浅谈Android应用的内存优化及Handler的内存泄漏问题

一、Android内存基础
物理内存与进程内存
物理内存即移动设备上的RAM，当启动一个Android程序时，会启动一个Dalvik VM进程，系统会给它分配固定的内存空间（16M,32M不定），这块内存空间会映射到RAM上某个区域。然后这个Android程序就会运行在这块空间上。Java里会将这块空间分成Stack栈内存和Heap堆内存。stack里存放对象的引用，heap里存放实际对象数据。
在程序运行中会创建对象，如果未合理管理内存，比如不及时回收无效空间就会造成内存泄露，严重的话可能导致使用内存超过系统分配内存，即内存溢出OOM，导致程序卡顿甚至直接退出。

内存泄露（Memory Leak）
Java内存泄漏指的是进程中某些对象（垃圾对象）已经没有使用价值了，但是它们却可以直接或间接地引用到gc roots导致无法被GC回收。Dalvik VM具备的GC机制（垃圾回收机制）会在内存占用过多时自动回收，严重时会造成内存溢出OOM。

内存溢出OOM
当应用程序申请的java heap空间超过Dalvik VM HeapGrowthLimit时，溢出。
注意：OOM并不代表内存不足，只要申请的heap超过Dalvik VM HeapGrowthLimit时，即使内存充足也会溢出。效果是能让较多进程常驻内存。

如果RAM不足时系统会做什么？
Android的Memory Killer会杀死优先级较低的进程，让高优先级进程获取更多内存。

Android系统默认内存回收机制

进程优先级：Foreground进程、Visible进程、Service进程、Background进程、Empty进程;
如果用户按Home键返回桌面，那么该app成为Background进程；如果按Back返回，则成为Empty进程
ActivityManagerService直接管理所有进程的内存资源分配。所有进程要申请或释放内存都需要通过ActivityManagerService对象。
垃圾回收不定期执行。当内存不够时就会遍历heap空间，把垃圾对象删除。
堆内存越大，则GC的时间更长

二、优化
Bitmap优化
Bitmap非常消耗内存，而且在Android中，读取bitmap时， 一般分配给虚拟机的图片堆栈只有8M，所以经常造成OOM问题。所以有必要针对Bitmap的使用作出优化：

图片显示：加载合适尺寸的图片，比如显示缩略图的地方不要加载大图。
图片回收：使用完bitmap，及时使用Bitmap.recycle()回收。
问题：Android不是自身具备垃圾回收机制吗？此处为何要手动回收。
Bitmap对象不是new生成的，而是通过BitmapFactory生产的。而且通过源码可发现是通过调用JNI生成Bitmap对象（nativeDecodeStream()等方法）。所以，加载bitmap到内存里包括两部分，Dalvik内存和Linux kernel内存。前者会被虚拟机自动回收。而后者必须通过recycle()方法，内部调用nativeRecycle()让linux kernel回收。
捕获OOM异常：程序中设定如果发生OOM的应急处理方式。
图片缓存：内存缓存、硬盘缓存等
图片压缩：直接使用ImageView显示Bitmap时会占很多资源，尤其当图片较大时容易发生OOM。可以使用BitMapFactory.Options对图片进行压缩。
图片像素：android默认颜色模式为ARGB_8888，显示质量最高，占用内存最大。若要求不高时可采用RGB_565等模式。图片大小：图片长度*宽度*单位像素所占据字节数
ARGB_4444：每个像素占用2byte内存
ARGB_8888：每个像素占用4byte内存 （默认）
RGB_565：每个像素占用2byte内存
对象引用类型

强引用 strong：Object object=new Object()。当内存不足时，Java虚拟机宁愿抛出OOM内存溢出异常，也不会轻易回收强引用对象来解决内存不足问题；
软引用 soft：只有当内存达到某个阈值时才会去回收，常用于缓存；
弱引用 weak ：只要被GC线程扫描到了就进行回收；
虚引用
如果想要避免OOM发生，则使用软引用对象，即当内存快不足时进行回收；如果想尽快回收某些占用内存较大的对象，例如bitmap，可以使用弱引用，能被快速回收。不过如果要对bitmap作缓存就不要使用弱引用，因为很快就会被GC回收，导致缓存失败。
关于java对象引用类型，具体可参加本人另一篇文章
池 pool

对象池：如果某个对象在创建时，需要较大的资源开销，那么可以将其放入对象池，即将对象保存起来，下次需要时直接取出使用，而不用再次创建对象。当然，维护对象池也需要一定开销，故要衡量。
线程池：与对象池差不多，将线程对象放在池中供反复使用，减少反复创建线程的开销。

三、Handler内存泄漏分析及解决
1、介绍
首先，请浏览下面这段handler代码：

public class SampleActivity extends Activity { private final Handler mLeakyHandler = new Handler() {  @Override  public void handleMessage(Message msg) {   // ...   } }}

在使用handler时，这是一段很常见的代码。但是，它却会造成严重的内存泄漏问题。在实际编写中，我们往往会得到如下警告：

  In Android, Handler classes should be static or leaks might occur.
那么，handler是如何造成内存泄漏的呢？

2、分析
（1）、Android角度
当Android应用程序启动时，framework会为该应用程序的主线程创建一个Looper对象。这个Looper对象包含一个简单的消息队列Message Queue，并且能够循环的处理队列中的消息。这些消息包括大多数应用程序framework事件，例如Activity生命周期方法调用、button点击等，这些消息都会被添加到消息队列中并被逐个处理。
另外，主线程的Looper对象会伴随该应用程序的整个生命周期。

然后，当主线程里，实例化一个Handler对象后，它就会自动与主线程Looper的消息队列关联起来。所有发送到消息队列的消息Message都会拥有一个对Handler的引用，所以当Looper来处理消息时，会据此回调[Handler#handleMessage(Message)](http://developer.android.com/reference/android/os/Handler.html#handleMessage(android.os.Message)方法来处理消息。

（2）、Java角度
在java里，非静态内部类 和 匿名类 都会潜在的引用它们所属的外部类。但是，静态内部类却不会。

（3）、泄漏来源
请浏览下面一段代码：

public class SampleActivity extends Activity { private final Handler mLeakyHandler = new Handler() {  @Override  public void handleMessage(Message msg) {   // ...  } } @Override protected void onCreate(Bundle savedInstanceState) {  super.onCreate(savedInstanceState);  // Post a message and delay its execution for 10 minutes.  mLeakyHandler.postDelayed(new Runnable() {   @Override   public void run() { /* ... */ }  }, 1000 * 60 * 10);  // Go back to the previous Activity.  finish(); }}

当activity结束(finish)时，里面的延时消息在得到处理前，会一直保存在主线程的消息队列里持续10分钟。而且，由上文可知，这条消息持有对handler的引用，而handler又持有对其外部类（在这里，即SampleActivity）的潜在引用。这条引用关系会一直保持直到消息得到处理，从而，这阻止了SampleActivity被垃圾回收器回收，同时造成应用程序的泄漏。
注意，上面代码中的Runnable类--非静态匿名类--同样持有对其外部类的引用。从而也导致泄漏。

3、泄漏解决方案
首先，上面已经明确了内存泄漏来源：

只要有未处理的消息，那么消息会引用handler，非静态的handler又会引用外部类，即Activity，导致Activity无法被回收，造成泄漏；
Runnable类属于非静态匿名类，同样会引用外部类。
为了解决遇到的问题，我们要明确一点：静态内部类不会持有对外部类的引用。所以，我们可以把handler类放在单独的类文件中，或者使用静态内部类便可以避免泄漏。
另外，如果想要在handler内部去调用所在的外部类Activity，那么可以在handler内部使用弱引用的方式指向所在Activity，这样统一不会导致内存泄漏。
对于匿名类Runnable，同样可以将其设置为静态类。因为静态的匿名类不会持有对外部类的引用。

public class SampleActivity extends Activity { /**  * Instances of static inner classes do not hold an implicit  * reference to their outer class.  */ private static class MyHandler extends Handler {  private final WeakReference<SampleActivity> mActivity;  public MyHandler(SampleActivity activity) {   mActivity = new WeakReference<SampleActivity>(activity);  }  @Override  public void handleMessage(Message msg) {   SampleActivity activity = mActivity.get();   if (activity != null) {    // ...   }  } } private final MyHandler mHandler = new MyHandler(this); /**  * Instances of anonymous classes do not hold an implicit  * reference to their outer class when they are "static".  */ private static final Runnable sRunnable = new Runnable() {   @Override   public void run() { /* ... */ } }; @Override protected void onCreate(Bundle savedInstanceState) {  super.onCreate(savedInstanceState);  // Post a message and delay its execution for 10 minutes.  mHandler.postDelayed(sRunnable, 1000 * 60 * 10);  // Go back to the previous Activity.  finish(); }}

4、小结
虽然静态类与非静态类之间的区别并不大，但是对于Android开发者而言却是必须理解的。至少我们要清楚，如果一个内部类实例的生命周期比Activity更长，那么我们千万不要使用非静态的内部类。最好的做法是，使用静态内部类，然后在该类里使用弱引用来指向所在的Activity。