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掉某些進程，用來補充可用內存，這樣會影響系統體驗。