应用优化的这笔成本账，小团队半年只换来0.4秒

我们花了半年做应用优化，启动时长从 2.8 秒压到 2.4 秒，商店评分一分没动。

后来复盘才发现，问题不在技术，在选错了指标。这篇讲清三个指标的口径，以及怎么避免白干半年。

应用优化做了半年，账是怎么算歪的

当时我们的假设是：启动慢导致用户流失。于是立项时把启动耗时定成唯一目标，从 2.8 秒一路优化到 2.4 秒，团队投入了 3 个人、半年时间。指标选错，做得再认真也是在错误的方向上加码。

上线后看数据才发现，真正影响转化的是登录环节的表单长度，而不是启动那 0.4 秒。用户从首页到注册成功，平均要填 9 个字段，这里流失了 6 成。

复盘时我们总结了一条经验：优化前先做主路径漏斗，找出流失最大的那一步，再决定优化什么。这一步只花了两天，却本该在立项时做。

这里补一句，同一主题我在另一篇里拆得更细，企业应用软件那篇可以一并看。

这三个指标经常被混着说，口径其实完全不同。启动耗时要从进程创建算起，而不是从闪屏出现算起，否则数字会好看一大截；包体积要看安装包和首次下载量两个数，用户实际下载的是后者。

内存要区分峰值和常驻。峰值高不一定卡，常驻高才会被系统回收，也才会导致后台切回来重新加载。我的习惯是同时看常驻内存和后台存活时长，两个一起判断。

埋点上报也建议一起看。上报太频繁会拉高耗电，太低又拿不到数据，我一般把非关键事件的批量上报间隔定在 30 秒以上。

指标的采集口径建议写进文档。参照 GB/T 25000.51—2016 对性能效率和可靠性的划分，把每项指标的计算起点、终点、采样环境写清楚，团队内部的争论能少一半。

先做漏斗，再动手。把主路径拆成 5 到 8 步，每步记录进入人数和完成人数，算出流失率。优化只做流失率最高的两步，其他先不管。

第二步是做对照。同一个版本里只改一个变量，A 组和 B 组各放一半流量，两到三天就能看出差别。这一步不做，后面所有结论都只是猜测。

没有对照组的优化结论，八成是巧合。

第三步才是技术手段。真正好用的应用优化方法无非三类：启动阶段延迟初始化和拆分任务，包体积上删冗余资源，界面卡顿先把长列表改成分页。这些手段没有高下之分，先做哪一步取决于漏斗指向哪里。

先定漏斗再动手，比先定指标再找问题省一半时间。我们那次如果把这两天前置，半年的投入会分散到更值得改的地方。

顺便提一下，同一主题我在另一篇里拆得更细，应用商店那篇可以一并看。

监控常见的问题是装了不设阈值，数据堆在那里没人管。我建议只盯 3 个数：崩溃率、卡顿率、启动耗时的 95 分位值。前两个按周看，第三个按版本看。

阈值要写死，比如崩溃率连续 2 天超过 0.5% 就触发排查，启动耗时的 95 分位连续两个版本上涨就回看改动。写死的规则比"感觉不对再看"可靠得多。

应用优化这件事，方向比力度重要。方向对了，改一个表单字段可能比压 0.4 秒更有价值。

建议你先做一件事：把主路径的漏斗数据拉出来排一遍，看看流失最集中的是哪一步。如果这一步和性能无关，那么这半年本来可以省下来。

用户数据的采集也有边界。依照《中华人民共和国个人信息保护法》的规定，收集信息要遵循最小必要原则，你可以把埋点清单和用途说明一并留档，避免后续争议。

[1] 国家标准化管理委员会.信息安全技术数据安全能力成熟度模型:GB/T 37988—2019[S].北京:中国标准出版社,2019.

[2] 艾媒咨询.中国在线办公行业研究报告[R].广州:艾媒咨询,2023.

[3] 马蒂·卡根.启示录:打造用户喜爱的产品[M].七印部落,译.武汉:华中科技大学出版社,2011.