1. Android内存管理概述
大家好，我是你们的老朋友。今天咱们聊聊Android内存管理。
说实话，我做了这么多年Android系统优化，内存这块踩过的坑真不少。你想想看，一个App动不动就几百兆，系统内存就那么大，怎么分？怎么管？这背后其实有一套完整的机制。
1.1 Android系统架构：内存管理的基石
先看整体架构。Android系统从上到下分几层：
- 应用层：咱们写的App，跑在ART虚拟机上
- Framework层：AMS、WMS这些系统服务
- Native层：C/C++写的库，比如SurfaceFlinger
- 内核层：Linux Kernel，真正的内存管家
我习惯把内存管理比作一个小区物业。内核是物业经理，管着所有资源。Framework是楼栋管家，协调各家需求。App就是住户，申请、使用、释放内存。
关键点：每一层都有自己的内存管理策略。上层出问题，下层兜底。下层压力大，上层就得收敛。
1.2 内存管理的重要性
为什么内存管理这么重要？说白了，手机就那么多内存。你多用一点，别人就少用一点。
我在项目中遇到过这样一个场景：某款手机在后台同时运行微信、支付宝、淘宝，结果前台游戏直接卡成PPT。为什么？后台App把内存吃光了，系统只能频繁触发LMK（Low Memory Killer）杀进程。
内存管理做不好，后果很直接：
- 卡顿：频繁GC导致掉帧
- 闪退：OOM直接崩溃
- 耗电：内存不足导致CPU频繁唤醒
- 体验差：App被系统杀掉，用户回来还得重新加载
我的建议：做性能优化，先从内存入手。内存稳了，CPU、IO、功耗问题往往迎刃而解。
1.3 内存泄漏 vs 内存溢出
这两个概念，很多人容易搞混。我刚开始做Android时也犯过迷糊。
| 对比项 | 内存泄漏 | 内存溢出 |
|---|---|---|
| 本质 | 对象无法被GC回收 | 申请内存超过可用上限 |
| 表现 | 内存占用持续增长 | 直接崩溃，报OOM |
| 原因 | 长生命周期对象持有短生命周期引用 | 一次性申请太多，或泄漏累积 |
| 后果 | 慢慢耗尽内存 | 瞬间爆炸 |
举个例子。内存泄漏就像水龙头没关紧，一滴一滴地漏。内存溢出就像你拿个杯子去接瀑布，直接冲垮。
注意：内存泄漏是内存溢出的重要诱因。很多OOM问题，追根溯源都是泄漏导致的。
1.4 常见的内存泄漏场景
我总结了几种高频泄漏场景，都是我在项目中亲手抓过的：
- 静态变量持有Activity引用
- 内部类/匿名内部类隐式持有外部类引用
- Handler未及时移除Message
- 注册的监听器未反注册
- 单例对象持有Context
嗯，这里要注意。很多开发者觉得「我代码写完了，跑起来没问题啊」。但内存泄漏是慢性病，不会立刻发作。
我曾经接手过一个项目，App运行半小时后必崩。用MAT一分析，发现一个静态HashMap里存了成千上万个Activity引用。为什么？因为开发者用了一个全局的EventBus，注册了没反注册。
1.5 如何判断是否存在内存问题
别靠感觉，靠数据。我常用的方法：
- Profiler：看内存曲线是否持续上升
- dumpsys meminfo：看进程内存分布
- LeakCanary：自动检测泄漏
- MAT：分析heap dump
核心指标：如果App在正常操作下，内存占用只增不减，那基本可以断定有泄漏。
1.6 本章小结
这一章咱们聊了Android内存管理的整体框架。说白了，内存管理就是「申请-使用-释放」的循环。但实际做起来，远比想象中复杂。
下一章，我会带大家深入ART虚拟机，看看GC到底是怎么工作的。为什么有时候GC会卡顿？怎么优化？咱们到时候细聊。
记住一句话：内存管理不是锦上添花，而是雪中送炭。做不好，再好的功能也是白搭。
课后思考：你手头的项目，有没有内存只增不减的现象？试着用Profiler跑一遍，看看结果。