引用 https://www.csdn.net/article/2015-09-18/2825737/1
該篇文件僅僅做了排版，方便閱讀
前面我們提到過使用getMemoryClass()的方法可以得到Dalvik Heap的閾值。簡要地獲取某個應用的內存占用情況可以參考下面的示例（更多內存查看的知識，可以參考Google官方教程： Investigating Your RAM Usage）
1）查看內存使用情況
通過命令行查看內存詳細占用情況，如圖3所示。
通過Android Studio的Memory Monitor查看內存中Dalvik Heap的實時變化，如圖4、5、6所示。
2）發(fā)生OOM的條件
關于Native Heap、Dalvik Heap、PSS等內存管理機制比較復雜，這里就不展開詳細描述。簡單的說，通過不同的內存分配方式（malloc/mmap/JNIEnv/etc）對不同的對象（Bitmap/etc）進行操作，會因為Android系統(tǒng)版本的差異而產生不同的行為，對Native Heap與Dalvik Heap以及OOM的判斷條件都會有所影響。在2.x的系統(tǒng)上，我們常常可以看到Heap Size的total值，明顯超過了通過getMemoryClass()獲取到的閾值而不會發(fā)生OOM的情況。那么，針對2.x與4.x的Android系統(tǒng)，到底如何判斷會發(fā)生OOM呢？
Android 2.x系統(tǒng)GC LOG中的dalvik allocated + external allocated + 新分配的大小 >= getMemoryClass()值的時候就會發(fā)生OOM。 例如，假設有這么一段Dalvik輸出的GC LOG：GC_FOR_MALLOC free 2K, 13% free 32586K/37455K, external 8989K/10356K, paused 20ms，那么32586+8989+(新分配23975)=65550>64M時，就會發(fā)生OOM。
Android 4.x的系統(tǒng)廢除了external的計數(shù)器，類似Bitmap的分配改到Dalvik的Java Heap中申請。只要allocated + 新分配的內存 >= getMemoryClass()的時候就會發(fā)生OOM，如圖7所示（注：雖然圖示演示的是ART運行環(huán)境，但是統(tǒng)計規(guī)則還是和Dalvik保持一致）。
