在日常的Android開發中，我們必然遇到過OutOfMemoryError這樣的崩潰，產生的原因無外乎兩點，一是內存過小不夠用，二是程序設計有誤，導致不能釋放內存，其中後者情況較多。在解決這個問題時，我們亦或多或少聽到android:largeHeap，然而這個概念又是什麼呢，它該如何使用，存在哪些問題呢。本文講比較全面介紹Android中的largeHeap幫助各位全面深入瞭解這個概念。
磨刀不誤砍柴工
爲了便於理解，先簡單介紹一些和文章相關的基礎概念。
- 通常，一個Android程序在運行時會啓動一個Dalvik虛擬機（暫不討論ART模式）
- 虛擬機的運行時內存一般由堆和棧兩大部分構成。
- 棧是存儲方法調用的一片內存數據區。
- 堆內存佔據了虛擬機的大部分內存空間，程序執行時產生的對象就分配在堆內存上。
- 如果是堆內存沒有可用的空間存儲生成的對象，JVM會拋出java.lang.OutOfMemoryError。
如若具體瞭解堆和棧，請參考文章Java中的堆和棧的區別和JVM運行時的數據區
largeHeap介紹
一個應用如果使用了largeHeap，會請求系統爲Dalvik虛擬機分配更大的內存空間。使用起來也很方便，只需在manifest文件application節點加入android:largeHeap=“true” 即可。
<application android:icon="@drawable/icon"
android:allowBackup="false"
android:label="@string/app_name"
android:debuggable="true"
android:theme="@android:style/Theme.Black"
android:largeHeap="true"
>
largeHeap有多大
在Android中，有如下兩個方法可以幫助我們查看當前內存大小
- ActivityManager.getMemoryClass()獲得內用正常情況下內存的大小
- ActivityManager.getLargeMemoryClass()可以獲得開啓largeHeap最大的內存大小
然而largeHeap這個最大值是如何決定的呢？想要了解這個問題，我們就需要看一下Android系統中的一個文件。
這個文件路徑是 /system/build.prop ，由於文件比較大，這裏我們只截取關於dalvik內存的配置信息，如下。
dalvik.vm.heapstartsize=8m
dalvik.vm.heapgrowthlimit=192m
dalvik.vm.heapsize=512m
dalvik.vm.heaptargetutilization=0.75
dalvik.vm.heapminfree=2m
dalvik.vm.heapmaxfree=8m
上面有諸多配置，但從字面意思也不難理解，爲了正確理解，有必要逐一解釋一下。
dalvik.vm.heapstartsize=8m
相當於虛擬機的 -Xms配置，該項用來設置堆內存的初始大小。
dalvik.vm.heapgrowthlimit=192m
相當於虛擬機的 -XX:HeapGrowthLimit配置，該項用來設置一個標準的應用的最大堆內存大小。一個標準的應用就是沒有使用android:largeHeap的應用。
dalvik.vm.heapsize=512m
相當於虛擬機的 -Xmx配置，該項設置了使用android:largeHeap的應用的最大堆內存大小。
dalvik.vm.heaptargetutilization=0.75
相當於虛擬機的 -XX:HeapTargetUtilization,該項用來設置當前理想的堆內存利用率。其取值位於0與1之間。當GC進行完垃圾回收之後，Dalvik的堆內存會進行相應的調整，通常結果是當前存活的對象的大小與堆內存大小做除法，得到的值爲這個選項的設置，即這裏的0.75。注意，這只是一個參考值， Dalvik虛擬機也可以忽略此設置。
dalvik.vm.heapminfree=2m與 dalvik.vm.heapmaxfree=8m
dalvik.vm.heapminfree對應的是-XX:HeapMinFree配置，用來設置單次堆內存調整的最小值。 dalvik.vm.heapmaxfree 對應的是-XX:HeapMaxFree配置，用來設置單次堆內存調整的最大值。通常情況下，還需要結合上面的 -XX:HeapTargetUtilization的值，才能確定內存調整時，需要調整的大小。
largeHeap需要權限麼
爲何有此疑問呢？ 原因是這樣的。 首先一個設備的內存是固定的，當我們使用了largeHeap之後就可以使我們的程序內存增加，但這部分增加的內存有可能是源自被系統殺掉的後臺程序。所以，使用largeHeap理論上是有可能殺掉其他的程序的。
然而，結果就是不需要權限，Google在一開始就是這樣，只需要簡單在Application元素上加入android:largeHeap=“true”就能正常使用。
largeHeap對GC的影響
擁有了更多的內存，是不是就意味着要花更多的時間遍歷對象垃圾回收呢？其實不然。
首先largeHeap自Android 4.0開始支持，而併發的垃圾回收方式從Android 2.3開始引入。
在引入併發垃圾回收之前，系統採用了Stop-the-World回收方式，進行一次垃圾回收通常消耗幾百毫秒，這是很影響交互和響應的。
引入併發垃圾回收之後,在GC開始和結束的階段會有短暫的暫停時間，通常在10毫秒以內。
因此在支持largeHeap的系統上都採用了併發垃圾回收，GC的Pause Time不會很長，對交互響應影響甚微。
慎用largeHeap
對於largeHeap的使用，我們該持有的謹慎的態度，largeHeap可以使用，但是要謹慎。
對於本身對內存要求過大的圖片或者視頻應用，我們可以使用largeHeap。
除上面的情況，如果僅僅是爲了解決OutOfMemoryError這樣的問題，而嘗試使用largeHeap分配更大內存的這種指標不治本的方法不可取。對待這樣的OOM問題，建議閱讀以下幾篇文章，瞭解Android中內存泄露和垃圾回收，從代碼上去查找問題，從根本上解決問題。