外观
View 性能优化具体优化哪些工作？
标准回答
View 性能可以按阶段拆：创建阶段看 inflate 与控件初始化，布局阶段看重复测量和复杂层级，绘制阶段看 onDraw 成本、图片与过度绘制，渲染阶段再看 GPU、图层和缓冲区等待。
优化首先要定位占用关键路径的工作。未必越扁平就一定越快，也未必 ConstraintLayout 永远比 LinearLayout 快。布局层级、约束关系和测量次数一起决定成本，应该用真实页面和 Trace 验证。
常见改动包括延后非首屏布局、用 ViewStub 按需创建，减少重复 requestLayout，复用 Paint 和路径，将尺寸相关计算移到 onSizeChanged，并按实际展示尺寸加载图片。列表场景还要减少无差别刷新与重复绑定。
过度绘制指同一像素被反复处理，但不意味着出现重叠就必须删除。阴影、半透明和背景可能是设计需要，重点是删除无意义的层和重复工作，同时保持正确的视觉效果。
关键机制
- onDraw 避免磁盘 IO、复杂解析和每帧大批对象分配；不能靠少一次 invalidate 掩盖状态不同步。
- 异步 Inflate 只优化部分创建成本，无法直接消除后续 measure、layout 和 GPU 成本。
- 观察启动、滚动和连续动画等不同场景；首屏变快不能以首次交互明显卡顿为代价。
通俗例子
一个首屏永远折叠的复杂面板，不必启动时就创建全部孩子；按需加载可能比逐个微调绘图函数更有收益。
追问与回答
布局层级减少就一定提升吗？
层级减少可能降低遍历成本，但新布局也可能增加约束求解或重复测量。是否改善取决于具体页面、更新频率和瓶颈。我的判断标准是同场景下关键阶段是否缩短、画面是否正确，而不是仅比较 XML 少了几个标签。
易混淆点
先确定哪一段慢，再选措施。把所有优化 API 用一遍，可能只是把耗时和内存转移到另一处。
参考资料
内容来源
- Android 技术札记 · 原条目
layout-cost