“APP有点卡”是一句模糊但真实的抱怨。开发可能看平均接口只有300毫秒，用户却在低端机、弱网和长列表里不断等待。只测一台新手机，很难复现。
性能诊断要把技术指标和用户感受对齐：用户在哪个动作后等待、是否有反馈、能否继续、失败后能否恢复。
01 先按用户场景描述问题
记录设备、系统、网络、账户数据量、页面和具体操作，例如“安卓中端机，订单超过1000条时首次进入列表需要6秒”。
比“首页慢”更具体的问题，才能对应日志、追踪和复现。
常见卡顿现象与排查方向
| 用户现象 | 可能原因 | 体验侧先做什么 |
|---|---|---|
| 冷启动很久 | 初始化过多、资源大、同步任务 | 尽快显示可用首屏，延后非必要初始化 |
| 点击没反应 | 主线程阻塞、请求未反馈 | 立即显示按压/加载，拆分长任务 |
| 列表滑动掉帧 | 复杂布局、图片、频繁更新 | 虚拟化、缓存、降低单项复杂度 |
| 图片慢或闪烁 | 原图过大、无缓存、占位缺失 | 合适尺寸、占位、渐进加载 |
| 网络切换后失败 | 重试和离线状态不足 | 明确错误、保留任务、支持重试 |
| 使用一段时间变慢 | 内存泄漏、缓存失控、数据累积 | 监控长期会话和大账户 |
02 启动时只做“必须现在做”的事
配置、埋点、广告、推荐、更新检查和大量数据预取不应全部阻塞首屏。先让用户进入可操作状态，再在后台完成低优先任务。
启动画面不应被当作等待遮罩。它只能平滑过渡，不能掩盖无节制初始化。
03 交互反馈要早于任务完成
网络请求可能需要时间，但按钮按下、列表刷新和提交都应立即反馈。用户知道系统正在工作，等待感会降低。
反馈不能虚假。进度未知时用不确定加载，能计算时才显示百分比；长任务允许离开并在完成后通知。
04 图片和列表按真实数据量设计
缩略图使用对应尺寸和格式，提前预留空间，避免滚动中不断重排。长列表需要分页、虚拟化和合理缓存。
设计稿中的十条理想数据不能代表用户账户里的十万条记录。
05 网络失败要能恢复
区分无网、超时、服务器错误、权限和数据为空，给出不同操作。提交类任务使用幂等和本地保存，避免用户重复付款或丢失输入。
弱网测试应覆盖上传、下载、切换网络和后台恢复。
06 建立设备与版本监控
按设备档位、系统版本、地区、网络和页面观察启动、帧率、崩溃、ANR、接口和错误。平均值会掩盖最差用户。
每次发布比较关键指标和用户反馈，性能回退要像功能Bug一样阻止上线。
常见问题
APP启动多少秒算慢？
没有单一阈值，应结合平台、任务和用户预期。原则是尽快呈现可用内容，并持续监控不同设备分布。
骨架屏越多越好吗？
不是。稳定可预测的列表适合骨架；简单内容用加载指示即可。骨架形状与真实内容差距过大会造成跳动。
性能问题主要是开发责任吗？
不是。产品范围、设计动效、图片规范、数据结构和第三方SDK都会影响，需要跨团队解决。
低端机还需要专门优化吗？
如果目标用户使用比例高，必须覆盖。应按真实设备分布确定测试矩阵，而不是只用旗舰机。
如何判断是接口慢还是界面慢？
结合网络追踪、主线程、渲染和交互时间分析。用户感知从点击开始，不应只看服务端耗时。
链接复制成功
