Android内存优化是我们性能优化工作中比较重要的一环，这里其实主要包括两方面的工作：
优化RAM，即降低运行时内存。这里的目的是防止程序发生OOM异常，以及降低程序由于内存过大被LMK机制杀死的概率。另一方面，不合理的内存使用会使GC大大增多，从而导致程序变卡。 优化ROM，即降低程序占ROM的体积。这里主要是为了降低程序占用的空间，防止由于ROM空间不足导致程序无法安装。
本文的着重点为第一点，总结概述降低应用运行内存的技巧。在这里我们不再细述PSS、USS等概念与Android应用的内存管理，如对这部分内容感兴趣，可自行阅读文末的参考文章。
内存泄露的检测与修改
内存泄露：简单来说对象由于编码错误或系统原因，仍然存在着对其直接或间接的引用，导致系统无法进行回收。内存泄露，容易留下逻辑隐患,同时增加了应用内存峰值与发生OOM的概率。它属于bug issue,是我们一定要修改的。
下面是造成内存泄露的一些常见原因，但是如何建立一套发现内存泄露、解决内存泄露的闭环方案，才是我们工作的重点。
一. 内存泄露的监控方案
Square的开源库leakcanry是一个非常不错的选择,它通过弱引用方式侦查Activity或对象的生命周期，若发现内存泄露自动dump Hprof文件，通过HAHA库得到泄露的最短路径，最后通过notification展示。
内存泄露判断与处理的流程如下图 ，各自运行的进程空间(主进程通过idlehandler，HAHA分析使用的是单独的进程)：
微信在leakcanry推出之前已经有了自己的内存泄露监控体系，与leakcanry大致有以下的区别：
在微信中，对于4.0以上的机型也是采用通过注册ActivityLifecycleCallbacks接口，对于4.0以下的机型我们会尝试反射ActivityThread中的mInstrumentation对象。当然，现在微信也改成只支持android-15以上，美美哒。 leakcanry尽管使用了idlehandler与分进程，但是dumphprof依然会造成应用明显的卡顿(SuspendAll Thread)。而在三星等一些手机，系统会缓存最后一个Activity，所以在微信，我们采取了更严格的检测模式，即泄露三次确认以及经过5个新建的Activity，确保不是由于系统缓存的原因造成。 在微信中，当发现疑似内存泄露时会弹出对话框，当我们主动点击时才会去做dumpHprof以及上传Hprof快照的操作，而是否误报、泄露链等分析工作也是放于服务器端。
事实上，通过对leakcanry做简单的定制，我们就可以实现以下一个内存泄露监控闭环。
二. 对系统内存泄露的Hack Fix
AndroidExcludedRefs列出了一些由于系统原因导致引用无法释放的例子，同时对于大多数的例子，都会提供建议如何通过hack的建议去修复。在微信中，对TextLine、InputMethodManager、AudioManger、android.os.Message也采用了类似Hack的方式(详细可看参考资料)。
三. 通过兜底回收内存
Activity泄漏会导致该Activity引用到的Bitmap、DrawingCache等无法释放，对内存造成大的压力，兜底回收是指对于已泄漏Activity，尝试回收其持有的资源，泄漏的仅仅是一个Activity空壳，从而降低对内存的压力。
做法也非常简单，在Activity onDestory时候从view的rootview开始，递归释放所有子view涉及的图片，背景，DrawingCache，禁用词语器等等资源，让Activity成为一个不占资源的空壳，泄露了也不会导致图片资源被持有。
…
…
Drawable d = iv.getDrawable();
if (d != null) {
d.setCallback(null);
}
iv.setImageDrawable(null);
...
...
总的来说，我们不是只懂得一些内存泄露解决方法就可以，更重要的是通过日常测试与监控，得到内存泄露检测与修改的一整套闭环体系。
降低运行时内存的一些方法
当我们能确保应用中不会出现内存泄露时，我们需要一些其他的方法来降低运行时的内存。更多的时候，我们其实只希望降低应用发生OOM的概率。
Android OOM：
| 
注册
登录
