淺談 maxMemory , totalMemory , freeMemory 和 OOM 與 native Heap

林冠巨集發表於2018-03-03
OOM

作者：林冠巨集 / 指尖下的幽靈

掘金：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中。

相關文章