Android内存管理及Memory Leak、OOM分析

一.Android进程管理&内存

Android主要应用在嵌入式设备当中，而嵌入式设备由于一些众所周知的条件限制，通常都不会有很高的配置，特别是内存是比较有限的。如果我们编写的代 码当中有太多的对内存使用不当的地方，难免会使得我们的设备运行缓慢，甚至是死机。为了能够使得Android应用程序安全且快速的运行，Android 的每个应用程序都会使用一个专有的Dalvik虚拟机实例来运行，它是由Zygote服务进程演变过来的，也就是说每个应用程序都是在属于自己的进程中运行的。一方面，如果程序在运行过程中出现了内存泄漏的问题，仅仅会使得自己的进程被杀掉，而不会影响其他进程（如果是system_process 等系统进程出问题的话，则会引起系统重启）。另一方面Android为不同类型的进程分配了不同的内存使用上限，如果应用进程使用的内存超过了这个上限， 则会被系统视为内存泄漏，从而被杀掉。
同时，Android会为每个应用程序分配一个单独的LINUX用户。Android会尽量保留一个正在运行进程，只在内存资源出现不足时，Android会尝试停止一些进程从而释放足够的资源给其他新的进程使用， 也能保证用户正在访问的当前进程有足够的资源去及时地响应用户的事件。Android会根据进程中运行的组件类别以及组件的状态来判断该进程的重要性，Android会首先停止那些不重要的进程。按照重要性从高到低一共有五个级别就是我们常说的：前台进程、可见进程、服务进程、后台进程、空进程。

二.单个应用最大内存

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为单位

三.为什么会内存泄漏（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种对象引用：
1. 强引用： 通常我们编写的代码都是Strong Ref，eg ：Person person = new Person(“sunny”);不管系统资源有多紧张，强引用的对象都绝对不会被回收，即使他以后不再用到。
2. 软引用：只要有足够的内存，就一直保持对象。一般可用来实现缓存，通过java.lang.r.efSoftReference类实现。内存非常紧张的时候会被回收，其他时候不会被回收，所以在使用之前需要判空，从而判断当前时候已经被回收了。
3. 弱引用：通过WeakReference类实现，eg : WeakReference p = new WeakReference(new Person(“Rain”));不管内存是否足够，系统垃圾回收时必定会回收。
4. 虚引用：不能单独使用，主要是用于追踪对象被垃圾回收的状态。通过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的方式，从图中可以看到 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掉的进程内存会被系统回收），但是对于一名开发工程师，绝对不能放过任何的内存泄露。

四.为什么会发生OOM(out of memory)

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

• Android 2.x系统 GC LOG中的dalvik allocated + external allocated + 新分配的大小 >= getMemoryClass()值的时候就会发生OOM。 例如，假设有这么一段Dalvik输出的GC LOG：GC_FOR_MALLOC free 2K, 13% free 32586K/37455K, external 8989K/10356K, paused 20ms，那么32586+8989+(新分配23975)=65550>64M时，就会发生OOM。
• Android 4.x系统 Android 4.x的系统废除了external的计数器，类似bitmap的分配改到dalvik的java heap中申请，只要allocated + 新分配的内存 >= getMemoryClass()的时候就会发生OOM

五.常见的Memory Leak分析

对象都是有生命周期的，对象的生命周期有的是进程级别的，有的是Activity所在的生命周期，随Activity消亡；有的是Service所在的生命周期，随Service消亡。很多情况下判断对象是否合理存在的一个很重要的理由就是它实际的生命周期是否符合它本来的生命周期。很多Memory Leak的发生，很大程度上都是生命周期的错配，本来在随Activity销毁的对象变成了进程级别的对象，Memory Leak就无法避免了。

1. 常见的Memory Leak

1.1 频繁的使用static关键字
很多初学者非常喜欢用static类static变量，声明赋值调用都简单方便。由于static声明变量的生命周期其实是和APP的生命周期一样的（进程级别）。大量的使用的话，就会占据内存空间不释放，积少成多也会造成内存的不断开销，直至挂掉。static的合理使用一般用来修饰基本数据类型或者轻量级对象，尽量避免修复集合或者大对象，常用作修饰全局配置项、工具类方法、内部类。
1.2 Bitmap
Bitmap的不当处理极可能造成OOM，绝大多数情况应用程序OOM都是因这个原因出现的。Bitamp位图是Android中当之无愧的胖子，所以在操作的时候必须小心。

• 及时释放recycle。由于Dalivk并不会主动的去回收，需要开发者在Bitmap不被使用的时候recycle掉。
• 设置一定的压缩率。需求允许的话，应该去对BItmap进行一定的缩放，通过BitmapFactory.Options的inSampleSize属性进行控制。如果仅仅只想获得Bitmap的属性，其实并不需要根据BItmap的像素去分配内存，只需在解析读取Bmp的时候使用BitmapFactory.Options的inJustDecodeBounds属性。
• 最后建议大家在加载网络图片的时候，使用软引用或者弱引用并进行本地缓存，推荐使用android-universal-imageloader或者xUtils。

1.3 View缓存
在ListView和GridView中，列表中的很多项(convertView)是可以重用的，不需要每次getView就重新生成一项。另外，页面的绘制其实是很耗时的，findViewById也比较慢。所以不重用View，在有列表的时候就尤为显著了，经常会出现滑动很卡的现象。
1.4 引用地狱
Activity中生成的对象原则上是应该在Activity生命周期结束之后就释放的。Activity对象本身也是，所以应该尽量避免有appliction进程级别的对象来引用Activity级别的对象，如果有的话也应该在Activity结束的时候解引用。如不应用applicationContext在Activity中获取资源。Service也一样。
1.5 BroadCastReceiver、Service 解绑
绑定广播和服务，一定要记得在不需要的时候给解绑。
1.6 handler 清理
在Activity的onDestroy方法中调用handler.removeCallbacksAndMessages(null);取消所有的消息的处理，包括待处理的消息。
1.7 Cursor及时关闭
在查询SQLite数据库时，会返回一个Cursor，当查询完毕后，及时关闭，这样就可以把查询的结果集及时给回收掉。
1.8 I/O流
I/O流操作完毕，读写结束，记得关闭。
1.9 线程
线程不再需要继续执行的时候要记得及时关闭，开启线程数量不易过多，一般和自己机器内核数一样最好，推荐开启线程的时候，使用线程池。
1.10 String/StringBuffer
当有较多的字符创需要拼接的时候，推荐使用StringBuffer。
1.11 避免在OnDraw方法内执行对象的创建
类似onDraw等频繁调用的方法，一定需要注意避免在这里做创建对象的操作，因为他会迅速增加内存的使用，而且很容易引起频繁的gc，甚至是内存抖动。
1.12 优化布局层次，减少内存消耗
越扁平化的视图布局，占用的内存就越少，效率越高。我们需要尽量保证布局足够扁平化，当使用系统提供的View无法实现足够扁平的时候考虑使用自定义View来达到目的。
1.13 谨慎使用抽象编程
很多时候，开发者会使用抽象类作为”好的编程实践”，因为抽象能够提升代码的灵活性与可维护性。然而，抽象会导致一个显著的额外内存开销：他们需要同等量的代码用于可执行，那些代码会被mapping到内存中，因此如果你的抽象没有显著的提升效率，应该尽量避免他们。
1.14 谨慎使用依赖注入框架
注入框架会通过扫描你的代码执行许多初始化的操作，这会导致你的代码需要大量的内存空间来mapping代码，而且mapped pages会长时间的被保留在内存中。除非真的很有必要，建议谨慎使用这种技术
1.15 复用系统自带的资源
Android系统本身内置了很多的资源，例如字符串/颜色/图片/动画/样式以及简单布局等等，这些资源都可以在应用程序中直接引用。这样做不仅仅可以减少应用程序的自身负重，减小APK的大小，另外还可以一定程度上减少内存的开销，复用性更好。但是也有必要留意Android系统的版本差异性，对那些不同系统版本上表现存在很大差异，不符合需求的情况，还是需要应用程序自身内置进去。
1.16 谨慎使用枚举

Enums often require more than twice as much memory as static constants. You should strictly avoid using enums on Android.

枚举的使用通常优化了代码的结构，但以消耗极大的内存为代价。

总结：

• 设计风格很大程度上会影响到程序的内存与性能，相对来说，如果大量使用类似Material Design的风格，不仅安装包可以变小，还可以减少内存的占用，渲染性能与加载性能都会有一定的提升。
• 内存优化并不就是说程序占用的内存越少就越好，如果因为想要保持更低的内存占用，而频繁触发执行gc操作，在某种程度上反而会导致应用性能整体有所下降，这里需要综合考虑做一定的权衡。
• Android的内存优化涉及的知识面还有很多：内存管理的细节，垃圾回收的工作原理，如何查找内存泄漏等等都可以展开讲很多。OOM是内存优化当中比较突出的一点，尽量减少OOM的概率对内存优化有着很大的意义。

参考：http://blog.csdn.net/vshuang/article/details/39647167