Android 应用开发面试学习清单

共 13 个主题分组、64 篇内容

面向 中级(3-5 年)Android 应用开发岗 的系统复习资料。

你的背景画像:设备指纹 / 风控 SDK 开发者,强项 C/C++ 与 NDK/JNI、系统底层、逆向视角; 短板在 UI 层(View / Compose)、Kotlin 协程 / Flow、Jetpack 全家桶、应用架构。 副技能 iOS 基础。

本资料策略:重点补短板(★),把强项包装成差异化亮点(☆),iOS 作为跨端谈资(辅)。

如何使用这套资料

1. 先读 01-面试路线与自我定位.md,想清楚怎么把“风控 SDK 背景“讲成应用岗的优势。
2. 按下面“复习路线“的优先级顺序学,先攻短板(协程 → UI → Jetpack → 架构 → 测试体系)。
3. 每篇结构统一:知识点讲解 → 高频面试题 + 参考答案要点 → 易错点 / 追问。
4. 学完一个知识点,回到本页的“自测清单“打勾 - [x],追踪进度。

复习路线(按优先级)

自测清单(学完打勾)

01 面试路线与自我定位

• STAR 法则讲项目
• 怎么把风控 SDK 项目讲成应用岗亮点
• 常见 HR / 反问环节
• 算法准备方向

02 Kotlin 语言核心

• val/var、空安全(?. ?: !!)、平台类型
• 扩展函数 / 扩展属性的原理(静态分发)
• 高阶函数、Lambda、inline/noinline/crossinline
• 作用域函数 let/run/with/apply/also 区别
• data class / sealed class / object / 伴生对象
• 属性委托 by lazy / Delegates.observable / 自定义委托
• 泛型型变 in/out、reified

03 Kotlin 进阶专题

• inline / reified / value class / sealed 类型的面试表达
• Kotlin 泛型、协变逆变、委托与 DSL 设计能力
• 协程状态机、Flow 操作符与性能陷阱的深入理解

04 Kotlin 协程与 Flow ★

• suspend 原理:CPS 变换与状态机
• 结构化并发:CoroutineScope / Job / 父子关系
• Dispatchers(Main/IO/Default)与 withContext
• launch vs async、Deferred
• 取消机制(协作式)与异常传播
• CoroutineExceptionHandler / supervisorScope / SupervisorJob
• 冷流 Flow vs 热流;StateFlow vs SharedFlow
• flowOn / buffer / conflate / collectLatest

05 RxJava 与响应式编程

• Observable / Observer / Subscriber 核心模型
• 变换(map/flatMap)、过滤(filter/debounce)、合并(merge/zip)
• 线程切换 SubscribeOn / ObserveOn 原理
• 背压机制 Flowable / Single / Completable
• 生命周期管理与内存泄漏防护

06 Java 与 JVM 基础

• HashMap 原理(扩容、红黑树、并发问题)、ConcurrentHashMap
• synchronized vs ReentrantLock、volatile、CAS、AQS
• 线程池 ThreadPoolExecutor 七参数与拒绝策略
• JMM 内存模型、happens-before
• JVM 内存区域、GC 算法与垃圾回收器
• 类加载机制、双亲委派

07 Android 四大组件与基础

• Activity 生命周期、启动模式、taskAffinity
• Fragment 生命周期与 commit/commitNow、懒加载
• Service(前台/绑定)、IntentService、JobScheduler/WorkManager
• BroadcastReceiver(静态/动态、有序、LocalBroadcast)
• ContentProvider 与跨进程数据共享
• Intent、序列化 Serializable vs Parcelable、Context 类型

08 UI 体系 - View 与自定义 View ★

• View 绘制三大流程 measure / layout / draw
• MeasureSpec 与 onMeasure、wrap_content 处理
• 事件分发 dispatch / intercept / onTouchEvent
• 滑动冲突(外部 / 内部拦截法)
• 自定义 View / ViewGroup、自定义属性
• invalidate vs requestLayout、硬件加速
• Window / DecorView / ViewRootImpl 关系

09 UI 体系 - Jetpack Compose ★

• 声明式 UI 思想、@Composable 原理
• 重组(Recomposition)与跳过、稳定性
• 状态:remember / mutableStateOf / state hoisting
• 副作用:LaunchedEffect / DisposableEffect / SideEffect / derivedStateOf
• CompositionLocal、Modifier 原理与顺序
• 三大阶段 Composition / Layout / Drawing
• 与 View 互操作、性能优化(key、lambda)

10 Compose 深水区

• 重组跳过、稳定性、remember key 与状态提升
• Modifier、Layout、SubcomposeLayout、自定义绘制核心机制
• Compose 性能分析、列表优化与 View 互操作边界

11 Android 版本适配

• Android 版本演进中的行为变更与兼容策略
• targetSdkVersion 升级风险、灰度验证与回滚方案
• 权限、后台限制、通知、前台服务等高频适配点

12 图片加载与缓存

• 图片加载链路:请求、解码、变换、缓存、展示
• 内存缓存 / 磁盘缓存 / 网络缓存的命中与失效策略
• 大图、列表滑动、生命周期绑定与 OOM 防护

13 Jetpack 架构组件 ★

• ViewModel 原理、生命周期、SavedStateHandle
• Lifecycle / LifecycleObserver、LiveData 原理与粘性事件
• Room(实体 / DAO / 迁移 / 协程&Flow 支持)
• Navigation、Hilt 依赖注入(vs Dagger)
• DataStore(替代 SharedPreferences)、WorkManager、Paging3

14 应用架构 - MVVM 与 MVI ★

• MVC / MVP / MVVM / MVI 演进与对比
• 单向数据流、State / Intent / Effect
• 分层(data / domain / ui)、Repository 模式
• UseCase、依赖倒置、可测试性

15 App 架构落地案例

• 分层架构在真实业务中的模块职责划分
• Repository、UseCase、ViewModel 与 UI State 协作链路
• 架构取舍、团队协作、可测试性与演进成本表达

16 测试体系

• 单元测试 JUnit、Mockito、Robolectric
• UI 测试 Espresso、UI Automator
• 测试驱动开发 TDD 原理与实践

17 组件化路由与模块通信

• 组件化拆分、依赖管理与 ARouter 原理
• 模块间通信、接口暴露与服务发现
• 资源冲突处理、公共库提取与解耦策略

18 Android 系统原理

• Handler / Looper / MessageQueue、同步屏障、IdleHandler
• Binder 机制(一次拷贝、mmap、驱动)
• AMS / 应用启动流程 / 进程创建(Zygote)
• 类加载与热修复 / 插件化原理
• 进程间通信方式对比

19 Binder 与 IPC 深入

• Binder 通信模型、驱动、ServiceManager 与代理对象
• AIDL、Messenger、ContentProvider 等 IPC 方式对比
• 大数据传输、死亡监听、线程池与安全校验边界

20 多线程并发专题

• Java/Kotlin 并发原语、线程池、锁与协程调度对比
• 共享状态、可见性、竞态条件与死锁排查方法
• Android 主线程约束、后台任务调度与取消传播

21 性能优化

• 启动优化(冷 / 热启动、Splash、延迟初始化)
• 内存泄漏(常见场景、LeakCanary 原理)、内存抖动
• 卡顿与掉帧、Choreographer、ANR 原理与定位
• 包体积优化(R8/ProGuard、资源、so)
• 布局优化、工具(Profiler / Perfetto / Systrace)

22 启动优化专项

• 冷启动 / 温启动 / 热启动指标与阶段拆解
• Application 初始化治理、懒加载与异步预热边界
• SplashScreen、Baseline Profile、启动链路监控与回归验证

23 内存优化与泄漏排查

• Android 内存模型、Java 堆 / Native 堆 / 图形内存差异
• 常见泄漏场景与 LeakCanary / MAT 分析路径
• 内存抖动、Bitmap、缓存上限与线上告警指标

24 ANR 与卡顿排查

• ANR 类型、触发阈值、traces 与主线程阻塞定位
• Choreographer、VSync、掉帧指标与 Perfetto 分析
• 锁竞争、IO、Binder 调用、布局过深等排查路径

25 性能工具专题

• Android Studio Profiler、Perfetto、Systrace 的适用场景
• Macrobenchmark、Baseline Profile 与启动/滚动性能验证
• 线上性能指标、采样策略、问题复现与闭环治理

26 APM 与线上监控

• 崩溃监控、错误堆栈聚合与分发
• 性能指标采集:FPS、启动时间、网络耗时
• 线上治理体系与告警策略

27 存储体系与 Scoped Storage

• 内部 / 外部 / App 专属目录与 MediaStore 使用场景
• Scoped Storage 迁移路径、兼容开关与权限边界
• 大文件、缓存、数据库、日志文件的存储治理方案

28 网络协议

• HTTP / HTTPS / HTTP2 / QUIC 原理与握手流程
• TCP vs UDP、三次握手、滑动窗口与拥塞控制
• DNS 劫持、证书校验与网络安全防护

29 网络排障专项

• DNS、TCP/TLS、HTTP/2、QUIC 等链路问题定位
• OkHttp 日志、抓包、证书、代理与弱网复现方法
• 超时、重试、连接池、缓存、网关错误的排查流程

30 数据库进阶

• SQLite 索引、事务、WAL、锁与查询优化原则
• Room 迁移、缓存一致性、分页与离线数据同步
• 数据库排障:慢查询、损坏恢复、并发写入与监控

31 Gradle 与工程化

• Gradle 生命周期、Task Graph、增量构建与缓存机制
• 插件开发、Transform API、依赖管理技巧
• 项目工程化最佳实践

32 Gradle 构建性能专题

• Configuration Cache、Build Cache、并行构建适用条件
• 构建耗时定位、插件治理与 CI 构建优化策略

33 CI/CD 与发布体系

• CI 流水线阶段:检查、测试、构建、签名、发布
• 灰度发布、渠道包、回滚与版本门禁设计
• 自动化质量门禁、制品管理与敏感信息保护

34 隐私合规与权限治理

• 权限申请时机、最小化原则与用户拒绝后的降级体验
• 隐私政策、数据采集清单、SDK 合规审计流程
• 敏感信息脱敏、加密、日志治理与跨境/第三方共享风险

35 登录鉴权与账号体系

• 登录态、Token、Refresh Token 与会话续期机制
• OAuth2 / 单点登录 / 设备绑定的核心流程与风险点
• 账号安全、风控拦截、退出登录与多端一致性处理

36 支付订单与状态机

• 订单状态流转、幂等、防重放与超时关闭机制
• 支付渠道回调、客户端轮询、服务端对账协作
• 异常订单、补偿任务、退款与状态机设计表达

37 推送 / 长连接 / 保活

• 三方推送厂商集成与 FCM、保活策略
• 长连接协议、心跳设计与断线重连机制
• 消息送达率优化与推送链路监控

38 埋点与数据采集 SDK

• 埋点模型、事件属性、会话、用户标识与采样策略
• 数据缓存、批量上报、重试、压缩与弱网治理
• 隐私合规、SDK 性能开销与线上质量监控

39 主流第三方库

• OkHttp(拦截器链、连接池、缓存)
• Retrofit(动态代理、协程适配)
• Glide / Coil(三级缓存、生命周期绑定)
• Gson / Moshi / kotlinx.serialization
• EventBus / 依赖注入框架对比

40 Android 安全与逆向

• APK 结构、反编译、脱壳与签名校验原理
• 常用逆向工具链、静态/动态分析、Frida 挂钩
• 安全编码实践与加固保护方案

41 移动安全防护体系

• 应用加固、反调试、完整性校验与风险分层思路
• 数据加密、密钥管理、通信安全与本地存储防护
• 设备指纹、风控 SDK、防刷防薅羊毛的应用岗表达

42 NDK 与 JNI ☆

• JNI 数据类型映射、签名规则
• 局部 / 全局 / 弱全局引用、引用表溢出
• JNIEnv vs JavaVM、线程 AttachCurrentThread
• 静态注册 vs 动态注册 RegisterNatives
• native crash 捕获(signal / breakpad)
• CMake / ABI / so 加载与裁剪、现代 C++(RAII / 智能指针)

43 NDK Native 调试与 Crash 定位

• tombstone、addr2line、符号表、so 映射与崩溃还原
• lldb / ndk-stack / breakpad 等 Native 调试工具链
• JNI 边界、线程、信号处理与线上 Native Crash 归因

44 iOS 基础速览(辅)

• Swift 基础、可选值、ARC 内存管理
• UIViewController 生命周期、UIKit vs SwiftUI
• GCD、与 Android 概念对照

45 Kotlin Multiplatform

• KMP 架构模型、expect/actual 关键字与共享策略
• 跨端业务逻辑复用、依赖管理与构建流程
• KMP 在移动端的落地场景与优劣分析

46 跨端技术对比

• Flutter、React Native、KMP、WebView Hybrid 的架构差异
• 性能、研发效率、生态、包体积与团队成本取舍
• 跨端落地中的平台能力、调试、发布与降级策略

47 WebView 与 Hybrid

• WebView 生命周期、缓存、进程、性能与内存治理
• JSBridge 通信模型、线程切换与安全白名单校验
• Hybrid 页面加载优化、异常监控与降级兜底

48 插件化 / 热修复 / 动态化

• 插件化类加载、资源加载、组件代理基本原理
• 热修复方案对比、兼容风险与发布安全边界
• 动态化收益、性能成本、合规风险与降级策略

49 音视频 / Media3 / ExoPlayer

• 编解码、渲染流程与 Media3/ExoPlayer 核心架构
• 预加载、缓存、倍速、软硬解切换与性能监控
• 业务场景下的播放优化、异常处理与功能定制

50 LeetCode Hot 100 算法清单

• 数组 / 哈希表 / 链表 / 栈与队列常用算法
• 树 / 图 / 递归与回溯、动态规划、贪心策略
• 二分搜索、滑动窗口、位运算、并查集

51 算法补充专题

• 排序算法对比、复杂数据结构原理
• 深度优先搜索 DFS / 广度优先搜索 BFS 进阶
• 常见大厂面试题复现与思维模型

52 海量数据处理

• 分治、MapReduce 思想与海量数据过滤/排序
• 布隆过滤器、BitMap、Trie 树适用场景
• Top K 问题、外排序、内存受限下的算法方案

53 Android 业务算法场景

• LRU、滑动窗口、优先队列等算法在业务中的应用
• 推荐、搜索、去重、限流、风控规则的算法化表达
• 复杂度分析、边界条件与工程落地取舍说明

54 操作系统与数据库基础

• 进程 / 线程 / 调度 / 内存管理与 Android 运行时关系
• 数据库索引、事务、ACID、范式与规范化
• 文件系统、锁、信号、系统调用在移动端的应用

55 操作系统进阶

• 虚拟内存、mmap、文件 IO、Page Cache 与性能影响
• 操作系统内核机制、同步原语与 Android 底层关系

56 设计模式与 Android 源码应用

• 创建型、结构型、行为型模式在 Android 源码中的体现
• 观察者、工厂、适配器、代理等高频模式的实践
• 设计原则 SOLID、解耦与可扩展性评估

57 系统设计场景题

• 即时通信、Feed、推送、离线缓存等移动场景设计框架
• 客户端架构、数据同步、弱网容错与服务端协作边界
• 容量估算、性能指标、监控告警与灰度降级方案

58 移动端系统设计题库

• 核心业务场景的系统化表达、架构图绘制
• 应对三高(高并发/高可用/高性能)的客户端方案

59 项目经验与软技能

• 项目价值、技术难点、个人贡献与业务闭环表达
• 团队沟通、冲突处理、技术视野与职业规划

60 项目复盘专题

• STAR / 背景目标行动结果结构化复盘项目
• 指标提升、故障处理、协作冲突与技术取舍表达
• 失败经验、重做方案、个人贡献边界与证据准备

61 简历追问防御清单

• 简历每个技术点准备原理、实践、指标与追问答案
• 区分亲自负责、参与协作、学习了解的边界表述
• 针对夸大风险、数据真实性、项目细节进行反问演练

62 Vibe Coding

• AI 辅助下的快速原型、实验性开发流程
• 与 AI 协作的编码风格、意图表达与反馈循环

63 Harness Engineering

• AI 辅助开发中的自动化验证、反馈闭环设计
• 为 AI 构建上下文、工具链集成与质量门禁

64 AI Coding 工程化进阶

• Context Engineering、任务拆解与 AI 代码审查闭环
• MCP、工具调用、自动化验证与可追溯开发流程
• AI 生成代码的风险:幻觉、越权修改、测试缺口与治理

面试路线与自我定位

这一篇不讲技术,讲策略。你不是普通的应届/转行选手,你是“底层强、应用层有空白“的特殊画像。打法和别人不一样。

一、你的优势与劣势盘点

优势(面试中要主动亮出来)

这些是你的护城河。很多 App 团队正缺懂 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,为什么转应用开发?能行吗?” 准备好这套话术:

“我在风控 SDK 做的是 Android 最底层的部分——native 采集、对抗、性能与体积优化。这让我对系统机制(Binder、进程、内存、so 加载)有比一般应用开发者更深的理解。我想往上走,把这份底层功底用在完整的产品上。UI 和上层框架是我最近重点补的,我已经系统学了协程、Compose、Jetpack 和 MVVM 架构。”

关键三点:

• 不贬低过去:底层经验是稀缺的,要包装成“比别人更懂系统“。
• 承认短板但展示行动:“我已经系统学了 X、Y、Z”(配合本资料的学习成果)。
• 给团队一个理由:“我能补团队在 native / 性能 / 安全上的短板”。

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

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

• 音视频 / 直播 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(02 篇,最薄弱,先攻)。
• 第 3-4 周:UI 体系 View + Compose(05、06 篇)。
• 第 5 周:Jetpack + 架构(07、08 篇)。
• 第 6 周:系统原理 + 性能优化(09、10 篇)。
• 第 7 周:复习强项 NDK/JNI 做亮点(11),刷主流库(12)。
• 第 8 周:项目复盘(14)、算法、模拟面试、iOS 速览(13)。

六、心态提醒

你不是从零开始。底层功底是很多面试官给不出、也很羡慕的硬实力。你要补的是“上层广度“,这是可以在两个月内系统补齐的知识型短板,而不是需要多年积累的经验型短板。把姿态放在“我是带着系统功底来做应用“的位置,而不是“我是个 UI 新手“。

Kotlin 语言核心

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

一、空安全(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,线程安全延迟初始化。

二、扩展函数 / 扩展属性

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

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

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

三、高阶函数与 inline

inline fun <T> measure(block: () -> T): T { ... }

• Lambda 默认会被编译成 Function 对象,有对象创建开销。
• inline 把函数体和 lambda 直接内联到调用处,消除对象分配,还能让 lambda 内的 return 直接返回外层函数(非局部返回)。
• 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 才持有外部类引用。

六、委托(Delegation)

• 类委托:class B(b: Base) : Base by b,把接口实现委托给成员,组合优于继承。
• 属性委托:
  • by lazy { }:首次访问时计算,默认 SYNCHRONIZED 线程安全。
  • Delegates.observable:值变化时回调。
  • Delegates.notNull():非空但延迟赋值。
  • by map:从 Map 读取属性。
  • 自定义委托需实现 getValue / setValue。

七、泛型型变

• out T(协变):只能作为输出(生产者),List<out T>,List<String> 可赋给 List<Any>。
• in T(逆变):只能作为输入(消费者),Comparator<in T>。
• * 星投影:不关心具体类型时使用。
• PECS:Producer-Extends(out),Consumer-Super(in)。面试可用一句话落地:只从容器里读 T 用 out,只往容器里写 T 用 in;既要读又要写具体 T 时通常不要加型变,否则编译器会限制不安全操作。

高频面试题

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

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

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

Q4:inline 一定能提升性能吗? 不一定。inline 消除 lambda 对象分配,适合高阶函数;但内联会增大字节码,对大函数滥用反而增加体积、降低性能。Kotlin 编译器会对大 inline 函数告警。

Q5:Kotlin 的 Unit、Nothing、Any 区别? Any 是所有非空类型的根(类比 Object);Unit 表示无返回值(类比 void,但是真实对象);Nothing 表示永不返回(抛异常或死循环),是所有类型的子类型。

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

Kotlin 进阶专题

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

一、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 会把实现暴露给调用方字节码,库开发要注意二进制兼容和实现细节泄露。

三、委托:类委托、属性委托与工程价值

委托强调“组合优于继承”。类委托把接口实现转交给成员对象,属性委托把 getter/setter 的通用逻辑抽出去。

Android 中常见落地是 ViewBinding 委托、SharedPreferences/DataStore 属性包装、配置中心读取和页面参数校验。

四、sealed interface、value class 与领域建模

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

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 设计和文档约束。

五、context receivers 概览

context receivers 让函数声明“需要哪些上下文能力”,调用点处于对应上下文时才能调用。它适合 DSL、依赖环境显式化、避免参数列表过长。

// 概念示例:实际可用性取决于 Kotlin 版本和编译选项
context(Logger, CoroutineScope)
fun launchTracked(name: String, block: suspend () -> Unit) {
    log("start $name")
    launch { block() }
}

面试中不要把它讲成 Android 必备能力,而是讲成“更显式的上下文依赖建模”。工程落地要看团队 Kotlin 版本、IDE 支持、可读性和 Java 互操作成本。

六、JVM 字节码角度看 Kotlin

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

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

七、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 的非空类型。

Kotlin 协程与 Flow ★

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

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

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

• 挂起(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),状态机从上次挂起点恢复执行。

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

// 你写的:
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(),状态有 Active/Completing/Cancelled/Completed。
• 父子关系:协程内启动的子协程,其 Job 是父 Job 的子节点。

Android 常用现成 scope:

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

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 切换上下文并挂起等待结果返回,是最常用的线程切换方式。IO 与 Default 共享底层线程池,两者间切换不一定真正换线程(优化)。

五、launch vs async

• launch:返回 Job,不返回结果,适合“发射后不管“的副作用;异常立即传播给父。
• async:返回 Deferred<T>,await() 取结果,适合并发计算多个值;异常在 await() 时抛出。

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

六、取消机制(协作式)

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

• 所有 kotlinx.coroutines 的 suspend 函数(delay 等)在恢复时会检查取消状态,抛出 CancellationException。
• 纯 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,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。
• 无初始值,不去重。
• 适合一次性事件(导航、Toast、SnackBar)—— 用 replay=0 避免事件重放。

对比表

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

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

进阶补充: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 必须释放监听器,否则会泄漏。

combine / zip / flatMapLatest

stateIn / shareIn

stateIn 把冷 Flow 转成有当前值的 StateFlow;shareIn 把冷 Flow 共享给多个订阅者。面试要说明 scope、started 策略和 replay。

协程测试

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

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

高频面试题

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

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

Q3:launch 和 async 区别?async 不 await 会怎样? launch 返回 Job 无结果,async 返回 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 重新触发;热流独立于收集者。状态用 StateFlow(有初值、去重),事件用 SharedFlow(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)时启动收集,离开时取消,再次进入重启,是官方推荐的安全收集方式。

RxJava 与响应式编程

RxJava 在新项目里常被协程/Flow 替代,但大量老 Android 项目仍在使用。中级面试经常考“你能不能维护老项目,并解释迁移取舍“。

一、响应式编程心智模型

RxJava 把异步事件看成数据流:上游发射、操作符转换、下游订阅、调度器切线程。

二、Observable、Single、Maybe、Completable、Flowable

三、调度器与线程切换

subscribeOn 影响上游订阅线程,通常只第一个生效;observeOn 切换下游观察线程,可多次使用。

api.getUser()
    .subscribeOn(Schedulers.io())
    .observeOn(AndroidSchedulers.mainThread())
    .subscribe(::renderUser, ::showError)

四、常用操作符

• 变换:map、flatMap、concatMap
• 过滤:filter、distinctUntilChanged
• 组合:zip、combineLatest、merge
• 错误:onErrorReturn、retryWhen
• 生命周期:takeUntil、AutoDispose/RxLifecycle

五、背压与资源释放

背压问题来自上游生产快、下游消费慢。Flowable 可配置 BUFFER、DROP、LATEST 等策略。Android 页面销毁时必须 dispose,否则可能泄漏 Activity。

六、RxJava 与协程/Flow 对比

高频面试题

Q1:subscribeOn 和 observeOn 区别? 答:subscribeOn 决定订阅发生在哪个线程,通常第一个生效;observeOn 决定后续观察者在哪个线程执行,可以多次切换。

Q2:RxJava 为什么容易内存泄漏? 答:订阅链持有 observer/lambda,如果页面销毁后未 dispose,异步结果回来仍可能持有 Activity/View。

Q3:老项目 RxJava 怎么迁移到协程? 答:先从边界层开始,比如 Retrofit 支持 suspend;内部复杂链路可逐步迁移,不要一次性重写全部业务流。

易错点 / 追问

• 不要把所有异步都写成复杂操作符链。
• 不要忘记错误分支,否则链路会终止。
• 不要在主线程做重 map/flatMap 计算。

Java 与 JVM 基础

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

一、集合框架

HashMap(必考)

• 结构:数组 + 链表 + 红黑树(JDK8)。链表长度 ≥ 8 且数组长度 ≥ 64 转红黑树;退化阈值 6。
• 初始容量 16,负载因子 0.75,扩容翻倍(2 倍)。容量始终是 2 的幂,便于用 (n-1) & hash 取代取模。
• 扰动函数:hash = h ^ (h >>> 16),让高位参与运算,减少碰撞。
• JDK8 头插改尾插:JDK7 头插法在并发扩容时会形成环形链表导致死循环;JDK8 改尾插缓解,但 HashMap 仍非线程安全。
• 并发问题:多线程 put 可能丢数据、扩容期间读到 null。

ConcurrentHashMap

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

其他

• ArrayList(动态数组,扩容 1.5 倍)vs LinkedList(双向链表)。
• HashSet 底层是 HashMap;LinkedHashMap 维护插入/访问顺序(可做 LRU)。

二、并发

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

• 保证可见性(写立即刷主存,读从主存)和有序性(禁止指令重排,插入内存屏障)。
• 不保证原子性(如 i++ 仍不安全)。
• 经典用途:双重检查锁单例的实例字段。

CAS 与 AQS

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

线程池 ThreadPoolExecutor

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

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

三、JVM 内存与 GC

内存区域

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

GC

• 判活:引用计数(有循环引用问题)vs 可达性分析(GC Roots,主流)。
• GC Roots:虚拟机栈引用、静态变量、常量、JNI 引用等。
• 回收算法:标记-清除(碎片)、复制(浪费空间,适合新生代)、标记-整理(适合老年代)。
• 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 参数经验当作移动端结论。

类加载

• 过程:加载 → 验证 → 准备 → 解析 → 初始化。
• 双亲委派:类加载请求先委托父加载器,父无法加载才自己加载。保证核心类不被篡改(如自定义 String 不会覆盖系统的)。
• 打破双亲委派:SPI、热修复、插件化、Tomcat 的 WebappClassLoader。

高频面试题

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 密集型设为核数+1;IO 密集型设为核数×2 或更高(经验值,需压测)。

Q6:双亲委派的作用?为什么 Android 热修复要打破它? 保证类的唯一性和安全性。热修复需要让补丁类优先于原类被加载,所以要把补丁 dex 插到 classloader 的 dexElements 数组前面,本质是绕过/利用加载顺序。

四大组件与基础

四大组件是 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 等)可动态控制。

二、Fragment

• 生命周期比 Activity 多:onAttach → onCreate → onCreateView → onViewCreated → onStart → onResume ...→ onDestroyView → onDestroy → onDetach。
• commit vs commitNow vs commitAllowingStateLoss:commit 异步;commitNow 同步;前两者在 onSaveInstanceState 后调用会抛 IllegalStateException,allowingStateLoss 容忍但可能丢状态。
• 现代用 FragmentStateAdapter + ViewPager2 替代旧懒加载;getViewLifecycleOwner 观察 LiveData 防泄漏。
• 为什么用 Fragment 而非多 Activity:轻量、复用、共享 ViewModel、单 Activity 架构配合 Navigation。

三、Service

• 启动方式:startService(独立运行,需手动 stopSelf/stopService)vs bindService(绑定,随调用者销毁,可通信)。
• 前台服务:必须 startForeground 显示通知(Android 8+ 后台限制),用于音乐、定位、下载。Android 12+ 还有前台服务类型限制。
• IntentService 已废弃:用 WorkManager 或协程替代后台任务。
• Service 不是线程:默认运行在主线程,耗时操作仍需开子线程,否则 ANR。

四、BroadcastReceiver

• 注册方式:
  • 静态注册(Manifest):适合系统或跨应用广播;Android 8.0 起对很多隐式广播做了限制,普通应用不要依赖静态注册来长期唤醒进程。
  • 动态注册(registerReceiver):跟随 Activity/Fragment/Service 生命周期,常在 onStart/onResume 注册、onStop/onPause 反注册,用于只在界面可见或组件存活时接收。
• 分发流程:sendBroadcast/sendOrderedBroadcast → ActivityManager/系统广播队列匹配 IntentFilter → 找到静态/动态 Receiver → 目标进程已在则直接回调,未启动且允许则拉起进程 → 主线程调用 onReceive。
• 类型边界:
  • 普通广播:异步分发,多个 Receiver 接收顺序不应作为业务依赖。
  • 有序广播:按优先级依次分发,前一个 Receiver 可通过 setResult* 改结果,也可在允许的场景中 abortBroadcast() 终止后续接收;因此更像一条责任链。
  • LocalBroadcastManager / 粘性广播:都已不推荐。应用内事件优先用 StateFlow/SharedFlow、回调、Lifecycle-aware observer 或明确的 Repository 状态流。

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 方法可能被跨进程并发调用,数据库访问要考虑线程安全和事务。

常见错误:

• 只记“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 控制页面生命周期。

前台 Service 类型

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

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

高频面试题

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 一个默认尺寸。

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 请求父不要拦截(滑动冲突解决用)。

三、滑动冲突解决

当内外层都能滑动(如 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 关闭。

六、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 是否参与,滚动前后分发消耗量。

典型场景:CoordinatorLayout + AppBarLayout + RecyclerView。

Choreographer 与 VSync

Choreographer 接收 VSync 信号,驱动 input、animation、traversal。60Hz 下每帧约 16.6ms,超时会掉帧。卡顿排查要看主线程是否阻塞、布局是否过重、GPU 是否过载。

RecyclerView 复用与预取

• ViewHolder 复用减少创建成本。
• DiffUtil 减少无效刷新。
• GapWorker 负责预取。
• onBindViewHolder 不做重 IO/复杂计算。

GestureDetector 与 VelocityTracker

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

**追问:**为什么 RecyclerView 滑动卡顿?常见是 bind 太重、图片加载无占位/无取消、布局层级深、频繁全量刷新。

高频面试题

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 等应在构造时创建并复用。

UI 体系 - Jetpack Compose ★

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

一、声明式 UI 思想

• 命令式(View):你持有 View 引用,手动 findViewById、setText、setVisibility 去“改“UI。
• 声明式(Compose):你描述“UI 在某状态下长什么样“,状态变了框架自动重绘。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 要无副作用、幂等、快。
  • 执行顺序不保证、可能并行。
  • 不要在 Composable 体内直接做副作用(网络、写变量),要用副作用 API。

稳定性(Stability)

• 编译器判断类型是否 @Stable/@Immutable。不稳定类型(如 List 接口、含 var 的 class)会导致无法跳过,引发不必要重组。
• 优化:用 data class + 不可变属性、kotlinx.collections.immutable 的 ImmutableList。

三、状态管理

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

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

• 状态提升(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。
• Modifier:装饰 Composable(尺寸、padding、点击、背景)。顺序敏感:padding().background() 与 background().padding() 效果不同(前者内边距区域无背景色)。Modifier 是链式不可变的。

六、三大阶段

Compose 渲染分三阶段:

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

理解阶段有助于性能优化:只改绘制层的东西(如颜色)不必触发重组——用 lambda 形式的 Modifier(如 graphicsLayer { }、drawBehind)可跳过 Composition/Layout,直接在 Draw 阶段更新。

七、与 View 互操作 & 性能

• Compose 中嵌 View:AndroidView { }。
• View 中嵌 Compose:ComposeView.setContent { }。
• 性能优化要点:
  • 用稳定类型,避免不必要重组。
  • LazyColumn 给 key 提升 diff 效率。
  • 把状态读取推迟到最小范围(defer reads),用 lambda Modifier。
  • 避免在 Composable 里做重计算(用 remember 缓存)。
  • @Stable/@Immutable 标注帮助编译器跳过。

高频面试题

Q1:Compose 和传统 View 的本质区别? View 是命令式、保留模式(retained,持有可变 View 树,手动改);Compose 是声明式、即时模式思想(描述 UI=f(state),状态变自动重组)。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:为什么会发生不必要的重组?怎么优化? 参数类型不稳定(List 接口、含 var 的类)导致无法跳过。优化:用不可变类型、@Stable/@Immutable、derivedStateOf、给 LazyColumn 加 key、defer state reads。

Q6:Compose 的三个阶段是什么? Composition(发射 UI 树)、Layout(测量摆放)、Drawing(绘制)。只影响绘制的变化可用 lambda Modifier 跳过前两阶段。

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

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

Compose 深水区

Compose 深水区考的不是“会写 Text/Button”,而是你是否理解重组、稳定性、Snapshot、Modifier、LazyColumn 性能和测试,能不能把声明式 UI 写得稳定、可测、不卡。

一、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)
    }
}

二、Stability 与 Skippable

Compose 编译器会判断参数是否稳定,稳定且参数未变化时,Composable 可以被跳过(skippable)。

怎么答:优化 Compose 性能不是“少写 Composable”,而是让状态和参数稳定,让框架能精准重组和跳过。

三、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 */ }
}

五、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)
    }
}

七、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 里用普通单元测试覆盖。

高频面试题

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

Q2：稳定性和 skippable 是什么? 如果 Composable 参数稳定且值没变,编译器/运行时可以跳过它,减少重组成本。不稳定类型如可变 class、普通 List 接口会降低跳过概率,应使用不可变 UI State 和稳定集合。

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 版本适配

★ 版本适配是考察 Android 基础扎实度和工程经验的试金石。不要死记硬背每个 API，重点讲清“为什么改”以及“线上怎么平滑过渡”。

一、Android 6.0 - 9.0 核心适配回顾

虽然年代久远，但这是现代 Android 权限和后台限制的基石：

• Android 6.0 (M): 动态权限机制（Runtime Permissions）。核心思想：敏感权限必须在用到时申请，不能全靠安装时授权。
• Android 7.0 (N): FileProvider。严禁在 Intent 中传递 file:// URI，必须使用 content://，提升跨应用文件共享的安全性。
• Android 8.0 (O):
  • 后台执行限制：应用在后台时不能随便启 Service，推荐用 JobScheduler 或 WorkManager。
  • 通知渠道（Notification Channels）：通知必须分类，把控制权交给用户。
• Android 9.0 (P): 限制 Http 明文请求（需配置 networkSecurityConfig），以及非 SDK 接口限制（深反射受限）。

二、Android 10 - 11：存储与隐私大修

这是近年来适配痛点最集中的版本，核心是分区存储与包可见性。

• Android 10 (Q):
  • Scoped Storage (分区存储)：应用默认只能访问自己的沙盒目录和公共媒体集合（MediaStore）。不能再随便遍历 /sdcard。
  • 后台定位限制：细分了前台定位和后台定位权限。
• Android 11 (R):
  • 强制分区存储：TargetSDK 30 时 requestLegacyExternalStorage 失效，必须彻底适配 MediaStore 或 SAF。
  • 包可见性 (Package Visibility)：不能再无脑 getInstalledPackages()。必须在 Manifest 中用 <queries> 声明你要交互的应用包名，防流氓应用拉取用户应用列表。

三、Android 12：用户体验与安全加固

• SplashScreen API：系统强制的闪屏规范。启动时自动接管显示 App 图标，需适配新的主题属性，否则会出现“双闪屏”。
• PendingIntent 可变性：必须显式声明 FLAG_IMMUTABLE 或 FLAG_MUTABLE，防止组件劫持。
• 精确闹钟限制：AlarmManager.setExact() 需要申请 SCHEDULE_EXACT_ALARM 权限，防止滥用唤醒系统。
• 蓝牙权限细分：分离了定位和蓝牙权限，扫蓝牙不再必须申请定位权限（需声明 neverForLocation）。

四、Android 13：细粒度权限时代

• 通知运行时权限：发通知不再是默认开启的，必须动态申请 POST_NOTIFICATIONS 权限。
• 细化的媒体权限：废弃了粗放的 READ_EXTERNAL_STORAGE，拆分为：
  • READ_MEDIA_IMAGES
  • READ_MEDIA_VIDEO
  • READ_MEDIA_AUDIO
• 照片选择器 (Photo Picker)：无需任何存储权限即可让用户选择图片，强烈建议替换掉自研的图片选择器。

五、Android 14：前台服务与后台行为收紧

• 前台服务类型强制：启动 Foreground Service 必须声明对应的类型（如 location, mediaPlayback, dataSync），且必须附带具体的原因和对应权限。
• 隐式 Intent 限制：内部组件通信必须使用显式 Intent 或指定 package，防止被外部恶意截获。
• 精确闹钟默认拒绝：TargetSDK 34 的非日历/闹钟类应用，精确闹钟权限默认关闭，需引导用户去设置页开启。

六、版本适配速查矩阵与面试策略

为了在面试中快速调取记忆，可以参考以下核心版本适配矩阵：

面试实战：版本适配的回答结构

当被问到“讲讲你做过哪些版本适配”时，用 STAR 法则 构建你的回答：

1. 情境(Situation): “在升级 TargetSDK 到 33 时…”
2. 任务(Task): “…我们遇到了图片选择和通知发送失效的问题。”
3. 行动(Action): “…我将存储权限拆分请求，并接入了官方的 Photo Picker，同时利用一套版本判断工具类统一封装了通知权限的申请逻辑。”
4. 结果(Result): “…不仅解决了崩溃，还把包体积减小了（因为移除了臃肿的第三方相册组件），并且减少了向用户索要危险权限的次数，合规性提升。”

高频面试题

Q1：你们是如何平滑过渡分区存储（Scoped Storage）的？ 答：我们分了两步走。首先在 TargetSDK 29 时通过 requestLegacyExternalStorage="true" 作为过渡方案。其次，梳理了所有文件读写场景：将应用内缓存切到 Context.getExternalFilesDir()；将需要分享给用户的图片/视频，改为通过 MediaStore API 插入；对于需要用户选择外部文件的场景，接入了 Storage Access Framework (SAF)。

Q2：Android 12 的 PendingIntent 崩溃问题怎么排查和解决？ 答：这是因为 TargetSDK 31 后未声明可变性。我们首先通过全局搜索 PendingIntent.getActivity/getBroadcast 找到所有调用点。对于只用于拉起界面的点击通知，统一加上 PendingIntent.FLAG_IMMUTABLE；对于需要回传输入结果（如 Direct Reply）的场景，使用 FLAG_MUTABLE。同时检查了第三方推送 SDK 是否已升级到兼容版本。

Q3：如何处理 Android 14 前台服务的限制？ 答：梳理业务中所有的 Foreground Service。比如定位打卡服务，在 Manifest 声明 foregroundServiceType="location"，并在启动前确保已获得前台定位权限。如果是数据同步，尽量将其迁移到 WorkManager，因为 Android 14 极度不推荐长驻的后台同步服务。

易错点 / 追问

• TargetSDK 与 CompileSDK 混淆：CompileSDK 是编译时环境，TargetSDK 是运行时的兼容模式开关。只有提升了 TargetSDK，系统才会用新的限制策略约束你。
• 第三方 SDK 拖后腿：自己业务适配了，但旧版第三方 SDK 仍用老 API 导致崩溃。追问解决方案时，可以说“推动 SDK 更新、使用 ASM 字节码插桩拦截修改、或寻找替代方案”。
• 忽略条件判断：在调用新 API 时没有包裹 if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.TIRAMISU)，导致在老机器上发生 NoSuchMethodError 崩溃。

图片加载与缓存

★ 图片是移动端内存消耗的第一大户，也是 OOM 的万恶之源。面试题通常从“怎么用 Glide”深入到“如果让你手写一个图片框架，你会怎么设计三级缓存”。

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

一张 Bitmap 占多大内存？ 公式：分辨率宽 × 分辨率高 × 每个像素占用的字节数（还要考虑放错 drawable 文件夹带来的缩放系数）。

• ARGB_8888（默认）：每个像素 4 字节。高质量，带透明度。
• RGB_565：每个像素 2 字节。无透明度，省一半内存。

注意：Android 8.0 之后，Bitmap 的像素数据移到了 Native 内存中，减少了对 JVM 堆的压力，降低了 Java 层的 OOM，但总内存占用并没变。

二、采样压缩：inSampleSize 的奥秘

加载 4K 高清图到 100x100 的 ImageView，直接加载必爆内存。必须使用 BitmapFactory.Options 进行采样压缩。

// 1. 只读取图片宽高，不将像素加载到内存
val options = BitmapFactory.Options().apply { inJustDecodeBounds = true }
BitmapFactory.decodeResource(resources, R.id.my_image, options)

// 2. 根据目标 View 尺寸计算采样率 (inSampleSize，必须是 2 的幂)
options.inSampleSize = calculateInSampleSize(options, reqWidth, reqHeight)

// 3. 关闭只读边界，真正加载图片
options.inJustDecodeBounds = false
val bitmap = BitmapFactory.decodeResource(resources, R.id.my_image, options)

三、经典三级缓存设计

1. 内存缓存 (LruCache)：速度极快，空间小。基于强引用，利用 LinkedHashMap 记录访问顺序，满时淘汰最近最少使用的图片。
2. 磁盘缓存 (DiskLruCache)：速度中等，空间大。保存下载的原始文件或转换后的图。
3. 网络获取：最慢，消耗流量。内存和磁盘都没命中时才走网络。

流程：读（内存 → 磁盘 → 网络），写（网络回来后写入磁盘和内存）。

四、Glide 的多级缓存机制剖析

Glide 的缓存比经典三级缓存更精细：

1. 活动资源 (ActiveResources)：当前正在屏幕上显示的图片。使用弱引用持有，防止 GC 时被回收导致闪烁，同时分担 LruCache 压力。
2. 内存缓存 (LruCache)：刚被移出屏幕，但可能马上要用到的图片。
3. 磁盘缓存 (DiskCache)：
   • Resource：缓存经过转换、裁剪后的图（直接拿来就能显示）。
   • Data：缓存网络下载的原始全尺寸数据。

五、列表滑动与超长图优化

• RecyclerView 滑动卡顿优化：
  • 在 onBindViewHolder 里绝对不能在主线程 decode 图片。
  • 滑动时暂停加载 (Glide.with(context).pauseRequests())，停止滑动时恢复加载。
  • 给 ImageView 固定宽高，避免多次 measure。
• 巨图加载 (长图/清明上河图)：
  • 使用 BitmapRegionDecoder 局部解码，结合手势监听，滑到哪里只加载那一部分的内存。

高频面试题

Q1：如何设计一个图片加载框架？（架构题） 答：可以拆分为四大模块：

1. 请求封装层：对外提供流式 API (如 with().load().into())，封装 Request 对象。
2. 任务调度层：管理线程池，负责将加载任务派发给 IO 线程，把结果回调到主线程。并与生命周期绑定，在 Activity 销毁时取消任务。
3. 缓存拦截层：实现 ActiveResource -> LruCache -> DiskCache -> Network 的责任链/拦截器模式。
4. 解码/变换层：负责网络流到 Bitmap 的解码，处理 inSampleSize 采样，以及圆角、模糊等 Transformation。

Q2：排查线下和线上 OOM 崩溃，你的思路是什么？ 答：线下通常通过 Android Profiler 监控内存，或者集成 LeakCanary，当触发 dump 后，通过 MAT 或 Shark 分析堆栈，找出是哪个组件持有大对象。 线上 OOM 通常缺乏具体堆栈。我们会分析 APM 收集的机型和发生页面，重点排查该页面的大图加载是否有采样压缩、列表图片是否使用了 ARGB_8888、是否有未关闭的动画或大 Bitmap 引用泄露。可以上报 OOM 时的内存使用统计，辅助定位。

Q3：Glide 的生命周期管理是怎么做的？为什么 Activity 销毁时它能停止加载？ 答：Glide 通过向当前传入的 Context（Activity/Fragment）偷偷注入一个无 UI 的隐藏 Fragment。因为系统会回调这个 Fragment 的生命周期方法，Glide 借此感知到了宿主的 onStart、onStop、onDestroy，从而自动暂停、恢复或取消图片加载任务，防止内存泄漏和无效流量浪费。

易错点 / 追问

• 混淆 drawable 文件夹的缩放规则：把大图放在 drawable-mdpi，在高密度屏幕手机上加载时，系统为了保持物理尺寸一致，会对其进行放大采样，导致内存成倍暴增。图片应该尽量提供 xxhdpi，或者放在 drawable-nodpi 中。
• 误解 LruCache 的原理：追问 LruCache 底层数据结构时，必须答出是 LinkedHashMap 并且开启了 accessOrder=true 模式，每次 get 或 put 都会把元素移到双向链表尾部。
• 忽略 Bitmap 回收机制：虽然 Bitmap 数据在 Native，但 Java 层的 wrapper 对象仍靠 GC。追问优化时可以提 inBitmap 属性，即复用已分配的旧 Bitmap 内存块来加载新图片，避免频繁申请和销毁内存。

Jetpack 架构组件 ★

你的重点短板。 Jetpack 是应用开发日常,中级面试必问 ViewModel/LiveData/Room/Hilt 原理。

一、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) { } }。

三、LiveData

• 生命周期感知的可观察数据持有者:只在活跃状态(STARTED/RESUMED)通知观察者,组件销毁自动移除观察,避免泄漏和崩溃。
• setValue(主线程)/ postValue(任意线程)。
• 粘性问题:新观察者会立即收到最新值,用于“事件“场景会重复触发(用 SingleLiveEvent/Flow 替代)。
• MediatorLiveData:合并多个源。
• 现代趋势:新项目用 StateFlow/SharedFlow 替代,但老项目仍大量使用,必须懂。

四、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)
        }
    }
}

常见错误:

• 在多个页面散落手写跳转字符串,导致参数名/route 不一致;可用常量、封装 route builder 或 Safe Args 降低风险。
• 登录、首页、详情都压入同一栈后不清理,返回路径混乱;需要明确 popUpTo 和 inclusive。
• 把导航事件放进持久 State,旋转后重复 navigate;一次性导航应使用 Effect/SharedFlow。
• 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 实现)、统一管理对象创建。

七、DataStore / WorkManager / Paging

• DataStore:替代 SharedPreferences。基于协程 + Flow,异步、事务安全、无 ANR 风险。两种:Preferences DataStore(键值)、Proto DataStore(类型安全)。SP 的问题:同步 apply 仍可能阻塞、getXXX 可能主线程 IO、无类型安全。
• WorkManager:可延迟、保证执行的后台任务(即使 App 退出/重启)。支持约束(网络、充电)、链式、周期任务。底层根据系统版本选 JobScheduler/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 的粘性事件问题是什么?怎么解决? 新观察者注册时会立即收到最新值,对“一次性事件“(导航/Toast)会重复触发。解决:SingleLiveEvent、事件包装类、或改用 SharedFlow(replay=0)。

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 读,实现离线缓存和单一数据源。

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

Hilt 组件层级与作用域

常见层级:SingletonComponent → ActivityRetainedComponent → ViewModelComponent → 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。

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

应用架构 - MVVM 与 MVI ★

你的重点短板,中级必考。 面试常问“你项目用什么架构?为什么?“,要答得出演进逻辑和取舍。

一、架构演进

核心趋势:职责分离 → 解耦 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 就是来解决这个的。

三、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 / SideEffect:一次性事件(导航、Toast),用 Channel/SharedFlow 表达(不放进 State,避免重放)。

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。

高频面试题

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? State 是持久状态,旋转重建后会重新渲染,若把事件放进 State 会重复触发(重复弹 Toast/重复导航)。应用 Channel/SharedFlow(replay=0)表达一次性 Effect。

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

进阶补充:端到端架构、MVI 状态机与 Offline-first

推荐端到端分层

ui(Screen/Fragment/Composable)
  -> ViewModel(State/Effect)
  -> UseCase(业务规则)
  -> Repository(数据协调)
  -> Local/Remote DataSource(Room/Retrofit)

依赖方向只能向内/向下的抽象走,UI 不直接依赖 Retrofit/Room。

MVI Reducer

MVI 的核心是事件驱动状态变化:

data class LoginState(val loading: Boolean = false, val error: String? = null)

fun reduce(state: LoginState, event: LoginEvent): LoginState = when (event) {
    LoginEvent.Submit -> state.copy(loading = true, error = null)
    is LoginEvent.Failed -> state.copy(loading = false, error = event.message)
}

一次性 Effect

Toast、导航、弹窗不适合放进持久 State,通常用 Effect/Channel/SharedFlow 处理。

Offline-first

离线优先通常以本地数据库为 single source of truth,网络同步更新本地,UI 观察本地。难点是冲突解决、同步状态、失败重试。

何时 MVVM 足够,何时 MVI 过重

简单表单/详情页 MVVM 足够;复杂交互、多状态、多事件流页面适合 MVI。不要为了追新把所有页面都写成复杂 reducer。

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

App 架构落地案例

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

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

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

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

核心原则:

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

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

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

data class ProductListState(
    val isLoading: Boolean = false,
    val isRefreshing: Boolean = false,
    val items: List<ProductUi> = emptyList(),
    val error: UiError? = null,
    val hasMore: Boolean = true,
) {
    val isEmpty: Boolean get() = !isLoading && items.isEmpty() && error == null
}

三、一次性 Effect: Toast、导航、弹窗

一次性事件不要放进持久 State,否则配置变更或重新收集可能重复触发。常见做法是 Channel 或 MutableSharedFlow(replay = 0)。

• State:页面长期状态,旋转后重新渲染也合理。
• Effect:一次性动作,如 Toast、导航、打开弹窗、提交成功返回。
• Intent/Action:用户输入,如刷新、点击、提交、加载更多。

怎么答:ViewModel 处理 Intent 后同时可能产出新 State 和一次 Effect;UI 分别 collectAsStateWithLifecycle() 渲染 State,用 LaunchedEffect 收集 Effect。

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

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

1. Refresh:重置页码/游标,请求第一页,成功后替换列表。
2. LoadMore:使用下一页 key,成功后 append,失败时保留旧列表并显示底部错误。
3. 去重:按业务 ID 去重,避免刷新和加载更多交叉导致重复。
4. 并发控制:同一时间只允许一个分页请求,或用 collectLatest 取消旧请求。

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

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

• 本地校验:手机号、验证码、必填项在提交前快速反馈。
• 提交中状态:submitting=true 禁用按钮,防重复点击。
• 服务端错误:映射成字段错误或页面错误,不要直接把接口文案散落到 UI。
• 幂等:订单/支付/注册类提交要有 requestId 或服务端幂等键。
• 成功 Effect:提交成功通常是导航/Toast,用 Effect 发出。

怎么排查重复提交:看按钮是否禁用、ViewModel 是否丢弃 submitting 期间的新 Intent、接口是否具备幂等键。

六、Offline-first 与离线缓存

离线优先不是“网络失败读缓存”这么简单,更推荐本地数据库作为 Single Source of Truth:

UI 观察 Room Flow
Repository 触发网络刷新
Remote 成功 -> 写入 Room
Room 变化 -> UI 自动更新
Remote 失败 -> UI 保留本地数据 + Effect 提示

优点:页面旋转、进程重建、短暂断网都能稳定展示;Repository 统一控制刷新策略、过期时间、同步状态。难点是冲突解决、脏数据标记、失败重试和缓存淘汰。

七、多源数据合并

真实页面经常需要合并用户信息、配置、列表、埋点开关、缓存状态。Repository/UseCase 可以用 Flow 组合多源:

• combine:多个数据源任一变化都重新产出 UI 模型。
• flatMapLatest:筛选条件变化时取消旧查询。
• zip:严格一一配对,业务上较少用于 UI 持续状态。
• 本地 + 远端:本地先出首屏,远端刷新后写库再更新。

八、落地检查清单

一个页面架构是否靠谱,可以按这张表自查:

高频面试题

Q1：请讲一个页面从 UI 到数据层的完整链路。 UI 负责渲染 State 和发送 Intent;ViewModel 接收 Intent,维护 UiState/Effect;UseCase 封装业务规则;Repository 决定网络、本地缓存和多源合并;DataSource 只负责具体 Retrofit/Room/DataStore 操作。依赖方向单向,上层不直接感知底层实现。

Q2：loading、error、empty 怎么统一管理? 用一个不可变 UiState 表达完整页面,例如 isLoading/items/error/hasMore。首屏错误显示全屏错误;刷新失败保留旧数据并发 Effect;请求成功但列表为空显示 empty,避免多个 Boolean 分散导致状态互相矛盾。

Q3：Toast/导航为什么不放进 State? State 是持久状态,配置变更或重新收集会再次渲染。如果把 Toast/导航放进 State,可能重复弹出或重复跳转。一次性动作应放 Effect,用 Channel 或 SharedFlow(replay=0) 发送。

Q4：分页加载更多失败时怎么处理? 不要清空已有列表。保留 items,记录底部错误或发一次 Effect,允许用户重试当前 pageKey;同时用 hasMore/loadingMore 防止重复触发并发请求。

Q5：Offline-first 怎么落地? 以 Room 作为 Single Source of Truth,UI 观察本地 Flow;Repository 触发网络刷新,成功后写入 Room,UI 因数据库变化自动更新;失败时保留本地数据并提示。难点是冲突、过期策略和失败重试。

易错点 / 追问

• 不要让 UI 直接依赖 Retrofit/Room,否则页面难测、数据策略分散。
• 不要把一次性事件塞进 UiState,旋转屏幕或重新订阅会重复消费。
• 分页失败要区分首屏失败和加载更多失败,后者不能清空已有内容。
• UseCase 不是越多越好;简单 CRUD 可省略,复杂业务规则/复用逻辑再引入。
• Offline-first 的核心是本地单一数据源,不是简单“catch 网络异常后读缓存”。

测试体系

★ 测试体系是中级 Android 面试的短板高频区。能讲清“怎么测“,比只会说 MVVM/MVI 更能证明工程能力。

一、测试金字塔与 Android 测试分层

原则:越靠下越多、越快、越稳定;越靠上越少、越接近真实用户。

二、单元测试:Junit、断言与 Mock

• JUnit 负责组织测试生命周期。
• Truth/AssertJ 让断言可读。
• MockK/Mockito 用于隔离外部依赖,但不要 mock 一切。

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 层。

六、可测试性如何反推架构质量

如果一个 ViewModel 很难测,通常说明它持有太多 Android 依赖、业务逻辑没有下沉、状态/副作用没有分离。

高频面试题

Q1:你项目里怎么做测试分层? 答:核心业务规则放单元测试,ViewModel/Repository 做集成测试,关键用户路径做 UI 测试。比例上单元测试最多,UI 测试最少。

Q2:为什么 Repository 不应该直接测 Retrofit/Room? 答:Retrofit/Room 是框架能力,业务测试应关注 Repository 的缓存、错误兜底、数据源切换。框架集成可少量用 integration test 验证。

Q3:协程测试为什么不用真实 delay? 答:真实 delay 会让测试慢且不稳定;runTest 用虚拟时间推进,可稳定验证超时、重试、debounce 等逻辑。

易错点 / 追问

• 不要为了覆盖率 mock 所有东西,那会测到实现细节。
• UI 测试不要依赖真实网络和随机数据。
• Compose 测试要给关键节点加稳定语义,否则 matcher 容易脆弱。

组件化路由与模块通信

组件化不是把包拆成很多 module,而是让业务边界、依赖方向和发布协作更清晰。中高级面试常追问路由、通信和依赖治理。

一、组件化解决什么问题

二、模块拆分方式

• app 壳工程:组装入口。
• feature module:业务功能。
• core/common:基础能力。
• api/contract:跨模块接口。

依赖方向应从上层依赖抽象,避免 feature 之间直接互相依赖。

三、路由框架原理(以 ARouter 类框架理解)

核心流程:编译期扫描注解 → APT/KSP 生成路由表 → 运行时按 path 查找目标 → 拦截器处理登录/权限/降级 → 跳转或返回服务实例。

interface UserService {
    fun currentUserId(): String?
}

跨模块不要直接调用实现类,而是依赖 UserService 这样的 contract。

四、模块通信方式

五、路由拦截、降级与灰度

登录校验、权限校验、A/B 实验、页面不存在降级都适合放在拦截器链里。路由失败必须有兜底,不能直接 crash。

六、和 Gradle 工程化的关系

组件化设计关注业务边界;Gradle 工程化关注构建配置、依赖版本、产物和性能。两者相关但不是一回事。

高频面试题

Q1:组件化和模块化区别? 答:模块化偏代码物理拆分,组件化更强调业务组件独立开发、独立测试、按契约通信和可组装。

Q2:ARouter 这类框架大概怎么实现? 答:编译期注解处理生成路由表,运行时初始化加载,按 path 找目标 class/provider,再通过拦截器处理统一逻辑。

Q3:跨模块通信为什么不直接依赖实现? 答:直接依赖会导致 feature 耦合、编译依赖变重、循环依赖风险;接口下沉能保持依赖方向稳定。

易错点 / 追问

• 不要为了组件化制造过多小 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。

为什么主线程死循环不卡死/不 ANR? loop() 是死循环,但无消息时阻塞在 epoll_wait 让出 CPU,有事件(触摸、绘制)再唤醒。ANR 是消息处理太久,不是循环本身。

进阶:

• 同步屏障(Sync Barrier):插入屏障后,同步消息被拦截,优先处理异步消息(如 UI 绘制 doFrame),保证及时刷新。
• IdleHandler:队列空闲时回调,可做延迟初始化(不阻塞关键路径)。

二、Binder 机制

Android 跨进程通信(IPC)的核心,理解它能体现你的底层深度。

• 为什么用 Binder 而非传统 IPC? 性能:常见说法是一次拷贝(传统管道/socket 通常需要用户态/内核态多次拷贝)。安全:内核知道调用方 UID/PID,服务端可做权限校验。
• 一次拷贝原理(实现层面直觉):Binder 驱动为进程维护映射区,传输时把发送方 Parcel 数据拷贝到驱动管理的 binder_buffer;接收进程可通过映射区读取,从而少一次“内核缓冲区 → 接收方用户空间”的显式拷贝。不同 Android 版本的驱动细节可能调整,面试回答用“当前主流实现/实现层面”表述更稳。
• 结构:Client、Server、ServiceManager(类似 DNS,管理服务注册查找)、Binder 驱动(/dev/binder,核心)。
• 代理模式:Client 拿到的是 BinderProxy,调用经驱动转发到 Server 的 Binder 实体。AIDL 自动生成这套 Stub/Proxy 代码。

一次 Binder 调用怎么走

1. Client 调用 AIDL 生成的 Proxy 方法,把参数写入 Parcel。
2. transact() 进入 Binder 驱动,驱动根据 handle 找到目标 Binder 实体和目标进程。
3. 目标进程的 Binder 线程池取到事务,回调 Stub 的 onTransact() 反序列化参数并执行服务端方法。
4. 同步调用会把返回值写回 reply Parcel,Client 线程在结果返回前阻塞;oneway 调用不等待业务返回,但仍受队列和线程调度影响。

三、应用启动流程

点击图标到界面显示的大致链路:

1. Launcher 捕获点击,通过 Binder 调用系统服务请求启动 Activity。Android 10 之后 Activity 启动职责更多落在 ATMS(ActivityTaskManagerService),但面试可把 AMS/ATMS 作为同一条系统调度链讲清楚。
2. 系统检查目标进程是否存在,不存在则经 Zygote 连接发送 fork 命令;历史和实现细节里常见 socket/zygote command 描述,不要把具体通信细节当公开 API 契约。
3. Zygote fork 出应用进程,子进程执行 ActivityThread.main(),创建主线程 Looper。
4. 新进程通过 Binder 向系统 attachApplication,系统再回调创建 Application 和目标 Activity。
5. 执行 Application.onCreate → Activity.onCreate → onResume,ViewRootImpl 触发首帧绘制。

Zygote:所有应用进程的“母体“,预加载了核心类和资源,fork 时通过 COW(写时复制)共享,加速启动、省内存。

冷启动拆解与可优化点

回答启动流程时要区分公开生命周期和系统实现细节:对业务开发者稳定的是 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 改动运行时内部结构,要用设备矩阵验证,不要承诺“所有版本通用”。
• 热修复适合止血,根因仍要通过正常发版修复;插件化适合业务动态化,不应绕过系统权限和安装模型。

五、进程间通信方式对比

高频面试题

Q1:主线程 Looper 死循环为什么不会卡死 App? loop() 是死循环,但 MessageQueue 无消息时通过 epoll 阻塞,让出 CPU 不占用资源;有消息(触摸/绘制等)再唤醒处理。ANR 是单条消息处理太久,不是循环本身导致。

Q2:Handler 内存泄漏怎么产生?如何避免? 非静态内部类 Handler 隐式持有外部 Activity,若有延迟消息未处理,Activity 无法回收。解决:静态内部类 + 弱引用,或在 onDestroy 中 removeCallbacksAndMessages(null)。

Q3:Binder 为什么只需一次拷贝? 实现层面可理解为 Binder 驱动维护映射区和 binder_buffer,发送方 Parcel 数据拷贝到驱动缓冲后,接收方通过映射区读取,省去一次显式拷贝。它不是零拷贝,且事务缓冲有大小限制,大数据要走共享内存/文件描述符等方案。

Q4:为什么用 Binder 而不是传统 IPC? 性能:一次拷贝优于管道/socket 的两次。安全:内核自动附带可靠的 UID/PID,支持身份鉴权,传统 IPC 需自行在数据层鉴权。

Q5:Zygote 的作用?为什么用 fork? Zygote 预加载核心类库和资源,作为所有应用进程的母体。fork 通过写时复制共享已加载内容,加速进程创建、减少内存占用(避免每个进程重复加载framework)。

Q6:热修复的基本原理? 利用类加载机制,把补丁 dex 插入 ClassLoader 的 dexElements 数组前面,使补丁类优先于有 bug 的旧类被加载。属于“类加载方案”,通常需要重启或确保旧类尚未加载;另有 native 方法替换方案,但强依赖 ART 内部结构,兼容风险更高。

Q7:ThreadLocal 在 Looper 里起什么作用? 保证一个线程只有一个 Looper。Looper.prepare 把 Looper 存入 ThreadLocal,各线程独立互不干扰,getMainLooper 拿主线程的。

Binder 与 IPC 深入

Binder 是 Android 系统面试里最能拉开层次的题:不要只背“一次拷贝”,要能把 mmap、ServiceManager、AIDL、线程池和大数据边界讲成一条工程链路。

一、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()。

三、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

七、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 接口时,按下面清单回答会更像工程落地:

高频面试题

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 是并发共享的。

易错点 / 追问

• 把 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 常驻后台。

三、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
    }
}

六、死锁与线程安全排查

死锁通常满足互斥、持有并等待、不可抢占、循环等待。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. 线程池设置有界队列、命名线程、异常日志和拒绝策略。

高频面试题

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 对体积/性能极度敏感,你的经验比一般应用开发者更有说服力。

一、启动优化

启动分类:

• 冷启动:进程不存在,需创建进程 + Application + Activity,最慢。
• 温启动:进程在但 Activity 重建。
• 热启动:Activity 还在,仅恢复,最快。

冷启动耗时点 + 优化:

• Application.onCreate 过重:第三方 SDK 初始化阻塞。优化:异步初始化、延迟初始化、按需初始化(用 Jetpack App Startup 统一管理依赖顺序)。
• 闪屏页(Splash):用 Android 12+ SplashScreen API,避免白屏/黑屏。
• 主线程 IO:首屏不读大文件/SP。
• 测量:adb shell am start -W 看 TotalTime;Perfetto/Systrace 看主线程占用。
• 进阶:类预加载、ContentProvider 初始化收敛(很多 SDK 用 ContentProvider 自启,拖慢启动)。

二、内存优化

内存泄漏(常见场景)

• 非静态内部类/匿名类持有外部 Activity(Handler、Runnable、监听器)。
• 静态变量持有 Context/View。
• 单例持有 Activity Context(应用 Application Context)。
• 未注销监听器/广播/观察者。
• 资源未关闭(Cursor、Stream、Bitmap)。

LeakCanary 原理(以 LeakCanary 2.x 思路理解):默认会 watch Activity、Fragment、Fragment View、ViewModel 等应被回收的对象。对象销毁后交给 ObjectWatcher,内部用弱引用和引用队列观察;延迟一小段时间后触发/等待 GC,若对象仍未被回收,就认为是 retained object。达到阈值后 dump HPROF,再由 Shark 分析 GC Roots 到泄漏对象的最短强引用链。

内存抖动

短时间大量创建小对象(如 onDraw / 循环里 new),频繁 GC 导致卡顿。优化:对象复用、避免在高频路径分配、用对象池。

三、卡顿与 ANR

掉帧原理

屏幕 60fps → 每帧 16.6ms 内必须完成 measure/layout/draw。超时就丢帧(jank)。Choreographer 接收 VSync 信号驱动每帧渲染,可监控帧耗时。

卡顿优化

• 布局优化:减少层级(ConstraintLayout 扁平化)、<merge>/<ViewStub>、避免过度绘制(overdraw)。
• 主线程不做耗时(IO、解析、复杂计算),用协程切后台。
• RecyclerView:复用、DiffUtil、避免在 onBindViewHolder 做重活、预取。

ANR(Application Not Responding)

触发条件:

• 主线程阻塞:常见记忆口径是 Input 事件约 5s 未响应、前台 BroadcastReceiver 约 10s、后台广播约 60s、前台 Service 约 20s、后台 Service 约 200s。但这些阈值会受 Android 版本、前后台状态、组件类型和厂商策略影响,面试要说“常见阈值/典型场景”,不要当成所有版本的硬契约。 定位:
• /data/anr/traces.txt 看主线程堆栈。
• 看是否主线程 IO、锁等待、Binder 阻塞、死锁。
• 工具:ANR-WatchDog、线上监控(主线程卡顿监控)。

卡顿/ANR 排查链路

四、包体积优化

• 代码:R8/ProGuard 混淆 + 裁剪无用代码(shrinkResources)。
• 资源:无用资源删除、图片用 WebP、矢量图、资源混淆(AndResGuard)。
• so 库:按 ABI 拆分(abiFilters 通常只留 arm64-v8a)、动态下发。这是你的强项——SDK 开发对 so 体积敏感。
• dex:移除未用依赖、避免方法数膨胀。
• App Bundle(aab):按设备下发,Google Play 强制。

五、工具链

• Android Studio Profiler:适合开发期快速看 CPU / Memory / Network / Energy。证据是方法耗时、分配热点、网络请求时间线;局限是插桩/采样会有开销,线上问题要结合 trace/埋点。
• Memory Profiler:看 Java/Kotlin 堆、对象数量、分配调用栈、dump HPROF。用于“内存上涨/频繁 GC/疑似泄漏”,修复后要对比同一路径的实例数量是否回落。
• Perfetto / Systrace:系统级 trace,看 main thread、RenderThread、Binder、锁、调度、Frame Timeline。Perfetto 是现代首选;Systrace 常用于老项目/旧资料口径。证据是具体 slice 和线程状态,不是“感觉变流畅”。
• LeakCanary:自动发现 retained objects 并给出引用链。适合 debug/内测定位泄漏;不要在生产默认开启 heap dump。
• Layout Inspector:看视图层级、约束、重叠与 Compose/View 混合结构。适合布局层级深、过度绘制、首屏 inflate 慢的问题。
• StrictMode:开发期检测主线程磁盘/网络、资源未关闭等。适合把“偶发卡顿”提前暴露;惩罚策略可从 log 开始,不要在生产随意 crash 用户。

工具选择速答表

高频面试题

Q1:冷启动优化有哪些手段? 异步/延迟/按需初始化 SDK、收敛 ContentProvider 自启动、避免主线程 IO、用 SplashScreen API、类与资源预加载。用 am start -W 和 Perfetto 量化。

Q2:内存泄漏常见场景?LeakCanary 怎么检测的? 非静态内部类/Handler 持 Activity、单例持 Context、未注销监听、资源未关。LeakCanary 2.x 可理解为 ObjectWatcher 监听销毁对象,用弱引用+引用队列观察是否回收;延迟和 GC 后仍 retained,再 dump HPROF 并用 Shark 分析引用链。结论要结合生命周期,不要把所有 retained 都当业务泄漏。

Q3:为什么 16.6ms 是关键?掉帧怎么排查? 60fps 下每帧预算 16.6ms,超时丢帧。用 Choreographer 监控帧耗时,Profiler/Perfetto 看主线程哪段超时,优化布局层级和主线程耗时操作。

Q4:ANR 触发条件?怎么定位? 主线程阻塞超阈值会触发 ANR,常见口径是输入约 5s、前台广播约 10s、前台 Service 约 20s,后台场景通常更长,但具体阈值和触发条件随版本/前后台/厂商策略变化。定位看 ANR traces 主线程堆栈,结合锁 owner、Binder 对端、CPU/IO 状态,排查主线程 IO、锁竞争、死锁、同步 Binder。

Q5:包体积优化怎么做?(你的强项,展开答) R8 裁剪混淆、资源压缩、WebP/矢量图、so 按 ABI 拆分(只留 arm64-v8a)+ 动态下发、移除无用依赖、用 App Bundle 按需下发。结合 SDK 经验讲 so 瘦身和符号裁剪更有说服力。

Q6:RecyclerView 卡顿如何优化? DiffUtil 局部刷新、onBindViewHolder 不做耗时、setHasFixedSize、预取(prefetch)、图片异步加载、减少 item 布局层级、复用 ViewHolder。

Q7:Serializable 和 Parcelable 哪个对性能更好,为什么? Parcelable。Serializable 用反射、产生大量临时对象触发 GC;Parcelable 专为内存/IPC 设计,无反射,速度快约一个数量级。

启动优化专项

启动速度是用户对 App 的第一印象。作为 SDK 开发者，你需要知道如何做到既不拖累宿主，又能精准测量性能瓶颈。

一、启动分类与指标

启动可划分为三种典型场景，各自的耗时与指标不同：

• 冷启动(Cold Start)：最慢。系统为 App 创建进程 -> 实例化 Application -> 实例化首个 Activity -> 渲染第一帧。
• 温启动(Warm Start)：较快。App 进程存在，但 Activity 被回收需重新创建，或者用户从退出后返回重新将后台转前台并重建视图。
• 热启动(Hot Start)：最快。App 进程和 Activity 都在后台，仅将后台应用切到前台。

关键监控指标：

• 首帧时间 (TTID)：首个可见 Activity 的第一帧渲染完成的时间。
• 可交互时间 (TTFI)：主线程空闲，用户可以开始操作界面的时间。

二、Application 初始化治理

很多冷启动问题源头是 Application.onCreate 堆积了过多第三方 SDK 的初始化操作。

延迟与异步初始化

并非所有 SDK 都必须在 Application.onCreate 主线程同步初始化：

• 异步初始化：网络库、日志库等可在子线程初始化。
• 延迟/按需初始化：地图、分享等 SDK，等用户真正点击进入相关页面前再初始化。

Jetpack App Startup

用来管理库初始化的官方方案：

• 原理：利用一个统一的 ContentProvider 集中分发和按序初始化各组件。
• 优势：减少多个第三方 SDK 各自带 ContentProvider 自启带来的性能损耗（每个 Provider 的创建和调用都有 IPC 与生命周期开销）。

三、ContentProvider 自动初始化陷阱

很多 SDK（如早期的 Firebase、WorkManager 等）为了对开发者透明，悄悄在库内声明 ContentProvider。

• 问题：系统启动应用时，会先实例化所有声明的 Provider，再调 Application.onCreate。过多 Provider 会严重拖慢启动。
• 解法：通过 tools:node="remove" 在 manifest 中剔除不需要自启的 Provider，转为手动在适当的时机初始化。

四、排查路径与流程（本地 vs 线上）

本地诊断与线上监控是有本质区别的：

定位流程：

1. 定量分析：本地通过 adb shell am start -W 包名/Activity 获取 ThisTime 和 TotalTime，或线上看 APM 启动耗时分位数。
2. 抓取 Trace：使用 Perfetto 抓取启动阶段的 trace 文件。
3. 分析主线程 (Main Thread)：在 Perfetto 中查看主线程的 slice，寻找导致阻塞的长任务（如文件 IO Open / Read、锁等待、长计算等）。
4. 改造与验证：针对长任务进行异步、懒加载改造，再用 Macrobenchmark（避免 JIT 与系统状态差异）进行 A/B 对比测试。

五、SplashScreen API (Android 12+)

Android 12 引入了标准的 SplashScreen API，应用冷/温启动时系统会自动显示闪屏。

• 优势：规范了启动体验，消除了应用自己实现闪屏页带来的白屏/黑屏，且首帧可立即进入业务 Activity，减少中间 Activity 跳转耗时。
• 适配：通过配置主题属性（如 windowSplashScreenBackground、windowSplashScreenAnimatedIcon）修改系统闪屏样式，或使用 androidx.core:core-splashscreen 兼容低版本。

高频面试题

Q1: 冷启动的整个系统流程是怎样的？ 从点击桌面图标 -> Launcher 通过 Binder 通知 AMS -> AMS 创建进程请求 -> Zygote fork 进程 -> ActivityThread.main -> 实例化 Application -> 实例化 Activity -> setContentView -> 渲染完成第一帧。

Q2: 为什么有些第三方 SDK 接入后会拖慢冷启动，即使用户还没调用它？ 可能是 SDK 内部通过 ContentProvider 实现了自动初始化。系统在进程创建后、调用 Application.onCreate 之前，会先实例化并调用所有注册 Provider 的 onCreate，若里面有耗时操作或 IO，就会阻塞启动。

Q3: 如何用工具定位启动慢的具体代码行？ 使用 Perfetto 或 Android Studio CPU Profiler (Call Chart/Flame Chart) 录制启动阶段。如果是代码插桩模式能看到具体方法耗时，如果是 System Trace 模式，重点看 Main Thread 上的长耗时 Slice 和线程状态（Blocked/Runnable 等）。

易错点 / 追问

• 易错点： 把异步初始化当万能药。如果首屏 UI 恰好强依赖某个被异步到子线程初始化的数据/SDK，会导致数据还没准备好 UI 已经展示，或产生竞态崩溃。
• 追问： 如果启动优化已经把能异步的都异步了，还能怎么优化？（答：类预加载、资源预加载、减少首屏布局层级/延迟加载非首屏 Fragment、甚至更底层的 PGO 等技术）。
• 误区： 线上监控直接使用 System.currentTimeMillis() 算差值。线上容易受到系统休眠、时间跳变影响，建议用 SystemClock.uptimeMillis()。

内存优化与泄漏排查

内存问题直接影响 App 的存活率（OOM）和流畅度（频繁 GC 导致卡顿）。对于底层背景开发者，native 内存泄漏排查会是很好的加分项。

一、常见的内存泄漏场景

内存泄漏（Memory Leak）的本质是：长生命周期的对象（如单例、静态变量、系统级线程）持有了短生命周期对象（如 Activity/Fragment）的强引用，导致短生命周期对象无法被 GC 回收。

Java / Kotlin 泄漏重灾区

1. 静态变量 / 单例：静态变量持有 Activity 的 Context 或 View 实例。
2. 非静态内部类 / 匿名类：如 Handler 延时消息未移除、Runnable 在子线程还在跑，它们隐式持有外部类的引用。
3. 未注销监听器：广播接收器 BroadcastReceiver、EventBus 等未在 onDestroy 注销。
4. 协程 / Flow：未跟随组件生命周期（如在 Activity onDestroy 后协程仍在运行），或全局 ViewModel 持有了 UI 元素。
5. 资源未关闭：Cursor、Stream、FileDescriptor 没有 close，或者 Bitmap 未及时 recycle。

二、内存抖动与 GC 机制

• 内存抖动 (Memory Churn)：短时间内频繁创建大量临时小对象（如在 onDraw 或大循环内 new 对象），导致可用内存迅速耗尽，触发频繁 GC。
• 影响：Dalvik/ART 的 GC 过程可能会产生应用停顿（Stop-The-World，尽管 ART 有并发 GC，但仍有停顿和 CPU 开销），从而引发界面卡顿甚至掉帧。
• 优化：使用对象池复用对象，避免在高频调用的路径（如 UI 渲染）中进行堆分配。

三、Bitmap 与 Native 内存

现代 Android (8.0+) 的 Bitmap 像素数据存放于 Native 内存中，这大大缓解了 Java 堆 OOM 的压力，但也带来了 Native 泄漏的风险。

• Native OOM：当系统总可用物理内存不足或虚拟地址空间耗尽时，Native 层同样会发生分配失败（OOM）。
• 排查手段：Native 内存的追踪较难，可以通过 malloc_debug 或 HWASan/ASan 等底层工具进行内存越界和泄漏排查。

四、排查路径与流程（本地 vs 线上）

诊断策略需区分开发期和生产环境：

泄漏排查流程：

1. 现象发现：观察到应用内存占用持续走高或收到 OOM 奔溃报告。
2. 触发 Dump：在开发阶段，利用 Memory Profiler 点击强制 GC 并抓取 Java Heap (hprof)。LeakCanary 会在后台对象保留超时后自动 dump。
3. 寻找 GC Roots：将 hprof 导入 Memory Profiler 或 MAT (Memory Analyzer Tool)。寻找怀疑泄漏的对象实例（如 MainActivity）。
4. 分析引用链 (Reference Chain)：查看从 GC Root 到该泄漏实例的最短强引用路径。
5. 切断引用：修改代码，将该路径上的长生命周期引用置为 null、改用弱引用 (WeakReference)，或在合适的生命周期节点手动解绑。

五、LeakCanary 原理剖析

LeakCanary 是如何自动发现泄漏的？

1. Hook 生命周期：自动注册 Application.ActivityLifecycleCallbacks（或利用 Fragment/ViewModel 钩子）监听对象销毁。
2. 弱引用观察：对象销毁后，用它构建一个带有 ReferenceQueue 的弱引用，交由 ObjectWatcher 观察，并标记个超时时间（如 5s）。
3. 判断回收：超时后强制触发一次 GC，如果该弱引用没有出现在 ReferenceQueue 中，说明对象还被强引用，标记为 retained。
4. 抓取分析：若 retained 对象数达阈值，dump 整个 hprof 文件，交由内嵌的 Shark 库解析 hprof，找出最短强引用链并发送通知。

高频面试题

Q1: 内部类一定会导致内存泄漏吗？ 不一定。只有非静态内部类才会隐式持有外部类的引用。且只有当内部类的生命周期长于外部类时（比如被 static 变量引用，或跑在一个没结束的子线程里），才会造成外部类无法释放，形成泄漏。静态内部类不持有外部类引用。

Q2: Handler 导致的内存泄漏怎么解决？ 将 Handler 声明为静态内部类，内部通过 WeakReference<Activity> 持有 Activity 以便更新 UI。更关键的是，在 Activity onDestroy 中调用 handler.removeCallbacksAndMessages(null) 清除所有未执行的消息和任务。

Q3: Android 8.0 之后 Bitmap 内存存在哪里？如果 OOM 了怎么排查？ 存放于 Native 内存中。Java 层面的 OOM (OutOfMemoryError) 和 Native 内存溢出不同。排查时可以抓取 hprof，看是不是应用中有大量的 Bitmap 引用没有被回收。线上可以用 KOOM 等库，利用 fork 子进程的方式 dump 内存，减少对主进程的影响。

易错点 / 追问

• 误区： “使用弱引用可以解决所有内存泄漏”。很多时候泄漏是因为生命周期管理错乱，比如网络请求没取消导致回调还在等。粗暴地改成弱引用可能掩盖逻辑漏洞（回调突然没反应了）。正确的做法是绑定生命周期及时取消任务。
• 追问： LeakCanary 会影响生产环境的性能吗？（答：会，抓取 hprof 时进程会发生长达数秒的冻结，且分析过程耗 CPU 和内存，所以通常只在 debug 环境或灰度阶段启用。）
• 易错点： 分析 MAT 时死盯所有引用链。只需关注强引用 (Strong Reference)，软/弱/虚引用不会阻止对象被垃圾回收。

ANR 与卡顿排查

ANR (Application Not Responding) 和卡顿 (Jank) 是导致用户流失的直接原因。作为中高级开发者，仅仅知道 ANR 的触发时间是不够的，必须具备看懂 traces.txt 和系统调度的能力。

一、ANR 的本质与类型

ANR 的触发条件往往被记忆为几个固定阈值（如输入事件 5s），但底层本质是：主线程无法在系统规定的时间预算内，响应系统派发的特定事件或完成相应的生命周期调度。

常见的 ANR 类型：

• KeyDispatchTimeout：输入事件（点击/触摸）超过 5 秒无响应。
• BroadcastTimeout：前台广播 10 秒，后台广播 60 秒未执行完毕。
• ServiceTimeout：前台 Service 20 秒，后台 Service 200 秒未启动/绑定完成。
• ContentProvider：publish 超时（通常为 10 秒）。

二、ANR / 卡顿的核心诱因

ANR 和卡顿（丢帧）在表现上严重程度不同，但诱因往往相似——主线程被占据。主要原因可分为三大类：

1. 主线程做耗时操作：如直接在主线程解析大 JSON、读写 SharedPreferences (尤其是老版本)、或者加载庞大的布局导致 measure/layout 时间过长。
2. 锁等待 (Lock Wait) 与死锁：主线程等待工作线程释放某个锁，而工作线程迟迟不释放；或者主线程与工作线程互相等待对方的锁（Deadlock）。
3. 系统层面阻塞：
   • Binder 阻塞：主线程发起同步 IPC 调用，对端进程卡住或系统负载过高导致超时。
   • CPU 饥饿：后台大量高优先级线程抢占 CPU，或者系统整体处于高负载，分配给当前 App 主线程的时间片极少。

三、ANR 与卡顿 (Jank) 的区别联系

• 卡顿 (Jank)：主线程并未完全死锁，只是单次处理事件/渲染耗时超过了 16.6ms（60Hz 屏幕），导致丢帧。用户觉得“不跟手”。
• ANR：主线程彻底罢工或执行超长任务（如长达 5 秒甚至更久），完全失去响应能力。
• 联系：持续的严重卡顿，若碰巧阻塞了系统的输入事件或广播调度，就会升级为 ANR。

四、排查路径与流程（本地 vs 线上）

解决此类问题同样依赖不同阶段的针对性工具。

ANR 定位流程：

1. 获取 Traces 文件：当 ANR 发生时，系统会生成 traces.txt（位于 /data/anr/ 下，高版本可能聚合成了 Bugreport 格式）。
2. 分析 Main Thread 堆栈：打开 traces 文件，首先寻找 main 线程的调用栈。
   • 状态是 Runnable？可能是死循环或大计算量代码。
   • 状态是 Blocked？说明在等锁，需要顺藤摸瓜找当前占有这把锁的线程（held by owner）。
3. 结合 CPU / IO 状态：看 traces 头部，检查当时的 CPU 负载（User/System/IOWait）。如果 IOWait 极高，说明主线程可能阻塞在磁盘操作；如果 CPU 总体负载达到 100%，哪怕主线程是简单的运算也会因分配不到时间片而 ANR。
4. 验证 Binder 对端：如果卡在 BinderProxy.transact，需分析当时的系统服务或其他进程状态是否异常。

五、ANR-WatchDog (线上监控思路)

线上由于权限限制，难以直接去 /data/anr/ 拉取完整的 traces。 常见的应用层监控手段是基于 WatchDog 的思路：

• 启动一个后台线程（WatchDog 线程）。
• 每隔固定时间（如 5 秒），向主线程的消息队列 MessageQueue 抛一个任务（修改某个标志位）。
• WatchDog 线程休眠 5 秒后醒来，检查标志位是否被修改。如果没有修改，说明主线程 5 秒内都没能处理这个极其简单的消息，说明主线程卡死了。
• 此时由 WatchDog 线程主动去 dump 主线程的堆栈信息并上报服务器。

高频面试题

Q1: 看 traces.txt 定位 ANR，主线程处于 Runnable 状态就一定是代码在死循环吗？ 不一定。Runnable 只代表在操作系统的就绪队列中，或者正在运行。如果系统 CPU 资源极度紧张被其他进程抢占，主线程虽然是 Runnable 但实际上得不到 CPU 时间片，也会发生 ANR。

Q2: 什么是 Binder 阻塞引起的 ANR？ 当主线程调用诸如获取系统服务（如 ActivityManager、PackageManager）的方法时，通常是一个跨进程的同步调用（IPC）。如果当时系统服务端负载过高或卡死，主线程就会一直等对端返回，最终导致 ANR。

Q3: 如何用工具查出是布局层级过深导致的滑动卡顿？ 可以使用 Layout Inspector 查看 View 树的层级结构。同时，抓取一段滑动的 Perfetto (或 Systrace) 文件，观察 RenderThread 和 Main Thread 上的 Choreographer#doFrame 切片，看里头的 measure/layout 子片段是否消耗了大量时间（远超 16ms）。

易错点 / 追问

• 误区： “发生 ANR 一定是我的代码写错了。” 很多时候线上的 ANR 是由于手机老化、后台其他应用疯狂抢占资源（CPU/IO）导致的，或者厂商系统的 Bug 导致 Binder 响应缓慢。
• 追问： 如果 traces 看到主线程卡在底层的 epoll_wait 或者 MessageQueue.nativePollOnce，说明什么？（答：这通常说明主线程是空闲的，在等待新的消息，并没有阻塞。如果此时发生了 ANR，极有可能是 ANR 发生瞬间主线程刚好处理完了阻塞任务进入空闲，或者是系统组件派发消息出现了时序错乱。）
• 易错点： 将卡顿监控的阈值设得太低。线上网络和设备环境复杂，过于激进的卡顿阈值会产生海量无效上报，淹没真正的性能瓶颈。

性能工具专题

性能优化不是“凭感觉改几行代码”,而是先观测、再定位、再验证。工具章节的面试重点是:每个工具看什么、适合什么问题、输出如何转化为工程动作。

一、工具选型总览

工具回答要避免“列名词”,而要说清楚“我怀疑什么 → 用什么采样 → 看哪个指标 → 怎么验证改动”。

二、Android Studio Profiler

Android Studio Profiler 适合本地开发阶段快速观察 CPU、Memory、Network、Energy。

• CPU Profiler:看主线程是否有长任务、方法调用耗时、线程调度。可用 Sampled/Instrumented/Java/Kotlin Method Trace,采样开销更低,插桩更细但扰动更大。
• 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 + baseline-prof Gradle 插件生成/合并 profile,再用 Macrobenchmark 验证收益。

面试要点:

• Macrobenchmark 关注稳定设备、固定版本、足够迭代次数和噪声控制。
• Baseline Profile 不是万能优化,主要改善解释执行/JIT 预热带来的启动和关键路径抖动。
• 性能数据要保存历史趋势,否则无法判断回归。

五、LeakCanary 与内存定位

LeakCanary 自动观察 Activity、Fragment、ViewModel 等对象生命周期,对象应被回收却仍被引用时触发 heap dump 并给出泄漏引用链。

常见泄漏原因:

• 静态单例持有 Activity/Context。
• Handler/Runnable/Coroutine 未随生命周期取消。
• Adapter、Listener、Callback 未解绑。
• Dialog/PopupWindow/Animator 持有 View。
• 全局缓存无上限或 key/value 持有页面对象。

Memory Profiler 更适合看对象分配和堆变化,LeakCanary 更适合自动发现泄漏。线上内存问题则要结合 OOM 日志、dumpsys meminfo、业务埋点和设备分布分析。

六、StrictMode 与开发期红线

StrictMode 用来在开发/测试阶段发现主线程磁盘 I/O、网络、资源未关闭、Activity 泄漏等问题。

if (BuildConfig.DEBUG) {
    StrictMode.setThreadPolicy(
        StrictMode.ThreadPolicy.Builder()
            .detectDiskReads()
            .detectDiskWrites()
            .detectNetwork()
            .penaltyLog()
            .build()
    )
}

它不是线上性能监控方案,而是把“本不该发生的开发期违规”尽早暴露。不要为了消除告警简单 permitAll,应该定位调用链并把 I/O 移到合适线程或启动阶段之外。

七、dumpsys、gfxinfo、meminfo

dumpsys 是 Android 系统服务状态入口,适合连接真机后快速拿到系统级快照。

gfxinfo framestats 可导出每帧各阶段时间,适合脚本化对比优化前后。meminfo 的 PSS 更接近进程实际占用视角,但仍要结合 Android 版本、厂商和图形内存差异理解。

八、simpleperf 与 Native CPU 热点

simpleperf 是 Android 官方 native profiling 工具,可采样 CPU 指令、调用栈和符号,适合 NDK/JNI、音视频、加解密、图像处理等热点定位。

典型关注:

• native 函数是否占用异常 CPU。
• JNI 往返是否过多。
• 锁竞争、内存拷贝、算法复杂度是否是瓶颈。
• so 是否保留符号或能通过符号表/映射文件还原调用栈。

面试表达可以说:Java/Kotlin 层先用 Perfetto/Profiler 定位到 native 调用段,再用 simpleperf 下钻 native 热点,最后用基准测试和真实场景回归验证。

高频面试题

Q1:Profiler、Perfetto、Systrace 怎么选? Profiler 适合开发期快速看单进程 CPU/内存/网络;Perfetto 适合系统级时序分析,能看调度、渲染、Binder、I/O;Systrace 是旧链路但概念相通。复杂卡顿优先 Perfetto,内存泄漏优先 LeakCanary/Memory Profiler。

Q2:Trace.beginSection 有什么价值? 它把业务阶段标记进系统 trace,让 Perfetto 里能把主线程长任务和具体模块对应起来。注意 section 名称要稳定、简洁、无敏感信息,并保证 begin/end 成对。

Q3:Macrobenchmark 和普通 benchmark 区别? Macrobenchmark 从 App 外部驱动真实启动、滚动、跳转等宏观场景,更贴近用户体验;普通 microbenchmark 更适合测小函数/算法。性能门禁通常用 Macrobenchmark 看趋势和回归。

Q4:Baseline Profile 解决什么问题? 它把启动和关键路径热点提前提供给 ART 编译,减少冷启动/首帧阶段解释执行和 JIT 预热成本。它不是替代业务优化,仍要用 Macrobenchmark 验证收益。

Q5:LeakCanary 报出泄漏后怎么处理? 先看泄漏对象和引用链,判断是否生命周期结束后仍被持有;再定位静态引用、回调、协程、Handler、Adapter 等持有者;修复后重新进入/退出页面并确认泄漏不再出现。

易错点 / 追问

• 不要只贴工具截图,要能说明指标含义和下一步工程动作。
• 不要在 debug、插桩、连接 Profiler 的环境下直接宣称线上性能收益。
• Perfetto 看到主线程长任务后,要继续区分 CPU 忙、锁等待、I/O、Binder 等原因。
• Baseline Profile 需要随关键路径变化更新,否则 profile 会逐渐失效。
• StrictMode 告警不能靠关闭规则解决,应修正线程和资源使用。

APM 与线上监控

☆ APM 是把“性能优化“从本地经验升级成线上体系的关键。你的风控 SDK 背景可以重点讲 native crash、采样、灰度和宿主影响控制。

一、APM 监控什么

二、Crash 监控:Java 与 Native

Java crash 常通过 Thread.setDefaultUncaughtExceptionHandler 捕获;native crash 需要 signal handler 或 Breakpad/Crashpad 这类方案。

面试边界:不要说“所有 native crash 都能优雅恢复“。多数情况下只能采集现场、下次启动上报、灰度回滚。

三、ANR 与卡顿监控

• ANR:系统判定,重点是拿到 traces 和主线程阻塞证据。
• 卡顿:应用侧可用主线程 watchdog、Choreographer 帧回调、FrameMetrics 监控。
• 线上采样必须控制开销,避免监控本身制造卡顿。

四、启动与网络监控

启动监控要区分进程创建、Application、首 Activity、首帧、业务首页可交互。网络监控要拆 DNS、TCP、TLS、请求、响应、解析,不要只报一个总耗时。

五、上报链路、采样与隐私

• 本地缓存:避免 crash 当场丢失日志。
• 批量上报:减少电量和流量开销。
• 采样:高频事件不能全量。
• 隐私:不上传明文 token、手机号、身份证、设备敏感字段。

六、怎么把 SDK 经历讲成亮点

可以这样组织:“SDK 嵌入宿主 App 后,我关注的不只是功能成功,还要保证不拖累宿主稳定性。我们会监控 native crash、初始化耗时、线程/网络开销,灰度阶段看指标,异常时能按版本/ABI/机型聚合定位。”

高频面试题

Q1:线上卡顿怎么监控? 答:轻量方案是主线程 watchdog 或 Choreographer 统计慢帧;深入定位要结合 Perfetto/trace。线上只采样关键指标,本地复现再做完整 trace。

Q2:native crash 怎么定位? 答:采集 signal、寄存器、线程栈、so build id/版本/ABI,结合未 strip 符号或 symbol server 还原堆栈,按版本和机型聚类。

Q3:APM SDK 会不会影响性能? 答:会,所以要采样、异步、批量、延迟上报,关键路径不做重 IO,监控逻辑本身也要被监控。

易错点 / 追问

• 不要把本地 Profiler 等同于线上 APM。
• 不要上传敏感业务数据。
• 不要只讲采集,还要讲聚合、告警、灰度回滚和修复闭环。

存储体系与 Scoped Storage

★ 数据持久化是客户端的根本。面试不仅考“怎么存”，更考“存哪里最安全”、“大文件怎么管”以及“多进程怎么防丢数据”。

一、轻量级 KV 存储：SharedPreferences 与 DataStore

SP 的核心痛点： commit() 同步阻塞；apply() 虽然异步，但在 Activity/Service 销毁时，系统层（QueuedWork）会等待所有 apply 的磁盘写入完成，极易导致 ANR。

二、关系型数据库：SQLite 与 Room

• Room 的优势：编译时 SQL 语法检查；与协程/Flow/LiveData 无缝结合；基于注解的类型转换与实体映射。
• WAL 模式 (Write-Ahead Logging)：开启后 (setWriteAheadLoggingEnabled)，读写可以并发执行，极大提升并发性能。写操作先追加到 -wal 文件，稍后再 Checkpoint 同步到 .db。
• 数据库升级 (Migration)：

val MIGRATION_1_2 = object : Migration(1, 2) {
    override fun migrate(database: SupportSQLiteDatabase) {
        database.execSQL("ALTER TABLE users ADD COLUMN age INTEGER NOT NULL DEFAULT 0")
    }
}

三、文件目录与沙盒机制

Android 的私有目录分为内部存储和外部存储的私有部分，应用卸载时都会被删除：

1. 内部存储 (Internal Storage): Context.getFilesDir(), Context.getCacheDir()。空间非常有限，绝对不能放图片视频等大文件。
2. 外部私有存储 (External Storage - App-specific): Context.getExternalFilesDir(), Context.getExternalCacheDir()。空间较大，适合放应用的业务文件。不需要存储权限即可访问。

四、分区存储 (Scoped Storage) 与 SAF

在 Android 10+ 引入，为了防止应用在 SD 卡上“拉屎”。

• 自己产生的业务文件：放沙盒 (getExternalFilesDir)，不需要权限，卸载自动删。
• 需要分享/保存给用户的多媒体：通过 MediaStore 插入（图片、视频、音频）。插入不需要权限，读取别的应用插入的媒体需要 READ_MEDIA_IMAGES 等权限。
• 让用户选择文件/非媒体文件：使用 SAF (Storage Access Framework)，即 ACTION_OPEN_DOCUMENT。由系统选择器 UI 授权，返回一个不可伪造的 Document URI。

五、安全存储：Keystore 与 EncryptedSharedPreferences

• 敏感信息（如 Token、密码）怎么存？ 不能明文写在 SP 或文件里。推荐使用 Jetpack Security 库中的 EncryptedSharedPreferences。
• 底层原理：它利用 Android Keystore 系统生成并保管主密钥（Master Key），主密钥存放在设备的硬件安全模块（TEE/SE）中，极难被提取。然后用主密钥加密真实的数据。

高频面试题

Q1：SharedPreferences 为什么会导致 ANR？怎么解决？ 答：因为 apply() 提交的任务会进入系统级的 QueuedWork 队列。在组件（如 Activity）执行 onStop 时，系统为了保证数据不丢，会强制等待队列中的磁盘写入任务完成。如果写入量大或磁盘 IO 慢，就会阻塞主线程导致 ANR。 解决：迁移到 DataStore 或 MMKV；或者通过反射清理 QueuedWork（黑科技，不推荐）。

Q2：如何优雅地处理几十上百 MB 的大文件下载与缓存清理？ 答：

1. 存储位置：放在 Context.getExternalCacheDir() 下，千万别放内部存储。
2. 清理策略：实现 LRU 算法的磁盘缓存工具，设定最大容量（如 200MB）。在每次写入后检查总大小，淘汰最旧的未访问文件。
3. 系统干预：可以覆写 Application 的 onTrimMemory，在设备空间不足时主动清理。

Q3：Room 数据库在跨版本升级时，如果用户跨了好几个版本（比如 V1 直接升级到 V4）怎么处理？ 答：Room 支持定义多段 Migration，如 1-2, 2-3, 3-4。在构建 Database 时 addMigrations() 传入所有规则。Room 内部会自动寻找最短的迁移路径（按序应用 1-2，然后 2-3，然后 3-4）。如果没有找到路径且没有配置 fallbackToDestructiveMigration()，App 会崩溃。

易错点 / 追问

• 混淆 MediaStore 与 File API：在 Android 11+，即使你拿到了 MediaStore 中的文件真实绝对路径 (_data 字段)，用 File API 去读写也可能被拒绝，必须使用 ContentResolver.openInputStream() 处理 URI。
• 忽略多进程 SP 的危险：多进程读写 SP 是数据损坏和丢失的重灾区。追问时一定要提到 MMKV 的共享内存 (mmap) 与文件锁机制是目前多进程 KV 存储的最佳实践。
• 数据库主线程读写：初学者常在主线程做 DB 查询。必须借助协程调度到 Dispatchers.IO。

网络协议

网络是中级面试必考硬通货,也是你的潜在主场——做风控/抓包对抗,HTTPS、证书、TLS 你比一般应用开发者懂得深,能讲到中间人、证书校验、双向认证的层面。

本篇含知识点讲解 + 高频面试题。

一、HTTP 基础

• 无状态:每次请求独立,靠 Cookie/Session/Token 维持状态。
• 请求结构:请求行(方法 + URL + 版本)+ 请求头 + 空行 + 请求体。
• 常用方法:GET(查,幂等)、POST(增,非幂等)、PUT(全量改,幂等)、DELETE、PATCH(部分改)、HEAD、OPTIONS(预检)。
• GET vs POST:GET 参数在 URL、有长度限制、可缓存、幂等;POST 参数在 body、无长度限制、不可缓存。语义区别 > 技术区别。

状态码

• 1xx 信息;2xx 成功(200、201、204)。
• 3xx 重定向:301(永久)、302(临时)、304(协商缓存命中)。
• 4xx 客户端错:400、401(未认证)、403(无权限)、404、405、429(限流)。
• 5xx 服务端错:500、502(网关错误)、503(不可用)、504(网关超时)。

缓存

• 强缓存:Cache-Control(max-age)、Expires,不发请求直接用本地。
• 协商缓存:ETag/If-None-Match、Last-Modified/If-Modified-Since,发请求由服务端判断,命中返 304。

二、HTTP 版本演进

• HTTP/1.1 队头阻塞:同一连接请求需按序响应,前一个慢会卡后面。HTTP/2 多路复用在应用层缓解,但 TCP 层仍有队头阻塞;HTTP/3 基于 QUIC/UDP,通过独立 stream 降低 TCP 层队头阻塞影响。
• WebSocket:基于 HTTP 升级(Upgrade)的全双工长连接,用于实时通信(IM、推送)。

三、HTTPS 与 TLS(你的强项,讲深)

HTTPS = HTTP + TLS/SSL,解决三个问题:加密(防窃听)、完整性(防篡改)、身份认证(防冒充)。

TLS 握手:RSA 密钥交换 vs ECDHE

TLS 的核心思想是:先认证身份并协商出对称会话密钥,后续用对称加密传 HTTP 数据。对称加密快,但首次密钥分发困难;非对称/密钥交换负责解决首次协商与身份认证。

TLS 1.2 RSA 简化流程

1. Client Hello:客户端发支持的 TLS 版本、加密套件、随机数。
2. Server Hello:服务端选择套件、返回随机数、下发证书(含公钥)。
3. 客户端验证证书(CA 链、域名、有效期、吊销状态等),生成 pre-master secret,用服务端 RSA 公钥加密后发送。
4. 服务端用私钥解密,双方用 pre-master secret + client_random + server_random 派生对称会话密钥。
5. 双方发送 Finished 校验握手完整性,之后用对称加密通信。

TLS 1.2 ECDHE / TLS 1.3 直觉

• ECDHE:服务端发送临时 ECDHE 公钥并用证书私钥签名,客户端验证签名后也生成临时公钥;双方各自用“自己的临时私钥 + 对方临时公钥”算出共享秘密。网络上没有直接传输会话密钥。
• TLS 1.3:移除静态 RSA 密钥交换等旧套件,把常规握手压到 1-RTT:ClientHello 携带 key share,ServerHello 返回 key share 和证书相关消息,双方很快得到密钥。
• 0-RTT:客户端基于上次会话恢复提前发送早期数据,降低重连延迟;边界是早期数据可能被重放,所以只适合幂等 GET/查询类请求,不适合支付、下单、转账、登录态变更等非幂等操作。

面试一句话:旧 RSA 像“用证书公钥包住会话密钥”,现代 ECDHE/TLS 1.3 更像“证书负责证明你是谁,临时密钥交换负责生成本次会话密钥”,因此具备前向保密。

证书与信任链

• 证书由 CA 逐级签发,设备内置根 CA。验证时沿链校验到可信根。
• 为什么不能只用对称加密? 密钥分发难题:首次怎么安全传密钥?用非对称解决。
• 为什么不全用非对称? 慢。所以只用它协商对称密钥。

安全实战(你能讲、别人讲不了)

• 中间人攻击(MITM):攻击者伪造证书。防御靠客户端严格校验证书。
• 证书锁定(SSL Pinning):App 内置服务端证书/公钥指纹,只信任它,防抓包/MITM——风控/金融 App 标配。
• 双向认证(mTLS):服务端也验证客户端证书。
• 抓包对抗:Charles/Fiddler 装根证书抓 HTTPS;App 可用 Pinning + 检测代理对抗。这是你做风控的实战领域。

四、TCP / UDP

TCP 三次握手

1. Client → SYN(seq=x)
2. Server → SYN+ACK(seq=y, ack=x+1)
3. Client → ACK(ack=y+1) 为什么三次? 确认双方收发能力都正常;两次无法确认客户端的接收能力,且防止历史失效连接请求建立连接。

TCP 四次挥手

1. Client → FIN 2. Server → ACK 3. Server → FIN 4. Client → ACK 为什么四次? 关闭是双向的,服务端收到 FIN 后可能还有数据要发,所以 ACK 和 FIN 分开。 TIME_WAIT(2MSL):主动关闭方等待,确保最后 ACK 到达 + 让旧报文消散。

可靠性机制

序列号 + 确认应答、超时重传、滑动窗口(流量控制)、拥塞控制。

拥塞控制:看懂 cwnd / ssthresh 转换

• cwnd(congestion window):发送端根据网络拥塞程度维护的拥塞窗口,限制“未确认在途数据量”。
• ssthresh(slow start threshold):慢启动阈值,决定从指数增长切到线性增长。
• 实际发送窗口通常取 min(cwnd, rwnd):拥塞控制看网络承载能力,流量控制看接收端缓存能力。

超时 vs 快重传的区别:

• 超时重传说明网络可能严重拥塞或 ACK 完全回不来,处理更保守:常见做法是 ssthresh = cwnd / 2,然后 cwnd 回到很小值重新慢启动。
• 3 个重复 ACK说明后续包还能到达,网络没有完全断流,所以只减半窗口并快恢复,比超时温和。

新连接/超时
  ↓ cwnd 指数增长
慢启动 ── cwnd >= ssthresh ──> 拥塞避免(线性增长)
  │                              │
  └── 超时:ssthresh=cwnd/2,cwnd 重置 ─┘
                                 │
                                 └── 3 dup ACK:快重传 → 快恢复 → 拥塞避免

面试答题流:先区分可靠性(序号/ACK/重传)与拥塞控制(保护网络),再解释 cwnd/ssthresh,最后用“超时更严重、快重传更温和”讲阶段转换。

TCP vs UDP

高频面试题

Q1:HTTP 和 HTTPS 区别? HTTPS = HTTP + TLS,提供加密、完整性、身份认证。HTTP 明文 80 端口,HTTPS 加密 443 端口,需证书,有握手开销但安全。

Q2:TLS 握手为什么用非对称 + 对称结合? 非对称/密钥交换解决首次协商和身份认证,对称加密负责后续高性能传输。旧 RSA 是客户端用证书公钥加密 pre-master secret;现代 ECDHE/TLS 1.3 用临时密钥交换生成会话密钥,证书主要证明服务端身份,并提供前向保密。

Q3:TCP 为什么三次握手不是两次? 三次才能确认双方收发能力都正常,并防止已失效的历史连接请求突然到达导致错误建连。两次无法确认客户端接收能力。

Q4:TIME_WAIT 是什么?为什么等 2MSL? 主动关闭方在四次挥手后进入 TIME_WAIT,等 2 倍报文最大生存时间:确保最后的 ACK 能到达对端(否则对端重传 FIN),并让本连接的旧报文在网络中消散。

Q5:HTTP/2 相比 1.1 的核心改进? 二进制分帧、多路复用(一个连接并发多请求,解决应用层队头阻塞)、头部压缩 HPACK、服务端推送。

Q6:什么是 SSL Pinning?为什么风控 App 要用?(你的强项) 客户端内置服务端证书或公钥指纹,握手时只信任它而非系统 CA,防止中间人用伪造证书抓包/篡改。金融、风控 App 用它对抗抓包和 MITM。

Q7:输入 URL 到页面展示发生了什么? DNS 解析 → 建立 TCP 连接(三次握手)→ TLS 握手(HTTPS)→ 发 HTTP 请求 → 服务端响应 → 客户端解析渲染 → 关闭/复用连接。

进阶补充:DNS、QUIC、TCP 状态与 TLS 细节

DNS 解析链路

域名访问前通常经历缓存查询、本地 DNS、递归解析。移动端排查网络慢时要区分 DNS、TCP、TLS、请求、响应各阶段。

HTTP/3 与 QUIC

HTTP/3 基于 QUIC(运行在 UDP 上),把传输层和 TLS 1.3 握手整合,改善队头阻塞和弱网迁移。面试不要说“UDP 就不可靠“,QUIC 在用户态实现可靠传输。

TIME_WAIT / CLOSE_WAIT 排障

TLS 补充:SNI、ALPN、OCSP、会话恢复

• SNI:客户端握手时告诉服务端目标域名。
• ALPN:协商 HTTP/1.1、HTTP/2 等应用协议。
• OCSP:检查证书吊销状态。
• Session Ticket/PSK:减少重复握手成本。

**追问:**HTTP/2 和 HTTP/3 都解决什么问题?HTTP/2 多路复用仍受 TCP 队头阻塞影响;HTTP/3 基于 QUIC 改善连接迁移和队头阻塞。

网络排障专项

网络排障的核心不是背 HTTP 状态码,而是把一次请求拆成 DNS → TCP → TLS → HTTP → 业务解析 → 本地缓存/重试。Android 面试尤其看你能否用 OkHttp、Charles、日志和弱网策略定位真实线上问题。

一、移动端网络排障总流程

先按链路分层,不要一上来就改超时或重试。每一层都要有证据:耗时、错误码、异常类型、抓包结果、服务端日志。

用户反馈慢/失败
  ↓
确认网络类型/Wi-Fi/蜂窝/代理/VPN
  ↓
DNS 解析 → TCP 连接 → TLS 握手 → HTTP 请求/响应
  ↓
OkHttp EventListener/Interceptor 日志
  ↓
Charles/服务端 trace 对照
  ↓
重试、降级、缓存或服务端修复

二、DNS 慢与解析失败

DNS 问题常表现为“首包慢、部分地区失败、切 Wi-Fi/蜂窝表现不同”。Android 端要区分 DNS 解析耗时和后续连接耗时。

• 原因:运营商 DNS 慢/污染、IPv6/IPv4 选择问题、DNS 缓存过期、内网域名不可达、DoH/HTTPDNS 配置异常。
• 证据:OkHttp EventListener.dnsStart/dnsEnd 耗时、解析到的 IP、网络类型、地区、失败异常。
• 策略:合理 DNS 缓存、HTTPDNS/DoH、Happy Eyeballs、失败 IP 黑名单、按域名维度监控。
• Android 注意:不要在主线程解析域名;多域名、多 IP 兜底要避免无限重试导致电量和流量浪费。

面试话术:先证明是不是 DNS 慢,再谈替代方案;HTTPDNS 能绕过运营商 DNS,但要处理 HTTPS 证书域名校验、调度准确性和缓存过期。

三、TLS 失败、证书错误与 Pinning 调试

TLS 失败要按“证书链、域名、时间、协议套件、Pinning、代理抓包”逐项排除。

Charles 调试与 Pinning 策略:

1. 开发/测试包可使用 debug-only network_security_config 信任用户 CA。
2. Pinning 必须区分 debug/release:debug 可关闭或使用测试 pin,release 严格校验。
3. 不要为了抓包在线上包硬编码关闭 Pinning;应该用构建变体、白名单测试域名或内部证书。
4. Pinning 要支持证书轮换:至少保留当前和备用公钥 pin。

四、HTTP 4xx/5xx 与业务错误定位

HTTP 状态码要先分清“协议层状态”和“业务层 code”。移动端常见误区是看到 500 就重试,看到 401 就清登录态,但真实原因可能更细。

• 400:参数格式、签名、时间戳、序列化字段缺失。
• 401:token 过期、刷新 token 失败、设备被踢、匿名接口误带错误凭证。
• 403:无权限、风控拦截、地区/灰度策略不允许。
• 404/405:路径、环境、方法不一致,常见于测试环境配置错。
• 429:限流,客户端要退避而不是立刻重试。
• 500/502/503/504:服务端、网关、上游依赖或超时;客户端要带 traceId 找服务端对日志。

Android 实践:

• Interceptor 统一注入 traceId、版本、网络类型,便于端云对齐。
• 401 刷新 token 要做单飞(single flight),避免并发请求同时刷新。
• 4xx 多数不应盲重试;5xx 可对幂等请求有限退避重试。

五、弱网络重试、连接池与超时设置

弱网策略要平衡成功率、电量、流量和业务副作用。不是“失败就重试三次”这么简单。

val client = OkHttpClient.Builder()
    .connectTimeout(10, TimeUnit.SECONDS)
    .readTimeout(15, TimeUnit.SECONDS)
    .writeTimeout(15, TimeUnit.SECONDS)
    .callTimeout(30, TimeUnit.SECONDS)
    .retryOnConnectionFailure(true)
    .connectionPool(ConnectionPool(5, 5, TimeUnit.MINUTES))
    .build()

• connectTimeout:TCP 建连超时,过短会误伤弱网,过长会拖慢失败反馈。
• readTimeout/writeTimeout:读写单次阻塞超时,适合控制传输阶段。
• callTimeout:一次 call 总预算,避免 DNS/TLS/重试叠加无限拉长。
• 连接池:复用 TCP/TLS 连接降低握手成本;但域名/IP/证书变化、长时间 idle、网络切换会导致旧连接失效。
• 重试原则:GET/查询类可退避重试;下单、支付、登录态变更必须依赖幂等 key 或服务端去重。
• 退避策略:指数退避 + jitter,避免所有客户端同时重试放大故障。

六、OkHttp Interceptors、EventListener 与 Charles

OkHttp 排障工具分两类:Interceptor 看请求/响应内容,EventListener 看阶段耗时。两者结合才能回答“慢在哪里”。

• Application Interceptor:业务层,适合加公共 header、日志、签名、token、业务错误处理。
• Network Interceptor:网络层,能看到重定向、网络响应、缓存细节。
• EventListener:记录 DNS、connect、secureConnect、requestHeaders、responseHeaders 等阶段耗时。
• Charles:验证请求是否发出、header/body 是否正确、TLS 证书链、代理环境下服务端响应。

排障 checklist:

1. 打印 URL、method、traceId、状态码、异常类型、各阶段耗时。
2. Charles 对照请求头、body、证书和响应。
3. 断网/弱网/代理/VPN/IPv6 场景复现。
4. 和服务端用 traceId 对齐网关日志。
5. 修复后保留监控指标,避免同类问题复发。

高频面试题

Q1:用户反馈接口慢,你怎么定位? 先拆阶段:DNS、TCP、TLS、请求上传、服务端处理、响应下载。用 OkHttp EventListener 记录阶段耗时,Interceptor 打 traceId,Charles/服务端日志对照,再判断是客户端网络、证书、连接池还是服务端问题。

Q2:TLS 证书错误常见原因有哪些? 证书过期、设备时间错误、证书链不完整、域名与 SAN 不匹配、老设备 TLS 套件不兼容、Pinning 指纹不匹配、Charles 代理证书未被 debug 包信任。

Q3:弱网重试怎么设计? 只对幂等或有幂等 key 的请求重试,设置总 callTimeout,使用指数退避和 jitter,限制次数,网络恢复后再补偿。非幂等业务必须服务端去重,不能客户端盲重发。

Q4:OkHttp Interceptor 和 EventListener 区别? Interceptor 适合改请求、加 header、签名、日志和处理响应;EventListener 更适合记录 DNS/TCP/TLS/请求/响应各阶段耗时,用于定位慢在哪里。

易错点 / 追问

• 易错:把 5xx 全部归因客户端;应带 traceId 找服务端/网关日志。
• 追问:HTTPDNS 访问 IP 时 HTTPS 证书怎么校验?仍要用原始域名做 SNI/Hostname verification,不能简单把 URL host 改成 IP 后跳过校验。
• 易错:为了 Charles 抓包关闭 release Pinning;正确做法是 debug-only 策略或测试域名。
• 追问:为什么 429 不该立即重试?它表示限流,立即重试会放大压力,应按服务端提示或指数退避。

数据库进阶

移动端数据库面试不是背 SQL,而是解释清楚 SQLite 在单文件、弱资源、强一致本地存储下如何工作。能把索引、事务、WAL、锁、Room 迁移和缓存一致性串起来,就能从“会用 Room”升级成“能治理本地数据层”。

一、SQLite 索引与查询优化

SQLite 常用 B+Tree 组织表和索引。Android 端最常见的优化目标是:列表页首屏快、搜索条件可命中索引、分页不扫全表、写入不要被过多索引拖慢。

索引失效常见场景:

• 对索引列做函数或计算:where date(createdAt)=?。
• like '%keyword' 前缀模糊无法利用普通 BTree 范围。
• 联合索引 (a,b,c) 跳过 a 只查 b。
• 隐式类型转换,如文本列传数字参数。

二、事务、WAL 与持久性

事务保证一组本地状态变更要么一起成功,要么一起回滚。移动端常见场景是“网络响应入库 + 更新本地缓存版本 + 删除旧分页游标”必须在同一事务内完成。

@Transaction
suspend fun replacePage(page: Int, items: List<ItemEntity>, nextKey: String?) {
    remoteKeyDao.upsert(RemoteKeyEntity(page, nextKey))
    itemDao.deletePage(page)
    itemDao.insertAll(items)
}

• Rollback Journal:修改前先备份旧页,提交后删除 journal;读写互斥更明显。
• WAL(Write-Ahead Logging):先写入 WAL 文件,读者可继续读旧快照,写者追加日志,读写并发更好。
• Checkpoint:把 WAL 内容合并回主库;WAL 过大可能影响磁盘与启动恢复。
• Room 实践:批量 insert/update 用事务包住,避免每条 SQL 都 fsync,显著降低耗时和卡顿风险。

三、锁、并发与 Android 线程模型

SQLite 是嵌入式数据库,不是多进程数据库服务器。它的锁粒度会影响“UI 查询、后台同步、埋点写入”之间的互相阻塞。

1. 共享锁:多个读事务可并发读。
2. 保留锁/待提交锁:写事务准备提交时逐步升级。
3. 排它锁:真正写主库时需要排它访问。
4. WAL 模式下读写并发更好:读者看快照,写者追加 WAL,但同一时间通常仍只有一个 writer。
5. Android 约束:不要在主线程做大查询或大事务;Room 默认禁止主线程数据库访问是为了防 ANR。

面试回答可以强调:SQLite 适合本地轻量存储,但不适合把所有模块都当成高并发中心库;日志、缓存、业务状态最好按表职责拆清楚,写入队列化。

四、Explain Query Plan 排查慢查询

EXPLAIN QUERY PLAN 用来确认 SQL 是否走索引、是否全表扫描、是否临时排序。它不是“猜测优化”,而是用证据定位慢查询。

EXPLAIN QUERY PLAN
SELECT id, title, createdAt
FROM message
WHERE conversationId = ?
ORDER BY createdAt DESC
LIMIT 20;

-- 关注输出里是否出现:
-- SEARCH TABLE message USING INDEX index_message_conversation_createdAt
-- 避免: SCAN TABLE message 或 USE TEMP B-TREE FOR ORDER BY

Android 排查路径:

1. 先用日志记录慢 SQL、参数、耗时和线程。
2. 用 EXPLAIN QUERY PLAN 判断是否 SCAN TABLE。
3. 对 where + order by 组合设计联合索引。
4. 只查询 UI 需要的列,避免把大字段一次性读出。
5. 回归验证首屏、翻页、搜索三个关键路径。

五、Room Migration 与数据演进

Room 迁移考的是“线上旧数据怎么安全升级”,不是只会改 entity。中级面试要说明 schema 版本、迁移 SQL、回滚策略和测试。

• 显式 Migration:从版本 N 到 N+1 写清 ALTER TABLE、建新表、搬数据、删旧表。
• AutoMigration:适合简单加列/改名,复杂数据变换仍建议手写。
• 破坏性迁移风险:fallbackToDestructiveMigration() 会清库,只适合非核心缓存库。
• 迁移测试:用旧版本 schema 创建数据库,插入旧数据,跑 migration,再校验新 DAO 能正常读写。

val MIGRATION_2_3 = object : Migration(2, 3) {
    override fun migrate(db: SupportSQLiteDatabase) {
        db.execSQL("ALTER TABLE User ADD COLUMN riskLevel INTEGER NOT NULL DEFAULT 0")
        db.execSQL("CREATE INDEX IF NOT EXISTS index_User_riskLevel ON User(riskLevel)")
    }
}

六、N+1 查询、分页与缓存一致性

N+1 查询:先查 1 次列表,再对每个 item 查一次关联数据,列表 50 条就变成 51 次数据库访问。Android 列表滑动时会放大成卡顿。

• 用 JOIN、@Relation + @Transaction、批量 where id in (...) 解决。
• 对 RecyclerView/Compose 列表只暴露聚合后的 UI model,不要在 bind 阶段查库。
• Room Flow 监听表变化时要避免过宽查询,否则任意字段变更都触发大列表重算。

分页策略:

• Offset 分页:LIMIT 20 OFFSET 10000 越往后越慢,因为仍要跳过大量行。
• Keyset/Cursor 分页:where createdAt < ? order by createdAt desc limit 20,适合消息/Feed。
• Paging3 + RemoteMediator:网络页、本地 Room、RemoteKey 统一管理,离线也能展示。

缓存一致性:

1. 单一可信源:UI 优先观察 Room,网络结果先入库再由数据库驱动 UI。
2. 版本号/时间戳:解决本地缓存和服务端增量同步冲突。
3. 事务更新:数据表和分页 key 同事务提交。
4. 过期策略:TTL、etag、服务端版本号结合,不要永久相信本地缓存。

高频面试题

Q1:SQLite WAL 为什么能提升并发? WAL 把写入追加到日志文件,读事务继续读主库旧快照,因此读写不必像 rollback journal 那样频繁互斥。但通常仍只有一个 writer,且需要 checkpoint 把 WAL 合并回主库。

Q2:如何排查 Room 列表查询慢? 先记录 SQL 耗时和线程,再用 EXPLAIN QUERY PLAN 看是否全表扫描或临时排序;根据 where/order by 设计联合索引,只查必要列,最后用首屏和分页场景回归。

Q3:Room Migration 为什么不能随便 destructive migration? 线上用户的本地业务数据、离线缓存、登录态关联数据可能被清空。除非是可重建缓存库,否则要写显式 migration 并用旧 schema 数据测试。

Q4:N+1 查询在 Android 为什么危险? 它把列表渲染放大成大量小查询,在 RecyclerView/Compose 滑动和 Flow 重新计算时容易造成 IO 抖动和掉帧。应改成 JOIN、批量查询或一次性聚合。

易错点 / 追问

• 追问:联合索引 (uid, createdAt) 能否支持只按 createdAt 查?一般不能,因为不满足最左前缀。
• 易错:以为 WAL 下写入完全并行;实际多读一写更友好,但 writer 之间仍会竞争。
• 追问:Offset 分页为什么越翻越慢?数据库仍要扫描/跳过前面大量记录,移动端大表应优先考虑 keyset 分页。
• 易错:把 Room @Transaction 只理解成注解,忽略它对一致性和批量写性能的价值。

Gradle 与工程化

中级面试常问构建系统和工程化能力,体现你能不能搭/维护一个中大型项目。你做 SDK 对构建、依赖、产物体积本就敏感,这块容易讲出深度。

一、Gradle 基础

• Gradle:基于 JVM 的构建工具,用 Groovy/Kotlin DSL(.kts) 写脚本。Android 用 AGP(Android Gradle Plugin)。
• 构建生命周期三阶段:
  1. 初始化(Initialization):确定哪些模块参与构建(settings.gradle)。
  2. 配置(Configuration):执行所有 build.gradle,构建任务依赖图(Task DAG)。这阶段慢会拖累整体。
  3. 执行(Execution):按依赖图执行需要的 Task。
• Task:构建的最小执行单元,有输入/输出,支持增量。
• 核心文件:settings.gradle(.kts)(模块声明)、build.gradle(.kts)(模块配置)、gradle.properties(全局配置)。

二、依赖管理

• 依赖配置:
  • implementation:依赖不传递(只本模块可见),编译隔离、加快构建,首选。
  • api:依赖传递给上层模块(谨慎用,会扩大编译范围)。
  • compileOnly:只编译期(如注解处理、provided)。
  • runtimeOnly、testImplementation、kapt/ksp(注解处理)。
• Version Catalog(libs.versions.toml):集中管理依赖版本,多模块统一,现代推荐。
• 依赖冲突:Gradle 默认选最高版本;可用 resolutionStrategy 强制版本、exclude 排除传递依赖。
• BOM:统一一组库的版本(如 Compose BOM)。

三、构建变体与产物

• buildTypes:debug / release(混淆、签名、是否可调试)。
• productFlavors:多渠道/多环境(免费版/付费版、国内/海外),组合成 variant。
• 签名配置 signingConfigs:配置 keystore。
• manifestPlaceholders / BuildConfig 字段:按变体注入不同配置(如不同 API 域名、key)。

四、组件化 / 模块化

中大型项目的核心架构:

• 为什么组件化:编译解耦(改一个模块不全量编)、并行开发、复用、可独立运行调试。
• 分层:app 壳 → 业务模块(feature) → 基础库(common/network/ui)。
• 模块通信(解耦):模块间不直接依赖,用路由(ARouter) + 接口下沉(sink) + DI 组合;Hilt 更偏依赖注入,不是页面路由本身。
• 路由 ARouter 机制:
  1. 业务页面用注解声明路径,如 @Route(path = "/user/profile")。
  2. 编译期 APT 扫描注解,为每个模块生成路由表类,记录 path → Activity/Fragment/Provider 的映射。
  3. App 启动或首次使用时加载各模块路由表。
  4. 调用 ARouter.getInstance().build("/user/profile").withString("id", id).navigation() 时,框架按 path 找到目标并完成参数注入/Intent 跳转。
• 接口下沉(sink):把跨模块能力抽到公共 API 模块,例如 :user-api 只放 UserService 接口和数据模型,:feature-order 依赖接口而不依赖 :feature-user 实现。实现模块通过路由 Provider 或 DI 绑定暴露能力。
• 与 Hilt/DI 的区别:路由解决“页面/服务如何按路径发现和跳转”,DI 解决“对象依赖如何创建和注入”。组件化里常组合使用:ARouter 做跨模块入口,Hilt 给模块内部或接口实现注入依赖。

// :user-api
interface UserService {
    fun currentUserId(): String?
}

// :feature-order 只依赖 user-api,不依赖 feature-user
class OrderViewModel(
    private val userService: UserService
) : ViewModel()

五、构建优化(你的兴趣点)

• 配置阶段优化:避免在配置期做耗时操作、用 configuration cache。
• configuration cache 边界:它缓存配置阶段产物,命中时可跳过配置阶段;但构建脚本、Version Catalog、gradle.properties、环境变量/系统属性读取、配置期文件读取、自定义插件逻辑等配置输入变化都会导致失效。采用前要修复 Gradle 报告的 configuration cache problems,不要只开开关。
• 增量编译 / 构建缓存:org.gradle.caching=true,复用未变模块的产物。
• 并行构建:org.gradle.parallel=true,多模块并行。
• 守护进程:Gradle Daemon 常驻避免 JVM 重启。
• KSP 替代 KAPT:KSP 直接分析 Kotlin 符号,比 KAPT(生成 Java stub)快很多。
• 模块化:拆模块 + implementation 隔离,减少改动的重编范围。
• AGP 升级:新版本构建性能持续优化。
• 产物优化:R8 裁剪、资源压缩、so 按 ABI 拆分(见 10、11 篇,你的强项)。

六、测试

• 单元测试:JUnit + Mockito/MockK(mock 依赖),测纯逻辑(ViewModel、UseCase)。
• 协程测试:runTest + TestDispatcher(StandardTestDispatcher/UnconfinedTestDispatcher),Turbine 测 Flow。
• UI 测试:Espresso(View)、Compose Test Rule(createComposeRule)。
• 测试金字塔:大量单元测试 + 适量集成 + 少量 UI 测试。
• 可测试性:依赖注入 + 接口抽象,让逻辑可替换 mock(见 08 篇架构)。

七、Android 版本适配(高频)

• 运行时权限(6.0+):危险权限动态申请;后续版本继续细分一次性权限、后台定位、照片/视频/音频等权限边界。
• 分区存储 Scoped Storage(10/11+):App 只能自由访问自己目录 + MediaStore,访问其他需 SAF;具体强制行为和兼容开关与 Android 10/11、targetSdk 有关,升级时要按官方行为变更表核对。
• 后台限制(8.0+):后台 Service 受限、隐式广播限制、用 WorkManager/JobScheduler;Android 12(API 31) 起对 target 31+ 的后台启动前台服务限制更严格,不满足例外会抛异常。
• 通知渠道(8.0+):必须建 NotificationChannel;Android 13(API 33) target 33+ 需要申请 POST_NOTIFICATIONS,用户拒绝后普通通知不可见,但前台服务仍会在系统规定位置保留可见性。
• targetSdk 升级:每次升级要处理对应行为变更,不要只改数字。
  • Android 12 / API 31:target 31+ 创建 PendingIntent 必须显式声明 FLAG_IMMUTABLE 或 FLAG_MUTABLE;后台启动 FGS、通知 trampoline、精确闹钟等也有新限制。
  • Android 13 / API 33:通知运行时权限、细分媒体权限、部分组件导出/Intent 安全要求需要排查。
  • Android 14 / API 34:target 34+ 前台服务必须声明合适的 foreground service type;隐式 Intent 发送到应用内部未导出组件、mutable implicit PendingIntent 等行为更受限制。
• 适配排查清单:先读官方 behavior changes → 全局搜索权限/通知/FGS/PendingIntent/存储/API 调用 → 加兼容分支和自动化测试 → 用灰度观察崩溃、ANR、权限拒绝率。
• 64 位要求:Google Play 强制 arm64,需提供 64 位 so。

高频面试题

Q1:implementation 和 api 区别? implementation 依赖不传递,只本模块可见,编译隔离、加快构建;api 会把依赖暴露给上层模块(传递依赖),扩大编译范围。优先 implementation,仅需对外暴露时用 api。

Q2:Gradle 构建有哪几个阶段?哪个容易成为瓶颈? 初始化(定模块)、配置(执行所有 build.gradle 建任务图)、执行(跑 Task)。配置阶段会执行所有模块脚本,模块多/脚本重时成为瓶颈,可用配置缓存优化。

Q3:为什么要组件化?模块间怎么通信? 编译解耦(加快构建)、并行开发、复用、独立调试。模块间不直接依赖,通过路由(ARouter)+ 接口下沉 + 依赖注入通信,避免循环依赖。

Q4:怎么优化 Gradle 构建速度? 开启构建缓存、并行构建、配置缓存、Daemon;用 KSP 替代 KAPT;模块化 + implementation 隔离减小重编范围;升级 AGP/Gradle。

Q5:KAPT 和 KSP 区别? KAPT 为兼容 Java 注解处理器会生成 Java stub,慢;KSP 是 Kotlin 原生符号处理,直接分析 Kotlin 代码,速度快数倍,Room/Hilt 等已支持。

Q6:分区存储是什么?带来什么变化? Android 10+ 限制 App 只能自由访问自己的外部目录和 MediaStore,访问其他文件需通过 SAF 或 MediaStore API,不能再随意读写整个外部存储,提升隐私。

Q7:targetSdk 升级要注意什么? 每个版本有行为变更需适配,而且很多只对达到对应 targetSdk 的 App 生效。重点排查权限、存储、后台启动、通知、PendingIntent、前台服务类型、隐式 Intent 等;做法是对照官方 behavior changes 建清单,搜索代码命中点,加兼容分支和回归测试,灰度观察崩溃/ANR/权限拒绝率。

Gradle 构建性能专题

“构建工具是提高工程效率的核心。深刻理解 Gradle 生命周期和缓存机制，才能在大型工程里解决‘为什么编译这么慢’的痛点。”

面试策略: 结合你负责 SDK 开发的背景，聊聊你在解决依赖冲突、优化模块化编译速度、甚至推动 KSP 替代 KAPT 等方面的实战经验。

一、Gradle 构建生命周期

Gradle 构建的核心是确定执行图并执行，主要分为三个阶段：

1. 初始化阶段 (Initialization): 决定哪些项目/模块参与构建，解析 settings.gradle(.kts)，创建 Project 实例。
2. 配置阶段 (Configuration): 执行所有参与构建的 build.gradle(.kts) 脚本，配置 Project 对象，最关键的是构建出 Task 的依赖有向无环图 (DAG)。
   • 优化点: 这一阶段是容易拖慢构建的地方。不要在脚本里写耗时的 IO 或网络操作。
3. 执行阶段 (Execution): 根据 DAG 确定执行顺序，执行具体的 Task 操作，生成构建产物。

二、Gradle 核心概念：Task、Plugin 与 Variant

• Task: 构建的最小工作单元。每个 Task 有输入 (Inputs) 和输出 (Outputs)。
  • 增量构建 (UP-TO-DATE): 当 Task 的 Inputs 和 Outputs 没有发生变化时，Gradle 会跳过此 Task，这是加快构建的核心机制。
• Plugin: 插件是 Task 的集合并封装了配置逻辑。AGP (Android Gradle Plugin) 就是将编译 Android 相关的 Tasks 注入到工程中。
• Variant (构建变体): 由 Build Type（如 debug/release）和 Product Flavor（如免费版/付费版）组合而成，影响最终输出的 APK/AAB 结构。

三、依赖管理与冲突解决

随着项目增长，依赖管理往往成为灾难，特别是传递依赖导致的冲突。

四、构建性能深度优化

构建优化通常分为“配置期“与“执行期“优化。

1. 开启 Configuration Cache：
   • 缓存配置阶段的 Task Graph。第二次构建时，如果 build.gradle 没有变化，直接跳过耗时的配置阶段。
   • 要求极高：脚本中不能读取外部不可追踪的状态、自定义 Task 必须声明清楚输入输出等。
2. 构建缓存 (Build Cache) 与并行 (Parallel)：
   • org.gradle.caching=true: 复用之前或者其他机器（远程构建缓存）编译好的 Task 输出。
   • org.gradle.parallel=true: 多核并行执行互相没有依赖的 Project/Task。
3. 守护进程 (Daemon) 与 JVM 参数：
   • 保证 Daemon 开启（默认已开启），复用 JVM 以减少启动时间和 JIT 预热开销。
   • 调整 org.gradle.jvmargs 给出充足的 Heap 空间。

五、KSP vs KAPT 与多模块治理

• KAPT (Kotlin Annotation Processing Tool):
  • 传统注解处理。需要生成 Java Stub 文件，然后让 Java 的 AP 去处理。这会导致 Kotlin 编译变慢，并拖累整体速度。
• KSP (Kotlin Symbol Processing):
  • 直接在 Kotlin 符号层面上解析注解，避免生成 Java Stub，构建速度能提升 2 倍甚至更多。目前 Room、Glide、Hilt 等都已支持。
• 多模块优化:
  • 将大仓拆分更细粒度的业务模块和基础模块。
  • 使用 implementation 严格进行模块间隔离，当修改底层模块的非公开 API 时，上层模块不会触发重新编译。

高频面试题

Q1: 为什么有时候修改了一行代码，整个项目都要重新编译？ 因为依赖隔离没做好。如果底层模块对外暴露了 API（使用了 api 声明依赖或者修改了 public 的方法签名），依赖它的上层模块在 ABI（应用二进制接口）发生变化时，都会触发重新编译。另外也可能是因为使用了不兼容增量编译的旧版 AP。

Q2: 讲讲 Gradle 中的 UP-TO-DATE 是怎么判断的？ Gradle 在执行 Task 前，会对比该 Task 的 Inputs（文件内容哈希、属性值等）和 Outputs（生成的文件）。如果两次构建的 Inputs 和 Outputs 的哈希值完全一致，说明没有改动，Task 就会被标记为 UP-TO-DATE，直接跳过执行。

Q3: KSP 相比 KAPT 为什么快那么多？ KAPT 为了复用 Java 的注解处理器，需要先解析 Kotlin 代码，生成临时的 Java Stub 文件，这涉及到类型的推导和转换，非常耗时。KSP 是原生为 Kotlin 设计的，直接访问 Kotlin 的编译器符号树（AST 的上层），不需要生成 Stub，省去了解析和转换的巨大开销。

易错点 / 追问

• 忽略 Configuration Cache 的报错: 强行开启但忽略不兼容警告，可能导致拿到旧配置，打出来的包是错的。
• 过度拆分模块: 模块化虽然能并行，但每个模块配置和处理也会引入额外开销，拆分太碎反而可能拖慢配置阶段。
• 滥用 api 代替 implementation: 图省事把依赖全写成 api，导致任何一个库的更新引发全工程重编。

CI/CD 与发布体系

“从代码提交到用户手里的安装包，中间的自动化流水线不仅是效率工程，更是质量把控的最后防线。”

面试策略: 讲清楚持续集成（CI）的核心质量卡点，以及持续交付/部署（CD）中的版本、签名和多渠道策略，这能展现你对工程闭环的把控力。

一、CI/CD 核心概念与工具

• CI (Continuous Integration, 持续集成): 开发者频繁提交代码，流水线自动触发编译、静态代码检查（Lint/SonarQube）和自动化测试。目标是尽早发现缺陷。
• CD (Continuous Delivery/Deployment, 持续交付/部署): 自动将打好的包发布到测试环境，或者打包带有生产环境签名的正式包上传到应用商店/分发平台。
• 常用工具:
  • Jenkins：老牌开源，可高度定制，适合企业内网部署。
  • GitLab CI / GitHub Actions：基于 YAML 配置文件直接存在代码库里（Pipeline as Code），开箱即用，越来越流行。

二、APK 与 AAB 构建体系

三、渠道包与版本策略

• 多渠道打包 (Flavors):
  • 国内通常需要向不同的应用商店（华为、小米、应用宝等）发布，使用 Flavor 或第三方工具（如 Walle/VasDolly）写入渠道标识，以便服务端统计各个渠道的激活率和转化率。
• 版本治理 (Version Code / Version Name):
  • versionCode 必须递增，用于系统判断是否允许覆盖安装。
  • versionName 只是展示给用户的字符串。在 CI 中，通常将 versionCode 与 Git commit count 或者 CI 系统的 Build Number 绑定，保证其唯一和自增。

四、安全签名与构建产物管理

• 签名安全:
  • 绝对不能把 Release Keystore 和密码放在代码库里。
  • CI 中通常使用系统注入环境变量（Secrets），构建时通过临时解密或安全文件服务来签名。
• 产物归档 (Artifacts):
  • 构建成功后，不仅要保留 APK/AAB，还要归档 Mapping 文件（混淆后的符号表）和 Native 符号表 (.so 的 debug symbol)。如果没有它们，线上的崩溃堆栈将是一本无字天书，无法定位问题。

五、灰度发布、降级与质量门禁

发布绝不是一键上线那么简单，需要配合严密的策略控制风险。

1. 自动化质量门禁 (Quality Gates):
   • PR (Pull Request) 阶段强制触发 CI。如果不满足：单元测试通过率 > 80%、静态扫描无 Critical 级警告，禁止合并代码。
2. 灰度发布 (Gray Release):
   • 先放量 1% 的用户，配合 APM 监控崩溃率、ANR 和核心业务指标。观察平稳后再放量 10%、50% 到全量。
3. 兜底与回滚:
   • 客户端发布覆水难收（旧版本无法撤回），必须要有热修复补丁（Hotfix）机制，或者通过配置中心下发开关进行功能降级，关闭引起崩溃的新功能。

高频面试题

Q1: AAB 相比 APK 有什么优势？如果国内应用商店不支持 AAB 怎么优化体积？ 优势：AAB 将打包和分发的职责分离，Google Play 会根据用户设备具体情况（如只需要 hdpi 图片、arm64-v8a 库、中文语言包）裁切出特定的 APK，大幅减少体积。 国内不支持 AAB 时：可以利用 Gradle 构建配置分别打包特定 ABI 的分包（APK Splits），或者使用资源混淆（AndResGuard）、动态下发非核心动态库和大型资源等方式优化。

Q2: 如何保证 CI 环境打包和本地开发打包的结果一致性？ 使用固定的基础镜像环境（Docker）；强制使用统一版本的 JDK 和 Gradle Wrapper；禁止在脚本中读取个人计算机的环境变量；版本号和依赖全部锁定版本。

Q3: 线上出现严重的崩溃，无法发新版（审核慢），有哪些应急预案？ 首先利用功能开关（Feature Toggle）从配置中心下发指令，关闭引发崩溃的入口（降级）；如果无法关闭，利用热修复（Tinker、Robust）下发补丁修复逻辑；同时对未升级用户的应用商店渠道包进行下架或暂停灰度放量。

易错点 / 追问

• Mapping 文件丢失: 打完包丢弃了本次构建的 mapping 文件，导致崩溃上报后无法解混淆，这是灾难性的工程事故。
• 混淆配置未同步: CI 开启了 R8 混淆但没有在测试环境验证，直接上生产，由于反射或 JNI 类被裁减导致秒退。
• 密钥泄露: 将签名文件或 API Key 随代码 Push 到了公网 Github，安全风险极高。

隐私合规与权限治理

“在强监管时代，因为隐私合规不达标导致 App 被全面下架的惨痛教训比比皆是。合规不再是边角料工作，而是生命线工程。”

面试策略: 结合你 SDK 开发的经历，强调你在收拢采集入口、治理第三方 SDK 以及设备标识符（OAID 等）演进上的经验。

一、隐私合规的“生死红线“

国内工信部和网信办、海外的 GDPR 对隐私保护的底线要求非常严苛，核心原则是：未经同意，不取一毫；最小必要，严禁滥用。

• 隐私弹窗: 用户首次打开 App 时，必须弹窗展示《隐私政策》和《用户协议》，在用户点击“同意“之前，绝对不允许执行任何代码去读取敏感信息或初始化敏感 SDK。
• 默认勾选: 注册/登录页面的协议同意框，绝不能默认帮用户打勾。
• 超范围收集: 不能因为是一个手电筒 App 就要求读取通讯录和位置信息，这违反“最小必要“原则。
• 频次限制: 不允许在后台高频次地（如每秒一次）获取用户位置或读剪切板。

二、Android 权限治理演进

Android 系统本身的权限管理也顺应合规趋势，逐年收紧：

三、设备标识符的演变与 OAID

作为做设备指纹出身的开发者，这块是你的强项：

• MAC 地址 / IMEI: 曾经用来唯一追踪用户的神器。随着隐私收紧，Android 10 以后非系统级应用彻底无法获取真实的 IMEI 和全局不变的 MAC 地址（系统返回全 0 或抛出异常）。
• Android ID: 恢复出厂设置或签名改变会发生变化。在 Android 8.0 之后，不同的 App 读到的同一个设备的 Android ID 甚至是不一样的（基于签名的作用域隔离）。
• OAID (匿名设备标识符):
  • 国内由于 Google 服务的缺失，由移动安全联盟 (MSA) 推出的替代方案。
  • 特性：用户可以在系统设置中手动重置 OAID。
  • 它满足了广告归因的需求，又给了用户重置追踪的权利，是目前国内合规体系下获取设备标识的主流手段。

四、第三方 SDK 合规治理

因为第三方 SDK 的违规采集导致主 App 被下架，这叫“背锅”。所以大型 App 会对接入的 SDK 进行严苛治理。

• 延迟初始化: 所有第三方 SDK（尤其是广告、推送、统计、风控）的初始化动作，必须放在隐私弹窗“同意”按钮的回调之后。
• 采集点收口: 收拢项目里的定位、剪切板、设备信息读取入口，封装成统一的 Manager 代理。在 Manager 中增加鉴权、缓存、频次控制和合规拦截。
• 静态扫描与字节码 Hook:
  • 对于不受控的第三方 SDK 或陈旧的 Jar 包，在打包阶段（或运行时阶段，利用 ASM 插件 或类似 Epic 的机制），对 TelephonyManager.getDeviceId() 等敏感 API 调用进行 Hook 或替换，在未同意隐私政策时返回空数据。

五、敏感行为的安全保障

• 剪切板滥用:
  • iOS 14 和 Android 12 开始，App 读取剪切板系统会在顶部弹出明显提示。
  • 如果应用为了淘口令等功能无脑轮询读取剪切板，会让用户极其反感甚至遭遇投诉。正确做法是切前台时且发现特定格式的文本才进行解析。
• 日志安全 / 脱敏:
  • 本地日志绝不允许明文打印用户的手机号、身份证、真实姓名、密码。必须进行脱敏（如 138****1234）或强加密。
• 权限被拒处理:
  • 不能因为用户拒绝了位置权限，就不让用户使用“扫一扫”功能，不能搞权限捆绑。

高频面试题

Q1: 在用户点击同意隐私政策前，App 到底能不能访问网络？ 不能。任何网络请求都会向外暴露用户的 IP 地址等基础设备信息，因此在严格合规要求下，在隐私弹窗同意前，不允许发起任何向外部的请求，更不能拉起各种后台 Service 提前预热 SDK。

Q2: 怎么防止项目中接入的第三方广告 SDK 在后台偷读用户剪切板或位置信息？

1. 商务层面: 选用正规、经过官方审核的版本，并在应用内隐私政策明确披露该 SDK。
2. 工程层面: 不在后台启动和保活该 SDK 所在的组件；通过 ASM 字节码插桩，在打包期间将该 SDK 调用敏感 API 的方法替换为我们自己的代理方法，在代理中加入合规状态判断和频次拦截。

Q3: Android 10+ 无法获取 IMEI 后，风控和广告归因怎么做？ 国内推荐使用 MSA 提供的 OAID 库获取匿名设备标识；海外使用 Google Advertising ID (AAID)。同时，风控系统转为采用弱特征组合设备指纹（通过分辨率、系统版本、传感器特征等计算生成），不再依赖单一的绝对不变标识符。

易错点 / 追问

• 粗暴对待权限拒绝: 用户拒绝权限后不断弹窗骚扰，或者直接 finish() 应用，这会导致极差体验并被商店警告。
• 缓存单次授权状态: 在 Android 11+ 把获得的权限记录在 SharedPreferences 中，下次直接用，结果权限已被系统回收导致崩溃。
• 过度索权: 开发图省事，不管用不用，先把 Manifest 里的权限申请一大堆，上架时很容易被拒。

登录鉴权与账号体系

“账号是所有业务的基石，一次优秀的登录系统设计，需要兼顾安全防护、无缝体验以及应对多设备、状态同步的复杂性。”

面试策略: 把这道题当作架构设计题来答。不要只讲发送密码存一下 token，要从 双 Token 体系、状态机控制、安全存储 三个维度，展现对登录流程严密性的思考。

一、Token 与鉴权基础 (OAuth2/JWT)

移动端通常不再使用传统的 Session-Cookie 模型（有 CSRF 风险和跨端限制），主流方案是基于 Token 的鉴权机制。

• JWT (JSON Web Token): 自包含的令牌，服务端签发后无需查询数据库即可校验（只要验证签名）。
  • 结构: Header（算法）+ Payload（用户 ID/过期时间）+ Signature（防篡改签名）。
  • 弱点: 一旦签发，在过期前服务端难以主动使其失效（除非引入黑名单，但这会失去 JWT 无状态的优势）。
• OAuth2 核心流程: 用于第三方授权登录（微信/Google 登录），获取 Access Token 来访问资源。

二、双 Token 体系与无感刷新

为解决 JWT 无法撤销与长期有效带来的安全风险，业界标准是采用 双 Token (Access Token + Refresh Token) 机制：

1. Access Token (AT): 生命周期极短（如 2 小时），每次网络请求放在 Header 中 (Authorization: Bearer <token>)。即使泄漏，风险时间也短。
2. Refresh Token (RT): 生命周期较长（如 30 天），仅用于获取新的 AT。绝不能在普通业务接口中传输。

无感刷新流程设计 (并发拦截控制)： 当业务请求收到 401 Unauthorized（AT 过期）时：

• 网络层拦截器捕获到 401。
• 挂起当前及后续其他需要鉴权的请求。
• 发起使用 RT 换取新 AT 的请求。
• 刷新成功后，保存新 token，并自动重试刚才挂起的业务请求。
• 如果 RT 也过期（返回特定错误），则清空本地登录状态，跳转到登录页。

三、登录状态机管理

客户端的登录状态往往很乱（如闪屏页、其他请求触发掉线），必须引入状态机或单向数据流进行集中管理。

未登录 (LoggedOut) 
  ↓ (输入账号密码/授权)
登录中 (LoggingIn) → 失败回 [未登录]
  ↓ (获取 Token 成功)
已登录 (LoggedIn) 
  ↓ (401触发刷新)
刷新中 (Refreshing) → 成功回 [已登录]，失败去 [未登录]

使用单一可信源（如全局的 StateFlow/LiveData）来分发当前状态，UI 根据这个状态决定是展示个人中心还是弹出登录框。避免到处散落 if (isLogin())。

四、本地安全存储与风险对抗

Token 是用户的钥匙，保存在本地必须做安全防护：

设备绑定与风控检查： 登录不仅仅是密码匹配。服务端通常还会结合你收集的设备指纹进行判定：异地登录、新设备登录、同一设备高频切换账号等，需要触发短信验证码、滑块验证等二次认证机制。

五、多设备登录与单点登录 (SSO)

• 单点登录 (SSO): 企业内部多 App 互通登录状态。通常由一个主应用/网页提供统一鉴权，返回临时 Ticket，其他端用 Ticket 去认证中心换自己的 Token。
• 多设备互踢:
  • 服务端维护一张 [用户ID - 设备ID - Token] 映射表。
  • 用户在 B 设备登录，服务端使得 A 设备的 Token 失效，或者通过 WebSocket/Push 主动推一条“踢出下线“指令给 A 设备。
  • A 设备收到通知，清空本地状态，弹窗提示“您的账号在其他设备登录“。

高频面试题

Q1: Access Token 和 Refresh Token 的机制是什么？为什么要用两个 Token？ 为了平衡安全与用户体验。单一长效 Token 泄漏风险极大且难以撤销；短效 Token 频繁过期会让用户反复登录体验极差。双 Token 用短效 Access Token 降低泄漏后的损失窗口，用长效 Refresh Token 实现静默续期，且 Refresh Token 只发往专门的刷新接口，截获概率低。

Q2: 在协程/RxJava 拦截器中，怎么处理多并发请求导致的多次 Token 刷新问题？ 利用并发锁或者协程 Mutex。当第一个 401 触发刷新时，上锁，后续的 401 请求判断正在刷新中，则挂起等待。刷新成功后，通知所有等待的请求用新 Token 重试；如果刷新失败，则全部抛出未登录异常跳转登录页。

Q3: App 卸载重装后，如何保持依然处于登录状态（免密登录）？ 通常通过将加密 Token 或者账号绑定凭证备份到系统级的机制中，如 Android 的 KeyChain、AccountManager，或者依靠读取稳定的硬件设备指纹作为辅助免密凭证。但出于安全合规考虑，现在的 App 大多重装后仍要求重新登录或进行验证码二次确认。

易错点 / 追问

• Token 存在内存中没有持久化: 导致 App 被系统杀进程重启后状态丢失。
• 未处理多进程的 Token 同步: 很多 App 有独立推送或后台进程，单进程刷新了 Token 没通知其他进程，导致 401 死循环。
• 退出登录未通知服务端: 本地清空了 Token，但 JWT 仍然没有过期，截获这段 JWT 的黑客仍能继续请求（应当让服务端将该 Token 暂时加入黑名单）。

支付订单与状态机

“支付业务的核心是‘绝不能丢钱，也绝不能多扣钱’。网络可能是不可靠的，但我们的系统必须是可靠的。”

面试策略: 在这部分重点体现你对分布式系统异常情况的理解。突出幂等性、重试、轮询、超时取消，以及状态机控制这五个关键武器。

一、客户端支付全链路流程

一次完整的第三方支付（如微信/支付宝）交互绝不是客户端拿着金额去请求 SDK 这么简单，它涉及三方交互：

1. 客户端发起订单: 客户端请求自己服务器，传递商品信息。
2. 服务端生成预支付单: 业务服务器调用微信/支付宝生成预支付交易单，将包含签名等核心信息的 PayInfo 返给客户端。
3. 客户端拉起收银台: 客户端使用 SDK，传入 PayInfo 唤起支付 App 完成支付。
4. 客户端获取同步结果: 支付 SDK 回调给客户端支付结果（成功/取消/失败）。此结果仅供 UI 展示参考，不能作为最终发货依据。
5. 服务端接收异步通知: 微信/支付宝服务器将真实的支付成功通知发给你的业务服务器。
6. 客户端轮询/长连同步真实结果: 客户端主动拉取或接收服务器推送，确认支付最终状态，展示成功页。

二、订单状态机设计

复杂业务中，订单绝不能只有“成功“和“失败“。必须用严谨的状态机约束状态流转，防止非法倒流（如“已取消“的订单被发货）。

           [待支付]
          /    |   \
 (超时未付)   (支付)  (用户主动取消)
    /          |        \
[已取消]    [支付中]     [已取消]
               |
      (服务端接收回调成功)
               |
           [已支付/待发货]
               |
           [已发货] → [已完成]

• 核心原则: 状态只能单向推进，或根据特定规则流转。客户端 UI 根据状态机的当前状态来渲染按钮（如：待支付展示“去支付“，已取消展示“重新购买“）。

三、网络异常与重试机制 (幂等性)

移动端面临弱网、断网、重切等各种网络异常。当发出“确认购买“请求，但遇到了网络超时，此时钱扣了吗？

• 幂等性 (Idempotency): 无论接口被调用多少次，产生的业务结果应该和调用一次相同。
• 防重点击机制:
  • 前端 UI 防止连点（按钮变灰/Debounce拦截）。
  • 核心防线在服务端: 客户端生成全局唯一的单号或携带防重 Token，服务端依赖数据库唯一索引或 Redis 分布式锁拦截重复请求。客户端重试时必须带上同样的 ID。

四、支付结果确认与轮询机制

如第一节所述，客户端 SDK 返回成功，不代表真的成功了（可能是网络劫持伪造的响应）。

• 确认机制: 支付完成后，客户端展示“支付确认中“的加载框。
• 轮询 (Polling):
  • 客户端定时向业务服务器发起请求查询订单真实状态（比如：延时 1s、2s、4s 递增查询，最多查询 5 次）。
• 兜底策略: 如果轮询一直未确认，不能告诉用户“支付失败“，应该提示“结果确认中，请稍后查看订单列表“。服务端会在后续收到异步通知时更正订单状态。

五、超时取消与库存回退

• 当订单处于“待支付“状态，业务逻辑往往已经预占了商品的库存。
• 如果用户迟迟不付，必须有超时取消机制（例如 15 分钟未支付自动关闭），释放占用的库存。
• 客户端倒计时: 倒计时的计算一定要以服务端返回的时间戳为基准，切勿使用客户端本地的 System.currentTimeMillis()，因为用户可以随便修改手机时间。

六、安全边界与反作弊

• 金额不可信: 客户端绝不能自己提交 amount=100 给支付 SDK。金额必须由业务服务端通过商品 ID 和促销规则计算生成，客户端只拿组装好的签名串。
• 拦截抓包与篡改: 防止用户抓包拦截服务端的预支付单，修改成别人的订单号或极小金额。这里结合第 20 篇提到的签名、HTTPS 双向校验和风控逻辑发挥。

高频面试题

Q1: 支付完 SDK 告诉客户端成功了，此时可以立刻更新本地状态为“已支付”并给用户发货吗？ 绝对不可以。客户端环境不可控，SDK 返回的结果可能被篡改（如破解包或劫持回调）。发货的唯一凭证是业务服务器收到微信/支付宝的官方异步回调校验成功。客户端结果只用于触发向服务端查询的动作。

Q2: 弱网下用户点击“立即支付”由于没有响应，狂点了三下，怎么保证不产生三个订单？

1. 客户端防重: 按钮点击后 disable，通过 RxBinding 或协程防抖。
2. 状态机控制: 本地记录正在请求中，不响应二次点击。
3. 服务端唯一防重: 客户端生成或服务端提前下发的 UUID 作为本次交易的凭据（幂等 Key），服务端收到多次相同 Key 的请求时，只处理一次，其余的直接返回旧订单信息。

Q3: 如果支付完成后回到 App，网络断了，无法轮询服务端拿到结果，应该怎么处理？ 展示“订单处理中”或“网络异常，稍后请在订单列表查看”。绝不能显示“支付失败”（万一钱扣了会引发严重客诉），也绝不能显示“支付成功”（万一真没成功则产生资损）。等待网络恢复后，用户进入订单列表时再次向服务器同步最新状态。

易错点 / 追问

• 倒计时依赖本地时间: 利用修改手机系统时间可以无限延长支付时间或卡出倒计时负数 bug。
• 本地订单状态与服务端不一致: 客户端由于进程被杀等原因错过状态流转，重入时一定要从服务器重新拉取当前最新状态机节点。
• 支付 SDK 冲突: 集成多方支付 SDK 导致依赖库冲突（通常通过 exclude 或使用精简版 SDK 解决）。

推送 / 长连接 / 保活

☆ 推送、长连接和保活经常和 Android 后台限制、厂商策略、功耗合规一起考。你的风控/对抗经验可以讲“知道边界、尊重系统、用监控验证“。

一、三类实时方案

二、WebSocket 心跳与重连

心跳不是越频繁越好。移动端要在实时性、功耗、网络切换、后台限制之间取舍。

sealed class SocketState {
    object Disconnected : SocketState()
    object Connecting : SocketState()
    object Connected : SocketState()
    data class Backoff(val retryAfterMs: Long) : SocketState()
}

重连策略:指数退避 + 网络恢复触发 + 前后台状态感知 + 最大重试保护。

三、系统推送:FCM 与国内厂商通道

• 海外优先 FCM。
• 国内通常接入小米/华为/OPPO/vivo/荣耀等厂商推送。
• 应用内长连接适合前台实时,系统推送适合后台触达。

四、Android 后台限制与保活边界

Android 8.0 以后后台 Service、隐式广播、后台执行都有严格限制。面试要强调合规策略:前台服务、WorkManager、厂商推送、用户可见任务,而不是无限拉活。

五、进程保活与拉活的现实策略

历史方案包括双进程守护、1 像素 Activity、JobScheduler、账号同步、厂商白名单等,很多已被系统或厂商限制。中级面试更看重你能否说明风险:耗电、合规、用户体验、应用商店审核。

六、排障与监控

关注连接成功率、平均在线时长、心跳超时、重连次数、消息到达率、厂商通道回执。

高频面试题

Q1:IM 为什么不能只靠推送? 答:推送适合后台触达,不保证强实时和完整双向通信;前台聊天通常需要长连接保证低延迟、顺序和 ACK。

Q2:心跳间隔怎么定? 答:根据 NAT 超时、服务端成本、功耗和业务实时性实验确定,并区分前后台/网络类型,不能拍脑袋固定 5 秒。

Q3:怎么回答保活问题才安全? 答:讲系统允许的前台服务、WorkManager、厂商推送和业务必要性;历史黑科技可以说明了解但不建议作为长期方案。

易错点 / 追问

• 不要承诺后台永远在线。
• 不要忽略厂商 ROM 差异。
• 不要把推送到达率问题全归因于客户端。

埋点与数据采集 SDK ☆

埋点 SDK 的价值不是“多采集”,而是“准、稳、少打扰、可合规”。 你有设备指纹/风控 SDK 背景,面试时可以把采集准确性、隐私边界、离线队列和宿主性能控制讲成工程亮点。

一、埋点体系:手动埋点与自动埋点

埋点用于理解用户行为、业务转化和产品质量。常见分为手动埋点、自动埋点和可视化埋点。

成熟方案通常是“手动埋点保证核心业务,自动埋点补足基础行为,服务端配置控制采样和开关”。SDK 要提供统一事件模型,例如 eventName、timestamp、sessionId、pageName、properties、device/app context。

{
  "event": "product_click",
  "time": 1710000000000,
  "page": "HomePage",
  "session_id": "s_abc",
  "properties": {
    "product_id": "masked-id",
    "position": 3
  }
}

二、曝光与点击采集

点击采集相对直观,但曝光采集更容易出错。曝光通常要求“元素进入可见区域 + 可见比例达到阈值 + 停留时间达到阈值 + 去重策略满足”。

自动点击埋点可通过 View.OnClickListener 包装、Window callback、字节码插桩等方式实现。工程上要尽量避免破坏宿主原有监听器,不要在主线程做复杂序列化,并允许业务对敏感控件关闭自动采集。

三、Crash 前日志与上下文采集

Crash 前日志用于回答“崩溃前用户做了什么、页面状态是什么、关键接口是否失败”。它不应无限制采集,而应维护一个轻量环形缓冲区。

1. 记录最近 N 条关键事件:页面进入/退出、点击、网络错误、业务状态变更、SDK 关键状态。
2. Crash 发生时将缓冲区快照随崩溃报告上传或落盘等待下次上传。
3. 日志字段脱敏,避免 token、手机号、身份证、精确定位等敏感数据进入崩溃上下文。
4. 控制大小,避免 crash report 过大影响上传成功率。

RingBuffer(size=100)
  -> page_view: Home
  -> click: PayButton
  -> api_error: /order/create 500
  -> sdk_state: queue_size=42
  -> crash: attach last 100 breadcrumbs

这种设计对排查线上问题很有价值,但要明确它是诊断上下文,不是完整行为录像。

四、批量上传、采样与本地队列

数据采集 SDK 不能每条事件都立即上报,否则会放大网络、电量和宿主性能成本。常见策略是本地入队、批量上传、失败重试、采样控制。

本地队列通常使用内存队列 + 持久化存储。写入要异步,并设置容量上限;超过上限时按优先级丢弃或采样,不能无限增长。进程退出、断网、弱网、服务端限流都要可恢复。

五、离线缓存与可靠性

离线缓存解决“用户断网或服务端不可用时事件不丢失”。但可靠性不是越强越好,因为无限保留会带来隐私、磁盘和上传风暴问题。

1. 容量上限:按条数、字节数、天数三重限制。
2. 过期清理:超过有效期的行为数据直接删除。
3. 分片存储:避免单个文件过大导致读写失败。
4. 幂等标识:每批事件带 batchId/eventId,服务端去重。
5. 启动削峰:App 启动后延迟上传,避免和冷启动抢资源。
6. 网络约束:按 Wi-Fi/蜂窝、前后台、低电量模式调整上传策略。

面试可以强调:采集 SDK 的“可靠”是有边界的可靠,要在数据完整性、用户体验、隐私合规和资源成本之间平衡。

六、隐私、合规与最小化采集

隐私是数据采集 SDK 的红线。设计时要把“采什么、为什么采、保存多久、给谁用、如何撤回”说清楚。

对于设备标识、IP、定位、剪贴板、通讯录等敏感能力,必须按法规和平台政策处理。SDK 不能绕过宿主隐私弹窗自行采集,也不能把业务传入的敏感参数原样写入日志。

七、宿主性能影响控制

宿主性能是埋点 SDK 能否长期接入的关键。优秀 SDK 要“默认轻量、可观测、可关闭”。

• 主线程控制:事件组装、序列化、加密、压缩、磁盘写入、网络请求都应放到后台线程。
• 内存控制:队列有上限,大字段截断,避免持有 Activity/View/Context 强引用。
• CPU 控制:批量压缩和加密要限频;自动曝光计算要节流。
• 网络控制:批量、采样、退避、前后台策略,避免高频小包。
• 启动控制:延迟初始化非关键模块,不要阻塞 Application onCreate。
• 可观测性:SDK 自身要上报队列长度、丢弃数、上传耗时、失败原因和资源占用。

对宿主来说,SDK 应提供远程开关、采样率、黑名单、最大缓存、上传周期等配置,当线上异常时可以快速降级。

高频面试题

Q1:手动埋点和自动埋点怎么选? 核心业务转化用手动埋点,因为语义准确、参数可控;页面浏览、基础点击、曝光可用自动埋点补充覆盖。大型项目通常混合使用,并通过配置中心控制开关和采样。

Q2:曝光埋点怎么避免重复和误报? 用可见比例、停留时长、页面可见状态和业务 ID 去重。RecyclerView 不能只按 position 去重,因为 item 会复用和移动;Fragment/ViewPager 也不能只看 onResume,要结合真实可见性。

Q3:埋点 SDK 如何保证离线不丢数据? 事件先进入内存队列并异步持久化,网络可用时批量上传;失败使用退避重试,每批带幂等 ID。与此同时设置容量、天数和优先级上限,避免无限缓存影响隐私和磁盘。

Q4:Crash 前日志怎么设计? 维护轻量环形缓冲区,记录最近页面、点击、接口错误和 SDK 状态;Crash 时附带快照。日志要脱敏、限长、限量,不能把它做成完整行为录屏或敏感数据仓库。

Q5:如何控制埋点 SDK 对宿主性能的影响? 主线程只做轻量入队,序列化/压缩/加密/IO/网络放后台;队列和缓存有上限;曝光计算节流;上传批量化、采样和退避;SDK 自身提供监控和远程降级开关。

易错点 / 追问

• 不要为了“数据完整”无限缓存,这会带来隐私、磁盘和上传风暴风险。
• 不要在隐私协议同意前启动非必要采集,也不要默认采集敏感字段。
• 不要在点击回调里同步写数据库或发网络请求,会直接伤害宿主性能。
• 追问“自动埋点为什么不准”:控件复用、动态 UI、页面可见性和业务语义缺失都会导致误差。
• 追问“采样会不会影响分析”:会,所以要按用户/会话稳定采样,并对关键错误或转化事件保留更高优先级。

主流第三方库

中级面试常问“X 库的原理“,尤其网络层和图片库。你做 SDK 偏底层,这些上层库要补实战理解。

一、OkHttp

Android 网络底座(Retrofit 默认基于它)。

• 核心:拦截器链(责任链模式)。请求依次经过拦截器:
  1. 应用拦截器(开发者添加,如加 header、log)。
  2. RetryAndFollowUp(重试、重定向)。
  3. Bridge(补全 header、gzip)。
  4. Cache(缓存)。
  5. Connect(建立连接)。
  6. 网络拦截器(开发者添加)。
  7. CallServer(真正发送收发)。
• 连接池(ConnectionPool):复用 TCP/HTTP 连接,常见默认配置是最多空闲连接约 5 个、保活约 5 分钟,但这是 OkHttp 版本/构造参数相关的可配置默认值。复用可减少 TCP/TLS 握手;HTTP/2 下同一连接还能多路复用多个 stream。
• 缓存:基于 HTTP 缓存语义(Cache-Control、ETag),磁盘 LRU。
• 分发器(Dispatcher):异步请求用线程池执行,控制最大并发和单 host 并发;常见默认值是 maxRequests=64、maxRequestsPerHost=5,可通过属性调整。WebSocket 等特殊连接是否计入限制要看版本文档。

OkHttp 请求链路与调优

val client = OkHttpClient.Builder()
    .dispatcher(Dispatcher().apply {
        maxRequests = 32
        maxRequestsPerHost = 8
    })
    .connectionPool(ConnectionPool(5, 5, TimeUnit.MINUTES))
    .build()

上面数字不是“最佳实践模板”,只是说明默认项可配置。真实项目要根据接口耗时、弱网、服务端限流、HTTP/2 支持和页面优先级做压测。

二、Retrofit

把 HTTP API 封装成 Kotlin/Java 接口。

• 核心:动态代理(Proxy.newProxyInstance)。create() 为接口生成代理对象,调用方法时被 InvocationHandler 拦截。
• 解析方法上的注解(@GET/@POST/@Query/@Body)生成 ServiceMethod/RequestFactory,构造 OkHttp 的 Request。
• CallAdapter:适配返回类型(Call、协程 suspend、Flow、RxJava)。协程版可理解为把 OkHttp Call 的异步回调桥接为挂起恢复,取消协程时也要取消底层 Call。
• Converter:序列化转换(Gson/Moshi/kotlinx.serialization),负责请求体/响应体和业务对象之间的转换。
• 协程用法:接口方法加 suspend 直接返回 data class,无需 Call.enqueue。

Retrofit 三层扩展点

面试回答结构:先说“接口不是实现类,Retrofit 用动态代理拦截方法调用”;再说“注解生成请求,Converter 负责数据转换,CallAdapter 负责返回类型”;最后补“底层网络仍交给 OkHttp”。

三、图片库(Glide / Coil)

• 三级缓存:内存(ActiveResources 弱引用 + LruCache)→ 磁盘(DiskLruCache)→ 网络。
• 生命周期绑定:Glide 官方 API 强调传入 Activity/Fragment 后会随宿主销毁自动清理请求。实现层面常见解释是注入无 UI 的 RequestManagerFragment/等价生命周期组件监听宿主生命周期;这是库内部实现,版本可能演进,面试要说“实现层面”。Coil 基于协程 + Lifecycle,更贴近 Kotlin 项目。
• Bitmap 复用(BitmapPool):复用可复用的 Bitmap 内存,减少频繁分配和 GC;硬件位图、尺寸/配置不匹配时不一定能复用。
• Coil:Kotlin 优先、协程实现、API 轻量,Compose 场景友好;Glide 生态成熟、缓存/变换/集成丰富,老项目更多。
• 优化点:指定尺寸(override)避免加载过大图、合适的缓存策略、占位图。

图片加载机制拆解

RecyclerView 中的核心不是“手动取消所有请求”,而是每次绑定都给可复用 View 发起新请求或显式 clear。Glide 文档也提示,如果某个复用 View 不再加载图片,要 clear() 避免旧请求回调把旧图设置回来。

四、序列化库

• Gson:反射解析,易用但运行时反射有性能开销、不感知 Kotlin 默认值/空安全(可能给非空字段塞 null)。
• Moshi:Square 出品,支持 codegen(编译期生成 adapter,无反射),对 Kotlin 友好。
• kotlinx.serialization:Kotlin 官方,编译期插件生成,类型安全、多平台、无反射,新项目推荐。@Serializable 注解。

五、其他常见库

• EventBus:发布订阅解耦组件通信。现代趋势用 Flow/SharedFlow 替代(类型安全、可控生命周期)。
• 依赖注入:Hilt(主流,见 07)、Koin(纯 Kotlin、运行时解析、轻量但无编译期校验)。DI 的核心价值不是“少写 new”,而是把对象创建、作用域和替换点显式化,方便测试和模块解耦。
• 协程之外的响应式:RxJava(老项目多,操作符丰富但学习曲线陡),新项目协程 + Flow 已基本替代。

高频面试题

Q1:OkHttp 的拦截器链是什么设计模式?顺序? 责任链模式。顺序:应用拦截器 → RetryAndFollowUp → Bridge → Cache → Connect → 网络拦截器 → CallServer。每个拦截器处理后调 chain.proceed 传递。

Q2:应用拦截器和网络拦截器区别? 应用拦截器在最外层,只调用一次,能看到原始请求(重定向前),不一定有网络;网络拦截器在 Connect 之后,可能多次调用(重定向/重试),能看到真实网络请求和中间响应。

Q3:Retrofit 的核心原理? 动态代理。create() 用 Proxy 为接口生成代理对象,调用方法时 InvocationHandler 拦截,解析注解构造 OkHttp Request,经 CallAdapter 适配返回类型(协程/Call/Flow),Converter 做序列化。

Q4:Retrofit 怎么支持协程的? 方法加 suspend 后,Retrofit 内部把 OkHttp Call 的异步回调适配成协程挂起恢复,常见实现会通过类似 suspendCancellableCoroutine 的方式处理取消,直接返回结果或 Response,无需手动 enqueue。

Q5:Glide 如何感知生命周期防止泄漏? Glide.with(activity/fragment) 返回与宿主生命周期绑定的 RequestManager,宿主停止/销毁时可暂停或清理请求。实现层面常见解释是注入无 UI 的 RequestManagerFragment/生命周期组件监听回调,但这是库内部实现细节,回答时不要说成永久 API 契约。

Q6:Glide 三级缓存? 内存(活动资源弱引用 + LruCache)、磁盘(DiskLruCache,可缓存原图或转换后)、网络。命中内存最快,逐级回退。

Q7:Gson 在 Kotlin 里有什么坑? Gson 用反射、不走构造函数,可能绕过 Kotlin 的非空检查和默认值,给非空字段赋 null 导致后续 NPE。建议用 Moshi 或 kotlinx.serialization。

Android 安全与逆向 ☆

这一篇是你最大的差异化武器。 你做设备指纹/风控 SDK,签名、加固、抓包对抗、反调试、反 Hook 是你的本行,而 99% 的应用开发者答不出。

面试策略:投支付/金融/出海/风控相关团队时,主动把话题引到这里。即便普通应用岗,聊到安全也能瞬间拉开差距。这是你“从底层来做应用“叙事的最强证据。

一、APK 签名机制

签名用于校验 APK 完整性 和 来源可信(防篡改、防二次打包)。

• 签名校验流程:安装时系统校验签名;App 运行时也可自校验签名防二次打包。
• 面试可讲:v1 的弱点(可往 META-INF 塞文件不破坏签名,渠道包/恶意注入利用过),v2 怎么解决。

二、加固与脱壳

• 加固目的:防止反编译拿到源码逻辑(DEX)、保护 so、防调试。
• DEX 加固演进(防御/面试视角):

• 脱壳对抗的原则比较:从防守角度看,一代主要防静态读取,二代把攻击面缩到关键方法还原时机,三代把“读代码”变成“理解私有虚拟机”。面试只讲原理、成本和风险,不提供可执行流程。
• so 加固:字符串加密、符号裁剪/隐藏、控制流混淆、完整性校验、必要时对极少数核心算法做 native 侧虚拟化。注意 native 保护会引入兼容性、性能、可观测性问题,上线前要做灰度和崩溃监控。
• 你的发言点:讲你在 SDK 里怎么做 so 保护、防止采集逻辑被逆向,这是真实经验。

三、混淆

• R8 / ProGuard:重命名类/方法/字段(a.a())、删除无用代码、内联、优化。keep 规则保留反射/JNI 入口。
• 资源混淆:AndResGuard,缩短资源路径减体积 + 增加逆向难度。
• 控制流混淆 / 字符串加密:打乱执行流、加密敏感字符串(API key、URL),运行时解密。
• 注意:JNI 注册的 native 方法、反射调用的类、序列化字段要 keep,否则崩溃。

四、抓包与防抓包(你的实战领域)

• 抓包原理:Charles/Fiddler/mitmproxy 装根证书做中间人,解密 HTTPS;Wireshark 抓底层包。
• 防御手段:
  • SSL Pinning(证书锁定):App 内置服务端证书/公钥指纹,只信任它,系统装的抓包根证书无效。
  • 双向认证(mTLS):服务端也校验客户端证书。
  • 代理检测:检测系统代理设置、VPN。
  • 抓包工具检测:检测 Charles/Fiddler 证书、特征。
• Pinning 的边界:Pinning 能显著提高 MITM 成本,但不能作为单点方案。高安全 App 会把校验、参数签名、重放防护、完整性校验和风控策略组合使用,并把关键决策放到服务端复核。
• 关键参数加密 / 签名:即便被抓包,请求参数加密 + 签名(sign)防篡改和重放。

五、反调试与反 Hook

• 定位:反调试/反 Hook 不是为了单点阻止分析,而是为高价值动作提供环境风险信号,辅助服务端做分级处置(放行、二次验证、降级、拒绝)。

• 反 Hook:关注“是否有运行时插桩/代理/代码段异常”的风险信号,而不是背具体工具特征。工具特征随版本变化,面试要强调多信号融合 + 服务端决策 + 误伤控制。
• 完整性校验:运行时校验 APK 签名、DEX/so 的 CRC,发现篡改就退出/降级。
• 官方安全能力补充:可结合 Play Integrity API / Play Protect / App Access Risk 等信号判断“是否为可信 App、可信设备、低风险环境”。这些能力也不是唯一依据,更适合接入服务端风控策略,并对高价值动作按风险分层处理。
• 这是你的主场:这些正是设备指纹/风控 SDK 的核心对抗,你能讲实战细节,面试官会眼前一亮。

六、运行环境检测(风控核心)

• Root 检测:su 文件、Magisk、busybox、可写系统分区、危险属性。
• 模拟器检测:特征文件、CPU 架构(x86)、传感器缺失、IMEI/型号特征、qemu 痕迹。
• Hook 框架检测:见上(Frida/Xposed)。
• 多开/虚拟环境检测:包路径异常、进程名、/proc 特征。
• 设备指纹:综合硬件/系统/行为特征生成唯一标识——你的本职工作,可深入讲采集维度、稳定性、对抗篡改。

七、数据安全

• 敏感数据存储:用 EncryptedSharedPreferences / KeyStore 加密,不明文存 token。
• Android Keystore:密钥存于硬件安全模块(TEE/StrongBox),不出安全区。
• 传输安全:HTTPS + Pinning + 参数加密 + 签名防重放。

高频面试题

Q1:APK v1 和 v2 签名区别?v1 有什么漏洞? v1 是 JAR 签名,逐文件摘要、不保护 ZIP 元数据,可往 META-INF 加文件不破坏签名(被渠道包/注入利用)。v2 对整个 APK 签名块做校验,保护整体、更快、防篡改强。v3 加密钥轮转,v4 基于 Merkle 树支持增量。

Q2:App 加固有哪几代?VMP 为什么最难逆向? 一代整体 DEX 加密、二代方法抽取/按需还原、三代 VMP 指令虚拟化。VMP 把标准指令语义迁移到私有虚拟机里,分析者即使看到运行过程也需要理解解释器和私有指令语义,成本最高;但它也有性能、体积、兼容性成本,通常只保护核心逻辑。

Q3:什么是 SSL Pinning?它的边界是什么? 客户端只信任内置的服务端证书或公钥指纹,降低伪造 CA/MITM 抓包风险。边界是客户端逻辑始终可能被动态分析或篡改,所以高安全场景要组合 native 加固、完整性校验、参数签名、重放防护和服务端风控复核,不能只靠 Pinning 一个点。

Q4:怎么检测 App 被 Frida hook 了? 从防御视角看,可以收集运行时注入、模块加载、堆栈、代码段完整性、异常调试状态等风险信号;但具体特征会随工具版本和加载方式变化,不能当最终结论。工程上应多信号融合、服务端分级处置,并控制误伤。

Q5:怎么做反调试? 常见方向包括调试状态、关键路径时间异常、运行环境完整性和 native 代码段完整性等。回答重点不是背某个检测点,而是说明它们都有版本/ROM/工具差异和误判风险,应作为风控信号参与分级决策,而不是单点封禁。

Q6:设备指纹怎么提升唯一性和稳定性?(你的本职) 综合多维特征(硬件、系统、网络、行为)加权生成,容忍部分特征变化(系统升级/重置),并结合风险信号对抗篡改和模拟。讲清采集维度、降级策略、对抗思路即可——这是你的真实经验,放开讲。

Q7:敏感数据怎么安全存储? 用 Android Keystore 管理密钥(存 TEE/StrongBox 硬件区),用 EncryptedSharedPreferences 加密存储,绝不明文存 token/密钥,传输再叠加 HTTPS + Pinning。

进阶补充:逆向工具链、Native 分析与面试表达边界

常见工具链定位

Native so 分析要点

关注 ELF 结构、导出符号、JNI_OnLoad、RegisterNatives、字符串/xref、PLT/GOT、反调试和混淆。符号被 strip 后,可结合字符串、常量、调用图和动态 trace 恢复语义。

OWASP Mobile Top 10 视角

面试中可以从不安全存储、不安全通信、认证授权、代码篡改、逆向风险、敏感信息泄露等角度回答安全设计。

设备可信与服务端风控

客户端检测只能提高攻击成本,不能单独作为信任根。更稳妥的设计是客户端采集信号 + 服务端风控决策 + 灰度策略 + 异常监控。

面试表达边界

讲原理、风险、检测、防护和合规边界;避免细讲绕过步骤、攻击脚本和可直接滥用的操作流程。

**追问:**为什么不能只靠客户端反调试?因为攻击者控制运行环境,客户端防护只能增加成本,关键决策要在服务端完成。

移动安全防护体系

移动安全的成熟回答不是“客户端能绝对防住攻击”,而是“客户端提高成本、服务端做最终风控、工程上控制误伤和可用性”。本章只从防御、检测、加固和风险联动角度讲,不提供绕过脚本或攻击步骤。

一、防护体系的分层模型

移动端运行在用户可控设备上,不能把客户端当绝对可信根。合理体系要分层:

面试总原则:客户端防护用于“采集信号 + 提高成本 + 延迟攻击”,高价值决策必须回到服务端风控。

二、root / hook / emulator / Frida 检测

环境检测的目标不是“发现一个特征就封禁”,而是形成风险画像。常见信号包括:

• Root 检测:su/Magisk 痕迹、危险系统属性、可写系统分区、异常 SELinux 状态、敏感目录权限。
• Hook 检测:可疑框架痕迹、异常类加载、调用栈异常、运行时注入迹象、关键函数入口完整性异常。
• 模拟器检测:硬件/传感器缺失、qemu/虚拟化特征、CPU/ABI、设备型号和系统属性组合异常。
• Frida 检测:进程、端口、模块、线程名、内存映射、行为时序等风险信号的组合观察。

防御表达要强调限制:

1. 特征会随工具版本变化,需要远端配置和灰度。
2. 厂商 ROM、测试设备、无障碍工具、企业 MDM 可能造成误判。
3. 检测结果应是风险分,而不是唯一封禁依据。
4. 高风险动作可触发二次验证、降级、延迟处理或服务端复核。

三、SSL Pinning 与传输防护

SSL Pinning 是客户端内置服务端证书或公钥指纹,连接时只信任预期身份,降低用户安装恶意根证书后的 MITM 风险。

传输安全组合拳:
HTTPS/TLS
  + SSL Pinning(证书或公钥)
  + 请求参数签名(timestamp + nonce + body digest)
  + 重放防护(服务端校验 nonce/时间窗)
  + 高风险接口二次校验(设备风险 + 行为风险)

工程注意:

• Pinning 要支持证书轮换,通常 pin 公钥或准备备份 pin。
• 失败策略要区分网络异常、证书异常、系统时间错误和灰度问题。
• 不要把密钥硬编码当唯一保护,客户端 secret 只能提高成本。
• 与 OkHttp/Network Security Config/自研网络层配合时要有测试覆盖。

四、R8/ProGuard 与 Java/Kotlin 层加固

R8/ProGuard 的基础能力是压缩、优化、混淆,安全收益是增加静态分析成本并减少可读语义。

• 重命名:类、方法、字段改短名,降低可读性。
• 优化/内联:删除无用代码、调整调用结构,增加还原成本。
• keep 规则:反射、序列化、JNI、路由、依赖注入入口必须保留,否则线上崩溃。
• mapping 管理:mapping 是还原崩溃栈的关键敏感资产,要按版本安全保存。

Kotlin 项目还要注意 data class、默认参数、协程状态机、序列化字段、Compose/Hilt/Room 生成代码的 keep 要求。安全和稳定必须平衡,不能为了“混得更狠”破坏运行时反射/JNI 入口。

五、native obfuscation、shell/packing 与完整性检查

Native 层常用于保护高价值算法、设备指纹采集、加解密和环境检测。常见防护包括符号隐藏、字符串加密、控制流混淆、关键代码段完整性校验和少量核心逻辑 native 化。

shell/packing(加壳/壳保护)的概念是把 DEX/so 或关键方法以加密、抽取、虚拟化等方式保护,运行时再加载或还原。面试只需讲目标、成本和边界:

• 目标:提高静态反编译和批量篡改成本。
• 成本:启动耗时、兼容性、崩溃定位、包体积、灰度复杂度。
• 边界:代码运行时总要以某种形式执行,客户端无法做到绝对不可分析。

完整性检查常覆盖 APK 签名、安装来源、DEX/资源摘要、so 代码段、关键配置和运行时内存异常。对热修复、插件化、渠道包要设计白名单和版本策略,否则容易误伤。

六、device trust 与服务端风控联动

设备可信可以结合 Play Integrity API、厂商安全能力、设备指纹、账号行为、网络环境和业务风险事件。关键是把客户端信号传给服务端做统一决策。

客户端采集:
  设备指纹 + 完整性 + root/hook/emulator + 网络风险 + 行为摘要
        ↓
服务端风控:
  规则/模型评分 + 账号历史 + 交易/登录上下文 + 黑白名单
        ↓
分级处置:
  放行 / 降级 / 二次验证 / 延迟审核 / 拒绝 / 人工复核

服务端联动的优势:

• 风控策略可动态调整,不依赖发版。
• 能结合账号、设备、IP、行为、交易等多维数据。
• 可以做灰度、AB、阈值回滚和误伤监控。
• 客户端只上报必要风险信号,避免暴露完整策略细节。

七、安全工程化与合规边界

安全防护要纳入工程流程,不是临上线才加检测点。

• 威胁建模:识别登录、支付、设备绑定、优惠券、风控 SDK 等高价值资产。
• 分级防护:普通页面不应引入高成本防护,核心链路才做更强检测和加固。
• 可观测性:记录风险命中、误伤、崩溃、性能影响和策略版本。
• 隐私合规:设备指纹和环境信号要遵守最小必要、告知同意、用途限定和数据安全要求。
• 应急响应:证书轮换、密钥泄露、加固兼容性事故、误封回滚都要有预案。

面试表达边界:讲检测、防护、限制、误伤控制和服务端风控,不要讲绕过流程、攻击脚本、hook 代码或可直接复现的利用步骤。

高频面试题

Q1:客户端 root/hook/Frida 检测能完全防住攻击吗? 不能。客户端处于用户可控环境,检测只能提高成本并提供风险信号。工程上应多信号融合、服务端风控决策、灰度策略和误伤监控,不能单点封禁。

Q2:SSL Pinning 的作用和边界是什么? 作用是降低伪造 CA、中间人抓包和传输篡改风险。边界是客户端校验逻辑仍可能被分析或篡改,所以要结合请求签名、重放防护、完整性校验和服务端风险联动。

Q3:R8/ProGuard 和加壳有什么区别? R8/ProGuard 主要做压缩、优化、重命名混淆,属于基础构建能力;加壳/packing 更强调加密、抽取、运行时加载或虚拟化,保护更强但兼容性、性能和排障成本更高。

Q4:为什么安全决策要放服务端? 因为客户端环境不可完全可信,本地策略容易被分析和篡改。服务端能结合账号、设备、行为、IP、历史风险等多维信息,动态调整风控策略并控制误伤。

Q5:怎么在面试中安全地讲 Frida 检测? 只讲防御视角:运行时注入、模块、线程、堆栈、内存映射、代码完整性等风险信号的组合;强调特征变化、误判、服务端分级处置。不要提供 hook 脚本或绕过步骤。

易错点 / 追问

• 不要承诺“客户端绝对安全”,正确说法是提高攻击成本并联动服务端风控。
• 不要把 root、hook、emulator 任一单点命中当封禁依据,要考虑误伤和灰度。
• SSL Pinning 要考虑证书轮换和失败策略,否则可能造成大面积不可用。
• 混淆/加固要和 crash 符号化、mapping 管理、性能监控一起设计。
• 设备指纹和环境检测涉及隐私合规,必须遵守最小必要和用途限定。

NDK 与 JNI ☆

这是你的强项,也是你的差异化武器。 一般应用开发者只会调用别人的 so,你能独立写 SDK。这一篇帮你把这份功底结构化成面试语言,在三面/技术亮点环节碾压竞争者。面试讲这块时要主动、自信、深入。

一、JNI 基础与类型映射

JNI(Java Native Interface)是 Java/Kotlin 与 C/C++ 互调的桥梁。

类型映射

方法签名

格式 (参数)返回值,如 (ILjava/lang/String;)V 表示 (int, String) -> void。用 javap -s 可查看签名。

二、引用管理(高频深挖)

JNI 有三种引用,管理不当会泄漏或崩溃:

• 局部引用(Local Reference):默认创建的引用(如 FindClass、NewObject 返回值)。方法返回后自动释放,不能跨方法/线程缓存。JNI 规范保证进入 native 方法前至少可创建 16 个局部引用;ART/设备上的引用表容量和扩展行为可能不同,不要把“512”当通用契约。循环中大量创建不释放仍可能 ReferenceTable overflow —— 要及时 DeleteLocalRef,或用 EnsureLocalCapacity / PushLocalFrame 管理容量。
• 全局引用(Global Reference):NewGlobalRef 创建,跨方法/线程有效,必须手动 DeleteGlobalRef 否则泄漏。用于缓存常用 jclass、jobject。
• 弱全局引用(Weak Global Reference):NewWeakGlobalRef,不阻止 GC。使用前推荐通过 NewLocalRef 提升成强局部引用,若返回 NULL 说明对象已回收;单纯 IsSameObject(ref, NULL) 只能做瞬时判断,之后仍可能被 GC。

实战经验(面试可讲):缓存 jclass/jmethodID 用全局引用提升性能;在 native 循环处理数组时注意局部引用释放,避免引用表溢出。

// 批量处理对象数组:用 local frame 一次释放本轮临时引用
for (jsize i = 0; i < count; i += 64) {
    if (env->PushLocalFrame(64) < 0) return; // OOM pending
    for (jsize j = i; j < count && j < i + 64; ++j) {
        jobject item = env->GetObjectArrayElement(array, j);
        // ... 使用 item ...
    }
    env->PopLocalFrame(nullptr); // 释放本 frame 内局部引用
}

三、JNIEnv 与 JavaVM、线程

• JavaVM:进程唯一,代表整个虚拟机,可跨线程共享。
• JNIEnv:线程私有,每个线程一份,不能跨线程缓存使用。
• native 线程访问 JVM:在 native 自己创建的线程里要调用 Java,必须先 JavaVM->AttachCurrentThread 拿到该线程的 JNIEnv,线程退出前 DetachCurrentThread,否则可能造成线程相关资源泄漏。由 JVM 调进 native 的线程已经 attached,通常不应随意 detach。
• 拿 JavaVM 的方式:JNI_OnLoad 回调里保存全局 JavaVM 指针。

JavaVM* g_vm;
jint JNI_OnLoad(JavaVM* vm, void*) {
    g_vm = vm;                       // 保存,供后续线程 attach
    return JNI_VERSION_1_6;
}
// native 线程中:
JNIEnv* env;
g_vm->AttachCurrentThread(&env, nullptr);
// ... 调用 Java ...
g_vm->DetachCurrentThread();

更稳的工程写法是 RAII 包一层,确保异常路径/提前 return 也会 detach:

class ScopedJniEnv {
public:
    explicit ScopedJniEnv(JavaVM* vm) : vm_(vm) {
        if (vm_->GetEnv(reinterpret_cast<void**>(&env_), JNI_VERSION_1_6) == JNI_EDETACHED) {
            attached_ = (vm_->AttachCurrentThread(&env_, nullptr) == JNI_OK);
        }
    }
    ~ScopedJniEnv() {
        if (attached_) vm_->DetachCurrentThread();
    }
    JNIEnv* get() const { return env_; }
private:
    JavaVM* vm_ = nullptr;
    JNIEnv* env_ = nullptr;
    bool attached_ = false;
};

四、静态注册 vs 动态注册

• 静态注册:按命名约定 Java_包名_类名_方法名 命名 native 函数,运行时按名查找。缺点:函数名长、首次调用需查找、暴露包名(易逆向)。
• 动态注册:在 JNI_OnLoad 里用 RegisterNatives 把 Java 方法和 native 函数指针映射注册。优点:函数名自由、效率高、隐藏映射关系(更安全,SDK/加固常用)。

static JNINativeMethod methods[] = {
    {"nativeFoo", "(I)I", (void*)foo_impl},
};
env->RegisterNatives(clazz, methods, 1);

面试可讲:做 SDK/对抗时用动态注册隐藏 native 入口,增加逆向难度——这是你风控背景的天然加分点。

动态注册要检查 FindClass、RegisterNatives 返回值和 pending exception;注册失败如果继续运行,后续 Java 调 native 会变成难定位的 UnsatisfiedLinkError。

五、native 调用 Java 与异常

• 调用流程:FindClass → GetMethodID/GetStaticMethodID → CallXxxMethod。
• 异常处理:JNI 调用后若 Java 抛异常,native 不会中断,必须 ExceptionCheck/ExceptionOccurred 检查并 ExceptionClear,否则后续 JNI 调用行为未定义。

六、native crash 捕获(你的强项可深讲)

• native 崩溃(SIGSEGV/SIGABRT)不走 Java 的 try/catch,默认直接挂掉进程。
• 捕获方式:注册信号处理器(sigaction) 捕获 SIGSEGV、SIGABRT、SIGBUS 等,在 handler 里 dump 寄存器、调用栈(unwind)、maps。
• 成熟方案:Google Breakpad / Crashpad、字节的 xCrash。它们生成 minidump,符号化后定位。
• 难点:信号处理器中只能调用 async-signal-safe 函数;栈展开(unwind)需结合 .eh_frame/.ARM.exidx;符号化需保留带符号 so。
• 工程流程:线上包可 strip 符号减体积,但 CI/符号服务器必须保存同 build-id 的未裁剪 so;拿到 tombstone/minidump 后用 addr2line、ndk-stack 或 Breakpad/Crashpad 工具映射到函数、文件和行号。

七、CMake / ABI / so

• 构建:CMakeLists.txt + externalNativeBuild;add_library、target_link_libraries、find_library(log)。
• ABI:arm64-v8a(主流)、armeabi-v7a(老设备)、x86/x86_64(模拟器)。abiFilters 控制打包哪些,通常只留 arm64-v8a 减体积。
• so 加载:System.loadLibrary("name") 加载 libname.so,触发 JNI_OnLoad。
• 现代 C++:RAII(资源随对象析构释放)、智能指针(unique_ptr 独占 / shared_ptr 共享 / weak_ptr 防循环引用)、移动语义(std::move 转移资源所有权)。NDK 用这些写出更安全的 native 代码。

现代 C++ 在 NDK 里的落地

struct GlobalRefDeleter {
    JavaVM* vm;
    void operator()(jobject ref) const {
        if (!ref) return;
        ScopedJniEnv scoped(vm);
        scoped.get()->DeleteGlobalRef(ref);
    }
};

using UniqueGlobalRef = std::unique_ptr<_jobject, GlobalRefDeleter>;

移动语义陷阱:std::move 只是强制把对象当右值,真正移动取决于类型是否实现移动构造/赋值;对还要继续读取的对象不要随手 move。JNI 场景中尤其要避免把 JNIEnv*、局部引用这类线程/生命周期受限资源包装后跨线程 move。

高频面试题

Q1:JNI 的局部引用和全局引用区别?什么时候会引用表溢出? 局部引用方法返回或 local frame 弹出后释放、不可跨线程;规范保证至少 16 个局部引用,具体容量/扩展行为看 VM 实现,不要死记 512。全局引用需手动 DeleteGlobalRef、可跨线程缓存。循环中大量创建局部引用不及时 DeleteLocalRef/PushLocalFrame,就可能触发 ReferenceTable overflow。

Q2:JNIEnv 和 JavaVM 区别?native 线程怎么调 Java? JavaVM 进程唯一可共享;JNIEnv 线程私有不可跨线程。native 自建线程要调 Java,需先 AttachCurrentThread 拿当前线程的 JNIEnv,线程退出前 DetachCurrentThread;从 Java 调进来的线程已经 attached,不要误 detach。

Q3:静态注册和动态注册区别?为什么 SDK 喜欢动态注册? 静态按 Java_包名_方法名 命名约定查找;动态用 RegisterNatives 在 JNI_OnLoad 注册函数指针映射。动态注册函数名自由、效率高、隐藏入口映射,增加逆向难度,适合 SDK/加固。

Q4:native 崩溃为什么 Java 的 try/catch 抓不到?怎么捕获? native 崩溃是 OS 信号(SIGSEGV 等),不经过 JVM 异常机制。需注册 sigaction 信号处理器捕获,在 handler 中 dump 栈和寄存器,用 Breakpad/xCrash 生成 minidump 后符号化定位。

Q5:JNI 调用 Java 方法后为什么要检查异常? JNI 调用若使 Java 抛异常,native 代码不会自动中断,异常处于 pending 状态,此时继续调用其他 JNI 函数行为未定义。必须 ExceptionCheck 后 ExceptionClear 处理。

Q6:为什么大多 App 只打包 arm64-v8a? 现代设备基本都是 arm64,只留 arm64-v8a 可显著减小 so 体积;armeabi-v7a 仅老设备需要。按 ABI 拆分 + App Bundle 动态下发是体积优化常用手段。

Q7:智能指针怎么选?(现代 C++) 独占所有权用 unique_ptr;确实有共享所有权才用 shared_ptr(引用计数有成本);打破 shared_ptr 循环引用用 weak_ptr。默认优先 unique_ptr 和 RAII,把 JNI 全局引用、fd、native buffer 等资源包装进析构函数,避免裸 new/delete 和异常路径泄漏。

NDK Native 调试与 Crash 定位 ☆

Native 能力是你的差异化强项,但面试要讲成“稳定性与诊断能力”,不是炫底层。 本章把 JNI 引用、线程 attach、RegisterNatives、so 加载、ABI/CMake、tombstone、addr2line、ndk-stack、RAII 和 native 泄漏串成一套线上排障语言。

一、JNI 引用与线程模型复盘

Native 崩溃和泄漏里很大一部分来自 JNI 生命周期误用。引用类型要和生命周期严格匹配。

JNIEnv* 是线程私有的,不能跨线程保存;JavaVM* 进程唯一,可以保存后在 native 线程里 AttachCurrentThread 获取当前线程的 JNIEnv*,线程结束前 DetachCurrentThread。

class ScopedAttach {
public:
    explicit ScopedAttach(JavaVM* vm) : vm_(vm) {
        if (vm_->GetEnv(reinterpret_cast<void**>(&env_), JNI_VERSION_1_6) == JNI_EDETACHED) {
            attached_ = (vm_->AttachCurrentThread(&env_, nullptr) == JNI_OK);
        }
    }
    ~ScopedAttach() {
        if (attached_) vm_->DetachCurrentThread();
    }
    JNIEnv* env() const { return env_; }
private:
    JavaVM* vm_ = nullptr;
    JNIEnv* env_ = nullptr;
    bool attached_ = false;
};

面试高频追问是“为什么不能保存 JNIEnv 到全局变量”:因为它绑定当前线程,换线程使用会导致未定义行为甚至崩溃。

二、RegisterNatives、so 加载与初始化顺序

Native 方法注册分静态注册和动态注册。工程 SDK 更常用 RegisterNatives,在 JNI_OnLoad 中集中绑定 Java 方法和 C/C++ 函数。

UnsatisfiedLinkError 常见原因包括:没有打包对应 ABI 的 so、System.loadLibrary 名称错误、native 方法签名不匹配、R8 混淆改了 Java native 方法名、依赖库加载失败。定位时先看 logcat 的 linker 错误和 ABI 路径,再查 JNI_OnLoad 返回值和注册日志。

三、ABI、CMake 与构建产物

ABI 决定 so 能在哪类 CPU 上运行。现代 Android 主流是 arm64-v8a,但模拟器、老设备和第三方 SDK 可能需要其他 ABI。

cmake_minimum_required(VERSION 3.22)
project(native_demo)

add_library(native_demo SHARED native_demo.cpp)
find_library(log-lib log)
target_link_libraries(native_demo ${log-lib})