FrameLayout和LinearLayout性能PK

FrameLayout

LinearLayout

Measure：2.058ms
Layout：0.296ms
draw：3.857ms

FrameLayout

Measure：1.334ms
Layout：0.213ms
draw：3.680ms
从这个数据来使用LinearLayout，仅嵌套一个LinearLayou，在onMeasure就相关2倍时间和FrameLayout相比，layout和draw的过程两者相差无几，考虑到误差的问题，几乎可以认为两者不分伯仲

看下FrameLayout的源码，做了什么？

 protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {int count = getChildCount();final boolean measureMatchParentChildren =MeasureSpec.getMode(widthMeasureSpec) != MeasureSpec.EXACTLY ||MeasureSpec.getMode(heightMeasureSpec) != MeasureSpec.EXACTLY;//当FrameLayout的宽和高，只有同时设置为match_parent或者指定的size，那么这个//measureMatchParentChlidren = false，否则为true。下面会用到这个变量mMatchParentChildren.clear();int maxHeight = 0;     int maxWidth = 0;int childState = 0;    //宽高的期望类型for (int i = 0; i < count; i++) {    //一次遍历每一个不为GONE的子viewfinal View child = getChildAt(i);    if (mMeasureAllChildren || child.getVisibility() != GONE) {//去掉FrameLayout的左右padding，子view的左右margin，这时候，再去//计算子view的期望的值measureChildWithMargins(child, widthMeasureSpec, 0, heightMeasureSpec, 0);final LayoutParams lp = (LayoutParams) child.getLayoutParams();/*maxWidth找到子View中最大的宽，高同理，为什么要找到他，因为在这里，FrameLayout是wrap-content.他的宽高肯定受子view的影响*/maxWidth = Math.max(maxWidth,child.getMeasuredWidth() + lp.leftMargin + lp.rightMargin);maxHeight = Math.max(maxHeight,child.getMeasuredHeight() + lp.topMargin + lp.bottomMargin);childState = combineMeasuredStates(childState, child.getMeasuredState());/*下面的判断，只有上面的FragLayout的width和height都设置为match_parent 才不会执行此处的mMatchParentChlidren的list里存的是设置为match_parent的子view。结合上面两句话的意思，当FrameLayout设置为wrap_content，这时候要把所有宽高设置为match_parent的子View都记录下来，记录下来干什么呢？这时候FrameLayout的宽高同时受子View的影响*/if (measureMatchParentChildren) {if (lp.width == LayoutParams.MATCH_PARENT ||lp.height == LayoutParams.MATCH_PARENT) {mMatchParentChildren.add(child);}}}}// Account for padding toomaxWidth += getPaddingLeftWithForeground() + getPaddingRightWithForeground();maxHeight += getPaddingTopWithForeground() + getPaddingBottomWithForeground();// Check against our minimum height and widthmaxHeight = Math.max(maxHeight, getSuggestedMinimumHeight());maxWidth = Math.max(maxWidth, getSuggestedMinimumWidth());// Check against our foreground's minimum height and widthfinal Drawable drawable = getForeground();if (drawable != null) {maxHeight = Math.max(maxHeight, drawable.getMinimumHeight());maxWidth = Math.max(maxWidth, drawable.getMinimumWidth());}//设置测量过的宽高setMeasuredDimension(resolveSizeAndState(maxWidth, widthMeasureSpec, childState),resolveSizeAndState(maxHeight, heightMeasureSpec,childState << MEASURED_HEIGHT_STATE_SHIFT));count = mMatchParentChildren.size();//这个大小就是子view中设定为match_parent的个数if (count > 1) {for (int i = 0; i < count; i++) {//这里看上去重新计算了一遍final View child = mMatchParentChildren.get(i);final MarginLayoutParams lp = (MarginLayoutParams) child.getLayoutParams();int childWidthMeasureSpec;int childHeightMeasureSpec;/*如果子view的宽是match_parent，则宽度期望值是总宽度-padding-margin如果子view的宽是指定的比如100dp，则宽度期望值是padding+margin+width这个很容易理解,下面的高同理*/if (lp.width == LayoutParams.MATCH_PARENT) {childWidthMeasureSpec = MeasureSpec.makeMeasureSpec(getMeasuredWidth() -getPaddingLeftWithForeground() - getPaddingRightWithForeground() -lp.leftMargin - lp.rightMargin,MeasureSpec.EXACTLY);} else {childWidthMeasureSpec = getChildMeasureSpec(widthMeasureSpec,getPaddingLeftWithForeground() + getPaddingRightWithForeground() +lp.leftMargin + lp.rightMargin,lp.width);}if (lp.height == LayoutParams.MATCH_PARENT) {childHeightMeasureSpec = MeasureSpec.makeMeasureSpec(getMeasuredHeight() -getPaddingTopWithForeground() - getPaddingBottomWithForeground() -lp.topMargin - lp.bottomMargin,MeasureSpec.EXACTLY);} else {childHeightMeasureSpec = getChildMeasureSpec(heightMeasureSpec,getPaddingTopWithForeground() + getPaddingBottomWithForeground() +lp.topMargin + lp.bottomMargin,lp.height);}//把这部分子view重新计算大小child.measure(childWidthMeasureSpec, childHeightMeasureSpec);}}}

加了一个嵌套，onMeasure时间，多了将近一倍，原因在于：LinearLayout在某一方向onMeasure，发现还存在LinearLayout。将触发  if (useLargestChild && (heightMode == MeasureSpec.AT_MOST || heightMode == MeasureSpec.UNSPECIFIED)) {
            mTotalLength = 0;
            for (int i = 0; i < count; ++i) {
                final View child = getVirtualChildAt(i);
                if (child == null) {
                    mTotalLength += measureNullChild(i);
                    continue;
                }
                if (child.getVisibility() == GONE) {
                    i += getChildrenSkipCount(child, i);
                    continue;
                }

}

因为二级LinearLayout父类是Match_parent，所以就存在再层遍历。在时间就自然存在消耗。

结论

1.RelativeLayout会让子View调用2次onMeasure，LinearLayout 在有weight时，也会调用子View2次onMeasure
2.RelativeLayout的子View如果高度和RelativeLayout不同，则会引发效率问题，当子View很复杂时，这个问题会更加严重。如果可以，尽量使用padding代替margin。
3.在不影响层级深度的情况下,使用LinearLayout和FrameLayout而不是RelativeLayout。
最后再思考一下文章开头那个矛盾的问题，为什么Google给开发者默认新建了个RelativeLayout，而自己却在DecorView中用了个LinearLayout。因为DecorView的层级深度是已知而且固定的，上面一个标题栏，下面一个内容栏。采用RelativeLayout并不会降低层级深度，所以此时在根节点上用LinearLayout是效率最高的。而之所以给开发者默认新建了个RelativeLayout是希望开发者能采用尽量少的View层级来表达布局以实现性能最优，因为复杂的View嵌套对性能的影响会更大一些。

4.能用两层LinearLayout，尽量用一个RelativeLayout，在时间上此时RelativeLayout耗时更小。另外LinearLayout慎用layout_weight,也将会增加一倍耗时操作。由于使用LinearLayout的layout_weight,大多数时间是不一样的，这会降低测量的速度。这只是一个如何合理使用Layout的案例，必要的时候，你要小心考虑是否用layout weight。总之减少层级结构，才是王道，让onMeasure做延迟加载，用viewStub，include等一些技巧。