3. Compose Layout Inspector实战：查看组件树、测量结果与布局边界
嘿，聊到 Compose 调试，有一个工具我几乎天天用——Layout Inspector。为什么？因为它能让你像玩「透视镜」一样，把屏幕上的每一个 Composable 扒得清清楚楚。说白了，它解决了一个核心痛点：UI 跑出来了，但跟你预期不一样，你根本不知道是哪个组件撑大了，还是哪个约束没对上。
我个人习惯，先打开 Layout Inspector 扫一眼组件树，再定位测量结果，最后看布局边界。三步下来，90% 的布局问题都能找到根因。这节课，我们就一步步拆解这个过程。
3.1 打开 Layout Inspector，迈出调试第一步
你先在模拟器或真机上跑起你的 Compose 应用。然后 Android Studio 里，点 Tools → Layout Inspector。弹出来的窗口里，左边是组件树，中间是预览图，右边是属性面板。
嗯，这里有个小坑：务必确保应用进程是 debug 或者 profile 模式。我遇到过好几次，release 包连上后组件树一片空白，折腾半天才发现没开 debuggable。排查方法很简单——在 app/build.gradle 的 debug 变体中默认就是可调试的，只要你不是手贱改了就行了。
3.2 看组件树：揪出那些「不该出现」的组件
组件树展示的是当前屏幕上的所有 Composable 层级。每一条都是一个节点。我通常会关注三点：
- 深度：节点嵌套超过 8 层，性能可能出问题。有一次我重构一个列表 item，把嵌套从 11 层压到 5 层，滑动帧率从 45fps 升到了 59fps。
- 重复节点：比如一个
Row里明明只放两个文字，结果树里出现三个Text。这就说明条件渲染逻辑写错了。 - 重组次数：每个节点旁边的数字，表示它在这一帧被重组了多少次。如果某个节点每次滑动都重组几十次，那你得考虑加
remember或者derivedStateOf了。
我的一个小技巧：在组件树顶部的搜索框里直接搜组件名，比如搜“Button”，就能快速定位到目标节点。不用在树里手动一层层点开。
3.3 看测量结果：你到底占了多少空间？
选中组件树里任意一个节点，右侧属性面板就会显示它的测量结果。主要看这几个字段：
| 字段 | 含义 | 实战关注点 |
|---|---|---|
Measured Width |
测量后的实际宽度（px） | 是否超出父容器限制 |
Measured Height |
测量后的实际高度（px） | 跟预期差太多？检查约束 |
Layout Direction |
布局方向 LTR / RTL | 国际化场景容易踩坑 |
Padding |
内边距（上右下左） | 默认值可能不是 0 |
Layout Bounds |
可见区域坐标（left, top, right, bottom） | 配合“Show borders”看是否被裁剪 |
举个例子，你写了一个 Box 里面包一个 Text，期望 Box 是 100dp 宽。结果测量出来只有 80dp。Why？很可能 Box 没有指定 Modifier.width(100.dp)，而父容器给了它一个 maxWidth = 80.dp 的约束。我个人习惯，看到测量值不对，立刻回看 父容器的 Constraints 面板——那里写着最小和最大宽高的限制值。
3.4 布局边界：开启「透视眼」模式
Layout Inspector 顶部有一个 Show borders 开关，点击后，每个 Composable 周围都会出现彩色边框。边框颜色和组件树里的颜色是对应的。你想想看，如果一个子组件超出了父组件边界，边框会直接「破出去」，一眼就能看到。
核心场景：当我发现某个 Card 的阴影被截断时，第一时间开启 Show borders。果然，Card 的父容器加了 clipToBounds = true，阴影被硬生生剪掉了。解决方案：去掉 clipToBounds 或者给父容器加个 Modifier.padding(...) 留出阴影空间。
还有一个容易被忽视的点——裁剪区（clipBounds）。在属性面板里找到 clipBounds 属性，如果显示非空，说明该节点做了裁剪。我曾经在 LazyColumn 的 item 里用 Modifier.clipToBounds() 导致内部 DropdownMenu 显示不全，排查了好久，最后就是靠 Layout Inspector 的 clipBounds 信息找到的元凶。
3.5 实战案例：一个诡异的高度问题
之前有个学员跑来问我：一个竖直排列列表（LazyColumn），每个 item 应该只有 60dp 高，但实际渲染出来第一项是 120dp，后面正常。怎么调都不行。
我让他打开 Layout Inspector，定位到第一项组件树。发现 LazyColumn 的 item 外层被包了一个 Box，而这个 Box 的测量高度是 120dp。点开 Box 的属性看约束：minHeight = 120.dp。哦，原来 Box 的父级 LazyColumn 内部用了一个 height(IntrinsicSize.Min) 吗？不，再往下看：实际上是因为这个 item 里有一个 Spacer(Modifier.height(60.dp)) 和一个 Text 各 60dp，加起来正好 120dp — 但 Text 没有限制高度，所以 Box 用 wrapContentHeight 刚好包裹两个。解决方案很简单：给 Box 加上 Modifier.height(60.dp) 硬限制高度。
注意：LazyColumn 的 item 外面默认会有一层 ListItemHeader 或者 ListItem 等系统包装，不要混淆了测量结果里的节点层级。记得先展开所有子节点，找到你写的那个 Composable。
3.6 总结几条实用经验
- 养成习惯：每次写完一个新的界面，都打开 Layout Inspector 看一眼组件树和测量结果，尤其是第一次写自适应布局。
- 善用筛选：组件树里输入
text可以过滤出所有文本节点；输入modifier有时也能看到一些额外信息。 - 看 Constraints：布局问题 80% 都出在约束上。属性面板里
Constraints那一栏，标明了父级允许的最小/最大宽高。如果子组件测量值刚好等于约束的最大值，说明可能被撑满了。 - 不要忽略黄色警告：属性面板里如果看到黄色三角形，通常是测量或布局期间抛出的异常（比如
CompositionLocal没有提供），点开看详情，往往能直接定位 bug。