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 不新增第二份完整目录.

面试路线与自我定位

这一篇不讲技术, 讲策略. 如果你的真实经历确实是 “底层强, 应用层有空白”, 可以把下面内容当作转型模板; 否则请按自己的经历重写, 不要套用不符合事实的画像. 通用读者分流: 本篇的转型话术和各知识域的 “SDK 落点” 注记围绕 “风控 SDK 背景转应用开发” 人设组织; 经历不同的读者把话术替换为真实故事, 只保留方法与节奏, SDK 落点注记可直接跳过.

使用方式与完成定义

前置知识: 能如实列出自己的项目, 职责和学习时间; 本篇的目标不是制造统一人设, 而是把事实组织成可验证的求职叙事. 完成本篇后, 你应能选择目标岗位, 说明一项真实能力的证据链, 并完成一次有记录的模拟面试.

不要把 “读完” 当作完成: 没有真实项目证据的经历只能表述为学习或练习, 不应写入工作职责.

一, 你的优势与劣势盘点

优势 (先用证据自诊断, 再在面试中主动亮出来)

只把能说明项目背景, 个人职责, 方案取舍和结果的能力当作优势. 若确有这些证据, native, 性能和安全经验对音视频, IM, 支付, 出海 App 等方向可能是加分项.

劣势 (面试中会被重点拷问, 必须补)

1. UI 层: View 绘制流程, 事件分发, 自定义 View, Compose: 应用岗的核心, 你接触少.
2. Kotlin 协程 / Flow: 现代 Android 异步基石, 你不熟.
3. Jetpack 全家桶: ViewModel/Room/Navigation/Hilt/DataStore, 应用开发日常.
4. 应用架构: MVVM/MVI, 单向数据流, 分层: 中级必考.
5. 主流业务库实战: Retrofit/Glide/OkHttp 的工程化用法.

二, 转型叙事: 怎么讲你的故事

面试官一定会问:“你之前做风控 SDK, 为什么转应用开发? 能行吗?” 准备好这套话术:

“我过去在 [真实项目 / 模块] 负责 [可核验的底层工作], 积累了 [能举例说明的系统, 性能或稳定性经验]. 我希望把这些经验用在完整产品中. UI 和上层框架是我正在补的方向; [仅在完成学习和练习并能展示证据时] 我已经系统学了协程, Compose, Jetpack 和 MVVM 架构.”

关键三点:

• 不贬低过去: 如有可核验的底层经验, 可说明它带来的系统理解, 但不要用 “比别人更懂系统” 这类无法举证的比较性表述.
• 承认短板但展示行动: 只有完成 X, Y, Z 的学习, 练习或项目验证后, 才说 “我已经系统学了 X, Y, Z”; 否则如实说明当前进度和下一步计划.
• 给团队一个理由: 仅在有对应经历时说 “我能补团队在 native / 性能 / 安全上的短板”, 并准备事实依据.

本手册的 SDK 视角: 这本手册不是通用 Android 考点清单, 而是围绕 “设备指纹 / 风控 SDK 背景” 组织的一条差异化叙事线. 通用篇负责补应用侧短板 (UI, 架构, 协程), 让 “没做过完整 App” 不再是硬伤; 主场篇 (42-43) 负责拉开差距, 把背景转成别人难以复制的优势. 各技术篇都能与 SDK 背景挂钩: Gradle 篇讲 SDK 的发布与 consumer-rules 视角, 合规篇讲设备标识怎么采集才合规, 协程篇落到事件上报的竞态去重与并发限流. 读每一篇时按 “能讲我哪段经历 / 补我哪块短板” 对位, 而不是逐篇背考点.

面试策略: 被问到与主线无关的问题时, 可以用 “这个问题在我的 SDK 场景里是…” 的句式主动把话题引回风控背景, 与 42 篇开头的主动引导策略呼应; 前提是确有对应经历可讲, 不要强行安插.

三, 目标岗位选型 (扬长避短)

优先投这些方向, 你的底层背景是加分项而非累赘. 每个方向都按 “为什么契合 → 面试会问什么 → 怎么包装经历 → 可能追问” 准备:

• 音视频 / 直播 App
  • 为什么契合: 音视频链路常接触 FFmpeg, 编解码, OpenGL/音频采集, native crash 与性能调优, 你的 C++/NDK/JNI 经验能直接迁移.
  • 面试会问: JNI 调用开销怎么控制? native 崩溃怎么定位? 音视频卡顿如何拆解到采集, 编码, 网络, 渲染各环节?
  • 怎么包装: 把风控 SDK 里的 native 模块讲成 “在宿主 App 约束下做稳定, 低开销, 可回滚的 native 能力”, 突出跨层调用, 线程模型, so 体积和崩溃治理.
  • 可能追问: 如果没做过播放器, 不要硬装; 回答 “音视频业务链路我需要补, 但 native 性能, JNI 边界, crash 定位这些底层问题我能快速接住”.
• IM / 通讯
  • 为什么契合: IM 重视连接稳定性, 弱网, 消息可靠性, 离线 / 重连和端侧性能, 很多问题不是纯 UI, 而是协议与状态机.
  • 面试会问: 弱网下如何保证体验? 长连接断线重连怎么设计? 消息去重, ACK, 重试和本地落库怎么取舍?
  • 怎么包装: 强调你做 SDK 时对宿主环境, 网络 / 设备差异, 异常采集和后台约束的敏感度, 把它转成 “端侧可靠性” 语言.
  • 可能追问: 若被问到完整 IM 架构, 先按 “连接层 → 消息状态 → 本地缓存 → UI 同步 → 失败补偿” 分层, 不要一上来堆大规模服务端名词.
• 出海 App / 工具类
  • 为什么契合: 出海和工具类常受包体积, 机型兼容, 启动速度, 隐私合规, 多语言环境影响, SDK 背景天然关注 “不能拖累宿主”.
  • 面试会问: 包体积怎么拆? so ABI 如何收敛? 低端机启动 / 内存如何优化? 兼容性问题怎么排查?
  • 怎么包装: 讲你如何在 SDK 约束里做延迟初始化, 按需加载, ABI / 符号裁剪, 异常兜底; 这些都能转化为 App 侧工程质量.
  • 可能追问: 遇到隐私 / 合规问题时, 用 “最小化采集, 用户授权, 可配置开关, 日志脱敏” 这类工程原则回答, 不要编造具体合规项目.
• 支付 / 金融 App
  • 为什么契合: 支付金融对安全, 风控, 稳定性和审计非常敏感, 你的对抗视角能帮助团队提前发现风险点.
  • 面试会问: 如何防 Hook/篡改/重放? 敏感数据怎么保护? 安全能力如何避免影响性能和用户体验?
  • 怎么包装: 把风控经验翻译成 “安全风险识别 + 端侧防护 + 性能可控 + 可观测”; 强调防御和工程治理, 而不是炫攻击细节.
  • 可能追问: 被追具体安全方案时, 保持防御视角, 说清威胁模型, 边界和误报成本; 不要夸大成 “完全防住”.
• 大厂基础架构 / 性能团队
  • 为什么契合: 基础架构和性能团队关注启动, APM, 稳定性, 包体积, native 质量和跨业务复用, 与你的 SDK 工程经验最接近.
  • 面试会问: 启动耗时如何拆解? APM 指标怎么定义? native crash 符号化怎么做? 一个优化如何灰度和回滚?
  • 怎么包装: 突出 “做给多个宿主 / 业务使用” 的 SDK 思维: 接口稳定, 兼容性, 监控, 降级, 性能预算, 发布质量.
  • 可能追问: 如果问到业务产品经验不足, 回应 “我更适合先从性能/稳定性/native 基建切入, 同时补齐 UI 和业务架构”.

谨慎投: 纯营销活动类, 纯 UI 堆叠的业务岗: 这类岗位你的优势用不上, 而短板暴露无遗.

四, 典型面试流程与各轮重点

每轮都要准备一个 “桥接句”:我过去做的是底层 SDK, 现在补的是应用层 API 和架构实践; 底层经验能帮助我在性能, 稳定性, 安全问题上比普通应用开发者更快定位根因. 这句话不是万能答案, 而是把话题从 “你没做过完整 App” 拉回 “你能给团队补什么能力”.

五, 两个月冲刺计划 (示例, 按诊断结果调整)

这只是排期示例, 不承诺固定两个月能补齐真实项目经验. 先用模拟面试和自测确定短板, 再调整每阶段时长.

• 第 1-2 周: Kotlin 语言核心 + 协程与 Flow.
• 第 3-4 周: View 与自定义 View + Jetpack Compose.
• 第 5 周: Jetpack 架构组件 + MVVM 与 MVI.
• 第 6 周: Android 系统原理 + 性能优化总览.
• 第 7 周: NDK 与 JNI + 主流第三方库.
• 第 8 周: 项目复盘专题, 算法, 模拟面试和 iOS 基础速览.

六, 心态提醒

如果你已有可核验的底层经验, 这不是从零开始; 如果没有, 就从真实基础出发. 上层知识可通过阶段性学习逐步补齐, 但项目实践, 结果和协作经验仍需要真实证据积累. 把姿态放在 “我带着已有能力并持续补齐应用实践” 的位置, 不夸大也不回避短板.

职业规划证据练习表单

以下方括号字段是读者练习表单, 不是出版正文的未完成内容, 也不替读者生成个人答案. 只填写自己可证明的事实; 指标, 职责或成果没有证据时, 填写 [未测量/待补证据], 不以推测替代.

完成条件: 能用上述证据说明目标岗位与当前能力的匹配和缺口, 并能区分已完成, 进行中与未知项. 在读者填入可核验证据前, “职业规划” 类开放题只能视为部分完成.

七, 把学习变成可核验经历

简历 before / after (上下文片段, 方括号内容必须替换为事实)

不要在简历中把课程目录改写成工作成果. 下面是同一事实的表达对比:

Before:熟悉 Kotlin,协程,Compose,参与 Android SDK 开发.

After:[时间] 在 [项目/练习仓库] 中负责 [具体模块];用 [技术] 解决了
[可描述的问题].我负责 [个人决策与实现],通过 [测试,日志,人工步骤]
验证 [实际观察到的结果];限制是 [尚未覆盖的边界].

“After” 只有在每个占位项都有证据时才能使用. 常见失败是把团队成果, 无法复现的数字或尚未完成的学习写成个人结果. 排查路径: 症状是追问时无法复述输入和验证; 证据是没有 PR, 文档, 测试记录或演示; 定位为证据链断裂; 修复是删去推测性成果并改成职责和学习状态; 验证是请同事或自己按 STAR 追问五分钟仍能回答.

最小练习项目

建立一个本地, 可公开或私有的 “任务列表” 练习项目, 不必伪造线上数据. 它至少包含: 一个输入表单, ViewModel 持有的 StateFlow, 一个可取消的模拟加载, 加载/空/错误状态, 以及一次本地持久化或 fake repository. 分别在 README 或笔记中写下:

1. 每个状态由什么事件触发, 以及状态不可恢复时如何处理.
2. 旋转屏幕或离开页面时协程如何取消 / 重新收集.
3. 一个你亲自遇到的失败及 “症状→证据→定位→修复→验证”.

项目完成标准是能够从零演示上述流程, 并在不看稿的情况下说明为什么用 StateFlow 而不是一次性事件; 具体实现学习路径链接到协程与 Flow, 不在本篇重复技术细节.

20 分钟模拟面试脚本

录音后逐题标记 “事实, 推断, 未知”.未知不是失败; 将其转成下一周的学习任务, 完成后再更新说法.

Kotlin 语言核心

Kotlin 是现代 Android 的第一语言. 你会用, 但要把 “会用” 升级到 “讲得清原理”.本篇覆盖中级面试高频语法点的底层机制.

章节边界与示例说明: 本篇讲日常 Kotlin/JVM 基础语法, 类型系统和对象模型; inline 字节码, value class 装箱, context parameters 与 Java ABI 等编译器视角问题见进阶专题. 除标注 “可运行示例” 的小程序外, 本文既有 Kotlin 代码均为需要放入 Android/JVM 工程的上下文片段; 带 “伪代码” 标记的块只解释机制.

Kotlin 是什么: Kotlin 是静态类型语言, 以 JVM/Android 为重要运行环境, 也可通过 Kotlin Multiplatform 面向其他平台, 并非 “Android 专属”. 它以空安全与 Java 互操作降低边界风险, 以扩展函数, 高阶函数和简洁语法提升表达力; 协程由语言提供 suspend 等语法与编译支持, 调度, CoroutineScope 等能力属于协程库. 这些特性可组合使用, 但仍需根据运行平台和 API 边界判断实际行为.

学习目标: 读者应能解释 null 为何仍会进入 Kotlin, 何时选择作用域函数和类类型, 并能从编译器报错判断型变与可见性边界. 完成标准见文末练习.

一, 空安全 (Null Safety)

Kotlin 把 null 检查提前到编译期.

• val a: String 不可空; val b: String? 可空.
• 安全调用 b?.length: b 为 null 时整体返回 null.
• Elvis b?.length ?: 0: 为 null 时给默认值.
• 非空断言 b!!: 为 null 时抛 NPE (慎用).
• 平台类型 String!: 来自 Java 的类型, Kotlin 不知其可空性, 调用方负责.

易错: lateinit var 用于非空且延迟初始化 (只能用于 var, 非基本类型), 访问前未初始化抛 UninitializedPropertyAccessException, 可用 ::x.isInitialized 判断. by lazy 用于 val, 线程安全延迟初始化.

null 从哪里进入 Kotlin

非空类型是编译器在 Kotlin 边界内提供的约束, 不是运行时世界永远不产生 null 的保证. 常见入口如下:

• Java 注解缺失或平台类型: 无可靠 @Nullable/@NonNull 注解的 Java 返回值在 Kotlin 看作平台类型; 把它当 String 使用, 实际返回 null 时仍可能 NPE.
• 反射或序列化: 反射, JSON/Parcel 等框架可绕过正常构造/类型检查, 缺字段或不可信数据可能得到 null 或未初始化状态.
• Java 集合污染: Java 可把 null 写入 Kotlin 声明为 MutableList<String> 的底层集合, Kotlin 遍历时才暴露问题.
• 并发时序: 检查非空后, 另一线程可能修改共享可变引用; 用不可变快照, 锁或其他安全发布方式, 而不是依赖一次 null 检查.

边界层应将平台类型和外部数据先归一化为明确的可空/非空领域类型, 再交给核心逻辑. 症状是 “类型明明非空却 NPE”; 证据是 Java 调用链, 反序列化输入, 集合内容或跨线程写入记录; 定位输入首次跨越 Kotlin 边界的位置; 修复为注解, 显式校验/默认值, 不可变快照或同步; 验证用 null, 缺字段, 污染集合和并发交错的测试输入覆盖该边界.

Any, Any? 与 Java Object

Any 是 Kotlin 所有非空类型的根, Any? 则是包括 null 在内的可空类型根. Java Object 本身可为 null; 未标注空性时, Kotlin 将 Java Object 视为需在调用边界处理的 platform type, 不能把它直接等同于 Any 或 Any?. Kotlin 的基本类型在 JVM 上通常映射为原始类型, 在泛型, 可空类型或其他需要对象表示的位置会装箱; 与 Java 互操作时应依据签名的空性和装箱形式处理, 而不是只按源码名称判断.

Int 在可空 / 泛型位置会装箱为 Integer. JVM 的 Integer.valueOf 缓存 -128~127 (规范下限, 实现可扩大, 如 HotSpot 可用 -XX:AutoBoxCacheMax 调大), 区间内装箱复用同一实例, 区间外每次新建对象:

val a: Int? = 100
val b: Int? = 100
check(a === b)   // true,  缓存区间内复用同一 Integer

val c: Int? = 1000
val d: Int? = 1000
check(c === d)   // false, 缓存区间外各自装箱

Kotlin == 走 equals 按值比较, 所以 a == b 与 c == d 均为 true; 装箱陷阱只出现在 Java 互操作的 == 或 Kotlin === 引用比较. 热路径上高频装箱会产生对象分配, 增加 GC 压力, 应优先用原始 Int/Long.

if, when, try 都是表达式

Kotlin 的控制结构可产生值, 因此能减少 “先声明可变变量, 再在分支赋值” 的样板. Nothing 表示不会正常返回的计算, 是所有类型的子类型, 常用于让失败分支保持穷尽.

// 可运行示例(Kotlin/JVM,无额外依赖;保存为 ExpressionDemo.kt 后执行
// kotlinc ExpressionDemo.kt -include-runtime -d demo.jar && java -jar demo.jar).
sealed interface LoadState {
    data object Loading : LoadState
    data class Content(val text: String) : LoadState
    data class Failed(val cause: Throwable) : LoadState
}

fun fail(message: String): Nothing = error(message)

fun label(state: LoadState, cached: String?): String = when (state) {
    LoadState.Loading -> if (cached != null) "cached: $cached" else "loading"
    is LoadState.Content -> state.text
    is LoadState.Failed -> try {
        throw state.cause
    } catch (_: IllegalArgumentException) {
        "bad input"
    } catch (error: Throwable) {
        fail("unrecoverable: ${error.message}")
    }
}

fun main() {
    check(label(LoadState.Loading, null) == "loading")
    check(label(LoadState.Content("ready"), null) == "ready")
}

二, 日常语法与 Java 互操作

默认参数与 @JvmOverloads

Kotlin 调用方可直接省略默认参数; JVM 通过编译器生成的 synthetic 默认方法处理省略值: 普通函数通常生成带 bitmask 的 方法名$default, 构造函数则生成带 bitmask 与 DefaultConstructorMarker 的 synthetic constructor; Java 不会自动识别这些桥接. 对确实需要让 Java 省略末尾参数的构造函数或方法使用 @JvmOverloads, 编译器会从右向左生成重载, 每个重载省略一个或多个连续的末尾默认参数.

class Request @JvmOverloads constructor(
    val url: String,
    val timeoutMillis: Long = 3_000,
    val retryCount: Int = 1
)
// Java 可调用: new Request(url), new Request(url, timeoutMillis), new Request(url, timeoutMillis, retryCount)

它不会为跳过中间参数生成任意组合; 默认参数很多时会扩大 Java API 表面. 仅为稳定, 常用的 Java 调用路径添加它, 其他情况提供命名工厂方法或让 Java 显式传参.

Unit, Java void 与 java.lang.Void

Unit 是 Kotlin 表示 “正常完成但无业务返回值” 的类型; 普通返回 Unit 的 JVM 方法通常以 Java void 暴露. Unit 仍有单例值 Unit, 因而在函数类型或泛型位置会盒装为 kotlin.Unit, 例如 Result<Unit>. java.lang.Void 是可空的 Java 引用类型, 没有可供正常返回的实例; Java 泛型 API 通常以 null 表示无结果, 不应把它当作 Kotlin Unit 的等价替代.

fun save(): Unit = println("saved")
fun <T> completed(value: T): Result<T> = Result.success(value)

val result: Result<Unit> = completed(Unit)

infix, 解构和初始化顺序

infix 只能标记成员函数或扩展函数, 且函数必须恰好有一个参数. 该参数不能是 vararg, 也不能声明默认值; 调用时可写成 a merge b, 但没有点号和括号的写法不适合复杂表达式或 API 含义不直观的场景.

infix fun String.merge(other: String): String = this + other
val message = "Hello, " merge "Kotlin"

data class Point(val x: Int, val y: Int)
val (x, y) = Point(3, 5) // 依次调用 component1() 与 component2()

data class 自动生成 componentN; 普通类也可自行定义 operator fun componentN(). 解构只适合少量, 语义明确的字段, 不应用它隐藏昂贵计算或可空副作用.

主构造参数先成为属性参数或传给父类; 接着按源码顺序执行属性初始化器和 init 块; 最后才执行次构造函数体. 次构造函数必须先委托给主构造函数或另一个次构造函数, 因而不能绕过前面的初始化.

class InitOrder(val name: String) {
    private val normalized = name.trim().also { println("property: $it") }

    init {
        println("init: $normalized")
    }

    constructor(name: String, suffix: String) : this(name) {
        println("secondary: $suffix")
    }
}

// InitOrder(" Ada ", "!") 依次输出 property, init, secondary.

数值转换, 遍历与可见性映射

Kotlin 不做隐式数值扩大或缩小转换, 例如 Int 不能直接赋给 Long; 这避免 Java 风格隐式转换在重载, 精度和空值边界中掩盖错误. 根据意图显式调用 toLong(), toInt() 等, 并在窄化转换前处理溢出语义.

遍历时, for (item in items) 直接使用迭代器协议, 适合需要 break, continue 或清晰索引控制的主流程; forEach 是函数调用, 不能用普通 break/continue; map/filter 用于产生新集合或后续流水线, 不要只为副作用创建被丢弃的中间集合.

for (item in items) {
    if (item.isInvalid()) continue
    consume(item)
}
val visibleNames = users.filter { it.visible }.map { it.name }

Kotlin 与 Java 的可见性不是完全一一对应的源码规则. public 在两侧都对外可见; Kotlin internal 面向同一 Kotlin module, 但 JVM 字节码通常仍是 public 并带模块名改写, 不是 Java 安全边界; Kotlin protected 允许类和子类访问, Java 调用方还受 Java 的包 / 子类规则约束; Kotlin 没有 Java package-private 关键字. 需要给 Java 限制包内访问时, 应将 Java API 放在合适包中并通过公开入口封装, 不要假设 Kotlin internal 等于 package-private.

三, 扩展函数 / 扩展属性

fun String.lastChar(): Char = this[length - 1]

原理 (高频追问): 扩展函数编译成静态方法, 接收者作为第一个参数传入. 所以:

• 扩展函数是静态分发, 不是多态: 调用哪个由声明类型决定, 不是运行时类型.
• 不能真正修改类, 不能访问 private 成员.
• 扩展属性没有 backing field, 只能定义 get/set.

四, 高阶函数与 inline

// 伪代码:省略计时实现,只说明 inline 的函数签名.
inline fun <T> measure(block: () -> T): T

• 捕获外部变量的 lambda 常需要保存捕获状态; 非捕获 lambda 在具体 Kotlin 后端上可能复用单例. 两者的实际对象分配还受 JVM/IR 后端, 目标版本, 调用位置和优化器影响, 不能只凭源码断言.
• inline 会把函数体和可内联 lambda 展开到调用处, 常可避免该调用点的 lambda 对象 / 虚调用, 并支持 lambda 内的非局部返回; 它不保证所有后端, 所有调用形态都 “零分配”.
• noinline: 某个 lambda 参数不内联.
• crossinline: 禁止该 lambda 非局部返回 (用于会在别处调用的场景).
• reified: 配合 inline, 让泛型类型在运行时可见 (T::class), 解决泛型擦除.
• 边界: reified 只让内联函数调用点能拿到 T 的运行时类型, 不能恢复集合元素的完整泛型实参; 例如仍无法把 List<String> 和 List<Int> 的元素类型当作普通运行时类型安全区分.

五, 作用域函数 (let/run/with/apply/also)

记忆法:返回结果用 let/run/with, 返回自身用 apply/also; 用 it 是 let/also, 用 this 是 run/with/apply.

六, class 家族

• data class: 自动生成 equals/hashCode/toString/copy/componentN. 注意 copy 是浅拷贝; 只有主构造参数参与生成.
• sealed class / sealed interface: 密封类型, 子类受限在同一模块. 配合 when 可穷尽分支 (无需 else), 适合表达状态 (Loading/Success/Error).
• object: 单例; companion object 伴生对象 (类级别成员, 可实现接口, 可命名).
• enum: 枚举, 可带属性和方法.
• 嵌套 vs 内部类: Kotlin 嵌套类默认是静态的; 加 inner 才持有外部类引用.

反例: copy () 是浅拷贝, 可变字段共享同一引用:

data class Profile(val name: String, var tags: MutableList<String>)

val a = Profile("Ada", mutableListOf("a"))
val b = a.copy()            // tags 与 a 指向同一个 MutableList
b.tags.add("b")             // 就地修改共享列表, a.tags 同步变为 ["a","b"]
check(a == b)               // 仍相等: 两边看到同一个列表

val c = Profile("Ada", mutableListOf("a"))
val d = c.copy()
d.tags = mutableListOf("a", "b") // 替换为新列表, 内容不同
check(c == d)                    // false: MutableList.equals 按内容比较

data class 的 equals 逐字段调用各属性 equals, 因此可变成员内容或引用一旦出现分歧, 相等性就随内容漂移. 用可变字段做集合 key 或状态比较前, 应保证字段不可变或复制出独立快照.

可见性与 backing field

可见性决定 “谁能在源码层引用声明”, 不是线程安全或不可变性的同义词. public 对所有模块可见; internal 对同一 Kotlin 模块可见; protected 对类及子类可见; private 仅在声明范围可见. 公共 Android SDK 的 internal 在 JVM 字节码中并非安全边界, 敏感能力应通过 API 设计来保护, 而非依赖它.

可运行示例 (Kotlin/JVM, 无额外依赖; 保存为 VisibilityDemo.kt, 执行 kotlinc VisibilityDemo.kt -include-runtime -d demo.jar && java -jar demo.jar):

class Profile {
    var name: String = "anonymous"
        set(value) {
            field = value.trim()
        }
    val nameLength: Int
        get() = name.length
}

fun main() {
    val profile = Profile()
    profile.name = "  Ada  "
    check(profile.name == "Ada")
    check(profile.nameLength == 3)
    println(profile.name)
}

field 是编译器在 accessor 中提供的 backing field (后备字段) 引用. 带默认 getter/setter 的属性通常有后备字段; 只有自定义 getter, 且不引用 field 的计算属性通常没有. 例如 nameLength 每次读取计算结果, 不存储独立值. 症状是以为计算属性会缓存而得到过期性能判断; 证据是 getter 每次都会执行; 定位看是否引用 field; 修复是需要缓存时明确保存状态; 验证是在 getter 中断点或写测试确认读取次数.

域案例 (设备指纹 / 风控 SDK): 用 value class + sealed 把 “设备 ID” 与 “设备状态” 建模成类型, 让业务函数不可能收到裸字符串或乱传枚举值:

@JvmInline value class DeviceId(val raw: String) // 包装设备指纹 hash

sealed class DeviceState {
    data object Normal : DeviceState()
    data object Emulator : DeviceState()
    data object Unknown : DeviceState()
    data class RiskFlagged(val reason: String) : DeviceState()
}

fun report(id: DeviceId, state: DeviceState) {
    // 编译期约束: id 只能是 DeviceId, 不会误传原始字符串
}

sealed 保证 when (state) 穷尽所有状态, 新增状态分支时编译器强制检查; value class 让指纹字符串与普通 String 在类型上区分开.

七, 委托 (Delegation)

委托的心智模型是:我不亲自做, 把某件事交给另一个对象做. 它解决的是 “复用行为” 问题, 不是 “继承层级” 问题.

Kotlin 里有两类常见委托:

1. 类委托: 组合优于继承

interface DataSource {
    fun query(): String
}

class RemoteDataSource : DataSource {
    override fun query(): String = "remote"
}

class LoggingDataSource(
    private val real: DataSource
) : DataSource by real {
    override fun query(): String {
        println("before query")
        return real.query()
    }
}

: DataSource by real 的意思是: 如果 LoggingDataSource 没有自己实现某个 DataSource 方法, 编译器就自动生成转发代码, 把调用交给 real.

这比继承更灵活: 你可以包装不同实现, 增强行为, 替换数据源, 而不用把类层级设计得很深. Android 里常见于 Repository 包装, 缓存层包装, 埋点 / 日志包装, 测试 fake 实现替换.

易错点: 外层类 override 的成员, 不会改变委托对象内部自己的调用逻辑. 委托对象在执行自己的方法时, 访问的是它自己的成员, 不是外层包装类 override 后的成员.

2. 属性委托: 把属性访问逻辑抽出去

val config by lazy {
    loadConfigFromDisk()
}

var name: String by Delegates.observable("unknown") { property, old, new ->
    println("${property.name}: $old -> $new")
}

属性委托的本质是编译器把属性访问改写为对委托对象的调用:

class StringDelegate {
    operator fun getValue(thisRef: Any?, property: KProperty<*>): String {
        return "value of ${property.name}"
    }
}

val title: String by StringDelegate()

读取 title 时, 实际调用的是 StringDelegate.getValue(...). 如果是 var, 还需要 operator fun setValue(...).

常见标准库委托:

• by lazy { }: 首次访问才初始化. 默认 SYNCHRONIZED, 多线程安全但有锁开销; 单线程场景可考虑 LazyThreadSafetyMode.NONE.
• Delegates.observable: 属性变化时回调, 适合状态监听.
• Delegates.notNull(): 非空但延迟赋值, 访问前未赋值会抛异常.
• by map: 属性名作为 key, 从 Map 中读值, 常见于 JSON / 配置映射示例.

Android 落地可以这样理解: ViewBinding 委托, SharedPreferences/DataStore 属性包装, 页面参数校验, 配置中心读取, 本质都是把重复的 getter/setter 或初始化逻辑集中管理.

八, 泛型型变

泛型型变解决的是:泛型类型之间能不能保持原来的父子关系.

List 只读不等于深度不可变

List<T> 是只读接口 / 视图, 它不提供写操作, 但不保证底层集合或元素深度不可变; 同一底层集合仍可经其他 MutableList 引用被修改. MutableList<T> 才提供 add, remove 等写操作. 需要跨模块或并发边界隔离可变状态时, 使用 defensive copy 创建独立快照; 需要持续派生而不共享可变状态时, 选择持久化不可变集合, 并约束元素自身的可变性.

先看一个反直觉点:

val strings: MutableList<String> = mutableListOf("a")
// val anys: MutableList<Any> = strings // 编译不允许

虽然 String 是 Any 的子类, 但 MutableList<String> 不是 MutableList<Any> 的子类. 否则下面这种写法就会破坏类型安全:

val strings: MutableList<String> = mutableListOf("a")
val anys: MutableList<Any> = strings // 假设允许
anys.add(123)                        // 往 String 列表塞 Int
val s: String = strings[1]           // 运行时炸掉

所以 Kotlin 默认让泛型不型变 (invariant). 只有当编译器能确认安全时, 才允许你声明 out 或 in.

1. out: 只生产, 所以可以协变

interface Source<out T> {
    fun next(): T
}

val stringSource: Source<String> = object : Source<String> {
    override fun next(): String = "hello"
}

val anySource: Source<Any> = stringSource // 安全:String 一定也是 Any

Source<out T> 只把 T 作为返回值 “吐出来”, 外部不会把错误类型塞进去, 所以 Source<String> 可以当成 Source<Any> 使用.

2. in: 只消费, 所以可以逆变

interface Sink<in T> {
    fun accept(value: T)
}

val anySink: Sink<Any> = object : Sink<Any> {
    override fun accept(value: Any) = println(value)
}

val stringSink: Sink<String> = anySink // 安全:能消费 Any,当然能消费 String

Sink<in T> 只接收 T, 不把具体 T 返回给你. 一个能处理 Any 的消费者, 当然也能处理 String, 所以赋值方向和 out 反过来.

3. 什么时候用什么

记住 PECS: Producer Extends, Consumer Super. Kotlin 写法就是: 生产者用 out, 消费者用 in.

• 只从容器里读 T: 考虑 out T.
• 只往对象里传入 T: 考虑 in T.
• 既要读又要写具体 T: 通常不要加型变, 保持 T 不型变.
• 不知道具体类型, 只想安全遍历或打印: 用 * 星投影.

面试表达可以这样说: 型变不是为了 “更高级”, 而是为了在不牺牲类型安全的前提下, 让 API 参数更灵活.

版本基线与示例边界

Kotlin/JVM 结论应记录 Kotlin compiler, JDK, JVM target 与 Android desugaring 基线. inline, sealed 类型, 集合实现和标准库 API 可能受编译目标与版本影响; 示例在项目当前 toolchain 中验证后再声称可运行. 官方语义优先参考 Kotlin language/stdlib 文档, 不用反编译某一版本产物外推所有版本. 最后核验: 2026-08-07.

练习与掌握检查

1. 把 Profile.name 改为只允许非空且长度 1 到 20 的值. 预期: 非法输入在 setter 处失败, nameLength 始终由当前 name 计算.
2. 为 “网络返回的 Java 平台类型” 写一个边界转换函数: 输入可空 String?, 输出非空展示文案. 说明 !! 在这里为何不是默认方案.
3. 用 let, run, apply, also 各写一行, 并说明接收者名称和返回值; 能解释选择理由而非只背表格即通过.
4. 解释为什么 MutableList<String> 不能赋值给 MutableList<Any>, 再把只读参数改成合适的 List 类型.

高频面试题

Q1: == 和 === 的区别? == 比较值 (调用 equals), === 比较引用. Java 的 == 对应 Kotlin 的 ===.

Q2: lateinit 和 by lazy 的区别? lateinit 用于 var, 非空, 可多次赋值, 不能用于基本类型, 由开发者负责初始化时机; lazy 用于 val, 首次访问自动初始化, 线程安全可配置.

Q3: 扩展函数能被重写吗? 为什么? 不能. 扩展函数是静态分发, 编译成静态方法, 调用哪个由声明类型决定而非运行时类型, 所以没有多态.

Q4: inline 一定能提升性能吗? 不一定. inline 在常见调用形态可消除函数对象与调用开销, 适合小型高阶函数; 但 noinline, 捕获, 函数引用, 跨模块调用及不同后端 / 优化器都会影响结果, 不能承诺所有形态零分配. 内联还会增大字节码, 对大函数或大量调用点滥用可能增加体积, 降低性能; 应以目标工具链的字节码和基准测量判断.

Q5: Kotlin 的 Unit, Nothing, Any 区别? Any 是所有非空 Kotlin 类型的根, Any? 才包含 null; Java Object 未标注空性时进入 Kotlin 会形成平台类型, 不能简单等同于二者. Kotlin 基本类型在 JVM 上通常映射为原始类型, 在泛型或可空位置按需装箱. Unit 表示正常完成但无业务结果, 普通 JVM 方法通常映射为 void, 泛型位置则使用真实的 kotlin.Unit 对象; Nothing 表示永不正常返回 (抛异常或死循环), 是所有 Kotlin 类型的子类型.

Q6: data class 用作 HashMap 的 key 安全吗? 安全 (自动生成了 hashCode/equals), 但若字段可变, 作为 key 后修改字段会导致查找失败: 应保证 key 不可变.

Q7: Kotlin 委托的本质是什么? 类委托本质是编译器为接口方法生成转发代码, 把调用交给被委托对象; 属性委托本质是把 getter/setter 改写为 getValue / setValue 调用. 它的价值是用组合复用行为, 减少继承和重复样板代码.

Q8: 为什么 MutableList<String> 不能赋给 MutableList<Any>? 因为 MutableList 既能读也能写. 如果允许赋值, 就可以通过 MutableList<Any> 往原本的 MutableList<String> 里写入 Int, 破坏类型安全. 只读的生产者可以用 out, 只写 / 消费的对象可以用 in, 既读又写通常保持不型变.

Kotlin 进阶专题

Kotlin 进阶不是背语法糖, 而是能把语法, 编译器改写, JVM 字节码和 Android 工程边界串起来. 面试回答要从 “怎么用” 升级到 “为什么这样设计, 代价是什么, 和 Java / 协程怎么交互”.

章节边界与示例说明: 本篇从编译器改写, JVM 表示和跨语言边界深化 Kotlin; 空安全, 作用域函数, 可见性, 普通 class 家族和基础型变先学习语言核心. 除明确标注的 “可运行示例” 外, 代码均为上下文片段, 需要补齐 import, Android / 协程依赖或工程函数;“伪代码” 不保证可编译.

学习目标: 能把高级语法映射到字节码层的普通结构, 说明收益和代价, 并能用一个最小样例验证自己的判断.

一, inline / noinline / crossinline 的真实作用

inline 的核心是让编译器把函数体和可内联 lambda 展开到调用点, 减少高阶函数的对象分配与虚调用开销, 同时支持 lambda 内的非局部返回.

inline fun <T> around(name: String, block: () -> T): T {
    val start = System.nanoTime()
    return try {
        block()
    } finally {
        println("$name cost=${System.nanoTime() - start}")
    }
}

• inline: 适合小型高阶函数, 频繁调用路径, DSL, 类型检查工具函数.
• noinline: 某个 lambda 需要被保存, 传递给其他函数或作为对象使用时, 不能内联.
• crossinline: lambda 可能在另一个对象/线程/回调中被调用, 禁止 return 直接返回外层函数, 避免控制流不安全.
• 代价: 内联会复制字节码, 函数太大或调用点太多会增加包体积, 影响指令缓存和 R8 优化空间.

面试追问可以补一句: Kotlin 标准库很多集合 / 作用域函数都依赖 inline, 所以 list.forEach { } 并不一定比手写循环多出 lambda 对象.

二, reified 与泛型擦除

JVM 泛型默认擦除, 运行时通常不知道 T 是什么. reified 必须配合 inline, 因为编译器在调用点展开函数时可以把真实类型填进去.

inline fun <reified T> Any?.castOrNull(): T? = this as? T

inline fun <reified T> requireType(value: Any) {
    check(value is T) { "Expected ${T::class.java.name}" }
}

注意边界:

• reified T 可以做 value is T, T::class, T::class.java.
• 它不能彻底恢复嵌套泛型实参, 例如 List<String> 与 List<Int> 的元素类型仍受擦除影响.
• public inline API 会把实现暴露给调用方字节码, 库开发要注意二进制兼容和实现细节泄露.

域案例 (设备指纹 / 风控 SDK): 边界 JSON 解析用 inline reified 在调用点保留类型, 省去到处传 Class<T>:

inline fun <reified T> JsonParser.decode(json: String): T? =
    decode(json, T::class.java) // 内部仍是 Gson/自研解析器 + Class<T>

val device: DeviceProfile? = parser.decode(rawJson) // 调用点推断 T
val rules: RiskRules? = parser.decode(rulesJson)

reified 让 T 在调用点展开, 比显式传 Class<T> 更简洁; 但它仍只保留顶层类型实参, 嵌套泛型 (如 List<RiskRule>) 的元素类型仍受擦除影响, 要靠解析器自身策略处理.

三, 委托与型变的 JVM/ABI 边界

委托的使用语义, getValue/setValue 约定, 以及 out/in/星投影的类型安全基础见 Kotlin 语言核心. 本篇只聚焦编译后与公开 API 的边界: 类委托通常被编译成持有委托对象的字段与接口转发方法, 不是运行时动态代理; 显式 override 只影响经外层对象进入的调用, 不能改写委托对象的内部自调用. 属性委托的 operator 调用, KProperty 元数据以及 provideDelegate 会出现在生成调用路径中, 公共委托类型或 inline 委托实现的变更可能影响二进制兼容.

型变声明也会映射为 JVM 泛型签名 / wildcard: Kotlin 为 Java 调用方生成的 ? extends/? super 受声明位置和 @JvmSuppressWildcards, @JvmWildcard 等注解影响. 它们是 Java ABI 设计工具, 不应用来绕过 Kotlin 的类型安全; 发布 Kotlin/Java 双用 SDK 前, 应编译一个 Java 调用方并检查生成签名.

四, Sequence 的惰性流水线

Iterable 的 filter, map 等操作通常立刻创建中间集合; Sequence 把中间操作串成惰性流水线, 在终止操作拉取元素时才逐个计算. 这适合大输入, 可提前结束的筛选或转换链, 但不是所有集合操作的默认优化.

val firstActiveName = users
    .asSequence()
    .filter { it.active }
    .map { it.name }
    .firstOrNull() // 终止操作, 此时开始按需迭代

Sequence 的中间操作本身不会得到结果; toList(), count(), firstOrNull() 等终止操作才会消费它. sequence { } 通常会在每次调用 iterator() 时重新执行 builder, 因而可重复消费; iterator { } 返回的是 Iterator, 而非 Sequence. 典型的一次性或受限 Sequence 来自单个 Iterator.asSequence(), Enumeration.asSequence() 或 constrainOnce(), 第二次消费可能抛异常. 小集合上的简单链式操作常不值得引入额外迭代器层; 需要随机访问, 反复遍历或调试中间结果时, 直接用集合通常更清晰.

五, 对象表达式, 对象声明与 Java SAM

对象表达式在执行到表达式时创建新对象, 每次执行都是不同实例; 对象声明 (object) 在其作用域内表示单例. 前者适合一次性实现接口或捕获当前局部状态, 后者适合无状态或集中管理的唯一对象.

val first = object : Runnable { override fun run() = println("first") }
val second = object : Runnable { override fun run() = println("second") }
check(first !== second)

object AppLogger {
    fun log(message: String) = println(message)
}

Java SAM 接口只有一个抽象方法, Kotlin 可用 lambda 直接转换为该接口, 例如 Thread { work() }. Kotlin lambda 捕获的是外层变量所代表的状态; 访问外层 this 时仍是外层接收者, lambda 内 return 还可能在 inline 调用中发生非局部返回. 对象表达式有自己的 this, 可实现多个成员并覆盖方法, 但不能使用 lambda 的非局部返回语义. 选择 lambda 表达单一行为; 需要命名状态, 多个重写成员或独立 this 时使用对象表达式.

六, sealed interface, value class 与领域建模

sealed class / sealed interface 用来表达有限状态集合, 让 when 具备穷尽检查. sealed interface 比 sealed class 更灵活: 实现类仍可继承其他类, 也能让枚举, data class, object 同时表达同一协议.

普通直接子类必须与 sealed 声明处于同一 package 和编译 module; 在 multiplatform 项目中还受同一 source set 约束. expect/actual sealed 声明是例外: 可在各自的 source set 声明直接子类, 层级 source set 还可继续扩展该层级; 具体可见性和层级规则应以 Kotlin sealed classes 官方文档 与项目的 source set 结构核验. 间接子类可以在其直接 sealed 子类允许继承的位置继续扩展. 因而跨模块公开 sealed 层级前, 需要把 “未来能否新增分支” 视为 API / 二进制兼容决策.

sealed interface LoginState {
    data object Idle : LoginState
    data object Loading : LoginState
    data class Success(val token: Token) : LoginState
    data class Failed(val message: String) : LoginState
}

@JvmInline
value class Token(val raw: String)

value class 用单字段包装领域概念, 在很多场景下可被编译为底层字段, 减少运行时对象包装. 它适合 UserId, OrderId, Token 这类 “类型不同但底层都是 String/Long” 的值, 能减少参数传错.

限制也要会讲:

• value class 只能有一个主构造属性, 不能有 backing field 的额外状态.
• 遇到泛型, 可空, 接口装箱, 反射等场景可能仍会 box.
• Java 调用时可能看到 mangled 方法名或底层类型, 需要 @JvmName, API 设计和文档约束.

value class 在 JVM 上会生成 mangled 名称, 但主构造属性的 getter 不受影响 (如 DeviceId.raw 的 getter 就是普通的 getRaw()); 带 <hash> 后缀的是涉及 value class 类型的函数签名, 例如接收 DeviceId 参数的顶层函数会编译为 greet-<hash>(String) 形式, 用于区分共享同一底层类型的不同 value class. <hash> 是类全名 (含包名) 的稳定哈希, 同一构建内稳定但不应当作业务 ABI. Java 需要稳定名字时用 @JvmName 显式命名:

@JvmInline
value class DeviceId(val raw: String) {
    @JvmName("rawValue")   // Java 侧调用 deviceId.rawValue()
    fun rawAsString(): String = raw
}

七, context parameters 与迁移边界

Context parameters 让函数显式声明 “调用时必须提供哪些上下文能力”, 适合 DSL, 横切能力和受控作用域. 本文锁定 Kotlin 2.2.0: 该版本的 context parameters 是实验性语言特性, 必须显式启用, 不能把它作为稳定公共 API 能力. 核验入口:Kotlin 2.2.0 What’s new 与 Context parameters 官方文档.

上下文片段 (Gradle Kotlin DSL; 模块已使用 Kotlin 2.2.0 插件):

kotlin {
    compilerOptions {
        languageVersion.set(KotlinVersion.KOTLIN_2_2)
        freeCompilerArgs.add("-Xcontext-parameters")
    }
}

启用条件不只是升级 IDE: 还要确认 Android 构建链, KSP/注解处理器, IDE 和 Java 调用方支持该编译器与实验 flag. 升级 Kotlin 后须重新核验上述官方文档和项目 release note; 公共, 长期稳定或需要 Java 调用的接口, 优先普通参数/构造注入. context parameters 更适合受控 Kotlin 调用链, 不能用来隐藏核心业务依赖.

interface Logger {
    fun log(message: String)
}

context(logger: Logger, scope: CoroutineScope)
fun launchTracked(name: String, block: suspend () -> Unit) {
    logger.log("start $name")
    scope.launch { block() }
}

工程使用前要确认 Kotlin 版本, IDE 支持和对应语言开关. 迁移时将旧写法:

context(Logger, CoroutineScope)
fun launchTracked(...) { ... }

改为带名称的 context parameters, 并在函数体中通过参数名访问能力.

边界判断:

• Context parameter: 调用链中天然存在, 多个函数共同依赖的环境能力, 例如日志作用域或 DSL 上下文.
• Extension receiver: 函数主要是在扩展某个对象的操作集合时使用, 一次只能有一个扩展接收者.
• 普通参数或构造注入: 依赖需要被保存, 替换, 测试或跨较长生命周期使用时, 通常更清晰.
• 不要为减少几个参数而滥用 context parameters; 隐藏依赖会降低可读性, 并增加 Java 互操作成本.

面试中应把旧 context receivers 作为迁移背景, 而不是当前推荐语法.

八, JVM 字节码角度看 Kotlin

Kotlin 很多高级语法都会落到 JVM 的普通类, 静态方法, 字段和状态机上. 理解这一点能解释性能, 混淆, Java 互操作和调试问题.

因此分析 Kotlin 问题时可以用 javap, Android Studio bytecode viewer 或反编译 Java 结果辅助理解, 但不要机械迷信反编译代码, 因为它只是语义近似.

用 javap 验证, 而不是猜测

可运行示例 (Kotlin/JVM; 需要已安装 kotlinc 与 JDK 的 javap). 将下列内容保存为 BytecodeDemo.kt:

@JvmInline
value class UserId(val raw: String)

fun greeting(id: UserId): String = "hello ${id.raw}"
fun nullableGreeting(id: UserId?): String = id?.raw ?: "guest"

执行: kotlinc BytecodeDemo.kt -d out, 再执行: javap -classpath out -p -c BytecodeDemoKt. 预期观察到顶层函数位于 BytecodeDemoKt, 并可能看到为避免 JVM 签名冲突而生成的 mangled 名称; 实际名称受 Kotlin 编译器版本影响, 不能把某次输出当作稳定 ABI. 再用 javap -classpath out -p UserId 观察包装类.

value class 装箱微示例 (上下文片段):

@JvmInline value class UserId(val raw: String)

fun direct(id: UserId) = id.raw          // 常可使用底层 String 表示
fun nullable(id: UserId?) = id?.raw      // 可空位置需要能表示 null,可能装箱
fun generic(value: List<UserId>) = value // 泛型边界通常需要对象表示

不要依据 “可能装箱” 直接下性能结论. 失败场景是 Java 调用方找不到预期方法或反射名称变化; 证据是 javap 输出和实际 Java 调用编译错误; 定位先检查 mangling 与 nullable/generic/interface 边界; 修复是提供经过设计的 Java 友好桥接 API (如适当的 @JvmName 或普通底层类型入口); 验证是在目标 Kotlin/JDK/Android 工具链重新编译调用方.

九, Java 互操作与空安全陷阱

Kotlin 的空安全在纯 Kotlin 里很强, 但 Java 互操作会出现平台类型 String!, 编译器无法判断可空性.

• Java 方法无注解返回 String 时, Kotlin 看到的是 String!, 你可以当可空或非空用, 风险由调用方承担.
• Java 集合可把 null 塞进 MutableList<String> 的底层对象, 导致 Kotlin 侧遍历时 NPE.
• @Nullable / @NonNull, JSR-305, AndroidX 注解能改善推断, 但依赖库注解质量不一.
• Kotlin 默认参数, 命名参数, 顶层函数, internal, value class 对 Java 调用并不总是友好, 公共 SDK 要专门设计 Java API.

经验回答: 跨 Java 边界时要把平台类型当 “不可信输入”, 在边界层做 null 归一化, 参数校验和异常转换, 不要让平台类型扩散到核心业务层.

十, 更深一层的协程状态机

suspend 不等于切线程, 它表示函数可挂起. 编译器会把 suspend 函数改写成 Continuation Passing Style (CPS):多一个 Continuation 参数, 局部变量被保存到 Continuation 派生对象字段里, 挂起点用 label 区分.

suspend fun load() {
    val user = api.getUser()   // label 0 挂起点
    db.save(user)              // label 1 挂起点
}

// 直觉模型:
// when(label) {
//   0 -> 调用 getUser,挂起则返回 COROUTINE_SUSPENDED
//   1 -> 恢复 user,继续 save
// }

深入点:

• 挂起时不阻塞线程, 只是把后续执行封装进 Continuation, 等待回调恢复.
• 局部变量跨挂起点会变成状态机字段, 所以大对象跨挂起点存活可能延长生命周期.
• 异常传播仍遵循协程 Job 层级, 不是普通线程未捕获异常那一套.
• withContext(Dispatchers.IO) 是切换协程恢复的调度器, 不是直接创建新线程.
• 调试协程栈时要结合 Coroutine Debugger, 结构化并发父子关系和业务日志.

高频面试题

Q1: inline, noinline, crossinline 分别解决什么问题? inline 把函数和 lambda 展开到调用点, 减少对象分配并支持非局部返回; noinline 用于需要把 lambda 当对象保存或传递的参数; crossinline 用于 lambda 会在其他上下文调用时禁止非局部返回, 保证控制流安全.

Q2: reified 为什么必须配合 inline? 因为 JVM 泛型擦除后运行时没有普通 T 的类型信息. inline 会在调用点展开代码, 编译器能把真实类型写入调用点, 所以 T::class, value is T 才可用.

Q3: value class 一定没有对象分配吗? 不一定. 它在很多直接使用场景可用底层值表示, 但遇到泛型, 可空, 接口, 多态, 反射等场景可能装箱. 回答时要强调它主要提升类型安全, 性能收益要看字节码和基准测试.

Q4: Kotlin 空安全为什么仍可能 NPE? 主要来自平台类型, !!, lateinit 未初始化, Java 集合污染, 反射 / 序列化以及并发时序. 跨 Java 边界要做显式 null 校验, 不要让平台类型扩散.

Q5: suspend 函数底层是什么? 编译器把 suspend 函数改写成带 Continuation 参数的状态机, 挂起点用 label 记录进度, 跨挂起点局部变量保存到状态机字段里. 挂起不是阻塞线程, 恢复由调度器和 Continuation 驱动.

易错点 / 追问

• 不要说 inline 一定更快; 它减少 lambda 开销, 但可能造成字节码膨胀.
• 不要说 reified 能完整解决所有泛型擦除; 嵌套泛型实参仍有限制.
• sealed interface 适合有限状态建模, 但跨模块扩展边界和二进制兼容要提前设计.
• value class 首要价值是领域类型安全, 不是 “零成本对象” 的绝对承诺.
• Java 互操作时平台类型要当作风险边界处理, 而不是盲信 Kotlin 的非空类型.
• 不要把类委托讲成运行时动态代理; 它主要是编译器生成接口方法转发.
• 属性委托不是反射魔法, 核心是 getValue / setValue 约定; KProperty 只是让委托知道属性元信息.
• 不要把 out / in 当成 “输入输出参数名”; 它们描述的是类型参数在 API 中的安全使用位置.
• List<*> 不等于 List<Any?>; 星投影表达未知类型, 因此写入能力会被限制.

练习与掌握检查

1. 对本篇 around 和一个非 inline 的等价函数分别运行 javap, 写下你观察到的调用差异; 未观察到差异时记录编译器版本和命令, 不要臆测.
2. 将 UserId 分别用于直接参数, 可空参数, 泛型集合和接口参数. 预测哪些位置可能装箱, 再以目标工具链字节码验证.
3. 为一个需要 logger 的函数比较普通参数, 扩展接收者和 context parameter; 说明为何公共 Java API 不选择后者.
4. 能解释一例平台类型 NPE 的 “输入来源→边界校验→修复→验证”, 即达到本篇掌握标准.

Kotlin 协程与 Flow ★

这是你的头号短板, 也是中级面试的高频考点. 协程是现代 Android 异步编程的基石, 几乎必问. 本篇从原理到实战到面试题完整覆盖.

前置知识与示例说明: 先掌握 Kotlin 空安全, lambda 和异常 (见 Kotlin 语言核心).除明确标注 “可运行示例” 的代码外, 本文为 Android / 协程依赖下的上下文片段; 其中 api, repo, render 等名称由所在工程提供. 伪代码只用于解释状态机, 不能直接编译.

学习目标: 能画出一个请求的挂起 / 恢复与 Job 父子关系, 能在 ViewModel 中把冷流转换为可恢复的 UI 状态, 并能说明取消, 异常和缓冲的边界.

一, 协程是什么 (先建立心智模型)

协程不是线程. 它是一种可挂起 / 恢复的计算, 由编译器 + 运行时在用户态调度.

• 挂起 (suspend): 不阻塞线程. 协程挂起时, 它所在的线程被释放去做别的事, 等条件满足再恢复执行.
• 核心价值: 用同步顺序的写法表达异步逻辑, 消灭回调地狱.

// 回调写法
api.login(user) { token ->
    api.getProfile(token) { profile -> updateUI(profile) }
}
// 协程写法
val token = api.login(user)        // suspend,挂起不阻塞
val profile = api.getProfile(token) // suspend
updateUI(profile)

二, suspend 原理 (高频追问: 协程为什么不阻塞线程?)

suspend 函数由 Kotlin 编译器做 CPS 变换 (Continuation-Passing Style):

1. 编译器给每个 suspend 函数隐式加一个参数 Continuation(回调), 返回值变成 Any?.
2. 函数体被编译成一个状态机: 每个挂起点是一个状态.
3. 挂起时函数返回特殊标记 COROUTINE_SUSPENDED, 线程被释放.
4. 当结果就绪, 调用 continuation.resumeWith(result), 状态机从上次挂起点恢复执行.

所以协程 “挂起不阻塞” 的本质:把后续代码包装成回调, 挂起时退出函数让出线程, 恢复时再回来. 这是面试最爱的深挖点.

一次请求可以按下列顺序追踪. 这里的 “恢复” 由挂起 API 和 dispatcher 决定, 不能假定回到同一物理线程:

viewModelScope.launch (Job A, Main)
  -> api.fetch() 发起异步 I/O
  -> 返回 COROUTINE_SUSPENDED,Main 可处理其他消息
  -> I/O 完成,Continuation 恢复 Job A
  -> dispatcher 安排后续代码,更新 _uiState

// 你写的:
suspend fun login(user: User): Token
// 编译后近似:
fun login(user: User, cont: Continuation<Token>): Any?

三, 结构化并发 (Structured Concurrency)

协程必须在 CoroutineScope 中启动. 核心:协程有父子层级, 父协程等待所有子协程完成, 父被取消则子全部取消, 避免协程泄漏.

• CoroutineScope: 协程作用域, 持有 CoroutineContext.
• CoroutineContext: 元素集合, 关键有 Job(生命周期), CoroutineDispatcher(线程), CoroutineName, CoroutineExceptionHandler.
• Job: 协程生命周期句柄, 可 cancel() / join(), 状态有 New/Active/Completing/Cancelling/Cancelled/Completed.
• Job vs Deferred: Deferred<T> 是携带结果的 Job, 继承 cancel()/join() 并增加 await(); async 返回 Deferred. 取消一个 async 的任务后, await() 会抛出 CancellationException; 若该 Deferred 已成功完成, 取消不再影响其结果.
• 父子关系: 协程内启动的子协程, 其 Job 是父 Job 的子节点.

Android 常用现成 scope:

• viewModelScope: 绑定 ViewModel, onCleared 自动取消.
• lifecycleScope: 绑定 Lifecycle.
• GlobalScope:不推荐, 脱离结构化并发, 易泄漏.

父子 Job 图 (伪图) 应当能在面试时画出:

ViewModel.onCleared()
  └─ viewModelScope 的 SupervisorJob
       └─ launch load()(子 Job)
            ├─ async loadProfile()(子 Job)
            └─ async loadFeed()(子 Job)

viewModelScope 可理解为 SupervisorJob, Dispatchers.Main.immediate 和 ViewModel 清理回调组合出的作用域, 具体实现随 lifecycle 版本演进. 父 scope 取消会向下取消所有子 Job; 其中的 supervisor 语义避免一个直接子任务失败自动取消其他直接子任务, 但你仍要在各任务处把错误归约为明确状态. 不要把 “使用 viewModelScope” 误解为所有异常都会自动显示给用户.

coroutineScope 与 supervisorScope 都等块内子协程全部完成才返回, 区别在失败传播: coroutineScope 下任一子协程失败会取消整个作用域 (包括所有兄弟) 并向外抛出异常; supervisorScope 隔离失败, 直接子协程的异常不会取消兄弟或自身, 但该异常仍要由对应子协程处理或 await() 观察. 选型: 多个步骤是同一事务, 失败即整体回滚 → coroutineScope; 多个相互独立的卡片 / 接口并行加载, 一个失败不拖垮其他 → supervisorScope.

class MyViewModel : ViewModel() {
    fun load() = viewModelScope.launch {       // ViewModel 销毁自动取消
        val data = repo.fetch()                 // suspend
        _state.value = data
    }
}

四, Dispatchers 与 withContext

viewModelScope.launch {                         // Main
    val data = withContext(Dispatchers.IO) {    // 切到 IO
        api.fetch()
    }
    textView.text = data                        // 自动回到 Main
}

withContext 切换上下文并挂起等待结果返回, 是最常用的线程切换方式. 当前 kotlinx.coroutines 文档的 Dispatchers.IO 默认并行度为 “至少 64 或可用处理器数” 的较大值, 仍可由系统属性配置; IO.limitedParallelism(n) 创建的弹性视图可拥有独立并行度配额, 因此不能把总线程数简单等同于表中的默认值. IO 与 Default 共享底层线程资源, 两者间切换不一定真正换线程; 版本升级时应以目标 kotlinx.coroutines 文档和实际负载重新核验. 其中 “64” 是默认值, 随版本调整.

limitedParallelism 与 Semaphore 隔离层次不同: 前者在调度器层给视图划独立并发配额, 该视图上的任务最多 n 个同时执行, 不会与他处代码互相挤占线程; Semaphore 只在应用逻辑层限制在途任务数, 底层仍共享同一 IO 池, 不预留资源. 需要 “为某模块独立线程预算” 用 limitedParallelism, 需要 “限制打某下游的并发请求数” 用 Semaphore.

五, launch vs async

• launch: 返回 Job, 不返回结果, 适合副作用; 未处理异常会按父 Job / 根协程规则传播.
• async: 返回 Deferred<T>, await() 用于取得结果; 失败会存为 Deferred 的完成结果, await() 在观察它时重新抛出该异常.

// 并发请求,总耗时 = max 而非 sum
val a = async { api.getA() }
val b = async { api.getB() }
val result = a.await() + b.await()

await() 不是异常传播的唯一开关. 普通父 Job 中, 一个子 async 失败会立即取消父及兄弟, 即使尚未 await(); 随后 await 只是在调用点重新抛出该失败. supervisorScope 中失败的 async 不会取消兄弟或 supervisor, 但其异常仍保存在对应 Deferred, 调用方必须 await()/检查或以其他方式处理. 根 async(没有结构化父 Job, 例如不推荐的独立 scope) 若既没有 await 又没有显式观察 / 处理, 异常可能只停留在 Deferred, 因而容易被遗漏; 这不是 “所有不 await 都一定静默”.

// 上下文片段:三种异常边界,省略 dispatcher 与错误呈现.
coroutineScope {
    async { error("ordinary child failure") } // 立即取消本 coroutineScope
}

supervisorScope {
    val independent = async { error("independent failure") }
    // 兄弟可继续;此处必须在合适位置 independent.await() 并处理异常.
}

六, 取消机制 (协作式)

协程取消是协作式的: 取消只是把 Job 标记为 Cancelling, 真正停止需要协程代码配合检查.

• 可取消的 suspend 挂起点 (delay 等) 在恢复时会检查取消状态, 抛出 CancellationException; withContext(NonCancellable) 显式排除或未真正挂起即返回的挂起点除外.
• 纯 CPU 循环不会自动响应取消, 需手动检查 isActive / ensureActive() / yield().

val job = scope.launch {
    while (isActive) {        // 配合检查,否则取消无效
        doHeavyWork()
    }
}
job.cancel()                  // 标记取消

易错点:

• CancellationException 是正常的取消信号, 不要在 catch 中吞掉它, 否则破坏取消. try/catch (e: Exception) 会误捕获它, 应 catch (e: CancellationException) { throw e } 或只 catch 具体异常.
• 取消后想做清理用 try/finally, 但 finally 中若要再调挂起函数, 需用 withContext(NonCancellable).

七, 异常处理

• launch: 异常会立即向上传播给父 Job, 触发父及所有兄弟取消.
• async: 失败会记录在 Deferred; 普通父 Job 下子 async 失败会立刻取消父与兄弟, await() 只在调用处重新抛出该结果. supervisorScope 下失败不自动取消兄弟, 但 await 仍会重新抛出; 根 async 通常由 await 或其他显式观察结果的方式暴露失败.
• CoroutineExceptionHandler: 只对 launch 的根协程生效, 作为 “兜底” 处理未捕获异常.
• SupervisorJob / supervisorScope: 子协程失败不影响兄弟和父协程 (单向传播).适合多个独立任务的场景 (如同时加载多个卡片, 一个失败不拖垮其他).

supervisorScope {
    launch { riskyA() }   // A 失败不影响 B
    launch { riskyB() }
}

对比记忆: 普通 Job 一个子失败全家取消; SupervisorJob 子失败各自负责.

八, Flow (冷流)

Flow 是协程版的 “异步数据流”, 可以发射多个值 (协程的 suspend 函数只返回一个值).

• 冷流 (Cold): Flow 默认是冷的: 没有收集者就不执行, 每个 collect 都重新触发上游. 类比 “按需播放的录像”.
• 构建: flow { emit(x) }, flowOf(), asFlow().
• 操作符: map/filter/transform(中间操作, 惰性), collect/first/toList(末端操作, 触发执行).
• 线程切换: flowOn(Dispatchers.IO) 只影响上游; 收集所在线程由 collect 处的 scope 决定. 不要在 flow {} 里用 withContext 切线程 (会报错), 要用 flowOn.
• 背压: buffer() (并发缓冲, 让上游发射和下游收集可在缓冲容量内解耦), conflate()(下游慢时只保留最新值, 适合 UI 进度 / 状态), collectLatest(新值到来取消上个收集块, 适合搜索联想 / 列表刷新).边界是: 这些操作符优化的是 “生产快, 消费慢” 的处理方式, 不应掩盖下游耗时任务本身; 被取消的收集块仍要遵守协作式取消.

flow {
    emit(fetchFromNetwork())   // 上游在 IO
}.flowOn(Dispatchers.IO)
 .map { it.toUiModel() }
 .collect { render(it) }       // 收集在调用方线程(如 Main)

九, StateFlow 与 SharedFlow (热流)

热流 (Hot): 不管有没有收集者都 “活着”, 发射独立于收集者. 用于状态 / 事件, 是 Android MVVM 中替代 LiveData 的主力.

StateFlow

• 持有一个最新值, 新收集者立即拿到当前值 (类似 LiveData).
• 必须有初始值, value 可读可写 (MutableStateFlow).
• 去重: 值相等 (equals) 时不发射 (conflate 语义).
• 适合表达 UI State.

private val _uiState = MutableStateFlow(UiState.Loading)
val uiState: StateFlow<UiState> = _uiState.asStateFlow()
_uiState.value = UiState.Success(data)

SharedFlow

• 可配置 replay, extraBufferCapacity 和 onBufferOverflow, 适合广播允许丢失或明确允许重放的信号.
• replay = 0 在没有订阅者时不会保留值, 因此不能保证 UI 在 STOPPED, 旋转, 切后台或进程重建期间一定收到事件.
• 对于必须保证被处理的业务结果, ViewModel 应将其立即转换为可恢复的 UI state; UI 观察状态并在处理后回调 ViewModel 清除或推进状态.
• 纯 UI 局部且允许丢失的瞬时效果, 才可以在明确语义并有测试的前提下使用 SharedFlow/Channel.

对比表

Android 正确收集姿势 (避免后台浪费):

lifecycleScope.launch {
    repeatOnLifecycle(Lifecycle.State.STARTED) {
        viewModel.uiState.collect { render(it) }
    }
}

repeatOnLifecycle 由 lifecycle-runtime-ktx 2.4.0 引入. 旧写法 lifecycleScope.launch { viewModel.uiState.collect{...} } 会一直收集直到整个 scope 取消, 退后台不停止, 回前台不重启; repeatOnLifecycle 在进入指定状态时开启收集, 离开时取消, 再次进入重新启动.

进阶补充: Channel, callbackFlow 与测试

Channel 与 callbackFlow

Channel 更像协程里的阻塞队列, 适合一对一事件传递; callbackFlow 用于把回调式 API 包装成 Flow.

fun locationFlow(): Flow<Location> = callbackFlow {
    val listener = LocationListener { location -> trySend(location) }
    locationClient.addListener(listener)
    awaitClose { locationClient.removeListener(listener) }
}

关键点: awaitClose 必须释放监听器, 否则会泄漏.

Mutex / Semaphore: 限流与串行化

协程版 Mutex 提供互斥, Semaphore 限制并发进入数量; 与线程锁不同, 竞争时挂起协程而不是阻塞线程.

// 上下文片段: 上报串行化, 事件必须按产生顺序出网, 避免乱序与重复.
private val reportMutex = Mutex()

suspend fun enqueueReport(event: RiskEvent) {
    reportMutex.withLock {          // 排队: 同一时刻只有一个上报在途
        sender.send(event)          // send 可取消时, withLock 自动释放
    }
}

// 限流: 最多 3 个并发请求打采集服务
private val permits = Semaphore(3)
suspend fun rateLimitedCollect() {
    permits.withPermit { api.collect() }
}

风控场景用它保证 “上报串行 + 限流”: 事件队列消费者逐个上报, 采集失败重试时也不会乱序; 需要节流并发请求时用 Semaphore, 而不是无限开协程.

combine / zip / flatMapLatest

stateIn / shareIn

stateIn 把冷 Flow 转成有当前值的 StateFlow; shareIn 把冷 Flow 共享给多个订阅者. 面试要说明 scope, SharingStarted 策略, replay, 以及订阅者消失后上游是否继续运行. UI 常用 WhileSubscribed(stopTimeoutMillis=...), 但超时时间必须依据返回前台频率, 上游成本和数据新鲜度测量, 不能机械套固定值.

上下文片段 (Android ViewModel, 省略 UiState, repository, 依赖注入与 import):

class FeedViewModel(
    repository: FeedRepository
) : ViewModel() {
    val uiState: StateFlow<UiState> = repository.observeFeed()
        .map<Feed, UiState> { UiState.Content(it) }
        .onStart { emit(UiState.Loading) }
        .catch { error -> emit(UiState.Error(error.message ?: "Unknown error")) }
        .stateIn(
            scope = viewModelScope,
            started = SharingStarted.WhileSubscribed(stopTimeoutMillis = 5_000),
            initialValue = UiState.Loading
        )

    val sharedRefreshes: SharedFlow<RefreshResult> = repository.observeRefreshes()
        .shareIn(
            scope = viewModelScope,
            started = SharingStarted.WhileSubscribed(stopTimeoutMillis = 5_000),
            replay = 1
        )
}

上例的 5_000 是待测量的示例值, 不是推荐常量: 若短暂旋转或切换导航页很常见, 上游建立昂贵且数据允许短暂复用, 可从短超时开始; 若数据敏感, 上游成本低或后台保持订阅有风险, 应选择 0 或更严格策略. 测量前后台切换频率, 上游重连 / 查询次数, 内存和数据陈旧窗口, 再调整并记录依据. Eagerly 会立刻启动且在 scope 存活期间持续; Lazily 首次订阅后持续; WhileSubscribed 在订阅者为零后按超时停止并可配置 replay 过期. 选择错误的症状是离屏仍持续请求或回前台频繁闪烁加载; 用日志/网络拦截和生命周期事件取证, 定位 started/replay/scope, 调整后重复前后台与旋转步骤验证.

高频 Flow 的错误, 重试与时间语义

catch 能捕获它上游抛出的异常: 它可捕获 flow {}, 上游操作符和其上游内部流抛出的异常, 不能捕获位于它下游的 collect 块或后续操作符异常. 它同样不应把取消转成业务错误. retry/retryWhen 只重试暂时性且幂等安全的失败, 并必须限制次数或总时限. 搜索中应把 retry 放在每次 flatMapLatest 产生的内部请求流内, 否则外层重试会重新订阅输入流, 语义不是 “重试当前请求”. debounce 表示一段静默后才发送, 适合文本搜索; sample 表示按周期取期间最新值, 适合允许丢失的高频展示. 二者都改变事件语义, 不能用于每一条都必须处理的交易, 消息或写入.

// 上下文片段:query 是用户输入 Flow;search 为 suspend 且可取消的 repository 方法.
val results: Flow<SearchState> = query
    .debounce(300)
    .map(String::trim)
    .distinctUntilChanged()
    .flatMapLatest { keyword ->
        flow { emit(repository.search(keyword)) }
            .retry(retries = 2) { error -> error is IOException }
    }
    .catch { error -> emit(SearchState.Error(error.message ?: "search failed")) }

val sampledProgress: Flow<Int> = downloadProgress.sample(250)

300 和 250 同样只是假设值. 用输入事件时间戳, 请求数, 首个结果延迟和用户可感知刷新频率测量; 当请求仍过多提高 debounce, 当等待感明显则降低, 前提是业务允许. 以下才是会吞掉取消的反例:

// 上下文片段:不要这样写;Exception 包含 CancellationException.
suspend fun loadSafely(): UiState = try {
    UiState.Content(repository.load())
} catch (error: Exception) {
    UiState.Error(error.message ?: "load failed")
}

失败链路: 症状是取消页面后仍显示错误或不断重试; 证据是上述手写 try/catch (Exception) 将 CancellationException 归约为错误状态, 或 retry 未限制; 定位异常类型与 owner Job; 修复是先 catch (error: CancellationException) { throw error }, 再处理具体业务失败, 并限定可重试错误; 验证是开始请求后销毁 owner, 确认无新请求和无错误 UI 更新.

竞态叙事 (双请求竞态, 事件上报去重核心): 症状是刷新后偶发旧数据覆盖新结果; 证据是同一 key 两次请求的完成顺序与 _uiState 最终值矛盾; 定位为旧请求后完成, 覆盖了新值; 修复是启动新请求时取消旧请求 (协程取消或 flatMapLatest), 并把响应经版本号 update 归约进 StateFlow; 验证是注入两个不同延迟的响应, 断言最终 StateFlow 值为新请求结果.

协程测试

使用 runTest, StandardTestDispatcher 和虚拟时间, 不要在测试里真实 delay.

runTest 用虚拟时间执行: delay 不真实等待, 而是把任务排入虚拟时钟. 用 advanceTimeBy(ms) 快进虚拟时钟触发定时任务, 用 runCurrent() 立即执行当前虚拟时刻上已排队的任务; 断言 delay(300) 之后的逻辑时, 应先 advanceTimeBy(300) 再检查. 虚拟时间不要与真实 Thread.sleep 混用, 否则测试变慢且时序不稳.

需要测 Dispatchers.Main 相关逻辑时, 用 Dispatchers.setMain(testDispatcher) 替换主线程调度器, 测试结束用 Dispatchers.resetMain() 还原; 配合 StandardTestDispatcher 可手动控制协程的调度时机, 精确复现 “挂起后恢复” 的时序.

追问: 为什么 callbackFlow 里要写 awaitClose? 因为 Flow 被取消时需要注销外部回调, 否则回调继续持有对象导致泄漏.

高频面试题

Q1: 协程和线程的区别? 线程是 OS 调度的重量级资源; 协程是用户态的轻量 “可挂起计算”, 多个协程可复用少量线程. 协程挂起不阻塞线程. 一个线程能跑成千上万协程.

Q2: suspend 关键字做了什么? 协程凭什么不阻塞线程? 编译器对 suspend 函数做 CPS 变换, 加 Continuation 参数, 函数体编译成状态机. 挂起时返回 COROUTINE_SUSPENDED 并释放线程, 结果就绪后通过 resumeWith 从挂起点恢复. 所以是 “挂起协程” 而非 “阻塞线程”.

Q3: launch 和 async 区别? async 不 await 会怎样? launch 返回 Job 无结果, async 返回 Deferred 有结果. 普通父 Job 的子 async 失败会立刻取消父和兄弟, await 负责在调用点重新抛出结果; supervisorScope 下失败不取消兄弟, 但仍应 await / 处理对应 Deferred; 只有没有结构化父级且从未观察的根 async 才容易遗漏异常, 不能概括为 “不 await 一定静默”.

Q4: 协程的取消是怎样的? 为什么有时 cancel 无效? 协作式取消. cancel 只标记状态, suspend 函数恢复时检查并抛 CancellationException. 纯 CPU 循环不调用 suspend 函数, 不会响应取消, 需手动 isActive/ensureActive/yield.

Q5: Job 和 SupervisorJob 区别? 普通 Job: 子协程异常会取消父和所有兄弟. SupervisorJob: 子异常只影响自己, 不向上传播取消兄弟. 多个独立任务用 supervisorScope.

Q6: CoroutineScope, CoroutineContext, Job 的关系? Scope 持有 Context; Context 是元素集合 (Job, Dispatcher 等); Job 管理生命周期与父子层级. 三者共同实现结构化并发.

Q7: Flow 冷热的区别? StateFlow 和 SharedFlow 怎么选? 冷流无收集者不执行, 每次 collect 重新触发; 热流的生产生命周期由其 scope 和 started 策略决定. 持久页面状态通常用 StateFlow; 必须保证处理的业务结果先归约为 UI state. SharedFlow/Channel 只适合已经明确允许丢失, 重放和多订阅语义的信号, 不能靠 replay=0 获得 “恰好一次” 保证.

Q8: 为什么用 StateFlow 替代 LiveData? LiveData 有什么坑? StateFlow 不依赖 Android, 可在纯 Kotlin 层用, 操作符丰富, 与协程统一. LiveData 的坑: 粘性事件 (新观察者收到旧值), 只能主线程 setValue, observeForever 易泄漏. 但 StateFlow 不感知生命周期, 需 repeatOnLifecycle.

Q9: flowOn 和 withContext 区别? 能在 flow {} 里 withContext 切线程吗? 不能. flow {} 内 emit 必须在收集协程的上下文, 直接 withContext 会抛异常 (违反上下文保留).要切上游线程用 flowOn, 它只影响上游操作符.

Q10: repeatOnLifecycle 解决什么问题? 解决 “App 退后台时仍在收集 Flow 浪费资源 / 可能崩溃”.它在进入指定状态 (如 STARTED) 时启动收集, 离开时取消, 再次进入重启, 是官方推荐的安全收集方式.

练习与掌握检查

1. 画出一次 “页面加载后立即返回” 的 Job 图, 标出哪个 owner 取消, 哪个 Flow 停止, 哪个状态会由新 collector 得到.
2. 在最小 ViewModel 中实现上面的 stateIn, 用 fake repository 统计订阅次数; 旋转 / 停止再恢复页面, 验证策略是否符合你选择的超时语义.
3. 为搜索输入分别用 debounce 和 sample 记录时间线, 说明为何前者更符合 “输入停止后查询”.
4. 制造一个手写 try/catch (Exception) 吞掉取消的版本, 按 “症状→证据→定位→修复→验证” 复盘; 能复盘并修复即达到掌握标准.

RxJava 与响应式编程

RxJava 仍常见于存量 Android 项目. 面试重点不是背操作符, 而是能解释 RxJava 2/3 版本边界, 流语义, 背压, 资源释放, 错误终止以及向协程/Flow 的渐进迁移.

前置知识与示例说明: 先理解线程, 异常和集合基础 (见 Java 与 JVM 基础); 与协程 Flow 的冷热流, 取消语义对照见协程与 Flow. 本文代码均为上下文片段: 须按项目的 RxJava 2 或 RxJava 3 主版本补齐依赖, Android scheduler, api 和 UI 方法, 不能混用包名后声称可运行.

学习目标: 能根据事件是否可丢, 是否有序, 消费是否跟得上来选择 Rx 类型与操作符, 且能给出订阅释放和错误终止的验证方法.

一, 版本与类型选择

RxJava 2 与 RxJava 3 的核心模型相近, 但包名, 依赖坐标和生态 adapter 不兼容. 维护项目时先确认实际主版本及 RxAndroid/Retrofit adapter 的匹配关系, 不要在同一业务链路中无计划混用.

类型选择应表达业务基数, 不要把所有接口都包装为 Observable.

二, 变换操作符的语义差异

• map: 一对一同步变换; mapper 返回普通值.
• flatMap: 一对多并发合并, 结果顺序通常不保证与输入一致.
• concatMap: 按上游顺序串行订阅内部流, 以吞吐换顺序.
• switchMap: 新值到来时取消 / 切换旧内部流, 适合搜索联想等 “只关心最新结果” 的场景.
• zip: 按位置配对, 任一源无法继续配对时可能结束.
• combineLatest: 各源至少发射一次后, 任一源更新都与其他源最新值组合.

面试回答要给出并发, 顺序, 取消和错误传播差异, 不能只说 “都是把一个流变成另一个流”.

三, 调度器与线程边界

subscribeOn 影响订阅及其上游执行位置, 多次调用时通常由最靠近源且实际生效的调度决定; observeOn 从出现位置起切换下游, 可以多次使用. 不要把 “第一个 / 最后一个生效” 背成脱离具体 operator 的绝对口诀.

val disposable = api.getUser()
    .subscribeOn(Schedulers.io())
    .map(::toUiModel)
    .observeOn(AndroidSchedulers.mainThread())
    .doFinally { hideLoading() }
    .subscribe(::render, ::showError)

doFinally 在完成, 错误或 dispose 后都会执行, 适合对称收尾; doOnComplete 不覆盖错误和取消. 重 CPU 计算应使用合适 scheduler, 不能因为上游是网络请求就把所有变换都放在主线程.

四, 背压不是 “加个 BUFFER”

当生产速度持续高于消费速度时, 无界缓存会把速度问题转成内存和延迟问题. Flowable 策略要按业务语义选择:

• BUFFER: 不丢数据的诉求不等于天然有界; 必须明确容量, 上限和溢出策略.
• DROP: 丢弃无法及时消费的数据, 适合允许采样的场景.
• LATEST: 只保留最新值, 适合状态刷新, 不适合交易或消息流水.
• ERROR: 让过载显式失败, 由上层降级或限流.

还应优先考虑上游限速, 批处理, 窗口, 采样和减少无效工作. 背压策略必须与 “是否允许丢失, 是否要求顺序, 最大延迟” 一起回答.

Subject 家族: 热源, 状态与生命周期

Subject 同时是 Observer 和 Observable, 常被用作桥接回调的热源; 它不是默认的全局事件总线. 应优先把状态放在单一 owner, 避免任意位置都能 onNext 造成来源不可追踪. 大多数 Subject 的 onNext/onError/onComplete 不可由多个线程并发调用; 若确实有多个生产线程, 创建后立即用 subject.toSerialized() 暴露串行化入口, 并仍由一个 owner 定义事件顺序. 终止后不得再发射: onComplete/onError 是终止信号, 后续 onNext 无效; 未被订阅者消费的错误还可能进入全局错误处理器, 因此必须在 source 边界处理.

// 上下文片段:RxJava 3 写法;RxJava 2 的包名不同.
private val searchInput = PublishSubject.create<String>().toSerialized()

val results = searchInput
    .map(String::trim)
    .debounce(300, TimeUnit.MILLISECONDS)
    .distinctUntilChanged()
    .switchMapSingle { keyword -> api.search(keyword) }

这里 debounce 的时间线是 a(0ms) -> an(100ms) -> and(250ms) -> 550ms 发射 and; throttleLatest(300ms, unit, emitLast) 按窗口尽快发射一个值并保留窗口内最新值, emitLast = true 会在上游完成时补发最后暂存值, false 则不补发; 它适合允许周期性刷新. sample(300ms) 在采样时刻取最近值, 可能一个值也不发射; throttleFirst(300ms) 保留每个窗口第一值, 适合防连点. 300ms 只是示例: 用输入间隔, 请求数和可感知等待时间测量后调整. 搜索用错 flatMap 的症状是旧请求晚返回覆盖新结果; 证据是请求 ID 与返回顺序相反; 定位为没有取消旧 inner source; 修复为 switchMap 并确认 source 支持 dispose; 验证为故意让旧请求更慢, 检查 UI 只显示最新关键词结果.

背压策略的可操作选择

Observable 没有下游 request 协议; 从它转为 Flowable 时必须声明过载语义. Flowable.create(source, BackpressureStrategy.BUFFER) 本身使用无界缓冲, 不能称为有限 BUFFER. 需要容量上限时, 选择能提供有界队列的 source, 或在合适边界调用 onBackpressureBuffer(capacity, onOverflow, strategy); 也要区分 observeOn 等异步 operator 可能拥有自己的有界预取缓冲, 这不等于 source 已具备端到端背压策略. 示例: 传感器 UI 仪表可以丢中间读数, 审计流水不能丢也必须保序.

// 上下文片段:仅当业务允许丢弃中间仪表值.
val latestReading = sensorObservable
    .toFlowable(BackpressureStrategy.LATEST)
    .observeOn(AndroidSchedulers.mainThread())
    .subscribe(::renderReading, ::showError)

先记录生产频率, 下游处理耗时, 队列深度, 允许的最大陈旧时间和丢失比例; 若所有记录必须处理, 应采取上游限速/批处理/持久化队列或 ERROR 后明确降级, 而不是无界 BUFFER. 典型失败是内存增长和 UI 显示数秒前状态; 证据是队列长度, 堆快照和事件时间戳; 定位为生产速率长期大于消费速率; 修复按上述业务语义选择限速, 批处理或策略; 验证在压测 / 可控 fake 高频源下观察队列上限和延迟, 不虚构结果.

五, 生命周期与资源释放

页面或 owner 应集中管理订阅:

private val disposables = CompositeDisposable()

fun load() {
    disposables.add(repository.observeUser()
        .observeOn(AndroidSchedulers.mainThread())
        .subscribe(::render, ::showError))
}

fun clear() {
    disposables.clear() // owner 仍可能复用; dispose() 后容器不可再接收新订阅
}

注意:

• clear() 取消当前集合但允许继续 add; dispose() 会永久标记容器已释放.
• 长生命周期单例订阅短生命周期 View/Activity 容易泄漏.
• dispose 是取消请求继续向下游交付, 不等于底层工作一定瞬时停止; 取决于 source 是否支持取消.
• 生命周期库只能帮助触发 dispose, 不能修复错误的 owner 和共享链设计.

六, 错误, 重试与终止

Rx 流一旦向下游发送 terminal error 就结束. onErrorReturn/onErrorResumeNext 会把错误转换为值或替代流, 需要避免吞掉不可恢复错误.

retryWhen 必须有终止条件:

• 仅重试可恢复错误, 不重试鉴权失败, 参数错误等确定性失败.
• 指数退避并加入 jitter, 避免客户端同时重试.
• 设置最大次数或总时限.
• owner 销毁, 网络条件不满足或用户取消时停止.
• 重试写操作前确认服务端幂等键和业务语义.

七, 向协程与 Flow 渐进迁移

不要一次性重写整个存量项目. 推荐从边界开始:

1. 固定 RxJava 主版本并补行为测试.
2. 新 Retrofit API 优先使用 suspend; DAO/SDK 边界按真实支持选择适配方式.
3. 在 repository 边界集中做 Rx/Flow/suspend 转换, 避免 UI 层同时理解两套模型.
4. 明确取消, 热/冷流, 背压/缓冲, 错误终止和线程语义的差异.
5. 逐模块迁移并比较稳定性, 复杂度和性能, 不以 “新技术” 本身作为改造收益.

Flow 的挂起可形成自然背压, 但 buffer, conflate, SharedFlow 等仍可能丢失或积压; 不能把 Flow 简化为 “自动解决所有背压”.

高频面试题

Q1: flatMap, concatMap, switchMap 怎么选?
看是否允许并发, 是否要求顺序, 旧任务是否应取消. 并发合并用 flatMap, 严格顺序用 concatMap, 只关心最新结果用 switchMap.

Q2: CompositeDisposable.clear() 和 dispose() 的区别?
二者都释放当前订阅; clear() 后可继续 add, dispose() 后容器保持 disposed, 新加入项会立即被释放.

Q3: 重试为什么危险?
无限重试会放大故障和功耗, 写操作还可能重复扣款或写入. 必须分类错误, 限次, 退避, 加 jitter, 并依赖服务端幂等.

练习与掌握检查

1. 为搜索, 下载进度, 审计流水分别选择 Subject/Rx 类型和时间操作符, 写出是否允许丢失, 重放和乱序的理由.
2. 用一个可控 fake source 让上游快于下游, 记录队列或时间戳, 比较 LATEST 与有限 BUFFER 的业务后果.
3. 在页面销毁后调用 CompositeDisposable.clear(), 验证订阅不再更新 View; 若仍更新, 按 “owner→订阅位置→dispose 支持→验证” 排查.
4. 能解释上述搜索时间线, 旧请求覆盖问题和背压选择, 即达到本篇掌握标准.

版本与参考资料

• 最后核验: 2026-08-07.
• 适用基线: 先确认项目使用 RxJava 2 还是 RxJava 3, 以及 RxAndroid/Retrofit/Room 等 adapter 的对应版本.
• 官方资料: RxJava 项目, RxAndroid 项目.

Java 与 JVM 基础

即便项目用 Kotlin, 面试官仍常问 Java/JVM: 因为字节码, 并发, GC 是共通的底层. 这一篇覆盖高频考点.

前置知识与示例说明: 先会使用 Java/Kotlin 的类, 集合和异常; Kotlin 语言细节见 Kotlin 语言核心, 协程并发的结构化生命周期见协程与 Flow. 本文 Java/Kotlin 代码为上下文片段, 除明确标注 “可运行示例” 外需补齐工程类型, 线程和 import; HotSpot 实现与 Android ART 必须按文中的版本边界区分.

学习目标: 能用术语准确解释共享内存并发, 集合扩容和类加载, 能为一个线程池任务选择合适的同步工具, 并能识别 ThreadLocal 的生命周期泄漏.

一, Java 对象契约与语言基础

equals / hashCode

• equals 表示逻辑相等, 必须满足自反, 对称, 传递, 一致和非空.
• 重写 equals 时必须同时重写 hashCode: 相等对象必须有相同哈希值.
• 作为 HashMap key 的对象应保持不可变; 插入后修改参与相等判断的字段会导致对象仍在桶中, 但无法按新 key 找到.
• Kotlin data class 会按主构造参数生成 equals/hashCode; copy() 是浅拷贝, 可变成员仍可能共享.

String 与拷贝

• String 不可变, 便于常量池复用, 线程安全和作为 Map key. StringBuilder 是非同步的可变字符序列, 适合单线程或局部拼接; StringBuffer 的多数公开方法带同步, 仅在确有同一缓冲区跨线程共享且无法更好地隔离状态时考虑. 不要因为 “线程安全” 就在每次普通拼接中选择 StringBuffer.
• 大量拼接应使用 StringBuilder 或 Kotlin 的 buildString, 不要在循环中反复用 + 创建中间 String.
• 字符串字面量可能进入 String Pool, == 在 Java 中比较引用, equals 比较内容; Kotlin == 会调用 equals, === 才比较引用.
• 浅拷贝只复制对象外壳, 深拷贝还要复制可变引用图. Parcelable, 序列化和缓存快照都要明确这个边界.

String.length() 返回的是 UTF-16 code unit 数, 不等于用户看到的字符数. 例如以下示意代码中, 基本平面 (BMP) 以外的字符由代理对表示, 因此 length() 为 2:

// 示意代码: 用 codePointCount 统计 Unicode code point, 不等同于所有用户感知字素簇.
String emoji = "\uD83D\uDE00";
int utf16Units = emoji.length(); // 2
int codePoints = emoji.codePointCount(0, emoji.length()); // 1

截断用户名, 计算展示宽度或按用户可见字符计数时, 还要按产品语言规则处理组合字符, 变体选择符和 emoji 序列; 不应只按 length() 截断.

抽象类, 接口与修饰符

抽象类用于表达共享状态或部分实现, 类只能继承一个父类; 接口用于表达能力契约, 一个类可实现多个接口. 接口的 default 方法可在不破坏既有实现类的情况下演进 API, 但多个父接口出现同签名默认方法时, 实现类必须显式消歧. 不要为了复用少量工具方法建立继承层次, 可优先组合或静态工具方法.

• final 变量只能赋值一次, final 方法不可被覆写, final 类不可继承. 它有助于表达不可变和限制扩展, 但不使被引用的可变对象自动线程安全.
• static 成员属于类而非实例, 生命周期通常与类加载器一致. 静态集合或回调若持有 Activity, View 等短生命周期对象, 会形成长生命周期引用链.
• synchronized 为同一监视器提供互斥, 并在解锁与后续加锁之间建立可见性关系. 它不自动缩短临界区, 也不应包住网络, 磁盘或长时间计算. 线程状态, 等待协作和锁实践见 多线程并发专题.

泛型, 反射与注解

• JVM 泛型通常经过类型擦除, 运行时不能直接得到普通 T 的实参; Kotlin inline + reified 只能在调用点保留有限类型信息.
• bridge method 示例: 泛型父类 abstract class Base<T> { abstract T get(); }, 子类 class StringBase extends Base<String> { @Override String get() {...} }. 擦除后父类 Base.get() 返回 Object, 子类实际方法签名是 ()Ljava/lang/String;, 与父类不一致, 编译器自动生成桥方法 Object get() 转发到 String get(), 保证多态可用; 反射 getDeclaredMethods() 能看到 isBridge() == true 的额外方法.
• 反射的典型流程是从 Class 获取类型, 用 getDeclaredMethod/getDeclaredConstructor 查找成员, 根据访问控制决定是否允许访问, 再以 invoke 或 newInstance 调用. getDeclared* 能找到本类声明的非公开成员, 但不等于一定有访问权限; Java 模块边界, 安全策略或 Android 混淆配置都可能限制访问.
• 以下是反射流程示意代码, 仅说明访问检查和构造调用顺序, 不应直接用于高频业务路径:

// 示意代码: 真实代码需处理参数类型, 异常, 模块/混淆配置和访问边界.
Class<?> type = Class.forName("example.Profile");
Constructor<?> constructor = type.getDeclaredConstructor(String.class);
if (!constructor.canAccess(null)) {
    constructor.setAccessible(true); // 仍可能因运行时访问规则失败.
}
Object profile = constructor.newInstance("Ada");
Method method = type.getDeclaredMethod("displayName");
Object value = method.invoke(profile);

• 反射适合框架扩展和低频配置, 代价是查找, 访问检查, 装箱, 启动, 混淆适配和更晚暴露的运行时错误; 高频路径优先使用接口或编译期代码生成. 量级感: 单次 invoke/newInstance 相对直接调用常慢一到两个数量级, 且高频反射调用难以被 JIT 内联优化, 具体随 JDK/ART 版本与调用热点变化, 应以测量为准而非套固定数字.
• 注解由声明位置, 元素和保留策略组成. SOURCE 仅供源码工具, CLASS 写入 class 文件但通常不能反射读取, RUNTIME 才能通过反射读取. Room, Hilt, 路由和序列化库经常把注解处理放在编译期; 运行时扫描前应确认确实声明了 RetentionPolicy.RUNTIME.

异常与资源

• Throwable 分为 Error 与 Exception. Error 通常表示 JVM 或运行环境难以由业务恢复的问题, 例如 OutOfMemoryError; Exception 再分为 RuntimeException 及其子类, 与需要声明或捕获的受检异常.
• RuntimeException 常用于非法参数, 状态不满足或程序错误, 可以传播到统一边界处理, 但不能用它掩盖可预期的业务失败. 受检异常适合调用方确实能采取恢复动作的外部失败; 不要机械地在每层 throws Exception 或捕获后吞掉上下文.
• 不要用 Throwable 兜底后吞掉取消, 线程中断或进程终止信号. 捕获 InterruptedException 时, 要么结束当前操作并向上处理, 要么在无法抛出的边界恢复中断标记 Thread.currentThread().interrupt().
• 文件, Cursor, Socket 等资源必须有明确所有权和关闭路径. Kotlin 使用 use, 协程代码还要保证取消时执行清理.
• OOM 分类 (风控 SDK 常排查内存): 堆 OOM (OutOfMemoryError: Java heap space) 多来自对象泄漏或大对象 (采集缓存, Bitmap), 用堆 dump 沿 GC Root 引用链定位; 栈溢出 StackOverflowError 通常是无界递归或过深调用链 (如 JSON 自引用反序列化), 看异常栈的重复帧定位递归点; 元空间 OOM (Metaspace) 多来自类加载器泄漏或反射 / 动态生成类过多 (如反复生成代理类), 排查加载器存活与类数量.

变量生命周期与 I/O 分类

• 局部变量位于方法执行上下文, 超出作用域后不再由该局部变量引用; 实例字段随对象存活, 只要对象仍能从 GC Roots 可达就不会回收; 类变量随类及其类加载器存活. 因而 static 缓存, 监听器和单例是常见的长生命周期持有点.
• GC 判断的是对象是否可从 GC Roots 沿强引用链到达, 不是变量名是否还在源码中出现. 将对象赋给局部, 字段或类变量会改变可达性, 但实际回收时机仍由运行时决定.
• Java I/O 可按数据单位分为字节流 InputStream/OutputStream 与字符流 Reader/Writer; 可按处理层次分为节点流直接连接文件, 内存或 socket, 与缓冲, 编码, 对象序列化等处理流组合包装. 二进制内容按字节处理, 文本按明确字符集的字符流处理, 不要依赖平台默认编码.
• 传统阻塞 I/O 在读写未就绪时会阻塞调用线程; NIO 的 ‘Channel’, ‘Buffer’ 与 ‘Selector’ 可支持非阻塞和多路复用, 但也增加状态管理复杂度. 少量顺序文件读写优先清晰的阻塞 I/O; 大量连接或需要事件驱动时再考虑 NIO, 并正确处理半包, 背压和资源关闭.

二, 集合框架

HashMap (必考)

• 结构: 数组 + 链表 + 红黑树 (JDK8).链表长度 ≥ 8 且数组长度 ≥ 64 转红黑树; 退化阈值 6.
• 默认初始容量为 16, 负载因子为 0.75; 桶数组通常在首次 put 时才延迟分配, 之后达到阈值时扩容翻倍. 容量保持为 2 的幂, 便于用 (n-1) & hash 取代取模.
• 扰动函数: hash = h ^ (h >>> 16), 让高位参与运算, 减少碰撞.
• JDK 8 扩容会按 hash & oldCap 将单链表拆为 low/high 两条链, 并分别保持原相对顺序; 这不使 HashMap 线程安全. JDK 7 并发扩容的头插重排曾可能形成环, 但任何版本都不能用 HashMap 承担并发写入.
• 并发问题: 多线程 put 可能丢数据, 扩容期间读到 null.

扩容的数字推演

术语:容量 (capacity) 是桶数组长度; 负载因子 (load factor) 是达到扩容的比例; 阈值 (threshold) 通常是 capacity * loadFactor; 桶 (bin) 是同一索引上的链表或树节点集合. 以下是 JDK 8 HashMap 常见规则的数字示例, 不适用于并发写入或所有替代 Map 实现.

假设首次插入已经分配桶数组为 16, 负载因子为 0.75, 则阈值为 16 * 0.75 = 12. 插入第 13 个, 且触发检查时需要扩容的条目后, 容量扩为 32, 新的阈值为 32 * 0.75 = 24. 容量翻倍时, 一个节点的新索引不是任意重算: 设旧容量 oldCap = 16, 节点 hash 为 19, 则 19 & 16 != 0, 新索引为旧索引加 16; 若 hash & oldCap == 0, 索引保持不变. 原桶链中的节点会进入 low/high 链且各自保持相对顺序. 这就是容量为 2 的幂能用位运算拆分低位/高位的原因.

常见失败是把 HashMap 用于并发写入或把可变 key 插入后修改. 症状是丢值, 读取异常或查不到已插入键; 证据是并发调用栈, key 修改前后的 equals/hashCode 和最小复现; 定位为无同步访问, 扩容竞争或 key 契约破坏; 修复是选择 ConcurrentHashMap/外部同步并令 key 不可变; 验证是在受控并发循环和断言中检查映射完整性. 不要把一次未复现当作线程安全证明.

ConcurrentHashMap

• JDK7: 分段锁 Segment; JDK8:CAS + synchronized 锁单个桶头节点, 粒度更细, 并发度更高.
• size () 用 baseCount + CounterCell 分散统计.

其他

• ArrayList 是连续动态数组, 随机访问通常为 O (1), 尾部追加摊销为 O (1), 中间插入和删除需要移动元素. 它是大多数按索引读取场景的默认选择, 但频繁在中间插入删除大量元素时要测量移动成本.
• 扩容发生在追加元素且当前数组已满时. 常见 OpenJDK 实现中, 无参构造会先使用共享空数组, 首次 add 再延迟分配通常为 10 的容量; 指定初始容量的构造则按请求容量分配. 之后容量通常按旧容量约 1.5 倍增长, 并至少满足本次所需的最小容量. 扩容会通过 Arrays.copyOf 分配新数组并复制既有引用, 因而一次扩容是 O (n) 成本, 多次尾部追加的均摊成本才接近 O (1).
• 已知要写入大量元素时, 可在写入前以 new ArrayList<>(expectedSize) 或 ensureCapacity(expectedSize) 减少重复扩容和复制. 不要为不确定或过大的上限盲目预分配, 否则会增加堆占用和 GC 压力. 首次容量, 增长公式与内部空数组均是具体 JDK 实现细节, 需按目标 JDK 版本源码或文档核验, 不应视为 Java 语言规范承诺.
• LinkedList 是双向链表, 已定位节点后的插入删除为 O (1), 但按索引随机访问必须遍历, 节点对象也有额外内存和缓存局部性成本. 不要仅因为 “插入快” 就把它用于按索引遍历的热路径.
• HashSet 底层通常基于 HashMap; LinkedHashMap 额外维护双向链表, 可保持插入顺序, 或在 access-order 模式下将最近访问的节点移到末尾. 后者可作为受控大小 LRU 缓存的构件, 但并不自动解决并发, 过期, 加载抖动或缓存穿透.

Hashtable 与小型映射

Hashtable 自 Java 1.0 即存在, 历史原理是为早期 Java 提供同步键值容器. 其大部分公开方法以对象监视器保护, 因而常形成全表串行访问; 它还禁止 null 键和值. 当前 JDK 仍可使用且未被废弃, 但属于遗留同步容器, 新代码不应将它作为默认 Map. 多读写并发映射优先使用 ConcurrentHashMap; 非并发场景或可由短临界区明确保护的场景, 使用私有 HashMap 加受控外部同步. HashMap 即使由外部同步保护, 仍允许一个 null 键和多个 null 值; ConcurrentHashMap 则禁止 null 键和值, 以避免并发查询时无法区分键不存在与值为 null.

Android 的 ArrayMap 和 SparseArray 采用数组保存键和值或紧凑索引, 用较低对象数量换取查找时的二分, 移动或装箱取舍. 小规模映射, 特别是 Android 框架边界可考虑它们: SparseArray 适合 int 键以避免 Integer 装箱, ArrayMap 适合数量有限的对象键映射. 映射规模大, 频繁变更, 查找极热或需要并发访问时, 数组移动和查找成本可能不合适, 应基于数据规模和 profile 选择 HashMap 或并发容器. Android 组件持有与生命周期语境见 Android 四大组件与基础; 此处只定义容器的 Java 语义.

引用类型与 ReferenceQueue

ReferenceQueue 让程序在引用被 GC 入队后执行后续清理或登记. 虚引用入队表示对象已进入对应的可达性处理阶段, 不表示对象内存已完成回收; 它不提供确定的回收时间, 也不能替代 Closeable.close(), use 或显式资源所有权. 对文件, socket, 数据库游标和 native 资源, 应在不再使用时主动关闭, 不要等待引用队列.

三, 并发

synchronized

• 对象头 Mark Word 记录锁状态, GC 年龄, hashCode 或指向锁记录 / monitor 的指针. synchronized 进入临界区时会围绕 Mark Word 做 CAS 或 monitor 竞争, 所以面试讲锁升级不能只背流程, 要能说清 “对象头里记录了什么”.
• 无锁: 对象未被线程持有; 第一次进入同步块时, 运行时会尝试在 Mark Word 中记录当前锁形态或把对象头复制到线程栈上的 Lock Record.
• 偏向锁: 面向 “同一线程反复进入同一把锁” 的场景, Mark Word 记录偏向线程 ID, 后续同线程进入几乎不需要 CAS. 出现其他线程竞争, 调用 hashCode() 等需要占用 Mark Word 的信息时, 可能触发偏向撤销或重偏向. 版本边界要说清: JDK 15 起偏向锁被废弃并默认关闭, JDK 18 之后 HotSpot 已移除相关实现, 新版本面试更应把它当历史优化理解.
• 轻量级锁: 多线程交替进入但竞争不激烈时, 线程在栈帧创建 Lock Record, 用 CAS 把对象 Mark Word 指向该记录; 失败后可能自旋, 希望持锁线程很快退出, 避免立即阻塞到内核态.
• 重量级锁: 竞争持续, 线程自旋失败或需要阻塞 / 唤醒时, 锁膨胀为 ObjectMonitor, 未抢到锁的线程进入阻塞队列, 由操作系统互斥量参与调度, 吞吐更稳定但上下文切换成本更高.
• 升级边界: 常见路径可概括为无锁 → 偏向锁 → 轻量级锁 → 重量级锁, 但这主要描述 HotSpot 早期到 JDK 14 默认配置下的优化路径; 锁可以膨胀, 退出同步块后不等于立刻恢复到最轻状态, 具体是否偏向, 是否自旋和阈值会受 JDK 版本与 JVM 参数影响.
• 修饰实例方法锁 this, 静态方法锁 Class, 代码块锁指定对象.

volatile

• 对同一变量的 volatile 写与后续读建立 happens-before, 提供可见性和必要的顺序约束; 不要机械解释成 “每次都立即刷主存”.
• 不保证原子性 (如 i++ 仍不安全).
• 经典用途: 双重检查锁单例的实例字段.

CAS 与 AQS

• CAS(Compare-And-Swap): 无锁原子操作, compareAndSwap(内存值, 期望值, 新值), 失败自旋重试. 底层是 CPU 指令.
• ABA 问题: 值从 A→B→A, CAS 误判没变. 用版本号 (AtomicStampedReference) 解决.
• AQS(AbstractQueuedSynchronizer): 用 volatile int state + CLH 队列实现的同步框架, ReentrantLock, CountDownLatch, Semaphore 都基于它.

ReentrantLock 与并发工具怎么选

ReentrantLock 是显式锁: 同一线程可重入, 并可选择公平锁, tryLock 超时 / 可中断获取, 多个 Condition 队列和诊断能力. synchronized 语法更短, 异常退出会自动释放 monitor, 适合简单且作用域固定的临界区. 两者都不应包住网络, 磁盘或长计算.

// 上下文片段:必须在 finally 中释放,避免异常路径永久占锁.
if (lock.tryLock(100, TimeUnit.MILLISECONDS)) {
    try {
        updateSharedState();
    } finally {
        lock.unlock();
    }
} else {
    reportContention();
}

锁竞争的症状是线程长期 BLOCKED/WAITING 或请求超时; 证据可来自线程 dump, 锁等待耗时和临界区日志; 定位持锁时间, 锁顺序和资源泄漏; 修复是缩短临界区, 固定锁顺序, 采用限时/可中断获取或改为消息传递; 验证用受控并发任务确认不会死锁且超时路径可见. 锁/线程池参数不能只套 “核数公式”, 应以任务 CPU/IO 比例, 队列等待, 拒绝次数和端到端延迟测量后调整.

ThreadLocal: 弱键不等于弱值

ThreadLocal 让每个线程在自己的 ThreadLocalMap 中保存一份变量. Map 的 entry 对 key (ThreadLocal 对象) 使用弱引用, 但 value 是强引用: 当 key 被 GC 后, entry 可能变成 key = null, value = largeObject. 在线程池的工作线程长期存活时, 若后续没有触发清理陈旧 entry, value 会继续被线程→ThreadLocalMap→entry 链路持有.

线程池工作线程(长期存活)
  -> ThreadLocalMap
       -> Entry(key 弱引用已清空,value 强引用仍在)
            -> 大对象 / Context / 缓冲区

上下文片段: 每次设置后都在同一任务的 finally 调用 remove(), 不要依赖弱引用或下一次 map 操作的机会性清理.

private static final ThreadLocal<StringBuilder> BUFFER = new ThreadLocal<>();

void handle(Request request) {
    try {
        BUFFER.set(new StringBuilder());
        process(request, BUFFER.get());
    } finally {
        BUFFER.remove();
    }
}

典型症状是线程池空闲后堆中仍保留请求对象或 Activity/Context; 证据是堆 dump 的引用链指向 worker thread 的 ThreadLocalMap; 定位为 set 没有同任务 remove, 或在线程池中存放了不该跨请求复用的数据; 修复为 try/finally remove(), 缩小 value, 改为显式参数或受控对象池; 验证是重复提交任务并在任务结束后重新抓取堆引用链. Android 中也要避免将 Activity, View 等短生命周期对象放进长生命周期线程的 ThreadLocal.

线程池 ThreadPoolExecutor

七个参数: corePoolSize(核心线程), maximumPoolSize(最大), keepAliveTime, unit, workQueue(任务队列), threadFactory, handler(拒绝策略).

执行流程: 核心线程未满 → 创建核心线程; 满了 → 入队; 队列满 → 创建非核心线程到 max; 再满 → 触发拒绝策略 (AbortPolicy 抛异常 / CallerRunsPolicy 调用者执行 / DiscardPolicy 丢弃 / DiscardOldestPolicy 丢最老).

队列选型决定 “先排队还是先开线程”: SynchronousQueue 无缓冲, 任务直接交接给工作线程; 核心线程全忙时 offer 立即失败, 立刻创建非核心线程 (上限 max), 适合短而频繁, 阻塞占比高的 IO 任务: 阻塞线程不占 CPU, 多一线即多一线并发. ArrayBlockingQueue/LinkedBlockingQueue 有界缓冲, 核心线程满后先入队等待再开新线程, 适合 CPU 密集或需要削峰排队, 平滑负载的场景; 队列越大峰值越稳, 但任务滞留越久, 内存越高. 结合 CPU/IO 分类: IO 密集偏 “弹性线程 + 无缓冲” 提升并发, CPU 密集偏 “核数级线程 + 有界队列” 减少上下文切换, 最终仍以队列等待, 拒绝次数和延迟测量为准.

线程数不能用 “CPU 核数 + 1” 或 “IO 核数 × 2” 当固定答案. 先写清目标: 允许的同时在途任务数, 任务 CPU 时间与阻塞时间, 外部服务并发配额, 内存能承受的队列容量, 以及过载时是快速失败, 调用方降速还是可安全丢弃. 以保守 core/max, 有界队列和与业务匹配的拒绝策略开始, 在压测或生产观测中记录队列等待, 活跃线程, 拒绝次数, CPU 利用率, 外部依赖饱和度和端到端 p95/p99 延迟; 再一次只调整一个变量并比较结果. 长阻塞 IO 还应优先考虑超时, 限流和异步客户端, 而不是无限增大线程或队列.

四, Java 内存模型 (JMM)

JMM 是并发语义模型, 不是 “堆, 栈, 方法区” 那张 JVM 运行时区域图. 它回答的是: 一个线程写入共享变量后, 另一个线程在什么条件下必须看到这次写入.

三个核心性质

• 原子性: 操作不可被线程切开观察. 单次引用读写通常是原子的, i++ 仍是读, 改, 写三步.
• 可见性: 一个线程的写入何时对另一个线程可见. volatile, 锁释放 / 获取和线程 join 等建立可见性关系.
• 有序性: 编译器和 CPU 可以重排没有同步约束的指令. volatile 和锁会提供必要的顺序保证.

happens-before 规则

面试至少能说出以下规则, 并说明它们可以传递:

1. 同一线程内, 前面的操作 happens-before 后面的操作.
2. 对同一把锁, unlock happens-before 后续 lock.
3. 对同一个 volatile 变量, 写 happens-before 后续读.
4. Thread.start() happens-before 新线程中的操作.
5. 线程中的全部操作 happens-before 另一个线程成功 join() 返回.
6. 若 A happens-before B 且 B happens-before C, 则 A happens-before C.

private val ready = AtomicBoolean(false)
private var payload: String? = null

fun publish(value: String) {
    payload = value
    ready.set(true)
}

fun read(): String? = if (ready.get()) payload else null

这里 ready 的 volatile 写读建立了顺序边界, 使读线程在观察到 true 后能看到之前对 payload 的写入. 业务代码更推荐直接发布不可变快照, 避免让多个可变字段组成隐含协议.

安全发布与 Android 边界

• 通过静态初始化, 锁, volatile 引用, 线程安全容器或协程状态流发布对象, 才能避免读到半初始化状态.
• final 字段在构造完成后有额外的初始化可见性保证, 但对象引用暴露后仍不能把可变成员当成线程安全.
• JMM 规定的是语言级可见性和顺序; Android ART, 主线程 Looper, Binder 和协程 Dispatcher 还会叠加各自的调度语义.

五, JVM 内存与 GC

内存区域

• 线程私有: 程序计数器, 虚拟机栈, 本地方法栈.
• 线程共享: 堆 (对象实例, GC 主战场), 方法区 / 元空间 (类信息, JDK8 后用本地内存).
• 注意 Android 用 ART/Dalvik 而非标准 JVM, 但内存模型概念相通.

GC

• 判活: 引用计数 (有循环引用问题) vs 可达性分析 (GC Roots, 主流).
• GC Roots: 虚拟机栈引用, 静态变量, 常量, JNI 引用等.
• 判活与泄漏定位对应: 泄漏对象未被回收, 是因为它仍能从 GC Roots 沿强引用链到达: 本质是被 static 缓存, 单例或长期存活线程等长生命周期对象强引用; 用堆 dump 沿引用链找根, 即可定位 “谁还持有它”.
• 回收算法: 标记 - 清除 (碎片), 复制 (浪费空间, 适合新生代), 标记 - 整理 (适合老年代).
• HotSpot 分代模型: 服务端 JVM 常按新生代/老年代理解, Eden + Survivor, Minor GC, Major/Full GC 是典型面试语言; 但比例 (如 8:1:1) 和具体算法不是 Java 语言规范, 会受 JVM 版本, 收集器和参数影响.
• HotSpot 回收器边界: Serial 适合小堆/单核或客户端场景; Parallel 关注吞吐; CMS 关注低停顿但有碎片和浮动垃圾问题, 已在 JDK 9 标记废弃, JDK 14 移除; G1 将堆划分为 Region, 兼顾可预测停顿; ZGC/Shenandoah 面向大堆低停顿. 回答时应说 “这些是 HotSpot 收集器”, 不要直接套到 Android.
• Android ART 区分: Android App 运行在 ART(早期为 Dalvik) 上, 不是标准 HotSpot Server VM. ART 也有堆, 线程栈, JNI 引用, 可达性分析和并发/分代等 GC 思路; Android Runtime 文档里的 CMS/CC 是 ART 自己的 GC plan, 不等同于 HotSpot CMS/G1/ZGC, 普通应用也不是通过 HotSpot collector 参数来选择它们. Android 面试更关注内存泄漏, 对象分配抖动, Bitmap/native 内存, GC pause 对掉帧的影响.
• 安全表述: 讲 JVM 基础时可用 HotSpot 解释 Serial/Parallel/G1/ZGC; 讲 Android 性能时应切到 ART 语境, 用 “ART 的具体 GC 策略随 Android 版本和设备实现演进” 这类条件措辞, 避免把服务端 JVM 参数经验当作移动端结论.

类加载

• 过程: 加载 → 验证 → 准备 → 解析 → 初始化.
• 父优先委派: 默认 ClassLoader.loadClass 通常先检查已加载类, 再请求父加载器, 父无法加载才尝试自身查找; 它帮助保持核心类唯一性, 但具体行为由 loadClass 实现决定.
• 主动引用触发初始化: new 实例, 读写静态字段 (非常量), 调用静态方法, 反射调用, 或初始化某个子类 (父类先初始化) 等场景, 会触发目标类的初始化阶段.
• 被动引用不触发: 引用 final static 编译期常量 (值在编译期内联进常量池), 通过子类引用父类的静态字段, 或用数组定义引用类, 都不会触发目标类初始化.
• 初始化阶段才真正执行: 准备阶段只给静态字段分配默认值 (零值), static 块与静态赋值在初始化阶段才运行. 与类不同, 初始化接口不会自动初始化其父接口 (除非父接口的非编译期常量静态字段被访问).

类加载器层级与术语

在现代 HotSpot 中常见层级为 Bootstrap ClassLoader (由 JVM 实现, 加载核心平台类)→ Platform ClassLoader (平台模块)→ Application/System ClassLoader (应用 classpath).旧资料中的 Extension ClassLoader 对应旧 JDK 机制, 不能直接套到模块化 JDK.

四种容易混淆的情形应分别表述:

• SPI/TCCL: 接口通常由较高层加载器加载; ServiceLoader 或框架可通过线程上下文类加载器 (TCCL) 发现子加载器可见的实现. 这是选择发现实现的加载器, 不等于该加载器普遍 child-first.
• 容器 child-first: 为隔离应用依赖, 某些容器的 WebAppClassLoader 对非受保护包可先尝试自身, 再委派父加载器; 核心 / 受保护包仍可能 parent-first. 规则由容器实现和配置决定.
• 自定义 loadClass: 只有覆写 loadClass/定义查找顺序的加载器才可能改变默认父优先顺序; 覆写时须处理已加载检查, 并发锁和受保护类, 不能笼统称所有插件都 “打破双亲委派”.
• Android dexElements: ART 的 BaseDexClassLoader/DexPathList 会按 elements 列表查找 dex 路径; 将补丁 element 前插改变的是该加载器自己的 path 查找优先级, 仍要与其 parent 委派, Android 版本, 加载时机和签名 / 兼容性限制分开讨论.

Android 的 ART/DexPathList 类加载与标准 HotSpot 层级不是同一实现. 谈热修复时应说明其依赖特定 Android 版本, 加载时机, 签名/兼容性与平台限制, 不能将 dexElements 前插说成通用 Java 机制或一律称为 “打破双亲委派”.

HotSpot, ART 与 desugaring 边界

JVM 是 Java 虚拟机规范及其实现类别, HotSpot 只是常见的 JVM 实现, 不能把 JVM 一律等同于 HotSpot. 传统 Java 工具链通常将 Java/Kotlin 源码编译为 class 字节码, HotSpot 以栈式字节码执行并结合解释器和 JIT; 其 JIT, GC 和对象布局结论不能直接等同于 Android Runtime.

Android 早期 Dalvik 以 DEX 为主要执行格式, 使用寄存器式指令集, 与 class 文件及栈式 JVM 字节码不同. Dalvik 早期以解释执行为主, 后续 Android 版本引入 JIT 等优化; 具体策略随系统版本演进, 不应把早期行为当作所有设备结论. ART 在 Android 5.0/API 21 起取代 Dalvik, 先以安装期 AOT 为主要策略, 后续版本逐步演进为结合运行时 JIT, profile 引导 AOT 和安装/空闲期编译的模式. ART 的 GC 和运行时实现也随 Android 版本, 设备和厂商演进, 因此 Android 面试应按目标 API 级别说明, 而不是套用 HotSpot 收集器或参数.

Android 还受 DEX, AOT/JIT profile, 设备系统版本和厂商实现影响. Java 语言/API 能否在 Android 使用还取决于 minSdk, desugaring, AGP/JDK 与 library desugaring 配置; 面试时分别说明 “Java/JMM 规范”, “JVM 实现如 HotSpot” 和 “Dalvik/ART 与 Android 工具链”. 最后核验: 2026-08-08.

高频面试题

Q1: HashMap 为什么线程不安全? ConcurrentHashMap 怎么优化? HashMap 并发 put 会丢数据, JDK7 扩容还会成环死循环. ConcurrentHashMap JDK8 用 CAS + synchronized 锁桶头, 只锁单个桶, 并发度高.

Q2: volatile 能保证原子性吗? 不能. 只保证可见性和有序性. i++ 是读 - 改 - 写三步, volatile 不能保证复合操作原子, 需用 Atomic 类或锁.

Q3: synchronized 锁升级过程? 先讲对象头 Mark Word: 它保存锁标志位, GC 年龄, hashCode 或指向 Lock Record/ObjectMonitor 的指针. 典型 HotSpot 路径是无锁 → 偏向锁 (同一线程反复进入, Mark Word 记录线程 ID)→ 轻量级锁 (栈上 Lock Record + CAS, 少量竞争时自旋)→ 重量级锁 (ObjectMonitor, 竞争线程阻塞/唤醒).边界是: 偏向锁在 JDK 15 起废弃并默认关闭, JDK 18 后 HotSpot 移除; 新版本里不要把偏向锁当成必经阶段. 锁膨胀后通常不会在退出同步块时立刻退回最轻状态, 具体策略受 JVM 版本和参数影响.

Q4: 线程池核心线程会被回收吗? 默认不会. 设置 allowCoreThreadTimeOut(true) 后核心线程空闲超时也回收.

Q5: 为什么用线程池? 核心线程数怎么定? 复用线程降低创建销毁开销, 控制并发并统一治理. 先按目标并发, 任务阻塞比例, 外部依赖配额, 队列内存预算和拒绝语义设保守初值, 再测量队列等待, 拒绝次数, CPU, 外部依赖饱和度及端到端 p95/p99 延迟, 逐项调整. CPU/IO 分类只是输入, 不能推出固定线程数公式.

Q6: 双亲委派的作用? 为什么 Android 热修复要打破它? 父优先的默认查找顺序有助于核心类唯一性和一致性. SPI/TCCL, 容器 child-first, 自定义 loadClass 和 Android dexElements 前插是不同机制: 后者改变的是 DexPathList 中 path element 的查找优先级, 并不自动等于绕过 parent 委派. 热修复方案必须按对应 Android 版本, 加载器, 加载时机, 签名和兼容性说明其实际查找链.

Q7: JMM 和 JVM 内存区域有什么区别? JMM 描述线程之间共享变量的可见性, 顺序和同步规则; JVM 内存区域描述程序计数器, 栈, 堆, 方法区等运行时数据位置. 一个是并发语义, 一个是运行时结构, 不能混为一谈.

Q8: 什么是 happens-before? volatile 为什么能安全发布引用? happens-before 表示前一个操作的结果对后一个操作可见, 且顺序受约束. 对同一 volatile 变量的写 happens-before 后续读, 因此先完成对象初始化再写入 volatile 引用, 读线程观察到该引用后也能看到初始化写入.

Q9: 为什么重写 equals 必须重写 hashCode? HashMap 先用 hash 定位桶, 再用 equals 判断逻辑相等. 如果两个相等对象的 hashCode 不同, 它们可能落入不同桶, 导致查找, 去重和 Set 语义失效.

Q10: 反射和编译期代码生成怎么选? 反射灵活, 但错误更晚暴露, 还会增加启动, 混淆和性能风险; KSP/APT 等代码生成在编译期校验并生成直接调用, 更适合高频和强类型路径. 小规模插件扩展或调试工具仍可使用反射.

易错点 / 追问

• 不要把 volatile 说成 “保证变量操作原子”; 它不能让 i++ 变成原子操作.
• 不要把 JMM 的主内存 / 工作内存抽象直接等同于物理 RAM 和 CPU Cache.
• 不要把 String 常量池, 堆和方法区的具体位置说成所有 JDK/ART 版本都固定不变.
• HashMap key, StateFlow state 和跨线程快照优先使用不可变对象, 降低发布后被修改的风险.
• Android 使用 ART, 不能把 HotSpot 的 GC 收集器参数和锁实现细节当成 Android 的稳定 API.

四大组件与基础

四大组件是 Android 的根基, 中级面试常深挖生命周期, 启动模式, 跨进程.

一, Activity

生命周期

onCreate → onStart → onResume →(运行)→ onPause → onStop → onDestroy; onRestart 用于从 onStop 返回.

关键场景:

• A 启动 B: A.onPause → B.onCreate → B.onStart → B.onResume → A.onStop(B 的 onResume 在 A 的 onStop 之前).
• 透明 / Dialog 主题的 B 覆盖 A: A 只 onPause 不 onStop.
• 横竖屏旋转: 默认销毁重建, 走完整生命周期 + onSaveInstanceState/onRestoreInstanceState; 配 configChanges 可避免重建只回调 onConfigurationChanged.

启动模式 (LaunchMode)

• standard: 默认, 每次新建实例, 入当前任务栈.
• singleTop: 栈顶复用, 栈顶是它则走 onNewIntent, 否则新建.(防通知重复打开)
• singleTask: 栈内唯一, 已存在则复用并清除其上的 Activity (clearTop), 走 onNewIntent.(主页 / 首页)
• singleInstance: 独占一个任务栈.(来电, 闹钟)

taskAffinity 指定任务栈归属; Intent flag (FLAG_ACTIVITY_NEW_TASK 等) 可动态控制.

生命周期与任务栈推演

上下文片段: 以下日志放在同一应用的 MainActivity(A) 和 DetailActivity(B) 各生命周期回调中; 省略 Manifest 声明和 Log import. 点击 A 的按钮启动 B, 预期日志顺序为 A.onPause -> B.onCreate -> B.onStart -> B.onResume -> A.onStop. 按返回键后, 预期 B 依次 onPause/onStop/onDestroy, A 依次 onRestart/onStart/onResume.

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
        findViewById<View>(R.id.open_detail).setOnClickListener {
            startActivity(Intent(this, DetailActivity::class.java))
        }
    }
}

任务栈初始为 [A], A 启动 standard 模式的 B 后为 [A, B]; 从 B 按 Back 只弹出 B, 恢复 A. 若 B 已在栈内且以 singleTask 启动, 例如栈为 [A, B, C], 再次启动 B 后会清除 C, 变为 [A, B] 并回调 B 的 onNewIntent(). 这是针对该模式的推演, 不应把它外推到所有 flag, 跨 task 或厂商定制场景.

二, Fragment

• 实例与 View 是两套生命周期: Fragment 实例通常经历 onAttach → onCreate → onCreateView → onViewCreated → onStart → onResume; 离开前台时先 onPause → onStop. View 被销毁时走 onDestroyView, Fragment 实例最终被移除或宿主销毁时才走 onDestroy → onDetach.
• onDestroyView() 是分界点: Fragment 仍可能留在 FragmentManager 或返回栈中, 但其 View 树, View Binding 和所有仅服务于界面的引用都已失效. 在此处置空 _binding, 取消对旧 View 的回调, 不要在实例字段中持有 View.
• 返回栈与重建: 执行 replace(...).addToBackStack(...) 后, 被覆盖 Fragment 的 View 通常销毁而实例保留; 返回时实例可复用但会重新执行 onCreateView/onViewCreated. 配置变更或进程重建会由 FragmentManager 恢复 Fragment, 应把可恢复 UI 状态放在 ViewModel/SavedStateHandle, 而非假设旧实例或旧 View 仍存在.
• 观察 UI 状态: 涉及 View 的 LiveData 观察, Flow 收集和 Adapter 绑定使用 viewLifecycleOwner; 这样收集会在 View 销毁时停止, 在新 View 创建后按其生命周期恢复. 不依赖 View 的 Fragment 级工作才使用 Fragment 自身的 lifecycle.
• commit vs commitNow vs commitAllowingStateLoss: commit 异步; commitNow 同步; 前两者在 onSaveInstanceState 后调用会抛 IllegalStateException, allowingStateLoss 容忍但可能丢状态.
• 现代用 FragmentStateAdapter + ViewPager2 替代旧懒加载.
• 为什么用 Fragment 而非多 Activity: 轻量, 复用, 共享 ViewModel, 单 Activity 架构配合 Navigation.

Activity / Fragment 通信: 先确定状态所有权

选择前先回答 “这是单向结果还是共享状态, 结果应留在哪个返回栈 entry”. Fragment Result 以同一 key 正常交付后会清除; 若出现重复事件, 通常应检查发送方是否再次调用 setFragmentResult, 是否重注册监听器, 以及业务是否把一次性事件建模成可重复消费的状态. 例如详情页编辑完成可写入前一个 SavedStateHandle, 前页消费后清除该键; 跨多个同级页面的持续筛选条件则归共享 ViewModel 管理. 以上是 API 归属示意, 仍需结合页面销毁和进程重建路径验证.

Fragment 懒加载的边界

旧式 “根据可见回调才创建或请求数据” 容易与 FragmentStateAdapter, 返回栈和 onDestroyView() 交错: Fragment 可已创建但 View 不存在, 或不可见页面仍持有请求结果. 现代做法是以 View 生命周期收集 UI state, 由数据层按真正需求惰性加载, 取消或缓存; 可见性只影响渲染或触发意图, 不应成为唯一的数据正确性条件. 列表布局与 View.post 的时机区别见 UI 体系 - View 与自定义 View.

三, Service

• 启动方式: startService(独立运行, 需手动 stopSelf/stopService) vs bindService(提供绑定通信; 当没有启动状态且最后一个客户端解绑时, 系统可销毁它). 同一 Service 也可同时被启动和绑定, 此时解绑不会停止其启动状态.
• 前台服务: 必须 startForeground 显示通知 (Android 8+ 后台限制), 用于音乐, 定位, 下载. Android 14+ 还有前台服务类型限制.
• IntentService 已废弃: 用 WorkManager 或协程替代后台任务.
• Service 不是线程: 默认运行在主线程, 耗时操作仍需开子线程, 否则 ANR.

IntentService: 历史串行后台组件

1. 历史原理: IntentService 在内部工作线程按顺序处理每个 Intent, 任务完成后可自行停止, 用来避免普通 Service 在主线程执行耗时工作.
2. 限制与状态: 平台 android.app.IntentService 自 Android 11/API 30 废弃; 它不提供任务约束, 可靠重试或现代后台执行保证, Android 8.0 及以上的后台执行限制也使其不适合新任务. 新项目不应继续采用.
3. 现代替代: 可延迟且需保证执行的工作使用 WorkManager; 用户明确感知, 必须持续运行的工作使用声明正确类型并展示通知的前台服务; 与页面生命周期绑定的短任务使用 ViewModel 作用域协程. 线程协作原语见 多线程并发专题.

回到主线程: runOnUiThread 不是生命周期保护

Activity.runOnUiThread { ... } 会在非主线程时把代码投递到主线程, 调用方已在主线程时可直接执行. 它只解决线程亲和性, 不保证 Activity, Fragment View 或业务请求仍有效: 回调排队期间页面可能销毁. 页面逻辑优先由 ViewModel 暴露可恢复的 UI state, 用生命周期感知收集协程渲染; 临时 View 操作须先确认 View 生命周期有效. runOnUiThread 可用于遗留回调的窄桥接, 不应成为异步架构.

绑定 Service: 客户端与服务端的最小闭环

上下文片段: 将 Service 声明在同一应用 Manifest 中, Activity 在可见期间绑定. 此示例只演示同进程 Binder 通信, 不是跨进程 AIDL 示例. 调用 nextCount() 两次, 预期依次得到 1, 2; 离开页面会解绑.

class CounterService : Service() {
    private var count = 0
    inner class LocalBinder : Binder() { fun nextCount(): Int = ++count }
    override fun onBind(intent: Intent): IBinder = LocalBinder()
}

class CounterActivity : AppCompatActivity() {
    private var binder: CounterService.LocalBinder? = null
    private var bound = false // bindService() 已成功注册该 ServiceConnection
    private var connected = false
    private val connection = object : ServiceConnection {
        override fun onServiceConnected(name: ComponentName, service: IBinder) { binder = service as CounterService.LocalBinder; connected = true }
        override fun onServiceDisconnected(name: ComponentName) { binder = null; connected = false }
    }
    override fun onStart() { super.onStart(); bound = bindService(Intent(this, CounterService::class.java), connection, BIND_AUTO_CREATE) }
    override fun onStop() { if (bound) { unbindService(connection); bound = false }; binder = null; connected = false; super.onStop() }
}

bound 表示 bindService() 返回成功, 因此必须配对解绑; connected 表示 Binder 已通过 onServiceConnected() 到达, 只有此时才可调用 binder. 存在 “已绑定但尚未连接” 的竞态窗口: 页面可能在回调到达前进入 onStop(), 仍要按 bound 解绑并清理本地引用. onServiceDisconnected() 表示连接意外断开 (例如承载 Service 的进程被杀), 正常调用 unbindService() 不会因此回调.

四, BroadcastReceiver

• 注册方式:
  • 静态注册 (Manifest): 适合系统或跨应用广播; Android 8.0 起对很多隐式广播做了限制, 普通应用不要依赖静态注册来长期唤醒进程.
  • 动态注册 (registerReceiver): 跟随 Activity/Fragment/Service 生命周期, 常在 onStart/onResume 注册, onStop/onPause 反注册, 用于只在界面可见或组件存活时接收.
• 分发流程: sendBroadcast/sendOrderedBroadcast → ActivityManager/系统广播队列匹配 IntentFilter → 找到静态/动态 Receiver → 目标进程已在则直接回调,未启动且允许则拉起进程 → 主线程调用 onReceive.
• IntentFilter 匹配: action 必须匹配; filter 声明 category 时, Intent 中的每个 category 都必须被 filter 包含; data 的 URI, MIME type, scheme/host/path 还须满足声明. 不要以为只写同一个 action 就必然接收, 也不要用宽泛 data 暴露未校验输入.
• 类型边界:
  • 普通广播: 异步分发, 多个 Receiver 接收顺序不应作为业务依赖.
  • 有序广播: 按优先级依次分发, 前一个 Receiver 可通过 setResult* 改结果, 也可在允许的场景中 abortBroadcast() 终止后续接收; 因此更像一条责任链.

系统广播与 LocalBroadcastManager 的边界

LocalBroadcastManager 1.1.0 已完全废弃, 新代码不应使用. 应用内持续状态优先由 Repository 暴露 StateFlow/LiveData, 短暂事件可用作用域明确的 SharedFlow 或显式回调; 观察者仍应绑定恰当生命周期, 不把 “本地” 误当成完整的安全模型.

粘性广播: 旧状态快照不是状态流

平台粘性广播 API 仍存在, 但多数应用不应发送或依赖它, 不应杜撰统一的废弃版本. 粘性广播会保存最后一次 Intent, 之后注册的接收者可能立即拿到该旧值; 这会带来数据陈旧, 来源与时序难以判断的问题. 若广播可被外部接收或伪造, 还会扩大敏感数据泄露和错误状态注入的风险. 平台保留的少数系统状态场景应按其文档处理; 应用自己的状态以 Repository + StateFlow/LiveData 等可追踪, 可建模的状态流保存和观察, 而非用 sticky Intent 充当状态仓库.

class BatteryReceiver : BroadcastReceiver() {
    override fun onReceive(context: Context, intent: Intent) {
        // onReceive 运行在主线程,只做轻量解析;耗时任务交给 WorkManager/协程/Service
        val level = intent.getIntExtra(BatteryManager.EXTRA_LEVEL, -1)
        Log.d("BatteryReceiver", "level=$level")
    }
}

private val receiver = BatteryReceiver()

override fun onStart() {
    super.onStart()
    registerReceiver(receiver, IntentFilter(Intent.ACTION_BATTERY_CHANGED))
}

override fun onStop() {
    unregisterReceiver(receiver)
    super.onStop()
}

常见错误:

• 在 onReceive 中做网络 / 数据库等耗时操作, 导致主线程卡顿甚至 ANR; 需要异步任务时用 goAsync() 争取短暂收尾, 或转交 WorkManager / 前台 Service.
• 动态注册后忘记反注册, 导致组件泄漏或重复收到广播.
• 把广播当作应用内事件总线, 导致来源不清, 生命周期难控; 中级面试更推荐说明 “跨组件 / 跨应用通知可以用广播, 应用内状态流优先用 Flow”.
• 忽略 Android 8.0+ 隐式广播限制, 把 Manifest 静态注册当成稳定后台唤醒手段.

面试答题结构: 先说 “注册方式与生命周期”→ 再说 “普通 / 有序广播分发差异”→ 补 “8.0+ 限制与现代替代”→ 最后强调 “onReceive 主线程, 轻量处理, 及时反注册”.

五, ContentProvider

• 定位: 跨进程数据共享的标准组件, 用 content://authority/path/id 形式的 URI 寻址, 对外暴露 query/insert/update/delete/openFile 等接口. 系统通讯录, 媒体库就是典型例子.
• 对象关系:
  • ContentResolver: 调用方入口, 不直接依赖 Provider 实现类.
  • ContentProvider: 被调用方组件, 负责权限校验, URI 分发, 数据读写.
  • UriMatcher: 把不同 URI path 映射到不同业务分支, 避免手写大量字符串判断.
• 跨进程调用流: 调用方 ContentResolver.query(uri) → 系统根据 authority 找到目标 Provider → 必要时启动目标进程并创建 Provider → 通过 Binder 进入 Provider 的 query/insert/update/delete → Provider 访问 SQLite/文件/内存数据 → Cursor/结果返回调用方.

class UserProvider : ContentProvider() {
    private val matcher = UriMatcher(UriMatcher.NO_MATCH).apply {
        addURI("com.example.user", "users", 1)
        addURI("com.example.user", "users/#", 2)
    }

    override fun query(
        uri: Uri,
        projection: Array<out String>?,
        selection: String?,
        selectionArgs: Array<out String>?,
        sortOrder: String?,
    ): Cursor? = when (matcher.match(uri)) {
        1 -> queryAllUsers()
        2 -> queryUser(uri.lastPathSegment!!.toLong())
        else -> throw IllegalArgumentException("Unknown uri: $uri")
    }
}

// 调用方只依赖 URI + ContentResolver
val cursor = context.contentResolver.query(
    Uri.parse("content://com.example.user/users/42"),
    null,
    null,
    null,
    null,
)

• 为什么能早于 Application 初始化: 系统在创建应用进程时会先安装并创建该进程声明的 ContentProvider, 然后再进入 Application.onCreate(). Jetpack App Startup 利用这个时机做库初始化, 但现代工程应收敛自动初始化, 避免启动链路不可见, 冷启动变慢.
• 权限与边界: 对外暴露 Provider 要配置读写权限, exported, URI grant 或签名级权限; 内部初始化 Provider 不应暴露敏感数据. Provider 方法可能被跨进程并发调用, 数据库访问要考虑线程安全和事务.

ContentObserver 订阅的是 URI 变化

ContentResolver.registerContentObserver(uri, notifyForDescendants, observer) 订阅的是某个 Provider URI 的数据变更通知, Provider 在数据成功修改后通过 notifyChange(uri, null) 告知观察者. 它不读取数据, 也不替代 ContentResolver.query()/insert()/update()/delete() 的访问链路; 收到通知后, 调用方通常重新查询或让 Repository 刷新状态. 观察者必须按注册者生命周期注销, 跨进程调用仍需遵循 Provider 的权限和数据一致性约束.

常见错误:

• 只记 “CRUD + URI”, 说不清 ContentResolver → authority → Provider → Binder 的调用链.
• 把 Provider 当普通单例初始化器滥用, 导致 SDK 隐式启动, 冷启动耗时难定位.
• 忽略 exported/permission/grantUriPermission, 把内部数据暴露给其他应用.

面试答题结构: 先解释 “URI + ContentResolver/Provider 解耦”→ 再画出 “跨进程 Binder 调用链”→ 举 “通讯录/媒体库/App Startup” 例子 → 最后补 “权限, 并发, 启动成本” 的坑.

六, 序列化与 Context

• Serializable vs Parcelable: Serializable 是 Java 反射序列化, 慢, 产生大量临时对象; Parcelable 是 Android 专为内存 / IPC 设计, 快但代码繁琐 (Kotlin 用 @Parcelize 自动生成).跨进程 / Intent 传对象用 Parcelable.
• Context 类型: Application Context (全局, 生命周期最长, 不能用于 UI/Dialog), Activity Context (带主题, 可弹窗, 注意泄漏). getApplicationContext 用于单例避免持有 Activity.

进阶补充: 现代组件 API 与版本限制

Activity Result API

startActivityForResult 已不推荐. Activity Result API 把启动和结果回调绑定到 lifecycle, 避免配置变更后的回调丢失.

运行时权限

Android 6.0 后危险权限运行时申请; Android 13 引入通知权限; Android 14 对前台服务类型和后台启动有更多限制. 面试要按版本讲, 不要只背一套老流程.

Fragment 返回栈与状态丢失

commit() 是异步; commitNow() 立即执行但不能加入 back stack. onSaveInstanceState 后再提交可能 state loss. setMaxLifecycle 常用于 ViewPager2 控制页面生命周期.

状态丢失时间线: 系统为恢复保存 Activity 状态 -> 异步网络回调到达 -> 回调试图 commit() 新 Fragment -> 进程若随后被杀, 已保存状态没有这笔事务 -> 恢复后的界面与用户最后看到的界面不一致. 因此不要把 “ 捕获异常后改用 commitAllowingStateLoss()“ 当默认修复. 症状是 Can not perform this action after onSaveInstanceState; 证据是生命周期日志与事务提交时机; 定位到晚到回调后, 应将结果放进 ViewModel/UI state, 在 RESUMED 时由 UI 渲染可恢复状态; 最后旋转, 后台恢复与返回栈均需验证.

前台 Service 类型

前台服务必须有用户可见通知, 新版本要求声明类型, 如 location, mediaPlayback, dataSync. 不能把前台服务当万能保活工具.

追问: 为什么 Fragment 会出现状态丢失? 因为系统已保存 Activity 状态后, 再提交 Fragment 事务无法保证恢复一致性.

版本化平台规则矩阵

后台启动 Activity, 广播接收, 前台服务, 通知权限和 android:exported 都是版本 /targetSdk 敏感规则. 设计与面试回答按 “OS/API, targetSdk 条件, 组件类型, 是否用户可见, 允许的豁免, 商店政策” 记录矩阵, 不背一个跨版本绝对结论. Manifest 暴露组件遵循最小权限, exported 组件还需权限, 输入验证和调用方鉴权. 具体规则统一回到 Android 版本适配.

高频面试题

Q1: singleTask 和 singleInstance 区别? singleTask 在所属任务栈内唯一, 可与其他 Activity 共栈; singleInstance 独占一个任务栈, 栈内只有它一个.

Q2: 横竖屏切换 Activity 生命周期? 如何保存数据? 默认销毁重建 (onPause→onStop→onDestroy→onCreate→…).用 onSaveInstanceState 保存临时数据, 或用 ViewModel (配置变更时存活) 保存. 配 android:configChanges 可避免重建.

Q3: onSaveInstanceState 何时调用? 和 onPause 顺序? 在 Activity 可能被系统销毁前调用 (如旋转, 内存不足, 切后台). Android P 后在 onStop 之后调用. 正常返回键退出不调用 (因为是用户主动销毁).

Q4: Serializable 和 Parcelable 怎么选? 内存传递, IPC, 性能敏感场景用 Parcelable; 持久化到磁盘或简单场景可用 Serializable. Kotlin 用 @Parcelize 减少模板代码.

Q5: 为什么不能用 Application Context 弹 Dialog? Dialog 需要 Activity 的主题和 Window token, Application Context 没有, 会抛 BadTokenException.

Q6: Service 和 Thread 区别? Service 能做耗时操作吗? Service 是组件, 运行在主线程, 不是线程; 它的意义是 “后台运行, 可被系统管理”: 承载它的进程会被系统判为更重要而更不易被杀, 但线程调度优先级不变. 耗时操作必须在 Service 内另开线程, 否则 ANR.

Q7: 8.0 之后后台限制有哪些? 后台 Service 受限 (需前台服务 + 通知), 隐式广播大量禁止静态注册, 后台定位受限. 推荐用 WorkManager 处理可延迟的后台任务.

UI 体系 - View 与自定义 View ★

你的重点短板. View 体系是应用开发的日常, 绘制流程, 事件分发是中级面试必考的硬核题.

一, View 绘制三大流程

从 ViewRootImpl.performTraversals() 触发, 依次走:

1. measure (测量): 确定 View 的宽高.
2. layout (布局): 确定 View 在父容器中的位置.
3. draw (绘制): 把 View 画到画布上.

measure 与 MeasureSpec

MeasureSpec 是 32 位 int: 高 2 位是模式, 低 30 位是尺寸. 三种模式:

• EXACTLY: 精确值 (match_parent 或具体 dp).
• AT_MOST: 最大不超过 (wrap_content).
• UNSPECIFIED: 不限制 (ScrollView 子 View).

父 View 的 MeasureSpec + 子 View 的 LayoutParams 共同决定子 View 的 MeasureSpec. 自定义 View 必须处理 wrap_content: 否则 AT_MOST 模式下表现得和 match_parent 一样 (因为默认用了父给的最大尺寸), 需在 onMeasure 里给 wrap_content 一个默认尺寸.

推演 getDefaultSize/resolveSize: getDefaultSize(size, spec) 只有 UNSPECIFIED 才回退到传入的 size (建议尺寸), EXACTLY/AT_MOST 一律返回 specSize, 这就是 “不处理 wrap_content 就等同 match_parent” 的来源. resolveSize(size, spec) 与之类似但更精细: EXACTLY 取 specSize, AT_MOST 取 min(size, specSize), UNSPECIFIED 返回 size, 自定义 View 常用来给 wrap_content 一个期望默认值. View.onMeasure 默认实现即 setMeasuredDimension(getDefaultSize(suggestedMinimumWidth, widthSpec), getDefaultSize(suggestedMinimumHeight, heightSpec)), 其中 suggestedMinimum 来自背景与 minWidth/minHeight; 所以覆盖 onMeasure 的常规套路是: 先按子 View 算出内容尺寸, 再用 resolveSize 决定最终测量值.

layout

onLayout 中调用子 View 的 layout(l, t, r, b) 确定位置. View 的 getWidth/getHeight(布局后的实际尺寸) 与 getMeasuredWidth/Height(测量尺寸) 区别: 正常情况相等, 但可被 layout 强行改变.

draw 顺序

1. 绘制背景 drawBackground
2. 绘制内容 onDraw
3. 绘制子 View dispatchDraw
4. 绘制前景 / 滚动条 onDrawForeground

二, 事件分发机制

三个核心方法, 贯穿 Activity → ViewGroup → View:

• dispatchTouchEvent: 分发事件, 返回 true 表示消费.
• onInterceptTouchEvent:仅 ViewGroup 有, 返回 true 拦截, 交给自己的 onTouchEvent.
• onTouchEvent: 处理事件, 返回 true 表示消费.

传递规律 (U 型): 事件从 Activity 向下分发 (dispatch), ViewGroup 可在 intercept 拦截; 子 View 不消费则向上回传 (onTouchEvent 冒泡).

关键规则:

• 一旦某 View 在 ACTION_DOWN 返回 true 消费了事件, 后续 MOVE/UP 都直接交给它 (形成事件序列).
• 若 DOWN 没被消费, 后续事件不再传给它.
• requestDisallowInterceptTouchEvent(true): 子 View 请求父不要拦截 (滑动冲突解决用).

必考反例链: 子 View 已消费 DOWN 后, 父 ViewGroup 在某个 MOVE 的 onInterceptTouchEvent 返回 true, 父会先向子 View 补发一个 ACTION_CANCEL, 子 View 收到后应复位按下状态, 否则会 “卡在按下态”; 之后的 MOVE/UP 全部交给父, 子 View 收不到. 若 DOWN 一开始就被父拦截, 子 View 从头到尾收不到该序列, 也不会收到 CANCEL. getX/getRawX 坐标系差异: getX 是相对父容器的坐标 (含自身 left 偏移), getRawX 是相对屏幕的原始坐标; 跨容器比较滑动方向或手势位置时应优先用 raw 值, 否则父容器移动后 getX 已不反映真实屏幕位移.

三, 滑动冲突解决

当内外层都能滑动 (如 ViewPager 嵌 ListView, 横滑嵌竖滑), 需解决冲突:

• 外部拦截法 (推荐):重写父容器 onInterceptTouchEvent, 按需要判断是否拦截. DOWN 不拦截 (否则子 View 收不到), MOVE 时根据方向决定.
• 内部拦截法: 父容器默认拦截所有, 子 View 通过 requestDisallowInterceptTouchEvent 动态控制父是否拦截, 配合父重写 onInterceptTouchEvent 对 DOWN 不拦截.

判断依据: 水平 / 垂直距离比较, 速度, 业务规则.

四, 自定义 View

三种方式:

1. 继承现有 View(如 TextView):扩展功能.
2. 继承 View: 完全自绘, 重写 onMeasure (处理 wrap_content)+ onDraw.
3. 继承 ViewGroup: 自定义布局, 重写 onMeasure (测量子 View)+ onLayout (摆放子 View).

要点:

• 自定义属性: attrs.xml 定义 → obtainStyledAttributes 读取.
• 支持 padding (onDraw 中考虑 paddingLeft 等).
• 避免在 onDraw 中 new 对象 (每帧调用, 造成内存抖动), Paint 等提前创建.
• 状态保存: 重写 onSaveInstanceState/onRestoreInstanceState.

五, invalidate vs requestLayout

• invalidate(): 触发重绘 (只走 draw), 不重新测量布局. UI 内容变了用它. 必须在主线程; 子线程用 postInvalidate().
• requestLayout(): 触发重新 measure + layout (不一定 draw), 尺寸 / 位置变了用它.
• 硬件加速: GPU 渲染, 部分 Canvas API 不支持 (老版本), 可按 View 关闭.

六, 动画, 布局与旧列表机制

动画类型: 选错会让视觉状态和交互状态分离

插值器决定时间进度如何从 0 到 1, 例如先快后慢; 估值器根据该进度计算属性值, 例如颜色的 ARGB 插值. 把两者混为一谈会导致无法解释自定义动画的速度曲线和数值计算.

容器与列表的成本边界

ListView 的 convertView 和 ViewHolder 是历史上的行复用优化: 复用旧行并缓存子 View 查找结果. 它受单一布局, 局部更新, 动画和预取能力限制. 现代列表使用 RecyclerView 与 LayoutManager, DiffUtil 和 Recycler; 迁移不等于在 onBindViewHolder 做同步 IO. 更多复用链路见本章的 RecyclerView 复用与预取.

ListView 优化的完整回答

面试中可以按 “复用, 绑定, 数据更新, 滑动状态” 回答:

• 多 viewType 复用: getViewTypeCount() 返回布局类型总数, getItemViewType(position) 返回稳定且合法的类型下标. convertView 只能在同一 viewType 内复用; 不同类型的行不能强转或混用. 类型数量过多会分散复用池, 但把结构不同的行硬塞成一种类型更容易引入错位和状态残留.
• ViewHolder: 首次 inflate 时创建 Holder, 用 setTag 保存子 View 引用; 后续从 tag 取引用, 避免每次 findViewById. 每次 bind 都要显式覆盖文本, 可见性, 选中态和监听器等可变状态, 否则复用后会留下上一行的显示结果.
• bind 热路径: getView() 会在滚动时高频执行, 不要在其中做磁盘 / 网络 IO, 大图解码, 重复资源解析或无必要的对象分配. 预先准备轻量模型, 缓存可复用资源, 把昂贵工作移到后台; 主线程 bind 只做必要的 UI 写入. 优化目标不是 “完全不分配”, 而是避免随滚动频率增长的分配和同步阻塞.
• 图片生命周期: 图片请求应绑定到行或 ImageView 的当前身份, bind 前先设置占位图并取消或替换旧请求; 回调落地前校验目标仍对应同一 item/key, 避免图片回写到已复用的另一行. 在 adapter/listener 生命周期结束时取消请求或清理观察者, 避免泄漏和无效回调. 具体图片库的缓存与取消 API 以其生命周期约定为准.
• 分页与增量更新: 不要一次性把无限数据全部放进内存. 按滚动位置和加载状态触发下一页, 防抖并避免重复请求; 加载成功后在主线程追加快照并调用合适的更新通知. 同时处理 loading, empty, error, 重试和末页状态, 不要在 getView() 里直接发起不可控的请求.
• 滑动监听误区: OnScrollListener 的回调发生在滚动 / 布局过程中, 不能把 “接近末尾” 当成只触发一次的信号. 需要用 loading 标志, 当前数据量或请求 key 去重, 并区分 SCROLL_STATE_IDLE 与正在滚动; 不要在每次 onScroll() 中全量扫描, 刷新 adapter 或触发同步 IO. firstVisibleItem + visibleItemCount >= totalItemCount - threshold 只是触发条件, 不是分页完成条件.

迁移到 RecyclerView 的边界: 新功能通常优先 RecyclerView, 当需要多类型, 局部更新 / 动画, 横向或网格布局, 预取, 稳定 ID 与 DiffUtil 时迁移收益明显. 仅为修复单个旧页面的小问题不必机械迁移; 迁移会带来 ViewHolder, LayoutManager, item 装饰 / 动画, 无障碍和状态恢复等适配工作. RecyclerView 也不能自动解决 bind 热路径 IO, 图片错位或分页重复请求, 这些约束仍然成立.

自定义 LayoutManager 至少负责: 计算可见范围并摆放 child, 响应滚动距离, 回收离屏 View 并向 Recycler 取 View, 保存和恢复滚动位置. 下面只展示职责骨架, 不是可直接用于生产的完整实现:

// 示意代码: 未处理测量,预测布局,动画,边界与状态恢复细节.
class VerticalLayoutManager : RecyclerView.LayoutManager() {
    override fun generateDefaultLayoutParams() = RecyclerView.LayoutParams(
        ViewGroup.LayoutParams.MATCH_PARENT,
        ViewGroup.LayoutParams.WRAP_CONTENT,
    )

    override fun onLayoutChildren(recycler: RecyclerView.Recycler, state: RecyclerView.State) {
        detachAndScrapAttachedViews(recycler)
        // 依次 obtain/bind/layout 可见 item, 并记录首个 position 与 offset.
    }
}

scrollVerticallyBy(dy, recycler, state) 不是必须实现, 但不实现列表无法手动滚动 (只能显示首屏): 实现里算出实际滚动量, 用 offsetChildrenVertical(-dy) 移动 child, 回收移出屏幕的 View, 返回实际消费的距离. canScrollVertically() 同理返回能否继续滚动, 影响嵌套滚动和事件消费判断.

RemoteViews: 受限的跨进程 View 描述

通知和 App Widget 不能把任意 View 实例跨进程传给宿主. RemoteViews 传递的是受支持布局和操作的描述, 由宿主进程 inflate 并应用, 因而只支持有限 View 类型和方法. 它适合通知与小部件, 不适合自定义 View, 任意事件逻辑或频繁复杂 UI 更新.

七, 布局时机, 文本与渲染表面

View.post 与布局时机

获取 View 宽高可以用下面的矩阵回答, 关键是区分 “本轮是否已经 layout” 和 “是否要等待一次布局回调”:

手动 measure 更适合脱离 View 树测量可独立构造的内容, 例如已知父约束的自定义布局预计算. 普通页面不要把它当作 “提前拿到最终宽高” 的捷径; 最终 width 仍由后续 layout 决定.

View.post 历史上 “经常” 能取到宽高, 是因为 View attach 后 Runnable 会投递到所属主线程消息队列, 通常排在当前 traversal 的 measure/layout 之后执行. 这只是队列顺序带来的常见结果, 不是 Android 对布局完成的保证: 首次 attach, requestLayout(), 异步数据更新或队列中其他任务都可能改变先后关系, 也可能读到旧尺寸或 0. 需要等待一次布局时推荐 doOnLayout; 需要连续观察变化时使用并正确移除 OnLayoutChangeListener.

资源尺寸 API 的差别也在取整时显现: getDimension() 返回按 density 换算的浮点像素值; getDimensionPixelSize() 四舍五入为整数且非零尺寸会至少为 1px; getDimensionPixelOffset() 向 0 截断. 绘制可保留浮点值, 像素边界或 LayoutParams 通常需要选择明确的整数取整策略.

StaticLayout 用于在 Canvas 上测量并绘制多行文本, 包含换行, 宽度, 对齐和行距处理; 不能只用 Paint.measureText() 计算整段文本宽度. 长文本应缓存可复用布局, 文本或可用宽度变化后才重建, 否则在 onDraw() 重建会造成抖动.

LayoutInflater 解析 XML, 根据标签创建 View 并应用属性. <merge> 省去多余根节点, 但要求提供且 attach 到实际 root; attachToRoot = true 会立即加入 root, false 则只创建供调用方稍后添加. View.inflate() 是常用便利入口, 仍应理解它委托给 Inflater. 错误传入 root 或 attach 标志常导致 LayoutParams 丢失, 重复添加或 ClassCastException.

SurfaceView 与 TextureView

两者都跨越普通 Canvas 绘制边界. 按变换需求和实测帧性能选择, 不能仅因 “TextureView 可变换” 就用于所有视频场景.

八, 位移, 拖动与屏幕适配

layout() 改变 View 的实际边界和命中区域, 常用于父容器摆放子 View; translationX/Y 保留 layout 边界但改变渲染与通常的命中位置, 适合属性动画; scrollTo/scrollBy 改变容器内容的绘制偏移, 不改变子 View 的 layout 坐标; 动画是随时间改变上述属性的过程. 错误地用 layout 做每帧动画会触发更多布局, 用 translation 表达永久结构位置又会使读取坐标和状态恢复混乱.

两个嵌套 ViewPager 的冲突可按手势协商: DOWN 先让子页面收到事件, MOVE 比较 abs(dx) 与 abs(dy); 垂直手势交给可纵向滚动的父容器, 水平手势由子 pager 处理, 到子 pager 的首尾页且继续向外滑时允许父 pager 拦截. 阈值应基于 touch slop, 并处理多指, CANCEL 与 RTL 方向; 单凭第一次 MOVE 的固定方向会造成抖动.

ViewDragHelper 将复杂拖动拆为 tryCaptureView() 决定可捕获对象, clampViewPositionHorizontal/Vertical() 限制边界, onViewReleased() 决定释放后的停靠或回弹, 再在容器 computeScroll() 中持续推进. 它不是自动解决嵌套手势和无障碍的完整组件, 仍需协调父拦截和状态恢复.

适配清单

• 使用 dp 表示几何尺寸, sp 表示文字并尊重用户字体缩放; 不把固定 px 或关闭 font scale 当适配方案.
• 用限定符资源和可伸缩约束处理宽度, 高度, 语言和方向差异, 避免以单一屏幕尺寸硬编码 margin.
• 通过 WindowInsets 处理 system bars, 屏幕缺口, 手势区和 IME, 让输入框与列表内容避让而非猜测状态栏高度.
• 在折叠屏和大屏上根据窗口尺寸类别, 折叠状态和多窗口重新组织布局, 不假定横屏只是手机旋转.
• 在实际字体倍率, RTL, 分屏, 键盘展开和横竖屏下检查文本截断, 触摸目标与焦点顺序.

完整自定义 View: 可选评分条

可运行示例 (工程内): 在 Android App 中新增 res/values/attrs.xml, 以下 Kotlin 类和布局引用. 它涵盖 wrap_content 测量, 绘制, 自定义属性, 触摸和状态保存. 点击评分条的不同位置, 预期分数在 1–5 之间变化; 旋转后分数保持.

<!-- res/values/attrs.xml -->
<resources><declare-styleable name="RatingBarView">
    <attr name="starCount" format="integer" /><attr name="ratingColor" format="color" />
</declare-styleable></resources>

<!-- res/layout/fragment_rating.xml；父层须参与 View hierarchy state 保存 -->
<com.example.RatingBarView
    android:id="@+id/product_rating"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    app:starCount="5"
    app:ratingColor="@color/yellow" />

class RatingBarView @JvmOverloads constructor(context: Context, attrs: AttributeSet? = null) : View(context, attrs) {
    private val paint = Paint(Paint.ANTI_ALIAS_FLAG)
    private var starCount = 5; private var rating = 0; private var color = Color.YELLOW
    init { context.obtainStyledAttributes(attrs, R.styleable.RatingBarView).use {
        starCount = it.getInt(R.styleable.RatingBarView_starCount, 5).coerceAtLeast(1)
        color = it.getColor(R.styleable.RatingBarView_ratingColor, Color.YELLOW)
    }; isSaveEnabled = true }
    override fun onMeasure(widthSpec: Int, heightSpec: Int) {
        setMeasuredDimension(resolveSize(paddingLeft + paddingRight + starCount * 48.dp, widthSpec), resolveSize(paddingTop + paddingBottom + 48.dp, heightSpec))
    }
    override fun onDraw(canvas: Canvas) { val cell = (width - paddingLeft - paddingRight).toFloat() / starCount; if (cell <= 0f) return; paint.color = color
        repeat(rating) { canvas.drawCircle(paddingLeft + cell * (it + .5f), height / 2f, cell * .3f, paint) } }
    override fun onTouchEvent(event: MotionEvent): Boolean {
        if (!isEnabled) return false
        val usableWidth = width - paddingLeft - paddingRight
        if (usableWidth <= 0) return false
        return when (event.actionMasked) {
            MotionEvent.ACTION_DOWN, MotionEvent.ACTION_MOVE, MotionEvent.ACTION_CANCEL -> true
            MotionEvent.ACTION_UP -> { rating = (((event.x - paddingLeft) / usableWidth) * starCount).toInt().plus(1).coerceIn(1, starCount); updateStateDescription(); performClick(); invalidate(); true }
            else -> false
        }
    }
    override fun performClick(): Boolean = super.performClick()
    override fun onSaveInstanceState(): Parcelable = SavedState(super.onSaveInstanceState()).also { it.rating = rating }
    override fun onRestoreInstanceState(state: Parcelable?) { val saved = state as? SavedState; super.onRestoreInstanceState(saved?.superState ?: state); rating = saved?.rating ?: 0; updateStateDescription(); invalidate() }
    private class SavedState : BaseSavedState {
        var rating = 0
        constructor(superState: Parcelable?) : super(superState)
        constructor(source: Parcel) : super(source) { rating = source.readInt() }
        override fun writeToParcel(out: Parcel, flags: Int) { super.writeToParcel(out, flags); out.writeInt(rating) }
        companion object CREATOR : Parcelable.Creator<SavedState> {
            override fun createFromParcel(source: Parcel) = SavedState(source)
            override fun newArray(size: Int) = arrayOfNulls<SavedState>(size)
        }
    }
    private fun updateStateDescription() { ViewCompat.setStateDescription(this, "$rating / $starCount") }
    private val Int.dp get() = (this * resources.displayMetrics.density).toInt()
}

需导入 android.os.Parcel, android.os.Parcelable, android.view.View.BaseSavedState 和 androidx.core.view.ViewCompat. ViewCompat.setStateDescription 负责 API 兼容; performClick() 仅委托 super 发送标准无障碍点击语义, 不重复手动发事件. 稳定 android:id 与父层 View hierarchy state 保存是恢复前提. 数字推演: 父容器给 AT_MOST 300px, density 为 1,5 星 期望宽 5 x 48 = 240px, resolveSize 得 240px; 给 EXACTLY 180px 则得 180px. 事件 trace: DOWN 获取序列, MOVE 保持消费, UP 更新分数并触发标准点击语义, CANCEL 不改分数. 该示例未在本仓库构建验证, 预期旋转后恢复最后评分.

九, Window / DecorView / ViewRootImpl

• Window: 抽象窗口, PhoneWindow 是唯一实现.
• DecorView: Window 的顶层 View (含 status bar, content).
• ViewRootImpl: 连接 WindowManager 和 DecorView, 是绘制流程的发起者, 事件分发的入口.
• 关系: Activity → PhoneWindow → DecorView → ViewRootImpl 驱动绘制.
• 触发时机: View attach 到窗口后, requestLayout/invalidate 等请求会经 ViewRootImpl 调度下一帧 traversal; 面试说到这里即可, 不要把具体内部调度函数当稳定 API 背诵.

进阶补充: 嵌套滑动, 帧管线与 RecyclerView

NestedScrolling

嵌套滑动解决父子 View 都想消费滑动的问题. child 先询问 parent 是否参与, 滚动前后分发消耗量.

接口方法概览: child 调 startNestedScroll 发起协商, parent 的 onStartNestedScroll 决定是否参与; 滚动前 dispatchNestedPreScroll 让 parent 先消费, child 处理剩余后经 dispatchNestedScroll 分发, 回调 parent 的 onNestedScroll 落账; fling 同理走 dispatchNestedPreFling/dispatchNestedFling. requestDisallowInterceptTouchEvent(true) 只禁止父拦截 touch 事件, 与 NestedScrolling 的 scroll 协商是两套独立机制; CoordinatorLayout + AppBarLayout 正是靠这套协商协调 header 折叠与子列表滚动.

典型场景: CoordinatorLayout + AppBarLayout + RecyclerView.

Choreographer 与 VSync

Choreographer 接收 VSync 信号, 在主线程依次调度 input, animation, traversal 和 commit 等回调. traversal 完成 measure/layout 并记录绘制命令, 硬件加速路径再由 RenderThread 和 GPU 处理, 最终通过 Surface 提交缓冲, 由 SurfaceFlinger 合成显示:

VSync
  -> Choreographer
     -> UI Thread: input / animation / traversal
        -> RenderThread
           -> GPU
              -> Surface / BufferQueue
                 -> SurfaceFlinger
                    -> Display

理论预算不等于业务代码可以全部占满的时间, 系统调度和流水线阶段也需要预算. 掉帧可能来自主线程布局和绑定, RenderThread, 纹理上传, GPU 或 SurfaceFlinger 合成, 用 Perfetto 和 Frame Timeline 确认实际瓶颈, 不能只盯 onDraw().

RecyclerView 复用与预取

RecyclerView 的性能来自布局, 复用, 数据差分和预取共同协作, 不是只有一个 ViewHolder 缓存:

一次滚动可以这样回答: LayoutManager 计算即将进入屏幕的 position, Recycler 优先从 scrap/cache/pool 找可用 ViewHolder, Adapter 在需要时创建或绑定, 离屏 ViewHolder 被回收, GapWorker 根据预取位置提前准备后续 Item.

数据更新与局部绑定

• DiffUtil 比较旧列表和新列表, 计算插入, 删除, 移动和内容变化. 大列表应在后台计算, ListAdapter 和 AsyncListDiffer 已封装异步差分.
• areItemsTheSame 判断是否为同一业务实体, areContentsTheSame 判断展示内容是否变化. 两者不能都用 position.
• stable IDs 用稳定业务 ID 表达 Item 身份, 可帮助状态和动画保持, 但它不能替代正确的 DiffUtil 实现.
• payload 表达局部字段变化, 例如只更新点赞数, 避免重新绑定图片和复杂子树. Adapter 仍要保留完整 bind 作为兜底.
• 提交给 DiffUtil 的列表和 Item 应按快照理解. 原地修改旧对象可能让差分看不到变化.

Adapter 通知 API 的取舍

DiffUtil / stable IDs / payload 的机制, 比较原则与配合边界统一见「数据更新与局部绑定」.

位置通知的共同原则是 “先更新数据, 再发与变更完全匹配的通知”. 不要在异步回调里依赖过期 adapter position; 需要当前绑定位置时读取 bindingAdapterPosition, 并处理 NO_POSITION. 如果业务变化难以可靠地手工描述, 用不可变的新列表交给 DiffUtil/ListAdapter; 如果只是一个已知字段变化且身份和位置都未变, 单项 payload 通知更便宜. 通知越粗, 无效 bind 越多; 通知越细, 调用方维护位置和快照的正确性成本越高.

嵌套横向列表可让多个子 RecyclerView 共享 RecycledViewPool, 并根据首屏需求设置预取数量. 前提是相同 viewType 的 ViewHolder 结构和绑定契约一致; 还要避免每次父 Item bind 都创建新 Adapter, Pool 或 LayoutManager.

GestureDetector 与 VelocityTracker

复杂手势不要全靠手写坐标判断. 点击, 长按, fling 可用 GestureDetector; 速度计算可用 VelocityTracker.

追问: 为什么 RecyclerView 滑动卡顿? 常见是 bind 太重, 图片加载尺寸失控或复用回调错位, 布局层级深, 频繁全量刷新, 预取配置不合理以及共享 Pool 使用错误. 先用 Perfetto, Frame Timeline 和 Layout Inspector 判断是主线程, 渲染线程还是 GPU 瓶颈.

进阶补充: WindowInsets, 无障碍与 RecyclerView 细节

Edge-to-edge 与 WindowInsets

新版本 Android 对 edge-to-edge 的要求逐步收紧. View 体系里不要靠写死 status bar/nav bar 高度, 而是通过 WindowInsets 把系统栏, 屏幕缺口, IME 输入法区域当作布局输入.

常见处理方式:

ViewCompat.setOnApplyWindowInsetsListener(root) { view, insets ->
    val bars = insets.getInsets(WindowInsetsCompat.Type.systemBars())
    view.updatePadding(top = bars.top, bottom = bars.bottom)
    insets
}

面试重点: Insets 应该在基础容器统一处理, 否则每个页面各写一套 padding, 很容易出现输入框被键盘遮挡, 列表最后一项被导航栏遮挡, 沉浸式页面返回后状态不一致.

无障碍 Accessibility

中级面试常追问 “你做 UI 有没有考虑可访问性”.View 体系至少要说清:

• 图片按钮要有 contentDescription, 纯装饰图可标记为不重要.
• 触摸目标建议不小于 48dp.
• 自定义 View 要补充语义, 状态和点击行为, 不要只画图不暴露给 TalkBack.
• 表单错误要能被读屏感知, 不能只靠红色边框.
• 列表/弹窗/底部 Sheet 要考虑焦点顺序和返回键.

RecyclerView 现代实践

ConstraintLayout / MotionLayout

ConstraintLayout 适合减少层级, 表达复杂相对约束; MotionLayout 适合声明式描述状态间动画. 面试回答时不要只说 “性能好”, 要补一句: 复杂约束也会增加求解成本, 真正优化要用 Layout Inspector/Perfetto 看 measure/layout 时间.

刷新率, Insets 与 Compose 互操作

16.7 ms 只对应 60 Hz 的单帧周期示例, 不是所有设备固定 deadline; 90/120 Hz 与动态刷新率下预算更短且帧调度受系统影响. 自定义 View 要处理 window insets, 手势导航, 键盘, RTL, 字体缩放和无障碍. View/Compose 混用时明确状态 owner, ComposeView composition disposal, View 生命周期与重组边界. 卡顿证据统一见 ANR 与卡顿排查.

高频面试题

Q1: View 的绘制流程? 从哪里开始? 从 ViewRootImpl.performTraversals 开始, 依次 performMeasure (measure)→ performLayout (layout)→ performDraw (draw). measure 确定大小, layout 确定位置, draw 绘制内容.

Q2: MeasureSpec 是什么? 三种模式? 32 位 int, 高 2 位模式 + 低 30 位尺寸. EXACTLY (精确, match_parent / 具体值), AT_MOST (最大, wrap_content), UNSPECIFIED (不限, 如 ScrollView 子 View).由父 MeasureSpec + 子 LayoutParams 共同决定.

Q3: 自定义 View 直接继承 View, wrap_content 不生效怎么办? 在 onMeasure 中判断模式为 AT_MOST 时, 给一个默认尺寸 (不能直接用父给的最大值, 否则等同 match_parent).

Q4: 事件分发三个方法? 返回值含义? dispatchTouchEvent (分发), onInterceptTouchEvent (ViewGroup 拦截), onTouchEvent (处理).返回 true 表示消费, 事件序列后续都给它; 返回 false 向上回传.

Q5: 滑动冲突怎么解决? 外部拦截法 (父重写 onInterceptTouchEvent 按需拦截, DOWN 不拦截) 或内部拦截法 (子用 requestDisallowInterceptTouchEvent 控制).判断依据是滑动方向 / 距离.

Q6: invalidate 和 requestLayout 区别? 可以在子线程调用吗? invalidate 重绘 (走 draw), requestLayout 重新测量布局. invalidate 必须主线程, 子线程用 postInvalidate.

Q7: getWidth 和 getMeasuredWidth 区别? getMeasuredWidth 是 measure 后的测量值, getWidth 是 layout 后的实际值 (= right - left).通常相等, 但 layout 可强行改变实际尺寸使其不等.

Q8: onDraw 里能不能 new 对象? 不是绝对禁止, 而是避免: onDraw 每帧调用, 频繁创建对象导致内存抖动, 频繁 GC, 卡顿. Paint/Path 等应在构造时创建并复用; 偶发的低频分配并非违规, 重点是别在热路径每帧 new.

Q9: Edge-to-edge 页面为什么容易被系统栏或键盘遮挡? 因为内容区域延伸到了系统栏 / IME 后面, 但页面没有正确消费 WindowInsets. 正确做法是统一监听 systemBars/ime insets, 给根容器, 列表或输入框加动态 padding/margin, 不要写死状态栏高度.

Q10: View 体系里怎么做无障碍适配? 给可点击图片 / 图标补 contentDescription, 保证触摸目标大小, 自定义 View 暴露语义和状态, 错误提示可被 TalkBack 读到, 并检查焦点顺序和返回行为.

Q11: RecyclerView 的 Recycler, RecycledViewPool, LayoutManager 和 GapWorker 如何协作? LayoutManager 决定可见范围, 摆放和预取位置; Recycler 按 position 和 viewType 从 scrap, cache, pool 中找 ViewHolder; RecycledViewPool 保存可跨 RecyclerView 复用的回收 Holder; GapWorker 汇总预取位置并提前准备. Adapter 只负责创建和绑定, 不能把所有复用能力都归因于 Adapter.

Q12: DiffUtil, stable IDs 和 payload 分别解决什么问题? 三者分别解决列表差分, Item 身份稳定与局部字段更新, 可配合使用; 比较原则与边界 (stable IDs 不能替代 DiffUtil, payload 需完整 bind 兜底) 见「数据更新与局部绑定」.

Q13: 一帧从 VSync 到显示经历什么? Choreographer 接收 VSync 并在主线程调度输入, 动画和 traversal; 主线程记录绘制命令后, RenderThread/GPU 完成渲染并向 Surface 提交缓冲; SurfaceFlinger 合成各图层后交给显示系统. 60Hz, 90Hz 和 120Hz 的理论预算分别约为 16.7ms, 11.1ms 和 8.3ms.

UI 体系 - Jetpack Compose ★

你的重点短板, 且 2024-2025 中级面试几乎必问. Compose 是 Android 声明式 UI 的未来, 新项目首选. 即便面试官项目还在用 View, 也常问 Compose 的理解.

一, 声明式 UI 思想

• 命令式 (View): 你持有 View 引用, 手动 findViewById, setText, setVisibility 去 “改” UI.
• 声明式 (Compose): 你描述 “UI 在某状态下长什么样”, 状态变了框架自动重组 (recomposition, 重跑受影响的 Composable). UI = f(State).

@Composable
fun Greeting(name: String) {
    Text(text = "Hello $name")   // 不持有引用,name 变了自动重组
}

二,@Composable 与重组 (Recomposition)

• @Composable 函数不返回 UI 对象, 而是向 Composition (组合树) 发射 (emit) 描述节点.
• 直觉上可把 @Composable 理解为 “带有组合上下文的函数”:编译器会改写调用以便框架记录调用位置, 参数和状态读取, 从而决定哪里需要重组; 具体改写细节属于实现层面, 面试重点是理解 “状态读取驱动局部重组”.
• 重组: 当 Composable 读取的 State 变化时, 框架重新执行受影响的 Composable 来更新 UI.
• 重组特性 (必须理解, 易踩坑):
  • 可能频繁发生, 所以 Composable 要无副作用, 幂等, 快速.
  • 执行顺序不保证, 可能并行.
  • 不要在 Composable 体内直接做副作用 (网络, 写变量), 要用副作用 API.

稳定性, strong skipping, compiler reports 与性能测量属于 Compose 深水区; 本篇只要求先写出正确, 可读, 可测试的页面.

三, 状态管理

• remember { }: 在重组间记住值 (存在 Composition 中), 重组不重置.
• mutableStateOf(): 创建可观察状态, 读取它的 Composable 会在它变化时重组.
• remember { mutableStateOf(x) }: 最常见组合. rememberSaveable 还能跨配置变更 / 进程恢复.

var count by remember { mutableStateOf(0) }
Button(onClick = { count++ }) { Text("$count") }

• rememberSaveable 自定义 Saver: 不能直接存入 Bundle 的类型用 rememberSaveable(saver = ...) 提供 Saver(save = { ... }, restore = { ... }). 示意: rememberSaveable(saver = Saver(save = { it.id }, restore = { findById(it) })) { mutableStateOf(Task()) }, 让非 Parcelable 对象也能跨配置恢复.
• lambda 捕获陷阱: remember { count } 的初值 lambda 只在首次组合执行, 捕获的是当时旧值; 需要随 count 变化重建时应把 count 放进 key (remember(count) { ... }), 长生命周期对象里要用 rememberUpdatedState 拿最新值.
• 状态提升 (State Hoisting): 把状态移到调用者, Composable 变成无状态 (stateless), 通过参数接收 value + 回调 onValueChange. 利于复用, 测试, 单一数据源.

四, 副作用 API (Side Effects)

副作用是 “在 Composable 之外发生的影响”.因为重组随时可能发生, 副作用必须用专门 API 管理生命周期:

• LaunchedEffect(key): 进入组合时启动一个协程, key 变化时取消重启, 离开组合时取消. 用于一次性挂起操作 (加载数据, 监听 Flow).
• rememberCoroutineScope(): 拿到一个绑定组合生命周期的 scope, 在事件回调 (如 onClick) 里启动协程.
• DisposableEffect(key): 需要清理的副作用 (注册 / 反注册监听器), 提供 onDispose {}.
• SideEffect: 每次重组成功后执行, 用于把 Compose 状态同步给非 Compose 代码.
• derivedStateOf: 从其他 state 派生计算值, 只有结果变化才触发重组 (避免过度重组, 如根据滚动位置算 “是否显示回顶按钮”).
• rememberUpdatedState: 在长生命周期 effect 中引用最新值而不重启 effect.
• produceState / snapshotFlow: State 与 Flow 互转.

LaunchedEffect(userId) {              // userId 变才重新加载
    viewModel.load(userId)
}

五, CompositionLocal 与 Modifier

• CompositionLocal: 隐式向下传递数据 (主题, Context), 避免逐层传参. 如 LocalContext.current, MaterialTheme.
• compositionLocalOf 追踪读取: 某 Composable 读取它后, 值变化会触发读取处重组; staticCompositionLocalOf 不追踪读取, 值变化时使 Provider 子树整体重组, 适合几乎不变的默认值 (如主题).
• Provider 边界: CompositionLocalProvider(LocalX provides v) { ... } 只影响其子树, 子树外读到的仍是外层值; Local 定义应在文件顶层, 不要在重组路径上创建新 Local.
• Modifier: 装饰 Composable (尺寸, padding, 点击, 背景).顺序敏感: padding().background() 与 background().padding() 效果不同 (前者内边距区域无背景色). Modifier 是链式不可变的.

六, 三大阶段

Compose 渲染分三阶段:

1. Composition (组合): 执行 Composable, 构建 / 更新 UI 树 (发射什么).
2. Layout (布局): 测量 + 摆放 (多大, 放哪).
3. Drawing (绘制): 画到屏幕.

三个阶段用于建立渲染直觉; 重组范围, 跳过条件和性能诊断见 Compose 深水区.

七, 常用布局, Material 3 与完整页面

Column 纵向摆放, Row 横向摆放, Box 用于叠放; Scaffold 提供 top bar, bottom bar, snackbar 和内容 padding 的页面骨架; LazyColumn 只组合可见附近元素, 适合动态长列表. Material 3 组件通过 MaterialTheme 读取颜色, 排版和形状.

@Composable fun AvatarWithBadge() = Box {
    Icon(Icons.Default.Person, contentDescription = "用户")
    Text("3", Modifier.align(Alignment.TopEnd))
}

可运行示例 (工程内): 在已配置 Compose Material 3 的模块, 以 setContent { MaterialTheme { TodoPage() } } 调用. Preview 显示初始态; 运行后输入文本并点击添加, 预期列表新增一项, 输入框清空, 复选框可切换完成状态.

@Composable
fun TodoPage() {
    var input by rememberSaveable { mutableStateOf("") }
    var tasks by remember { mutableStateOf(listOf("阅读 Compose" to false)) }
    Scaffold(topBar = { TopAppBar(title = { Text("待办") }) }) { padding ->
        Column(Modifier.padding(padding).padding(16.dp)) {
            Row(verticalAlignment = Alignment.CenterVertically) {
                OutlinedTextField(input, { input = it }, label = { Text("新任务") }, modifier = Modifier.weight(1f))
                Button(onClick = { if (input.isNotBlank()) { tasks = tasks + (input.trim() to false); input = "" } }) { Text("添加") }
            }
            LazyColumn { itemsIndexed(tasks) { index, task ->
                Row(verticalAlignment = Alignment.CenterVertically) {
                    Checkbox(task.second, { checked -> tasks = tasks.toMutableList().also { it[index] = task.first to checked } })
                    Text(task.first)
                }
            } }
        }
    }
}
@Preview(showBackground = true) @Composable
private fun TodoPagePreview() { MaterialTheme { TodoPage() } }

这里 TodoPage 拥有演示状态; 复用组件应提升状态, 例如 TaskRow(task, checked, onCheckedChange), 让调用方持有状态和业务 ID. 列表来自服务端或可删除时, 不能用 index 作稳定 key, 应使用业务 ID.

八, 与 View 互操作

• Compose 中嵌 View: AndroidView(factory = { ctx -> View(ctx) }, update = { view, state -> ... }), factory 只在首次组合创建 View 一次, update 在每次重组同步参数, 不要在 factory 里放会变的状态.
• View 中嵌 Compose: ComposeView.setContent { }, 并设置合适的 ViewCompositionStrategy.
• ViewCompositionStrategy 决定 Composition 何时销毁: 默认 DisposeOnViewTreeLifecycleDestroyed (View attach 到带 Lifecycle 的树, 其销毁时释放); 也可用 DisposeOnDetachedFromWindow (脱离窗口即释放) 或 DisposeOnLifecycleDestroyed(lifecycle) (显式绑定 Lifecycle).
• 性能诊断, 稳定性与跳过规则统一见 Compose 深水区.

高频面试题

Q1: Compose 和传统 View 的本质区别? View 是命令式, 保留模式 (retained, 持有可变 View 树, 手动改); Compose 是声明式, 同样维护持续存在的组合树 (retained Composition), 状态变化时只增量重组受影响部分, 不是每帧全量重绘的即时模式 (immediate mode). Compose 无 findViewById, 无 XML, Kotlin 写 UI.

Q2: 什么是重组? 它有什么注意事项? State 变化时重新执行受影响的 Composable 更新 UI. 注意: 可能频繁/并行/乱序执行, 所以 Composable 必须无副作用, 幂等, 快, 副作用要用专门 API.

Q3: remember 和 rememberSaveable 区别? remember 在重组间保留值, 但配置变更 (旋转)/进程重建会丢失; rememberSaveable 额外通过 Bundle 保存, 能跨配置变更恢复 (类型需可 Parcelize).

Q4: LaunchedEffect 和 rememberCoroutineScope 区别? LaunchedEffect 在组合期启动协程, 随 key 重启, 离开自动取消, 用于进入界面就执行的副作用; rememberCoroutineScope 返回 scope, 在事件回调里手动启动协程.

Q5: 为什么要让 Composable 保持无副作用? 因为状态变化可使受影响范围再次执行, 函数体内直接发请求, 写数据库或修改外部变量会被重复执行. 把这类工作交给 LaunchedEffect, 事件回调或 ViewModel; 具体重组诊断见 Compose 深水区.

Q6: Compose 的三个阶段是什么? Composition 发射 UI 树, Layout 测量和摆放, Drawing 绘制内容. 它们帮助理解一次 UI 更新的路径; 性能诊断与跳过规则见 Compose 深水区.

Q7: Modifier 顺序为什么重要? Modifier 链按顺序应用, 每个包裹前一个. padding 在 background 前后效果不同. size, padding, clickable 顺序都会改变最终表现.

Q8: 状态提升是什么? 为什么重要? 把状态从 Composable 内移到调用方, 使 Composable 无状态 (接 value + onValueChange).好处: 单一数据源, 可复用, 可测试, 可被多处控制.

易错点 / 追问

• remember { } 的初值 lambda 只在首次组合执行, 捕获的是当时旧值: 需要随状态重建时把变化值放进 key, 长生命周期 effect 中要用 rememberUpdatedState.
• 不要在 Composable 体内直接做副作用 (网络, 写库, 改外部变量): 重组可能反复执行函数体, 副作用要交给 LaunchedEffect / DisposableEffect 或事件回调.
• LaunchedEffect 的 key 一变就取消重启: 把每次重组都新建的对象放进去会导致无限重启; key 应使用稳定标识 (ID 或业务值).
• rememberSaveable 只能保存 Bundle 兼容类型: 自定义对象必须提供 Saver, 否则配置变更后恢复失败.
• Modifier 顺序敏感: padding().background() 与 background().padding() 表现不同; 说不清顺序时按 “每个 Modifier 包裹前一个” 推导.
• AndroidView 的 factory 只在首次组合执行: 把会变的状态放进 factory 是常见错误, 同步参数要放 update.
• View 中嵌 Compose 时 ViewCompositionStrategy 选错会导致组合不销毁或过早销毁: 默认 DisposeOnViewTreeLifecycleDestroyed 覆盖大多数场景, 脱离 Lifecycle 树时改用 DisposeOnDetachedFromWindow.

Compose 深水区

本篇只讨论 Snapshot, 重组范围, 跳过与性能诊断; Column, Scaffold, Material 3, Preview 和状态提升的入门页面见 Compose 入门.

一, Recomposition: 状态读取驱动局部重组

Compose 的核心是 UI = f(State). 当某个 Composable 在组合阶段读取了 State, 这个读取关系会被记录; State 改变后, 相关范围进入重组.

• 重组是重新执行 Composable, 不是重新创建整个 Activity/View 树.
• 重组可能很频繁, Composable 必须幂等, 无副作用, 执行快.
• 不要在 Composable 体内直接发网络请求, 写数据库, 改全局变量.
• 把状态读取推迟到最小范围, 减少被重组的 UI 面积.

@Composable
fun ProfileScreen(state: ProfileState, onRetry: () -> Unit) {
    when {
        state.loading -> Loading()
        state.error != null -> ErrorView(state.error, onRetry)
        else -> ProfileContent(state.user)
    }
}

Phase 细分 (与 09「三大阶段」断链补齐): 一次 UI 更新依次走 Composition (组合, 执行 Composable 生成节点), Layout (布局, 测量与摆放), Drawing (绘制, 画到 Canvas). State 在哪个阶段被读取决定后续触发范围: 组合阶段读取 → 该 State 变化触发重组; 布局阶段读取 (如自定义 Layout 测量中读) → 变化只触发重新测量布局, 不重组; 绘制阶段读取 (如 Canvas 绘制中读) → 只触发重绘. 所以应把状态读取尽量放在组合阶段交给 Compose 追踪; 布局 / 绘制阶段直接读可变值会绕过快照追踪, 改值不一定刷新.

二, Stability, Strong Skipping 与 Skippable

Compose 的跳过规则依赖 Kotlin 与 Compose Compiler 版本及项目配置. 对采用 Kotlin 2.0.20+ 且未显式关闭 strong skipping 的项目, 它通常默认启用; 许多参数类型不稳定但函数可重启的 Composable 也可以被标记为 skippable. 因此, 下面这种旧口诀不再准确:

参数不稳定 → 整个 Composable 一定不能跳过.

当前更可靠的判断方式:

1. 先确认函数是否 restartable/skippable, 以及项目是否使用匹配版本的 Compose Compiler Gradle plugin.
2. 用 compiler reports/metrics 查看稳定性推断, 不凭肉眼猜测.
3. 用重组计数, Layout Inspector, Perfetto 或 Macrobenchmark 证明是否存在实际性能问题.
4. 优先修正状态读取范围, 对象频繁重建和列表 key/contentType; 不要为了 “稳定” 盲目添加注解.

@Immutable
// 只有字段及其可达状态确实不可变时才成立
 data class UserUiModel(
    val id: String,
    val name: String,
)

@Stable/@Immutable 是正确性契约, 不是性能开关. 若对象内部变化无法被 Compose 观察, 错误标注可能让界面漏更新. 对于第三方或集合类型, 可在边界转换成不可变 UI model, 或通过 stability configuration 谨慎声明, 并用报告验证结果.

strong skipping 具体例子: 参数稳定且 lambda 未变时可整段跳过, 例如 ProfileRow(user, onClick = onClickRef) 中 user 与 onClickRef 都未变 (strong skipping 下捕获稳定值的 lambda 会被自动 remember 为同一实例), 编译器跳过 ProfileRow. 反例: var count by remember { mutableStateOf(0) } 后传 ProfileRow(user, onClick = { log(count) }): lambda 捕获了会变的 count, count 一变 lambda 便重建, 参数引用不再相等, 即使 user 相同也无法跳过. strong skipping 只能忽略 “真的没变” 的参数, 不能阻止 “捕获了变化状态” 的 lambda 重建.

三, remember / rememberSaveable / derivedStateOf

remember 把值保存在 Composition 中, 重组不丢; rememberSaveable 额外通过 Bundle/Saver 支持配置变更和进程恢复; derivedStateOf 用于从一个或多个 State 派生计算结果, 只有派生结果变化时才通知.

val listState = rememberLazyListState()
val showTopButton by remember {
    derivedStateOf { listState.firstVisibleItemIndex > 3 }
}

使用边界:

• remember: 缓存计算结果, 对象实例, 滚动状态等组合内状态.
• rememberSaveable: 输入框, tab, 筛选条件等需要旋转后恢复的轻量状态.
• derivedStateOf: 高频变化中只关心派生布尔 / 分组结果, 如滚动位置.
• 不要滥用 derivedStateOf, 普通字符串拼接 / 低频计算没有必要.

四, Snapshot 系统

Compose 的 mutableStateOf 背后是 Snapshot 状态系统. 它记录状态读取和写入, 在写入提交后通知受影响的组合范围.

• Snapshot 让 Compose 能知道 “谁读了这个状态”.
• 状态写入应发生在主线程或受 Snapshot 管理的上下文中, 避免并发写冲突.
• snapshotFlow { } 可以把 Compose State 读取转换成 Flow, 适合观察滚动状态等.
• 不要直接修改普通可变集合后期待 UI 更新; 要替换 State 值或使用 Snapshot-aware 集合.

LaunchedEffect(listState) {
    snapshotFlow { listState.firstVisibleItemIndex }
        .collect { index -> /* analytics or load trigger */ }
}

提交推演: 写入先落在当前 Snapshot, 由 global snapshot 推进提交后统一使读取方失效并调度重组, 一次事务内多次写会合并, 不是每次写都立即重组. snapshotFlow 采用合并 (conflate) 语义: 两次 collect 之间状态变化多次, 只发射最新一次结果, 高频滚动位置经它收集天然去抖, 下游不会收到中间值.

五, Modifier 顺序与布局语义

Modifier 是链式包装, 顺序会改变测量, 绘制, 点击区域.

怎么落地: 先想 “尺寸/约束”, 再想 “点击/语义”, 最后想 “绘制”; 可访问性相关 semantics 要放在能覆盖正确节点的位置.

六, LazyColumn 性能

LazyColumn 不是解决所有问题的银弹, 关键是 key, contentType, 状态位置和 item 复杂度.

• 给稳定业务 ID 作为 key, 避免插入 / 删除导致 item 状态错位.
• 使用 contentType 帮助复用相同类型 item.
• 避免在 item lambda 里做重计算, 创建大对象或直接收集 Flow.
• 分页加载用列表滚动状态 + derivedStateOf/Paging, 避免每帧触发请求.
• item 内状态要么跟业务 ID 绑定, 要么上提到 ViewModel.

LazyColumn(state = listState) {
    items(
        items = users,
        key = { it.id },
        contentType = { "user" },
    ) { user ->
        UserRow(user)
    }
}

movableContentOf { ... } 把一段组合与其组合状态绑定: 在组合树中移动位置 (列表重排) 时状态随之迁移而非重建, 适合需要保留 item 内部 remember 状态的场景. LazyColumn 可用 beyondViewportItemCount 扩大组合 / 预取窗口, 提前准备即将滑入的 item, 减少滚动期卡顿但增加前期组合成本.

七, View 互操作与生命周期收集

Compose 和 View 混用在迁移期很常见.

• Compose 中嵌 View: 用 AndroidView, 在 update 中同步参数, 不要每次重组都重新创建重对象.
• View 中嵌 Compose: 用 ComposeView.setContent, 并设置合适的 ViewCompositionStrategy.
• 收集 Flow: 优先用 collectAsStateWithLifecycle(), 避免后台生命周期仍持续收集.
• 副作用: 进入组合加载用 LaunchedEffect(key), 注册监听用 DisposableEffect(key) 清理.

八, Compose Testing

Compose 测试关注语义树而不是具体 View ID.

• 用 createComposeRule() 设置内容.
• 通过 onNodeWithText, onNodeWithTag, onNodeWithContentDescription 查找节点.
• 给关键节点设置 Modifier.testTag().
• 对异步状态变化使用 waitUntil 或测试时注入可控 Dispatcher/Repository.

composeTestRule.setContent { LoginScreen(state, onSubmit = {}) }
composeTestRule.onNodeWithTag("login_button").assertIsDisplayed()

怎么答: Compose 测试不是截图测试优先, 而是验证语义, 状态渲染和用户交互; 业务逻辑仍应在 ViewModel/UseCase 里用普通单元测试覆盖.

九, Compiler reports 与 Macrobenchmark: 先测量再优化

上下文片段: 这是 Gradle Kotlin DSL 的诊断配置示意, 键名与产物位置随 Kotlin/Compose 插件版本变化, 必须以项目当前插件文档为准; 它不声称已经在本仓库执行. 目标是产出 report 后检查 composable 的 restartable/skippable 推断, 再结合真实交互验证.

composeCompiler {
    reportsDestination = layout.buildDirectory.dir("compose_compiler")
    metricsDestination = layout.buildDirectory.dir("compose_metrics")
}

可运行示例 (独立 benchmark module): 在 AndroidX Macrobenchmark 模块配置被测 app package, 并准备可冷启动的 MainActivity. 运行后预期报告含多次 timeToInitialDisplayMs; 不能把一次数字或未运行示例写成收益结论.

@RunWith(AndroidJUnit4::class)
class StartupBenchmark {
    @get:Rule val benchmarkRule = MacrobenchmarkRule()
    @Test fun startup() = benchmarkRule.measureRepeated(
        packageName = "com.example.app", metrics = listOf(StartupTimingMetric()),
        iterations = 10, startupMode = StartupMode.COLD,
    ) { pressHome(); startActivityAndWait() }
}

排障路径: 症状是滚动或点击掉帧; 证据先取 Macrobenchmark 分布和 Perfetto trace; 定位主线程 composition/layout, RenderThread/GPU 或 I/O 的超预算阶段; 修复方向可能是缩小 state 读取, 避免对象重建, 补 key/contentType 或降低 item 工作量; 最后在同一设备, 构建类型和场景重复测量.60Hz 的 16.7ms 只是一帧周期示例, 90/120Hz 预算更短, 不能作为固定业务阈值.

高频面试题

Q1: 什么会触发 Compose 重组? Composable 在组合阶段读取的 State 变化会触发相关范围重组. 重组是局部重新执行函数, 不是整棵 UI 全量重建. Composable 要幂等, 无副作用, 快速执行.

Q2: 稳定性和 skippable 是什么? 稳定性是编译器用于推断参数变化的属性, skippable 表示可在本次重组跳过该函数的能力. 稳定参数且值未变通常有利于跳过; 但在 Kotlin/Compose Compiler 版本和项目配置满足 strong skipping 条件时, 部分不稳定参数的 restartable Composable 也可能跳过. 不要凭口诀判断, 应查看当前 compiler report 并测量实际重组/性能.

Q3: remember, rememberSaveable, derivedStateOf 怎么区分? remember 保留组合内状态, 重组不丢但配置变更会丢; rememberSaveable 通过 Bundle/Saver 支持恢复; derivedStateOf 用于从高频状态派生低频结果, 结果不变时不触发下游重组.

Q4: Snapshot 系统解决什么问题? 它跟踪 Compose State 的读取和写入, 让框架知道哪些组合范围依赖某个状态, 写入提交后精准通知重组. 普通可变集合不受 Snapshot 自动追踪, 直接 mutate 可能不刷新 UI.

Q5: LazyColumn 怎么优化? 提供稳定 key 和 contentType, 避免 item lambda 重计算和直接收集 Flow, 把状态按业务 ID 管理, 分页触发用 derivedStateOf/snapshotFlow 控制频率, 不要每次滚动都发请求.

易错点 / 追问

• 在 Composable 函数体里直接发请求或写外部状态, 会因重组重复执行.
• remember 不能跨配置变更保存状态, 输入框 / 筛选条件要考虑 rememberSaveable 或 ViewModel.
• Modifier 顺序会改变背景, padding, 点击区域和语义范围, 不是随便链式调用.
• 普通 mutableList.add() 不一定触发 UI 更新, 应替换 State 或使用 Snapshot-aware 状态集合.
• LazyColumn 不加稳定 key 时, 插入 / 删除可能导致 item 状态错位和不必要重组.

Android 版本适配

最后核验: 2026-08-10. 版本适配必须同时说明系统版本 / API, targetSdk 条件, 安装或升级状态, 设备条件与分发渠道; 不要把系统行为变化和 Google Play 上架要求混为一谈.

一, 适配心智模型

每条变化都按以下四元组记录:

1. 运行系统版本 / API: 用户设备实际运行什么版本.
2. targetSdk 条件: 变化对所有应用生效, 还是只对达到某个 target 的应用生效.
3. 安装状态: 新安装, 覆盖升级和从旧系统升级是否不同.
4. 设备与豁免条件: 屏幕尺寸, 硬件能力, 权限角色, 企业设备或系统应用是否例外.

Google Play 的 target API 截止日期是分发政策, 不等于某个 Android 版本已经正式发布, 也不等于系统行为对所有应用同时生效.

targetSdk 门槛速查表

集中参考表: 系统侧门槛只对该 targetSdk 的应用生效, 商店侧门槛由 Google Play 分发政策强制; 二者不应混为一谈. 各行详细论证见本篇各版本小节 (二至六节).

二, Android 6–13 核心变化回顾

Android 7/8/9 历史迁移矩阵

下表用于补齐历史版本的迁移思路. 每一行都应同时在对应系统版本与受影响的 targetSdk 条件下验证, 并覆盖新安装和从旧版覆盖升级.

Android P 的明文限制不是要求以全局 cleartextTrafficPermitted="true" 放开流量的理由. 这种做法会扩大中间人攻击和误配置暴露面, 不能规避安全或合规风险. 新服务与迁移服务应使用 HTTPS; 遗留兼容必须经安全评审, 仅针对必要域名设置最小例外, 并在发布前复核当前平台和地区要求.

多机型适配矩阵

版本回归不等于只换一个系统镜像. 以业务关键路径建立最小设备矩阵, 记录机型, 系统版本, targetSdk, 安装状态, 应用版本和结果证据.

三, Android 14 / API 34

• 前台服务类型, 声明与启动条件收紧; 必须结合具体 service type 和豁免条件核对.
• 精确闹钟不是 “声明权限即可无条件使用”, 需要判断应用类别, 用户授权和系统策略.
• 后台启动 Activity, 隐式 Intent 和动态注册广播接收器的安全边界继续收紧.
• 升级 targetSdk 前应做真实设备与升级安装回归, 不能只做新安装冒烟测试.

四, Android 15 / API 35

• 对达到相应 targetSdk 的应用, edge-to-edge 成为默认行为; 需要系统处理状态栏, 导航栏 Insets, 而不是依赖旧式固定高度.
• 前台服务, 后台启动, 通知, 媒体投屏等变化应逐项标注 targetSdk 条件.
• 16 KB page size 是 native 依赖兼容问题之一, 需要检查 APK/AAB 中所有 .so, 包括第三方 SDK; 不能只验证自研 C++.
• 大屏和可调整窗口行为应按设备尺寸, 窗口模式和 targetSdk 条件测试.

五, Android 16 / API 36

Android 16 正式版 2025-06 发布, API 36. 以下为对 targetSdk 36 应用生效的关键变化 (按 Android Developers 官方行为变更页核验):

• 继续关注 edge-to-edge, 大屏适配, 后台任务与权限行为的 targetSdk 条件.
• 对含 native 库的应用, 将 16 KB page size 纳入 CI 制品检查和真机 / 模拟器测试.
• 部分屏幕共享: 用户可通过系统选择器只共享单个窗口, 需处理 “单窗口 vs 整屏” 的差异; 锁屏或系统停止共享时须处理 onStop 并释放资源 (targetSdk 36).
• edge-to-edge 的临时 opt-out (windowOptOutEdgeToEdgeEnforcement) 在 API 36 失效, 必须正式消费 Insets.
• 大屏 resizability / orientation 限制自 16 起对 targetSdk 36 生效 (游戏, sw600dp 以下及用户显式选择除外; 仍保留临时 opt-out), 17 起移除 opt-out.
• MediaStore getVersion() 改为每应用唯一标识, 防止指纹滥用; 设备指纹 / 风控 SDK 不应依赖其格式或内容.
• 健康类权限拆分: BODY_SENSORS 拆为 READ_HEART_RATE 等粒度权限; 本地网络权限 ACCESS_LOCAL_NETWORK 开始 rollout (阶段 opt-in), 涉及局域网通信的 SDK 需提前适配.
• 不把预览期或厂商特性写成所有设备统一行为; 以正式 API 文档和兼容性框架结果为准.

六, Android 17 / API 37

截至 2026-08-10, Android 17/API 37 正式版已于 2026-06-16 发布. 当前 Beta 指 Android 17 后续 QPR (季度平台发布) 预览, 不应倒推为 Android 17 正式版仍处于 Beta. 正式 API 37 的适配以 Android 17 overview/release notes 为准; QPR Beta 的新增或变更行为须按对应 QPR release notes 单独核验.

targetSdk 37 关键变化 (按 Android 17 行为变更页核验):

• 大屏 resizability / orientation 无开发者 opt-out: 目标 API 37 应用在 sw ≥ 600dp 大屏上须全自适应, 系统忽略 screenOrientation, resizeableActivity 与 aspectRatio 设置 (游戏与用户显式选择除外).
• 本地网络访问须运行时权限 ACCESS_LOCAL_NETWORK (隶属 NEARBY_DEVICES 组); 已授权 NEARBY_DEVICES 的用户不重复弹窗.
• Safer DCL 扩展到 native: System.load() 加载的 .so 必须只读, 否则抛 UnsatisfiedLinkError; 设备指纹 / 风控 SDK 需复核 so 加载路径与写入.
• static final 字段真正不可变 (反射写入抛异常, JNI SetStaticLongField 等致崩溃); MessageQueue 改 lock-free 实现, 反射其私有字段或方法的代码可能失效.
• 明文 HTTP 默认禁用 (usesCleartextTraffic 废弃); 证书透明度默认开启, 影响自定义 CA 与抓包场景 (targetSdk 37).
• SMS OTP 消息对非默认短信应用默认拦截 3 小时; 背景音频播放 / 音频焦点请求收紧.

七, Google Play target API 要求

截至 2026-08-10, Google Play 的 API 36 target 要求从 2026-08-31 起生效; API 37 不是当前强制线. 具体截止日期会变化, 发布前必须重新核验 Play Console 和官方 target API requirements 页面.

八, TargetSDK 升级 Playbook

1. 建立变化清单: 按系统版本, targetSdk, 安装状态和设备条件分类.
2. 扫描 manifest, 权限, 前台服务, 通知, 存储, 闹钟, 后台启动和 native 库.
3. 分阶段提高 compileSdk 与 targetSdk, 不要把工具链升级和业务行为修改混成一次不可回退的大提交.
4. 覆盖新安装, 覆盖升级, 权限已拒绝, 旧数据迁移, 后台恢复, 大屏和低内存设备.
5. 通过灰度, Android vitals, 崩溃/ANR/权限漏斗观察影响, 并保留回滚路径.

九, 权限矩阵与 edge-to-edge 迁移清单

迁移 edge-to-edge 时逐项完成: 确认目标系统 /targetSdk 条件; 根布局启用 edge-to-edge; 将 systemBars, cutout, IME Insets 作为布局输入; 验证列表末项, 底部按钮和输入框的导航栏/键盘遮挡; 测试手势导航, 三键导航, 深色模式, RTL, 大屏和旋转; 移除固定状态栏高度. 症状 “底部 CTA 被遮挡” 的证据是对应窗口模式下 Insets 日志/截图, 修复是消费正确 Insets, 验证是设备矩阵而非单一模拟器.

高频面试题

Q1: compileSdk, targetSdk, minSdk 有什么区别?
compileSdk 决定编译时可用 API; targetSdk 表示应用已针对相应行为变化完成适配, 并会触发对应兼容规则; minSdk 决定最低安装版本. 三者不是同一个 “支持版本”.

Q2: 如何回答一次 targetSdk 升级?
先给版本与截止日期, 再按行为变化清单, 代码改造, 安装 / 升级测试, 灰度指标和回滚方案展开, 并说明哪些变化对所有应用生效, 哪些由 targetSdk 触发.

Q3: Android 17 是否已经正式发布?
截至 2026-08-10 已于 2026-06-16 正式发布; 后续 QPR Beta 与 Android 17 正式版是不同发布轨道.

易错点 / 追问

• 不要把 Play 上架政策当成 Android 系统发布时间线.
• 不要只说 “适配 Android 15/16”, 必须补 targetSdk 与设备条件.
• 不要把预览版 release notes 当成不会变化的最终契约.
• 权限, 后台任务, 前台服务和商店政策属于易变内容, 发布前应由工程与合规共同复核.

版本与参考资料

• 最后核验: 2026-08-10
• 稳定性: Android 14–17 为已发布平台; Android 17 后续 QPR 预览可能仍为 Beta
• Android 16 overview
• Android 16 behavior changes
• Android 17 overview
• Android 17 behavior changes
• Android 17 behavior changes all apps
• Android 17 release notes
• Android 17 QPR1 release notes
• Android Developers Blog
• 正式发布日期的具体 Blog 公告 URL 应在发布前复核; 本次候选 URL 返回 404, 未保留为参考链接.
• Google Play target API requirements

图片加载与缓存

图片问题要区分泄漏, 瞬时解码峰值, Java heap, native/graphics 内存, 磁盘缓存和网络获取, 不能只用 “压缩图片” 概括.

一, Bitmap 内存模型与大小计算

Bitmap 像素内存可近似按 宽 × 高 × 每像素字节数 估算, 还要考虑 density 缩放, row bytes, 颜色空间, 硬件 Bitmap 和解码中间缓冲.

• ARGB_8888 通常每像素 4 字节.
• RGB_565 通常每像素 2 字节, 但色彩精度和透明度能力受限, 不能为了省内存无条件使用.
• Android 8.0 以后像素数据主要位于 native heap, 但仍计入进程内存压力; 这不等于 “移出 Java heap 后就不会 OOM”.
• density 缩放推演: 解码尺寸会被 scale = inTargetDensity / inDensity 放大, inDensity 是资源所在 density bucket (如 drawable-mdpi = 160), inTargetDensity 是设备 density (如 xxhdpi = 480). 一张 100x100 的 mdpi 资源在 xxhdpi 设备上放大 3 倍 (480/160) 解码为 300x300, 内存按放大后尺寸计算: 300 x 300 x 4 = 360KB, 而非原资源的 40KB: 面积放大 scale² 倍 (此例 9 倍), 这正是误放 mdpi 图到高密度设备导致内存暴涨的原因.

二, 按目标尺寸解码

可运行示例 (工程内): 下列函数与调用放在 Activity, Fragment 或 Repository 的资源解码路径中; 输入是存在的 R.drawable.my_image 和目标像素尺寸, 输出是采样后的 Bitmap?. 原图 4000x3000, 目标 1000x750 时选取 sample 4, 实际解码尺寸约为目标尺寸, 最终仍以解码结果为准.

fun calculateInSampleSize(options: BitmapFactory.Options, reqWidth: Int, reqHeight: Int): Int {
    var sample = 1
    while (options.outHeight / (sample * 2) >= reqHeight && options.outWidth / (sample * 2) >= reqWidth) sample *= 2
    return sample
}
fun decodeSampledResource(resources: Resources, @DrawableRes id: Int, reqWidth: Int, reqHeight: Int): Bitmap? {
    require(reqWidth > 0 && reqHeight > 0)
    val options = BitmapFactory.Options().apply { inJustDecodeBounds = true }
    BitmapFactory.decodeResource(resources, id, options)
    if (options.outWidth <= 0 || options.outHeight <= 0) return null
    options.inSampleSize = calculateInSampleSize(options, reqWidth, reqHeight)
    options.inJustDecodeBounds = false
    return BitmapFactory.decodeResource(resources, id, options)
}

inSampleSize 表示解码采样比例. 不同解码器和历史 Android 版本对非 2 次幂取值的处理存在差异, 因此实现应以目标尺寸, 实际解码结果和当前平台文档为准, 而不是写成 “永远必须是 2 的幂”.生产代码通常优先使用成熟图片库完成尺寸协商, 解码复用和线程调度.

• inBitmap 复用: 把 BitmapFactory.Options.inBitmap 设为一块可复用的旧 Bitmap, 解码直接复用其像素内存, 减少分配与 GC; 约束是目标尺寸与配置需能被旧对象容纳 (Android 4.4+ 允许尺寸不更大即可) 且解码器兼容, 不满足时需回退普通分配并严格校验.
• ImageDecoder (API 28+): 替代 BitmapFactory 的现代解码入口, 支持 setTargetSize() 目标尺寸, 缩放, 裁剪, 并自动按 EXIF 方向校正; 新代码优先考虑, 解码复用与后处理语义也更明确.
• Hardware Bitmap (Bitmap.Config.HARDWARE, API 26+): 像素存于 graphics 内存, 只能用于渲染不能读像素, 适合列表与 GPU 合成, 但取样, 序列化等需要读像素的 API 不可用.

三, 缓存与数据获取层次

通用图片管线可以分为:

1. 活跃资源 / 内存缓存: 最快, 但受进程生命周期和内存压力影响.
2. 转换后资源磁盘缓存: 缓存裁剪, 缩放或变换结果.
3. 原始数据磁盘缓存: 缓存下载或读取到的原始数据.
4. 数据源: 网络, 文件, ContentProvider 或应用资源, 不属于缓存层.

缓存 key 必须包含尺寸, 变换, 签名, 数据版本和必要的请求参数, 否则会出现错图或旧图.

四, Glide 缓存与生命周期边界

以 Glide 4 的公开行为模型说明, 请将内部类名视为版本相关实现细节. 典型查找顺序是:

1. Active resources;
2. Memory cache;
3. Resource disk cache;
4. Data disk cache;
5. Source.

网络只是可能的数据源之一, 不是 “第三级缓存”.Glide 会根据传入的 Activity, Fragment, View 或 Application Context 选择请求管理和生命周期作用域;“偷偷注入隐藏 Fragment” 只适合解释部分历史实现, 不能作为所有版本和所有 Context 的稳定 API 契约.

上下文片段 (Glide 4): 在 Fragment 的 onViewCreated 中, imageView 是该 Fragment 的 ViewBinding 成员, URL 是可信业务数据. 普通 Glide.with().load() 只需 Glide 依赖; 只有使用生成 API 或 AppGlideModule 时才需要相应注解处理器. 预期: 按 320x180 请求, 加载期间显示占位, 失败显示错误图; 离开 Fragment View 生命周期后请求会按宿主生命周期管理.

Glide.with(this)
    .load(imageUrl)
    .override(320, 180)
    .placeholder(R.drawable.placeholder)
    .error(R.drawable.image_error)
    .diskCacheStrategy(DiskCacheStrategy.AUTOMATIC)
    .into(binding.imageView)

缓存层级图:

请求(key = model + size + transform + signature)
  -> Active resource -> Memory LRU -> Resource disk -> Data disk -> source(network/file/provider)

数字示例: 可给自建 LruCache 的预算为运行时 maxMemory / 8, 若 maxMemory=256MiB, 容量是 32MiB; 一张 1080x720 ARGB_8888 约为 1080 x 720 x 4 = 2.97MiB, 理论仅约容纳 10 张, 未计对象与其他内存. 应通过低内存设备, 命中率和 OOM/GC 证据调整比例, 不把 1/8 当固定标准.

五, 列表, 长图与预取

• 不在主线程做大图 decode, 磁盘 I/O 或同步网络请求.
• 给列表项提供稳定尺寸, 避免用原始大图填充很小的 ImageView.
• 是否在滚动时暂停请求, 应通过 trace, 首屏命中率, 滑动帧时间和网络浪费测量; 现代图片库通常可以调度, 取消和复用请求, 不能把 “滑动必暂停” 写成通用最佳实践.
• 对可预测列表使用适量预取, 并同时约束并发数, 解码尺寸和缓存预算.
• 超长图可使用区域解码, 分块渲染或专用大图组件, 避免一次创建完整像素缓冲.

六, OOM 排查流程

1. 先判断是 Java heap, native heap, graphics, mmap 还是总体进程限制.
2. 区分持续增长的泄漏和瞬时解码 / 并发峰值.
3. 记录图片来源, 原始尺寸, 目标尺寸, 配置, 并发请求数和页面生命周期.
4. 线下结合 Memory Profiler, heap dump, LeakCanary, Perfetto/heapprofd; 线上按版本, 机型, 页面和内存档位聚合.
5. 检查缓存预算, 动画帧, 硬件 Bitmap, 列表预取和第三方库版本, 而不是看到 Bitmap 就直接调用 recycle().

七, WebP, SVG 与 GIF 的格式边界

格式选型不能只比较文件体积, 还要看透明度, 动画, 解码峰值, 目标 Android 版本和图片库的实际解码器.

WebP: 能力不等于无成本

WebP 的有损模式通常适合照片类资源, 无损模式适合需要精确边缘或透明度的图形. Android 平台从 Android 4.0 (API 14) 支持有损 WebP, 从 Android 4.2.1 (API 17) 支持无损和透明 WebP; 基于 AnimatedImageDrawable/ImageDecoder 的动画 WebP 原生支持从 Android 9 (API 28) 开始. 第三方图片库可能自带解码器, 其能力不能等同于平台能力, 必须按库版本和最低支持设备验证. 发布前应在目标设备验证静态, 透明和动画资源的显示与降级路径.

文件更小不必然加载更快. 编码格式会改变网络传输量, 也会改变解码 CPU 时间和瞬时内存. 仍应按目标视图尺寸请求, 控制并发解码, 并用 trace 或 profiler 观察滚动期间的解码与帧时间.

SVG 与 VectorDrawable: 转换有子集边界

SVG 在 Web 或专用解析器中可按视口缩放, 但 Android 的 VectorDrawable 不是任意 SVG 的完整运行时实现. 将 SVG 转为 VectorDrawable 前要检查路径, 渐变, mask, filter, text 和动画等特性是否被目标工具链支持. 对复杂 SVG, 可在构建阶段栅格化为多个目标密度资源, 或简化路径后再转矢量; 不应在列表滚动时反复解析复杂 XML / 路径.

VectorDrawable 适合尺寸变化明显的简单图标, 但路径数量过多仍会增加测量, 绘制和动画成本. 需要频繁变换或复杂动画时, 应依据目标设备上的渲染 trace 选择位图, 简化的矢量资源或其他动画方案.

GIF: 帧解码与生命周期管理

GIF 播放的成本不仅在于压缩文件体积, 还会产生当前帧, 合成缓冲和解码工作. 大尺寸, 多帧或同时播放的 GIF 容易造成内存峰值, CPU 竞争和掉帧. 将请求绑定到 Activity/Fragment/View 生命周期, 在不可见, 滚动离屏或页面停止时暂停或清理; 是否释放由所用图片库的公开 API 和版本决定, 不直接操作内部帧缓冲.

若内容需要透明, 更平滑的颜色或更高效的现代动画编码, 可评估动画 WebP 或视频; 若只是状态反馈, 优先使用短小的属性动画或 Lottie 等矢量动画方案. 替代方案都要结合最低版本, 包体, 解码成本和无障碍降动效设置验证.

高频面试题

Q1: 如何设计图片加载框架?
拆分请求建模, 生命周期, 调度与取消, 缓存 key, 多级缓存, 数据源, 解码 / 变换和观测模块. 说明去重, 优先级, 并发限制, 失败重试和内存压力下的降级策略.

Q2: Bitmap 在 native heap 后为什么仍可能 OOM?
像素内存仍属于进程内存预算, 且可能与 Java 对象, GPU 资源, 解码临时缓冲和并发请求叠加. 只观察 Java heap 会漏掉 native/graphics 峰值.

Q3: Glide 为什么能跟随页面生命周期?
RequestManager 会绑定合适的 Lifecycle / 宿主作用域, 在宿主停止或销毁时暂停或清理请求. 具体内部实现随版本和传入 Context 类型变化, 不应把某个隐藏 Fragment 实现当成永久契约.

易错点 / 追问

• 资源 ID 应使用 R.drawable.* 等可解码资源, 而不是 R.id.*.
• drawable-mdpi 等目录会参与 density 缩放; 不希望缩放的资源应评估 drawable-nodpi.
• LruCache 的容量应按字节成本计算, 而不是只按图片张数.
• inBitmap 复用受尺寸, 配置和解码器条件约束, 应交给成熟图片库或严格校验.
• 不把 Bitmap.recycle() 当现代 Android 的常规泄漏治理方法.
• EXIF 方向与采样顺序: 应先按方向校正再计算采样尺寸, 否则旋转后宽高互换会让目标尺寸算错, 解码出与预期相反的图; ImageDecoder 默认自动应用 EXIF, 手写 BitmapFactory 采样要自行处理方向.
• 异步加载竞态: 复用 ImageView 时若未在请求开始前 setImageDrawable(null) 或按请求校验, 旧请求晚返回会覆盖新位置的内容, 造成错图; 应在复用前取消旧请求或用请求 id / target 校验回写.
• Coil / AsyncImage: 基于 Kotlin 协程的图片库, AsyncImage(model = ...) 是 Compose 入口, 2024-2025 年在 Kotlin / Compose 项目中高频使用; ImageLoader 负责缓存与解码, 请求随组合作用域生命周期管理.

版本与参考资料

• 最后核验: 2026-08-07
• 适用基线: 现代 Android Bitmap API 与 Glide 4 公开行为模型
• Managing Bitmap Memory
• Loading Large Bitmaps Efficiently
• Glide caching

Jetpack 架构组件 ★

你的重点短板. Jetpack 是应用开发日常, 中级面试必问 ViewModel/LiveData/Room/Hilt 原理. 架构组织与选型见 MVVM 与 MVI, 完整落地见 App 架构落地案例.

一, ViewModel

• 作用: 持有 UI 相关数据, 在配置变更 (旋转) 时存活, 与 UI 解耦.
• 存活原理: 对外契约是同一 ViewModelStoreOwner 在配置变更后可取回同一个 ViewModel, 直到该 owner 真正结束才调用 onCleared(). 实现层面可理解为 ViewModelStore 被保留并在重建后重新关联, 历史实现中会经过 Activity 的 NonConfigurationInstance 保留链路; 面试中不要把某个内部方法名当成稳定 API 保证.
• 不要持有 View/Context 引用 (会泄漏); 需要 Context 用 AndroidViewModel (持 Application).
• SavedStateHandle: 在进程被杀重建后恢复关键数据 (配合 savedState).
• viewModelScope: 绑定 ViewModel 的协程作用域, onCleared 时取消.

二, Lifecycle

• LifecycleOwner: Activity/Fragment 实现它, 暴露 Lifecycle.
• LifecycleObserver: 观察生命周期事件, 把生命周期相关逻辑 (如开始 / 停止定位) 从组件中解耦出去.
• 现代用 DefaultLifecycleObserver 或 lifecycleScope.launch { repeatOnLifecycle(STATE) { } }.

LifecycleRegistry 状态机与派发

LifecycleRegistry 将 Owner 的生命周期表示为状态机, 对外重点是状态和事件的对应语义, 不应依赖其某个内部观察者集合或遍历实现. 常见状态为 INITIALIZED, CREATED, STARTED, RESUMED 和终态 DESTROYED.

新观察者加入后会被同步到 Owner 当前状态: 例如 Owner 已处于 STARTED, 新观察者会依序补收上行事件直到 STARTED, 而不是只等待下一次事件. Owner 上行时, 已注册观察者按前向顺序接收事件; Owner 回退时, 以相反顺序派发下行事件, 使后建立的依赖先释放. 回调中新增或移除观察者, 或再次触发状态变化属于重入情形; Registry 会以重新同步为目标处理这类变化, 因此观察者回调应保持短小, 幂等, 不应假设某次遍历期间的观察者集合或回调次数是跨版本固定的实现细节.

DESTROYED 是终态. Owner 销毁后, 与其绑定的观察关系和资源应清理, 不应期待该 Owner 或其观察者再回到 CREATED/STARTED 并恢复使用. 需要重新展示页面或重新订阅时, 应使用新建的 Owner 和新的观察关系.

使用边界:

• Activity 自身的长期 UI 资源可绑定 this 的 Lifecycle, 但仍应在不可见或停止时按业务停止昂贵工作.
• Fragment 的 View, View Binding, RecyclerView adapter 和收集 UI 状态应绑定 viewLifecycleOwner, 而不是 Fragment 生命周期, 避免 View 销毁后继续访问旧 View.
• 定位, 相机预览, 传感器和网络订阅等资源按可见性或交互状态启停; 观察者只协调开始 / 停止, 资源本身仍需处理权限, 失败, 取消和释放.
• Flow 收集使用 viewLifecycleOwner.lifecycleScope.launch { repeatOnLifecycle(Lifecycle.State.STARTED) { ... } }; 进入目标状态时启动子协程, 低于该状态时取消, View 销毁时随 owner 清理. 它适合可重新收集的 UI 流, 不替代需要持久化的业务状态或跨进程任务机制.

三, LiveData

• 生命周期感知的可观察数据持有者: 只在活跃状态 (STARTED/RESUMED) 通知观察者, 组件销毁自动移除观察, 避免泄漏和崩溃.
• setValue(主线程)/ postValue(任意线程).
• 粘性语义: 新观察者会立即收到最新状态. 不要用 SingleLiveEvent 或 SharedFlow (replay=0) 作为统一 “事件修复”; 必须处理的业务结果应归约为可恢复 UI state, 纯 UI 局部动作由 UI 直接处理.
• MediatorLiveData: 合并多个源.
• 现代项目通常用 StateFlow 表达持久状态; SharedFlow 是否适用取决于允许丢失, 重放和多订阅语义, 不能与 LiveData 做机械的一对一替换.

四, Room

• SQLite 之上的 ORM, 编译期校验 SQL.
• 三要素: @Entity(表), @Dao(数据访问接口), @Database(数据库持有者).
• 支持 协程 suspend 和 Flow 返回 (数据变化自动推送).
• 数据库迁移 Migration: 版本升级写 Migration, 否则崩溃; 开发期可 fallbackToDestructiveMigration(清库).
• 查询返回 Flow 时, 表数据变化会自动重新发射, 天然支持响应式 UI.

五, Navigation

• 定位: 单 Activity 多 Fragment/Composable 架构的导航框架, 把 “目的地, 参数, Action, Deep Link, 回退栈” 集中声明, 减少手写 FragmentTransaction/Intent flag 的分散逻辑.
• 对象关系:
  • NavHost: 承载导航内容的容器, Fragment 场景常见 NavHostFragment, Compose 场景是 NavHost Composable.
  • NavController: 执行 navigate/popBackStack 的控制器, 维护当前目的地和 back stack.
  • NavGraph: 目的地和跳转关系的图, 可来自 XML, 也可在 Compose 中用 Kotlin DSL 声明.
  • NavBackStackEntry: 回退栈条目, 携带 arguments, Lifecycle, SavedStateHandle, 也可作为 ViewModel 作用域边界.
• 导航调用流程: View 点击/Intent → 调用 NavController.navigate(route/action) → 按 NavGraph 匹配目的地与参数 → 创建或恢复目的地 → 新 NavBackStackEntry 入栈 → 目标 Fragment/Composable 渲染 → 返回时 popBackStack 出栈并恢复上一 entry.
• 回退栈 API:
  • navigate() 入栈新目的地; 可用 popUpTo 清理中间页面, 登录后清空登录流常用.
  • popBackStack() 返回上一目的地; 指定 destination/route 时可弹到某个节点.
  • launchSingleTop 避免重复点击把同一目的地压多份.
• Deep Link: 可以在图中声明 URI/Action/MIME 匹配. 外部 Intent 进入后由 Navigation 匹配目标目的地并补齐必要的 back stack; 面试要强调参数校验和未登录拦截, 不要只说 “配置一个 deepLink”.

@Composable
fun AppNavHost(navController: NavHostController = rememberNavController()) {
    NavHost(navController = navController, startDestination = "home") {
        composable("home") {
            HomeScreen(onOpenDetail = { id -> navController.navigate("detail/$id") })
        }
        composable(
            route = "detail/{id}",
            arguments = listOf(navArgument("id") { type = NavType.StringType }),
        ) { entry ->
            DetailScreen(id = entry.arguments?.getString("id") ?: return@composable)
        }
    }
}

类型安全路由 (Navigation 2.8+): Navigation Compose / Kotlin DSL 内置, 官方视作 XML 图时代 Safe Args 的等价物. 用 @Serializable 标注路由类型 (object Home / data class Profile(val id: String)), composable<T>() 声明目的地, navigate(Profile(id)) 跳转, toRoute<T>() 取参, 免手写字符串 route 与 navArgument.

• 弃字符串 route 的原因: 拼写错误无编译期校验, 参数名 / 类型易错且运行期才暴露; 新代码优先类型安全, 字符串 route 退居旧项目 / 简单跳转.

常见错误:

• 在多个页面散落手写跳转字符串, 导致参数名 / route 不一致; 可用常量, 封装 route builder 或 Safe Args 降低风险.
• 登录, 首页, 详情都压入同一栈后不清理, 返回路径混乱; 需要明确 popUpTo 和 inclusive.
• 把未建模的 navigate=true 永久留在 State 会造成重复导航. 用户点击产生的导航由 UI 直接执行; 若导航依赖业务完成结果, ViewModel 先写入可消费 / 可清除的状态, UI 观察后导航并回调确认. 不使用 SharedFlow (replay=0) 假装获得可靠投递.
• Deep Link 只做跳转不做鉴权和参数兜底, 容易打开非法状态页面.

面试答题结构: 先说 “NavGraph + NavHost + NavController” 三件套 → 再讲 back stack entry 的入栈/出栈流程 → 补 Compose/XML 两种写法 → 最后说 deep link, 参数安全, 重复导航与登录栈清理.

六, Hilt (依赖注入)

• 基于 Dagger 的 Android 专用 DI 封装, 大幅减少模板代码.
• 核心注解: @HiltAndroidApp(Application), @AndroidEntryPoint(注入到组件), @Inject(构造注入), @Module + @Provides/@Binds(提供无法构造注入的依赖), @HiltViewModel(注入 ViewModel).
• 作用域: @Singleton, @ActivityScoped, @ViewModelScoped 等, 控制实例生命周期.
• Hilt vs Dagger: Hilt 预定义了 Android 组件的标准注入点和组件层级, 开箱即用; Dagger 更灵活但配置繁琐.
• DI 的意义: 解耦, 可测试 (可替换 mock 实现), 统一管理对象创建.

Room + Hilt + ViewModel + DataStore 最小链路

上下文片段: 此最小工程片段需 Room, Hilt, DataStore Preferences, Lifecycle ViewModel 和 KSP/KAPT 依赖; Application 标注 @HiltAndroidApp, Activity/Fragment 标注 @AndroidEntryPoint. 省略 imports, Gradle 配置与 UI 收集. 插入用户后 observeUsers() 预期发射包含该用户的列表; 从数据库版本 1 升至 2 时执行列新增 migration, 而非清库.

@Entity(tableName = "users") data class UserEntity(@PrimaryKey val id: String, val name: String)
@Dao interface UserDao { @Query("SELECT * FROM users") fun observeUsers(): Flow<List<UserEntity>>; @Insert(onConflict = OnConflictStrategy.REPLACE) suspend fun upsert(user: UserEntity) }
@Database(entities = [UserEntity::class], version = 2) abstract class AppDatabase : RoomDatabase() { abstract fun userDao(): UserDao }
val MIGRATION_1_2 = object : Migration(1, 2) { override fun migrate(db: SupportSQLiteDatabase) { db.execSQL("ALTER TABLE users ADD COLUMN name TEXT NOT NULL DEFAULT ''") } }

@Module @InstallIn(SingletonComponent::class) object AppModule {
    @Provides @Singleton fun db(@ApplicationContext context: Context) = Room.databaseBuilder(context, AppDatabase::class.java, "app.db").addMigrations(MIGRATION_1_2).build()
    @Provides fun dao(db: AppDatabase): UserDao = db.userDao()
}
val Context.dataStore by preferencesDataStore("settings")
@HiltViewModel class UsersViewModel @Inject constructor(dao: UserDao, @ApplicationContext context: Context, private val savedState: SavedStateHandle) : ViewModel() {
    val users = dao.observeUsers().stateIn(viewModelScope, SharingStarted.WhileSubscribed(5_000), emptyList())
    val darkMode = context.dataStore.data.map { it[booleanPreferencesKey("dark_mode")] ?: false }
}

DataStore 适合保存小型偏好而不是用户表, 上例已将其读取实际接入 ViewModel. Hilt 层级是 SingletonComponent -> ActivityRetainedComponent -> (ViewModelComponent, ActivityComponent -> FragmentComponent): ViewModelComponent 与 ActivityComponent 是并列分支, 不能把前者说成后者的父/子组件. 对象 scope 必须与其持有资源的生命周期匹配. 迁移失败的症状是升级崩溃或 schema 校验失败, 证据是 migration test/升级安装日志, 修复是补齐从旧版本到新版本的迁移并验证保留旧数据.

上下文片段 (RemoteMediator 写库): db 是同一 Room 数据库, productDao/remoteKeyDao 分别操作列表和分页 key; 网络页已成功映射为 entities. 刷新时必须在一个 withTransaction 中同时清旧数据, 写新数据和更新 remote keys, 预期任一步抛异常时整笔事务回滚, UI 继续观察旧的一致快照而不会看到 “新列表配旧 key”.

db.withTransaction {
    if (loadType == LoadType.REFRESH) {
        remoteKeyDao.clear()
        productDao.clear()
    }
    productDao.insertAll(page.products.map(::ProductEntity))
    remoteKeyDao.insertAll(page.products.map { RemoteKey(it.id, page.nextKey) })
}

七, DataStore / WorkManager / Paging

• SharedPreferences 一致性边界: SP 会维护进程内缓存, 同一进程内的常规读写由实现同步协调, 但这不等于它提供跨进程事务或多进程一致性保证. commit() 会在调用线程同步写磁盘并返回成功与否, 因此不应放在主线程热路径; apply() 会先更新内存并异步调度落盘, 不返回写入结果, 进程异常终止或写入失败时不能把它当成已持久化确认. 多个进程同时访问, 旧的多进程模式或非原子修改会带来陈旧读, 覆盖和文件损坏风险, 不应将 SP 作为跨进程共享状态通道.
• 迁移方向与版本边界: 新代码优先使用 DataStore 保存小型偏好, 其中 Preferences DataStore 保留键值模型, Proto DataStore 提供 schema 与类型约束; 通过迁移在首次访问时将已知 SP 键复制到目标存储并验证迁移后行为. 默认的单进程 DataStoreFactory/preferencesDataStore 不是自动多进程方案. DataStore 1.1.0+ 的 MultiProcessDataStoreFactory 才用于多个进程访问同一文件; 每个进程对该文件只能创建一个实例, 且所有进程必须使用多进程工厂, 不可与普通实现混用同一路径. 不需要多进程存储时, 跨进程数据仍应由带明确并发与访问控制契约的 Provider, 数据库或服务接口承担. 保留 SP 的旧版本应先定义数据归属, 迁移窗口和回退读取策略, 不让两端长期双写.
• DataStore: 替代 SharedPreferences. 基于协程 + Flow, 异步, 事务安全; 正确使用异步 API 可降低常见主线程磁盘 IO 风险, 但阻塞式误用, 迁移或上游工作仍可能造成卡顿. 两种: Preferences DataStore (键值), Proto DataStore (类型安全). SP 的 apply() 会先更新内存再异步持久化, 但待落盘写入及其与生命周期的交互仍可能导致卡顿; getXXX 也可能带来主线程 IO 风险, 且无类型安全.
• WorkManager: 用于可延迟, 可持久化且期望最终执行的后台任务, 即使 App 退出 / 重启后也可由系统重新调度. 执行时间不精确, 强行停止应用和系统约束等是边界. 支持约束 (网络, 充电), 链式, 周期任务. 底层 API 23+ 用 JobScheduler, 低版本历史上用 GcmNetworkManager (已弃用), 现退化为 AlarmManager 兜底与重启重调度. 适合上传日志, 同步数据.
• Paging3: 分页加载大列表, 核心是 PagingSource → Pager → Flow<PagingData<T>> → UI Adapter/Compose.
  • PagingSource<Key, Value>: 定义 load(params) 如何按页加载数据, 返回 LoadResult.Page/Error; getRefreshKey() 决定刷新时从哪里继续.
  • Pager: 接收 PagingConfig 和 pagingSourceFactory, 把分页请求包装成 Flow<PagingData<T>>.
  • PagingData: 一次分页会话的数据流, UI 侧通过 collectAsLazyPagingItems() 或 PagingDataAdapter.submitData() 消费.
  • RemoteMediator: 网络 + 本地数据库场景的协调器, 负责判断何时从网络拉新页, 写入 Room, UI 实际从 Room 的 PagingSource 读取, 形成单一数据源.

class UserPagingSource(private val api: UserApi) : PagingSource<Int, User>() {
    override suspend fun load(params: LoadParams<Int>): LoadResult<Int, User> = try {
        val page = params.key ?: 1
        val users = api.users(page = page, size = params.loadSize)
        LoadResult.Page(
            data = users,
            prevKey = if (page == 1) null else page - 1,
            nextKey = if (users.isEmpty()) null else page + 1,
        )
    } catch (t: Throwable) {
        LoadResult.Error(t)
    }

    override fun getRefreshKey(state: PagingState<Int, User>): Int? =
        state.anchorPosition?.let { anchor ->
            state.closestPageToPosition(anchor)?.prevKey?.plus(1)
                ?: state.closestPageToPosition(anchor)?.nextKey?.minus(1)
        }
}

val users: Flow<PagingData<User>> = Pager(
    config = PagingConfig(pageSize = 20, prefetchDistance = 5),
    pagingSourceFactory = { UserPagingSource(api) },
).flow.cachedIn(viewModelScope)

RemoteMediator 流程: UI 触发刷新/滑到底 → Paging 判断需要加载 → RemoteMediator.load(REFRESH/PREPEND/APPEND) 请求网络 → 事务写入 Room + remote keys → Room 的 PagingSource 失效并重新发射 → UI 收到新的 PagingData. 这种方式适合离线缓存, 列表恢复, 网络与本地一致性要求高的页面.

UI 集成要点:

• RecyclerView 用 PagingDataAdapter + LoadStateAdapter 展示刷新, 加载更多, 错误重试.
• Compose 用 collectAsLazyPagingItems() 和 LazyColumn.items(count); 根据 loadState.refresh/append 渲染首屏 loading, 尾部 loading, 错误重试.
• 在 ViewModel 中 cachedIn(viewModelScope), 避免旋转屏幕后重新创建分页流导致重复请求.

常见错误:

• PagingSource 同时读网络和本地且没有一致性策略, 刷新 / 翻页状态难维护; 复杂缓存场景应考虑 RemoteMediator + Room.
• 忘记实现合理的 getRefreshKey, 刷新后列表跳到错误位置.
• 不处理 LoadState, 用户看不到加载, 错误, 重试状态.
• 每次 UI 重组 / 重建都新建 Pager, 导致重复加载; 应让分页流由 ViewModel 持有并缓存.

面试答题结构: 先说 “PagingSource 负责加载一页, Pager 产出 PagingData Flow, UI 订阅渲染” → 再补 “RemoteMediator 用于网络 + 数据库单一数据源” → 最后讲 cachedIn, LoadState, 刷新 key, 错误重试这些工程坑.

高频面试题

Q1: ViewModel 为什么能在旋转屏幕后存活? 旋转是配置变更, Activity/Fragment 会重建, 但同一 ViewModelStoreOwner 的 ViewModelStore 会在配置变更后重新关联, 因此可取回同一个 ViewModel 实例. 历史实现可从 NonConfigurationInstance 保留链路理解, 但对外稳定契约是 “配置变更存活, owner 真正结束时 onCleared”, 不要依赖内部方法名.

Q2: ViewModel 能持有 Context 吗? 不能持有 Activity/View Context (泄漏).需要 Application Context 时用 AndroidViewModel. 原则: ViewModel 不感知 UI.

Q3: LiveData 的粘性语义对 UI 事件有什么影响? 新观察者会收到最新状态, 因而不适合直接承载未设计消费语义的动作. 不推荐用 SingleLiveEvent, Event wrapper 或 SharedFlow (replay=0) 作为统一补丁: 必须处理的业务结果进入可恢复 UI state, UI 处理后回调确认; 用户本地导航由 UI 直接触发; 允许丢失的瞬时效果才使用事件流.

Q4: LiveData 和 StateFlow 怎么选? 新项目优先 StateFlow (纯 Kotlin, 操作符丰富, 与协程统一), 需配 repeatOnLifecycle 做生命周期安全收集; 老项目 / 简单场景 LiveData 自带生命周期感知更省事.

Q5: Room 相比直接用 SQLite 的优势? 编译期校验 SQL, 减少样板代码, 对象映射, 原生支持协程和 Flow (数据变化自动推送), 迁移管理.

Q6: 为什么用 DataStore 替代 SharedPreferences? SP 有主线程 IO 风险, apply() 会先更新内存再异步持久化, 但待落盘写入及其与生命周期的交互仍可能导致卡顿, 且无类型安全, 无错误信号. DataStore 基于协程 + Flow, 异步, 事务, 类型安全 (Proto), 但仍要避免阻塞式误用, 迁移或上游工作造成卡顿.

Q7: Hilt 和 Dagger 关系? DI 解决什么问题? Hilt 是 Dagger 的 Android 封装, 预置组件层级和注入点. DI 解决对象创建与依赖管理: 解耦, 便于替换实现做单元测试, 避免手动 new 的耦合.

Q8: 什么任务适合 WorkManager? 和协程 / Service 怎么区分? 适合 “可延迟, 可持久化且期望最终执行” 的后台任务 (日志上传, 数据同步), 即使进程被杀 / 重启也可由系统重新调度; 不保证精确时间, 强行停止应用和系统约束是边界. 即时 UI 相关异步用协程; 需要持续运行的用前台 Service.

Q9: Navigation 的回退栈怎么理解? NavController 根据 NavGraph 导航时会把目的地包装成 NavBackStackEntry 入栈, entry 携带参数, 生命周期和状态. 返回时 popBackStack 弹出当前 entry 并恢复上一个; 登录流, 首页清栈要用 popUpTo/launchSingleTop 控制, 避免重复页面和错误返回路径.

Q10: Paging3 的三件套是什么? RemoteMediator 解决什么? PagingSource 负责按 key 加载一页数据, Pager 把它包装成 PagingData 流, UI 用 PagingDataAdapter 或 Compose LazyPagingItems 渲染. RemoteMediator 用于网络 + 本地数据库: 网络结果写入 Room, UI 从 Room 读, 实现离线缓存和单一数据源.

易错点 / 追问

• ViewModel 持有 Activity/View/Context 引用是泄漏: 需要 Application Context 时用 AndroidViewModel, 页面级资源一律绑定 viewLifecycleOwner.
• 混用 viewLifecycleOwner 与 Fragment 的 lifecycleOwner: View 销毁后仍访问旧 View; Flow 收集用 repeatOnLifecycle.
• 用 SingleLiveEvent / SharedFlow (replay=0) 当统一 “事件修复”: 无 collector 时丢值; 必须处理的业务结果归约为可恢复 UI state.
• Room 升级不写 Migration: 升级后 schema 校验失败直接崩溃; fallbackToDestructiveMigration 只清库, 不能当发布方案.
• Navigation 字符串 route 散落各处且参数无编译期校验, 登录后不清栈导致返回路径混乱; 新代码优先类型安全路由 + popUpTo.
• Hilt scope 与资源生命周期不匹配: 过长泄漏, 过短重复创建; ViewModelComponent 与 ActivityComponent 是并列分支, 不是父子.
• 把 SP apply() 当已持久化确认, 或用默认 DataStore 工厂跨进程访问: 都不提供跨进程一致性; 多进程须用 MultiProcessDataStoreFactory 并全进程统一.
• Paging 不实现 getRefreshKey / 不处理 LoadState / 每次重组新建 Pager: 刷新跳位, 用户看不到加载错误态, 重复请求; 分页流应由 ViewModel 持有并 cachedIn.

进阶补充: Hilt, Room, WorkManager 与 Compose 生命周期

Hilt 组件层级与作用域

常见层级: SingletonComponent → ActivityRetainedComponent, 其下分为 ViewModelComponent 与 ActivityComponent, 再由 ActivityComponent → FragmentComponent. 作用域要和生命周期匹配, 不要把短生命周期对象注入成单例.

Qualifier 与 Assisted Injection

同类型多个实现用 @Qualifier 区分; 运行时参数可用 assisted injection 或 ViewModel 的 SavedStateHandle.

Room 迁移与 TypeConverter

Room migration 要显式描述 schema 变化, 不能依赖删除重建. 复杂类型用 TypeConverter, 关系查询要注意 N+1 和事务一致性.

collectAsStateWithLifecycle

Compose 收集 Flow 推荐用 lifecycle-aware API, 避免页面不可见时仍持续收集.

WorkManager 约束和退避

WorkManager 适合可延迟, 可持久化且期望最终执行的后台任务. 约束包括网络, 充电, 空闲; 失败可配置 backoff 和 unique work policy, 但执行时间不精确且受系统与强行停止应用等边界影响.

后台任务与状态恢复决策矩阵

选择机制时依次回答五个问题:

1. 工作是否必须跨页面, 进程死亡或设备重启继续?
2. 用户是否需要实时看到持续执行和通知?
3. 是要求精确触发时间, 还是只要求满足约束后最终执行?
4. 取消由谁触发, 已完成一半时如何清理或恢复?
5. 重试会不会重复扣款, 重复上传或覆盖新数据?

WorkManager 的 Result.retry() 只是请求以后重试, 不等于业务天然可靠. Worker 应使用稳定业务 ID 做幂等, 持久化阶段进度, 为网络和电量设置约束, 区分可重试错误与永久错误, 并为取消实现协作式清理. 周期任务也不是精确定时器, 系统可以为了省电合并和延迟执行.

追问: 为什么 Hilt scope 不能乱用? 因为对象生命周期过长会造成泄漏, 过短会导致重复创建和状态丢失.

应用架构 - MVVM 与 MVI ★

你的重点短板, 中级必考. 面试常问 “你项目用什么架构? 为什么?”, 要答得出演进逻辑和取舍. 组件基础见 Jetpack 架构组件, 完整落地见 App 架构落地案例.

一, 架构演进

核心趋势:职责分离 → 解耦 View 与逻辑 → 数据驱动 UI → 单向数据流.

二, MVVM

• View(Activity/Fragment/Composable):只负责展示和转发用户操作, 订阅 ViewModel 的数据.
• ViewModel: 持有 UI 状态和业务逻辑入口, 不引用 View, 通过 LiveData/StateFlow 暴露数据.
• Model: 数据层 (Repository + 数据源).
• 数据绑定: View 观察 ViewModel 的可观察数据, 数据变 UI 自动更新.

class UserViewModel(private val repo: UserRepo) : ViewModel() {
    private val _user = MutableStateFlow<User?>(null)
    val user: StateFlow<User?> = _user.asStateFlow()
    fun load(id: String) = viewModelScope.launch {
        _user.value = repo.getUser(id)
    }
}

MVVM 的问题: 多个 LiveData/StateFlow 分散表达状态 (loading/data/error 各一个), 状态可能不一致, 难追踪 “当前完整 UI 状态”.MVI 就是来解决这个的.

三, MVP 的 View 解绑与异步边界

MVP 中 Presenter 可以持有 View 接口, 但必须在 View 销毁时释放引用. 否则异步任务完成后可能回调已销毁的 Activity 或 Fragment, 既造成错误 UI 更新, 也可能延长 View 的存活时间.

下例是最小示意代码, 用于说明生命周期回调和异步竞态, 不是完整的生产实现. onStop() 是否解绑要按页面是否会在后台继续展示结果决定; 对不应跨出页面生命周期的工作, 应优先取消任务.

interface ProfileView {
    fun showProfile(profile: Profile)
    fun showError(message: String)
}

class ProfilePresenter(
    private val repository: ProfileRepository,
    private val mainDispatcher: CoroutineDispatcher = Dispatchers.Main.immediate,
    private val ioDispatcher: CoroutineDispatcher = Dispatchers.IO,
) {
    // This scope is created for each attached View and closed in detachView().
    private var scope: CoroutineScope? = null
    private var view: ProfileView? = null
    private var loadJob: Job? = null

    fun attachView(view: ProfileView) {
        scope?.cancel()
        scope = CoroutineScope(SupervisorJob() + mainDispatcher)
        this.view = view
    }

    fun loadProfile(id: String) {
        val activeScope = scope ?: return
        loadJob?.cancel()
        loadJob = activeScope.launch {
            try {
                val profile = withContext(ioDispatcher) {
                    repository.loadProfile(id)
                }
                view?.showProfile(profile)
            } catch (error: CancellationException) {
                throw error
            } catch (error: Exception) {
                view?.showError(error.message ?: "加载失败")
            }
        }
    }

    fun detachView() {
        view = null
        loadJob?.cancel()
        loadJob = null
        scope?.cancel()
        scope = null
    }
}

class ProfileFragment : Fragment(), ProfileView {
    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        presenter.attachView(this)
    }

    override fun onDestroyView() {
        presenter.detachView()
        super.onDestroyView()
    }

    override fun showProfile(profile: Profile) {
        // Render the profile in the current Fragment View.
    }

    override fun showError(message: String) {
        // Render an error only while the Fragment View exists.
    }
}

示例中的 scope 由 Presenter 所有, 每次 attachView() 都基于 mainDispatcher 创建一个绑定 View 生命周期的 scope; 默认值是 Dispatchers.Main.immediate, 因而所有 View 回调在主线程. detachView() 会取消并清空 scope, 所以同一个 Fragment 实例在 onDestroyView() 后再次 onViewCreated() 时可重新绑定; 未绑定 View 时 loadProfile() 直接返回. Repository 调用默认切到 Dispatchers.IO, 返回后自动回到 Main. Dispatcher 可注入, 使测试以确定性 dispatcher 驱动; 生产注入值仍必须保证 UI 更新在 Main. view?.showProfile(...) 只是在异步返回时避免调用已解绑的 View, 不能替代任务管理: 长期任务即使不更新 UI, 仍可能持续占用网络, CPU 或持有其他资源. CancellationException 必须重抛; 业务或预期运行失败才按 Exception 处理, 不要捕获 Throwable. 按工作所有权选择处理方式:

Fragment 的 View 生命周期与 Fragment 实例不同, 因此在 onDestroyView() 解绑比等到 onDestroy() 更符合 View 引用的实际存活期. 生命周期语境见 Android 四大组件与基础, 协程取消与结构化并发边界见 多线程并发专题.

MVP Presenter 的最小测试策略

MVP 的可测性来自边界设计: Presenter 只依赖 View 接口与 Repository 接口, 不持有 Android 框架对象, 可在纯 JVM 上注入 fake/mock 观察回调, 并注入 TestDispatcher 驱动虚拟时间. 测试的重点是解绑与取消: 至少覆盖成功回调, 预期失败回调, 以及 detachView() 后任务被取消且不再回调旧 View.

具体测试代码, 分层和工具见 见 16 的「协程与 Flow 测试」与「Fake 优先于过度 Mock」小节, 本节只保留可测性原理, 不重复其配置细节.

四, MVI (Model-View-Intent)

核心思想:单一数据源 + 单向数据流 (UDF).

• State: 用一个不可变对象描述整个 UI 状态 (data class UiState(val isLoading, val data, val error)).
• Intent(也叫 Event/Action):用户意图 (点击, 刷新), 是进入系统的唯一入口.
• 单向流: Intent → ViewModel 处理 → 产出新 State → View 渲染. 状态只能由 ViewModel 产出, View 不能直接改.
• Effect / 动作: 先区分可靠性. 用户点击触发的导航由 UI 直接处理; 必须保证处理的业务结果进入 State; 只有允许丢失的纯 UI 瞬时效果才使用独立事件流.

data class UiState(
    val isLoading: Boolean = false,
    val items: List<Item> = emptyList(),
    val error: String? = null,
)
sealed interface UiIntent {
    data object Refresh : UiIntent
    data class Click(val id: String) : UiIntent
}
class MyViewModel : ViewModel() {
    private val _state = MutableStateFlow(UiState())
    val state: StateFlow<UiState> = _state.asStateFlow()
    fun onIntent(intent: UiIntent) = when (intent) {
        UiIntent.Refresh -> refresh()
        is UiIntent.Click -> openDetail(intent.id)
    }
}

五, 官方推荐分层架构

Google 推荐三层 (配合单 Activity + Jetpack), 但它是可按复杂度裁剪的参考架构, 不是所有页面都必须机械套满三层:

• UI 层: Composable/Fragment + ViewModel + UiState. 只做展示和事件转发.
• Domain 层 (可选): UseCase 封装单一业务用例, 复用复杂逻辑, 降低 ViewModel 体积.
• Data 层: Repository (对外唯一数据入口)+ DataSource (网络 / 本地). Repository 决定数据来源, 缓存策略, 做单一数据源 (SSOT).

依赖方向单向向下: UI → Domain → Data, 上层依赖下层抽象 (依赖倒置).

六, 可测试性

• ViewModel 不依赖 Android 框架 (不持 Context/View), 可纯 JUnit 测试.
• Repository/UseCase 通过接口注入 (Hilt), 测试时替换为 fake/mock.
• 协程测试用 runTest + TestDispatcher, Flow 测试用 Turbine.

七, 同一页面的 MVVM/MVI 对比与选型

以 “商品列表刷新” 为例, 二者都可以使用 StateFlow 和 Repository, 区别在状态组织和事件入口, 不是 “一个先进, 一个落后”.

上下文片段: 下例是 MVI reducer 的可单元测试核心, Product, Repository 和协程启动代码省略. 输入 Refresh 时预期 loading 为 true 且清除旧错误; 成功事件后预期替换 items, 关闭 loading. 它不是完整 Android 页面.

data class ProductState(val loading: Boolean = false, val items: List<Product> = emptyList(), val error: String? = null)
sealed interface ProductEvent { data object Refresh : ProductEvent; data class Loaded(val items: List<Product>) : ProductEvent; data class Failed(val message: String) : ProductEvent }
fun reduce(old: ProductState, event: ProductEvent): ProductState = when (event) {
    ProductEvent.Refresh -> old.copy(loading = true, error = null)
    is ProductEvent.Loaded -> old.copy(loading = false, items = event.items)
    is ProductEvent.Failed -> old.copy(loading = false, error = event.message)
}

UDF trace: UI click/refresh -> Intent/Event -> ViewModel reducer + use case -> new immutable UiState -> UI render; 数据访问为 ViewModel -> Repository -> local/remote data.

选型顺序: 先画页面状态, 事件和失败恢复; 状态少且调用链短时使用收敛状态的 MVVM; 存在并发事件, 分页, 步骤流或需严格审计转移时用 reducer 风格 MVI; 若 reducer 只做转发, 阅读成本高, 则回退到 MVVM. 对风控 / 设备指纹这类需要排查与审计的场景, MVI 的单一 State 可序列化回放, 便于复现问题链路和审计每次状态转移, 是选型时的一个加分论点. 两者都应保持 UI 不直接访问数据源, 业务状态可恢复, 依赖可替换. 完整 UI 到 DataSource, 分页和离线实现见 App 架构落地案例.

高频面试题

Q1: MVP 和 MVVM 区别? MVP: Presenter 持有 View 接口, 双向手动调用, 需解绑防泄漏, 接口多. MVVM: ViewModel 不持有 View, 通过可观察数据 (LiveData/StateFlow) 单向通知, View 订阅, 解耦更彻底.

Q2: MVVM 和 MVI 区别? MVI 解决什么? MVVM 状态分散在多个 LiveData/StateFlow, 可能不一致, 难追踪. MVI 用单一不可变 State 描述整个 UI, 单向数据流, Intent 作唯一入口, 状态可预测, 易调试, 易回放. 代价是模板代码多.

Q3: 为什么 ViewModel 里不能直接更新 UI? ViewModel 不应感知 View (否则耦合 + 泄漏 + 不可测).它只产出状态, 由 View 订阅后自行渲染, 保持单向数据流.

Q4: Repository 模式的作用? 作为数据层唯一入口, 对上层屏蔽数据来源 (网络/缓存/数据库), 实现单一数据源, 缓存策略, 离线支持, 使 ViewModel 不关心数据从哪来.

Q5: UseCase (Interactor) 有必要吗? 非必须. 当业务逻辑复杂, 需被多个 ViewModel 复用, 或 ViewModel 过于臃肿时引入, 封装单一业务用例, 提升复用和可测试性. 简单页面可省略.

Q6: Toast / 导航应该放进 State 还是事件流? 不能按控件类型简单二分. 用户点击产生的导航由 UI 直接处理; 必须保证处理的业务结果进入可恢复 State, UI 处理后回调确认; 只有明确允许丢失的瞬时效果才使用 Channel/SharedFlow. replay=0 在无 collector 时会丢值, 不能提供恰好一次保证.

Q7: 你项目用什么架构? 为什么这么选?(开放题) 结合实际答: 中小页面 MVVM 足够轻量; 复杂交互/状态多的页面用 MVI 保证可预测性. 强调 “按复杂度选型”, 并说明分层 (UI/Domain/Data), 单一数据源, 依赖注入带来的可测试性收益.

易错点 / 追问

• MVP 等到 onDestroy() 才解绑: View 生命周期在 onDestroyView() 已结束, 之后回调会更新已销毁的 View; 解绑时机匹配 View 引用实际存活期.
• 捕获 CancellationException 不重抛: 破坏协程取消; 业务失败才按 Exception 处理, 不要捕获 Throwable.
• 状态分散在多个 LiveData/StateFlow: loading/data/error 各自为流容易不一致; 页面状态应收敛为单一 state, 再决定是否需要 MVI.
• MVI reducer 只做转发不归约: 模板成本高于收益; 状态少且调用链短时回退到收敛状态的 MVVM.
• 用 SharedFlow (replay=0) 传递必须可靠的事件: 无 collector 时丢值; 必须处理的业务结果进 State, UI 处理后回调确认.
• UI 层直接访问 Repository/DataSource, 或 Repository 按方法而非业务聚合切分: 破坏单向数据流和可测性, 过细会退化成无意义转发层.

落地边界

本篇止于定义, 同页对照, UDF 与选型. UI 到 Repository/DataSource 的完整链路, Offline-first, 分页失败恢复及 requestId 幂等, 统一见 App 架构落地案例, 避免同一案例在两篇重复维护.

追问: Repository 是不是越多越好? 不是. Repository 应按数据 / 业务聚合边界划分, 过细会变成无意义转发层.

App 架构落地案例

架构题不要只背 MVVM/MVI 名词. 面试官更想听到: 一个真实页面从 UI 到 ViewModel, UseCase, Repository, DataSource 怎么流动, 异常, 分页, 表单, 离线缓存怎么统一收口. 前置: 组件与架构概念见 Jetpack 架构组件 与 MVVM 与 MVI.

一, 完整页面流: UI → ViewModel → UseCase → Repository → DataSource

以 “商品列表 + 筛选 + 收藏 + 分页” 为例, 推荐链路是单向的:

Screen/Fragment/Composable
  -> ViewModel: 接收 UI Intent,维护 UiState
  -> UseCase: 封装业务规则,如筛选参数校验,收藏权限判断
  -> Repository: 决定网络/缓存/数据库数据来源,合并多源
  -> RemoteDataSource / LocalDataSource: Retrofit/Room/DataStore

核心原则:

• UI 不直接访问 Retrofit/Room, 只渲染 UiState 并发送用户意图.
• ViewModel 不写复杂数据来源选择, 把业务规则交给 UseCase/Repository.
• Repository 对上层暴露稳定模型, 隐藏网络 DTO, 数据库 Entity 的差异.

二, 统一 UI 状态: loading / error / empty / content

不要用多个互相独立的 Boolean 到处散落, 推荐一个不可变 UiState 表达完整页面状态.

跨文件上下文骨架

跨文件上下文骨架: 以下案例需要 Compose Material 3, lifecycle-runtime-compose, Room, Retrofit (或等价实现) 和 Hilt/手动注入. 为聚焦链路, 省略实体/DTO 映射, 数据库建表, DI, imports, 网络实现和错误文案资源; 因此它不是可直接复制编译的单文件示例. MVVM/MVI 概念与选型见 架构概念与选型.

data class ProductUi(val id: String, val title: String)
data class ProductFilter(val categoryId: String?)
data class RequestToken(
    val generation: Long,
    val filterSnapshot: ProductFilter,
)
data class AppendState(
    val hasMore: Boolean,
    val nextPageKey: String?,
    val failedPageKey: String?,
)
data class ActivationResult(val token: RequestToken, val initialAppendState: AppendState)
sealed interface GuardedWriteResult {
    data class Applied(val appendState: AppendState) : GuardedWriteResult
    data object Stale : GuardedWriteResult
}
data class ProductListState(val items: List<ProductUi> = emptyList(), val isLoading: Boolean = false, val isRefreshing: Boolean = false, val error: UiError? = null, val append: AppendState? = null) { val isEmpty get() = !isLoading && items.isEmpty() && error == null }
interface ProductRepository {
    fun observeProducts(filter: ProductFilter): Flow<List<Product>>
    suspend fun activateGeneration(filter: ProductFilter): ActivationResult
    suspend fun refresh(token: RequestToken): Result<GuardedWriteResult>
    suspend fun loadMore(pageKey: String, token: RequestToken): Result<GuardedWriteResult>
}
interface LocalProductDataSource {
    fun observeProducts(filter: ProductFilter): Flow<List<Product>>
    suspend fun activateGeneration(filter: ProductFilter): ActivationResult
    suspend fun writeRefreshIfCurrent(token: RequestToken, expectedPageKey: String?, page: ProductPage): GuardedWriteResult
    suspend fun writeAppendIfCurrent(token: RequestToken, expectedPageKey: String, page: ProductPage): GuardedWriteResult
}
interface RemoteProductDataSource { suspend fun fetchPage(pageKey: String?): ProductPage }
// Repository.refresh/loadMore: remote.fetchPage(...) 后直接返回 Local 的 guarded write 结果.
// Local 的两个 guarded write 均在一个 Room 事务中:验证 -> 写实体和 remote key ->
// return Applied(remoteKey.toAppendState());验证失败 return Stale.
private enum class RequestPhase { Idle, Loading, Failed }
private data class RequestState(val phase: RequestPhase = RequestPhase.Loading, val error: UiError? = null, val append: AppendState? = null)
class ProductViewModel(private val repository: ProductRepository) : ViewModel() {
    // 仓库快照和请求阶段是唯一事实来源;不要把展示用 items 再存一份到 transient state.
    private val filter = MutableStateFlow(ProductFilter(categoryId = null))
    private val products = filter.flatMapLatest(repository::observeProducts)
        .map { source -> source.map { ProductUi(it.id, it.title) } }
        .stateIn(viewModelScope, SharingStarted.Eagerly, emptyList())
    private val request = MutableStateFlow(RequestState())
    private var currentToken: RequestToken? = null
    private fun isCurrent(token: RequestToken): Boolean =
        currentToken == token && currentToken?.generation == token.generation
    val state = combine(products, request) { items, current -> ProductListState(
        items = items,
        isLoading = current.phase == RequestPhase.Loading && items.isEmpty(),
        isRefreshing = current.phase == RequestPhase.Loading && items.isNotEmpty(),
        error = current.error,
        append = current.append,
    ) }
        .stateIn(viewModelScope, SharingStarted.WhileSubscribed(5_000), ProductListState(isLoading = true))
    init { refresh() }
    fun refresh(newFilter: ProductFilter = filter.value) = viewModelScope.launch {
        // 此调用的成功提交是刷新线性化点;返回前绝不发布新 token.
        val activation = repository.activateGeneration(newFilter)
        val token = activation.token
        // 多个 refresh 协程恢复顺序可不同;只发布尚未被更高持久化 generation 取代的 token.
        if (currentToken?.generation?.let { it >= token.generation } == true) return@launch
        currentToken = token
        filter.value = token.filterSnapshot
        request.value = RequestState(phase = RequestPhase.Loading, append = activation.initialAppendState)
        repository.refresh(token).onSuccess { write ->
            if (!isCurrent(token)) return@onSuccess
            when (write) {
                is GuardedWriteResult.Applied -> request.update {
                    it.copy(phase = RequestPhase.Idle, error = null, append = write.appendState)
                }
                GuardedWriteResult.Stale -> Unit
            }
        }.onFailure { error ->
            if (isCurrent(token)) request.update {
                it.copy(phase = RequestPhase.Failed, error = UiError(error.message ?: "刷新失败"))
            }
        }
    }
    fun retryMore() = request.value.append?.failedPageKey?.let(::loadMore)
    fun loadMore(pageKey: String) = viewModelScope.launch {
        val token = currentToken ?: return@launch
        val append = request.value.append ?: return@launch
        if (!append.hasMore || pageKey != append.nextPageKey) return@launch
        // Flight registry 只按 (token, pageKey) 原子预留或共享网络 Deferred.
        repository.loadMore(pageKey, token).onSuccess { write ->
            if (!isCurrent(token)) return@onSuccess
            when (write) {
                is GuardedWriteResult.Applied -> request.update { it.copy(append = write.appendState) }
                GuardedWriteResult.Stale -> Unit
            }
        }.onFailure {
            if (isCurrent(token)) request.update {
                it.copy(append = it.append?.copy(failedPageKey = pageKey))
            }
        }
    }
}
@Composable fun ProductPage(vm: ProductViewModel) {
    val state by vm.state.collectAsStateWithLifecycle()
    Scaffold(topBar = { TopAppBar(title = { Text("商品") }) }) { padding -> Column(Modifier.padding(padding)) {
        Button(onClick = vm::refresh, enabled = !state.isLoading && !state.isRefreshing) { Text("刷新") }
        when {
            state.isLoading -> CircularProgressIndicator()
            state.error != null && state.items.isEmpty() -> Button(onClick = vm::refresh) { Text("重试") }
            state.isEmpty -> Text("暂无商品")
            else -> LazyColumn { items(state.items, key = { it.id }) { Text(it.title) }; state.append?.failedPageKey?.takeIf { !state.isRefreshing }?.let { item { TextButton(onClick = vm::retryMore) { Text("重试加载更多") } } } }
        }
        if (state.error != null && state.items.isNotEmpty()) Text("刷新失败:${state.error}")
    } }
}

RequestToken 是持久化层分配的一次请求围栏: 包含单调递增的 generation 和不可变 filterSnapshot. ActivationResult 同时返回 token 和由新 remote key 构造的初始 AppendState. Local 与 Repository 的 activateGeneration(filter): ActivationResult 完全一致; Local 在同一个 Room 数据库事务中读取并递增 generation, 写入当前 token 元数据, 重置 / 建立 remote key, 并构造后提交该结果. Repository 直接委托. 进程或 ViewModel 重建后, generation 从持久化值继续递增, 绝不从 0 重新计数.

同一 Room 数据库中的 generation/token 元数据行, 以及所有 guarded write 事务, 是唯一线性化边界. activate 的事务提交点才是刷新线性化点, 不是 ViewModel 发起函数调用的瞬间. ViewModel 只能在 activateGeneration 成功返回后发布 token; 并发 activate 恢复顺序相反时, 只接受 generation 大于 currentToken 的结果. 旧页写入和 activate 事务竞争时, 旧写先提交则属于刷新线性化点之前; activate 先提交则旧写验证失败. writeRefreshIfCurrent 与 writeAppendIfCurrent 都在同一 Room 事务内验证当前 token, filter 和各自的 expectedPageKey, 再写实体和 remote key, 并从该事务写后的 remote key 构造 GuardedWriteResult.Applied(AppendState); 任一验证失败返回 Stale, 不写实体或 key. Repository 直接传播该结果. 取消网络, flatMapLatest 与 ViewModel 丢弃回调仅节省资源, 不承担正确性.

products 保存 observeProducts(filter) 的当前快照, request 保存请求阶段, 刷新错误和由 Activation/Applied 返回的 AppendState. ViewModel 不默认构造或猜测分页元状态: 激活使用 ActivationResult.initialAppendState, 写入成功只使用 Applied.appendState, Stale 不更新 UI. 每个 refresh/loadMore 回调都先以 isCurrent(token) 验证 token 相等且 generation 未回退; 新 token 发布后旧调用的成功或失败均被忽略, 不能恢复 RequestState 或 AppendState. 刷新错误放在 RequestState.error; 追加错误只写当前 AppendState.failedPageKey.

append 的 single-flight 属于 Repository 的 flight registry, 不是 ViewModel 的 Mutex.registry 在短临界区按 (token, pageKey) 原子预留: 已有项共享同一个, 最终携带 GuardedWriteResult 的网络 Deferred, 没有才登记唯一 identity 后发网络; 新 token 发布时 registry 在自己的短临界区替换旧 generation 的项, 完成仅在 (token, pageKey, identity) 都匹配时清理, 因此旧 completion 不能清除新 flight. 它只负责网络请求去重, 不参与 generation 的持久化正确性, 也不是线性化边界. registry 的替换与网络取消都只是资源优化, 正确性始终由 Room guarded write 保证. retryMore() 选择 failedPageKey; loadMore(pageKey) 接受当前合法的 nextPageKey, 并不限定为重试调用. 底部重试仅在当前 failedPageKey 存在且未刷新时渲染.

三, UI 事件, 导航与可靠处理

不要把 Toast, 导航, 弹窗全部塞进 Channel 或 SharedFlow(replay=0). 先按可靠性建模:

data class FormUiState(
    val submitting: Boolean = false,
    val completedOrderId: String? = null,
    val message: UiMessage? = null,
)

interface PendingOrderStore { suspend fun loadOrCreateRequestId(draftId: String): String; suspend fun clearRequestId(draftId: String) }
class OrderViewModel(private val store: PendingOrderStore, private val orders: OrderRepository) : ViewModel() {
    fun submit(draftId: String) = viewModelScope.launch {
        val requestId = store.loadOrCreateRequestId(draftId) // 同一草稿的重试复用该值
        orders.submit(draftId, requestId).onSuccess { orderId -> store.clearRequestId(draftId); _state.update { it.copy(completedOrderId = orderId, submitting = false) } }
            .onFailure { _state.update { it.copy(submitting = false, message = UiMessage("提交失败,可重试")) } }
    }
}

fun onCompletionHandled() {
    _state.update { it.copy(completedOrderId = null) }
}

测试至少覆盖: UI 处于 STOPPED 时业务完成, 旋转后重新收集, 重复回调, 进程重建和用户重复点击.

四, 分页: 刷新, 加载更多与错误恢复

分页不是简单 append, 要区分首次加载, 下拉刷新, 加载更多失败.

1. Refresh: 重置页码 / 游标, 请求第一页, 成功后替换列表.
2. LoadMore: 使用下一页 key, 成功后 append, 失败时保留旧列表并显示底部错误.
3. 去重: 按业务 ID 去重, 避免刷新和加载更多交叉导致重复.
4. 并发控制: Repository 的 flight registry 必须以 generation-scoped (token,pageKey) 原子预留实现 append single-flight; 重复触底立即共享同一个 Deferred 或返回已在途, 绝不因 Mutex 排队后再发一次网络. 它不是持久化线性化边界; collectLatest/网络取消不能替代 Room guarded write 事务.

分页重试保存当前 token 内失败的 pageKey: retryMore() 取该 key, loadMore(pageKey) 也可处理当前合法的 nextPageKey. activate 提交会在 Room 中原子重置 / 建立新 generation 的 remote key; ViewModel 收到更高 token 后才发布它和 ActivationResult.initialAppendState. refresh/append 的 Applied 只能使用该写事务 remote key 构造出的 AppendState; 失败不得恢复旧 key. 旧请求晚返回时, Room guarded write 必须保证不新增旧实体, 不改旧 remote key. 症状 “重试后重复项” 可通过请求日志中的 generation/key/筛选版本和列表 ID 定位.

预期测试至少覆盖:

• 旧 loadMore 写事务先提交, 随后 activate 提交: 旧页可见, 且它属于刷新线性化点之前; activate 后的新 remote key/append state 被重置.
• activate 事务先提交, 旧 loadMore 随后尝试写: 事务内 token 校验失败, Room 不新增旧实体, 不改 remote key, failedPageKey 不回填.
• 旧 refresh 写事务先提交, 随后 activate 提交: 旧世代的实体替换和 remote key 更新属于线性化点之前; activate 随后原子建立新世代的 token 与初始 append state.
• activate 事务先提交, 旧 refresh 随后尝试写: 整个 guarded write 返回 Stale, 实体替换与 remote key 更新都不发生.
• 分别制造 token, filter snapshot, expectedPageKey 不匹配: 每一种失配都必须使事务整体返回 Stale, Room 的实体和 remote key 均保持不变.
• 进程或 ViewModel 重建后再次 activate: 持久化 generation 继续递增, 不会从 0 或旧内存值回退.
• 两个 activate 返回顺序相反: currentToken 仅接受更高 generation, 不能被较旧返回覆盖.
• 对同一 generation, 同一 pageKey 重复触底: 只发起一个网络 append; 其他调用共享同一 Deferred 或立即得知已在途.
• 新 generation 激活后旧 append completion 到达: 它不能删除新 generation 的 flight, 因清理必须匹配 token, pageKey 和 flight identity.
• 匹配 identity 的 append 分别以成功, 失败和取消结束: 三条路径都清理自己的 flight; 清理完成后, 相同 (token, pageKey) 可以发起一次新的重试.
• Local guarded write Applied: 返回值中的 AppendState 来自同一事务写后的 remote key, 不由 Repository/ViewModel 猜测或默认构造.
• guarded write 返回 Stale: 不更新 RequestState 或 AppendState.
• 新 token 发布后旧 refresh/loadMore 的成功与失败: 均不更新 RequestState 或 AppendState.
• 切换筛选或 refresh: 成功后 hasMore, nextPageKey, failedPageKey 来自新 generation 的 remote key; 不得继承旧筛选的 hasMore=false 或失败 key.

五, 表单提交: 校验, 幂等与防重复点击

表单页面适合体现 UseCase 价值. ViewModel 收集输入状态, UseCase 做业务校验和提交编排, Repository 执行网络 / 本地持久化.

• 本地校验: 手机号, 验证码, 必填项在提交前快速反馈.
• 提交中状态: submitting=true 禁用按钮, 防重复点击.
• 服务端错误: 映射成字段错误或页面错误, 不要直接把接口文案散落到 UI.
• 幂等: 订单/支付/注册类提交要有 requestId 或服务端幂等键.
• 成功结果: 必须处理时写入流程 State, UI 导航 / 展示后回调确认; 只有允许丢失的局部效果才使用事件流.

怎么排查重复提交: 看按钮是否禁用, ViewModel 是否丢弃 submitting 期间的新 Intent, 接口是否具备幂等键.

PendingOrderStore 可由 Room/DataStore-backed 实现保存草稿到 requestId 的映射; 新草稿创建新值, 进程重建后的重试仍复用旧值, 成功后清除. 客户端禁用按钮只减少重复, 服务端必须以幂等键保证重复请求返回同一业务结果. 预期测试: 同一 requestId 连续提交两次只创建一笔订单; 不同 requestId 按业务规则独立处理.

面试叙事模板: 事件上报幂等去重 (风控 / 设备指纹)

• 症状: 设备指纹 / 事件上报出现同一事件被服务端重复处理 (重复入库, 重复计费, 风控重复拦截).
• 证据: 服务端日志同一 requestId 多次出现, 客户端在弱网重试或超时重发时未带幂等键.
• 定位: 确认重复发生在网络层重试, 而非业务逻辑多写.
• 修复: 上报事件生成并持久化 requestId, 服务端按 requestId 幂等去重; 客户端重试复用同一 requestId.
• 验证: 构造弱网 / 超时重发场景, 服务端只处理一次, 压测与日志核对无重复.

六, Offline-first 与离线缓存

离线优先不是 “网络失败读缓存” 这么简单, 更推荐本地数据库作为 Single Source of Truth:

UI 观察 Room Flow
Repository 触发网络刷新
Remote 成功 -> 写入 Room
Room 变化 -> UI 自动更新
Remote 失败 -> UI 保留本地数据 + 可恢复错误状态/按语义允许丢失的提示

优点: 页面旋转, 进程重建, 短暂断网都能稳定展示; Repository 统一控制刷新策略, 过期时间, 同步状态. 难点是冲突解决, 脏数据标记, 失败重试和缓存淘汰.

七, 多源数据合并

真实页面经常需要合并用户信息, 配置, 列表, 埋点开关, 缓存状态. Repository/UseCase 可以用 Flow 组合多源:

• combine: 多个数据源任一变化都重新产出 UI 模型.
• flatMapLatest: 筛选条件变化时取消旧查询.
• zip: 严格一一配对, 业务上较少用于 UI 持续状态.
• 本地 + 远端: 本地先出首屏, 远端刷新后写库再更新.

八, 落地检查清单

一个页面架构是否靠谱, 可以按这张表自查:

高频面试题

Q1: 请讲一个页面从 UI 到数据层的完整链路. UI 负责渲染 State 和发送 Intent; ViewModel 接收 Intent, 维护 UiState; UseCase 封装业务规则; Repository 决定网络, 本地缓存和多源合并; DataSource 只负责具体 Retrofit/Room/DataStore 操作. 依赖方向单向, 上层不直接感知底层实现.

Q2: loading, error, empty 怎么统一管理? 用一个不可变 UiState 表达完整页面, 例如 isLoading/items/error/append.hasMore. 首屏错误显示全屏错误; 刷新失败保留旧数据并更新可恢复错误状态; 请求成功但列表为空显示 empty, 避免多个 Boolean 分散导致状态互相矛盾.

Q3: Toast / 导航应该放 State 还是事件流? 不能按控件类型二分. 用户点击产生的导航由 UI 直接处理; 必须保证处理的业务结果进入可恢复 State, UI 处理后回调确认; 只有明确允许丢失的瞬时效果才考虑 Channel/SharedFlow. replay=0 不能提供可靠投递或恰好一次保证.

Q4: 分页加载更多失败时怎么处理? 不要清空已有列表. 保留 items, 在 AppendState 记录当前 generation 的 failedPageKey, 允许用户重试该 pageKey; 用 append.hasMore 限制无更多页, 并由 Repository 的 (token,pageKey) single-flight 防止重复触发并发请求.

Q5: Offline-first 怎么落地? 以 Room 作为 Single Source of Truth, UI 观察本地 Flow; Repository 触发网络刷新, 成功后写入 Room, UI 因数据库变化自动更新; 失败时保留本地数据并提示. 难点是冲突, 过期策略和失败重试.

易错点 / 追问

• 不要让 UI 直接依赖 Retrofit/Room, 否则页面难测, 数据策略分散.
• 不要把消息永久留在 UiState, 也不要把所有结果都扔进事件流. 对可恢复消息使用唯一 ID 和消费确认, 并明确旋转与进程重建语义.
• 分页失败要区分首屏失败和加载更多失败, 后者不能清空已有内容.
• UseCase 不是越多越好; 简单 CRUD 可省略, 复杂业务规则 / 复用逻辑再引入.
• Offline-first 的核心是本地单一数据源, 不是简单 “catch 网络异常后读缓存”.

测试体系

★ 测试体系是中级 Android 面试的高频考点, 也是常见短板区. 能讲清 “怎么测”, 比只会说 MVVM/MVI 更能证明工程能力.

一, 测试金字塔与 Android 测试分层

原则: 越靠下越多, 越快, 越稳定; 越靠上越少, 越接近真实用户.

金字塔成立的前提是架构可测: 逻辑下沉到纯 JVM 层, 依赖可注入替换; MVP/MVVM 的可测性原理见 应用架构 的「MVP Presenter 的最小测试策略」. 本篇聚焦测试方法与工具.

二, 单元测试: JUnit, 断言与 Mock

• JUnit 负责组织测试生命周期.
• Truth/AssertJ 让断言可读.
• MockK/Mockito 用于隔离外部依赖, 但不要 mock 一切.
• MockK 常见坑: 挂起函数要用 coEvery/coVerify, 直接 every/verify 匹配不上; relaxed = true 会对未 stub 的调用静默返回默认值, 掩盖漏 stub 的调用, 属反模式.

class LoginUseCaseTest {
    @Test
    fun `blank username returns validation error`() {
        val useCase = LoginUseCase(fakeRepository)
        val result = useCase.execute(username = "", password = "123456")
        assertThat(result).isEqualTo(LoginResult.InvalidUsername)
    }
}

三, 协程与 Flow 测试

• 用 runTest 控制虚拟时间.
• 用 StandardTestDispatcher 替换真实 dispatcher.
• Flow 可用 Turbine 验证 emit 顺序.

@Test
fun `flow emits loading then success`() = runTest {
    repository.userFlow().test {
        assertThat(awaitItem()).isEqualTo(UiState.Loading)
        assertThat(awaitItem()).isInstanceOf(UiState.Success::class.java)
        awaitComplete()
    }
}

四, ViewModel / Repository 怎么测

ViewModel 测试重点不是测试 Android 框架, 而是测试输入事件到 UI State 的转换.

五, UI 测试: Espresso 与 Compose Test

• Espresso 适合 View 体系页面.
• Compose Test 适合声明式 UI, 优先通过 semantic matcher 找节点.
• UI 测试要覆盖核心路径, 不要把所有边界都堆在 UI 层.
• 现状定位: Compose UI Test 与 Robolectric 仍是主流工具链, 具体 API 行为以当前版本为准.

可运行示例 (instrumented test): 以下代码放在 src/androidTest. 前提是模块配置 AndroidJUnitRunner, androidx.test.ext:junit, Espresso 依赖, LoginActivity 使用 R.id.login_button, 并用 fake/IdlingResource 消除异步网络. 运行到设备/模拟器后, 预期按钮可见且点击成功; 不能依赖 sleep.

class LoginActivityTest {
    @get:Rule val scenarioRule = ActivityScenarioRule(LoginActivity::class.java)
    @Test fun loginButton_isClickable() {
        onView(withId(R.id.login_button)).check(matches(isDisplayed())).perform(click())
    }
}

可运行示例 (Compose instrumented test): 前提是 Compose UI test 依赖与 AndroidJUnitRunner; 下例内联被测组件, 测试 rule 来自 createComposeRule(). 预期点击后回调被调用一次.

@get:Rule val composeRule = createComposeRule()
@Composable fun SubmitButton(modifier: Modifier = Modifier, onSubmit: () -> Unit) {
    Button(onClick = onSubmit, modifier = modifier) { Text("提交") }
}
@Test fun submit_invokesCallback() { var calls = 0
    composeRule.setContent { SubmitButton(Modifier.testTag("submit")) { calls++ } }
    composeRule.onNodeWithTag("submit").performClick()
    composeRule.runOnIdle { assertThat(calls).isEqualTo(1) }
}

可运行示例 (Robolectric JVM test): 适用于依赖资源或轻量 Android 生命周期的代码, 不证明真机权限弹窗. 启动 Activity 后预期标题资源被正确解析.

@RunWith(RobolectricTestRunner::class)
class MainActivityTest {
    @Test fun title_isShown() {
        val activity = Robolectric.buildActivity(MainActivity::class.java).setup().get()
        assertThat(activity.title).isEqualTo("首页")
    }
}

六, 可测试性如何反推架构质量

如果一个 ViewModel 很难测, 通常说明它持有太多 Android 依赖, 业务逻辑没有下沉, 状态 / 副作用没有分离.

七, Android 测试 Harness: 让测试稳定, 可重复

中级面试不只问 “会不会写 JUnit”, 更常追问 “为什么你的测试稳定”.核心是把时间, 线程, 数据源和 Android 框架依赖都收口.

MainDispatcherRule 与协程调度

ViewModel 默认使用 Dispatchers.Main, 本地单元测试里没有真实 Main Looper, 需要在测试规则里替换.

@OptIn(ExperimentalCoroutinesApi::class)
class MainDispatcherRule(
    private val dispatcher: TestDispatcher = StandardTestDispatcher()
) : TestWatcher() {
    override fun starting(description: Description) {
        Dispatchers.setMain(dispatcher)
    }

    override fun finished(description: Description) {
        Dispatchers.resetMain()
    }
}

面试表达: 生产代码不要在业务逻辑里硬编码 Dispatchers.IO/Main, 可以通过 DispatcherProvider 注入, 测试时替换成 TestDispatcher.

Fake 优先于过度 Mock

Mock 适合验证交互, Fake 更适合表达业务状态. Repository/DataSource 可以写内存 fake, 让测试更接近真实流程.

Robolectric vs Instrumentation

Flaky Test 治理

• 不用 Thread.sleep 等待异步, 改用虚拟时间, IdlingResource, Compose test clock.
• UI 测试用稳定语义节点, 不依赖文案频繁变化或 RecyclerView 位置.
• 每个测试自己准备数据并清理, 不依赖执行顺序.
• CI 对 flaky 用隔离重跑和标记治理, 不能简单 “失败就 rerun 到绿”.

CI 质量门禁

PR 阶段至少跑快速单元测试, lint 和关键模块测试; 夜间或合并后跑更慢的 UI / 端到端测试. 性能回归用 Macrobenchmark 单独门禁, 不要混在普通单元测试里.

八, 测试类型与 CI 运行条件

测试报告必须说明设备/API, 构建类型, 是否使用 mock/fake, 重试情况和未覆盖项. “Robolectric 通过” 不能证明厂商 ROM, 系统权限弹窗或真实性能正确.

高频面试题

Q1: 你项目里怎么做测试分层? 答: 核心业务规则放单元测试, ViewModel/Repository 做集成测试, 关键用户路径做 UI 测试. 比例上单元测试最多, UI 测试最少.

Q2: 为什么 Repository 不应该直接测 Retrofit/Room? 答: Retrofit/Room 是框架能力, 业务测试应关注 Repository 的缓存, 错误兜底, 数据源切换. 框架集成可少量用 integration test 验证.

Q3: 协程测试为什么不用真实 delay? 答: 真实 delay 会让测试慢且不稳定; runTest 用虚拟时间推进, 可稳定验证超时, 重试, debounce 等逻辑.

Q4: 怎么让 Android 测试稳定不 flaky? 答: 把不可控因素收口. 协程用 runTest 和 TestDispatcher, 时间用 FakeClock, 网络用 Fake/MockWebServer, UI 用稳定 semantic matcher 或 IdlingResource, 测试数据每次独立准备. CI 上把快测和慢测分层, 失败要定位原因, 不能靠无限重跑掩盖问题.

易错点 / 追问

• 不要为了覆盖率 mock 所有东西, 那会测到实现细节.
• UI 测试不要依赖真实网络和随机数据.
• Compose 测试要给关键节点加稳定语义, 否则 matcher 容易脆弱.

组件化路由与模块通信

组件化不是把包拆成很多 module, 而是让业务边界, 依赖方向和发布协作更清晰. 中高级面试常追问路由, 通信和依赖治理.

一, 组件化解决什么问题

二, 模块拆分方式

• app 壳工程: 组装入口.
• feature module: 业务功能.
• core/common: 基础能力.
• api/contract: 跨模块接口.

依赖方向应从上层依赖抽象, 避免 feature 之间直接互相依赖.

三, 路由框架原理 (以 ARouter 类框架理解)

核心流程: 编译期扫描注解 → APT/KSP 生成路由表 → 运行时按 path 查找目标 → 拦截器处理登录/权限/降级 → 跳转或返回服务实例.

APT/KSP 生成表示意 (伪代码, 仅解释生成物, 不声称可编译):

@Route(path = "/user/profile") ProfileActivity
          -> processor scans feature-user
          -> generated RouteTable { "/user/profile" -> ProfileActivity::class }
          -> app 打包 feature-user-impl 的生成表,并在启动时显式注册;若框架用类路径发现,则需保证生成表未被裁剪

演进提示: ARouter 官方维护已趋缓 (最后一次实质更新约 2021 年前后), 社区有迁移 AndroidX / 适配新 AGP 的维护 fork. 新一代方案 (KRouter 等) 多转向 KSP 编译期生成路由表, 强调类型安全与减少运行期反射 / 扫描; 各方案现状以社区 / 官方最新文档为准, 面试讲清选型理由即可.

工程权衡: 路由表规模与冷启动注册耗时成正比, 路由表越大启动扫描 / 注册成本越高, 大项目需懒加载或异步注册, 避免阻塞冷启动.

interface UserService {
    fun currentUserId(): String?
}

跨模块不要直接调用实现类, 而是依赖 UserService 这样的 contract.

四, 模块通信方式

五, 路由拦截, 降级与灰度

登录校验, 权限校验, A/B 实验, 页面不存在降级都适合放在固定顺序的路由 pipeline 中: 规范化参数 -> 登录 -> 权限/风控 -> 实验/动态模块 -> 最终 navigator. 路由失败必须有兜底, 不能直接 crash.

上下文片段: 这是与具体路由库无关的顺序 pipeline 伪代码 (不是带 proceed() 的责任链).每个步骤可变换 request 或短路返回; 预期: 未登录访问支付页时 LoginInterceptor 返回登录路由, 后续步骤和最终 navigator 不执行; 通过所有检查后才由 navigator 负责实际跳转.

interface RouteInterceptor { fun intercept(request: RouteRequest): RouteResult }
fun dispatch(request: RouteRequest, pipeline: List<RouteInterceptor>, navigator: Navigator): RouteResult {
    var current = request
    for (interceptor in pipeline) {
        val result = interceptor.intercept(current)
        if (result !is RouteResult.Continue) return result
        current = result.request
    }
    return navigator.navigate(current)
}

失败排查: 症状是页面未打开; 证据记录 path, 参数 schema, 拦截器名称和结果; 先区分未注册, 参数非法, 登录 / 权限拒绝和动态模块未安装; 修复为注册生成表, 校验 contract 或提供降级; 最后覆盖每条拦截分支与目标跳转.

六, 和 Gradle 工程化的关系

组件化设计关注业务边界; Gradle 工程化关注构建配置, 依赖版本, 产物和性能. 两者相关但不是一回事.

七, 现代组件化治理: 契约, 构建逻辑与类型安全路由

面试官往往不满足于 “用了 ARouter”, 会继续追问模块怎么拆, 依赖怎么防腐, 路由怎么治理.

依赖方向

下图中的箭头表示 Gradle 依赖方向: app 负责组装实现模块, feature-*-impl 依赖自身 feature-*-api, 其他 feature 只能依赖 API 契约, 不能依赖实现模块.

app
 ├─ feature-home-impl  ──> feature-home-api
 ├─ feature-pay-impl   ──> feature-pay-api
 └─ core-ui / core-network / core-common

从单体迁移时可分三步: 先在单模块内抽出 feature API 和实现包; 再移动实现到 feature module, 让 app 组装; 最后用 CI 检查 feature 不反向依赖 app 或其他 feature 的 impl. 正确依赖图如下 (箭头为 Gradle 依赖):

app -> feature-user-impl -> feature-user-api
app -> feature-pay-impl  -> feature-pay-api
feature-user-impl -> core-*
feature-pay-impl  -> core-*
other feature -> feature-*-api (never feature-*-impl)

单体到组件化的迁移图如下 (箭头为 Gradle 依赖):

before: app(ui + user + pay + data)
after:  app -> feature-user-impl -> feature-user-api
        app -> feature-pay-impl  -> feature-pay-api
        other feature -> feature-*-api
        feature-* -> core-common / core-ui / core-network

• api/contract 模块只放接口, 路由契约, DTO, 不放具体页面和重业务逻辑.
• impl 模块实现页面和业务, 依赖自己的 api 与公共 core.
• feature 之间不直接依赖实现, 避免循环依赖和 “改 A 编译半个项目”.

Convention Plugin 与 Version Catalog

组件化后如果每个 module 都复制 Android/Kotlin/Compose 配置, 会迅速失控. 更好的做法是把公共配置沉淀到 Gradle convention plugin, 并用 Version Catalog 管理依赖版本.

类型安全路由契约

字符串 path 容易写错, 参数缺失难发现. 可以在 contract 层定义类型安全入口:

data class PayRoute(val orderId: String, val source: String)

interface PayNavigator {
    fun openPay(route: PayRoute)
}

底层可以仍然用路由框架, 但上层业务依赖的是类型化 contract, 而不是到处拼 "/pay/detail?orderId=...".

Dynamic Feature / 插件化边界

动态交付适合低频, 体积大的功能, 但会带来下载失败, 版本兼容, 冷启动和路由降级问题. 面试中要强调: 动态化不是为了炫技, 而是为了控制包体积, 灰度风险或业务隔离.

路由治理清单

1. path 命名规范和归属人.
2. 参数 schema 与必填校验.
3. 未命中, 版本不兼容, 未安装动态模块时的降级页.
4. 登录/权限/风控拦截器顺序.
5. 路由耗时, 失败率, 来源页面埋点.

编译期路由与 API 稳定性

评估路由方案不能只比较运行时反射能力. 可使用 KSP/注解生成编译期路由表, 但要评估增量构建, 错误提示和跨模块 API 演进. Dynamic Feature 取决于分发渠道和安装状态. 组件 API 应有 owner, 版本/废弃周期和依赖可视化, CI 阻止反向依赖与循环依赖; “彻底解耦” 不是目标, 可理解且可演进的契约才是目标.

高频面试题

Q1: 组件化和模块化区别? 答: 模块化偏代码物理拆分, 组件化更强调业务组件独立开发, 独立测试, 按契约通信和可组装.

Q2: ARouter 这类框架大概怎么实现? 答: 编译期注解处理生成路由表, 运行时初始化加载, 按 path 找目标 class/provider, 再通过拦截器处理统一逻辑.

Q3: 跨模块通信为什么不直接依赖实现? 答: 直接依赖会导致 feature 耦合, 编译依赖变重, 循环依赖风险; 接口下沉能保持依赖方向稳定.

Q4: 组件化项目怎么避免 Gradle 配置复制和依赖版本失控? 答: 把公共 Android/Kotlin/Compose/lint/test 配置沉淀为 convention plugin, 新模块默认套用; 依赖版本放 Version Catalog 或统一依赖管理. 这样既减少重复, 也能在升级 compileSdk, Kotlin, AGP 时集中治理.

易错点 / 追问

• 不要为了组件化制造过多小 module.
• 不要把所有通信都塞进 EventBus.
• 路由 path 要集中治理, 否则重构时容易断链.

Android 系统原理

这一篇偏底层; 如果你已有操作系统或并发基础, 理解会更顺畅. 面试常问 Handler, Binder, 启动流程, 应结合自己的基础和项目经验组织回答.

一, Handler / Looper / MessageQueue

Android 的线程间通信与主线程消息循环核心机制.

• Looper: 每个线程最多一个 Looper, 内部持有 MessageQueue, loop() 死循环不断取消息分发. 主线程的 Looper 由系统在 ActivityThread.main 中创建.
• MessageQueue: 消息队列, 按时间排序的单链表; next() 取消息, 无消息时通过 epoll 阻塞 (不耗 CPU).
• Handler: 发送 (sendMessage/post) 和处理 (handleMessage) 消息; Message 持有 target (发送它的 Handler).
• ThreadLocal: Looper 通过 ThreadLocal 与线程绑定, 保证一个线程一个 Looper.

子线程 Looper 的创建与退出

子线程默认没有 Looper, 需先 Looper.prepare() 把 Looper 放入当前线程的 ThreadLocal, 创建绑定它的 Handler, 再 loop() 持续分发. 无参构造 Handler() 自 API 30 起已废弃, 应显式传 Handler(looper) 或 Handler(looper, callback). 退出用 quit() (立即丢弃未处理消息) 或 quitSafely() (处理已到期消息后退出); 不要创建没有退出策略的常驻 Looper. 工程上更常用 HandlerThread, 用法与生命周期见 多线程并发专题 - Android 线程模型与 HandlerThread.

// 示意代码: 生命周期 owner 应保存 handler, 在任务完成或销毁时发送 STOP.
Thread {
    Looper.prepare()
    val handler = Handler(Looper.myLooper()!!) { message ->
        when (message.what) {
            1 -> {
                refreshIndex(message.obj as String)
                true
            }
            2 -> {
                Looper.myLooper()?.quitSafely()
                true
            }
            else -> false
        }
    }
    handler.sendMessage(handler.obtainMessage(1, "books"))
    handler.sendEmptyMessage(2) // STOP: 处理已到期消息后退出
    Looper.loop()
}.start()

post 与 sendMessage 的职责

二者都只是在目标 Looper 所在线程执行, 不自动切换到后台. Handler.post 是消息队列投递, 而 View.post 还依附于 View 的 attach 状态; 后者不等同于 “布局已完成”, 布局时机见 UI 体系 - View 与自定义 View.

UI 线程亲和性

View 层级, Window 和大多数 UI toolkit API 都由创建它们的主线程拥有. 子线程直接修改 View 会破坏遍历和事件分发的串行假设, 通常抛出 CalledFromWrongThreadException, 即使偶发未立即失败也属于竞态. 将结果投递回主线程只是最后一步; 若页面已经停止或 View 已销毁, 仍应丢弃过期渲染或通过生命周期感知的 state 收集处理.

为什么主线程死循环不卡死 / 不 ANR? loop () 是死循环, 但无消息时阻塞在 epoll_wait 让出 CPU, 有事件 (触摸, 绘制) 再唤醒. ANR 是消息处理太久, 不是循环本身.

进阶:

• 同步屏障 (Sync Barrier): 插入屏障后, 同步消息被拦截, 优先处理异步消息 (如 UI 绘制 doFrame), 保证及时刷新.
• IdleHandler: 队列空闲时回调, 可做延迟初始化 (不阻塞关键路径).

二, Binder 机制

Android 跨进程通信 (IPC) 的核心. 相比管道 / socket 的多次拷贝, Binder 通过 mmap 映射实现一次拷贝, 且内核自动附带调用方 UID/PID 便于安全鉴权. 结构上是 Client, Server, ServiceManager (服务注册查找), Binder 驱动; Client 拿到的是 BinderProxy, AIDL 自动生成 Stub/Proxy 代码.

一次拷贝简图

发送进程用户空间                 内核 / Binder 驱动              接收进程用户空间
Parcel 数据 -- 拷贝一次 --> binder_buffer -- mmap 同一页 --> Binder 线程读取 Parcel

发送方 Parcel 拷贝到驱动管理的 binder_buffer 是一次拷贝, 接收方经预先 mmap 的映射区直接读取, 省去一次显式拷贝. 它是 “一次拷贝, 不是零拷贝”, 大数据应走共享内存 / 文件描述符; 实现层 (mmap, binder_alloc, 线程池上限) 见 Binder 与 IPC 深入 - 一次拷贝模型与 mmap.

一次 Binder 调用怎么走

Client 的 Proxy 把参数写入 Parcel, 经驱动按 handle 路由到目标进程, 由 Binder 线程池回调 Stub 的 onTransact() 执行并回写 reply; 同步调用阻塞调用线程, oneway 不等待. 调用链见 Binder 与 IPC 深入 - AIDL 调用链, 线程池 / 死锁风险见 Binder 与 IPC 深入 - Binder 线程池与调用风险.

常见追问: 真零拷贝? 不是, 一次拷贝; 能传多大? 约 1MB 且并发共享, 见 TransactionTooLargeException 与 Parcelable 边界; 为何死锁? 同步调用持锁或主线程发 Binder 易锁等待 / ANR; AIDL 与 Binder? AIDL 是代码生成器, 底层仍走驱动. 完整问答见 Binder 与 IPC 深入 - 高频面试题.

三, 应用启动流程

点击图标到界面显示的大致链路: Launcher 经 Binder 请求 ATMS → 目标进程不存在时 Zygote fork 出应用进程, 执行 ActivityThread.main() 准备主线程 Looper → 进程经 Binder attachApplication, 系统回调创建 Application 与目标 Activity, 走 onCreate → onResume, ViewRootImpl 触发首帧. Zygote 是所有应用进程的 “母体”, 预加载核心类和资源, fork 时通过 COW (写时复制) 共享加速启动. 完整链路与源码细节见 Framework 源码与进程生命周期 - Activity 启动完整链路.

冷启动拆解与可优化点

回答启动流程时要区分公开生命周期和系统实现细节: 对业务开发者稳定的是 Application/Activity 生命周期与进程可能被系统创建/杀死; AMS/ATMS, Zygote 命令格式, 预加载列表属于实现层面, 可作为理解但不宜写成永久不变的 API. 优化深度见 启动优化专项.

四, 类加载与热修复 / 插件化

• 类加载器: PathClassLoader(加载已安装 APK), DexClassLoader(可加载外部 dex/jar, 热修复/插件化基础).它们持有 DexPathList, 内部是 dexElements 数组.
• 热修复原理: 把修复后的补丁 dex 插到 dexElements 数组最前面, 根据双亲委派 + 数组顺序查找, 补丁类先被加载, 从而 “覆盖” 有 bug 的旧类 (如 Tinker, QFix). AndFix 则走 native 方法替换.
• 插件化: 动态加载未安装的 APK, 需解决类加载, 资源加载 (AssetManager.addAssetPath), 组件生命周期 (Hook AMS / 占坑 Activity) 三大问题.

热修复方案对比

dexElements 前插流程可以按四步讲: 下载补丁并校验签名 / 版本 → 用 DexClassLoader 加载补丁 dex → 反射合并补丁与宿主的 dexElements → 重启进程或在安全时机让新类优先命中. 重点不是 “反射代码背诵”, 而是说明类查找顺序改变.

插件化三大难点

占坑思路: 宿主 manifest 预注册一个透明 / 通用 Activity, 启动插件 Activity 前把 Intent 替换成占坑 Activity; 系统校验通过后, 在回调到应用侧时再把真实插件 Intent 换回来, 由插件框架接管生命周期与资源. 这个概念能说明 “为什么插件 Activity 不在 manifest 也能跑”, 但面试中要补一句: 这不是官方组件模型, 兼容性和合规风险需要框架兜底.

工程风险清单:

• 补丁必须做签名, 版本, 灰度, 回滚, 不能把远端 dex 加载当成无约束能力.
• 反射/隐藏 API 在高版本可能受限制, 厂商 ROM 对 ClassLoader/Resources 实现也可能不同.
• native 替换与组件 Hook 改动运行时内部结构, 要用设备矩阵验证, 不要承诺 “所有版本通用”.
• 热修复适合止血, 根因仍要通过正常发版修复; 插件化适合业务动态化, 不应绕过系统权限和安装模型.

Android 9 非 SDK 接口限制: 面试回答与工程边界

Android 9/API 28 起, 平台限制应用访问非 SDK 接口, 即未作为公开 Android SDK 契约提供的 framework 类, 方法和字段. 限制会随 Android 版本, targetSdk 与非 SDK 名单演进: 较低 targetSdk 在部分版本上可能仅收到警告或适用较宽的兼容行为, targetSdk 提升或名单收紧后则可能被阻止. 因此不能把某一设备或版本上反射成功当作长期兼容承诺.

面试若原题问 “如何绕过限制”, 应先纠正前提: 反射, 修改豁免名单或依赖第三方绕过都不是可维护方案, 也不应作为应用交付路径, 本章不提供规避代码. 先查找公开 SDK API, AndroidX 组件或有文档的系统服务契约; 无法替代时, 将最小依赖隔离在版本 / ROM 适配层, 做能力检测, 准备可用功能降级, 通过灰度和监控观察失败率, 并为移除该依赖制定版本化计划. 插件化和热修复的完整工程边界见 插件化, 热修复与动态化.

五, 进程间通信方式对比

章节边界与源码版本

本章讲系统总览; 进程生命周期细节见 Framework 源码与进程生命周期, IPC 见 Binder 与 IPC 深入, 通用 OS 基础见操作系统与数据库基础. 描述 ActivityThread, AMS/ATMS, Zygote, LMKD 等内部实现时注明 Android 版本/AOSP tag; 内部类名和调用链不是稳定 SDK 契约.

高频面试题

Q1: 主线程 Looper 死循环为什么不会卡死 App? loop () 是死循环, 但 MessageQueue 无消息时通过 epoll 阻塞, 让出 CPU 不占用资源; 有消息 (触摸 / 绘制等) 再唤醒处理. ANR 是单条消息处理太久, 不是循环本身导致.

Q2: Handler 内存泄漏怎么产生? 如何避免? 非静态内部类 Handler 隐式持有外部 Activity, 若有延迟消息未处理, Activity 无法回收. 解决: 静态内部类 + 弱引用, 或在 onDestroy 中 removeCallbacksAndMessages (null).

Q3: Binder 为什么只需一次拷贝? 发送方 Parcel 拷贝到驱动 binder_buffer 一次, 接收方经 mmap 映射区读取, 省去一次显式拷贝; 它是 “一次拷贝, 不是零拷贝”, 且约 1MB 并发共享限制. 细节与边界见 Binder 与 IPC 深入.

Q4: 为什么用 Binder 而不是传统 IPC? 性能上一次拷贝优于管道/socket 的两次, 安全上内核自动附带调用方 UID/PID 支持鉴权. 详见 Binder 与 IPC 深入.

Q5: Zygote 的作用? 为什么用 fork? Zygote 预加载核心类库和资源, 作为所有应用进程的母体. fork 通过写时复制共享已加载内容, 加速进程创建, 减少内存占用 (避免每个进程重复加载 framework).

Q6: 热修复的基本原理? 利用类加载机制, 把补丁 dex 插入 ClassLoader 的 dexElements 数组前面, 使补丁类优先于有 bug 的旧类被加载. 属于 “类加载方案”, 通常需要重启或确保旧类尚未加载; 另有 native 方法替换方案, 但强依赖 ART 内部结构, 兼容风险更高.

Q7: ThreadLocal 在 Looper 里起什么作用? 保证一个线程只有一个 Looper. Looper.prepare 把 Looper 存入 ThreadLocal, 各线程独立互不干扰, getMainLooper 拿主线程的.

实践补充: 消息, 线程与启动时序

机制伪代码, 不能直接编译: Handler.post 把带 target 的 Message 入队; Looper.loop() 从 MessageQueue.next() 取消息 (空队列时 epoll 等待), 再经 target.dispatchMessage() 调用 Runnable 或 handleMessage(). 异步消息不等于后台线程, 主线程 Handler 的 Runnable 仍在主线程运行; 应用不应依赖隐藏 API 手工插同步屏障.

上下文片段 (放在 Activity): Activity 是该 HandlerThread 的生命周期 owner: 创建时启动, 销毁时调用 quitSafely(). Handler(worker.looper) 显式绑定 worker 的 Looper, 不使用已废弃的无参构造; 用法详见 多线程并发专题 - Android 线程模型与 HandlerThread.

private lateinit var worker: HandlerThread
override fun onCreate(state: Bundle?) { super.onCreate(state); worker = HandlerThread("thumbnail-worker").apply { start() }; Handler(worker.looper).post { loadThumbnailIndex() } }
override fun onDestroy() { worker.quitSafely(); super.onDestroy() }

预期是任务不占 UI 线程; 若 loadThumbnailIndex 长时间 I/O, 后续消息会排队. 症状是同一 worker 任务不执行, 证据是线程 dump 卡在 I/O; 修复为超时或有限并发执行器, 重复路径确认队列恢复.

Launcher -> ATMS/AMS (Binder) -> Zygote fork -> app ActivityThread.main
app -> AMS: attachApplication (Binder) -> ApplicationThread callback
-> ActivityThread main Handler -> 生命周期/首帧 -> SurfaceFlinger 合成

COW (写时复制) 是 fork 后先共享物理页, 写入时才复制该页的机制. 此图是 AOSP 心智模型, 具体类名和事务随版本变化. 启动测量见启动优化专项, AIDL 实现见 Binder 与 IPC 深入.

Android Framework 源码与进程生命周期

本篇承接四大组件, View 和 Binder 章节, 把系统服务, Activity 启动, Window 显示, 应用安装和进程死亡串成一条链. 面试重点不是背某个 Android 版本的私有方法名, 而是说明跨进程边界, 线程切换, 状态所有权和版本边界.

一, Android 系统启动与核心角色

从 init 到应用进程

Linux kernel
  -> init
     -> servicemanager / native services
     -> Zygote
        -> system_server
        -> application process

• init: 用户空间第一个进程, 解析 rc 配置并启动 Zygote, ServiceManager 和部分 native 服务.
• ServiceManager: Binder 服务注册与查询中心. 系统服务把 Binder 入口注册进去, Client 按名称取得代理.
• Zygote: 预加载常用类和资源, 通过 fork 创建 system_server 与应用进程, 利用写时复制减少启动成本.
• system_server: 承载 AMS, ATMS, WMS, PMS 等大量 Java 系统服务.
• 应用进程: 从 ActivityThread.main() 建立主线程 Looper, 再通过 Binder 与 system_server 协作.

核心系统服务怎么分工

Android 10 前后部分职责从 AMS 拆分到 ATMS. 面试可按当前架构区分职责, 同时说明旧资料可能仍把 Activity 调度统称为 AMS.

二, Activity 启动完整链路

从点击图标到目标进程

1. Launcher 根据 PMS 返回的可启动组件构造 Intent.
2. startActivity() 最终通过 Binder 请求 ATMS 启动目标 Activity.
3. ATMS 解析 Intent, 权限, 启动模式, taskAffinity 和 Intent flags, 决定复用哪个 Task/Activity 或创建新实例.
4. 如果目标进程不存在, system_server 请求 Zygote fork 应用进程.
5. 新进程进入 ActivityThread.main(), 准备主线程 Looper, 创建 ActivityThread 并向 AMS 执行 attachApplication.
6. system_server 通过应用侧的 Binder 入口下发生命周期事务, 应用主线程处理事务并创建目标组件.

应用进程内如何创建 Activity

现代 Android 使用 ClientTransaction 及一组 transaction item 描述启动和生命周期变更. 可以用下面的稳定心智模型回答:

system_server
  -> ApplicationThread Binder callback
     -> ActivityThread main Handler
        -> create/load Activity
           -> Instrumentation.newActivity
           -> Activity.attach
           -> Instrumentation.callActivityOnCreate
           -> onStart / onResume

• ActivityThread: 应用进程主线程的管理者, 负责调度组件和生命周期, 它本身不是 Thread 子类.
• ApplicationThread: 应用暴露给 system_server 的 Binder 入口, 接收系统调度.
• Instrumentation: 参与 Activity 创建和生命周期调用, 测试框架也利用它观察或替换组件行为.
• LoadedApk/ClassLoader: 提供 APK 的类, 资源和组件信息.
• ClientTransaction: 把启动, 暂停, 恢复等事务统一下发; 私有 item 名称会随版本演进, 不应当作公开 API 背诵.

启动模式到底在哪里生效

启动模式不是 Activity 自己在 onCreate() 里决定的. ATMS 在创建实例前根据当前 Task, Manifest 配置和 Intent flags 计算启动结果:

• singleTop: 目标已在当前栈顶时复用, 回调 onNewIntent().
• singleTask: 寻找合适任务中的既有实例, 常伴随清理其上的 Activity.
• FLAG_ACTIVITY_NEW_TASK: 根据调用方和 affinity 寻找或创建 Task.
• FLAG_ACTIVITY_CLEAR_TOP: 目标存在时清除它上方实例, 是否复用还要结合启动模式和其他 flag.

面试画任务栈时要同时写出原栈, Intent flag, 最终栈和回调, 不能只背四种 launchMode 定义.

三, Window 与一帧如何显示

Activity, Window 和 View 的对象关系

Activity
  -> PhoneWindow
     -> DecorView
        -> content View tree

WindowManagerImpl
  -> WindowManagerGlobal
     -> ViewRootImpl
        -> IWindowSession / WMS

• Activity 在 attach 阶段创建 PhoneWindow.
• setContentView() 把业务布局放进 DecorView 的 content 区域.
• WindowManager 把 DecorView 加入窗口系统, 应用侧为这棵 View 树创建 ViewRootImpl.
• ViewRootImpl 通过 Binder 与 WMS 的 Session 通信, 申请窗口, Surface, 焦点和输入相关资源.

Window 是窗口能力抽象, DecorView 是 View 树根节点, ViewRootImpl 是应用侧 View 树与系统窗口服务之间的桥梁. ViewRootImpl 不是 DecorView 的父 View.

从 requestLayout 到屏幕像素

1. View 请求布局或重绘, ViewRootImpl 安排下一次 traversal.
2. Choreographer 接收 VSync, 在主线程执行 input, animation, traversal 等阶段.
3. 主线程完成 measure/layout, 并记录绘制命令或更新渲染节点.
4. RenderThread/GPU 在硬件加速路径处理渲染命令, 把结果写入 BufferQueue 对应的图形缓冲.
5. SurfaceFlinger 收集各窗口图层, 结合 Z-order, 变换和硬件合成能力生成最终画面.
6. 显示系统在合适的刷新时序把合成结果送到屏幕.

掉帧不只可能发生在 onDraw(). 主线程布局, RenderThread, 纹理上传, GPU, SurfaceFlinger 合成和系统调度都可能超过帧预算, 所以要用 Perfetto/Frame Timeline 确认瓶颈位置.

高刷新率下的帧预算

16.7ms 不是所有设备的固定标准. 面试应回答 “预算由当前刷新率和系统调度决定”, 并用 Frame Timeline 的实际 deadline 判断 jank.

BufferQueue, 缓冲与 VSync

BufferQueue 是生产者 (应用渲染侧) 与消费者 (通常是 SurfaceFlinger) 交换图形 buffer 的队列:

Producer(应用):       VSync -> dequeueBuffer -> 绘制 -> queueBuffer
BufferQueue(队列):              空闲 buffer <- 就绪 buffer <- 被 Consumer 获取
Consumer(SurfaceFlinger): VSync -> acquireBuffer -> 合成 -> present/release

应用渲染与 SurfaceFlinger 合成是异步节拍: Producer 的 queueBuffer 不保证被同一个 VSync 的 Consumer 合成, 队列可能等待下一次消费. 双缓冲可理解为显示和绘制各占一个 buffer; 三缓冲多保留一个就绪 buffer, 能减少生产者等待但可能增加排队延迟和内存. 它们是教学模型, 不是每台设备固定配置; 应以 Frame Timeline 的实际 deadline 判断 jank.

四, PMS 与应用安装 / 更新

系统为什么能找到 Activity

PMS 维护已安装包, 组件, IntentFilter, 权限, 签名和版本等信息. Launcher 查询可启动 Activity, ATMS 解析显式 / 隐式 Intent, 系统校验 exported 和 permission 都依赖这份包信息.

安装链路的稳定模型

PackageInstaller session
  -> 校验安装请求和包结构
  -> 复制/准备 APK 与 native library
  -> 解析 Manifest 和组件
  -> 校验签名,版本和权限
  -> 注册包信息并准备 dex 优化
  -> 发送包变更通知

• 覆盖安装通常要求 applicationId 一致, 签名兼容且 versionCode 满足系统策略.
• APK Signature Scheme v2/v3/v4 覆盖范围和增量安装能力不同, 但业务面试重点是 “签名保护身份和完整性, 更新必须维持签名连续性”.
• DEX 优化会随 Android 版本, 安装方式, 设备状态和 ART Service 策略变化, 不要把 dex2oat 的某个命令流程说成所有版本都固定.
• 四大组件, Provider authority, 权限和 exported 配置在安装 / 扫描阶段进入系统可查询的数据结构.

五, 进程优先级与 LMK

Android 会根据组件状态和用户可见性调整进程重要性, 再由系统内存管理与 lmkd 在压力下选择回收目标.

进程被杀时通常不会给应用可靠的 Application.onTerminate() 或完整清理回调. 关键数据必须在业务操作时持久化, 不能把希望寄托在 “被杀前保存”.

进程优先级不是固定五档枚举实现. Android Framework 内部会计算进程 adj, 再最终映射为内核暴露的 oom_score_adj; 旧资料中的 oom_adj 是历史接口 / 术语, 不能与 oom_score_adj 混称. 系统还会结合组件关系, 前台服务, 厂商策略和实时内存压力计算, 面试应使用层级模型而不是承诺固定阈值.

oom_adj 与任务栈推演

oom_score_adj 是内核 OOM 选择使用的调整值, 数值通常越大越易被杀. 以 Android 10+ AOSP 的概念性区间示例, 前台/可见/服务/缓存常见值约在 0, 100, 500, 900 一带; 这不是 API 或设备承诺. 应在目标设备读取 adb shell cat /proc/<pid>/oom_score_adj, 并结合 dumpsys activity processes 验证.

假设性演练, 非设备实测: Task 为 [A, B], B 在顶端; 从 B 启动 B 且 B 为 singleTop, 最终仍为 [A, B], 既有 B 收到 onNewIntent(). 从 B 用 CLEAR_TOP 启动 A 会清除 A 之上的 B, A 是否复用还受启动模式影响. 推演先写初始栈, 调用方, manifest/flags, 再写最终栈和回调, 不能把 singleTask 说成永远全局唯一.

六, 配置变更, 进程死亡与状态恢复

三类 “重建” 必须分开

• ViewModel: 解决配置变更期间的内存状态保留, 不能跨进程死亡保存实例.
• SavedStateHandle/Bundle: 保存少量可序列化 UI 状态, 受 Binder/Bundle 大小与恢复时机约束.
• Room/DataStore/文件: 保存必须跨进程和设备重启存在的数据.
• Repository: 决定恢复时从网络, 本地数据库或缓存重建页面状态.

推荐把页面状态拆成三层:

1. 可由业务数据重新计算的派生 UI 状态, 不持久化.
2. 当前 tab, 输入草稿, 滚动锚点等轻量状态, 使用 SavedState.
3. 订单, 消息, 上传进度等关键状态, 持久化并设计幂等恢复.

七, Framework 源码题的答题方法

1. 先说业务入口和最终结果.
2. 标出进程边界: 应用进程, system_server, Zygote/SurfaceFlinger.
3. 标出 Binder 调用和线程切换: Binder 线程还是应用主线程.
4. 说清状态归属: Task 在系统侧, View 树在应用侧, 图层由 SurfaceFlinger 合成.
5. 最后补版本边界, 不把私有类名和方法名说成稳定 API.

帧预算统一口径

一帧 16.7 ms 仅是 60 Hz 示例, 不能作为固定性能标准. View/Compose/动画章节统一用实际显示刷新率, FrameTimeline 和用户可见 jank 证据说明 deadline; 详细排查见 ANR 与卡顿排查. Framework 调用链应标注所读 AOSP tag, 不把内部实现当稳定 API.

高频面试题

Q1: ActivityThread 是线程吗? 不是. 它是应用进程主线程的组件调度管理者, 真正的主线程从 ActivityThread.main() 启动并进入 Looper. ApplicationThread 则是提供给 system_server 的 Binder 回调入口.

Q2: AMS 和 ATMS 有什么区别? AMS 更关注进程以及 Service, Broadcast, Provider 等运行管理; ATMS 从 AMS 中拆出, 专门处理 Activity, Task, 启动模式和窗口容器相关调度. 旧资料可能把两者统称为 AMS 链路.

Q3: Activity 的生命周期是谁调用的? system_server 决定生命周期事务, 通过应用侧 Binder 入口下发; ActivityThread 在应用主线程处理事务, 并通过 Instrumentation 调用 Activity 的生命周期方法.

Q4: ViewRootImpl 是 View 吗? 是 DecorView 的父节点吗? 都不是. ViewRootImpl 是应用侧 View 树与 WindowManager/WMS 之间的桥梁, 驱动 traversal, 输入和 Surface 协作; DecorView 仍是 View 树的根 View.

Q5: View 调用 draw 后为什么还没有直接显示到屏幕? 应用生成绘制命令并把缓冲提交到 Surface, SurfaceFlinger 还要把多个窗口图层按层级和变换合成, 再交给显示系统. 主线程, RenderThread, GPU 和合成都可能影响一帧.

Q6: 进程被系统杀死前一定会回调 onDestroy/onTerminate 吗? 不一定. 内存压力下系统可以直接终止缓存进程, 不能依赖清理回调保存关键数据. 状态应在发生变化时持久化, 返回页面时按持久状态和 SavedState 重建.

Q7: ViewModel 能解决进程死亡吗? 不能保存旧实例. ViewModel 只保证同一 owner 在配置变更中的保留语义. 进程死亡后需要 SavedStateHandle 恢复少量 UI 状态, 用 Room/DataStore/文件恢复关键业务数据.

Q8: 安装 APK 时系统主要做什么? 接收 PackageInstaller session, 校验包结构, 签名, 版本和权限, 解析 Manifest 与组件, 准备 APK/native library 和 dex 优化, 更新 PMS 包信息并通知包变化. 具体内部服务和优化时机会随 Android 版本变化.

易错点 / 追问

• 不要说 AMS 负责所有 Activity 细节; 新版本应说明 ATMS 的拆分.
• 不要把 ActivityThread 说成 Thread 子类, 也不要把 ApplicationThread 当作应用主线程.
• 不要说 ViewRootImpl 是 View 或 DecorView 的父 View.
• 不要把 onSaveInstanceState 当数据库使用, 大对象会增加事务和恢复风险.
• 不要依赖 onDestroy(), Application.onTerminate() 保存关键状态.
• 源码类名和事务 item 会随版本变化, 回答重点应是跨进程模型和职责边界.

Binder 与 IPC 深入

Binder 是 Android 系统面试里最能拉开层次的题: 不要只背 “一次拷贝”, 要能把 mmap, ServiceManager, AIDL, 线程池和大数据边界讲成一条工程链路. 前置: 系统 / 进程模型见 Android 系统原理 与 Framework 源码与进程生命周期, 并发模型见 多线程并发专题.

一, Binder 总体模型

Binder 是 Android 最核心的 IPC 机制, 把跨进程调用包装成 “像调用本地对象一样调用远端服务”.它同时解决三件事:

• 通信: Client 通过 Binder 驱动把 Parcel 发给 Server.
• 寻址: ServiceManager 负责服务注册与查询, 类似系统服务的 “电话簿”.
• 安全: Binder 驱动天然知道调用方 UID/PID, 服务端可以做权限校验.

Client(BinderProxy)
  -> /dev/binder 驱动
  -> Server(Binder Stub / Binder 实体)
  -> Binder 线程池执行 onTransact

面试回答要强调: Binder 不是单个类, 而是 用户态 Stub/Proxy + Binder 驱动 + ServiceManager + 线程池调度 的组合机制.

二, 一次拷贝模型与 mmap

常见说法是 Binder “一次拷贝”, 不是零拷贝. 传统 socket/pipe 往往需要 “发送方用户态 → 内核缓冲区 → 接收方用户态” 两次拷贝; Binder 通过内核维护的映射区减少一次显式拷贝.

• Server 进程启动 Binder 线程池时, 会和 Binder 驱动建立映射区 (mmap).
• Client 把参数序列化到 Parcel, 调用 transact() 进入驱动.
• 驱动把数据拷贝到目标进程可通过映射区访问的 Binder buffer.
• Server 的 Binder 线程从映射区读取 Parcel 并分发到 onTransact().

mmap 实现层推演 (面试按需深度): 下面这些是驱动 / 内核实现细节, 答到 “一次拷贝 + mmap + 线程池上限” 就够, 不用死背.

• Server 端建立 Binder 线程池时通过 mmap 映射一段内核缓冲区, 该区域由驱动的 binder_alloc 管理. “一次拷贝” 的完整路径: 发送方 copy_from_user 把 Parcel 拷进内核 Binder buffer, 接收方通过自己 mmap 的映射区直接读这块 buffer, 无需第二次显式拷贝到用户态.
• 驱动与用户态用 binder 协议命令交互: 客户端发起事务向驱动写 BC_TRANSACTION, 服务端从驱动读到事务通知是 BR_TRANSACTION.
• 进程的 Binder 线程池有上限: 内核需要更多线程时发 BR_SPAWN_LOOPER, 由用户态增开线程, 受 max_threads 限制, 默认 15 (默认值, 随版本 / 驱动调整).
• “约 1MB” 只是经验值: 内核 buffer 大小与分配计数随版本 / 驱动调整 (如 Android 15 前后内核修正过异步事务空间计算, 以 AOSP 当前实现为准), 面试别把 1MB 当精确上限.

三, ServiceManager 与服务注册查找

ServiceManager 是 Binder 世界里的特殊服务, 负责把服务名映射到 Binder handle.

1. SystemServer 创建系统服务, 把 Binder 实体注册到 ServiceManager.
2. Client 通过服务名查询, 拿到的是远端 Binder 的代理对象.
3. 后续调用不再直接找服务名, 而是通过 handle 让 Binder 驱动路由事务.

怎么答得更工程化: ServiceManager 解决 “我怎么拿到远端服务入口” 的问题; Binder 驱动解决 “这个入口怎么跨进程调用” 的问题; AIDL 解决 “业务接口怎么自动生成序列化和代理代码” 的问题.

四, AIDL, Messenger 与 ContentProvider IPC

不同 IPC 方式适合不同粒度, 不要把 AIDL 当成唯一答案.

AIDL 调用链

1. .aidl 定义接口和 Parcelable 数据类型.
2. 编译器生成 Stub, Proxy, onTransact(), asInterface().
3. Client 调用 Proxy 方法, 参数写入 Parcel.
4. Server Binder 线程执行 Stub 的业务方法, 再把返回值写回 reply.

五, Binder 线程池与调用风险

Binder 回调不是自动跑在主线程. 服务端通常由 Binder 线程池处理事务, 这带来两个面试重点:

• 线程安全: 多个 Client 可并发调用同一服务方法, 共享状态要加锁或串行化.
• 阻塞风险: 同步 Binder 会阻塞调用方线程; 如果主线程发耗时 Binder, 可能导致 ANR.
• 线程池耗尽: 服务端 Binder 线程被慢任务占满后, 新事务排队, 上游看起来像 “系统服务卡住”.
• 反向调用死锁: Client 持锁调用 Server, Server 回调 Client 又等待同一把锁, 容易死锁.

怎么落地: 服务端 Binder 方法里只做参数校验和轻量分发, 耗时工作转到业务线程池; Client 侧避免主线程同步调用不可信远端服务.

六, DeathRecipient 与远端进程死亡

Binder 可以监听远端服务死亡, 常用 linkToDeath() 注册 DeathRecipient.

• 用途: 远端进程崩溃 / 被杀后, Client 能清理缓存代理, 重连服务, 更新 UI 状态.
• 触发: binderDied() 在 Binder 线程里回调, 不要直接更新 UI 或做重活.
• 清理: 服务恢复或不再需要监听时调用 unlinkToDeath().

常见落地流程:

获取远端 Binder -> linkToDeath
调用失败或 binderDied -> 标记服务不可用 -> 清理代理
后台重连/重新 bind -> 成功后重新注册 DeathRecipient

真实踩坑 (风控 SDK 尤其要关注):

• binderDied 与 unlinkToDeath 竞态: 远端断开与本地解注册之间没有原子保证, 连接断开与 unlinkToDeath() 并发时可能漏收死亡通知. 风控场景漏掉一次 “远端进程死亡” 会导致状态残留或误判, 要把死亡处理做成幂等的重连流程.
• 回调洪峰: 服务端高频回调 (如每秒多次上报) 会同时压垮客户端 Binder 线程池和 Handler 队列, 表现为回调堆积, 主线程卡顿. 对策: 回调合并 / 节流, 客户端给回调接口配独立 Binder 线程池, 或改批量拉取加背压.
• 代理被系统静默回收: Binder 代理只在获取它的进程内有效; 长生命周期对象缓存的代理, 一旦所在进程被杀 / 重建就全部失效, 必须重新 bind 拿新代理, 不能把旧代理当永久对象缓存复用.

七, TransactionTooLargeException 与 Parcelable 边界

Binder transaction buffer 通常按约 1MB 级别理解, 而且是进程内并发事务共享, 不是 “每次调用都稳定可用 1MB”.因此大 Bundle, 大 Bitmap, 大列表都可能触发 TransactionTooLargeException.

• Activity/Fragment 传参: 不要把大对象塞进 Intent/Bundle, 传 ID, 详情从数据库/Repository 取.
• Parcelable: 适合轻量结构化对象, 不是大数据通道; 字段要控制数量和嵌套深度.
• 大文件 / 图片: 用 Uri, FileDescriptor, ContentProvider openFile, 共享内存等方式.
• 并发影响: 多个事务同时发生时共享缓冲区, 单次数据即使小于 1MB 也可能失败.

怎么排查: 看异常堆栈里的组件跳转 / 状态保存路径, 重点检查 Intent extras, onSaveInstanceState, AIDL 返回列表, Provider Cursor Window.

八, IPC 设计与排查模板

设计一个稳定 IPC 接口时, 按下面清单回答会更像工程落地:

九, 现代 Binder 工程细节: oneway, 版本, 安全与排障

同步调用 vs oneway

普通 AIDL 调用是同步的: Client 线程等待 Server 执行完并返回. oneway 是异步事务, Client 发出后不等结果, 适合 fire-and-forget 通知.

面试要点: oneway 不是 “无限快”, 它仍然占 Binder 队列和服务端处理能力. 高频事件要节流, 合并或改共享内存 / 批量拉取.

补充完整语义: oneway 调用不阻塞调用方 (发出即返回), 同一线程对同一 Binder 发出的多条 oneway 仍按发送顺序到达, 但调用方不等返回结果, 也感知不到业务层异常. 需要确认 “已生效” 语义时, 应改用同步调用或让服务端显式回调.

AIDL 版本演进

• Parcelable 字段只增不乱删, 新增字段要有默认语义.
• 方法语义不要悄悄改变, 老 Client 和新 Server 必须能互通.
• 系统/跨团队接口可提到 stable AIDL / versioned AIDL: 核心是让接口版本, 兼容性和生成代码可审计.
• 回调接口也要考虑版本, 否则 Server 调用老 Client 新方法会失败.

大数据 IPC 选择

• SharedMemory: 生命周期由引用计数管理, 内核在所有持有者 close() fd 后回收共享内存; 适合双方同时读同一份大块数据的场景.
• FD 跨进程传递: Binder 由驱动在事务中处理 BINDER_TYPE_FD, 在接收进程文件表安装指向同一内核对象的独立 fd; 适合把数据 “所有权” 或流式通道转移给对方, 而不是把数据本体塞进事务. SCM_RIGHTS 是 Unix domain socket 的机制, 不要与 Binder 混淆.

Binder 安全边界

服务端不能因为 “是本机进程调用” 就信任参数. 跨进程入口要做:

1. Binder.getCallingUid()/getCallingPid() 识别调用方.
2. 检查签名权限, manifest permission 或自定义鉴权 token.
3. 对 exported Service/Provider/Receiver 做最小暴露.
4. 必要时结合 AppOps/SELinux/系统权限边界理解平台限制.
5. 所有入参重新校验, 不要信任 Parcelable 内部字段.

Binder 排障线索

• 主线程栈卡在 Binder transact: 怀疑同步远端调用慢或系统服务阻塞.
• 服务端 Binder 线程都在 IO / 锁等待: 线程池饥饿, 上游大量超时.
• TransactionTooLargeException: 检查 Bundle/Intent/AIDL 返回值和并发事务.
• 可通过 dumpsys, ANR traces, Perfetto binder/sched 轨迹定位调用链; 面试里说思路即可, 不要背厂商差异命令输出.

Binder 边界与失败模式

“一次拷贝” 只是在特定 Binder 数据路径下相对传统 IPC 的简化表述, 不包含序列化, 用户态读写和大对象成本. 还要考虑事务 buffer 有限, 线程池耗尽, 同步调用阻塞, binder death, TransactionTooLargeException, FD / 共享内存生命周期和调用方身份校验. 大数据优先文件描述符, 共享内存或分块协议, Binder 只传控制信息和小 payload.

上下文片段: 从 AIDL 到死亡回调

以下内容是 Android Gradle 工程的上下文片段, 不能脱离 manifest, imports, executor, Service 声明和实际权限独立运行; 两个 AIDL 文件放在 src/main/aidl/com/example/ipc/, 构建会生成 Stub/Proxy.

// IProgressCallback.aidl
package com.example.ipc; interface IProgressCallback { void onProgress(int value); }
// IDownloadService.aidl
package com.example.ipc; import com.example.ipc.IProgressCallback;
interface IDownloadService { void start(String taskId); void registerCallback(IProgressCallback callback); void unregisterCallback(IProgressCallback callback); }

上下文片段 (服务端 Service): RemoteCallbackList 在远端死亡时移除回调, 不是事件持久化队列.

private val callbacks = RemoteCallbackList<IProgressCallback>()
private val binder = object : IDownloadService.Stub() {
    override fun start(taskId: String) { executor.execute { notifyProgress(100) } }
    override fun registerCallback(cb: IProgressCallback) { callbacks.register(cb) }
    override fun unregisterCallback(cb: IProgressCallback) { callbacks.unregister(cb) }
}
private fun notifyProgress(value: Int) { val n = callbacks.beginBroadcast(); try { for (i in 0 until n) callbacks.getBroadcastItem(i).onProgress(value) } finally { callbacks.finishBroadcast() } }
override fun onBind(intent: Intent): IBinder = binder

上下文片段 (Client Activity/Repository): 回调必须是 AIDL 生成接口的 Stub; 在解绑时先注销回调, 再解除死亡监听, 避免保留旧 Binder.

private var service: IDownloadService? = null
private var remoteBinder: IBinder? = null
private val callback = object : IProgressCallback.Stub() {
    override fun onProgress(value: Int) { mainHandler.post { renderProgress(value) } }
}
private val deathRecipient = IBinder.DeathRecipient {
    service = null
    mainHandler.post { showServiceUnavailable() }
}
private val connection = object : ServiceConnection {
    override fun onServiceConnected(name: ComponentName, raw: IBinder) {
        remoteBinder = raw
        service = IDownloadService.Stub.asInterface(raw)
        raw.linkToDeath(deathRecipient, 0)
        service?.registerCallback(callback)
    }
    override fun onServiceDisconnected(name: ComponentName) { service = null; remoteBinder = null }
}
private fun unbindDownloadService() {
    service?.unregisterCallback(callback)
    remoteBinder?.unlinkToDeath(deathRecipient, 0)
    unbindService(connection)
    service = null; remoteBinder = null
}

省略项包括 mainHandler, renderProgress, showServiceUnavailable, bind 时的 Intent 和异常处理. 服务端 Binder 方法仍需权限和入参校验, 耗时工作转线程池. 失败演练: 持锁同步 Binder, 服务端反调同一把锁时, 症状为 transact 与 lock wait 互等, 证据是 ANR trace/Binder 链; 修复为不持锁跨进程调用, 杀掉服务进程验证死亡通知和重连.

高频面试题

Q1: Binder 为什么说是一次拷贝? mmap 起什么作用? 普通 Binder 事务不是零拷贝. Server 与 Binder 驱动建立 mmap 映射区后, 驱动把 Client Parcel 数据拷贝到目标进程可访问的 Binder buffer, 接收方通过映射区读取, 减少一次 “内核缓冲区到接收方用户态” 的显式拷贝.

Q2: ServiceManager 的作用是什么? 它负责服务注册和查询, 把服务名映射到 Binder handle. Client 先通过 ServiceManager 找到远端服务代理, 后续事务由 Binder 驱动根据 handle 路由到目标 Binder 实体.

Q3: AIDL, Messenger, ContentProvider 怎么选? AIDL 适合强类型, 多方法, 高并发服务; Messenger 是 Handler + Binder, 适合简单串行消息; ContentProvider 适合跨应用共享结构化数据或文件流. 它们底层都可能走 Binder, 差异在抽象层和使用场景.

Q4: Binder 线程池会带来什么问题? 服务端方法可能被多个 Binder 线程并发调用, 共享状态要线程安全. 耗时任务占满 Binder 线程池会导致后续事务排队; 主线程同步调用慢 Binder 还可能 ANR.

Q5: TransactionTooLargeException 怎么避免? 不要在 Intent, Bundle, AIDL, Parcelable 里传大对象. 传 ID, Uri, 分页数据或 FileDescriptor; 图片 / 文件走 ContentProvider stream 或共享内存. 还要记住 Binder buffer 是并发共享的.

Q6: oneway AIDL 是不是就不会卡? 不是. oneway 只是调用方不等待返回, 事务仍会进入 Binder 队列并占用服务端处理能力. 高频 oneway 可能造成队列堆积和服务端线程压力, 需要节流, 合并, 批量拉取或换共享内存 / FD 方案.

Q7: 跨进程服务怎么做安全校验? 服务端用 getCallingUid/getCallingPid 识别调用方, 结合签名权限, manifest permission, AppOps 或业务 token 做鉴权; 同时对所有参数重新校验, 不要因为本机 IPC 就信任调用方.

易错点 / 追问

• 把 Binder 说成 “零拷贝” 是常见错误, 更稳妥是 “普通事务一次拷贝, 大数据另走共享内存 / FD”.
• AIDL 方法默认可能在 Binder 线程并发执行, 不要默认它运行在主线程或天然串行.
• 持锁发同步 Binder, 在 Binder 回调里再反向调用, 是死锁和 ANR 高频追问.
• Parcelable 只解决序列化效率, 不突破 Binder transaction buffer 限制.
• binderDied() 不是 UI 回调, 要切线程并做轻量清理 / 重连.

多线程并发专题

Android 并发题要同时答 Java 基础和移动端场景: 线程池参数背得出只是起点, 还要知道 HandlerThread, IntentService, 协程调度, 锁, CAS, ANR/OOM 怎么落地排查.

一, Android 线程模型与 HandlerThread

主线程负责 UI, 输入事件和生命周期回调, 耗时任务必须离开主线程. HandlerThread 是带 Looper 的后台线程, 适合串行处理一类任务.

val thread = HandlerThread("worker").apply { start() }
val handler = Handler(thread.looper)
handler.post { /* 串行后台任务 */ }

特点:

• 一个 HandlerThread 对应一个 Looper/MessageQueue, 任务按消息顺序串行执行.
• 适合相机回调, 轻量 IO, SDK 内部串行状态机.
• 不适合大量并行任务; 任务太慢会阻塞后续消息.
• 退出时调用 quitSafely(), 避免线程泄漏.

二, IntentService / JobIntentService 的边界

IntentService 本质是 Service + HandlerThread, 按 Intent 串行执行, 执行完自动停止. 它曾适合后台串行任务, 但在后台执行限制增强后使用场景变窄.

怎么答: 如果是页面内短任务, 用协程 / 线程池; 如果是可延迟, 需约束, 进程死后仍要执行的任务, 用 WorkManager, 不要滥用 Service 常驻后台.

三, Thread, Runnable, Callable 与 Future

Thread 是执行线程的对象, Runnable 表示不返回结果的任务, Callable<T> 可以返回 T 且声明受检异常. ExecutorService.submit() 会把 Runnable 或 Callable 封装为 Future, 调用方可查询完成状态, 获取结果或取消任务.

run() 只是当前调用线程中的普通方法调用, 不会创建新线程; start() 才会让 JVM 创建并调度新线程, 再由该新线程调用 run(). 同一个 Thread 不能重复 start().

NEW -- start() --> RUNNABLE -- 运行或让出 CPU --> RUNNABLE

RUNNABLE -- 竞争 synchronized 监视器 --> BLOCKED
BLOCKED -- 获得监视器 ----------------> RUNNABLE

RUNNABLE -- wait() ------------------------> WAITING
WAITING -- notify()/notifyAll() -----------> BLOCKED -- 获得监视器 --> RUNNABLE

RUNNABLE -- join()/park() -----------------> WAITING
WAITING -- join 目标结束/unpark() ---------> RUNNABLE

RUNNABLE -- wait(timeout) -----------------> TIMED_WAITING
TIMED_WAITING -- notify()/notifyAll()/超时 -> BLOCKED -- 获得监视器 --> RUNNABLE

RUNNABLE -- sleep()/join(timeout)/park(timeout) --> TIMED_WAITING
TIMED_WAITING -- sleep 超时/join 目标结束或超时/unpark() --> RUNNABLE

任意可执行状态 -- run() 结束或未捕获异常 --> TERMINATED

这是 Java Thread.State 的语言级状态, 不等同于操作系统调度器的运行, 就绪或内核等待状态. 从 RUNNABLE 竞争 synchronized 监视器进入 BLOCKED; 无超时的 wait(), join() 或 park() 进入 WAITING; sleep() 或带超时的 wait(), join(), park() 进入 TIMED_WAITING. Object.wait() 被 notify()/notifyAll() 唤醒或超时后, 必须重新竞争同一监视器, 竞争期间为 BLOCKED, 获得监视器后才回到 RUNNABLE. sleep() 到期直接回到 RUNNABLE; join() 的目标结束或超时, 以及 park()/unpark() 的返回不涉及监视器时也直接回到 RUNNABLE.

wait/notify 与 sleep

wait(), notify() 和 notifyAll() 必须由持有同一对象监视器的线程在 synchronized (monitor) 中调用, 否则抛出 IllegalMonitorStateException. wait() 会释放该监视器并进入等待集; 被通知后还要重新竞争锁. 通知可能早于等待, 也可能发生虚假唤醒, 因此条件必须使用 while 重查. sleep() 仅让当前线程在一段时间内不运行, 不释放已持有的锁, 不能替代条件协作.

// 上下文片段:多个消费者等待同一队列时使用 notifyAll, 并始终在 while 中重查条件.
synchronized (monitor) {
    while (queue.isEmpty()) {
        monitor.wait();
    }
    Item item = queue.remove();
}

synchronized (monitor) {
    queue.add(item);
    monitor.notifyAll();
}

手写监视器协作容易遗漏中断, 关闭和异常路径. 生产者消费者优先选择后文的 BlockingQueue; 需要多个条件队列或可中断获取时选择 Condition/ReentrantLock.

四, Executor 与 ThreadPoolExecutor

线程池用于复用线程, 限制并发, 隔离任务类型. ThreadPoolExecutor 关键参数不是背诵, 要能讲执行流程:

提交任务
  -> 工作线程数 < corePoolSize: 新建核心线程
  -> 否则尝试入队 workQueue
  -> 队列满且线程数 < maximumPoolSize: 新建非核心线程
  -> 仍无法处理: RejectedExecutionHandler

五, 协程 Dispatchers 与线程池关系

Kotlin 协程不是 “没有线程”, 它是挂起 / 恢复的调度模型, 最终仍运行在线程上.

• Dispatchers.Main: 主线程, 更新 UI.
• Dispatchers.IO: IO 密集型任务, 适合网络, 磁盘, 底层有弹性线程池策略.
• Dispatchers.Default: CPU 密集型任务, 如排序, JSON 大计算, 图片算法.
• withContext: 切换执行上下文并等待结果.

怎么落地: Repository 做网络 / 数据库可用 withContext(IO); CPU 计算不要丢到 IO; UI 收集 Flow 用生命周期感知 API, 避免页面销毁后继续更新.

六, 锁, volatile, CAS 与 Atomic

并发控制要区分 “可见性, 原子性, 有序性”.

private val running = AtomicBoolean(false)

fun startOnce() {
    if (running.compareAndSet(false, true)) {
        // only one caller can enter
    }
}

悲观锁与乐观锁

悲观锁假设冲突常见, 先通过 synchronized 或 ReentrantLock 排他地保护临界区, 适合写入冲突高且失败重试代价大的共享资源. 乐观锁假设冲突较少, 先读后以 CAS 或版本号提交; 冲突时重读并重试, 适合短小的无阻塞更新.

CAS 的重试不是没有成本: 高竞争下自旋会消耗 CPU, 复杂操作也无法自然地一次 CAS 完成. 值从 A 变为 B 又回到 A 时, 只比较值的 CAS 看不出中间变化, 即 ABA 问题; 需要识别版本语义时使用 AtomicStampedReference 或显式版本号. 不能因为使用了 Atomic 就假定跨多个字段的业务不变量已经成立.

BlockingQueue 与并发集合

BlockingQueue 将生产者消费者的交接, 等待与容量边界封装起来. 有界队列能把过载显式化: 队列满时 put() 阻塞, offer() 可按超时失败, 调用方可降速, 合并或拒绝任务, 而不是让无界积压持续占用内存.

// 上下文片段:容量和超时应按业务延迟, 内存预算及丢弃语义确定.
BlockingQueue<Job> queue = new ArrayBlockingQueue<>(64);
if (!queue.offer(job, 100, TimeUnit.MILLISECONDS)) {
    rejectOrCoalesce(job);
}

七, ThreadLocal 与共享状态

ThreadLocal 为每个线程保存独立副本, 解决的是上下文隔离, 不是共享对象的互斥. synchronized 则让多个线程按顺序访问同一份共享状态. 两者不能互相替代.

// 上下文片段:requestId 在线程内隔离; balance 是共享状态, 必须在同一把锁下更新.
private static final ThreadLocal<String> REQUEST_ID = new ThreadLocal<>();
private final Object balanceLock = new Object();
private int balance;

void handle(String requestId, int delta) {
    try {
        REQUEST_ID.set(requestId);
        synchronized (balanceLock) {
            balance += delta;
        }
    } finally {
        REQUEST_ID.remove();
    }
}

在线程池中, 工作线程会被下一个任务复用. 未调用 remove() 的值可能被后续请求观察到, 或长期持有 Activity, Context, 大缓冲区等对象. 因此每次 set() 后都应在同一任务的 finally 调用 remove(); 能通过方法参数传递的上下文不应滥用 ThreadLocal. Java 定义和弱键泄漏机制可回看 Java 与 JVM 基础.

八, AsyncTask 的历史边界

历史原理: AsyncTask 将 onPreExecute(), 后台 doInBackground() 和主线程 onPostExecute() 串成便捷模板, 内部使用线程池和 Handler 回投结果. Android 3.0 (API 11) 起, execute() 默认串行执行; 需要并行时曾可调用 executeOnExecutor(), 因此不能把它笼统说成始终串行或始终并行.

废弃或限制状态: AsyncTask 在 API 30 起废弃. 它的回调容易脱离 Activity/Fragment 生命周期, 造成页面销毁后的更新, 取消语义不清和任务持有 View/Context. 新项目不应继续使用, 也不应以 executeOnExecutor() 规避这些问题.

现代替代: 页面内短任务使用生命周期绑定的协程, 在 viewModelScope/lifecycleScope 中调度并将状态暴露给 UI; 需约束, 重试或跨进程存活的延迟后台任务使用 WorkManager. Activity/Fragment 的生命周期语境见 四大组件与基础.

九, 死锁与线程安全排查

死锁通常满足互斥, 持有并等待, 不可抢占, 循环等待. Android 里高频场景是 “主线程等后台锁, 后台线程切回主线程” 或 “持锁发同步 Binder”.

排查路径:

1. 抓 ANR traces 或线程 dump, 看主线程卡在哪把锁/哪个 Future/Binder.
2. 找持锁线程, 看它是否等待主线程, IO, 网络或另一个锁.
3. 检查锁顺序是否全局一致, 是否在锁内做耗时操作.
4. 用超时, tryLock, 缩小临界区或串行队列替代复杂嵌套锁.

怎么答: 不要只说 “加锁解决线程安全”, 还要补 “锁粒度, 锁顺序, 锁内不做耗时 / 跨进程调用”.

十, 线程池导致 ANR/OOM 的坑

线程池配置错会从 “优化” 变成 “事故”.

• ANR: 主线程等待线程池结果, 但线程池被长任务占满; 或回调切主线程后主线程被阻塞.
• OOM: 无界队列堆积大量 Runnable/闭包持有 Activity/Bitmap; 线程数过多导致栈内存暴涨.
• 线程饥饿 / 队头阻塞: 低优先级长任务占满池, 高优先级 UI 相关任务排队.
• 任务泄漏: 页面销毁后任务仍持有 View/Context.

十一, 并发设计落地模板

面试讲项目时可以按这个模板说明并发方案:

1. UI 事件进入 ViewModel, 用协程保证生命周期自动取消.
2. Repository IO 任务切到 Dispatchers.IO, CPU 计算切到 Default.
3. SDK 内部串行状态用 HandlerThread 或单线程 Executor.
4. 共享状态用不可变快照, Atomic 或小粒度锁.
5. 线程池设置有界队列, 命名线程, 异常日志和拒绝策略.

结构化并发与可验证性

Android 并发不仅是锁和线程池: 协程任务应绑定 owner scope, 父子取消和异常传播可解释; 不用 GlobalScope 逃避生命周期. 原子性, 可见性和竞态结论用可重复测试, stress test/trace 辅助, 不能以 “本机没复现” 证明安全. UI 状态只在主线程或受控单写者模型更新, 阻塞 I/O 和重 CPU 任务按性质调度.

参数决策与故障演练

CPU 密集任务以可用核心数附近的有限并发起步; 阻塞 I/O 可更高, 但受远端容量, 超时, 内存和队列等待约束. UI 只在主线程提交状态, 不能在主线程 get() 等待. 以下上下文片段的数字仅是压测起始假设; 省略 java.util.concurrent imports, downloadAndDecode(), recordRejected() 和应用退出时的 ioPool.shutdown(), 须记录 active count, 队列长度, 拒绝次数和 P95 等待时间后调整:

val ioPool = ThreadPoolExecutor(2, 4, 30, TimeUnit.SECONDS, ArrayBlockingQueue(32), ThreadFactory { r -> Thread(r, "image-io") }, ThreadPoolExecutor.AbortPolicy())
try { ioPool.execute { downloadAndDecode() } } catch (e: RejectedExecutionException) { recordRejected("image-io") }

拒绝频繁时先合并, 取消或施加背压, 不要无限扩队列. volatile 适合停止标志但不能保证 count++ 原子性. 需要版本语义时用 AtomicStampedReference 或版本号.

伪造 trace (教学, 非真实事故): main: waiting lock B held by worker, worker: waiting lock A held by main 是循环等待证据. 先查锁 owner 是否又在 I/O, Binder 或等待主线程, 再统一锁顺序或移除嵌套锁; 修复后用并发重复测试与线程 dump 验证.

高频面试题

Q1: HandlerThread 适合什么场景? 和线程池区别? HandlerThread 是一个带 Looper 的单后台线程, 任务按消息串行执行, 适合相机, SDK 状态机, 轻量 IO 等需要顺序的任务. 线程池适合多个独立任务并发执行, 但要控制队列和线程数.

Q2: ThreadPoolExecutor 的执行流程是什么? 先看工作线程是否小于 corePoolSize, 是则建核心线程; 否则入队; 队列满且线程数小于 maximumPoolSize 时建非核心线程; 仍处理不了就走拒绝策略. 无界队列会让 maximumPoolSize 基本失效.

Q3: volatile 能保证 i++ 线程安全吗? 不能. volatile 保证可见性和一定有序性, 但 i++ 是读 - 改 - 写复合操作, 不具备原子性. 需要 synchronized, Lock 或 AtomicInteger/CAS.

Q4: 协程 Dispatchers.IO 和 Default 怎么选? IO 用于网络, 磁盘, 数据库等阻塞 IO; Default 用于 CPU 密集计算. 协程最终仍在线程上执行, 选错调度器会导致线程饥饿或 CPU 争用.

Q5: 线程池为什么会导致 ANR 或 OOM? 主线程等待线程池结果会 ANR; 线程池被长任务占满会让关键任务排队. 无界队列堆积大量 Runnable, 线程数过多导致栈内存增长, 任务闭包持有大对象, 都可能 OOM.

易错点 / 追问

• 协程不是替代线程的魔法, 挂起恢复最终仍依赖 Dispatcher 背后的线程.
• volatile 不能保证复合操作原子性, 回答时要区分可见性和原子性.
• 锁内不要做 IO, 网络, 同步 Binder 或切主线程等待, 这是死锁 / ANR 高频点.
• 无界队列 + 大量任务比 “线程数很多” 更隐蔽, 也更容易拖到 OOM.
• IntentService/JobIntentService 不是现代后台任务万能解, 可延迟可靠任务优先考虑 WorkManager.

性能优化

性能优化是中级面试的高频区, 也是你的潜在主场: 风控 SDK 对体积 / 性能敏感, 你的经验比一般应用开发者更有说服力.

一, 性能方法论

性能问题先定义用户路径与指标, 再建立可比较的基线, 最后才改代码. 每个结论须包含设备/OS/构建, 场景, 样本量, 分位数与观测开销; 一次耗时, 平均值或 “感觉变快” 均不足以证明收益.

1. 指标与基线: 定义里程碑和分母, 固定冷/温/热等场景, 记录 P50/P90/P95/P99 及环境.
2. 归因假设: 将退化按主线程, 渲染, CPU, I/O, 锁, Binder, 内存或网络分类, 收集能证伪假设的证据.
3. 最小改动: 只改变已定位路径的一个变量, 保留功能, 线程安全和失败降级.
4. 验证: 在同基线复测分布, 并检查耗时没有转移到首次交互, 内存或电耗.
5. 灰度与回滚: 在线上按版本 / 设备分群观察预设指标, 达到回退条件时关闭开关或回滚制品.

总览章节边界

本章只维护 “指标 → 复现 → 定位 → 假设 → 最小改动 → 基线对比 → 灰度 / 回滚” 方法论. 专项内容分别见启动, 内存,ANR / 卡顿, 工具和线上监控. 具体阈值和工具步骤放在专项章, 避免多处维护过时数字.

方法论演练: 先测量, 再回滚

这是假设性教学案例, 不是实测结果. 发现某个用户路径退化时, 先定义该路径的起止指标和分母, 在相同设备, OS, 构建和场景下取得分位数基线; 再用适当证据提出一个可证伪归因假设. 一次只改一个已定位变量, 复测同一分布并检查没有把成本转移到其他路径, 内存或电耗. 最后以版本 / 设备分群灰度, 预先约定暂停放量和回滚条件. 启动, 内存, ANR, 工具和线上观测的具体操作分别见本章前述链接.

高频面试题

Q1: 如何开始一次性能优化? 先定义用户路径, 指标和分母, 建立可复现基线; 没有基线, 不应先改代码.

Q2: 如何从相关性走到归因? 写出可证伪假设, 收集线程, 渲染, I/O, 锁, 内存或网络证据; 单个慢方法或一次 trace 只能支持下一步调查, 不能单独证明因果.

Q3: 如何验证优化没有制造回归? 在原场景复测分布, 再检查关联路径, 功能正确性, 内存 / 电耗, 并按版本和设备分群灰度; 达到预设回退条件则关闭开关或回滚制品.

Q4: 优化在多个指标间冲突 (如启动更快但内存上涨) 怎么取舍? 先明确业务目标和可接受边界: 为关键路径设预算 (启动耗时预算, 内存预算), 收益按用户可感知指标量化, 成本按回归风险量化; 无法同时满足时按业务优先级取舍, 把取舍和测量证据写进方案记录, 不留无依据的 “平衡”.

Q5: 为什么不能只用平均值评估性能? 平均值掩盖长尾: 缓存命中, GC, 网络抖动会让 P99 远高于均值, 一次冷启动就能拉高整体耗时. 要看 P50/P90/P95/P99 与样本分布, 并固定场景 (冷/温/热, 低端机) 和环境; 具体采样方法见 性能工具专题.

Q6: 没有现成工具和基线时, 怎么开始一次性能排查? 先定义用户路径和可观测指标, 从系统自带能力 (dumpsys, am start -W, logcat, Perfetto) 收集分布; 复现问题路径后用二分定位到具体环节, 建立基线后再改代码. 顺序是 “先测量, 再假设, 最后最小改动”, 不是先改代码再补测量.

Q7: 性能优化和代码可维护性冲突怎么办? 优先优化已定位的热路径, 不牺牲抽象和可读性; 用注释记录优化原因和测量证据; 若优化依赖易碎假设 (版本行为, 厂商差异), 加兼容分支与回归测试并标注核验日期, 避免后续维护者无法回退.

启动优化专项

启动优化要先定义用户可感知里程碑, 再区分本地 / CI 基准测试与线上真实用户监控. 不要用单次 am start -W 或平均值代替完整证据. 方法论, 指标口径与跨域取舍见 性能优化总览.

一, 启动类型与官方指标

• 冷启动: 进程不存在, 系统创建进程, Application 和首个 Activity, 再绘制首帧.
• 温启动: 进程仍在, 但 Activity 需要重新创建或恢复部分状态.
• 热启动: 进程和 Activity 基本保留, 主要恢复到前台.

Android 常用指标:

• TTID(Time to Initial Display): 从启动到第一帧显示, 代表用户第一次看到界面.
• TTFD(Time to Full Display): 从启动到应用报告 “关键内容已可用”, 通常通过 reportFullyDrawn() 或相关 API 标记.

如果项目使用 TTFI 等自定义指标, 必须定义起止点, 交互条件和采集方法, 不能与官方 TTFD 混用.

二, Application 与初始化治理

1. 盘点 Application, ContentProvider, Startup Initializer 和首屏依赖.
2. 只有首帧前必需且线程安全要求明确的任务才同步执行.
3. 可延迟功能按首次使用初始化; 可并行任务仍需避免主线程等待和锁竞争.
4. SDK 必须公开初始化成本, 线程模型, 幂等性和禁用自动初始化的方法.
5. 异步并不天然更快: 如果首屏马上等待结果, 只是把阻塞换了位置.

三, ContentProvider 与 App Startup

系统会在 Application.onCreate() 前实例化清单中的 Provider. 成本来自组件实例化, 类加载, 初始化逻辑和 manifest 合并; 同进程 Provider 初始化不等于每个 Provider 都发生 IPC.

Jetpack App Startup 用单个 InitializationProvider 统一声明依赖和初始化顺序, 可减少散落 Provider, 但不会自动让耗时工作变快. 应删除不需要的自动初始化项, 并为必要初始化建立 trace 与预算.

四, 本地 / CI 与线上观测

Macrobenchmark 是本地或 CI 基准测试工具, 不是线上 APM. 线上指标要考虑采样, 设备性能, 安装状态, 网络, 实验分组和异常值.

五, 排查与验证流程

1. 定义启动场景, TTID/TTFD 里程碑和目标分位数.
2. 固定设备, 构建类型, 预热状态和迭代次数, 建立基线.
3. 用 Perfetto 定位主线程长任务, Binder 等待, I/O, 锁和 RenderThread/GPU 阶段.
4. 改造初始化依赖图, 首屏数据路径, 布局和 Profile.
5. 用 Macrobenchmark 做 A/B 对比, 并在线上按版本和设备档位观察回归.

实操: 命令, Splash 与 trace

命令示例 (需 USB 调试, 已安装目标包): 先执行 adb shell am force-stop com.example.app, 再执行 adb shell am start -W -n com.example.app/.MainActivity.

示意输出, 非真实测量:

Status: ok
LaunchState: COLD
Activity: com.example.app/.MainActivity
ThisTime: 318
TotalTime: 421
WaitTime: 438
Complete

Status 表示启动请求是否成功; LaunchState 是系统判断的启动状态, 需结合本次是否 force-stop 解读; Activity 是最终启动组件. ThisTime 是目标 Activity 启动相关耗时, TotalTime 是本次启动链路耗时, WaitTime 包含 shell 等待启动完成的时间, 因此三者不可互换, 也不能用单次值宣布收益. 重复同一冷/温/热条件并记录分布.

Android 12 (API 31) 及以上用 SplashScreen API; 低版本由 AndroidX 兼容实现.上下文片段 (Activity): installSplashScreen() 必须在 super.onCreate 前调用, 保留条件只应等待极短且首屏必需的状态, 不能把重初始化藏在闪屏后.

override fun onCreate(state: Bundle?) { installSplashScreen().setKeepOnScreenCondition { !uiState.value.ready }; super.onCreate(state); setContentView(R.layout.main) }

在 Perfetto 中为 Application 初始化, 首 Activity 创建, 首屏数据绑定加入稳定的 trace section, 按时间看 Provider/Application/Activity/RenderThread slice 是否跨越首帧; 示例 slice 名是定位线索, 不是工具已生成的测量结论.

高频面试题

Q1: TTID 与 TTFD 有什么区别?
TTID 表示第一帧已经显示; TTFD 表示应用定义的关键内容已准备完成. 只有明确调用 fully drawn 报告并定义业务条件, TTFD 才有可比性.

Q2: ContentProvider 为什么可能拖慢启动?
它在 Application 之前实例化, 可能触发类加载, 对象创建和同步初始化. 问题是初始化工作本身及数量, 不是 “每个 Provider 都必然 IPC”.

Q3: 如何证明优化有效?
本地 trace 证明瓶颈消失, Macrobenchmark 证明受控环境下分布改善, 线上分位数证明真实用户没有回退; 三类证据不能互相替代.

易错点 / 追问

• 不把 TTFI 当官方统一指标; 保留时写清项目定义.
• 不把 Macrobenchmark 放在线上监控栏.
• 不用单次耗时或平均值宣布优化成功.
• 不把所有初始化都扔到后台线程; 先检查首屏依赖和线程安全.

版本与参考资料

• 最后核验: 2026-08-07
• App startup time
• Macrobenchmark overview
• App Startup

内存优化与泄漏排查

内存问题不是只有 Java heap 泄漏. 中级以上排查必须区分 Java, native, graphics, mmap / 文件映射, 线程栈和瞬时峰值, 并用证据判断增长来源. 方法论, 指标口径与跨域取舍见 性能优化总览.

一, 内存问题分类

Retained set (保留集合): 移除对象 A 后变得不可达, 可被回收的对象集合.Retained size (保留大小): 该集合中所有对象 shallow size (对象自身占用, 不含其引用对象) 的总和, 是一个数值而非集合.

Dominator Tree (支配树): 若任意一条从 GC Root 到对象 B 的引用路径都经过对象 A, 则 A 支配 B. 树记录对象之间的直接支配关系; A 的支配子树可帮助近似识别 A 的 retained set, 并据此计算其 retained size. 它不是 retained set 本身, 也不是 retained size 这个数值.

二, Android 常见泄漏

• Activity/Fragment/View 被单例, 静态集合, 长生命周期回调或未取消任务持有.
• Fragment View 生命周期结束后仍保留 binding, adapter 或 listener.
• 非静态内部类, Handler/Runnable, 匿名回调隐式持有外部对象.
• 协程或 Flow 使用了错误 scope, 页面销毁后仍持续收集.
• Cursor, 文件, ParcelFileDescriptor, 线程和 native 资源未关闭.

ViewModel 不应持有 Activity, Fragment 或 View; 需要 Context 时优先注入 Application Context, 并检查对象是否真的需要跨页面生命周期.

三, 标准排查流程

1. 复现并记录页面路径, 设备内存档位, 版本和前后台次数.
2. 观察 GC 后基线是否持续上升, 区分泄漏和峰值.
3. Java 对象使用 heap dump/LeakCanary 找 shortest path to GC root 和 dominator.
4. native/graphics/mmap 使用 Perfetto, heapprofd 和进程内存映射, 不只盯 Android Studio Java heap 图.
5. 修复后重复相同场景, 比较峰值, 回落基线和线上 OOM 分布.

四, Bitmap 与资源释放

现代 Android 中不应把 Bitmap.recycle() 当常规泄漏治理方法. 只要没有引用, 普通 Bitmap 生命周期应交给 GC/native 内存管理; 手动 recycle 可能导致仍在绘制或缓存中的 Bitmap 被提前释放.

更有效的手段:

• 按目标尺寸解码, 限制并发和预取.
• 使用成熟图片库管理请求, 缓存和生命周期.
• 对动画, 视频帧和大图建立内存预算.
• 在明确所有权的底层组件中关闭 Closeable/native 资源.

五, 线上 OOM 治理

• 按系统版本, ABI, 机型内存档位, 页面和前后台状态聚合.
• 上报进程内存快照, 关键业务上下文和图片 / 模型尺寸, 但避免收集敏感数据.
• Java OOM 堆栈不一定指向真正的长期持有者; 需要与趋势, heap dump 和 native 指标关联.
• 为高风险页面设置并发, 缓存和降级策略, 不依赖崩溃后猜测.

完整泄漏演练: Heap Dump 到回归

上下文片段 (Activity): 错误示例把页面引用交给单例; 它用于复现, 不应进入生产代码. 省略 Activity, Bundle 等 imports, 布局中名为 title 的 View, 以及完整生命周期代码.

object EventBus { var listener: (() -> Unit)? = null }
override fun onCreate(state: Bundle?) { super.onCreate(state); EventBus.listener = { title.text = "updated" } }

进入并退出页面后, 在 debug 环境用 Memory Profiler 或 LeakCanary 捕获 Heap Dump. Dominator Tree 的直接支配关系用于定位 retained size 较大的支配子树; 它不等同于 GC Root, 也不能把树本身说成 “可释放集合”.沿 Activity 到 GC Root 的强引用链可得到 EventBus.listener -> lambda -> Activity/View. 修复是在 onDestroy(或更合适的 View 生命周期) 清除回调, 并避免长期对象持有 View: EventBus.listener = null. 随后重复相同进退路径, 检查引用链消失, GC 后基线回落并验证事件功能未丢失. 此流程是操作演练, 未声称任何实际 heap 数字.

高频面试题

Q1: LeakCanary 的核心思路是什么?
在对象生命周期本应结束后使用弱引用观察是否被回收, 必要时触发 heap dump 并分析到 GC Root 的引用链. 它主要帮助定位 Java/Kotlin 对象泄漏, 不能覆盖所有 native/graphics 问题.

Q2: 内存上涨就是泄漏吗?
不是. 缓存, JIT, 图片解码, 线程, mmap 和延迟 GC 都可能使占用上升. 关键看相同场景重复后基线是否持续增长, 资源是否可回收及增长归属.

易错点 / 追问

• 不把 System.gc(), recycle() 当通用修复.
• 不只看 Java heap 就排除 OOM 风险.
• 不把 Application Context 当成 “永远不会泄漏” 的万能对象; 它仍可能持有大缓存和注册项.
• 修复泄漏后还要验证页面功能, 并发取消和缓存命中是否被破坏.

版本与参考资料

• 最后核验: 2026-08-07
• Memory management overview
• Profile your app memory
• Perfetto heapprofd

ANR 与卡顿排查

ANR, 掉帧和 “页面感觉慢” 是不同问题. 阈值依赖触发类型, Android 版本和设备状态; 不要背一个固定秒数覆盖所有场景. 方法论, 指标口径与跨域取舍见 性能优化总览.

一, ANR 类型与版本条件

常见类型包括输入分发超时, BroadcastReceiver, Service, ContentProvider 和前台服务相关超时. 具体阈值与判定逻辑可能随 Android 版本, 前后台状态, CPU / 内存压力和组件类型变化, 排查时应以对应系统版本官方文档和 traces 为准.

回答面试题时不要只说 “主线程卡 5 秒就是 ANR”.更完整的表达是: 系统监控特定组件或交互的完成 deadline; 应用在 deadline 内没有响应时, 系统记录 ANR, 随后结合进程状态决定提示, 杀进程或上报.

二, 掉帧与帧预算

16.7 ms 只是 60 Hz 下一帧周期的近似示例, 不是所有设备的固定标准:

实际是否掉帧还受 VSYNC, 输入, 主线程, RenderThread, GPU, SurfaceFlinger 和可变刷新率影响. 应使用 frame timeline/jank 证据, 而不是看到某方法超过 16.7 ms 就直接下结论.

三, 标准排查路径

1. 先分类: ANR, 主线程长任务, 锁等待, Binder 阻塞, I/O, GC, GPU/渲染还是系统资源不足.
2. 收集 ANR traces, ApplicationExitInfo, logcat, Perfetto 和 Android vitals 聚合数据.
3. 对齐时间线: 主线程状态, 锁 owner, Binder 对端, CPU 调度, I/O 和内存压力.
4. 修复后验证功能正确性, 帧时间分布和线上 ANR rate, 而不是只验证 “不再弹框”.

四, 常见根因

• 主线程同步网络, 磁盘 I/O, 数据库大查询或大对象序列化.
• 主线程等待锁/Future.get(), 锁 owner 又被低优先级线程或 Binder 对端阻塞.
• BroadcastReceiver/Service 中执行过长任务, 没有转交合适的调度机制.
• 大量布局, 重组, 图片解码, GC 或 GPU overdraw 造成连续 jank.
• 进程处于严重 CPU/内存/thermal 压力, 正常工作也错过 deadline.

五, 线上治理

• 使用 Android vitals 观察 user-perceived ANR 和版本趋势.
• 用 ApplicationExitInfo 补充近期退出原因与 traces (受系统和版本支持约束).
• 按版本, 机型, ABI, 页面, 前后台状态和实验组聚合.
• 采集调用栈和 trace 时遵守隐私, 采样与存储预算, 并归档匹配的 mapping/native symbols.

实操: 逐段阅读 traces 与最小帧采样

以下是伪造 traces 片段, 仅用于教学, 不是某次真实 ANR:

"main" tid=1 WAITING
  at java.lang.Object.wait(Native Method)
  - waiting on <0x123> (a java.lang.Object)
  - locked <0x456> (a com.example.UiLock)
"worker" tid=31
  at android.os.BinderProxy.transactNative(Native Method)
  - locked <0x123> (a java.lang.Object)

示意 CPU usage 段, 非真实 ANR:

CPU usage from 0ms to 5120ms later:
  32% 1842/com.example.app: 24% user + 8% kernel
  20% 621/surfaceflinger: 9% user + 11% kernel
  71% TOTAL: 52% user + 18% kernel + 1% iowait

先确认发生时间和进程, 再读 main 的状态与等待对象; 这里 Object.wait() 与 WAITING 一致, main 等 <0x123>, owner worker 又停在同步 Binder. 进程汇总 CPU 不能直接归因给该 worker: 即使 app 进程 CPU 高, 也可能来自同进程其他线程. 下一步必须先核对 tid=31 的线程栈, 调度状态与采样证据; 若 TOTAL 接近满载而 app 低 CPU, 再看调度竞争; iowait 高则继续找磁盘路径, 不能只改锁.

真实 traces 常见的 Binder 对端线索形态可能是 BinderProxy.transactNative, nativePollOnce, binder thread 或 outgoing transaction, 并不保证直接打印 “对端进程名”.用 transaction ID, 时间戳, 服务名 (若 trace 可得) 和 Perfetto 的 binder/sched 轨道关联发起方与服务端; 若服务端线程又在锁或 I/O, 才形成 “main 等 worker, worker 等 Binder 对端” 的下一步判断. 修复可能是缩小锁范围, 禁止持锁 Binder, 给工作设置超时; 验证要重放触发路径, 检查 main 不再等待, 对端完成, 并观察线上 ANR rate.

最小采样上下文片段 (API 24+ Activity): FrameMetrics 统计的是窗口帧指标, 适合轻量趋势, 不替代 Perfetto 归因.

val listener = Window.OnFrameMetricsAvailableListener { _, metrics, _ ->
    val totalNs = metrics.getMetric(FrameMetrics.TOTAL_DURATION)
    if (totalNs > 16_700_000L) recordSlowFrame(totalNs) // 60Hz 近似阈值示例
}
window.addOnFrameMetricsAvailableListener(listener, Handler(Looper.getMainLooper()))
// onDestroy: window.removeOnFrameMetricsAvailableListener(listener)

必须保存 listener 并在 onDestroy 调用 window.removeOnFrameMetricsAvailableListener(listener). 代码中的 16_700_000L 仅是 60Hz 的粗筛示例, 不是通用慢帧阈值; Choreographer 相邻 frameTimeNanos 也只反映回调节奏, 需按刷新率, Frame Timeline 和用户可见 jank 分析.

高频面试题

Q1: ANR 和卡顿有什么区别?
卡顿是帧或交互未按预期 deadline 完成; ANR 是系统针对特定组件 / 交互超时做出的诊断结果. 短暂掉帧不一定 ANR, ANR 前也可能经历较长的不可响应.

Q2: 如何分析一个 ANR traces?
先看主线程状态和栈, 再找锁, Binder, I/O 或 CPU 调度证据; 如果主线程在等待锁, 要继续追 owner 线程, 不能停在表面栈帧.

易错点 / 追问

• 不把所有 ANR 都写成固定 5 秒.
• 不把 16.7 ms 当所有刷新率和所有阶段的硬阈值.
• 不用 “全部放 IO 线程” 替代线程模型与取消设计.
• 线上聚合和本地 Perfetto 各自解决不同问题, 需要关联使用.

版本与参考资料

• 最后核验: 2026-08-07
• Keep your app responsive
• ApplicationExitInfo
• Slow rendering

性能工具专题

性能优化不是 “凭感觉改几行代码”, 而是先观测, 再定位, 再验证. 工具章节的面试重点是: 每个工具看什么, 适合什么问题, 输出如何转化为工程动作. 方法论, 指标口径与跨域取舍见 性能优化总览.

一, 工具选型总览

工具回答要避免 “列名词”, 而要说清楚 “我怀疑什么 → 用什么采样 → 看哪个指标 → 怎么验证改动”.

二, Android Studio Profiler

Android Studio Profiler 适合本地开发阶段快速观察 CPU, Memory, Network, Energy.

• CPU Profiler: 看主线程是否有长任务, 方法调用耗时, 线程调度. 可用 Java/Kotlin Method Trace (分 Sampled 与 Instrumented 两种模式), 采样开销更低, 插桩更细但扰动更大.
• Memory Profiler: 看 Java/Kotlin 堆, 对象分配, GC 频率, Heap Dump. 适合发现短时间内对象抖动和明显泄漏.
• Network Profiler: 看请求时序, 流量大小, 频率, 但复杂线上网络问题仍要配合 OkHttp event listener, 服务端日志和抓包合规流程.
• Energy Profiler: 关注 wakelock, 定位, 网络等耗电行为.

局限: Profiler 连接调试进程会带来观测扰动, 结论要用 release-like 包, Macrobenchmark 或 Perfetto 再验证.

三, Perfetto, Systrace 与 Trace sections

Perfetto 是现代 Android 系统级 tracing 工具, 可观察 CPU 调度, Binder, 线程状态, Choreographer, SurfaceFlinger, RenderThread, I/O 等. Systrace 是旧版工具, 很多概念仍沿用, 但新项目优先用 Perfetto.

import androidx.tracing.Trace

fun bindFeed(items: List<Item>) {
    Trace.beginSection("Feed.bind")
    try {
        adapter.submitList(items)
    } finally {
        Trace.endSection()
    }
}

Trace sections 的价值是把业务阶段写进系统 trace, 让你在 Perfetto 里看到 “哪段业务代码” 对应主线程长任务. 命名要稳定, 短, 能定位模块, 避免把用户敏感信息写入 trace 名称.

看 Perfetto 的常见路径:

1. 先看主线程是否 Running 太久或频繁 Blocked.
2. 看耗时段是否跨过 VSync 导致 missed frame.
3. 看 RenderThread/GPU 是否被复杂绘制或纹理上传拖慢.
4. 看 Binder, I/O, 锁等待是否阻塞主线程.
5. 结合自定义 Trace sections 还原业务阶段.

四, Macrobenchmark 与 Baseline Profile

Macrobenchmark 用独立测试 APK 驱动目标 App, 在接近真实环境下测启动, 滚动, 页面跳转等宏观性能. 它适合做性能回归门禁, 比普通单元测试更贴近用户体验.

@Test
fun startup() = benchmarkRule.measureRepeated(
    packageName = "com.example.app",
    metrics = listOf(StartupTimingMetric()),
    iterations = 10,
    startupMode = StartupMode.COLD
) {
    pressHome()
    startActivityAndWait()
}

Baseline Profile 是把关键路径的类和方法提前提供给 ART, 安装后可更早编译热点代码, 改善冷启动和首帧性能. 典型流程是用 profileinstaller + androidx.baselineprofile Gradle 插件生成 / 合并 profile, 再用 Macrobenchmark 验证收益.

面试要点:

• Macrobenchmark 关注稳定设备, 固定版本, 足够迭代次数和噪声控制.
• Baseline Profile 不是万能优化, 主要改善解释执行 / JIT 预热带来的启动和关键路径抖动.
• 性能数据要保存历史趋势, 否则无法判断回归.

五, LeakCanary 与内存定位

LeakCanary 自动观察 Activity, Fragment, ViewModel 等对象生命周期, 对象应被回收却仍被引用时触发 heap dump 并给出泄漏引用链.