相对布局(RelativeLayout)嵌套导致Layout卡顿瓶颈分析与方案

编舞者Choreographer#doFrame 做一次从ViewRootImpl到子View的traversal遍历，需要经历animation，input，measure，layout，draw

卡顿优化就针对这5个过程，进行耗时优化。

测试设备：vivo X20Plus

场景：

主feeds手指往上滑，从一个视频滑到另外一个视频并启播，分析Trace

在新视频启播过程中，这一次遍历的性能瓶颈是layout，从trace中可以看到是约束布局做onMeasure次数达到32次，进一步分析发现是同一对象的约束布局被反复执行onMeasure

所以第一步就是要分析被多次执行的根因。

梳理布局层次，层级较深同时容器嵌套较多，那么是否层级深就会引发上述问题，答案是否定的。通过追溯相对布局系统源码发现问题所在。

从相对布局的源码看，一次onMeasure实现上，会遍历所有Child两次，且做两次child的measure，换句话说，使用相对布局(不嵌套的情况下)，在一次doFrame遍历中，他的child会进行2次measure，这是一个很重要的结论。

虽然一直都知道不要嵌套布局这样的规范，但并不深刻，这里知其然，知其所以然

按照上述结论，在左侧这样的布局当中，叶子节点ViewGroup，在一次doFrame遍历中，onMeasure会被执行2^5=32次。

再重新看前面Trace会发现，约束布局同一对象被执行了32次onMeasure，所以首先要做的就是优化相对布局，那么用什么布局代替呢？帧布局或线性布局。约束布局本身其实也耗时(具体可看源码，这里不在列出)

从上述现象可以看到，越容易布局的Layout(相对布局或约束布局)，性能越差，越难以布局的Layout(帧布局，线性布局)，性能越好。

一般来讲，直接再一个xml中嵌套相对布局的写法不常见，但由于自定义View的存在，咱们大部分时候的写法如下：

类似于这样的代码较多，优点很明显，方便解耦集中维护自己业务布局，缺点是容易被相对布局嵌套导致doFrame遍历耗时。

使用帧布局替换所有的相对布局后：

同样操作下耗时从300m→50ms,同时，不再有同一个对象被反复onMeasure的情况出现了，证明是直接有效的。

结论：相对布局和约束布局禁止嵌套使用，需要嵌套布局使用帧布局或线性布局，仅作为容器(壳)的布局尽量使用帧布局

在复杂层级深的布局中，顶层根布局容器尽量选择帧布局，叶子节点的布局容器可以不受限制，但尽量不选择约束布局。

同时，inflate的xml中自定义布局不是马上需要显示，或则条件显示的，建议设置visibility=gone，避免不需要显示的时候也会去measure和layout

比较好的层级深的布局层级如下：

简单布局，例如只有一层父容器这种，不受限制，因为本身耗时不多