浅谈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代码：

在使用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）、泄漏来源
请浏览下面一段代码：

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

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

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

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