Android——内存管理基础

内存收集概念

内存垃圾收集器（garbage collector）

概念：自定内存管理。

功能：分配内存、保证全部被引用的对象还在内存中、能够释放在运行的代码中再也不引用的对象的内存。

垃圾收集器避免了悬挂指针（dangling reference），缘由是一个仍然被引用的对象永远不会内存回收而且也不会被认为已经被释放掉了。

垃圾收集器解决了空间泄漏（space leaks）问题，缘由是它能够自动释放再也不被引用的空间。

垃圾收集（garbage collection）

若是对象被引用着，那咱们说它活着（live）；若是对象再也不被引用了，那咱们说他死了（dead），术语称做垃圾（garbage）。寻找并释放这些对象的空间的过程就作垃圾收集（garbagecollection）。

那么在何时会出发垃圾收集动做呢？通常来讲整个堆或一部分被填满或者达到某一百分比数值时将被收集。

常见的三种垃圾收集器

串行（Serial）：也被称为彻底停顿(Stop-the-world)。当执行GC时，程序的线程都会被挂起。

并行(Parallel)：圾收集工做被分红几部分，这些子部将会在不一样的CPU上被同时执行。同时执行会使垃圾收集得更快，可是代价是会增长复杂性和潜在碎片。

并发（Concurrent）：一个或者多个垃圾收集任务也能够并发的与应用程序同时执行。一般，一个并发收集器能够并发的执行垃圾收集的大部分工做，可是也会不可避免的引起一个小的停顿。

Android Garbage Collector发展

Android 1.0~2.2，Dalvik虚拟使用的垃圾收集机制有如下特色：

1. Stop-the-word（彻底停顿），也就是一个垃圾收集线程在执行的时候，其它的线程都中止；
2. Full heap collection，也就是一次收集彻底部的垃圾；
3. 长等待，一次垃圾收集形成的程序停止时间一般都大于100ms。

Android 2.3~至今，Dalvik虚拟使用的垃圾收集机制获得了改进

1. Cocurrent（并发），也就是大多数状况下，一个或多垃圾收集线程与其它线程是并发执行的；
2. Partial collection，也就是一次可能只收集一部分垃圾；
3. 短等待，一次垃圾收集形成的程序停止时间一般都小于5ms。

Dalvik虚拟机执行完成一次垃圾收集以后，咱们一般能够看到相似如下的日志输出：

1 D/dalvikvm(9050): GC_CONCURRENT freed 2049K, 65% free 3571K/9991K, external 4703K/5261K, paused 2ms+2ms  

在这一行日志中，GC_CONCURRENT表示GC缘由，2049K表示总共回收的内存，3571K/9991K表示Java Object Heap统计，即在9991K的Java Object Heap中，有3571K是正在使用的，4703K/5261K表示External Memory统计，即在5261K的External Memory中，有4703K是正在使用的，2ms+2ms表示垃圾收集形成的程序停止时间。

Android内存管理

Dalvik虚拟机的内存大致上能够分为Java Object Heap、Bitmap Memory和Native Heap三种。

Java Object Heap

Java Object Heap是用来分配Java对象的，也就是咱们在代码new出来的对象都是位于Java Object Heap上的。

Dalvik虚拟机在启动的时候，能够经过-Xms和-Xmx选项来指定Java Object Heap的最小值和最大值。为了不Dalvik虚拟机在运行的过程当中对Java Object Heap的大小进行调整而影响性能，咱们能够经过-Xms和-Xmx选项来将它的最小值和最大值设置为相等。

Java Object Heap的最小和最大默认值为2M和16M，可是手机在出厂时，厂商会根据手机的配置状况来对其进行调整，例如，G一、Droid、Nexus One和Xoom的Java Object Heap的最大值分别为16M、24M、32M 和48M。咱们能够经过ActivityManager类的成员函数getMemoryClass来得到Dalvik虚拟机的Java Object Heap的最大值。

ActivityManager类的成员函数getMemoryClass的实现以下所示：

 1 public class ActivityManager {
 2     ......
 3 
 4     /**
 5      * Return the approximate per-application memory class of the current
 6      * device.  This gives you an idea of how hard a memory limit you should
 7      * impose on your application to let the overall system work best.  The
 8      * returned value is in megabytes; the baseline Android memory class is
 9      * 16 (which happens to be the Java heap limit of those devices); some
10      * device with more memory may return 24 or even higher numbers.
11      */
12     public int getMemoryClass() {
13         return staticGetMemoryClass();
14     }
15 
16     /** @hide */
17     static public int staticGetMemoryClass() {
18         // Really brain dead right now -- just take this from the configured
19         // vm heap size, and assume it is in megabytes and thus ends with "m".
20         String vmHeapSize = SystemProperties.get("dalvik.vm.heapsize", "16m");
21         return Integer.parseInt(vmHeapSize.substring(0, vmHeapSize.length()-1));
22     }
23 
24     ......
25 }

Dalvik虚拟机在启动的时候，就是经过读取系统属性dalvik.vm.heapsize的值来得到Java Object Heap的最大值的，而ActivityManager类的成员函数getMemoryClass最终也经过读取这个系统属性的值来得到Java Object Heap的最大值。

这个Java Object Heap的最大值也就是咱们平时所说的Android应用程序进程可以使用的最大内存。这里必需要注意的是，Android应用程序进程可以使用的最大内存指的是可以用来分配Java Object的堆。

在Android3.0以及更高的版本中，咱们还能够在AndroidManifest.xml的application标签中增长一个值等于“true”的android:largeHeap属性来通知Dalvik虚拟机应用程序须要使用较大的Java Object Heap。事实上这个属性受限于手机内存，同时也会影响系统体验（毕竟系统总共可用的内存是固定的，一个应用程序用得多了，就意味意其它应用程序用得少了）。

Bitmap Memory

Bitmap Memory也称为External Memory，它是用来处理图像的，这部份内存受Java Object Heap的大小限制的

• 在Android3.0以前，Bitmap Memory是在Native Heap中分配的，可是这部份内存一样计入Java Object Heap中，也就是说，Bitmap占用的内存和Java Object占用的内存加起来不能超过Java Object Heap的最大值。这就是为何咱们在调用BitmapFactory相关的接口来处理大图像时，会抛出一个OutOfMemoryError异常的缘由。
• 在Android3.0以及更高的版本中，Bitmap Memory就直接是在Java Object Heap中分配了，这样就能够直接接受GC的管理。

Native Heap

Native Heap就是在Native Code中使用malloc等分配出来的内存，这部份内存是不受Java Object Heap的大小限制的，也就是它能够自由使用，固然它是会受到系统的限制。可是有一点须要注意的是，不要由于Native Heap能够自由使用就滥用，由于滥用Native Heap会致使系统可用内存急剧减小，从而引起系统采起激进的措施来Kill掉某些进程，用来补充可用内存，这样会影响系统体验。