第 16 章：方法论

一次性能调查要能复查、复现和交接，至少要说清四件事：现象怎样定义，现有证据能证明什么，App、系统和测试环境分别影响哪一段，以及修复后怎样验证。

前面的章节解释系统机制和工具用法。本章把问题定义、责任归因、指标、实验、线上监控、源码阅读和团队协作放进同一套判断流程；16.8另讨论AI编码评测，其任务、验证器和统计口径不能替代App性能实测。

图：先明确现象和指标，再结合现场与源码检验归因，以对照实验和发布监控验证修复。 设备策略按场景验证；AI编码评测另有任务与验证协议，不能替代App性能实测。

内容索引

• 16.1 Android 性能优化原则、实证与治理
• 16.2 如何区分系统问题和 App 问题
• 16.3 性能指标体系与线上监控
• 16.4 设备分级性能策略实战
• 16.5 性能测试最佳实践
• 16.6 竞品分析方法
• 16.7 AOSP 代码阅读
• 16.8 Google Android Bench：AI 编码能力评测方法论

阅读建议

• 第一次建立性能分析流程：按 16.1 → 16.2 → 16.3 阅读，先统一问题、证据与指标口径，再检验归因。
• 设计可比较的实验：阅读 16.6 和 16.5；前者偏竞品对照，后者偏回归测试。
• 处理线上问题并推动修复：先用 16.3 定义监控信号和指标，再用 16.1 的治理方法跟到发布验收。
• 从证据继续追源码或研究数据：阅读 16.7 和 16.1。评估 AI 修改 Android 代码的能力时，再阅读 16.8。
• 制定跨启动、渲染、内存和媒体的设备差异化策略：阅读 16.4，并回到对应机制章验证每项预算。

图：基础调查、实验策略和源码/编码评测各有阅读入口，再回到具体机制与验证对象。 这些是阅读分组而非互斥责任；16.8评估编码能力，不能用榜单推断平台或App性能。