Framework / AOSP 定制学习路线

定位：从"会用 Android API"到"能读改 Framework 源码、定制系统能力"的手机厂商核心稀缺方向。
适用对象：3 年以上 Android 开发，希望进入手机厂商/系统厂商做 Framework 层或 ROM 定制开发。
抗替代性逻辑：AOSP 源码体量巨大（千万行级）、公开语料远少于应用层 API 用法、且改动必须在真机上验证不能靠模拟，AI 难以独立完成"改 Framework 代码 → 编译 ROM → 真机验证影响面"的完整闭环。

一、能力地图

能力域	内容
AOSP 编译体系	Soong/Make 构建、镜像刷写、源码结构
Framework 核心服务	AMS、WMS、PMS、PowerManagerService 等系统服务
Binder IPC	跨进程通信机制，Framework 的血管系统
HAL 与厂商定制	HIDL/AIDL HAL、厂商 Overlay、定制化能力
系统定制能力	权限定制、多屏协同、厂商专属特性开发

二、学习路线总览（建议 12～18 个月）

阶段 0：Linux/C++ 基础与 AOSP 编译体系   → 2 月
阶段 1：Framework 启动与核心服务         → 3 月
阶段 2：Binder IPC 深入                  → 2 月
阶段 3：Window/View 系统与 WMS           → 2 月
阶段 4：HAL 与厂商定制开发               → 3 月
阶段 5：系统级调试与问题定位             → 2 月
阶段 6：项目化与求职                     → 持续

三、阶段 0：Linux/C++ 基础与 AOSP 编译体系（2 月）

3.1 必须补齐的基础

主题	要求
C/C++	能读懂 Framework native 层代码（智能指针、STL 基础）
Linux 基础	进程/线程、文件系统、权限模型
Makefile/Soong	AOSP 的 `Android.bp`/`Android.mk` 构建语法

3.2 获取与编译 AOSP

# 初始化 repo
mkdir aosp && cd aosp
repo init -u https://android.googlesource.com/platform/manifest -b android-14.0.0_r1
repo sync -j8

# 编译（选择一个模拟器目标先跑通）
source build/envsetup.sh
lunch aosp_arm64-eng
m -j$(nproc)

# 运行模拟器验证
emulator

建议：先用模拟器目标跑通完整编译流程，再考虑真机（如 Pixel 系列有官方支持的编译镜像）刷机验证。

3.3 源码目录速查

frameworks/base/     — Framework 核心（AMS/WMS/PMS 等）
frameworks/native/   — Native 层服务（SurfaceFlinger 等）
system/core/         — init、logcat、Binder 相关基础
hardware/interfaces/ — HAL 接口定义（HIDL/AIDL）
packages/apps/       — 系统内置应用
device/              — 设备相关配置（厂商定制常改动区）
vendor/              — 厂商私有代码（如果有权限访问）

3.4 阶段产出

[ ] 成功编译一次 AOSP 并在模拟器/真机跑起来
[ ] 熟悉 repo/git 在 AOSP 多仓库场景下的使用
[ ] 写一份《AOSP 源码目录导航笔记》

四、阶段 1：Framework 启动与核心服务（3 月）

4.1 系统启动链路（背诵级）

Bootloader → Kernel → init 进程
  → 启动 Zygote（预加载虚拟机与常用类）
  → Zygote fork 出 SystemServer 进程
  → SystemServer 依次启动核心服务：
      ActivityManagerService (AMS)
      WindowManagerService (WMS)
      PackageManagerService (PMS)
      PowerManagerService
      ... 上百个系统服务
  → 启动 Launcher，用户可见桌面

4.2 核心服务职责

服务	职责
AMS	管理四大组件生命周期、任务栈、进程调度
WMS	窗口管理、Surface 分配、多窗口/分屏
PMS	应用安装、权限管理、包信息查询
PowerManagerService	电源状态、唤醒锁管理

4.3 跟读方法

1. 从一个具体行为出发（如 startActivity 的完整调用链）
2. 用 grep/cscope 在 frameworks/base 中定位关键类
3. 画调用链图，标注跨进程 Binder 调用发生的位置
4. 结合官方文档 Documentation/ 目录理解设计意图

4.4 阶段产出

[ ] 完整跟读一次 startActivity 从应用进程到 AMS 再到目标进程的链路
[ ] 画出 SystemServer 启动服务的时序图
[ ] 写一份《核心系统服务职责笔记》

五、阶段 2：Binder IPC 深入（2 月）

5.1 为什么 Binder 是 Framework 的"血管系统"

几乎所有跨进程通信（应用↔系统服务、系统服务之间）都走 Binder
理解 Binder 是理解 Framework 的必经之路

5.2 核心概念

Client → Proxy（本地代理）→ Binder 驱动（内核）→ Stub（远端骨架）→ Service 实现
  ↓
一次 Binder 调用 = 一次跨进程 + 一次内核态切换 + 数据拷贝（一次拷贝优化）

5.3 必学内容

AIDL 生成代码的原理（Proxy/Stub 模式）
Binder 线程池与并发模型
oneway 异步调用与同步调用的差异
Binder 事务缓冲区限制（大数据传输的坑）

5.4 阶段产出

[ ] 手写一个简单的 AIDL 跨进程调用 Demo 并画出调用链
[ ] 能解释 Binder 驱动在内核中做了什么（概念级）
[ ] 理解为什么 Binder 事务有大小限制，如何应对大数据传输场景

六、阶段 3：Window/View 系统与 WMS（2 月）

6.1 核心链路

Activity.setContentView
  → DecorView 创建
  → WindowManager.addView
  → WMS 分配 Surface
  → ViewRootImpl 驱动 measure/layout/draw
  → SurfaceFlinger 合成显示

6.2 定制方向（手机厂商常见需求）

多屏协同、分屏、悬浮窗定制
状态栏/导航栏定制
手势导航与全面屏适配

6.3 阶段产出

[ ] 完整画出从 setContentView 到屏幕显示的跨进程链路
[ ] 完成一次简单的系统 UI 定制实验（如自定义状态栏样式，在 AOSP 源码上改动并编译验证）

七、阶段 4：HAL 与厂商定制开发（3 月）

7.1 HAL 演进

传统 HAL（.so 直接加载）
  → HIDL（Android 8+，接口与实现分离）
  → AIDL for HAL（Android 11+，统一 IPC 机制）

7.2 典型定制场景

场景	涉及层面
摄像头效果定制	Camera HAL + Framework Camera2 API
电源管理策略定制	PowerManagerService + Kernel cpufreq/cpuidle
传感器融合算法	Sensor HAL
指纹/人脸识别	Biometric HAL

7.3 阶段产出

[ ] 阅读至少一个 HAL 接口定义（.hal 或 .aidl）并理解其实现结构
[ ] 完成一次简单的厂商 Overlay 定制实验（资源覆盖或行为定制）

八、阶段 5：系统级调试与问题定位（2 月）

8.1 调试工具

工具	用途
`adb bugreport`	全量系统状态快照
`dumpsys`	各系统服务状态查询
Perfetto/Systrace	系统级性能追踪
GDB + Native 符号	Native 层崩溃分析
Kernel `dmesg`	内核日志（涉及驱动问题时）

8.2 常见问题类型

- 系统服务 ANR（如 SystemServer 主线程阻塞）
- Native crash（tombstone 分析）
- Binder 调用超时/死锁
- 厂商定制引入的兼容性回归

8.3 阶段产出

[ ] 完成一次 bugreport 分析，定位一个模拟问题的根因
[ ] 分析过至少 1 次 Native tombstone 崩溃日志

九、阶段 6：项目化与求职

9.1 作品集建议

一次 AOSP 源码改动 + 编译 + 真机验证的完整记录（如自定义系统服务或定制 UI）
一份系统启动链路/Binder 机制的技术笔记或分享
一次真实或模拟的系统级问题排查报告

9.2 简历表述模板

「基于 AOSP 源码定制 XX 系统能力，涉及 Framework 层 XX Service 改动与
HAL 层适配，完成从源码修改到真机验证的完整流程，解决 XX 兼容性问题。」

9.3 目标公司

手机厂商（传音/OPPO/vivo/荣耀/小米）Framework 团队是本方向核心需求方，其次是车载系统厂商（AAOS 定制）。

十、能力自检清单（20 项）

打勾 ≥ 14 项，可视为具备 Framework/AOSP 定制中高级水平：

编译与源码

[ ] 成功编译过完整 AOSP 并跑通
[ ] 熟悉 AOSP 源码目录结构
[ ] 能用 repo/git 管理多仓库源码

Framework 核心

[ ] 完整跟读过一次跨进程调用链路（如 startActivity）
[ ] 理解 AMS/WMS/PMS 的核心职责
[ ] 能画出 SystemServer 启动时序图

Binder

[ ] 手写过 AIDL 跨进程 Demo
[ ] 理解 Binder 线程池与事务限制

Window/View

[ ] 画出过完整绘制到显示的跨进程链路
[ ] 完成过至少 1 次系统 UI 定制实验

HAL

[ ] 读过至少 1 个 HAL 接口定义
[ ] 完成过厂商 Overlay 或行为定制实验

调试

[ ] 分析过 bugreport
[ ] 分析过 Native tombstone 崩溃

产出

[ ] 有完整的 AOSP 改动+验证记录
[ ] 有系统级问题排查报告
[ ] 做过相关技术分享

软实力

[ ] 能讲清一次真实定制开发案例的完整流程
[ ] 理解厂商定制与 AOSP 原生行为的兼容性风险

十一、常见误区

误区	正确认知
只看 API 文档不读源码	Framework 定制必须读源码，官方文档粒度不够
只在模拟器验证	真机（尤其目标厂商机型）验证是必经环节
忽视编译体系学习	不懂 Soong/Make，改了代码也编译不出来
认为 HAL 只是"驱动的事"	HAL 是 Framework 与硬件之间的契约，定制常从这里入手

十二、最短路径

1. 补齐 Linux/C++ 基础，跑通 AOSP 编译（2个月）
2. 跟读一次完整跨进程调用链路（3个月）
3. 手写 AIDL Demo，理解 Binder（2个月）
4. 完成一次系统 UI 或 HAL 定制实验（3个月）
5. 整理一份完整案例作品，投递手机厂商 Framework 岗

一句话总结：

Framework/AOSP 定制的护城河是"千万行级源码 + 必须真机验证"的双重壁垒，公开语料远少于应用层，是手机厂商的核心稀缺岗位。

十三、关联文档

../Linux内核学习路线.md — 内核基础与本方向阶段 0 衔接
../Android高级架构师学习路线.md — Framework 深度章节的补充
../Android移动开发方向抗替代性与薪酬分析.md — 替代率与薪酬定位

05-Framework / AOSP 定制学习路线