第1章 课程介绍与目标：对象泄漏导致ANR，数据保护场景的特殊性
1.1 什么是ANR？对象泄漏怎么引发的？
ANR（Application Not Responding）说白了就是你的App卡死了。系统给你5秒，你没处理完输入事件，就直接弹个窗口问用户「继续等待还是关闭」。用户的选择往往是「关闭」——这体验你懂的。
传统上大家觉得ANR是因为主线程做了耗时操作：比如网络请求、大文件读写、数据库操作。嗯，这些确实容易引发，但还有一个很隐蔽的原因——对象泄漏导致的内存压力。
对象泄漏本身不直接卡主线程，但泄漏累积会让GC（垃圾回收）越来越频繁。当GC达到一定阈值，会触发Stop-The-World的并发标记或压缩阶段。这时候所有线程都得停下来等GC做完。主线程自然也被冻结了。
我曾在项目中遇到过这样一个案例：一个加密数据服务，每次启动都创建一个巨大的安全缓冲区对象，然后因为某些回调没注销，这个对象始终被全局持有。用户反馈说「App用久了就会卡死」，一开始大家都怀疑是网络问题。后来我用Profiler一查，发现GC每秒触发3-4次，每次停顿200ms以上。嗯，这就是典型对象泄漏导致的ANR。
1.2 数据保护场景的特殊挑战
数据保护往往涉及加密、解密、序列化、安全上下文传递。这些环节相比普通业务逻辑，更容易埋下对象泄漏的隐患。为什么？你想想看：
- 加密对象生命周期复杂：密钥对象、Cipher实例、SecureRandom，哪些应该复用，哪些必须及时销毁？稍不注意就泄漏。
- 安全回调持有引用：很多安全框架使用回调或监听器模式，比如SSL握手完成回调、密钥生成回调。如果注册后忘记取消，就会导致外部对象被长生命周期对象持有。
- 序列化与反序列化：数据保护需要把对象转成加密流，再读回来。过程中临时对象（如ByteArrayOutputStream、CipherOutputStream）若未正确关闭，内部缓冲区就一直占用内存。
我见过一个项目，数据保护模块用了一个全局的ConcurrentHashMap来缓存加密上下文。每次新请求都往里面放，但移除的逻辑写漏了分支。结果这个Map越来越大，里面的对象全都泄漏了。线上ANR率一度飙升到1.2%。
1.3 本节课的目标
通过这一章节，我希望你建立清晰的认知：
- 掌握对象泄漏→ANR的完整链路：从代码级泄漏到GC停顿，再到主线程卡死。
- 理解数据保护场景的特殊性：为什么传统排查思路在这里常常失效。
- 学会系统化的调优方法：不是头痛医头，而是从架构设计、代码规范、监控工具多个维度入手。
说白了，这门课不是教你怎么写代码不泄漏，而是教你在数据保护这种高风险场景下，如何用最短的时间定位并修复泄漏导致的ANR。我会拿出一些真实项目里的经验（当然脱敏处理了），咱们一步步拆解。
我个人的习惯是：遇到ANR先不急着看代码，先问自己一句话——「这个ANR是GC导致的，还是业务逻辑超时导致的？如果是GC，那泄漏点大概率在内存增长的模块里。」这个判断，能帮你节省至少一半的排查时间。
1.4 两类ANR的对比
为了方便后续排查，这里整理了一个对比表格，你可以在实际工作中参考：
| 维度 | 传统耗时ANR | 对象泄漏ANR |
|---|---|---|
| 触发原因 | 主线程执行耗时操作（网络、IO、计算） | GC频繁停顿导致主线程被挂起 |
| 内存特征 | 通常内存正常，甚至偏低 | 堆内存持续增长，GC频繁 |
| 堆栈现象 | 卡在具体业务方法（如Socket.connect） | 卡在GC方法（如DaVinci GC的mark阶段） |
| 复现难度 | 较易，通常有规律操作 | 较难，往往需要一定时间或特定场景触发 |
| 数据保护场景 | 较少，除非加解密直接在主线程做 | 常见，加密对象泄漏、安全回调持有引用 |
GC 或 HeapTaskDaemon 相关，那十有八九是内存泄漏。如果卡在具体的业务代码，再去查耗时操作。
接下来，我画了一张流程图，把这个章节的核心逻辑整理了一下——从对象泄漏到ANR，以及数据保护场景下特有的风险环节。你结合着看，思路会更清晰。
这张图里左侧的三个绿色节点，就是数据保护场景里最容易出现泄漏的「三座大山」。它们会直接导致堆内存增长，然后沿着红色链路一路发展到ANR。我在后面的章节里会针对每一个点给出具体的排查方法和代码示例，包括如何用Android Studio的Memory Profiler找到泄漏的KeyStore实例，以及怎么用LeakCanary自动检测安全回调泄漏。
这一章我们先把全景搭起来。不用急，后面的内容会越来越硬核。你先把这张图印在脑子里，后面分析具体案例的时候，就知道每一个异常现象到底对应哪个环节了。