2、單個應用可用的最大內存

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為單位

上面的幾個參數是與虛擬機的內存分配相關的，虛擬機的內存分配過程是下面這樣的：

1 ?首先判斷一下需要申請的size是不是過大，如果申請的size超過了堆的最大限制，則轉入步驟6

2 ?嘗試分配，如果成功則返回，失敗則轉入步驟3

3 ?判斷是否gc正在進行垃圾回收，如果正在進行則等待回收完成之后，嘗試分配。如果成功則返回，失敗則轉入步驟4

4 ?自己啟動gc進行垃圾回收，這里gcForMalloc的參數是false。所以不會回收軟引用，回收完成后嘗試分配，如果成功則返回，失敗則轉入步驟5

5 ?調用dvmHeapSourceAllocAndGrow嘗試分配，這個函數會擴張堆。所以heap startup的時候可以給一個比較小的初始堆，實在不夠用再調用它進行擴張

6 ?進入回收軟引用階段，這里gcForMalloc的參數是ture，所以需要回收軟引用。然后調用dvmHeapSourceAllocAndGrow嘗試分配，如果失敗則拋出OOM。

3、為什么會內存泄露(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種對象引用：

強引用： 通常我們編寫的代碼都是Strong Ref，eg ：Person person = new Person("sunny");不管系統資源有多緊張，強引用的對象都絕對不會被回收，即使他以后不再用到。

軟引用：只要有足夠的內存，就一直保持對象。一般可用來實現緩存，通過java.lang.r.efSoftReference類實現。內存非常緊張的時候會被回收，其他時候不會被回收，所以在使用之前需要判空，從而判斷當前時候已經被回收了。

弱引用：通過WeakReference類實現，eg : WeakReference p = new WeakReference(new Person("Rain"));不管內存是否足夠，系統垃圾回收時必定會回收。

虛引用：不能單獨使用，主要是用于追蹤對象被垃圾回收的狀態。通過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

假設內存中對象之間的引用關系可以看成圖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掉的進程內存會被系統回收)，但是對于一名開發工程師，絕對不能放過任何的內存泄露。

4、為什么會發生OOM(Out Of Memory)？

OOM：即OutOfMemoery，顧名思義就是指內存溢出了。之前我們知道Android的應用程序所能申請的最大內存都是有限的，OOM是指APP向系統申請內存的請求超過了應用所能有的最大閥值的內存，系統無法再分配多余的空間，就會造成OOM error。在Android平臺下，除了之前所說的持續發生了內存泄漏(Memory Leak)，累積到一定程度導致OOM的情況以外，也有一次性申請很多內存，比如說一次創建大的數組或者是載入大的文件如圖片的時候。實際中很多情況就是出現在圖片不當處理加載的時候。

5、常見的MemoryLeak分析

后來看到了更多的MemoryLeak相關的知識，有了更多的實踐經驗，

總結

以上是生活随笔為你收集整理的android应用对于内存的大小是有限制的,Android 的内存限制的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。