Android 应用开发面试手册使用指南

本手册面向中级 Android 应用开发岗位复习, 也为经验较少的开发者提供从基础到案例的学习路径. 章节目录, 顺序和标题以 SUMMARY.md 为唯一事实源; 本页只说明使用方法, 依赖和验收约定, 不重复维护完整章节清单和逐章自测标题.

读者分流: 本书部分章节围绕 “风控 SDK 背景转应用开发” 人设组织 (01 的转型话术, 知识域里的 SDK 落点注记, 42-45 的主场安排). 经历不同的通用读者: 跳过转型话术, 把示例替换为真实项目故事, SDK 落点注记可直接忽略; 通用考点主体不受影响.

如何使用

1. 先读面试路线与自我定位, 用真实经历确定目标岗位, 优势和短板. 第 01 章的 “底层强, 应用层有空白” 画像只是条件化模板, 其中事实必须替换为自己有证据支撑的内容.
2. 经验较少时, 先按一条建议路径连续学习. 每章先写下自己已有的前置知识和一个待验证问题, 再看机制, 示例和失败排查; 遇到术语不懂时回到前置域, 不以跳读 Q&A 代替正文学习.
3. 从 SUMMARY.md 打开章节, 每次围绕一个主题完成 “定义 → 机制 → 示例 → 失败 → 证据 → 复述”.
4. 平台, 工具链, 法规和产品能力会变化; 优先阅读章节中的版本基线, 最后核验日期和官方来源.
5. 面试答案只使用自己能解释, 能复现, 能说明边界的内容; 指标必须保留基线, 样本和测量方法.

知识域依赖与章节角色

八个知识域按依赖从低到高组织, 但目录中的主题顺序不等于每个人唯一的学习顺序:

• 语言与运行时 (02-06) 是协程, UI 状态, 并发和工程代码阅读的前置.
• Android 基础与 UI (07-17) 建立组件, 生命周期, View/Compose, Jetpack, 架构, 测试和模块通信的日常应用主线.
• 系统机制与性能稳定性 (18-27) 以组件和并发基础为前置, 将 Framework, Binder, 线程与性能问题串起来.
• 数据, 网络与存储 (28-31) 支撑业务状态, 数据一致性和网络排障; 工程化, 构建与发布 (32-36) 建立在这些应用实践之上.
• 业务场景与 SDK 能力 (37-41) 需要网络, 存储和状态机基础; 安全, 风控与逆向视角 (42-45) 再补充信任边界与 Native 风险.
• 跨端, 动态化与音视频 (46-51) 是专项选型和工程实践, 应在掌握 Android 应用主线后按岗位需要进入.
• 算法与计算机基础 (52-58) 服务于编码题, 性能推理和源码阅读, 可与前述主线并行, 但海量数据, 业务算法和系统机制依赖基础算法与 OS / 数据库知识.
• 系统设计, 项目表达与 AI 辅助开发 (59-67) 要求读者先有可核验的工程经历或练习产出, 用来综合表达, 复盘和治理开发过程.

基础章节用于建立术语, 最小机制和可操作起点; 深入章节解释边界, 原理, 诊断或选型; 案例 / 题库章节要求把前两类知识用于完整场景, 练习或个人证据. 学习机制按章型分轨: 02-06 与 52-67 以章内学习目标为准 (52-54 另附进度自测); 07-51 技术章以章末高频面试题与易错点自测; 01 的完成定义表与 65 的完成定义分别约束路线与 Harness 篇. 以各章实际给出的目标, 自测或面试题为完成标准, 不把编号本身当作难度标签.

章节标题或开头的标记含义: ★ 必考核心 (短板且面试高频); ☆ 差异化主场 (强项, 面试差异化武器); (辅) 辅助速览 (低概率直接考, 用于建立上下文).

建议复习路径

路径 A: 应用基础与架构

Kotlin/协程 → View/Compose → Jetpack → MVVM/MVI → 测试 → 组件化.

适合补齐日常 Android 应用开发的主干能力. 重点练习生命周期, 状态恢复, 线程 / 取消, 导航和失败重试, 不只背 API.

路径 B: 系统, 性能与稳定性

Framework/Binder/并发 → 性能方法论 → 启动/内存/ANR → 工具 → APM.

每个优化结论都要回答: 指标是什么, 如何复现, 用什么工具, 前后基线如何, 有哪些副作用, 如何回滚.

路径 C: 工程化与业务安全

存储/网络/数据库 → Gradle/AGP/CI/CD → 隐私 → 鉴权/支付/推送/埋点 → 安全/NDK.

区分客户端与服务端信任边界, 区分技术能力与应用商店 / 法律要求, 对版本和地区敏感结论保留核验日期.

路径 D: 系统设计, 项目表达与 AI Coding

系统设计方法论 → 题库 → 项目证据 → 简历核验 → AI Coding 四章.

系统设计先给目标, 容量, 状态机, 一致性, 失败恢复, 观测和验收; AI Coding 强调小范围修改, 最小权限, 独立验证, 审计与终止条件.

按能力目标选择

• 想独立完成常见功能: 从路径 A 开始, 再按功能需要插入路径 C 的存储, 网络和数据库.
• 想定位线上问题或面试性能题: 先补 Kotlin 并发与组件生命周期, 再走路径 B; 不先学专项工具而跳过问题模型.
• 想应聘业务 / 平台岗位: 路径 A 后走路径 C, 然后选择安全, 跨端或音视频等专项.
• 想准备综合面试: 保留一段可披露的练习或项目证据, 最后走路径 D; 系统设计答案和项目故事不能替代基础机制说明.

通用自测清单

学完一章后, 不再回到首页勾选重复目录, 而是按 “定义 → 机制 → 示例 → 失败 → 证据 → 复述” 保留本章自己的完成证据:

• 定义: 能用 1 分钟说清概念, 解决的问题, 适用前提和一个反例.
• 机制: 能画出核心数据流, 状态机或调用链, 并解释关键步骤为什么发生.
• 示例: 能运行, 补全或手推本章的示例, 并记录输入, 环境, 实际结果与预期是否一致.
• 失败: 能说出至少一个症状, 给出 “症状 → 证据 → 定位 → 修复 → 验证” 的排查路径.
• 证据: 能区分平台事实, 工程经验, 本文工作定义和个人观点; 指标包含基线, 样本量, 分位数, 环境和个人贡献.
• 复述: 能脱离正文说明取舍, 版本/设备/地区/商店/实现边界, 并回答一个追问.
• 对不确定或易变结论, 已回到官方资料重新核验并记录核验日期.

示例性质约定

• 可运行示例必须给出依赖, 调用上下文, 执行方式和预期结果; 只有实际在声明环境运行后, 才能把实际结果作为完成证据.
• 上下文片段必须说明省略的工程代码和应放置的位置; 它用于解释局部实现, 不承诺可独立编译.
• 伪代码只解释机制, 流程或取舍, 不声称可编译或已验证.
• 数字示例必须列出假设, 公式, 计算过程和结论的适用范围; 数字练习不能替代真实性能指标.

维护约定

• 目录变更只修改 SUMMARY.md.
• 章节间引用使用相对 Markdown 链接, 不使用 “见第 N 篇” 这类易失效文本编号.
• 历史计划和设计文档只作为决策记录, 不作为当前导航或平台事实来源.
• 易变章节应在相关结论处标明适用范围 / 版本, 最后核验日期, 并在适用时提供一手来源.
• 新增或修订章节时, 作者应在该章保留适合其类型的完成定义和自测证据: 概念 / 机制, 示例或案例, 失败排查, 边界与复述; 不要求所有章节采用相同标题或都包含可执行代码.
• 维护验收至少检查目录链接与相邻职责, 示例性质标注, 相对链接目标, 代码围栏成对以及章节是否有可核验的学习证据. 目录仍只在 SUMMARY 维护, README 不新增第二份完整目录.