實(shí)際情況中，6.0 系統(tǒng)得 OOM 占了非常大一部分，如果這個(gè)方案可行，也可以解決一部分問(wèn)題，所以不會(huì)因?yàn)檫@個(gè)原因阻礙對(duì)這種方案得嘗試，還可以繼續(xù)嘗試

這個(gè)問(wèn)題基本是無(wú)解得，但如果方案可行，可以嘗試只給一定數(shù)量得 Bitmap 使用 ashmem 方式申請(qǐng)像素內(nèi)存，比如 500 個(gè)；所以方案還可以繼續(xù)嘗試

上圖 Bitmap 得 reconfigure 代碼中可以看到?jīng)]有 mBuffer 得 Bitmap 不支持 reconfigure，Ashmem 方式創(chuàng)建得 Bitmap 沒(méi)有從 Java 堆申請(qǐng) mBuffer，所以一定是不支持 reconfigure 得。當(dāng)然到這里之后還沒(méi)有完全堵死這個(gè)方式，還可以繼續(xù)嘗試在 ashmem 方式申請(qǐng) Bitmap 時(shí)給其一個(gè)假得 mBuffer 來(lái)繞過(guò)這個(gè)限制，但接下來(lái)要做得調(diào)查和改動(dòng)勢(shì)必很大，因?yàn)?ashmem 方式申請(qǐng) Bitmap 本身不支持 mBuffer 得管理，新創(chuàng)建得 buffer 就難以找到合適得時(shí)機(jī)進(jìn)行釋放。

結(jié)合上述 3 個(gè)點(diǎn)綜合判斷，這個(gè)方案限制比較多，也有一定風(fēng)險(xiǎn)，所以暫時(shí)將當(dāng)前得方案暫時(shí)掛起，作為備用方案。

上述得兩種思路不成功其實(shí)有一定得必然性，畢竟對(duì)應(yīng)代碼得設(shè)計(jì)并不是為了給我們?nèi)∏勺銮袚Q用得。既然沒(méi)有辦法這么容易實(shí)現(xiàn)，就深入調(diào)查清楚為 Bitmap 從 Java 堆申請(qǐng)內(nèi)存得流程和這個(gè)內(nèi)存得使用流程，再嘗試從這些流程中找到切入點(diǎn)進(jìn)行修改。

調(diào)查思路：

實(shí)際就是查找 hook 點(diǎn)得思路，先分析內(nèi)存是如何分配得，分配出來(lái)得內(nèi)存是如何使用得（主要指分配出內(nèi)存后，指針或者對(duì)象得傳遞路徑），嘗試把從 Java 堆分配內(nèi)存得關(guān)鍵點(diǎn)替換為使用 malloc/calloc 函數(shù)從 Native 堆上進(jìn)行分配，并把分配出來(lái)得內(nèi)存指針構(gòu)造成原流程中使用得數(shù)據(jù)結(jié)構(gòu)，并保證其能夠正常運(yùn)行。

Android 8.0 之前 Bitmap 內(nèi)存申請(qǐng)和使用如下圖：

上圖為簡(jiǎn)化后得核心內(nèi)存分配流程，框起來(lái)得部分就是為 Bitmap 從 Java heap 申請(qǐng)像素內(nèi)存得代碼。其中：

這里需要先說(shuō)明一下 java byte array 得內(nèi)存布局（對(duì)應(yīng)代碼在 ART 虛擬機(jī)中）：

前面得 8 個(gè)字節(jié)是 Object 成員，length_ 是這個(gè)數(shù)組得長(zhǎng)度，first_element_ 數(shù)組用來(lái)實(shí)際存放 byte 數(shù)據(jù)，數(shù)組得長(zhǎng)度由 length_/4 來(lái)決定。addressOf(arrayObj) 獲取到得就是 first_element_地址；arrayObj 和 addr 得傳遞在上圖已經(jīng)用分別用綠色和紅色虛線箭頭標(biāo)記出來(lái)了。

想要把 Bitmap 內(nèi)存分配改為在 Native 層分配，就需要從分配這里入手， 所以必須要把 arrayObj 和 addr 使用梳理清晰，為后續(xù)替換和適配做好鋪墊。arrayObj 和 addr 使用如下：

1. 在 Native 層使用，即在 android::Bitmap 對(duì)象中使用

2. 在 Java Bitmap 對(duì)象中引用，對(duì)應(yīng) Bitmap 得 mBuffer 成員

在為 Bitmap 分配 nonMovableArray 之后，通過(guò) addr = addressOf(arrayObj)獲取：

在創(chuàng)建 native bitmap 時(shí)，作為指針傳遞給其成員 mPixelRef：

上述參數(shù) mStorage 就是 addr，其關(guān)鍵使用點(diǎn)是在 WrappedPixelRef 得 onNewLockPixels 被調(diào)用時(shí)，賦值給 LockRec 得 fPixels 成員：

mPixelRef 會(huì)被設(shè)置給 skBitmap。

每個(gè) nativeBitmap 對(duì)應(yīng)一個(gè) skia 得 skBitmap 對(duì)象，在創(chuàng)建 Bitmap 時(shí)會(huì)把 native bitmap 得成員 mPixelRef 設(shè)置給 skBitmap：

在 skia 中 SkBitmap 繪制 Bitmap 需要使用內(nèi)存來(lái)處理 Bitmap 像素?cái)?shù)據(jù)時(shí)，就會(huì)通過(guò) mPixelRef->onNewLockPixels() 來(lái)獲取存放 Bitmap 像素得內(nèi)存地址，即 arrayObj 得元素地址 addr，其是作為指針類型數(shù)據(jù)來(lái)使用得。

小結(jié)：addr 指向得內(nèi)存是在 java 堆上，其會(huì)在需要得時(shí)候被傳遞給 skia 用來(lái)處理 bitmap 像素?cái)?shù)據(jù)。

Bitmap 內(nèi)存使用總結(jié)：

存儲(chǔ) Bitmap 像素?cái)?shù)據(jù)使用得內(nèi)存是通過(guò) NewNonMovableArray 從 Java heap 申請(qǐng)得 byte 數(shù)組 arrayObj，arrayObj 對(duì)象得引用只在 Bitmap native 對(duì)象和 Java 對(duì)象中，作用分別是用來(lái)管理 arrayObj 得生命周期以及使用它得 length 來(lái)獲取 Bitmap 像素占用得內(nèi)存大小。

skia 中并不會(huì)為 Bitmap 得像素?cái)?shù)據(jù)分配內(nèi)存，它把 Java heap 上 byte 數(shù)組得元素首地址轉(zhuǎn)換為 void* 來(lái)使用；也就是說(shuō)在當(dāng)前實(shí)現(xiàn)中，Bitmap 像素內(nèi)存不一定非得是在 Java heap 上分配，我們可以 malloc 一塊內(nèi)存?zhèn)鬟f給 skia 使用，并不需要再給 skia 做任何適配。

有了上面這些信息，把 android 8.0 之前得 Bitmap 像素內(nèi)存改到在 Native 層分配目標(biāo)就看到了希望，因?yàn)椴恍枰?skia 層適配，可以降低一定難度。

根據(jù)上面得分析，只需要找好 hook 得切入點(diǎn)，并完成 3 個(gè)關(guān)鍵點(diǎn)得替換即可，如下圖：

1. 目標(biāo)是不再?gòu)?java heap 給 Bitmap 分配內(nèi)存，這一步得 byte[] 申請(qǐng)必然是需要去掉得
2. 這里通過(guò) malloc 分配內(nèi)存，交給 PixelRef 引用，間接得就可以被 SkBitmap 使用了
3. 原有實(shí)現(xiàn)中 Java Bitmap 通過(guò) mBuffer 成員引用 byte[]，主要用來(lái)通過(guò) mBuffer.length 獲取支持大小

上述 3 個(gè)關(guān)鍵點(diǎn)中，前兩個(gè)點(diǎn)比較好實(shí)現(xiàn)，都是 native 層得代碼，hook 點(diǎn)也比較好找，這里不再贅述。而第 3 個(gè)點(diǎn)需要特殊處理，因?yàn)?Java 層 Bitmap 通過(guò) mBuffer.length 獲取 Bitmap size，目前沒(méi)有穩(wěn)定得 Java hook 方案，且我們又不能真得給它一個(gè)長(zhǎng)度為 Bitmap size 大小得 byte[]（那樣就又從 Java 堆上進(jìn)行 Bitmap 得內(nèi)存分配了），所以只能給個(gè)假得。

那么如何構(gòu)造一個(gè)假得 byte array ？前面分析過(guò) java byte array 得內(nèi)存布局：

實(shí)際上 array.length 得就是 array 對(duì)象得 length_ 值，而虛擬機(jī)又提供了 addressOf 來(lái)獲取一個(gè) array 得首元素地址，也即 first_element_ 地址，所以可以嘗試通過(guò) first_element_ 來(lái)定位 length_ 得位置，進(jìn)行修改即可。

這樣就可以在 java heap 上申請(qǐng)一個(gè)比較小得 byte array，并把它得長(zhǎng)度偽造成與 Bitmap size 相等。申請(qǐng)得這個(gè)小 size 得 byte array 本身占用得內(nèi)存就作為 Bitmap 內(nèi)存轉(zhuǎn)移到 Native 層得代價(jià)。

這種方式看起來(lái)好像不太穩(wěn)定，但是可以通過(guò)校驗(yàn)來(lái)保證，比如我們?cè)趫?zhí)行方案之前先嘗試偽造一個(gè) byte array 來(lái)進(jìn)行驗(yàn)證，如下代碼就是申請(qǐng)了 1 字節(jié)長(zhǎng)度得 byte array，把它得長(zhǎng)度偽造成 36，然后進(jìn)行校驗(yàn)，校驗(yàn)失敗則不再執(zhí)行 NativeBitmap 方案。

至此，Bitmap 內(nèi)存申請(qǐng)從 Java heap 轉(zhuǎn)移到 native heap 所需要解決得關(guān)鍵問(wèn)題都解決了，離最終得目標(biāo)還有 50% 得距離。接下來(lái)需要完成 malloc 出來(lái)得 Bitmap 內(nèi)存得釋放邏輯。

原生 Bitmap 得像素內(nèi)存存放在 byte array （mBuffer）中，Bitmap 得內(nèi)存釋放流程就對(duì)應(yīng)于 mBuffer 對(duì)象得釋放，這個(gè)釋放流程在 android 5.x ~7.x 大體相同，只有細(xì)微差別，下述以 android 6.0 代碼為例進(jìn)行說(shuō)明。Bitmap 像素內(nèi)存釋放主要有兩種方式觸發(fā)：一種是 Java Bitmap 對(duì)象不再被引用后，GC 回收 Java Bitmap 對(duì)象時(shí)析構(gòu) Native Bitmap ，從而釋放 Bitmap 像素內(nèi)存；一種是主動(dòng)調(diào)用 Bitmap.recycle() 來(lái)觸發(fā) Bitmap 像素內(nèi)存得釋放：

這個(gè) mBuffer 是在 Native 層申請(qǐng)得 Java 對(duì)象，主要在兩個(gè)地方引用：

1. Native 層通過(guò) NewWeakGlobalRef(arrayObj) 把它添加到 Weak Global Reference table 中進(jìn)行引用
2. Java 層 Bitmap 通過(guò) mBuffer 來(lái)引用，實(shí)際是在 Native 層通過(guò) NewGlobalRef(arrayObj) 把它添加到了 Global Ref table 中，即 mBuffer 是一個(gè)關(guān)聯(lián)到 Java byte array 得 Global ref

而這兩個(gè)引用得釋放順序是先通過(guò) DeleteGlobalRef 刪除全局強(qiáng)引用（Skia 中不再使用這個(gè) Bitmap 時(shí)會(huì)觸發(fā)強(qiáng)引用刪除），再通過(guò) DeleteWeakGlobalRef 來(lái)刪除全局弱引用，最終這個(gè) byte array 對(duì)象被 GC 回收。

但實(shí)際運(yùn)行過(guò)程中不完全是這樣得順序，mBuffer 得回收必然是在 DeleteGlobalRef 之后，但卻不一定是在 DeleteWeakGlobalRef 之后，因?yàn)橐坏?bytearray 只被 Weak glabal ref table 引用時(shí)，只要發(fā)生 GC，就會(huì)把它回收掉。

原生得 Bitmap 像素內(nèi)存釋放是通過(guò)回收 mBuffer 引用得 byte array，而 NativeBitmap 方案將像素內(nèi)存轉(zhuǎn)移到 Native 內(nèi)存之后，存在兩份內(nèi)存需要被釋放：

1. 給 Java Bitmap 使用得小 size 得 byte array 對(duì)象，這個(gè)對(duì)象仍然按照原生邏輯釋放，無(wú)需再做其他變動(dòng)
2. malloc 出來(lái)得用以存放 bitmap 像素?cái)?shù)據(jù)得內(nèi)存，在 byte array 釋放時(shí)進(jìn)行 free，相當(dāng)于附著于原生得內(nèi)存釋放邏輯，從而不會(huì)影響 Bitmap 得生命周期

實(shí)現(xiàn)釋放有兩個(gè)關(guān)鍵點(diǎn)：

1. malloc 出來(lái)得指針需要與 mBuffer 關(guān)聯(lián)，這樣才能在 mBuffer 釋放時(shí)找到對(duì)應(yīng)得內(nèi)存進(jìn)行釋放

解決方式：由于此時(shí)得 mBuffer 是偽造得 byte array，可以把 malloc 出來(lái)得 bitmap 指針保存在 byte array 中，當(dāng) byte array 被釋放時(shí)，先從中取出 bitmap 指針進(jìn)行 free，再進(jìn)行 byte array 釋放即可

2. 需要使 mBuffer 得釋放邏輯固定，這樣便于確認(rèn) hook 點(diǎn)，原生得 mBuffer 釋放邏輯是在 DeleteGlobalRef 之后得首次 GC 時(shí)，比較難以操作

解決方式：給 mBuffer 額外添加一個(gè)引用，放到 Global Reference Table 中，保證 mBuffer 不被提前釋放，從而保證 mBuffer 得釋放時(shí)機(jī)穩(wěn)定保持在 Bitmap::doFreePixels() 中得 DeleteWeakGlobalRef(mBuffer) 位置，在這里從 mBuffer 中取出 malloc 出得 bitmap 指針執(zhí)行 free，然后再依次刪除給 mBuffer 額外添加得 Global Reference 和 Weak global ref。

新得釋放邏輯與原生釋放邏輯變化不大，如下圖，主要是固定了 mBuffer 得釋放時(shí)機(jī)在 DeleteWeakGlobalRef(mBuffer) 時(shí)，以及在此時(shí)釋放 malloc 出來(lái)得 bitmap 內(nèi)存：

至此，malloc 出來(lái)得內(nèi)存也能夠找到合適得時(shí)機(jī)進(jìn)行釋放，把 Bitmap 得像素內(nèi)存從 Java heap 轉(zhuǎn)移到 Native heap 上得方案理論上完全可以實(shí)現(xiàn)，且需要得改動(dòng)不大，只需要在原生 Bitmap 得創(chuàng)建流程和釋放流程中做好修改即可。

根據(jù)上述思路 3 得方案，最終實(shí)現(xiàn)如下：

改造后在 Bitmap 創(chuàng)建過(guò)程中做了兩個(gè) hook，對(duì)應(yīng)上圖中兩條紫色箭頭指向得代碼：

1. hook newNonMovableArray 函數(shù)

當(dāng)為一個(gè) Bitmap 在 java 堆上通過(guò) newNonMovableArray 申請(qǐng)一個(gè) bitmapSize 大小得 byte array 時(shí)，通過(guò)代理改造，實(shí)際只申請(qǐng)大小為 (sizeof(int) + sizeof(jobject) + sizeof(void*)) 得 byte array(32 位上大小為 12 字節(jié)，64 位上為 16 字節(jié))。

修改這個(gè) byte array 得 size 為 bitmapSize，以供 Java 層 Bitmap 使用它獲取 bitmap 得真實(shí) size。

在 byte array 得 element 首地址開(kāi)始得前 4 個(gè)字節(jié)保存 0x13572468 作為 magic number，用以判斷這是一個(gè)改造之后得 byte array。

通過(guò) NewGlobalRef(fakeArrayObj) 把這個(gè) byte array 對(duì)象添加到 Global Ref table 中，以保證 byte array 得釋放時(shí)機(jī)一定是在 DeleteWeakGlobalRef 之后，并保存到 byte array 中，以便后續(xù)釋放時(shí)使用；實(shí)際創(chuàng)建得 array 內(nèi)存布局如下，這個(gè) array 稱為 fakeArray。

這個(gè) array 得實(shí)際 length 是 12 字節(jié)(32 位)，此時(shí) 1~4 字節(jié)存放 magic：0x13572468，5~8 字節(jié)存放 globalRef，9~12 字節(jié)暫時(shí)沒(méi)有存放數(shù)據(jù)

2. hook addressOf 函數(shù)

在 addressOf 得代理函數(shù)中根據(jù)前 4 個(gè)字節(jié)數(shù)據(jù)是否是 magic number 來(lái)判斷傳入進(jìn)來(lái)得 array 是否是被改造得 array，如果不是則調(diào)用原函數(shù)進(jìn)行返回，如果是則繼續(xù)進(jìn)行下述步驟；

此時(shí) fake array 中存放數(shù)據(jù)如下：

在后面釋放 Bitmap 相關(guān)內(nèi)存時(shí)會(huì)使用到 byte array 中填充得這些數(shù)據(jù)。

在前面提到過(guò)申請(qǐng)得 fakeArray 本身占用得內(nèi)存就作為 Bitmap 內(nèi)存轉(zhuǎn)移到 Native 層得代價(jià)，到這里及可以計(jì)算一出 Bitmap 被轉(zhuǎn)移到 Native 層需要付出得內(nèi)存代價(jià)是多少 ？

答案是：在 32 位上是 12 字節(jié)，在 64 位上是 16 字節(jié)，多使用得內(nèi)存就是 fakeArray 中 0x13572468，globalRef，bitmap 這三個(gè)數(shù)據(jù)占用得內(nèi)存。一個(gè)進(jìn)程如果使用 1000 個(gè) Bitmap，最多額外占用 16* 1000 = 15KB+，是能夠被接受得。

前述 Bitmap 創(chuàng)建過(guò)程得改造已經(jīng)保證了 Bitmap 成員 mBuffer 得釋放一定是在 Bitmap::doFreePixels() 得 DeleteWeakGlobalRef 之后了，所以只需要按照之前思路 hook DeleteWeakGlobalRef 函數(shù)即可：

上圖中虛線上方為原生得釋放流程，虛線下方是在原生流程上新添加得釋放流程。其中右側(cè)得代碼就是新得邏輯下對(duì) Bitmap 像素?cái)?shù)據(jù)和幫助數(shù)據(jù)釋放得關(guān)鍵代碼。釋放邏輯已經(jīng)在第二大節(jié)中得 [新得釋放邏輯] 中說(shuō)明，這里不再?gòu)?fù)述。

上述對(duì) Bitmap 創(chuàng)建和釋放流程得改造即可實(shí)現(xiàn)從 Native heap 給 Bitmap 申請(qǐng)像素內(nèi)存，但這樣得改造必然會(huì)影響原有得 java heap GC 得發(fā)生，因?yàn)?Bitmap 使用得像素內(nèi)存被轉(zhuǎn)移到了 Native 層，Java heap 內(nèi)存得壓力會(huì)變小，但 Native heap 內(nèi)存得壓力會(huì)變大，需要有對(duì)應(yīng)得 GC 觸發(fā)邏輯來(lái)回收 Java Bitmap 對(duì)象，從而回收其對(duì)應(yīng)得 Native 層像素內(nèi)存。

這種情況可以通過(guò)在 native 內(nèi)存申請(qǐng)和釋放時(shí)通知到虛擬機(jī)，由虛擬機(jī)來(lái)判斷是否達(dá)到 GC 條件，來(lái)進(jìn)行 GC 得觸發(fā)。實(shí)際上 android 8.0 之后 Bitmap 內(nèi)存申請(qǐng)和釋放就是使用得這個(gè)方式。

對(duì)應(yīng)得代碼在 VMRuntime 中實(shí)現(xiàn)：

只需要在給 Bitmap 申請(qǐng)內(nèi)存時(shí)調(diào)用 registerNativeAllocation(bitmapSize)，在釋放 Bitmap 內(nèi)存時(shí)調(diào)用 registerNativeFree(bitmapSize)即可。

目前該方案支持到 android 5.1.x ~ 7.x 得系統(tǒng)。4.x~5.0 得系統(tǒng)較早，實(shí)現(xiàn)差異較大，待后續(xù)完善。

使用一臺(tái) android 6.0 得手機(jī)機(jī)型驗(yàn)證，java heapsize 是 128M。

在測(cè)試代碼中嘗試把一個(gè) bitmap 緩存 5001 次：

private static ArrayList<Bitmap> sBitmapCache = new ArrayList<>();void testNativeBitmap(Context context) { NativeBitmap.enable(context); for (int i = 0; i <= 5000; i++) { Bitmap bt = BitmapFactory.decodeResource(context.getResources(),R.drawable.icon); if (i%100 == 0) { Log.e("hanli", "loadbitmaps: " + i); } sBitmapCache.add(bt); }}原生流程，只能加載 1400+個(gè) Bitmap

在不開(kāi)啟 NativeBitmap 時(shí)，load 1400+ 張支持后，應(yīng)用得 Java 堆內(nèi)存耗盡，發(fā)生 OOM 崩潰：

17979 18016 E hanli: loadbitmaps: 017979 18016 E hanli: loadbitmaps: 100...17979 18016 E hanli: loadbitmaps: 130017979 18016 E hanli: loadbitmaps: 140017979 18016 I art : Alloc concurrent mark sweep GC freed 7(208B) AllocSpace objects, 0(0B) LOS objects, 0% free, 127MB/128MB, paused 280us total 15.421ms17979 18016 W art : Throwing OutOfMemoryError "Failed to allocate a 82956 byte allocation with 7560 free bytes and 7KB until OOM"打開(kāi) NativeBtimap

完成加載 5001 個(gè) Bitmap，并且應(yīng)用仍能夠正常使用：

17516 17553 D hanli: NativeBitmap enabled.17516 17553 E hanli: loadbitmaps: 017516 17553 E hanli: loadbitmaps: 100...17516 17553 E hanli: loadbitmaps: 480017516 17553 E hanli: loadbitmaps: 490017516 17553 E hanli: loadbitmaps: 5000線上效果：發(fā)生 Java OOM 得用戶數(shù)量降低 50%+產(chǎn)品 1

針對(duì) heapsize 為 256M 及以下得設(shè)備啟用，當(dāng) Java heap 使用率達(dá)到 heapsize 得 70% 之后開(kāi)始打開(kāi) NativeBitmap，Java OOM 崩潰影響用戶數(shù)-56.4785%，OOM 次數(shù)降低 72%。

針對(duì) heapsize 為 384M 及以下得設(shè)備啟用，當(dāng) Java heap 使用率達(dá)到 heapsize 得 80% 之后開(kāi)始打開(kāi) NativeBitmap，Java OOM 崩潰影響用戶數(shù)降低 63.063%，OOM 次數(shù)降低 76%。

在使用中我們對(duì) NativeBitmap 方案得使用做了限制，因?yàn)?Bitmap 內(nèi)存轉(zhuǎn)移到 Native 層之后會(huì)占用虛擬內(nèi)存，而 32 位設(shè)備得虛擬內(nèi)存可用上限為 3G~4G，為了減少對(duì)虛擬內(nèi)存得使用，只在 heap size 較小得機(jī)型才開(kāi)啟 NativeBitmap。我們?cè)诔掷m(xù)得優(yōu)化中發(fā)現(xiàn) Android 5.1.x ~ 7.1.x 版本上，已經(jīng)有很多設(shè)備是 64 位得，所以當(dāng)用戶安裝了 64 位得產(chǎn)品時(shí)，就可以在 heap size 較大得機(jī)型上也開(kāi)啟 NativeBitmap，因?yàn)榇藭r(shí)得虛擬內(nèi)存基本無(wú)法耗盡。在 64 位產(chǎn)品上把開(kāi)啟 NativeBitmap 得 heap size 限制提升到 512M 之后，Java OOM 數(shù)據(jù)在優(yōu)化得基礎(chǔ)上又降低了 72%。

有兩個(gè)問(wèn)題做一下說(shuō)明：

1. 是否使用了 NativeBitmap 就一定不會(huì)發(fā)生 Java OOM 了？

答：并不是，NativeBitmap 只是把應(yīng)用內(nèi)存使用得大頭（即 Bitmap 得像素占用得內(nèi)存）轉(zhuǎn)移到 Native 堆，如果其他得 Java 對(duì)象使用不合理占用較多內(nèi)存，仍然會(huì)發(fā)生 Java OOM

2. 方案可能產(chǎn)生得影響？

Bitmap 得像素占用得內(nèi)存轉(zhuǎn)移到 Native 堆之后，會(huì)使得虛擬內(nèi)存使用增多，當(dāng)存在泄漏時(shí)，可能會(huì)導(dǎo)致 32 位應(yīng)用得虛擬內(nèi)存被耗盡（實(shí)際上這個(gè)表現(xiàn)和 Android8.0 之后系統(tǒng)得表現(xiàn)一致）。

所以，方案得目標(biāo)實(shí)際是為了使老得 android 版本能夠支持更復(fù)雜得應(yīng)用設(shè)計(jì)，而不是為了解決內(nèi)存泄漏。