移动App性能测试不在于看单一数字的高低，而在于区分场景、抓住用户真正的瓶颈。

启动时间：

冷启动指进程从无到有。Android 侧一般从 Application 构造函数算到首个 Activity 首帧渲染完成；iOS 侧从进程创建算到首个 UIViewController.didAppear。

温启动指进程还活着，但 Activity 已被销毁，比如按返回键退出后再进入。Android 侧通常从 Activity.onCreate 算到 onResume；iOS 没有严格对应概念。

热启动指进程存活，从后台切回前台。Android 侧从 Activity.onRestart 算到 onResume；iOS 侧从 willEnterForeground 算到 didBecomeActive。

现代测试更值得关注两个用户感知指标：TTID，即首帧渲染耗时，用户“看到东西”的时间；TTFD，即应用达到可交互状态的时间，需要业务自定义完全就绪的判定点。

参考阈值以中端机型、冷启动为基准：冷启动到首屏有意义内容建议不超过 2.0 秒，目标 1.5 秒；若以冷启动总耗时计，Good 小于 3 秒，Acceptable 小于 5 秒，超过 5 秒为 Poor。热启动 Good 小于 500 毫秒，Acceptable 小于 1 秒。

测试必须用真机，至少覆盖高端和中低端两档设备。冷启动测试前要强制停止进程或重启设备，排除缓存干扰。Android 侧可用 Macrobenchmark 在真实设备上获取可复现的启动时间线。

如果启动超标，需要拆解阶段。Android 关注 attachBaseContext、onCreate、onResume 各段耗时；iOS 关注 exec、+load、didFinishLaunching、首帧渲染的逐段耗时。

帧率：

平均 FPS 很容易被误读。PerfDog 官方文档指出，FPS 为 50 可能意味着前 200 毫秒只渲染了 1 帧、后 800 毫秒渲染了 49 帧，平均数字好看，但用户感知是明显卡顿。反过来，稳定 30fps 且帧耗时均匀的画面，可能比波动剧烈的 40fps 更顺滑。

因此帧率测试重心应放在卡顿指标上。

Jank 的判定口径可以按 PerfDog：当前帧耗时大于前三帧平均耗时的 2 倍，且大于两倍电影帧时长，约 83 毫秒，记一次 Jank；若同时当前帧耗时大于 125 毫秒，记为 BigJank，即严重卡顿。

指标包括 Stutter，即卡顿时间占测试总时长的百分比；慢帧和冻结帧比例，Android Vitals 口径下慢帧大于 16 毫秒应小于 5%，冻结帧大于 700 毫秒应小于 0.1%；平均 FPS 参考线为 Good 大于等于 58，Needs Work 50 到 57，Poor 小于 50，高刷新率设备需相应调整。

测试场景不能只看静止界面，应覆盖列表快速滑动、页面转场动画、复杂 Feed 流加载、图片密集页面等高渲染压力场景。单次采集建议不少于 10 分钟，观察 Jank 的持续分布。

内存占用：

第一是场景峰值内存。在首页、列表页、相机或地图等重资源页面、多任务切换后返回等关键页面采集 PSS 物理内存峰值。一个常见粗筛参考是关键场景峰值建议不超过 200MB，但更合理的做法是以同机型、同系统、同版本的历史基线作为回归阈值。

第二是内存泄漏。判断依据不是“占用高”，而是在反复进入退出同一页面，或长时间后台驻留后，内存是否持续攀升且不回落。Android 侧可用 LeakCanary 在测试过程中实时捕获泄漏对象；iOS 侧用 Instruments 的 Allocations 和 Leaks 模板追踪。

第三是 OOM 率。OOM 是内存问题的终态，应作为线上或灰度监控指标持续跟踪。核心口径是 OOM 率等于 OOM 次数除以总启动次数。行业参考上，OOM 率中位数约 1.12 次每万次会话，容忍阈值约 10 次每万次会话。

前后台要区分。Android 采集时应区分 total_pss_foreground 与 total_pss_background、Java 堆与 Native 堆，否则前台峰值和后台驻留问题容易混在一起。

耗电测试：

App 耗电测试的难点在于系统总耗电中 App 的贡献很难精确剥离。更务实的路径是：用系统级工具找出 App 在什么时间、因为什么行为拉高了功耗，再针对性验证。

Android工具是Battery Historian。导入 bugreport 后，从两个层面分析。系统级视图观察电量曲线陡降的时间点，同时段是否有 CPU 运行、Wakelock 持锁、屏幕点亮叠加发生。App 级数据查看该应用的预估耗电排名、网络活动、Wakelock 次数、JobScheduler 或 SyncManager 触发频率。频繁同步、过高唤醒闹钟频率、持续 GPS 锁定，都是典型耗电反模式。

iOS用 Instruments的Energy Log模板追踪CPU、GPU、网络、定位的能耗影响，结合MetricKit 可在线上收集能耗诊断数据。

耗电问题往往不在“用着的时候”，而在后台。应专项测试后台定位、后台音频、后台数据同步、推送唤醒后的处理逻辑，观察是否存在不必要的长时 Wakelock 或高频网络轮询。

工具：

Android 启动测试可用 Macrobenchmark、adb shell am start -W；iOS 启动测试可用 Xcode Organizer、Instruments 的 Launch 模板；跨平台可用 PerfDog、Datadog RUM、火山引擎 APM。

帧率和卡顿方面，Android 可用 PerfDog、dumpsys gfxinfo；iOS 可用 Instruments 的 Core Animation 和 PerfDog；PerfDog 的 Jank 和 Stutter 口径跨平台一致，适合统一比较。

内存方面，Android 用 Android Studio Profiler、LeakCanary；iOS 用 Instruments 的 Allocations 和 Leaks；火山引擎内存模块、腾讯 RUM Pro 可作为补充。

耗电方面，Android 核心是 Battery Historian 和 batterystats；iOS 用 Instruments 的 Energy Log 和 MetricKit。

PerfDog价值在于跨Android和 iOS的帧率与卡顿统一，且统计的是屏幕真实 Display 刷新数据，而非 GPU 提交数据，因此在流畅度专项测试中仍然直接可用。如果预算受限，可考虑开源的 perfara、PowerMeter 等替代方案，但需要自行验证jank判定口径是否与团队既有基线一致。