淺談 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中。