布局渲染优化：从卡顿到丝滑的必经之路

说实话，布局渲染这块，是我在性能优化路上踩坑最多的地方。早期做项目时，总觉得界面能显示出来就行，直到用户反馈「滑动卡成PPT」，我才意识到——布局层级和渲染效率，直接决定了App的生死。

今天咱们就聊聊布局渲染优化的几个核心手段。我会结合自己的实战经验，把那些坑和技巧都抖出来。

布局层级优化：少即是多

你想想看，一个界面嵌套了七八层RelativeLayout，会是什么后果？测量、布局、绘制三个阶段，每一层都要递归遍历。层级越深，CPU和GPU的负担就越重。

我在项目中遇到过最夸张的一个页面，光布局文件就写了600行，嵌套了11层。结果呢？在低端机上启动要3秒多。后来我硬是把它压到了4层，启动时间降到了800毫秒。

核心原则：

  • 能用ConstraintLayout，就别用多层LinearLayout
  • 能用RelativeLayout一层解决的，就别套两层
  • 避免使用FrameLayout做无意义的包裹

这里有个小技巧：用Layout Inspector工具查看实际渲染层级。别光看代码，实际跑起来才知道系统是怎么解析的。我习惯每写完一个页面，都跑一遍Layout Inspector，看看有没有多余的层级。

// 优化前：三层嵌套
<LinearLayout>
    <LinearLayout>
        <TextView />
        <TextView />
    </LinearLayout>
    <ImageView />
</LinearLayout>

// 优化后：一层ConstraintLayout搞定
<androidx.constraintlayout.widget.ConstraintLayout>
    <TextView app:layout_constraintTop_toTopOf="parent" />
    <TextView app:layout_constraintTop_toBottomOf="@id/tv1" />
    <ImageView app:layout_constraintTop_toTopOf="parent" app:layout_constraintEnd_toEndOf="parent" />
</androidx.constraintlayout.widget.ConstraintLayout>

过度绘制检测：别让GPU白干活

过度绘制，说白了就是同一个像素点被重复绘制了多次。你想想看，GPU辛辛苦苦画了一层，结果又被另一层盖住了，这不是白干活吗？

怎么检测？打开开发者选项里的「调试GPU过度绘制」开关。界面会变成彩色：

颜色 含义 建议
蓝色 绘制1次（理想） 保持
绿色 绘制2次 可接受
粉色 绘制3次 需要优化
红色 绘制4次以上 必须优化

我曾经接手过一个列表页面，整个屏幕都是红色。排查后发现，每个item的背景、父容器的背景、甚至ListView本身都设置了背景色。去掉多余的背景后，直接变成了蓝色。

避坑指南：我曾经在自定义View里直接画了一个全屏矩形作为背景，然后又给ViewGroup设置了background。结果就是双重绘制。后来我统一用setWillNotDraw(false)控制，才彻底解决。

ViewStub与Merge标签：懒加载的艺术

有些布局，不是一开始就需要显示的。比如「加载失败」的提示、「暂无数据」的占位图。如果一开始就加载进来，不仅浪费内存，还会拖慢启动速度。

ViewStub就是干这个的。它是一个轻量级的View，只有在调用inflate()或setVisibility(View.VISIBLE)时，才会真正加载布局。

<ViewStub
    android:id="@+id/stub_loading"
    android:layout="@layout/layout_loading"
    android:layout_width="match_parent"
    android:layout_height="wrap_content" />

// 使用时
val stub = findViewById<ViewStub>(R.id.stub_loading)
stub.inflate()  // 此时才真正加载

再说说Merge标签。它有什么用？减少一层不必要的布局嵌套。比如你自定义了一个组合控件，外面套了个LinearLayout，里面又放了一堆子View。如果父布局已经是LinearLayout了，那这个自定义控件的根布局就可以用Merge代替。

<!-- 自定义布局文件 -->
<merge xmlns:android="http://schemas.android.com/apk/res/android">
    <Button
        android:id="@+id/btn_ok"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="确定" />
    <Button
        android:id="@+id/btn_cancel"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="取消" />
</merge>

// 使用时，直接添加到父布局中，不会多一层

注意：Merge标签只能作为布局文件的根标签使用。而且，它必须配合addView()或inflate()时指定attachToRoot为true才能生效。否则，它就是个摆设。

异步布局：AsyncLayoutInflater的妙用

你有没有遇到过这种情况：一个复杂的列表，滑动时卡顿明显。原因往往是主线程在忙着解析布局文件。

AsyncLayoutInflater就是来解决这个问题的。它在后台线程解析布局文件，解析完成后回调到主线程，直接使用解析好的View。

AsyncLayoutInflater(this).inflate(R.layout.complex_item, parent) { view, resid, parent ->
    // 回调在主线程，可以直接使用view
    parent.addView(view)
}

嗯，这里要注意一点：AsyncLayoutInflater不支持在后台线程中创建带构造参数的View。如果你自定义了View，并且重写了带AttributeSet的构造方法，那没问题。但如果你的View只有Context参数的构造方法，就会报错。

我在项目中用过一次，效果立竿见影。一个原本需要120ms才能加载完成的复杂卡片，用异步布局后，主线程几乎零等待。不过，它不适合所有场景。比如列表的item，如果每个item都异步加载，反而会因为线程切换增加开销。我建议只在首次进入页面时加载的复杂布局中使用。

总结一下我的优化清单：

  1. 用Layout Inspector检查层级，能压到4层以内最好
  2. 打开过度绘制检测，把红色区域消灭掉
  3. 非首屏显示的布局，用ViewStub懒加载
  4. 自定义组合控件，用Merge减少嵌套
  5. 复杂布局首次加载，用AsyncLayoutInflater异步解析

说白了，布局渲染优化没有太多玄学。就是少画、晚画、异步画。你按照这个思路去排查，大部分卡顿问题都能解决。下次咱们聊聊「内存优化」——那又是一个大坑，我当年被OOM折磨得够呛。

← 上一章 📖 返回目录 下一章 →