IM即时通讯开发之Android内存泄漏监控

对于Android平台的应用程序来说，内存优化一直是个热门话题，与传统PC应用程序不同，Android上的应用一旦出现各种异常时系统默认会以最严厉的“崩溃”方式反馈给用户，如果处理不当，将严重影响用户体验。

丛所周之，移动设备的软硬件资源无法与传统PC相提并论（至少目前是这样），因而开发人员在编写应用时，需要有更多技巧、更精深的技术来应对各种局面。这其中尤以内存OOM（内存溢出）等涉及内存泄漏这样的问题最为常见。

先来谈谈内存泄漏的监控机制

内存泄露：简单来说对象由于编码错误或系统原因，仍然存在着对其直接或间接的引用，导致系统无法进行回收。内存泄露，容易留下逻辑隐患,同时增加了应用内存峰值与发生OOM的概率。它属于bug issue,是我们一定要修改的。下面是造成内存泄露的一些常见原因，但是如何建立一套发现内存泄露、解决内存泄露的闭环方案，才是我们工作的重点。

监控方案

Square的开源库leakcanry是一个非常不错的选择,它通过弱引用方式侦查Activity或对象的生命周期，若发现内存泄露自动dump Hprof文件，通过HAHA库得到泄露的最短路径，最后通过notification展示。

内存泄露判断与处理的流程如下图 ，各自运行的进程空间(主进程通过idlehandler，HAHA分析使用的是单独的进程)：

事实上，通过对leakcanry做简单的定制，我们就可以实现以下一个内存泄露监控闭环。 

内存泄露后的挽救措施

Activity泄漏会导致该Activity引用到的Bitmap、DrawingCache等无法释放，对内存造成大的压力，挽救措施是指对于已泄漏Activity，尝试回收其持有的资源，泄漏的仅仅是一个Activity空壳，从而降低对内存的压力。

做法也非常简单，在Activity onDestory时候从view的rootview开始，递归释放所有子view涉及的图片，背景，DrawingCache，监听器