Android 内存管理 &Memory Leak & OOM 分析

转自http://blog.csdn.net/vshuang/article/details/39647167

1、Android 进程管理&内存

Android主要应用在嵌入式设备当中，而嵌入式设备由于一些众所周知的条件限制，通常都不会有很高的配置，特别是内存是比较有限的。如果我们编写的代 码当中有太多的对内存使用不当的地方，难免会使得我们的设备运行缓慢，甚至是死机。为了能够使得Android应用程序安全且快速的运行，Android 的每个应用程序都会使用一个专有的Dalvik虚拟机实例来运行，它是由Zygote服务进程演变过来的，也就是说每个应用程序都是在属于自己的进程中运行的。一方面，如果程序在运行过程中出现了内存泄漏的问题，仅仅会使得自己的进程被杀掉，而不会影响其他进程（如果是system_process
等系统进程出问题的话，则会引起系统重启）。另一方面Android为不同类型的进程分配了不同的内存使用上限，如果应用进程使用的内存超过了这个上限， 则会被系统视为内存泄漏，从而被杀掉。

同时，Android会为每个应用程序分配一个单独的LINUX用户。Android会尽量保留一个正在运行进程，只在内存资源出现不足时，Android会尝试停止一些进程从而释放足够的资源给其他新的进程使用， 也能保证用户正在访问的当前进程有足够的资源去及时地响应用户的事件。Android会根据进程中运行的组件类别以及组件的状态来判断该进程的重要性，Android会首先停止那些不重要的进程。按照重要性从高到低一共有五个级别就是我们常说的：前台进程、可见进程、服务进程、后台进程、空进程。

2、单个应用可用的最大内存

Android设备出厂以后，java虚拟机对单个应用的最大内存分配就确定下来了，超出这个值就会OOM。这个属性值是定义在/system/build.prop文件中的

dalvik.vm.heapstartsize=8m

它表示堆分配的初始大小，它会影响到整个系统对RAM的使用程度，和第一次使用应用时的流畅程度。

它值越小，系统ram消耗越慢，但一些较大应用一开始不够用，需要调用gc和堆调整策略，导致应用反应较慢。它值越大，这个值越大系统ram消耗越快，但是应用更流畅。

dalvik.vm.heapgrowthlimit=64m // 单个应用可用最大内存

主要对应的是这个值,它表示单个进程内存被限定在64m,即程序运行过程中实际只能使用64m内存，超出就会报OOM。（仅仅针对dalvik堆，不包括native堆）

dalvik.vm.heapsize=384m//heapsize参数表示单个进程可用的最大内存，但如果存在heapgrowthlimit参数，则以heapgrowthlimit为准.

heapsize表示不受控情况下的极限堆，表示单个虚拟机或单个进程可用的最大内存。而android上的应用是带有独立虚拟机的，也就是每开一个应用就会打开一个独立的虚拟机（这样设计就会在单个程序崩溃的情况下不会导致整个系统的崩溃）。

注意：在设置了heapgrowthlimit的情况下，单个进程可用最大内存为heapgrowthlimit值。在android开发中，如果要使用大堆，需要在manifest中指定android:largeHeap为true，这样dvm heap最大可达heapsize。

不同设备，这些个值可以不一样。一般地，厂家针对设备的配置情况都会适当的修改/system/build.prop文件来调高这个值。随着设备硬件性能的不断提升，从最早的16M限制（G1手机）到后来的24m,32m，64m等，都遵循Android框架对每个应用的最小内存大小限制，参考http://source.android.com/compatibility/downloads.html 3.7节。

通过代码查看每个进程可用的最大内存，即heapgrowthlimit值：

ActivityManager activityManager = (ActivityManager) context.getSystemService(Context.ACTIVITY_SERVICE);

int memClass = activityManager.getMemoryClass();//64，以m为单位

3、为什么会内存泄露(Memory Leak)?

  android通过android虚拟机来管理内存，程序员只管申请内存创建对象，创建完不再需要关心怎么释放对象内存，一切由虚拟机帮你搞定，然而虚拟机回收对象是有条件的。这里简单叙述下java内存管理机制，java虚拟机维护着一张当前对象关系的object tree，当GC发生时，虚拟机会从GC Roots 开始去扫描当前的对象树，发现通过任何reference chain(引用链)无法访问某个对象的时候，该对象即被回收。名词GC Roots正是分析这一过程的起点，例如JVM自己确保了对象的可到达性(那么JVM就是GC
Roots)，所以GC Roots就是这样在内存中保持对象可到达性的，一旦不可到达，即被回收。通常GC Roots是一个在current thread(当前线程)的call stack(调用栈)上的对象（例如方法参数和局部变量），或者是线程自身或者是system class loader(系统类加载器)加载的类以及native code(本地代码)保留的活动对象。所以GC Roots是分析对象为何还存活于内存中的利器。知道了什么样的对象GC才会回收后，再来学习下对象引用都包含哪些吧。
Java中包含4种对象引用：
强引用： 通常我们编写的代码都是Strong Ref，eg ：Person person = new Person("sunny");不管系统资源有多紧张，强引用的对象都绝对不会被回收，即使他以后不再用到。
软引用：只要有足够的内存，就一直保持对象。一般可用来实现缓存，通过java.lang.r.efSoftReference类实现。内存非常紧张的时候会被回收，其他时候不会被回收，所以在使用之前需要判空，从而判断当前时候已经被回收了。
弱引用：通过WeakReference类实现，eg : WeakReference p = new WeakReference(new Person("Rain"));不管内存是否足够，系统垃圾回收时必定会回收。
虚引用：不能单独使用，主要是用于追踪对象被垃圾回收的状态。通过PhantomReference类和引用队列ReferenceQueue类联合使用实现。
我们可能还需要了解shallow size、retained size概念，简单来说，Shallow size就是对象本身占用内存的大小，不包含对其他对象的引用，也就是对象头加成员变量（不是成员变量的值）的总和。在32位系统上，对象头占用8字节，int占用4字节，不管成员变量（对象或数组）是否引用了其他对象（实例）或者赋值为null它始终占用4字节。故此，对于String对象实例来说，它有三个int成员（34=12字节）、一个char[]成员（14=4字节）以及一个对象头（8字节），总共34
+14+8=24字节。根据这一原则，对String a=”rosen jiang”来说，实例a的shallow size也是24字节。Retained size是该对象自己的shallow size，加上只能从该对象能直接或间接访问到对象的shallow size之和。换句话说，retained size是该对象被GC之后所能回收到内存的总和。为了更好的理解retained size，我们来看个例子。



    图1

假设内存中对象之间的引用关系可以看成图1的方式，从图中可以看到 GC正是reference chain的起点。从obj1入手，上图中蓝色节点代表仅仅只有通过obj1才能直接或间接访问的对象。因为可以通过GC Roots访问，所以左图的obj3不是蓝色节点；而在右图却是蓝色，因为它已经被包含在retained集合内。所以对于左图，obj1的retained size是obj1、obj2、obj4的shallow size总和；右图的retained size是obj1、obj2、obj3、obj4的shallow
size总和。

相信了有以上的这些基础概念，我们应该对java内存管理有了一个初步的了解。

为什么会内存泄露呢，根本原因就是一个永远不会被使用的对象，因为一些引用没有断开，没有满足GC条件，导致不会被回收，这就造成了内存泄露。比如在Activity中注册了一个广播接收器，但是在页面关闭的时候进行unRegister，就会出现内存溢出的现象。如果我们的java运行很久,而这种内存泄露不断的发生，最后就没内存可用了，最终就是我们看到的OOM错误。虽然android的内存泄露做到了应用程序级别的泄露（android中的每个应用程序都是独立运行在单独进程中的，每个应用进程都由虚拟机指定了一个内存上限值，一旦内存占用值超过这个上限值，就会发生oom错误，进程被强制kill掉，kill掉的进程内存会被系统回收），但是对于一名开发工程师，绝对不能放过任何的内存泄露。

4、为什么会发生OOM(Out Of Memory)？

OOM：即OutOfMemoery，顾名思义就是指内存溢出了。之前我们知道Android的应用程序所能申请的最大内存都是有限的，OOM是指APP向系统申请内存的请求超过了应用所能有的最大阀值的内存，系统无法再分配多余的空间，就会造成OOM error。在Android平台下，除了之前所说的持续发生了内存泄漏(Memory Leak)，累积到一定程度导致OOM的情况以外，也有一次性申请很多内存，比如说一次创建大的数组或者是载入大的文件如图片的时候。实际中很多情况就是出现在图片不当处理加载的时候。

5、常见的MemoryLeak分析 

后来看到了更多的MemoryLeak相关的知识，有了更多的实践经验，

1.1 频繁的使用static关键字修饰
很多初学者非常喜欢用static类static变量，声明赋值调用都简单方便。由于static声明变量的生命周期其实是和APP的生命周期一样的（进程级别）。大量的使用的话，就会占据内存空间不释放，积少成多也会造成内存的不断开销，直至挂掉。static的合理使用一般用来修饰基本数据类型或者轻量级对象，尽量避免修复集合或者大对象，常用作修饰全局配置项、工具类方法、内部类。

1.2 BitMap隐患
Bitmap的不当处理极可能造成OOM，绝大多数情况应用程序OOM都是因这个原因出现的。Bitamp位图是Android中当之无愧的胖子，所以在操作的时候必须小心。
1.2.1 及时释放recycle。由于Dalivk并不会主动的去回收，需要开发者在Bitmap不被使用的时候recycle掉。
1.2.2 设置一定的压缩率。需求允许的话，应该去对BItmap进行一定的缩放，通过BitmapFactory.Options的inSampleSize属性进行控制。如果仅仅只想获得Bitmap的属性，其实并不需要根据BItmap的像素去分配内存，只需在解析读取Bmp的时候使用BitmapFactory.Options的inJustDecodeBounds属性。
1.2.3最后建议大家在加载网络图片的时候，使用软引用或者弱引用并进行本地缓存，推荐使用android-universal-imageloader或者xUtils。

1.3 页面背景图
在布局和代码中设置背景和图片的时候，如果是纯色，尽量使用color；如果是规则图形，尽量使用shape画图；如果稍微复杂点，可以使用9patch图；如果不能使用9patch的情况下，针对几种主流分辨率的机型进行切图。

1.4 View缓存
在ListView和GridView中，列表中的很多项(convertView)是可以重用的，不需要每次getView就重新生成一项。另外，页面的绘制其实是很耗时的，findViewById也比较慢。所以不重用View，在有列表的时候就尤为显著了，经常会出现滑动很卡的现象。

1.5 引用地狱
Activity中生成的对象原则上是应该在Activity生命周期结束之后就释放的。Activity对象本身也是，所以应该尽量避免有appliction进程级别的对象来引用Activity级别的对象，如果有的话也应该在Activity结束的时候解引用。如不应用applicationContext在Activity中获取资源。
Service也一样。

1.6 BroadCastReceiver、Service 解绑
绑定广播和服务，一定要记得在不需要的时候给解绑。

1.7 handler 清理
在Activity的onDestroy方法中调用handler.removeCallbacksAndMessages(null);取消所有的消息的处理，包括待处理的消息；

1.8 Cursor及时关闭
在查询SQLite数据库时，会返回一个Cursor，当查询完毕后，及时关闭，这样就可以把查询的结果集及时给回收掉。

1.9 I/O流
I/O流操作完毕，读写结束，记得关闭。

1.10 线程
线程不再需要继续执行的时候要记得及时关闭，开启线程数量不易过多，一般和自己机器内核数一样最好，推荐开启线程的时候，使用线程池。

1.11 String/StringBuffer
当有较多的字符创需要拼接的时候，推荐使用StringBuffer。