Android 布局优化，看过来 ~

屏幕刷新机制

基本概念

• 刷新率：屏幕每秒刷新的次数，单位是 Hz，例如 60Hz，刷新率取决于硬件的固定参数。
• 帧率：GPU 在一秒内绘制操作的帧数，单位是 fps。Android 采用的是 60fps，即每秒 GPU 最多绘制 60 帧画面，帧率是动态变化的，例如当画面静止时，GPU 是没有绘制操作的，帧率就为0，屏幕刷新的还是 buffer 中的数据，即 GPU 最后操作的帧数据。

显示器不是一次性将画面显示到屏幕上，而是从左到右边，从上到下逐行扫描，顺序显示整屏的一个个像素点，不过这一过程快到人眼无法察觉到变化。以 60 Hz 刷新率的屏幕为例，这一过程的耗时： 1000 / 60 ≈ 16.6ms。

屏幕刷新的机制大概就是： CPU 执行应用层的测量，布局和绘制等操作，完成后将数据提交给 GPU，GPU 进一步处理数据，并将数据缓存起来，屏幕由一个个像素点组成，以固定的频率（16.6ms）从缓冲区中取出数据来填充像素点。

画面撕裂

如果一个屏幕内的数据来自两个不同的帧，画面会出现撕裂感。屏幕刷新率是固定的，比如每 16.6ms 从 buffer 取数据显示完一帧，理想情况下帧率和刷新率保持一致，即每绘制完成一帧，显示器显示一帧。但是 CPU 和 GPU 写数据是不可控的，所以会出现 buffer 里有些数据根本没显示出来就被重写了，即 buffer 里的数据可能是来自不同的帧，当屏幕刷新时，此时它并不知道 buffer 的状态，因此从 buffer 抓取的帧并不是完整的一帧画面，即出现画面撕裂。

那怎么解决这个问题呢？Android 系统采用的是 双缓冲 + VSync

双缓冲：让绘制和显示器拥有各自的 buffer，GPU 将完成的一帧图像数据写入到 BackBuffer，而显示器使用的是 FrameBuffer，当屏幕刷新时，FrameBuffer 并不会发生变化，当 BackBuffer 准备就绪后，它们才进行交换。那什么时候进行交换呢？那就得靠 VSync。

VSync：当设备屏幕刷新完毕后到下一帧刷新前，因为没有屏幕刷新，所以这段时间就是缓存交换的最佳时间。此时硬件屏幕会发出一个脉冲信号，告知 GPU 和 CPU 可以交换了，这个就是 Vsync 信号。

掉帧

有时，当布局比较复杂，或者设备性能较差的时候，CPU 并不能保证在 16.6ms 内就完成绘制，这里系统又做了一个处理，当正在往 BackBuffer 填充数据时，系统会将 BackBuffer 锁定。如果到了 GPU 交换两个 Buffer 的时间点，你的应用还在往 BackBuffer 中填充数据，会发现 BackBuffer 被锁定了，它会放弃这次交换。 这样做的后果就是手机屏幕仍然显示原先的图像，这就是所谓的掉帧。

优化方向

如果想要屏幕流畅运行，就必须保证 UI 全部的测量，布局和绘制的时间在 16.6ms 内，因为人眼与大脑之间的协作无法感知超过 60fps 的画面更新,也就是 1000 / 60Hz = 16.6ms，也就是说超过 16.6ms 用户就会感知到卡顿。

层级优化

层级越少，View 绘制得就越快，常用有两个方案。

• 合理使用 RelativeLayout 和 LinearLayout：层级一样优先使用 LinearLayout，因为 RelativeLayout 需要考虑视图之间的相对位置关系，需要更多的计算和更高的系统开销，但是使用 LinearLayout 有时会使嵌套层级变多，这时就应该使用 RelativeLayout。
• 使用 merge 标签：它会直接将其中的子元素添加到 merge 标签 Parent 中，这样就不会引入额外的层级。它只能用在布局文件的根元素，不能在 ViewStub 中使用 merge 标签，当需要 inflate 的布局本身是由 merge 作为根节点的话，需要将其置于 ViewGroup 中，设置 attachToRoot 为 true。

一个布局可以重复利用，当使用 include 引入布局时，可以考虑 merge 作为根节点，merge 根节点内的布局取决于include 这个布局的父布局。编写 XML 时，可以先用父布局作为根节点，然后完成后再用 merge 替换，方便我们预览效果。

merge_layout.xml

父布局如下：

如果需要通过 inflate 引入 merge_layout 布局文件时，可以这样引入：

class MyLinearLayout(context: Context, attrs: AttributeSet) : LinearLayout(context, attrs) {

    init {
        LayoutInflater.from(context).inflate(R.layout.merge_layout, this, true)
    }
}

第一个参数为 merge 布局文件 id，第二个参数为要将子视图添加到的 ViewGroup，第三个参数为是否将加载好的视图添加到 ViewGroup 中。

需要注意的是，merge 标签的布局，是不能设置 padding 的，比如像这样：

上面的这个 padding 是不会生效的，如果需要设置 padding，可以在其父布局中设置。

ViewStub

ViewStub 是一个轻量级的 View，一个看不见的，并且不占布局位置，占用资源非常小的视图对象。可以为 ViewStub 指定一个布局，加载布局时，只有 ViewStub 会被初始化，当 ViewStub 被设置为可见或 inflate 时，ViewStub 所指向的布局会被加载和实例化，可以使用 ViewStub 来设置是否显示某个布局。

ViewStub 只能用来加载一个布局文件，且只能加载一次，之后 ViewStub 对象会被置为空。适用于某个布局在加载后就不会有变化，想要控制显示和隐藏一个布局文件的场景，一个典型的场景就是我们网络请求返回数据为空时，往往要显示一个默认界面，表明暂无数据。

view_stub_layout.xml

通过 ViewStub 引入

然后在代码中 inflate，这里通过按钮点击来控制其显示和隐藏。

class MainActivity : AppCompatActivity() {

    private var viewStub: ViewStub? = null

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        val binding =
            DataBindingUtil.setContentView(this, R.layout.activity_main)
        binding.click = ClickEvent()
        viewStub = binding.defaultPage.viewStub
        if (!binding.defaultPage.isInflated) {
            viewStub?.inflate()
        }
    }

    inner class ClickEvent {
        // 后面 ViewStub 已经回收了，所以只能用 GONE 和 VISIBLE
        fun showView(view: View) {
            viewStub?.visibility = View.VISIBLE
        }

        fun hideView(view: View) {
            viewStub?.visibility = View.GONE
        }
    }
}

过度绘制

过度绘制是指屏幕上的某个像素在同一帧的时间内被绘制了多次，在多层次重叠的 UI 结构中，如果不可见的 UI 也在做绘制操作，就会导致某些像素区域被绘制了多次，从而浪费了 CPU 和 GPU 资源。

我们可以打开手机的开发人员选项，打开调试 GPU 过度绘制的开关，就能通过不同的颜色区域查看过度绘制情况。我们要做的，就是尽量减少红色，看到更多的蓝色。

• 无色：没有过度绘制，每个像素绘制了一次。
• 蓝色：每个像素多绘制了一次，蓝色还是可以接受的。
• 绿色：每个像素多绘制了两次。
• 深红：每个像素多绘制了4次或更多，影响性能，需要优化，应避免出现深红色区域。

优化方法：

• 减少不必要的背景：比如 Activity 往往会有一个默认的背景，这个背景由 DecorView 持有，当自定义布局有一个全屏的背景时，这个 DecorView 的背景对我们来说是无用的，但它会产生一次 Overdraw，可以干掉。

window.setBackgroundDrawable(null)

• 自定义 View 的优化：在自定义 View 的时候，某个区域可能会被绘制多次，造成过度绘制。可以通过 canvas.clipRect 方法指定绘制区域，可以节约 CPU 与 GPU 资源，在 clipRect 区域之外的绘制指令都不会被执行。

AsyncLayoutInflater

setContentView 函数是在 UI 线程执行的，其中有一系列的耗时动作：XML 的解析，View 的反射创建等过程都是在 UI 线程执行的，AsyncLayoutInflater 就是把这些过程以异步的方式执行，保持 UI 线程的高响应。

implementation 'androidx.asynclayoutinflater:asynclayoutinflater:1.0.0'

---

class TestActivity : AppCompatActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        AsyncLayoutInflater(this).inflate(R.layout.activity_test, null) { view, _, _ ->
            setContentView(view)
        }
    }
}

这样，将 UI 的加载过程迁移到了子线程，保证了 UI 线程的高响应，使用时需要特别注意，调用 UI 一定要等它初始化完成之后，不然可能会产生崩溃。

Compose

Jetpack Compose 相对于传统的 XML 布局方式，具有更强的可组合性，更高的效率和更佳的开发体验，相信未来会成为 Android UI 开发的主流方式。

传统的 XML 布局方式是基于声明式的 XML 代码编写的，使用大量的 XML 标签来描述 UI 结构，XML 文件通过解析和构建生成 View 对象，并将它们添加到 View 树中。在 Compose 中，UI 代码被组织成可组合的函数，每个函数都负责构建某个具体的 UI 元素，UI 元素的渲染是由 Compose 运行时直接管理的，Composable 函数会被调用，以计算并生成当前 UI 状态下的最终视图。

为了帮助到大家更好的全面清晰的掌握好性能优化，准备了相关的核心笔记（还含底层逻辑）：https://qr18.cn/FVlo89

性能优化核心笔记：https://qr18.cn/FVlo89

启动优化

内存优化

UI优化

网络优化

Bitmap优化与图片压缩优化：https://qr18.cn/FVlo89

多线程并发优化与数据传输效率优化

体积包优化

《Android 性能监控框架》：https://qr18.cn/FVlo89

《Android Framework学习手册》：https://qr18.cn/AQpN4J

1. 开机Init 进程
2. 开机启动 Zygote 进程
3. 开机启动 SystemServer 进程
4. Binder 驱动
5. AMS 的启动过程
6. PMS 的启动过程
7. Launcher 的启动过程
8. Android 四大组件
9. Android 系统服务 - Input 事件的分发过程
10. Android 底层渲染 - 屏幕刷新机制源码分析
11. Android 源码分析实战