第1章 性能评估核心指标定义
在开始优化 Material 3 组件之前，必须建立一套可量化、可复现的评估体系。本章定义六个核心指标——FPS、帧耗时、布局时间、重绘面积、内存占用、GC 频率，并讲解它们的物理意义、测量原理及在组件性能评估中的典型作用。只有理解了这些指标的底层机制，后续章节的优化手段才有据可依。
1.1 指标对照表
| 指标 | 定义 | 测量方式 | 典型影响 |
|---|---|---|---|
| FPS（帧率） | 每秒渲染的帧数，通常目标 ≥ 60fps，高刷屏目标 ≥ 90/120fps | `adb shell dumpsys gfxinfo` 或 Profiler | 直接反映 UI 流畅度，低于目标值会导致视觉卡顿 |
| 帧耗时 | 每一帧从绘制到显示所需毫秒数（含 vsync 等待） | 同上，结合 `FrameTimeline` 分段数据 | 单帧超过 16.67ms（60fps）产生掉帧 |
| 布局时间 | 组件树 measure + layout 阶段消耗的 CPU 时间 | `LayoutInspector` 或 Systrace 标记 | 非线性布局、嵌套 ConstraintLayout 或多次重排会大幅增加 |
| 重绘面积 | 每帧中实际需要重新绘制的像素面积占比 | `adb shell dumpsys gfxinfo --reduced` 查看 `Fetch` / `Issue` | 大面积无效重绘（如背景层叠）导致 GPU 负载陡增 |
| 内存占用 | 组件及其关联对象在 Java heap / native heap 中的字节数 | `adb shell dumpsys meminfo` 或 MAT/LeakCanary | 过高内存可能触发低内存杀进程（LMK） |
| GC 频率 | 每单位时间内垃圾回收触发次数，常用 `Logcat` 中 `GC_ALLOC` / `GC_CONCURRENT` 统计 | `adb logcat -s "dalvikvm"` 或 Studio Profiler GC 事件 | 频繁 GC 导致“世界暂停”，引起卡顿与帧延后 |
1.2 评估流程步骤
性能评估应遵循标准闭环，确保不同场景下的数据可比性：
- 定场景：明确测试的组件、交互（点击、滑动、动画）及环境（API 版本、屏幕密度）
- 录数据：使用统一工具（Profiler / systrace / Perfetto）采集至少 30 秒运行数据
- 提指标：从原始数据中提取上表六个核心指标的数值及分布（如 P95 帧耗时）
- 定基线：对照无组件干扰的基准页面（如空白 Activity），明确组件引起的额外消耗
- 析根因：关联布局时间→重绘面积→内存→GC 链，定位瓶颈层（CPU / GPU / 内存）
- 改&验：实施优化后重复 1~5 步，对比优化前后的六维雷达图
实操命令示例：获取某 Activity 的前 128 帧帧率与掉帧数
adb shell dumpsys gfxinfo com.example.material3app --framestats | grep "Frames:" -A 10输出中 MissedVsync 列数值即掉帧次数，FrameTime 列单位为毫秒。
1.3 指标关联图
下面 SVG 展示了六个核心指标与评估流程的关系——指标既是流程的输入（测量目标），也是输出（优化效果的判断依据）。
1.4 常见陷阱与稳定性提示
误区一：只关注 FPS 而忽略帧耗时分布。60fps 平均下可能存在大量 30ms 的“小卡顿”，必须同时查看 P95 / P99 帧耗时。
误区二：把 GC 频率当作独立指标——频繁 GC 通常由内存占用中的“滞留对象”引起，应先检查内存泄漏而非直接调 GC 策略。
稳定性红线：性能评估必须在同一设备、同一系统版本、相同屏幕刷新率下进行。不同设备的 GPU 驱动差异会导致重绘面积数据不可比。切勿在开发者选项中强制开启“GPU 过度绘制”作为唯一标准，它只显示粗略色阶，不能量化像素面积。