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

提示：扫一扫查出行
【扫一扫了解最新限行尾号】
复制提示

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掉的进程内存会被系统回收）。可是对于一名开发project师。绝对不能放过不论什么的内存泄露。

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

OOM：即OutOfMemoery，顾名思义就是指内存溢出了。之前我们知道Android的应用程序所能申请的最大内存都是有限的，OOM是指APP向系统申请内存的请求超过了应用所能有的最大阀值的内存，系统无法再分配多余的空间，就会造成OOM error。

在Android平台下，除了之前所说的持续发生了内存泄漏(Memory Leak)，累积到一定程度导致OOM的情况以外，也有一次性申请非常多内存，比方说一次创建大的数组或者是载入大的文件如图片的时候。

实际中非常多情况就是出如今图片不当处理载入的时候。

5、常见的MemoryLeak分析

后来看到了很多其它的MemoryLeak相关的知识，有了很多其它的实践经验。

就此小小总结了大约。见 Android 内存优化 (反Memory Leak)