移动安全 / 逆向分析学习路线

定位：从"会用 Android"到"能分析、攻防、评审移动安全机制"的方向，是移动开发方向中抗替代性最强的分支之一。
适用对象：3 年以上 Android 开发，希望转向移动安全测试/研究方向。
抗替代性逻辑：安全领域天然是攻防对抗，训练数据稀少且持续变化（新漏洞类型没有历史语料），出错需要"自然人担责"（安全签字、漏洞评级），AI 只能辅助分析已知模式，无法独立完成 0day 挖掘和责任判断。
完整详细版：本文是精简导航版，完整分阶段路线（面向资深岗位，含 TEE/虚拟化/评审标准等）见 ../资深系统安全工程师-学习路线.md，两文档配合使用。

一、能力地图

二、学习路线总览（建议 12～20 个月，转型者节奏）

阶段 0：密码学与信任边界基础            → 1 月
阶段 1：Android 安全架构精讲            → 2～3 月
阶段 2：静态分析实战（逆向基础）        → 2 月
阶段 3：动态分析实战（Hook/调试）       → 2～3 月
阶段 4：常见漏洞类型与漏洞分析报告      → 2～3 月
阶段 5：进阶专题（TEE/内核保护，选修）  → 3～4 月
阶段 6：项目化与求职                    → 持续

三、阶段 0：密码学与信任边界基础（1 月）

3.1 必学概念

机密性、完整性、身份认证、不可抵赖 —— 四大安全目标
对称加密(AES) / 非对称加密(RSA/ECC) / 哈希(SHA-256) / HMAC / AEAD(GCM)
数字证书、证书链、根证书与信任锚

3.2 阶段产出

• [ ] 写一页笔记：四大安全目标各用什么机制实现
• [ ] 能画出证书链验证的基本流程

四、阶段 1：Android 安全架构精讲（2～3 月）

4.1 信任链（背诵级）

BootROM → Bootloader（验证下一阶段签名）
  → Verified Boot / AVB（验证系统分区完整性）
  → dm-verity（运行时验证系统分区未被篡改）
  → Kernel（SELinux 强制访问控制）
  → init → Zygote → SystemServer
  → 应用沙箱（UID隔离、SELinux domain）

4.2 核心机制

4.3 阶段产出

• [ ] 画一张完整信任链图，标注每层由谁验证
• [ ] 能看懂 SELinux 拒绝日志（avc: denied）并定位原因
• [ ] 默写 Verified Boot、dm-verity、SELinux、TEE、Keystore 的一句话定义

五、阶段 2：静态分析实战（2 月）

5.1 工具链

5.2 分析要点

1. AndroidManifest.xml：暴露的组件（exported=true）、权限声明
2. 关键字符串/常量：API Key、Base URL、加密密钥硬编码
3. 网络请求逻辑：是否有证书校验绕过风险
4. 加密实现：是否使用弱算法、密钥是否硬编码

5.3 阶段产出

• [ ] 独立分析至少 3 个 APK（可用公开靶场应用，如 OWASP MSTG 提供的练习 App）
• [ ] 输出《静态分析发现清单》：暴露组件、潜在硬编码密钥等

六、阶段 3：动态分析实战（2～3 月）

6.1 核心工具

6.2 典型练习

// Frida Hook 示例：绕过简单 SSL Pinning 检测（仅用于授权测试环境）
Java.perform(function () {
    var X509TrustManager = Java.use('javax.net.ssl.X509TrustManager');
    // Hook 逻辑用于学习理解证书校验机制
});

重要原则：所有动态分析练习必须在自己搭建的靶场应用或授权的 CTF/众测环境中进行，不得对未授权的真实线上系统测试。

6.3 阶段产出

• [ ] 用 Frida 完成至少 3 次运行时 Hook 练习（在授权靶场环境）
• [ ] 用 drozer 完成一次组件暴露面测试

七、阶段 4：常见漏洞类型与漏洞分析报告（2～3 月）

7.1 移动端常见漏洞分类

7.2 漏洞分析报告模板

标题：[漏洞名称]

原理：
- 漏洞成因，涉及的机制原理

复现步骤：
- 环境搭建、触发条件、复现过程（在授权环境中）

影响面：
- 该漏洞可能造成的实际危害

修复建议：
- 具体的代码/配置层面修复方案

7.3 阶段产出

• [ ] 复现至少 2 个公开 CVE 或 CTF 题目并写出完整分析报告
• [ ] 完成至少 1 份《本机应用攻击面清单》（基于公开信息与合法测试）

八、阶段 5：进阶专题（选修，3～4 月）

详细展开见 ../资深系统安全工程师-学习路线.md 阶段 2～6。

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

9.1 必须产出（安全岗最看重）

1. 漏洞分析报告 3 份以上（原理→复现→修复建议）
2. 一个自动化工具（APK 静态扫描脚本、Frida Hook 工具集），放 GitHub
3. 一次内部分享/博客，讲清一个安全机制

9.2 求职路径

认证参考：OSCP（渗透测试）、CISSP（偏管理），作品和实战报告比证书更重要。

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

打勾 ≥ 14 项，说明已建立移动安全实质能力：

基础

• [ ] 能讲清 Android 完整信任链
• [ ] 能看懂 SELinux 拒绝日志并定位原因
• [ ] 默写五大安全机制的一句话定义

静态分析

• [ ] 用 jadx/apktool 独立分析过 3 个以上 APK
• [ ] 能识别 Manifest 中的高风险暴露组件
• [ ] 能发现硬编码密钥等常见静态问题

动态分析

• [ ] 用 Frida 完成过运行时 Hook 练习
• [ ] 用 drozer 完成过组件攻击面测试
• [ ] 理解常见网络层安全测试方法

漏洞分析

• [ ] 复现过至少 2 个公开 CVE
• [ ] 写过完整《原理-复现-修复建议》报告
• [ ] 理解至少 6 种常见移动端漏洞类型

进阶（可选）

• [ ] 理解 TEE 与 Keystore 的职责划分
• [ ] 了解虚拟化隔离基本概念

产出与表达

• [ ] GitHub 有 1 个安全相关工具/脚本
• [ ] 做过至少 1 次安全技术分享
• [ ] 简历能写出"移动开发+安全"复合项目经历

软实力

• [ ] 能举出一次"我拍板并承担后果"的安全判断
• [ ] 理解安全测试的授权边界与合规要求

十一、常见误区

十二、最短路径

1. 补齐密码学与信任链基础（1个月）
2. 精讲 Android 安全架构，默写核心机制（2个月）
3. 静态分析 3 个 APK + 动态分析 Hook 练习（4个月）
4. 复现 2 个 CVE，写完整分析报告（3个月）
5. 产出 1 个开源工具，整理作品集求职

一句话总结：

移动安全的护城河是"攻防对抗 + 稀缺数据 + 责任判断"三重壁垒，AI 能辅助分析已知模式，但无法替你在授权环境中完成真实复现与责任判断。

十三、关联文档

• ../资深系统安全工程师-学习路线.md — 完整详细版（面向资深岗位）
• ../Linux内核学习路线.md — 内核保护机制基础
• ../Android移动开发方向抗替代性与薪酬分析.md — 替代率与薪酬定位
• ../传音推荐.md — 手机厂商真实安全岗位 JD 参考

端侧 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 — 性能调优方法论可交叉参考

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

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

定位：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 — 架构相关面试题