布局调试：Inspect Layouts 使用详解
说实话，Compose 的布局调试，远比你想的复杂。
我自己刚用 Compose 的时候，就踩过一个坑。一个简单的 Column，里面的文字死活对不齐。我改 modifier、调 alignment，折腾了半天，最后用 Inspect Layouts 一看——嗯，有个 padding 加错了地方。
这种问题，光看代码你根本看不出来。因为你脑子里会自动「脑补」布局的对齐逻辑，而实际渲染出来的东西，跟你想的完全不一样。
所以，Inspect Layouts 是我个人必用的工具。它就像布局的「X 光机」，一照下去，所有问题都无所遁形。
Inspect Layouts 是什么？为什么你需要它？
Inspect Layouts 是 Android Studio 自带的布局检查工具。如果你用过 View 系统的 Layout Inspector，那对这个应该不陌生。
但 Compose 的布局模型跟 View 不一样。View 是树形结构 + 逐个测量的。Compose 呢？它是三阶段流水线：组合 → 布局 → 绘制。所以 Compose 的 Inspect Layouts 展示的，其实是布局阶段的结果——每个组件的测量尺寸、摆放位置、约束条件，全在里面。
为什么要用它？说白了，就三个场景：
- UI 错位或溢出：文字跑到屏幕外面了，但代码里没看到明确的宽度限制。这时候，看一眼就有答案。
- 布局性能问题：某个组件反复重组，或者测量了 N 次。Inspect Layouts 能直接告诉你，谁触发了这个重组。
- Modifier 链诡异行为：padding、offset、size 叠加在一起，结果跟你预期的不一样。嗯，我建议你直接打开工具看看。
Inspect Layouts 的核心方法论
我要分享一个我自己的排查思路。分三步走：
- 先看整体结构：打开 Inspect Layouts，不急着点组件。先看左侧的组件树，感受一下布局深度。如果嵌套层级超过 5 层，可能需要考虑扁平化。
- 再点具体组件：选中某个组件，右侧会显示它的
bounding box、padding、size、offset。我一般先看size是不是match的，再看padding有没有加多。 - 最后看约束：Compose 没有传统的
ConstraintLayout约束，但Modifier.constrainAs或者Modifier.sizeIn会产生隐式约束。这些在 Inspect Layouts 里也能看到。
这套三步法，我基本每次调试都会走一遍。效率很高。
实战技巧：如何用好 Inspect Layouts
1. 启用 Inspect Layouts
在 Android Studio 中，点击 View → Tool Windows → Layout Inspector，然后选择你的进程。如果你用的是模拟器，按 Ctrl + Shift + L 可以直接截图并打开工具。
不过有个坑，你需要注意：Inspect Layouts 只对 Debug 构建生效。Release 构建默认不启用。
⚠️ 我曾经遇到的坑：Release 包上 Inspect Layouts 显示空白，折腾了半天，结果是因为混淆把类名弄乱了。建议调试时保持 Debug 构建。
2. 抓取布局快照
点击 Capture 按钮，工具会抓取当前屏幕的布局快照。
你可能会问，这跟直接截图有什么区别？
区别大了。截图只能看到像素，而布局快照能看到 组件的边界、Padding、Margin、甚至绘制顺序。而且，你还可以点击任意组件，查看它的 属性面板。
// 注意：Inspect Layouts 不需要写代码
// 只需要在 Android Studio 中操作即可
// 但你需要确保你的 Compose 版本 >= 1.0.0
3. 使用布局层级和属性面板
左侧的组件树，默认只显示上层节点。你可以展开，看到每一个 @Composable 函数生成的节点。
我强调一个经验：如果一个 Composable 生成了多个组件，它们会以父节点的形式存在。比如 Row 里面有三个 Text，你在左侧展开 Row 就能看到三个子节点。每个都标注了 measurement 信息。
右侧属性面板里，我会关注这几个字段：
| 字段 | 说明 | 常见问题 |
|---|---|---|
size |
组件的最终宽高 | 如果高度是 0，可能是内容为空或测量出错 |
padding |
内边距（left, top, right, bottom） | 四个方向不一致时，小心不对称 |
offset |
相对于父组件的偏移量 | 负值可能意味着组件溢出 |
alignment |
在父容器中的对齐方式 | Center 不如预期？可能跟 weight 冲突 |
4. 常见问题排查
问题一：组件显示不全或溢出
我遇到过好几次。一个 Text 加上长字符串，直接跑到屏幕外面去了。
Inspect Layouts 里一看，size 宽度是 wrap content，但父容器宽度有限，所以文字被裁剪了。
解决方法：给 Text 加上 .widthIn(max = ...) 或 .weight(1f)。
问题二：布局性能差，卡顿明显
这时候我会打开 Profile GPU Rendering 辅助分析。但先看 Inspect Layouts 的 drawing order，看看是不是有组件频繁重组。
在属性面板里，查看 recompose count。如果出现几百上千，说明你的 Composable 不稳定。
💡 个人小技巧：把 Inspect Layouts 和 @Stable 注解配合使用。我看到某个组件重组次数过高，首先检查它的参数是否被 mutableStateOf 包裹。
典型调试场景实战
场景 1：ConstraintLayout 中的约束冲突
假设你有两个 Button，一个靠左，一个靠右。结果一个把另一个覆盖了。
用 Inspect Layouts 选中两个按钮，看它们的 offset 和 size。你会发现，某个约束没生效，导致它们都占据了同样的空间。
// 错误示例
Button(
modifier = Modifier.constrainAs(btn1) {
start.linkTo(parent.start)
end.linkTo(parent.end) // 问题：占满整行
}
) { Text("Left") }
Button(
modifier = Modifier.constrainAs(btn2) {
start.linkTo(parent.start)
end.linkTo(parent.end) // 同样占满，必然冲突
}
) { Text("Right") }
Inspect Layouts 里，两个按钮的 size.width 都是父容器宽度，offset.x 是 0。这不覆盖才怪。
修复方法：一个用 start.linkTo(parent.start)，另一个用 end.linkTo(parent.end)。
场景 2：Modifier 顺序导致效果异常
之前有个学员问我，为什么 Modifier.padding(16.dp).size(100.dp) 和 Modifier.size(100.dp).padding(16.dp) 结果不一样？
我用 Inspect Layouts 给他演示了一下。
- 第一种：先 padding，再 size。padding 让组件内部空出了 16dp，然后 size 把整体撑到了 100dp。实际内容被压在了中间。
- 第二种：先 size，再 padding。组件先变成 100dp，然后 padding 向内缩了 16dp，所以内容区域只有 68dp。
Inspect Layouts 的属性面板里，size 和 padding 数值一目了然。你不需要靠猜。
场景 3：Intrinsic 测量导致的误导
Compose 的 IntrinsicSize 机制，有时候会让布局结果变得很奇怪。
比如一个 Column 里的子组件，明明设置了固定高度，但在 Inspect Layouts 里显示的高度却是父容器决定的。
这是因为 IntrinsicSize.Max 让子组件撑满父容器，导致你在属性面板里看到的高度，跟代码里的固定值不一样。
重点记住：Inspect Layouts 显示的是最终布局结果。它不会去区分「代码写的尺寸」和「实际渲染的尺寸」之间的差距。如果发现不一致，先检查有没有 IntrinsicSize 或 fillMaxSize。
SVG 图：Inspect Layouts 调试流程
下面这张图，是我总结的 Inspect Layouts 调试流程。你按这个思路走，80% 的布局问题都能找到根因。
总结：三个必须记住的点
- Inspect Layouts 是布局调试的「第一工具」。遇到布局问题，先打开它，不要盲目改代码。
- 关注 size、padding、offset 三个字段。这三者基本能解释 90% 的布局异常。
- 结合重组计数和绘制顺序，可以定位性能瓶颈。如果某个组件重组次数上了三位数，说明你的组件稳定性有问题。
好啦，这就是我的 Inspect Layouts 使用心得。下次你遇到布局问题，试试这三步，肯定能省不少时间。