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