一次 Android 首页性能体验优化复盘

脱敏说明：本文来自一段真实业务优化笔记，已去掉公司、业务线、内部平台、内部链接、截图和精确业务数据。文中的「某电商 App」「首页」「卡片」「首屏」只代表一类常见移动端业务场景。

背景

某电商 App 的首页在首次安装启动、冷启动和刷新场景下，存在比较明显的白屏、空坑和滑动卡顿。用户真正感受到的并不是某一个接口耗时，而是从点击图标到首屏可见、可滑动、图片稳定出现之间的连续体验。

所以这次优化没有只盯着单点耗时，而是围绕几个问题展开：

启动阶段是不是做了太多非必要任务？
首页首屏数据是否可以更早、更小、更稳定地返回？
View 创建和渲染能否前置或缓存？
图片从空白到显示之间有没有更平滑的过渡？
优化上线后如何发现劣化？

优化一：启动任务削峰填谷

首页启动阶段通常堆了很多初始化任务：消息、小程序、动态化引擎、快捷入口、实验配置、历史兼容逻辑等。这些任务单独看都合理，但叠在首屏阶段，就会抢 CPU、IO 和主线程调度。

处理方式是先把启动任务按优先级重新分组：

必须在首页可见前完成的任务保留在关键路径。
对首屏无感或低优先级的任务后置到首页稳定后。
可以异步执行的初始化尽量放到子线程。
历史实验、废弃开关、无用兼容逻辑直接下线。

这个动作的核心不是「一律延迟」，而是把任务和用户体感重新对齐。用户进入首页前必须要用到的东西，才应该占用首屏阶段的资源。

优化二：首屏接口拆分和预加载

首页接口往往为了业务扩展变得越来越大，但首屏真正依赖的数据有限。一个有效方向是拆分首屏关键数据和非关键数据：

首屏关键区块优先返回。
非首屏或低优先级区块延后请求。
固定字段和冗余字段做裁剪。
有缓存价值的数据允许本地持久化。

缓存使用上要注意一个边界：如果上一次数据导致启动崩溃，下一次启动不应该继续盲目使用同一份缓存。缓存策略最好和稳定性策略联动，比如启动异常后丢弃高风险缓存。

对于 Tab 类首页，还要警惕容器的预加载行为。很多容器默认会创建相邻页面，如果页面创建时就触发网络请求和渲染，启动阶段会突然多出几屏工作量。实际优化中，可以把相邻 Tab 的预加载请求延迟几秒，或由服务端/配置开关控制。

优化三：View 创建和渲染前置

首页里有些 View 创建成本较高，尤其是动态化容器、复杂卡片、嵌套列表。可以考虑几种手段：

异步 inflate。
部分 View 预创建。
卡片高度缓存。
动态化引擎初始化前置。
XML 布局转代码，减少反射和解析开销。

这里有一个容易踩坑的点：用 Application Context 提前创建 View 并不总是安全。Activity Context 可能携带主题、窗口、生命周期和资源配置语义。对 Dialog、PopupWindow、依赖主题属性的自定义 View、需要 Activity 跳转链路的组件，都需要白名单验证或保留兜底。

我的经验是，View 预创建可以做，但应该小范围、可回滚、可观测，不适合把所有 View 都粗暴前置。

优化四：图片直出和空坑治理

首页体感里，图片空白非常明显。即使文字和布局已经出来，只要首屏图片还在闪，用户仍然会觉得页面慢。

这里做了几类尝试：

使用缓存数据提前选择图片 URL 并预加载。
对尺寸确定、质量要求可控的首屏图片，走更短链路生成预加载 URL。
对固定小图标做内置资源，减少网络和图片库链路开销。
刷新时保留上一帧图片作为背景，避免新旧数据切换时出现空坑。

图片直出需要谨慎处理回退。比如 URL 规则、图片格式、尺寸裁剪、CDN 缓存 key 都可能影响最终质量和兼容性。比较稳的做法是只覆盖首屏、固定尺寸、失败可回退的图片场景。

缓存池也不能只看白屏收益，还要控制内存风险。至少要有 LRU 上限、Bitmap 大小估算、生命周期释放和低内存回调处理。

优化五：效果评估和防劣化

性能优化最怕只有一次性收益，没有长期约束。上线后需要同时看线上指标和线下体感。

线上指标可以关注：

首页打开耗时。
首屏关键区块出现时间。
首次可交互时间。
启动阶段卡顿时长。
分设备档位、网络环境、版本的分位数数据。

线下体感可以用录屏分帧、OCR 识别关键区块、自动化对比等方式。它不一定完全稳定，但能补足纯埋点看不到的视觉空窗。

我更喜欢把性能优化写成「防劣化系统」，而不是「某次专项」。因为首页会持续接业务，今天减掉的 200ms，明天可能被一个新任务悄悄吃回去。

总结

这次首页优化的主线不是某个神奇技巧，而是把首屏阶段重新拆开：

启动任务做削峰填谷。
首屏接口只保留关键链路。
View 创建和动态化容器适当前置。
图片加载减少空白和闪动。
指标和体感都纳入防劣化。

首页性能优化最终拼的是工程纪律：知道哪些事必须现在做，哪些事可以晚一点做，哪些事应该永远不要再做。