在日常的Android開發(fā)中丰捷，我們必然遇到過OutOfMemoryError這樣的崩潰篡石，產生的原因無外乎兩點，一是內存過小不夠用使套，二是程序設計有誤罐呼，導致不能釋放內存，其中后者情況較多侦高。在解決這個問題時嫉柴，我們亦或多或少聽到android:largeHeap，然而這個概念又是什么呢奉呛，它該如何使用计螺，存在哪些問題呢。本文講比較全面介紹Android中的largeHeap幫助各位全面深入了解這個概念瞧壮。
磨刀不誤砍柴工
為了便于理解登馒，先簡單介紹一些和文章相關的基礎概念。
通常咆槽，一個Android程序在運行時會啟動一個Dalvik虛擬機（暫不討論ART模式）
虛擬機的運行時內存一般由堆和棧兩大部分構成陈轿。
棧是存儲方法調用的一片內存數據區(qū)。
堆內存占據了虛擬機的大部分內存空間秦忿，程序執(zhí)行時產生的對象就分配在堆內存上麦射。
如果是堆內存沒有可用的空間存儲生成的對象，JVM會拋出java.lang.OutOfMemoryError小渊。
如若具體了解堆和棧法褥，請參考文章Java中的堆和棧的區(qū)別和JVM運行時的數據區(qū)
largeHeap介紹
一個應用如果使用了largeHeap，會請求系統(tǒng)為Dalvik虛擬機分配更大的內存空間酬屉。使用起來也很方便，只需在manifest文件application節(jié)點加入android:largeHeap=“true”即可揍愁。
1234567
largeHeap有多大
在Android中呐萨，有如下兩個方法可以幫助我們查看當前內存大小
ActivityManager.getMemoryClass()獲得內用正常情況下內存的大小
ActivityManager.getLargeMemoryClass()可以獲得開啟largeHeap最大的內存大小
然而largeHeap這個最大值是如何決定的呢？想要了解這個問題莽囤，我們就需要看一下Android系統(tǒng)中的一個文件谬擦。
這個文件路徑是/system/build.prop，由于文件比較大朽缎，這里我們只截取關于dalvik內存的配置信息惨远，如下谜悟。
123456
dalvik.vm.heapstartsize=8mdalvik.vm.heapgrowthlimit=192mdalvik.vm.heapsize=512mdalvik.vm.heaptargetutilization=0.75dalvik.vm.heapminfree=2mdalvik.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之后就可以使我們的程序內存增加骨望，但這部分增加的內存有可能是源自被系統(tǒng)殺掉的后臺程序。所以欣舵，使用largeHeap理論上是有可能殺掉其他的程序的擎鸠。
然而，結果就是不需要權限缘圈，Google在一開始就是這樣劣光，只需要簡單在Application元素上加入android:largeHeap=“true”就能正常使用袜蚕。
largeHeap對GC的影響
擁有了更多的內存，是不是就意味著要花更多的時間遍歷對象垃圾回收呢绢涡？其實不然牲剃。
首先largeHeap自Android 4.0開始支持，而并發(fā)的垃圾回收方式從Android 2.3開始引入垂寥。
在引入并發(fā)垃圾回收之前颠黎，系統(tǒng)采用了Stop-the-World回收方式，進行一次垃圾回收通常消耗幾百毫秒滞项，這是很影響交互和響應的狭归。
引入并發(fā)垃圾回收之后,在GC開始和結束的階段會有短暫的暫停時間，通常在10毫秒以內文判。
因此在支持largeHeap的系統(tǒng)上都采用了并發(fā)垃圾回收过椎，GC的Pause Time不會很長，對交互響應影響甚微戏仓。
慎用largeHeap
對于largeHeap的使用疚宇，我們該持有的謹慎的態(tài)度，largeHeap可以使用赏殃，但是要謹慎敷待。
對于本身對內存要求過大的圖片或者視頻應用，我們可以使用largeHeap仁热。
除上面的情況榜揖，如果僅僅是為了解決OutOfMemoryError這樣的問題，而嘗試使用largeHeap分配更大內存的這種指標不治本的方法不可取抗蠢。對待這樣的OOM問題举哟，建議閱讀以下幾篇文章，了解Android中內存泄露和垃圾回收迅矛，從代碼上去查找問題妨猩，從根本上解決問題。
補漏
感謝大牛裸奔的凱子哥指出秽褒。
無論是否開啟largeHeap壶硅，ActivityManager.getLargeMemoryClass()都可以打印出largeHeap的大小。因為其本身只是讀取了配置文件的值而已震嫉。即下面的代碼無論largeHeap開啟與否森瘪，打印出來的日志都相同
12345678910
ActivityManageractivityManager=(ActivityManager)getSystemService(ACTIVITY_SERVICE);intlargeMemoryClass=activityManager.getLargeMemoryClass();intmemoryClass=activityManager.getMemoryClass();ActivityManager.MemoryInfoinfo=newActivityManager.MemoryInfo();activityManager.getMemoryInfo(info);Log.d(LOGTAG,"largeMemoryClass = "+largeMemoryClass);Log.d(LOGTAG,"memoryClass = "+memoryClass);
如何驗證
關于如何驗證，這里設置一個按鈕票堵，每次創(chuàng)建100M的內存對象，觀察開啟largeHeap前后的反應
1234567891011121314
privateArrayListmLeakyContainer=newArrayList<>();@OverrideprotectedvoidonCreate(BundlesavedInstanceState){super.onCreate(savedInstanceState);setContentView(R.layout.activity_main);findViewById(R.id.testBtn).setOnClickListener(newView.OnClickListener(){@OverridepublicvoidonClick(Viewv){byte[]b=newbyte[100*1000*1000];mLeakyContainer.add(b);}});testMemoryInfo();}
以正常情況下可用192M內存為例逮栅，點擊兩次按鈕悴势，應用崩潰窗宇。
然后在manifest開啟largeHeap，以最大512M內存可用為例特纤，點擊6次應用崩潰
http://droidyue.com/blog/2015/08/01/dive-into-android-large-heap/index.html
