Compose 性能分析：Layout Inspector 之外还有什么

Compose性能分析：Layout Inspector之外还有什么

去年把项目里的Compose BOM从2023.06.00升级到2023.10.00，对应Compose UI 1.5.3，编译器升到1.5.3，配合Android Studio Iguana 2023.2.1 Patch 2，重构了一个设置页。界面本身不复杂，一个LazyColumn套几组Preference项，但真机测试时滑动有明显顿挫。打开Layout Inspector，层级极其干净：一个LazyColumn，里面直接是自定义的ListItem，没有深层嵌套，也没有过度绘制。Layout Inspector的重组高亮偶尔闪一下，看起来重组频率也不高。可帧率就是上不去。这个场景让我意识到，对于Compose，Layout Inspector能揭示的问题实在太有限了，它本质上还是一个“布局层级”观察器，而Compose的性能瓶颈往往不在布局，而在重组粒度、状态订阅和测量策略。

Layout Inspector的重组高亮只能当个参考

Android Studio Giraffe之后，Layout Inspector对Compose的支持多了一项重组计数，配合Compose UI Tooling 1.4.0以上版本，可以在调试时看到每个Composable的重组次数，高亮闪烁也能直观展示哪些地方在反复计算。这个功能在演示时很漂亮，但真正用来定位性能问题时，误导性不小。

第一个问题是观察本身会改变结果。Layout Inspector的重组计数依赖debug build，而Compose在debug和release下的执行路径差异极大。debug build会启用更多断言、额外的修饰符检查，以及Compose Runtime内部的一些校验逻辑。很多在debug下看起来“频繁重组”的代码，在release下其实被编译器优化掉了。反过来更麻烦：release build里实际在反复重组的Composable，在debug下可能因为执行速度变慢，导致帧率下降被掩盖，