结果因为妹纸公司临时有事，她不得不回公司一趟…然后我也只能宅家里了，既然妹纸不在家，刚好最近一直在为项目做内存泄漏的优化工作，那就来写一点个人总结好了。

什么是内存泄漏

对于不同的语言平台来说，进行标记回收内存的算法是不一样的，像Android（Java）则采用GC-Root的标记回收算法。下面这张图就展示了Android内存的回收管理策略（图来自Google 2011的IO大会）

图中的每个圆节点代表对象的内存资源，箭头代表可达路径。当圆节点与GC Roots存在可达路径时，表示当前资源正被引用，虚拟机是无法对其进行回收的（如图中的黄色节点）。反过来，如果圆节点与GC Roots不存在可达路径，则意味着这块对象的内存资源不再被程序引用，系统虚拟机可以在GC过程中将其回收掉。

有了上面的内存回收的栗子，那么接下来就可以说说什么是内存泄漏了。从定义上讲，Android（Java）平台的内存泄漏是指没有用的对象资源任与GC-Root保持可达路径，导致系统无法进行回收。举一个最简单的栗子，我们在Activity的onCreate函数中注册一个广播接收者，但是在onDestory函数中并没有执行反注册，当Activity被finish掉时，Activity对象已经走完了自身的生命周期，应该被资源回收释放掉，但由于没有反注册，此时Activity和GC-Root间任然有可达路径存在，导致Activity虽然被销毁，但是所占用的内存资源却无法被回收掉。类似的栗子其实有很多，不一一例举了。

泄漏的源头了解完内存泄漏的理论知识后，再来归类一下内存泄漏的源头。这里我将其归位以下三类：

自身编码引起

由项目开发人员自身的编码造成。

第三方代码引起

这里的第三方代码包含两类：第三方非开源的SDK和开源的第三方框架。

系统原因

由Android系统自身造成的泄漏，如像WebView、InputMethodManager等引起的问题，还有某些第三方ROM存在的问题。

泄漏的定位

内存泄漏不像闪退的BUG，排查起来相对要比较困难些，比较极端的情况是当你的应用OOM了才发现存在内存泄漏问题，到了这种情况才去排查处理问题的话，对用户的影响就太大了。为此，我们能够在编码中尽早发现到问题就不要拖到上线之后才去填坑，下面介绍一些我比较常用排查内存泄漏的工具。

静态代码分析工具——Lint

Lint是Android Studio自带的工具，使用姿势很简单Analyze -> Inspect Code然后选择想要扫面的区域即可

对可能引起泄漏的编码，Lint都会进行温馨提示。

这里只是抛砖引玉的介绍Lint，实际上玩法还有很多，大家可以自行拓展学习。除了Lint外，还有像FindBugs、Checkstyle等静态代码分析工具也是很不错的。

严苛模式——StrictMode

StrictMode是Android系统提供的API，在开发环境下引入可以更早的暴露发现问题。官方文档链接在下面（需要科学上网）：

https://developer.android.com/reference/android/os/StrictMode.html

以官网的示例代码为栗子，一般StrictMode只在测试环境下启用，到了生产环境就会进行关闭，通常我们都会借助BuildConfig.DEBUG来实现。

启用StrictMode后，在过滤日志的地方加上StrictMode的过滤Tag，如果手机连接着电脑进行开发，定期观察一下StrictMode这个Tag下的日志，一般你看到一大堆红色告警的Log，就需要好好排查一下是否跟内存泄漏有关了。

LeakCanary

Square公司出品的内存分析工具，官方地址如下：

https://github.com/square/leakcanary/

LeakCanary和Stri