淺談 maxMemory , totalMemory , freeMemory 和 OOM 與 native Heap
作者：林冠宏 / 指尖下的幽靈
掘金：https://juejin.im/user/587f0dfe128fe100570ce2d8
博客：http://www.cnblogs.com/linguanh/
GitHub ： https://github.com/af913337456/
騰訊雲專欄： https://cloud.tencent.com/developer/user/1148436/activities
回答內存管理類面試問題可以說出下面這些內容，加分。
前言： 站在巨人的肩膀上，總結此文。
目錄：
- Java runtime 三個計算內存函數
- OOM 的說法，為什麽大型遊戲能申請那麽多內存？
- 如何繞過dalvikvm heap size的限制 ？
- Bitmap分配在native heap還是dalvik heap上？
1，Java runtime 三個計算內存函數：
maxMemory
獲取當前 APP 最大能夠申請的內存，在 Java Heap 部分。
totalMemory
獲取當前 APP 已經從系統拿到的內存，包含使用上了的和沒有用上的，因為一般申請會申請多一部分，它總是慢慢按需要從系統拿取。
freeMemory
獲取當前 APP 拿到的內存中，還沒用上的，即是可以被 gc 回收的。
計算此刻 APP 在 Java Heap 層次已經使用了的內存 usedMemory ：
usedMemory = totalMemory - freeMemory
2，OOM 的說法，為什麽大型遊戲能申請那麽多內存？
在不同的 Android 系統版本中，OOM 的判斷是不一樣的。
通俗來說，OOM 是當前進程共申請的內存綜和超過一個限制，而被拋出。
專業來說，Android為每個進程設置Dalvik Heap Size閾值，這個閾值在不同的設備上會因為RAM大小不同而各有差異。如果APP想要分配的內存超過這個閾值，就會發生OOM。
Android
3.x以前，Bitmap分配在Native heap中，而在3.x之後，Bitmap分配在Dalvik或ART的Java heap中。Android 2.x系統，當dalvik allocated + native allocated + 新分配的大小 >= dalvik heap 最大值時候就會發生OOM，也就是說在2.x系統中，考慮native heap對每個進程的內存限制。
Android 3.x系統，廢除了native的計數器，類似bitmap的分配改到dalvik的java heap中申請，只要allocated + 新分配的內存 >= dalvik heap 最大值的時候就會發生OOM（art運行環境的統計規則還是和dalvik保持一致），也就是說在3.x系統中，不考慮native heap對每個進程的內存限制，native heap只會收到本機總內存（包括RAM以及SWAP區或分頁文件）的限制。
這也是為什麽有些APP（比如大型遊戲）可以超過 Dalvik Heap Size 這個值？那是因為Java內存又分為Java Heap和Native Heap，3.X 後 Native Heap是不受該值約束的。像C/C++的內存都是在Native Heap中分配的。另外Bitmap是在Java Heap中分配的，我們開發過程中經常遇到由Bitmap引起的OOM，這就是一個例子。
3，如何繞過dalvikvm heap size的限制 ？
創建子進程，上面說了，內存分配按進程來。再使用進程通訊
創建一個新的進程，那麽我們就可以把一些對象分配到新進程的heap上了，從而達到一個應用程序使用更多的內存的目的，當然，創建子進程會增加系統開銷，而且並不是所有應用程序都適合這樣做，視需求而定。
創建子進程的方法：使用android:process標簽
按不同的系統版本，使用 jni 在native heap上申請空間（推薦使用）
3.X 後的系統 native heap的增長並不受dalvik vm heapsize的限制，只要RAM有剩余空間，程序員可以一直在native heap上申請空間，當然如果 RAM快耗盡，memory killer會殺進程釋放RAM。大家使用一些軟件時，有時候會閃退，就可能是軟件在native層申請了比較多的內存導致的。比如，我就碰到過UC web在瀏覽內容比較多的網頁時閃退，原因就是其native heap增長到比較大的值，占用了大量的RAM，被memory killer殺掉了。
使用顯存（操作系統預留RAM的一部分作為顯存）
使用OpenGL textures等API，texture memory不受dalvik vm heapsize限制，這個我沒有實踐過。再比如Android中的GraphicBufferAllocator申請的內存就是顯存。
4，Bitmap分配在native heap還是dalvik heap上？
上面說了，不同的系統版本不同，那麽在 3.X 及其之後，為什麽在 java heap 而不是在 native heap 。請看下面源碼。
主要的文件
framework/base/graphic/java/Android/graphics/BitmapFactory.java
framework/base/core/jni/Android/graphics/BitmapFactory.cpp
framework/base/core/jni/Android/graphics/Graphics.cpp BitmapFactory.java 裏面有幾個decode***方法用來創建bitmap，最終都會調用：
private staticnative Bitmap nativeDecodeStream(InputStream is, byte[] storage,Rect padding,Options opts);而nativeDecodeStream()會調用到BitmapFactory.cpp中的deDecode方法，最終會調用到Graphics.cpp的createBitmap方法。
createBitmap方法的實現:
jobjectGraphicsJNI::createBitmap(JNIEnv* env, SkBitmap* bitmap, jbyteArray buffer,
boolisMutable, jbyteArray ninepatch, int density)
{
SkASSERT(bitmap);
SkASSERT(bitmap->pixelRef());
jobject obj = env->NewObject(gBitmap_class, gBitmap_constructorMethodID,
static_cast<jint>(reinterpret_cast<uintptr_t>(bitmap)),
buffer, isMutable, ninepatch,density);
hasException(env); // For the side effectof logging.
return obj;
} 從代碼中可以看到bitmap對象是通過env->NewOject(...)創建的，到這裏疑惑就解開了，bitmap對象是虛擬機創建的，JNIEnv的NewOject方法返回的是java對象，並不是native對象，所以它會分配到dalvik heap中。
淺談 maxMemory , totalMemory , freeMemory 和 OOM 與 native Heap