作者 ｜ 抖音基礎(chǔ)技術(shù)團(tuán)隊(duì)

一、背景和目標(biāo)

背景

作為 Android 開發(fā)者，相信大家都碰到過 Java OOM 問題，導(dǎo)致 OOM 的原因可能是應(yīng)用存在內(nèi)存泄漏，也可能是因?yàn)槭謾C(jī)的 heapsize 比較小不能滿足復(fù)雜應(yīng)用對(duì)內(nèi)存資源的大量需求。對(duì)于 Java 內(nèi)存泄漏治理，業(yè)界已經(jīng)有比較成熟的方案，這里不做介紹，本文主要針對(duì)第二點(diǎn)嘗試進(jìn)行分析和優(yōu)化。

舉個(gè)例子：我們?cè)诒O(jiān)控平臺(tái)查看穩(wěn)定性數(shù)據(jù)，發(fā)現(xiàn) heapsize=256M 的設(shè)備發(fā)生的 OOM 崩潰最多，而 heapsize=512M 的設(shè)備很少發(fā)生 OOM 崩潰。且除此之外，還有一個(gè)特點(diǎn)：OOM 崩潰絕大多數(shù)發(fā)生在 Android 8.0 之前的設(shè)備。

對(duì)于這種 heapsize 較小難以滿足業(yè)務(wù)復(fù)雜度的情況，可能有以下幾種方式來解決：

1. 增加 heapsize

如果我們已經(jīng)設(shè)置了 largeHeap，也就沒有常規(guī)的提升 heapsize 的方式了;再想往前一步，可以嘗試從虛擬機(jī)中突破這個(gè)限制，因?yàn)? heapsize 是虛擬機(jī)的配置，是否拋出 OOM 異常也是在虛擬機(jī)中決定的;修改虛擬機(jī)運(yùn)行邏輯是有一定可能的，但是其難度和可行性與想要修改的內(nèi)容相關(guān)性較大，修改方案的穩(wěn)定性也需要非常深厚的功力才能保證，而如果運(yùn)氣不好，找不到好的切入點(diǎn)，甚至從理論上都無法保證其穩(wěn)定性，那么達(dá)到上線的難度就更大了，本文不在這個(gè)方向深入。

2. 降低業(yè)務(wù)復(fù)雜度，裁剪應(yīng)用功能

這個(gè)方案也不在我們的考慮范圍之內(nèi)，實(shí)際上很多應(yīng)用都有推出極速版，但是功能都會(huì)有所裁剪，對(duì)于使用常規(guī)版本的用戶，我們也不能推送極速版，因?yàn)槭褂皿w驗(yàn)會(huì)有很大變化。

3. 分析 Java Heap 里的內(nèi)容都是什么，嘗試發(fā)現(xiàn)主要矛盾進(jìn)行優(yōu)化，對(duì)癥下藥

實(shí)際上本文就是從這個(gè)方向經(jīng)過調(diào)查后，找到了一個(gè)相對(duì)穩(wěn)定的突破口。下面是結(jié)合 OOM 堆棧、android 版本、heapsize 維度對(duì) OOM 整體概況的一個(gè)分析：

最常見 OOM 堆棧

出現(xiàn)最多的堆棧就是 Bitmap 創(chuàng)建時(shí)內(nèi)存不足從而 OOM 崩潰，那么是不是已使用的內(nèi)存大多都是 Bitmap 呢 ?不能 100%確定，因?yàn)橹苯佑|發(fā) OOM 崩潰的原因是最后一次內(nèi)存分配失敗，而真正的原因是 OOM 之前的內(nèi)存分配;但是仍然有一定可能性，因?yàn)榭偸浅霈F(xiàn)同一個(gè)堆?？赡懿⒉皇乔珊?，可以在一定程度上說明這個(gè)堆棧執(zhí)行的比較頻繁，而且 Bitmap 一般占用內(nèi)存較大。

這里先做一個(gè)不 100%確認(rèn)的初步推斷：OOM 時(shí) Java heap 中占用內(nèi)存較多的對(duì)象是 Bitmap。

OOM 在不同 android 版本、heapsize 上的表現(xiàn)

繼續(xù)對(duì) OOM 數(shù)據(jù)做總結(jié)后發(fā)現(xiàn)了 OOM 的分布規(guī)律如下圖：

上圖紅色地雷代表 OOM，橫坐標(biāo)是 android 版本，縱坐標(biāo)是 heapsize，原點(diǎn)是：(android8.0， 384M);可以看到：

• 第一、四象限，OOM 最少;對(duì)應(yīng) android 高版本，大 heapsize 和小 heapsize 都有
• 第二象限有一定 OOM;對(duì)應(yīng) android 低版本，大 heapsize
• 第三象限 OOM 最多;對(duì)應(yīng) android 低版本，小 heapsize

簡(jiǎn)單總結(jié)就是：

• heapsize 越大越不容易 OOM
• Android8.0 及之后的版本更不容易 OOM

第四象限的數(shù)據(jù)說明，即便在 heapsize 較小的情況下，在 android 8.0 之后的版本上也不容易發(fā)生 OOM，結(jié)合上面的初步推斷信息“OOM 時(shí) Java heap 中占用內(nèi)存較多的對(duì)象是 Bitmap”，很容易想到，應(yīng)該是 Bitmap 在 android 8.0 前后的實(shí)現(xiàn)變化導(dǎo)致了當(dāng)前的 OOM 分布現(xiàn)象：

Bitmap 變化：

• 在 Android 8.0 之前，Bitmap 像素占用的內(nèi)存是在 Java heap 中分配的
• Android 8.0 及之后，Bitmap 像素占用的內(nèi)存分配到了 Native Heap

由于 Native heap 的內(nèi)存分配上限很大，32 位應(yīng)用的可用內(nèi)存在 3~4G，64 位上更大，虛擬內(nèi)存幾乎很難耗盡，所以在前面的推測(cè) “OOM 時(shí) Java heap 中占用內(nèi)存較多的對(duì)象是 Bitmap” 成立的情況下，應(yīng)用更不容易 OOM。

而第三象限數(shù)據(jù)，則進(jìn)一步佐證了前面的推測(cè)，Android 8.0 之前，Bitmap 像素內(nèi)存在 Java heap 中分配時(shí)，即便 heap size 大到 512M，OOM 發(fā)生也比較多。

至此，得到了確定的結(jié)論：

• OOM 的分布主要在 Android 8.0 之前 heap size 較小的設(shè)備
• OOM 時(shí) Java heap 中占用內(nèi)存較多的是 Bitmap(確切的說是 Bitmap 的像素?cái)?shù)據(jù))，當(dāng) Bitmap 像素占用內(nèi)存在 Native Heap 分配時(shí)，即便 heap size 很小，應(yīng)用也不容易 OOM

目標(biāo)

根據(jù)上述結(jié)論，目標(biāo)也就比較清晰了：

• 使 Android 8.0 之前 Bitmap 的像素內(nèi)存也從 Native 層分配，從而減少 Java OOM 崩潰。

二、Bitmap 使用分析和方案調(diào)查

想要使得 Android 8.0 之前的設(shè)備 Bitmap 像素內(nèi)存也分配在 Native heap，需要先把 Bitmap 的創(chuàng)建流程調(diào)查清楚。

Bitmap 創(chuàng)建流程

如下堆棧描述了 Bitmap 的創(chuàng)建：

Bitmap 的構(gòu)造方法是不公開的，在使用 Bitmap 的時(shí)候，一般都是通過 Bitmap、BitmapFactory 提供的靜態(tài)方法來創(chuàng)建 Bitmap 實(shí)例。下圖中以 Bitmap.createBitmap 說明了 Bitmap 對(duì)象的主要?jiǎng)?chuàng)建過程：

從上圖可以看到 Java Bitmap 對(duì)象是在 Native 層通過 NewObject 創(chuàng)建的。圖中的兩個(gè)函數(shù)：

• allocateJavaPixelRef，是 8.0 之前版本為 Bitmap 像素從 Java heap 申請(qǐng)內(nèi)存
• allocateHeapBitmap，是 8.0 版本為 Bitmap 像素從 Native heap 申請(qǐng)內(nèi)存

allocateJavaPixelRef 函數(shù)的實(shí)現(xiàn)

allocateJavaPixelRef 通過 newNonMovableArray 從 Java 堆上為 Bitmap 像素分配內(nèi)存，然后再構(gòu)造 Native Bitmap 對(duì)象，對(duì)應(yīng)的構(gòu)造函數(shù)如下：

構(gòu)造函數(shù)中發(fā)現(xiàn) Native Bitmap 構(gòu)造時(shí)對(duì)應(yīng)的 mPixelStorageType 是 PixelStorageType::Java，表示 Bitmap 的像素是保存在 Java 堆上，所以嘗試看下 PixelStorageType 總共有幾種，是否可能有把 pixels 數(shù)據(jù)存儲(chǔ)到 Native 層。查找代碼發(fā)現(xiàn) PixelStorageType 只有三類，如下：

這個(gè)信息可以作為一個(gè)切入點(diǎn)，在后面進(jìn)行深入調(diào)查。

allocateHeapBitmap 實(shí)現(xiàn)

allocateHeapBitmap 主要是通過 calloc 為 Bitmap 的像素分配內(nèi)存，這個(gè)分配就在 Native 堆上了。

通過初步的分析，初步有兩個(gè)思路可以先進(jìn)行嘗試：

• 在創(chuàng)建 Bitmap 時(shí)，把對(duì) allocateJavaPixelRef 的調(diào)用替換為調(diào)用 allocateHeapBitmap 來達(dá)到從 Native 層分配內(nèi)存的目的
• 調(diào)查 PixelStorageType 共有哪些種類，是否可能從當(dāng)前的保存到 Java 堆切換為保存到 Native 堆

思路 1：allocateJavaPixelRef 替換為 allocateHeapBitmap

這個(gè)思路看起來想要實(shí)現(xiàn)目標(biāo)，做一下替換就可以了，但實(shí)際上沒有這么簡(jiǎn)單，存在的問題如下：

• allocateHeapBitmap 返回的是 skBitmap，allocateJavaPixelRef 返回的是 android::Bitmap，類型并不匹配
• 并不是簡(jiǎn)單的插拔就可以把 allocateJavaPixelRef 替換為 allocateHeapBitmap，8.0 之前的 Android 版本上沒有 allocateHeapBitmap 的實(shí)現(xiàn)。如果想要為 8.0 之前的系統(tǒng)寫一個(gè)全新的實(shí)現(xiàn)，只是參數(shù)的獲取就需要做很多適配，比如無法直接使用 skia 中的 SkBitmap、SkColorTab、SkImageInfo，就沒有辦法動(dòng)態(tài)獲取到要分配的內(nèi)存 size
• Bitmap 內(nèi)存的申請(qǐng)和釋放要有匹配的邏輯和合適的時(shí)機(jī)

所以這個(gè)思路基本可以斷定不可行。

思路 2：allocateJavaPixelRef 替換為 allocateAshmemPixelRef

前面的調(diào)查發(fā)現(xiàn) PixelStorageType 只有三類，如下：

其中 External 方式存儲(chǔ) Bitmap 像素，在源碼中沒有看到相關(guān)使用，無法參考;Java 類型就是默認(rèn)的 Bitmap 創(chuàng)建方式，像素內(nèi)存分配的 Java 堆上;Ashmem 方式存儲(chǔ) Bitmap 像素的方式在源碼中有使用，主要是在跨進(jìn)程 Bitmap 傳遞時(shí)使用，對(duì)應(yīng)的場(chǎng)景主要是 Notification 和截圖場(chǎng)景：

查看其實(shí)現(xiàn)：

從代碼中看到 allocateAshmemPixelRef 這個(gè)函數(shù)是通過 mmap ashmem 內(nèi)存來創(chuàng)建 native Bitmap 對(duì)象，且參數(shù)、返回值都與 allocateJavaPixelRef 相同，所以使用 Ashmem 方式存儲(chǔ) Bitmap 像素看起來有一定可行性，只需把 allocateJavaPixelRef 的調(diào)用替換為 allocateAshmemPixelRef 即可達(dá)到從 Native 層為 Bitmap 像素分配內(nèi)存的目的。

但經(jīng)過詳細(xì)的源碼分析以及實(shí)際驗(yàn)證，其可行性仍然很低，主要原因如下：

• allocateAshmemPixelRef 實(shí)現(xiàn)只在 android 6.0 ~ android7.1 上存在，所以這個(gè)方案即便能夠?qū)崿F(xiàn)，也只能覆蓋 android 6.0 ~ android 7.1

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

• ashmem 方式存儲(chǔ) Bitmap 像素，每個(gè) Bitmap 需要對(duì)應(yīng)一個(gè) fd，應(yīng)用的 Bitmap 使用數(shù)量是能夠達(dá)到 1000+ 的，這樣可能會(huì)導(dǎo)致 fd 資源使用耗盡，從而發(fā)生崩潰

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

• 最終嘗試后發(fā)現(xiàn)這種方式影響 Bitmap 正常功能(一些視頻動(dòng)圖不能正常展示)，經(jīng)分析主要原因是使用 ashmem 申請(qǐng)的 Bitmap 無法進(jìn)行 reconfigure ：

上圖 Bitmap 的 reconfigure 代碼中可以看到?jīng)]有 mBuffer 的 Bitmap 不支持 reconfigure，Ashmem 方式創(chuàng)建的 Bitmap 沒有從 Java 堆申請(qǐng) mBuffer，所以一定是不支持 reconfigure 的。當(dāng)然到這里之后還沒有完全堵死這個(gè)方式，還可以繼續(xù)嘗試在 ashmem 方式申請(qǐng) Bitmap 時(shí)給其一個(gè)假的 mBuffer 來繞過這個(gè)限制，但接下來要做的調(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用的。既然沒有辦法這么容易實(shí)現(xiàn)，就深入調(diào)查清楚為 Bitmap 從 Java 堆申請(qǐng)內(nèi)存的流程和這個(gè)內(nèi)存的使用流程，再嘗試從這些流程中找到切入點(diǎn)進(jìn)行修改。

思路 3：剖析 Java 堆分配 Bitmap 內(nèi)存的過程，再嘗試找到方案

Bitmap 內(nèi)存申請(qǐng)

調(diào)查思路：

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

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

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

• arrayObj 是通過 newNonMovableArray 從 java heap 分配出來的 byte array 對(duì)象
• addr 是 arrayObj 對(duì)象存放 byte 元素的首地址

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

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

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

arrayObj 的使用

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

在創(chuàng)建 Bitmap 時(shí)，把 arrayObj 添加到 weak global ref tab 中，并通過 Bitmap 的 mPixelStorage.jweakRef 引用 arrayObj：

在 Bitmap 的 pinPixelsLocked 中，把 arrayObj 添加到 global ref tab 中，并保存在 Bitmap 的 mPixelStorage.java.jstrongRef 中：

在 Bitmap 的 unpinPixelsLocked 中，從 global ref tab 中刪除對(duì) arrayObj 的引用：

在 Bitmap 的 doFreePixel 中(即釋放像素內(nèi)存)，刪除 arrayObj 對(duì)應(yīng)的 weak ref：

通過 Bitmap 的成員函數(shù) javaByteArray() 向外部提供引用，即 mPixelStorage.jstrongRef (只在創(chuàng)建 Java Bitmap 對(duì)象時(shí)傳遞為參數(shù)，賦值給 Bitmap 的 mBuffer 成員進(jìn)行使用)

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

在創(chuàng)建 Java Bitmap 時(shí)通過 nativeBitmap->javaByteArray()獲取對(duì) arrayObj 的引用，并賦值給 Java Bitmap 的 成員：private byte[] mBuffer;

在 Bitmap.reconfigure 中，需要使用 arrayObj.length，在 Native 層會(huì)使用這個(gè) length 判斷當(dāng)前的 Bitmap 能否滿足 reconfigure 需求：

在 Bitmap.getAllocationByteCount()中通過 arrayObj.length 獲取這個(gè) Bitmap 的像素內(nèi)存大?。?/p>

小結(jié)：arrayObj 對(duì)象的引用只在 Bitmap native 對(duì)象和 Java 對(duì)象中，作用分別是用來管理 arrayObj 的生命周期以及使用它的 length 來獲取 Bitmap 像素占用的內(nèi)存大小。

addr 的使用

在為 Bitmap 分配 nonMovableArray 之后，通過 addr = addressOf(arrayObj)獲?。?/p>

在創(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)存來處理 Bitmap 像素?cái)?shù)據(jù)時(shí)，就會(huì)通過 mPixelRef->onNewLockPixels() 來獲取存放 Bitmap 像素的內(nèi)存地址，即 arrayObj 的元素地址 addr，其是作為指針類型數(shù)據(jù)來使用的。

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

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

• 存儲(chǔ) Bitmap 像素?cái)?shù)據(jù)使用的內(nèi)存是通過 NewNonMovableArray 從 Java heap 申請(qǐng)的 byte 數(shù)組 arrayObj，arrayObj 對(duì)象的引用只在 Bitmap native 對(duì)象和 Java 對(duì)象中，作用分別是用來管理 arrayObj 的生命周期以及使用它的 length 來獲取 Bitmap 像素占用的內(nèi)存大小。
• skia 中并不會(huì)為 Bitmap 的像素?cái)?shù)據(jù)分配內(nèi)存，它把 Java heap 上 byte 數(shù)組的元素首地址轉(zhuǎn)換為 void* 來使用;也就是說在當(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 層適配，可以降低一定難度。

嘗試從 native 層申請(qǐng) Bitmap 內(nèi)存

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

• 目標(biāo)是不再?gòu)?java heap 給 Bitmap 分配內(nèi)存，這一步的 byte[] 申請(qǐng)必然是需要去掉的
• 這里通過 malloc 分配內(nèi)存，交給 PixelRef 引用，間接的就可以被 SkBitmap 使用了
• 原有實(shí)現(xiàn)中 Java Bitmap 通過 mBuffer 成員引用 byte[]，主要用來通過 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 通過 mBuffer.length 獲取 Bitmap size，目前沒有穩(wěn)定的 Java hook 方案，且我們又不能真的給它一個(gè)長(zhǎng)度為 Bitmap size 大小的 byte[](那樣就又從 Java 堆上進(jìn)行 Bitmap 的內(nèi)存分配了)，所以只能給個(gè)假的。

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

實(shí)際上 array.length 的就是 array 對(duì)象的 length_ 值，而虛擬機(jī)又提供了 addressOf 來獲取一個(gè) array 的首元素地址，也即 first_element_ 地址，所以可以嘗試通過 first_element_ 來定位 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à)。

這種方式看起來好像不太穩(wěn)定，但是可以通過校驗(yàn)來保證，比如我們?cè)趫?zhí)行方案之前先嘗試偽造一個(gè) byte array 來進(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)鍵問題都解決了，離最終的目標(biāo)還有 50% 的距離。接下來需要完成 malloc 出來的 Bitmap 內(nè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)行說明。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() 來觸發(fā) Bitmap 像素內(nèi)存的釋放：

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

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

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

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

新的釋放邏輯

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

• 給 Java Bitmap 使用的小 size 的 byte array 對(duì)象，這個(gè)對(duì)象仍然按照原生邏輯釋放，無需再做其他變動(dòng)
• malloc 出來的用以存放 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 出來的指針需要與 mBuffer 關(guān)聯(lián)，這樣才能在 mBuffer 釋放時(shí)找到對(duì)應(yīng)的內(nèi)存進(jìn)行釋放

解決方式：由于此時(shí)的 mBuffer 是偽造的 byte array，可以把 malloc 出來的 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 出來的 bitmap 內(nèi)存：

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

三、實(shí)現(xiàn)方案

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

Bitmap 創(chuàng)建改造

改造前 Bitmap 的創(chuàng)建和內(nèi)存申請(qǐng)流程：

改造后 Bitmap 的創(chuàng)建和內(nèi)存申請(qǐng)流程：

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

1. hook newNonMovableArray 函數(shù)

當(dāng)為一個(gè) Bitmap 在 java 堆上通過 newNonMovableArray 申請(qǐng)一個(gè) bitmapSize 大小的 byte array 時(shí)，通過代理改造，實(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 首地址開始的前 4 個(gè)字節(jié)保存 0x13572468 作為 magic number，用以判斷這是一個(gè)改造之后的 byte array。

通過 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í)沒有存放數(shù)據(jù)

2. hook addressOf 函數(shù)

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

• 從 array 中獲取 bitmapSize，并通過 calloc(bitmapSize，1) 在 Native 堆上為 Bitmap 分配內(nèi)存;
• 把分配出來的 bitmap 指針保存到 fakeArray 的 9-12 字節(jié)中;
• 把 bitmap 指針返回，由原生邏輯在后續(xù)傳遞給 skia 使用;

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

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

在前面提到過申請(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 釋放改造

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

上圖中虛線上方為原生的釋放流程，虛線下方是在原生流程上新添加的釋放流程。其中右側(cè)的代碼就是新的邏輯下對(duì) Bitmap 像素?cái)?shù)據(jù)和輔助數(shù)據(jù)釋放的關(guān)鍵代碼。釋放邏輯已經(jīng)在第二大節(jié)中的 [新的釋放邏輯] 中說明，這里不再?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ā)邏輯來回收 Java Bitmap 對(duì)象，從而回收其對(duì)應(yīng)的 Native 層像素內(nèi)存。

這種情況可以通過在 native 內(nèi)存申請(qǐng)和釋放時(shí)通知到虛擬機(jī)，由虛擬機(jī)來判斷是否達(dá)到 GC 條件，來進(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

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

四、線下驗(yàn)證和線上效果

線下驗(yàn)證

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

測(cè)試代碼

在測(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

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

17979 18016 E hanli: loadbitmaps: 0
17979 18016 E hanli: loadbitmaps: 100
...
17979 18016 E hanli: loadbitmaps: 1300
17979 18016 E hanli: loadbitmaps: 1400
17979 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.421ms
17979 18016 W art   : Throwing OutOfMemoryError "Failed to allocate a 82956 byte allocation with 7560 free bytes and 7KB until OOM"

打開 NativeBtimap

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

17516 17553 D hanli: NativeBitmap enabled.
17516 17553 E hanli: loadbitmaps: 0
17516 17553 E hanli: loadbitmaps: 100
...
17516 17553 E hanli: loadbitmaps: 4800
17516 17553 E hanli: loadbitmaps: 4900
17516 17553 E hanli: loadbitmaps: 5000

線上效果：發(fā)生 Java OOM 的用戶數(shù)量降低 50%+

產(chǎn)品 1

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

產(chǎn)品 2

針對(duì) heapsize 為 384M 及以下的設(shè)備啟用，當(dāng) Java heap 使用率達(dá)到 heapsize 的 80% 之后開始打開 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ī)型才開啟 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ī)型上也開啟 NativeBitmap，因?yàn)榇藭r(shí)的虛擬內(nèi)存基本無法耗盡。在 64 位產(chǎn)品上把開啟 NativeBitmap 的 heap size 限制提升到 512M 之后，Java OOM 數(shù)據(jù)在優(yōu)化的基礎(chǔ)上又降低了 72%。

五、兩點(diǎn)說明

有兩個(gè)問題做一下說明：

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

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

方案可能產(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)存泄漏。