内测群刚建起来，最先收到的往往不是功能报错，而是一句很含糊的反馈："这包有点卡。"没有机型、没有场景、没有复现步骤，开发者很难下手。启动慢与滑动卡顿属于体验类问题，排查的第一步是把模糊的"卡"拆成可测量的几件事。

先把"卡"拆成四类可测量的现象

同一句"卡"，背后可能是完全不同的原因。收到反馈时先归入下面四类。

• 冷启动慢：点击图标到首屏可交互之间的等待过长，从后台切回却很快。
• 列表滑动掉帧：滚动时画面一顿一顿，长列表与图片流最容易出现。
• 操作响应迟滞：点按钮要等一会儿才有反应，输入时键盘跟随不跟手。
• 后台耗电与发热：包能跑，但待机掉电快、机身发烫，测试用户会主动卸载。

分类的意义在于排查入口完全不同：启动慢看初始化，掉帧看渲染，迟滞看主线程，耗电看后台任务。

开发者侧的自查清单

包交出去之前，这几项可以自己先过一遍，成本很低。

1. 区分构建类型：确认发出的是发布构建而非调试构建，后者带着额外日志与检查代码，性能表现不代表真实情况。
2. 记录基线数据：在固定机型上记录冷启动耗时、首屏渲染耗时与长列表滚动帧率，作为后续版本的对照基线。
3. 配置保持一致：混淆、压缩、资源裁剪这些开关若与线上包不同，性能对比就没有意义。
4. 在低端机上实测一次：中端机顺畅不代表低端机顺畅，备一台低配机器专门做这项检查。
5. 固定版本号再发：给每个待测版本明确的版本号并在分发时标注，避免"我到底测的哪一版"。

关于版本标注与命名约定，可以参考 https://xiafenfa.com 上已有的分发教程。

分发与测试阶段的分工

性能问题的一大特点是版本相关：同一个用户，装 A 版很顺，装 B 版就卡。分发环节要能支撑版本对照，而不是把包一发了事。

• 分发侧：为每个待测版本保留独立入口并标注版本号，支持随时启停，方便测试用户在两版之间切换对比。
• 测试侧：反馈时至少带上四项——机型与系统版本、版本号、复现路径、录屏或出现时间点。
• 组织侧：把性能单列为一个反馈分类，不要和功能缺陷混在一个列表里，否则容易被功能问题淹没。

反馈模板：让测试用户少说废话

把这张表随安装指引发给测试用户，回收到的反馈质量会明显不同。

建议给团队定一条硬性约定：任何"卡"的反馈都必须带机型与版本号，缺任一项就不进排查队列。规则一开始显得麻烦，但能把"无法复现"的比例压下来。

常见问题

性能更像每轮内测都要重新确认的基础项。把分类、基线、版本对照固定下来，卡顿反馈就会从扯皮变成可执行的待办。