Android布局层级过深为什么会对性能有影响？为什么Compose没有布局嵌套问题？

Posted 2023-04-02 码中之牛

做过布局性能优化的同学都知道，为了优化界面加载速度，要尽可能的减少布局的层级。这主要是因为布局层级的增加，可能会导致测量时间呈指数级增长。

而Compose却没有这个问题，它从根本上解决了布局层级对布局性能的影响: Compose界面只允许一次测量。这意味着随着布局层级的加深，测量时间也只是线性增长的.

下面我们就一起来看看Compose到底是怎么只测量一次就把活给干了的,本文主要包括以下内容：

• 布局层级过深为什么影响性能?
• Compose为什么没有布局嵌套问题?

①布局层级过深为什么影响性能?

我们总说布局层级过深会影响性能，那么到底是怎么影响的呢？主要是因为在某些情况下ViewGroup会对子View进行多次测量

举个例子

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="wrap_content"
    android:layout_height="match_parent"
    android:orientation="vertical">

    <View
        android:layout_width="match_parent"
        android:layout_height="100dp"
        android:background="@android:color/holo_red_dark" />

    <View
        android:layout_width="100dp"
        android:layout_height="100dp"
        android:background="@android:color/black" />
</LinearLayout>

• LinearLayout宽度为wrap_content,因此它将选择子View的最大宽度为其最后的宽度
• 但是有个子View的宽度为match_parent，意思它将以LinearLayout的宽度为宽度，这就陷入死循环了
• 因此这时候， LinearLayout 就会先以0为强制宽度测量一下子View，并正常地测量剩下的其他子View，然后再用其他子View里最宽的那个的宽度，二次测量这个match_parent的子 View，最终得出它的尺寸，并把这个宽度作为自己最终的宽度。
• 这是对单个子View的二次测量，如果有多个子View写了match_parent ，那就需要对它们每一个都进行二次测量。
• 除此之外，如果在LinearLayout中使用了weight会导致测量3次甚至更多,重复测量在Android中是很常见的

上面介绍了为什么会出现重复测量，那么会有什么影响呢？不过是多测量了几次，会对性能有什么大的影响吗？

之所以需要避免布局层级过深是因为它对性能的影响是指数级的

• 如果我们的布局有两层，其中父View会对每个子View做二次测量，那它的每个子View一共需要被测量 2 次

• 如果增加到三层，并且每个父View依然都做二次测量，这时候最下面的子View被测量的次数就直接翻倍了，变成 4 次

• 同理，增加到 4 层的话会再次翻倍，子 View 需要被测量 8 次

也就是说，对于会做二次测量的系统，层级加深对测量时间的影响是指数级的,这就是Android官方文档建议我们减少布局层级的原因

②Compose为什么没有布局嵌套问题?

我们知道，Compose只允许测量一次，不允许重复测量。

如果每个父组件对每个子组件只测量一次，那就直接意味着界面中的每个组件只会被测量一次

这样即使布局层级加深，测量时间却没有增加，把组件加载的时间复杂度从O(2ⁿ) 降到了 O(n)。

那么问题就来了，上面我们已经知道，多次测量有时是必要的，但是为什么Compose不需要呢？

Compose中引入了固有特性测量(Intrinsic Measurement)

固有特性测量即Compose允许父组件在对子组件进行测量之前，先测量一下子组件的「固有尺寸」

我们上面说的，ViewGroup的二次测量，也是先进行这种「粗略测量」再进行最终的「正式测量」，使用固有特性测量可以产生同样的效果

而使用固有特性测量之所以有性能优势，主要是因为其不会随着层级的加深而加倍，固有特性测量也只进行一次

Compose会先对整个组件树进行一次Intrinsic测量，然后再对整体进行正式的测量。这样开辟两个平行的测量过程，就可以避免因为层级增加而对同一个子组件反复测量所导致的测量时间的不断加倍了。

总结成一句话就是，在Compose里疯狂嵌套地写界面，和把所有组件全都写进同一层里面，性能是一样的！所以Compose没有布局嵌套问题

Android 学习笔录

Kotlin 篇：https://qr18.cn/CdjtAF
Android 性能优化篇：https://qr18.cn/FVlo89
Android 车载篇：https://qr18.cn/F05ZCM
Android Framework底层原理篇：https://qr18.cn/AQpN4J
Android 音视频篇：https://qr18.cn/Ei3VPD
Jetpack全家桶篇（内含Compose）：https://qr18.cn/A0gajp
Gradle 篇：https://qr18.cn/DzrmMB
OkHttp 源码解析笔记：https://qr18.cn/Cw0pBD
Flutter 篇：https://qr18.cn/DIvKma
Android 八大知识体：https://qr18.cn/CyxarU
Android 核心笔记：https://qr21.cn/CaZQLo
Android 面试题锦：https://qr18.cn/CKV8OZ

Android布局优化之层级优化

程序的每个组件和 Layout 都需要经过初始化、布局和绘制，如果布局嵌套层次过深，就会导致加载操作更为耗时，更严重的话还可能导致内存溢出。本节我们学习使用两个工具来检查和优化 Layout。

 

 

HierarchyViewer

 

 

该工具位于Android SDK tools中，使用HierarchyViewer可以分析正在运行app的布局，从而打破影响布局性能的瓶颈。

 

HierachyViewer通过选择运行在模拟器或真机上的进程来工作，并通过布局树来展示。上面每个标识代表布局的Measure、Layout和Draw的性能，帮助开发者来定位潜在的问题。

 

如图1所示，图中是ListView中的一条布局，这个布局左边是一个ImageView，右边是一个LinearLayout中嵌套两个TextView布局。

 

 

图1

 

HierarchyView工具可以用于Android模拟器，打开后，即可看到可用设备列表和运行的组件。在Windows选项卡里，点击Hierarchy View后，即可看到选择组件的布局层次结构。例如图2 展示了图1 的ListItem布局的层次结构。

 

图2

 

 

减少层次结构

 

由于上图使用了嵌套的LinearLayout结构布局，导致性能变慢。我们可以使用扁平化的思想来优化它们——布局要宽而广，而不是窄而深！ 我们可以使用Relativelayout来作为顶级节点，这样转向RelativeLayout来布局之后，我们会看到下图这样的布局层级结构。

 

图3

 

修改为RelativeLayout布局之后，层级减少，布局性能大大增强。另外，LinearLayout中的layout_weight也会减慢measure的速度，所以不是必要时不要使用layout_weight属性。这只是一个小小的例子，在一些非常复杂的布局中，如果层级太多或LinearLayout嵌套过多，系统会将很大性能消耗在UI的measure计算上面，因此，层级结构优化至关重要。

 

Lint

Android Lint是在 ADT 16 提供的新工具，它是一个代码扫描工具，Lint已经替代了Layoutopt tool成为重要的提示工具，它具有更多更高级的功能 ，能够帮助我们识别代码结构存在的问题。Lint 包含的一些检测规则有：

 

• 使用 compound drawable 替代一个包含 ImageView 和 TextView 的 LinearLayout。

• 合并根 FrameLayout

• 没用的子节点或父节点

• 硬编码问题

 

另外，开发者可以通过 File>Settings>Project Settings 来管理配置文件。