3. Android系统架构与性能影响
Android 的性能问题很少是“单点故障”，它更像一条纵向堆叠的链路：应用代码运行在应用框架之上，框架依赖系统服务，系统服务通过 HAL 访问内核驱动，最终落到具体硬件。任何一层出现阻塞、排队或资源争用，都会以卡顿、掉帧、启动慢、功耗高的形式暴露在用户面前。理解这条层级链路，是建立性能基线与量产验收标准的前提。
核心判断原则：上层现象，下层根因。看到的是掉帧，根因可能在 HAL 线程调度；看到的是启动慢，根因可能在系统服务初始化顺序或 IO 竞争。
一、五层架构与性能职责
从下往上，Android 可拆成硬件、内核、HAL、系统服务、应用框架五层。每一层都有明确的性能职责和典型瓶颈。
- 硬件层：CPU 大小核调度、GPU 频率、内存带宽、UFS 读写、DDR 通道、温控策略。瓶颈常表现为降频、带宽饱和、存储随机读放大。
- 内核层：进程调度（CFS/EEVDF）、内存管理（LMK、页回收）、IO 调度（blk-mq）、电源管理（cpuidle、DVFS）、Binder 驱动。瓶颈常表现为调度延迟、直接回收、IO 等待。
- HAL 层：Camera HAL、Audio HAL、Display HAL、Sensor HAL、Graphics HAL。瓶颈常表现为 HAL 线程阻塞、缓冲区不足、同步等待。
- 系统服务层：AMS、WMS、PMS、SurfaceFlinger、InputFlinger、Binder 线程池。瓶颈常表现为锁竞争、Binder 事务排队、服务初始化串行。
- 应用框架层：Activity 生命周期、View 绘制、Choreographer、RecyclerView、协程调度。瓶颈常表现为主线程耗时、过度绘制、布局层级过深。
二、层级影响关系图
下图展示五层之间的调用与影响方向，以及每层最典型的性能瓶颈点。箭头方向表示“上层依赖下层、下层反压上层”。
三、常见瓶颈与定位方法
不同层级的瓶颈，需要用不同的工具和指标来定位。下表给出量产验收中最常见的瓶颈清单。
| 层级 | 典型瓶颈 | 关键指标 | 定位工具 |
|---|---|---|---|
| 应用框架 | 主线程耗时、过度绘制、布局嵌套过深 | 帧耗时 >16.6ms、GPU 过度绘制 >2x | Perfetto、Layout Inspector、GPU 渲染模式 |
| 系统服务 | Binder 事务排队、AMS 锁竞争、SurfaceFlinger 合成慢 | Binder 等待 >5ms、合成耗时 >8ms | Perfetto、dumpsys SurfaceFlinger、Binder 统计 |
| HAL | Camera HAL 线程阻塞、Audio 缓冲欠载、Display 帧丢失 | HAL 回调延迟 >10ms、underrun 计数 | systrace、HAL 日志、dumpsys media.camera |
| 内核 | 调度延迟、直接内存回收、IO 等待、频率抖动 | sched latency >5ms、DMA 回收次数、iowait >20% | ftrace、perfetto、/proc/schedstat、vmstat |
| 硬件 | CPU 降频、DDR 带宽饱和、UFS 随机读放大 | 频率低于阈值、带宽利用率 >85%、IOPS 下降 | perfetto 频率轨、devfreq、存储 benchmark |
四、案例：启动慢的层级排查
某项目冷启动耗时 2.8s，超出基线 1.5s。按层级逐层排查：
- 应用框架层：Perfetto 显示 Application.onCreate 耗时 420ms，其中 300ms 花在初始化第三方 SDK。这是上层直接原因。
- 系统服务层：AMS 启动 Activity 时 Binder 事务等待 180ms，PMS 扫描包耗时偏高。
- HAL 层：Display HAL 首帧提交延迟 90ms，Camera HAL 初始化被无关服务抢占。
- 内核层：启动阶段 IO 调度队列深度过大，直接回收触发 12 次，每次约 15ms。
- 硬件层：UFS 随机读 IOPS 在启动阶段下降 40%，DDR 带宽利用率达到 88%。
排查顺序建议：先用 Perfetto 看全局时间线，再按“应用 → 系统服务 → HAL → 内核 → 硬件”逐层下钻。不要一上来就怀疑硬件，多数问题在系统服务和 HAL 层就能定位。
五、误区与复盘
- 误区一：只看应用层。应用层优化到极致，若 HAL 或内核存在阻塞，帧率依然上不去。
- 误区二：把 Binder 当免费通道。跨进程调用有序列化、线程切换和排队成本，高频小事务会显著放大延迟。
- 误区三：忽略温控与降频。量产验收必须包含持续负载下的频率与温度曲线，否则实验室数据不可信。
- 误区四：用平均值掩盖抖动。性能基线应关注 P95/P99 分位值，而非平均值，卡顿往往发生在长尾。
# 常用层级排查命令示例
adb shell dumpsys SurfaceFlinger --latency
adb shell dumpsys activity processes | grep -i "slow"
adb shell cat /proc/schedstat
adb shell vmstat 1 10
adb shell dumpsys media.camera | grep -i "latency"
adb shell cat /sys/class/devfreq/*/cur_freq
量产验收基线必须覆盖五层：应用帧率、系统服务响应、HAL 回调延迟、内核调度与 IO、硬件频率与带宽。任何一层缺失，基线都不完整。
总结来说，Android 性能是纵向链路问题。建立基线时，要按层定义指标、按层采集数据、按层设定阈值；出现问题时，按层下钻定位。只有把应用框架、系统服务、HAL、内核、硬件五层的性能语言统一起来，量产验收才有可执行的标准。