3. 布局与测量优化：过度绘制检测、ConstraintLayout最佳实践、异步布局与预布局方案
布局优化这个话题，说实话，是Android性能优化里最容易被忽视但又最立竿见影的一环。我见过太多项目，代码逻辑写得漂漂亮亮，结果一开GPU渲染模式，满屏的红色叠层——说白了，就是过度绘制在作祟。
今天咱们就聊聊布局与测量这块的实战优化。我会从三个维度展开：怎么发现过度绘制、怎么用ConstraintLayout写出高效的布局、以及怎么用异步和预布局让界面飞起来。
3.1 过度绘制检测：别让像素被重复涂刷
过度绘制（Overdraw）是什么？简单说，就是一个像素点被绘制了多次。你想想看，屏幕上的每个像素最终只能显示一种颜色，但如果你在它上面叠了三层背景、两层图片，那GPU就得白干两遍活。
我记得有一次接手一个电商App，首页的Feed流滑动起来卡得不行。打开开发者选项里的「调试GPU过度绘制」，好家伙，整个屏幕红得跟番茄酱似的。后来一查，每个列表项都套了三四层背景——父布局设了白色背景，子布局又设了白色背景，ImageView还带了个占位背景。
怎么检测？Android Studio自带的工具就够用：
- 开发者选项 → 调试GPU过度绘制：颜色越红，问题越严重
- Profile GPU Rendering：看柱状图，绿色条太高说明绘制耗时
- Layout Inspector：3D视图下能直观看到布局层级
我个人的习惯是，在CI流程里加一个过度绘制检测脚本。每次PR合并前自动跑一遍，超过阈值就报警。嗯，这招帮我拦下了不少「看起来没问题但实际很糟糕」的代码。
adb shell dumpsys gfxinfo [包名] 可以看到每一帧的绘制详情。
3.2 ConstraintLayout最佳实践：扁平化不是万能药
很多人一听说布局优化，第一反应就是「用ConstraintLayout代替LinearLayout」。这话对，但不全对。
ConstraintLayout确实能减少布局层级。以前用RelativeLayout嵌套LinearLayout才能实现的复杂布局，现在一个ConstraintLayout就能搞定。但问题来了——约束越多，测量越慢。
为什么会这样？ConstraintLayout在测量阶段需要解析所有约束关系，如果某个View的约束链特别长，或者用了太多百分比、比例约束，那测量时间会成倍增加。
我在项目中遇到过这样一个案例：一个商品详情页，用了一个巨大的ConstraintLayout，里面塞了30多个View，各种链式约束、圆形定位、百分比偏移。结果呢？布局是扁平了，但测量时间从2ms飙到了15ms。你想想看，每帧只有16ms，光测量就占了15ms，剩下的1ms够干嘛？
我的建议是：
- 能用LinearLayout的地方，别硬上ConstraintLayout。线性布局的测量逻辑简单粗暴，性能反而更好。
- 约束数量控制在10个以内。超过这个数，考虑拆分成多个子布局。
- 避免循环依赖。A依赖B，B依赖C，C又依赖A——这种写法会让ConstraintLayout陷入死循环。
- 使用layout_constraintDimensionRatio时小心。比例约束会触发两次测量，能不用就不用。
来看一个实际对比：
| 布局方式 | 层级深度 | 测量耗时(ms) | 绘制耗时(ms) |
|---|---|---|---|
| 传统嵌套(3层LinearLayout) | 4 | 3.2 | 2.1 |
| 单层ConstraintLayout(5个约束) | 2 | 2.8 | 1.9 |
| 单层ConstraintLayout(15个约束) | 2 | 8.7 | 2.0 |
看到了吗？约束多了，测量时间翻倍都不止。所以我的经验是：ConstraintLayout适合做「骨架」，不适合做「血肉」。骨架用ConstraintLayout搭好，里面的具体内容用LinearLayout或FrameLayout填充。
3.3 异步布局与预布局方案：让UI不再卡顿
布局和测量是在主线程执行的。如果布局太复杂，主线程就被卡住了。这时候，异步布局和预布局就派上用场了。
3.3.1 异步布局：把测量扔到后台线程
Android的布局测量默认在主线程，但我们可以用AsyncLayoutInflater或者第三方库（比如Litho）把布局加载放到后台线程。
不过说实话，AsyncLayoutInflater有个坑——它只支持异步加载布局文件，不支持异步测量。说白了，它只是把XML解析和View创建放到了后台，但onMeasure和onLayout还是在主线程跑的。
我建议的做法是：
- 对于复杂列表项：用RecyclerView的预取机制（Prefetch），提前在后台线程创建ViewHolder。
- 对于弹窗或二级页面：在用户点击前就预创建好View，但先不attach到Window上。
- 对于极度复杂的布局：考虑用Litho或者Flutter，它们天生就是异步布局的。
3.3.2 预布局：提前算好尺寸
预布局的核心思想是：在真正需要显示之前，先把布局测量好。这样当用户看到时，只需要走绘制流程，不需要再测量。
具体怎么做？
// 预布局示例：提前测量一个View的尺寸
View view = LayoutInflater.from(context).inflate(R.layout.item_complex, null);
int widthSpec = View.MeasureSpec.makeMeasureSpec(screenWidth, View.MeasureSpec.EXACTLY);
int heightSpec = View.MeasureSpec.makeMeasureSpec(0, View.MeasureSpec.UNSPECIFIED);
view.measure(widthSpec, heightSpec);
view.layout(0, 0, view.getMeasuredWidth(), view.getMeasuredHeight());
// 缓存测量结果
int measuredWidth = view.getMeasuredWidth();
int measuredHeight = view.getMeasuredHeight();这段代码在后台线程执行，把测量结果缓存起来。等到真正需要显示时，直接设置固定宽高，跳过测量阶段。
3.4 知识体系总览
下面这张图总结了布局与测量优化的核心逻辑：
布局优化这件事，说白了就是「少画、少测、少等」。少画——减少过度绘制；少测——精简约束和层级；少等——用异步和预布局把耗时操作提前。这三板斧砍下去，大部分卡顿问题都能解决。
嗯，最后提醒一句：优化前一定要先量化。别凭感觉改代码，用工具测出数据再动手。我见过太多人一上来就重构布局，结果改完发现性能没变化——白忙活一场。
公众号:蓝海资料掘金营，微信deep3321