一次不靠「重写」的性能优化：先量化，再按影响面排序，最后把优化固化进构建流程。
客户最初的诉求是「App 打开太慢」。慢是一种感受，无法直接优化。我们做的第一件事是把这句话翻译成三条可测量的指标，然后才动代码。
以上数据来自真机 4G 网络下的中位值，而非本地调试环境。所有后续判断都建立在这组基线之上。
我们在三个层面埋点：启动耗时（冷启动到首帧）、首屏数据可用时长、以及可交互时间。三者分开之后，问题立刻清楚了——启动耗时只占 0.9s，真正的瓶颈在首屏数据可用之前的串行等待。
这一步的意义在于避免「凭经验优化」。团队最初的直觉是渲染太重，量化后才发现渲染只占不到 20%。
用户信息、配置、随访任务三个接口依次发起，总耗时等于三者之和。
全部业务模块打进一个包，首屏只需要其中约三分之一的代码。
列表头图直接用了运营后台上传的原图，单张超过 800KB。
两款自定义字体同步加载，字体未就绪时文本区域保持空白。
性能优化最怕的是三个月后回退。我们在 CI 里加了两道门槛：主包体积超过阈值直接失败，核心页面首屏指标在回归测试中劣化超过 10% 则阻断合并。
同时接入真实用户监控（RUM），每周看线上分位数而不是平均值。平均值会掩盖低端机型的体验，而恰恰是那部分用户在流失。
优化本身不难，难的是让它不退化。能被 CI 挡住的回退，才叫优化成果。
这个项目里最有价值的不是那六项改动，而是「先量化再动手」的工作顺序。它让我们避开了重写 UI 层的诱惑，用八周而不是一个季度解决了真正的问题。
告诉我们所在行业与业务阶段，我们提供对应的交付路径与周期参考。
