Framework / AOSP 定制学习路线

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

一、能力地图

二、学习路线总览（建议 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 必须补齐的基础

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 核心服务职责

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 典型定制场景

7.3 阶段产出

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

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

8.1 调试工具

8.2 常见问题类型

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

8.3 阶段产出

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

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

9.1 作品集建议

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

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 原生行为的兼容性风险

十一、常见误区

十二、最短路径

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 — 替代率与薪酬定位

端侧 AI 部署与调优学习路线

定位：让模型在真实手机上"又快又省又稳"地跑起来的系统工程方向，不是"转行做算法"。
适用对象：Android 开发背景，希望将性能优化、Native、Framework 经验延伸到模型端侧部署领域。
抗替代性逻辑：端侧 AI 工程的核心矛盾是"云端模型很强，但手机内存/算力/功耗有限"，需要既懂模型又懂移动端系统资源约束的人做取舍，这正是纯算法背景缺的一课，AI 无法替你在真机上验证功耗与延迟。
完整详细版：本文是精简导航版，完整分阶段展开（含更多代码示例、llama.cpp 端侧大模型部署细节）见 ../端侧AI与AI系统工程学习路线.md，两文档内容互补，建议配合使用。

一、能力迁移对照（为什么 Android 背景是优势）

二、能力地图

1. 机器学习与模型基础 — 看懂模型结构，不要求会训练
2. 端侧推理框架 — TFLite、ONNX Runtime、MediaPipe、llama.cpp
3. 模型优化技术 — 量化、剪枝、蒸馏
4. 硬件加速与异构计算 — CPU/GPU/NPU 调度
5. 系统工程与性能调优 — 延迟、内存、功耗量化分析

三、学习路线总览（建议 9～14 个月）

阶段 0：机器学习与模型基础补齐          → 1～1.5 月
阶段 1：端侧推理框架实战                → 2 月
阶段 2：模型压缩与优化                  → 1.5～2 月
阶段 3：硬件加速与异构调度              → 1.5～2 月
阶段 4：端侧大模型部署（进阶加分项）    → 1.5～2 月
阶段 5：系统级性能调优                  → 1～1.5 月
阶段 6：项目化与求职                    → 持续

四、阶段 0：机器学习与模型基础（1～1.5 月）

4.1 必学内容

4.2 阶段产出

• [ ] 能解释量化/剪枝/蒸馏各解决什么问题
• [ ] 能用 Netron 读懂一个 .tflite 模型的算子列表
• [ ] 写一页《模型部署链路笔记》

五、阶段 1：端侧推理框架实战（2 月）

5.1 框架选型

5.2 最小集成示例

val model = FileUtil.loadMappedFile(context, "mobilenet_v2.tflite")
val interpreter = Interpreter(model, Interpreter.Options().apply { numThreads = 4 })
interpreter.run(inputBuffer.buffer, outputBuffer.buffer)

5.3 阶段产出

• [ ] 一个可运行的 Android Demo（图像/文本分类），真机验证
• [ ] 《TFLite vs ONNX Runtime Mobile 对比笔记》

六、阶段 2：模型压缩与优化（1.5～2 月）

决策框架："精度损失是否在业务可接受范围" + "延迟/体积收益是否值得" + "能否部分层量化折中"。

阶段产出

• [ ] 对同一模型做动态量化/全整数量化/FP32 三版本对比测试并写报告

七、阶段 3：硬件加速与异构调度（1.5～2 月）

CPU（兜底）→ GPU Delegate（并行计算强）→ NNAPI（统一异构接口）→ 厂商 NPU SDK

必须做：在 2～3 台不同芯片真机上跑同一模型，对比 CPU/GPU/NNAPI 延迟差异，产出对比报告——这是简历上最有说服力的数据。

阶段产出

• [ ] 《多设备加速对比报告》
• [ ] 了解至少一个厂商 NPU SDK 基本接入流程

八、阶段 4：端侧大模型部署（进阶加分项，1.5～2 月）

方案选型：llama.cpp（社区最活跃）、MLC-LLM（多后端）、MediaPipe LLM Inference API
路径：PC 跑通量化小模型 → NDK 交叉编译 → JNI 封装 → 手机端聊天 Demo

详细代码与编译步骤见 ../端侧AI与AI系统工程学习路线.md 第八节。

阶段产出

• [ ] 一个能在真机跑本地大模型对话的 Demo App
• [ ] 不同量化等级的速度/内存/质量对比记录

九、阶段 5：系统级性能调优（1～1.5 月）

现象（卡顿/发热）→ 工具定位（Perfetto/TFLite Benchmark）→ 归因 → 优化 → 数据验证

阶段产出

• [ ] 用 Perfetto 分析一次完整推理耗时分布
• [ ] 一份《机型兼容性测试矩阵》

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

简历表述模板

「在 Android 平台完成 XX 模型端侧部署，通过 INT8 量化将模型体积压缩 70%、
推理延迟从 XXms 降至 XXms，并在 3 款不同芯片机型上验证 NNAPI/GPU Delegate
加速效果差异，输出兼容性测试矩阵。」

目标岗位

内部转岗（大厂端侧智能小组）> 社招端侧 AI 工程师（手机厂商/大模型厂商）> AI Infra 延伸岗位

十一、能力自检清单（精简版 12 项）

• [ ] 能解释量化/剪枝/蒸馏区别
• [ ] 独立完成 TFLite Android 集成
• [ ] 完成量化对比实验并有数据报告
• [ ] 启用过 GPU Delegate / NNAPI 并测量效果
• [ ] 在 2 款以上真机做过加速对比
• [ ] 完成端侧大模型 Demo（可选）
• [ ] 用 Perfetto 分析过推理耗时
• [ ] 完成一次性能优化闭环案例
• [ ] 建立机型兼容性矩阵
• [ ] 有可演示的端侧 AI Demo App
• [ ] 简历能用数据讲清一次优化案例
• [ ] 能对比端侧与云端推理的取舍逻辑

完整 24 项自检清单见 ../端侧AI与AI系统工程学习路线.md 第十二节。

十二、最短路径

1. 跑通官方 TFLite 图像分类 Demo（2周）
2. 量化对比实验，产出数据报告（4周）
3. 2~3台真机测 CPU/GPU/NNAPI 对比（4周）
4. 端侧大模型 Demo 加分（6周，可选）
5. Perfetto 完成一次性能优化案例（3周）

一句话总结：

端侧 AI 工程不是"重新学 AI"，而是把 Android 系统资源管理能力用在"让模型在真实手机上又快又省又稳"这件事上。

十三、关联文档

• ../端侧AI与AI系统工程学习路线.md — 完整详细版，含更多代码与深度内容
• ../移动开发转型规划-不易被AI替代方向.md — 本方向在整体转型策略中的定位
• ../Android移动开发方向抗替代性与薪酬分析.md — 替代率与薪酬定位
• 01-性能优化专项学习路线.md — 性能调优方法论可交叉参考

音视频与图形渲染学习路线

定位：Android 平台音视频处理与图形渲染专家方向，覆盖相机、编解码、直播/短视频、图形渲染管线。
适用对象：有 Android 基础，希望往音视频/图形这类专业性强、人才稀缺的技术方向深耕。
抗替代性逻辑：音视频/图形是专业知识壁垒 + 真机适配成本双高的领域——涉及大量数学（矩阵变换、色彩空间）、硬件差异（不同芯片编解码器行为不同）、且必须真机调试验证，公开语料远少于普通业务开发，AI 难以独立完成跨机型的调试与调优闭环。

一、能力地图

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

阶段 0：图形与信号处理基础              → 1.5 月
阶段 1：OpenGL ES 图形渲染              → 2.5 月
阶段 2：Camera2/CameraX 与图像处理      → 2 月
阶段 3：MediaCodec 编解码               → 2.5 月
阶段 4：直播/短视频全链路实战           → 3 月
阶段 5：Vulkan 与新一代图形 API（选修） → 2 月
阶段 6：性能优化与兼容性治理            → 持续

三、阶段 0：图形与信号处理基础（1.5 月）

3.1 必学数学基础

3.2 音视频基本概念

视频 = 一系列图像帧 + 时间信息
帮助理解的关键词：
  分辨率、帧率(FPS)、码率(Bitrate)、色彩空间(YUV/RGB)
  关键帧(I帧)/预测帧(P帧/B帧)、GOP
  封装格式(MP4/FLV) vs 编码格式(H.264/H.265/VP9)

3.3 阶段产出

• [ ] 能解释 YUV 与 RGB 的区别及转换场景
• [ ] 能解释码率、分辨率、帧率对视频质量和文件大小的影响关系
• [ ] 手写一次简单的矩阵变换（平移+旋转组合）验证理解

四、阶段 1：OpenGL ES 图形渲染（2.5 月）

4.1 图形渲染管线基础

顶点数据 → 顶点着色器(Vertex Shader) → 图元装配 → 光栅化
  → 片元着色器(Fragment Shader) → 逐片元测试与混合 → 帧缓冲输出

4.2 Android 集成方式

class MyGLSurfaceView(context: Context) : GLSurfaceView(context) {
    init {
        setEGLContextClientVersion(2)
        setRenderer(MyRenderer())
    }
}

class MyRenderer : GLSurfaceView.Renderer {
    override fun onSurfaceCreated(gl: GL10?, config: EGLConfig?) {
        // 编译链接 Shader
    }
    override fun onDrawFrame(gl: GL10?) {
        // 每帧绘制逻辑
    }
}

4.3 必须掌握的 Shader 基础

// 顶点着色器示例
attribute vec4 position;
attribute vec2 texCoord;
varying vec2 vTexCoord;
void main() {
    gl_Position = position;
    vTexCoord = texCoord;
}

// 片元着色器示例（简单滤镜：灰度化）
precision mediump float;
varying vec2 vTexCoord;
uniform sampler2D texture;
void main() {
    vec4 color = texture2D(texture, vTexCoord);
    float gray = dot(color.rgb, vec3(0.299, 0.587, 0.114));
    gl_FragColor = vec4(vec3(gray), color.a);
}

4.4 实战练习

1. 用 OpenGL ES 渲染一张纹理贴图到屏幕
2. 实现一个简单滤镜（灰度、反色、亮度调节）
3. 实现 Camera 预览画面通过 OpenGL 渲染（而非直接用 SurfaceView）
4. 用 FBO（帧缓冲对象）实现多重滤镜叠加

4.5 阶段产出

• [ ] 独立实现一个自定义相机滤镜 Demo（至少 3 种滤镜效果）
• [ ] 理解并能画出完整渲染管线图
• [ ] 能解释 EGL、GLSurfaceView、Renderer 三者的关系

五、阶段 2：Camera2/CameraX 与图像处理（2 月）

5.1 Camera API 选型

5.2 核心概念

CameraDevice → CaptureRequest → CaptureSession → ImageReader/Surface 输出
  ↓
关键参数：曝光、对焦模式、帮率、分辨率、图像格式(YUV_420_888)

5.3 图像处理管线设计

Camera 采集(YUV) → 格式转换(RGB/OpenGL纹理)
  → 滤镜/美颜处理(GPU Shader)
  → 渲染到 SurfaceView / 编码输出

5.4 阶段产出

• [ ] 用 CameraX 实现一个带实时滤镜的相机 Demo
• [ ] 理解 ImageReader 与 YUV_420_888 格式的处理方式
• [ ] 完成一次美颜/滤镜算法的简单接入（如磨皮/美白参数调节）

六、阶段 3：MediaCodec 编解码（2.5 月）

6.1 硬编硬解基础

MediaCodec：Android 官方硬件编解码 API
  编码：原始帧(YUV/RGB) → 压缩数据(H.264/H.265)
  解码：压缩数据 → 原始帧，用于渲染显示

6.2 典型编码流程

val codec = MediaCodec.createEncoderByType(MediaFormat.MIMETYPE_VIDEO_AVC)
val format = MediaFormat.createVideoFormat(MediaFormat.MIMETYPE_VIDEO_AVC, width, height).apply {
    setInteger(MediaFormat.KEY_COLOR_FORMAT, MediaCodecInfo.CodecCapabilities.COLOR_FormatSurface)
    setInteger(MediaFormat.KEY_BIT_RATE, bitRate)
    setInteger(MediaFormat.KEY_FRAME_RATE, frameRate)
    setInteger(MediaFormat.KEY_I_FRAME_INTERVAL, 2)
}
codec.configure(format, null, null, MediaCodec.CONFIGURE_FLAG_ENCODE)
val inputSurface = codec.createInputSurface()
codec.start()

6.3 常见坑与厂商差异（专业壁垒所在）

- 不同芯片（高通/联发科/三星）硬编码器行为差异：颜色格式支持、码率控制精度
- 某些机型硬解码器对特定分辨率/帧率支持不完整，需要 fallback 到软解
- MediaCodec 异步模式 vs 同步模式的坑
- 编码延迟与队列积压问题（直播场景尤其敏感）

6.4 阶段产出

• [ ] 实现一个 Camera 采集 → MediaCodec 硬编 → 保存 MP4 文件的完整 Demo
• [ ] 完成一次编码参数调优实验（码率/分辨率/帧率对文件大小和质量的影响）
• [ ] 在至少 2 款不同芯片手机上测试兼容性并记录差异

七、阶段 4：直播/短视频全链路实战（3 月）

7.1 完整链路

采集(Camera/麦克风)
  → 预处理(滤镜/美颜/降噪)
  → 编码(H.264/H.265 + AAC)
  → 封装(FLV/RTMP 或 自定义协议)
  → 推流(RTMP/WebRTC/自研协议)
  → 服务端(转码/分发/CDN)
  → 拉流
  → 解封装
  → 解码
  → 渲染

7.2 关键技术点

7.3 实战项目建议

1. 用开源库（如 ijkplayer 思路或自行集成 FFmpeg）实现一个视频播放器
2. 实现一个简单推流 Demo：采集 + 编码 + RTMP 推流
3. 做一次动态码率调整实验：模拟弱网环境，观察卡顿与码率变化关系

7.4 阶段产出

• [ ] 完成一个端到端的推流/播放 Demo（哪怕依赖开源库拼装）
• [ ] 写一份《音视频延迟分析报告》：拆解采集/编码/网络/解码/渲染各环节耗时
• [ ] 理解并能讲清弱网场景下的码率自适应策略

八、阶段 5：Vulkan 与新一代图形 API（选修，2 月）

Vulkan 相比 OpenGL ES 的核心差异：
- 更底层的控制力，显式管理内存和同步
- 更高的性能天花板，但开发复杂度也更高
- 适合对渲染性能要求极高的场景（游戏引擎、复杂特效）

建议：先精通 OpenGL ES，再视岗位需要（游戏引擎、高端相机应用）学习 Vulkan，多数业务场景 OpenGL ES 已足够。

九、阶段 6：性能优化与兼容性治理（持续）

9.1 音视频领域特有的性能问题

9.2 兼容性测试矩阵建议

覆盖：高通/联发科/三星 Exynos 至少各 1～2 款机型
覆盖：不同 Android 版本（尤其编解码器行为变化较大的版本）
记录：分辨率支持范围、颜色格式支持、编码延迟、崩溃率

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

打勾 ≥ 15 项，可视为具备音视频/图形专项中高级水平：

图形基础

• [ ] 能画出完整 OpenGL ES 渲染管线图
• [ ] 独立实现过至少 3 种滤镜效果
• [ ] 理解 Shader 的基本语法与运行机制

相机与图像

• [ ] 用 CameraX 或 Camera2 实现过完整相机应用
• [ ] 理解 YUV_420_888 格式与处理方式
• [ ] 完成过美颜/滤镜算法接入

编解码

• [ ] 实现过 MediaCodec 硬编/硬解 Demo
• [ ] 完成过编码参数调优实验
• [ ] 在多款芯片机型上测试过兼容性差异

直播/短视频

• [ ] 理解完整推拉流链路
• [ ] 完成过端到端推流/播放 Demo
• [ ] 能讲清弱网码率自适应策略

工程与治理

• [ ] 建立过机型兼容性测试矩阵
• [ ] 完成过一次音视频延迟分析报告
• [ ] 有可量化的性能优化数据

进阶（可选）

• [ ] 了解 Vulkan 基本概念
• [ ] 了解 WebRTC 低延迟方案

软实力

• [ ] 能对比不同推流协议的适用场景
• [ ] 能讲清一次真实的跨机型兼容性排障案例

十一、常见误区

十二、最短路径

1. 补齐图形/信号处理数学基础（1个月）
2. 用 OpenGL ES 实现基础滤镜 Demo（2个月）
3. 用 CameraX + MediaCodec 实现"采集-处理-编码-保存"完整链路（3个月）
4. 做一次多机型兼容性测试与延迟分析报告（1个月）
5. 尝试一次简单推流/播放 Demo，理解全链路（2个月）

一句话总结：

音视频与图形渲染的护城河是"数学基础 + 硬件差异适配经验"的双重壁垒，训练语料稀缺、必须多机型真实调试验证，这是 AI 现阶段很难独立替代的专业领域。

十三、关联文档

• ../Android移动开发方向抗替代性与薪酬分析.md — 本方向的替代率与薪酬定位
• ../Android高级架构师学习路线.md — 性能优化方法论的通用基础
• 01-性能优化专项学习路线.md — 与本方向的性能优化章节可交叉学习

架构设计与技术选型学习路线

定位：从"能实现别人设计的架构"到"能主导架构设计并对后果负责"的方向。
适用对象：3～6 年 Android/移动开发，希望往架构师方向纵向发展。
抗替代性逻辑：架构设计的核心是"在不完整信息下做权衡并承担后果"，AI 可以列出选项和优缺点，但不能替你承担选错的责任，这是本方向抗替代的根本原因。
与仓库关联：本文是聚焦"架构设计与技术选型"这一单点能力的精简路线，更全面的架构师综合能力（含性能、稳定性、工程效能、领导力）见 ../Android高级架构师学习路线.md。

一、为什么"架构设计"和"写代码"是两种不同的能力

写代码：给定方案，把它正确实现
架构设计：在多个不完整、有冲突的方案里，选一个并说明为什么

前者有标准答案（AI 擅长），后者没有标准答案（AI 擅长列举，不擅长拍板）

架构师的核心产出不是代码，而是 决策 + 决策理由 + 决策后果的责任承担。

二、能力地图

三、学习路线总览（建议 8～12 个月）

阶段 0：架构模式的本质理解              → 1～1.5 月
阶段 1：系统分解与模块化实战            → 2 月
阶段 2：技术选型方法论                  → 1.5 月
阶段 3：架构文档与决策记录（ADR）       → 1 月
阶段 4：架构评审实战                    → 1.5 月
阶段 5：架构演进与治理                  → 2 月
阶段 6：项目化与影响力建立              → 持续

四、阶段 0：架构模式的本质理解（1～1.5 月）

4.1 不要死记模式定义，要理解模式解决的问题

4.2 训练方法：给定场景，判断该用什么模式

练习示例：
- 一个纯展示型 5 屏小工具 App → 用什么？为什么不需要 Clean Architecture？
- 一个有复杂状态机的直播间互动页面 → 用 MVI 而非 MVVM 的理由是什么？
- 一个多数据源、长期迭代的电商 App → Clean Architecture 值得吗？

4.3 阶段产出

• [ ] 写一份《架构模式决策树》：给定业务特征，推导该用什么模式
• [ ] 能对着任意一个开源项目，评价它的架构选择是否合理

五、阶段 1：系统分解与模块化实战（2 月）

5.1 模块化的本质

模块化不是"拆文件夹"，而是"用编译边界强制约束依赖方向"
目的：让一个改动的影响范围可预测、可控制

5.2 典型分层结构

app（壳工程，只做组装）
  ├── feature-x / feature-y（业务模块，互不依赖）
  ├── business-api（业务对外契约，interface only）
  ├── lib-network / lib-ui / lib-account（基础能力）
  └── build-logic（Gradle 统一约定）

依赖原则：
✅ 上层依赖下层
✅ feature 之间通过 business-api 通信，不直接依赖
✅ 基础库暴露稳定 API，内部实现可替换
❌ 反向依赖、循环依赖

5.3 实战练习

1. 找一个单体 App（自己的项目或开源项目），画出当前模块/类的依赖关系图
2. 设计一版目标模块化方案，标注每个模块的职责边界
3. 制定迁移计划：分几个阶段迁移，每个阶段的验证标准是什么
4. 写一份《模块接口设计规范》：模块间通信只能怎么做，不能怎么做

5.4 阶段产出

• [ ] 完成一次真实或模拟项目的模块化拆分方案设计
• [ ] 写出《模块依赖治理规范》，包含允许/禁止的依赖方式

六、阶段 2：技术选型方法论（1.5 月）

6.1 结构化评估框架（避免"凭感觉选"）

面对任何技术选型，按以下维度打分（1~5分）：

1. 解决核心问题的匹配度
2. 团队现有能力与学习成本
3. 社区/官方长期维护的可能性
4. 对构建、包体、性能的影响
5. 退出成本（如果选错了，换掉的代价多大）
6. 与现有架构的兼容性
7. 是否有类似规模的成功案例可参考

6.2 案例训练（针对 Android 常见选型）

6.3 阶段产出

• [ ] 用结构化框架，对一次真实选型决策打分并写出结论
• [ ] 写 2 篇《技术选型对比报告》，包含备选方案、打分、最终决策理由

七、阶段 3：架构文档与决策记录 ADR（1 月）

7.1 ADR（Architecture Decision Record）模板

标题：ADR-00X [决策主题]

背景（Context）：
- 为什么需要做这个决策，当前面临什么问题

决策（Decision）：
- 最终选择的方案是什么

备选方案（Alternatives Considered）：
- 列出至少 2 个被否决的方案及否决理由

代价（Consequences）：
- 这个决策带来的正面收益和负面代价分别是什么

回滚方案（Rollback）：
- 如果这个决策后来证明是错的，怎么退回

7.2 为什么 ADR 是架构师的核心资产

没有 ADR：决策全靠口头传承，人一走方案就没人知道为什么这么设计
有 ADR：新人能看历史决策，避免"重新踩一遍坑"，也是你个人能力的书面证明

7.3 阶段产出

• [ ] 完成 3 篇高质量 ADR（真实项目或复盘历史决策）
• [ ] 建立团队/个人的 ADR 归档习惯

八、阶段 4：架构评审实战（1.5 月）

8.1 一次好的架构评审应该问什么

1. 这个方案解决的核心问题是什么？不用这个方案会怎样？
2. 有没有更简单的方案？为什么不用？
3. 这个方案对现有系统/团队的影响范围有多大？
4. 极端情况（高并发/异常/边界）下会怎样？
5. 如果 3 年后业务规模扩大 3 倍，这个方案还撑得住吗？
6. 如果这个方案错了，多久能发现？代价多大？怎么回滚？

8.2 练习方式

1. 找一份公开的技术方案文档（或自己项目的历史方案）
2. 用上面 6 个问题逐一提问并写下答案
3. 模拟评审会，邀请同事对你的方案做同样的提问
4. 复盘：哪些问题当时没想到，说明什么能力短板

8.3 阶段产出

• [ ] 主导或参与至少 2 次真实架构评审
• [ ] 整理一份《架构评审检查清单》，可复用于未来评审

九、阶段 5：架构演进与治理（2 月）

9.1 架构不是一次性设计，而是持续演进

常见误区：追求"一次性完美架构"
正确认知：架构要能在业务不确定的情况下，以可控代价演进

演进能力体现在：
- 预留扩展点而不过度设计
- 技术债可见、可量化、可分阶段偿还
- 重大重构前有充分的影响面评估

9.2 技术债治理方法论

1. 建立技术债清单（不是模糊的"代码不好"，要具体到模块/问题）
2. 量化影响：构建耗时、Bug 率、开发效率、招聘难度等
3. 排优先级：影响面大 + 修复成本低的优先处理
4. 争取时间：用数据说服业务方给技术债处理的排期
5. 分阶段处理：避免"大重构长期不可用"的风险

9.3 评估重构 ROI 的框架

重构成本 = 开发时间 + 测试验证时间 + 风险（可能引入新 Bug）
重构收益 = 效率提升 + 故障率下降 + 后续开发速度提升
只有收益明显大于成本，且团队能承受迁移期风险，才值得做

9.4 阶段产出

• [ ] 写一份《技术债清单与治理计划》（真实或模拟项目）
• [ ] 完成一次"评估某个重构是否值得做"的分析报告

十、阶段 6：项目化与影响力建立（持续）

10.1 架构师影响力的来源

不是职级给的，而是：
- 你的方案被反复验证是对的
- 你的评审提问总能提前发现风险
- 遇到架构级问题，同事第一反应是找你讨论

10.2 建议的产出节奏

10.3 简历/面试表述框架

不要写：「负责 App 架构设计」
要写：
「主导 XX App 模块化重构，将单体架构拆分为 8 个业务模块 + 3 个基础库，
建立模块依赖治理规范，将平均编译耗时从 XX 分钟降至 XX 分钟，
新功能并行开发冲突率下降 XX%。」

十一、能力自检清单（22 项）

打勾 ≥ 16 项，可视为具备独立架构决策能力：

判断力

• [ ] 能根据业务场景推导该用什么架构模式，而非死记定义
• [ ] 能评价一个开源项目架构选择的合理性
• [ ] 独立完成过至少 1 次真实模块化拆分方案

方法论

• [ ] 使用结构化框架做过至少 2 次技术选型决策
• [ ] 写过至少 3 篇高质量 ADR
• [ ] 建立过模块依赖治理规范

评审能力

• [ ] 主导或参与过至少 2 次真实架构评审
• [ ] 有自己的架构评审检查清单
• [ ] 能提前发现方案里的边界/极端情况风险

治理与演进

• [ ] 写过技术债清单并推动过至少 1 项治理
• [ ] 完成过重构 ROI 评估分析
• [ ] 理解如何在不确定业务下预留合理扩展点

影响力

• [ ] 有同事主动找你讨论架构问题
• [ ] 做过至少 1 次架构/选型相关技术分享
• [ ] 简历上有可量化的架构改进数据

软技能

• [ ] 能清晰表达一个决策的备选方案与否决理由
• [ ] 能承认并复盘一次自己选错的技术决策

十二、常见误区

十三、最短路径

1. 建立架构模式决策树，理解各模式解决什么问题（1个月）
2. 完成一次真实/模拟项目模块化拆分方案（2个月）
3. 用结构化框架做 2 次技术选型并写报告（1.5个月）
4. 写 3 篇 ADR + 主导 1 次架构评审（2个月）
5. 输出 1 份技术债治理计划或重构 ROI 分析（持续）

一句话总结：

架构设计能力的护城河不是"知道更多模式名词"，而是"在不完整信息下做权衡决策、并对后果负责"的能力，这正是 AI 能建议但不能替你承担的部分。

十四、关联文档

• ../Android高级架构师学习路线.md — 更全面的架构师综合能力路线（含性能/稳定性/工程效能/领导力）
• ../Android移动开发方向抗替代性与薪酬分析.md — 本方向的替代率与薪酬定位
• ../十年以上Android开发面试问题.md — 架构相关面试题

Android 性能优化专项学习路线

定位：从"会用 Profiler 看一看"到"能建立体系化性能治理机制"的资深/专家级方向。
适用对象：3 年以上 Android 开发，希望往性能优化专项深耕，建立难以被 AI 替代的核心竞争力。
抗替代性逻辑：性能问题的定位依赖 真机环境 + 多变量归因 + 现场复现，AI 目前只能辅助分析日志，无法独立完成"发现→定位→验证→治理"的完整闭环。

一、能力地图

性能优化专项工程师需要在 5 个子领域 建立体系化能力：

核心方法论（贯穿全部子领域）：

现象 → 工具定位 → 归因（排除变量）→ 制定方案 → 数据验证 → 建立基线/门禁 → 持续监控

不建立这个闭环思维，学再多工具也只是"点状救火"，无法成为"体系化治理专家"。

二、学习路线总览（建议 10～14 个月）

阶段 0：性能分析基础工具链              → 1 月
阶段 1：启动性能优化                    → 2 月
阶段 2：渲染与卡顿优化                  → 2～3 月
阶段 3：内存优化                        → 2～3 月
阶段 4：包体积优化                      → 1 月
阶段 5：电量与网络性能（选修）          → 1～2 月
阶段 6：体系化治理与项目化              → 持续

三、阶段 0：性能分析基础工具链（1 月）

3.1 必须打通的工具

3.2 实操练习

# 用 Perfetto 抓取一次冷启动 trace
adb shell perfetto -o /data/misc/perfetto-traces/trace_file.perfetto-trace \
  -t 10s sched freq idle am wm gfx view

# 查看渲染信息
adb shell dumpsys gfxinfo <package_name>

# 查看内存快照
adb shell dumpsys meminfo <package_name>

3.3 阶段产出

• [ ] 独立完成一次 Perfetto trace 抓取并能读懂时间轴上的线程活动
• [ ] 能用 dumpsys 系列命令快速做初步诊断
• [ ] 搭建 LeakCanary 到一个真实项目并复现一次内存泄漏

四、阶段 1：启动性能优化（2 月）

4.1 核心概念

冷启动：进程不存在，从零创建
温启动：进程存在，Activity 需要重新创建
热启动：进程和 Activity 都存在，仅需恢复

4.2 冷启动完整链路（背诵级）

点击图标
  → Zygote fork 新进程
  → ActivityThread.main() 建立主线程 Looper
  → Application.onCreate()
  → 目标 Activity 创建：onCreate → onStart → onResume
  → 首帧测量布局绘制
  → Choreographer 等 VSYNC 提交
  → 首帧上屏（TTID：Time To Initial Display）
  → 页面完全可交互（TTFD：Time To Full Display）

4.3 常见瓶颈与治理手段

4.4 实战项目

1. 找一个真实/练习项目，测量冷启动 TTID/TTFD 基线
2. 用 Perfetto 找出 Top 3 耗时点并逐一优化
3. 用 Macrobenchmark 建立自动化启动耗时回归测试
4. 引入 Baseline Profile，对比优化前后数据

4.5 阶段产出

• [ ] 一份《启动优化报告》：基线数据 → 归因 → 方案 → 优化后数据对比
• [ ] 搭建 Macrobenchmark 自动化基线测试，接入 CI
• [ ] 能背诵完整冷启动链路并画图讲解

五、阶段 2：渲染与卡顿优化（2～3 月）

5.1 核心链路

measure → layout → draw（应用侧生成 DisplayList）
  ↓
Choreographer 等待 VSYNC 信号
  ↓
RenderThread 执行 GPU 渲染指令
  ↓
SurfaceFlinger 合成多个 Layer
  ↓
显示到屏幕

掉帧本质：从 VSYNC 到下一个 VSYNC（通常 16.6ms/60Hz 或 11.1ms/90Hz）之间，应用没能完成一帧的全部工作。

5.2 常见卡顿原因与排查

5.3 实战项目

1. 制造一个人为的卡顿场景（如复杂列表 + 主线程阻塞）
2. 用 Perfetto 定位是「应用侧慢」还是「GPU 侧慢」
3. 用 dumpsys gfxinfo 输出的 Total frames rendered / Janky frames 建立卡顿率基线
4. 优化后用同样工具验证收益

5.4 阶段产出

• [ ] 能解释 VSYNC 掉帧的完整链路，画出时间轴图
• [ ] 完成至少 2 次真实卡顿定位案例（人为构造或真实项目）
• [ ] 建立"卡顿率"监控指标定义与采集方式

六、阶段 3：内存优化（2～3 月）

6.1 内存问题三大类型

6.2 常见泄漏场景（背诵级）

- 静态变量持有 Activity/Context
- 匿名内部类/Handler 持有外部类隐式引用
- 未注销的监听器/回调（EventBus、观察者）
- 单例持有短生命周期对象
- 资源未关闭（Cursor、Bitmap、Stream）

6.3 排查方法论

1. LeakCanary 捕获泄漏对象 → 看引用链
2. 判断引用链上哪个节点"生命周期该结束但没结束"
3. Memory Profiler 做 Before/After 堆快照对比，定位增长的对象类型
4. 用 MAT (Eclipse Memory Analyzer) 分析更复杂的 dump 文件
5. 区分「一次性峰值」和「持续增长」——只有持续增长才是真泄漏

6.4 图片内存计算（面试高频，务必掌握）

Bitmap 内存 = 宽(px) × 高(px) × 每像素字节数
ARGB_8888: 每像素 4 字节
RGB_565:   每像素 2 字节

示例：1080×1920 的 ARGB_8888 图片
= 1080 × 1920 × 4 ≈ 7.9 MB

6.5 阶段产出

• [ ] 独立复现并修复至少 3 种不同类型的内存泄漏
• [ ] 完成一次 OOM 分析报告（现象→Heap Dump→归因→方案）
• [ ] 能现场计算任意分辨率/格式图片的内存占用

七、阶段 4：包体积优化（1 月）

7.1 分析工具

• APK Analyzer（Android Studio 内置）：查看 DEX、资源、So 库占比
• R8 / ProGuard：代码压缩、混淆、Tree Shaking

7.2 常见优化手段

7.3 阶段产出

• [ ] 对一个真实项目做完整包体积分析，输出 Top 5 占比项
• [ ] 完成一次包体积优化，记录优化前后数据

八、阶段 5：电量与网络性能（选修，1～2 月）

8.1 电量分析

• Battery Historian / dumpsys batterystats
• 常见耗电源：唤醒锁滥用、频繁定位、后台网络轮询、传感器未释放

8.2 网络性能

• 弱网模拟工具、请求合并与重试策略
• 离线缓存与预加载策略设计

8.3 阶段产出

• [ ] 完成一次耗电异常排查案例
• [ ] 设计一套弱网降级策略

九、阶段 6：体系化治理与项目化（持续）

9.1 从"救火"到"治理机制"的升级

救火思维：出问题 → 修 → 结束
治理思维：出问题 → 修 → 建立基线/门禁 → 防止同类问题再发生 → 定期巡检

9.2 必须建立的机制

9.3 简历/面试表述框架

不要写：「做了启动优化」
要写：
「建立 App 冷启动性能基线与 CI 回归门禁，通过异步化初始化、Baseline Profile
和布局扁平化，将冷启动 TTID 从 XXXms 降至 XXXms（-XX%），
并接入 Macrobenchmark 实现持续监控，防止性能劣化。」

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

打勾 ≥ 17 项，可视为具备资深性能优化工程师水平：

工具

• [ ] 熟练使用 Perfetto 分析全链路 trace
• [ ] 熟练使用 Memory Profiler 做 Before/After 对比
• [ ] 会用 Macrobenchmark 搭建自动化基线测试
• [ ] 会用 Baseline Profile 优化关键路径

启动

• [ ] 能画出完整冷启动链路图
• [ ] 完成过至少 1 次真实启动优化并有数据对比
• [ ] 理解 App Startup 库的编排原理

渲染

• [ ] 能解释 VSYNC 与掉帧的关系
• [ ] 完成过至少 1 次卡顿定位与优化案例
• [ ] 理解过度绘制的成因与排查方法

内存

• [ ] 独立修复过 3 种以上不同类型泄漏
• [ ] 能现场计算 Bitmap 内存占用
• [ ] 完成过至少 1 次 OOM 分析报告
• [ ] 理解内存抖动与 GC 的关系

包体与其他

• [ ] 完成过包体积分析与优化
• [ ] 了解电量分析基本方法

体系化能力（区分资深/专家的关键）

• [ ] 建立过性能基线文档
• [ ] 推动过性能相关 CI 门禁
• [ ] 主导过一次跨团队性能专项治理
• [ ] 有可量化的优化数据作为简历支撑

十一、常见误区

十二、最短路径

1. 打通 Perfetto + Memory Profiler + dumpsys 工具链（1个月）
2. 做一次完整启动优化案例并写报告（2个月）
3. 做一次卡顿定位 + 一次内存泄漏修复案例（2个月）
4. 建立性能基线文档，接入 CI 门禁（1个月）
5. 用真实数据整理 2～3 个案例，作为面试/晋升素材

一句话总结：

性能优化的护城河不是"知道更多工具"，而是"建立现象→定位→归因→验证→治理"的完整闭环能力，这个闭环必须在真机上跑通，AI 只能辅助分析日志，不能替你在真实设备上验证结果。

十三、关联文档

• ../Android高级架构师学习路线.md — 性能与稳定性章节的进一阶展开
• ../Android移动开发方向抗替代性与薪酬分析.md — 本方向的替代率与薪酬定位
• ../十年以上Android开发面试问题.md — 性能优化相关面试题