一、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。