# 一、前言

筆者最近致力於vivo遊戲中心穩定性維護，在分析線上異常時，發現有相當一部分是由OutOfMemory引起。談及OOM，我們一般都會想到記憶體洩漏，其實，往往還有另外一個因素——圖片，如果對圖片使用不當的話，很容易吃掉大量記憶體，從而導致異常。

尤其是遊戲中心在2020末~2021初的幾個重要版本，上線了很多內容相關的feature，引入大量圖片、影片列表，從而導致線上OOM佔比上升。

在這篇文章中，筆者將講解一張看似普通的Bitmap對記憶體的佔用，介紹Android Studio中幫助我們分析圖片佔用記憶體的工具，舉例說明流行的兩大圖片載入框架：Glide、Picasso在載入圖片時使用記憶體的不同方式，接著分析不同drawable目錄下圖片的顯示策略，最後基於手機記憶體、版本，提出一種最佳化記憶體分配的方案。

# 二、檢視圖片記憶體佔用

一張圖片在記憶體佔用的空間究竟有多少，普遍存在的一個誤解是，圖片本身在磁碟上/從網路下載下來是多大，就會佔用多少的記憶體。這種說法是不正確的，圖片佔用記憶體的大小不取決於它本身的大小，而取決於圖片庫所採用的展示方式所申請的記憶體。

拿鋼鐵俠這張圖片舉例，它的尺寸是350*350，可以看到在電腦磁碟上，它只佔36KB的空間。

![](https://static001.geekbang.org/infoq/14/14e57769cd2c3c187bf635a6362924fa.jpeg)

我們建立一個簡單的Demo，頁面正中央是一個ImageView，用於顯示這張鋼鐵俠圖片。

![](https://static001.geekbang.org/infoq/d7/d71766df61c3579ca07e7ed0a6fc9092.jpeg)

透過Android Studio進行heap dump，從而看圖片所佔用的記憶體。首先我們將顯示圖片時的記憶體快照儲存下來。操作路徑為Profiler -> Memory -> Heap Dump，這會生成一個dump檔案，在其中可以看到當前堆的使用情況。

![](https://static001.geekbang.org/infoq/01/013ea1970c9f032d18b3ed37bb7a2aa4.jpeg)

在下面這張圖可以看到，程式執行時，“鋼鐵俠”這張圖片佔用的記憶體（Retained Size）是2560000bytes，約等於2.4MB記憶體。與它在磁碟上36KB的大小，相差了整整70倍！

![](https://static001.geekbang.org/infoq/57/577d2cc5b30edec69e28505ebaaa32d8.jpeg)

**小技巧：如何檢視dump檔案中的圖片**

在除錯時，如果我們手頭只有一個dump檔案，往往需要還原圖片內容，以幫助定位問題。有兩種方式可以從dump檔案裡提取原圖片。

**方式一：透過Android Studio直接檢視**

如果dump檔案來源自Android版本為7.1.1（Android N，API=25）及以下的裝置，可以使用這種方法。選中Bitmap物件，直接在視窗的Bitmap Preview中檢視圖片內容（如上圖），非常方便。

**方式二：透過MAT+GIMP檢視**

![](https://static001.geekbang.org/infoq/38/38756f0ec29f8c58b01cdea00c643f9a.png)

這種方法適用於全部Android版本的裝置，首先用[MAT](https://www.eclipse.org/mat/)開啟dump檔案，有時會發生下圖的錯誤：

![](https://static001.geekbang.org/infoq/55/55f9118ce801b541b483b304f970b1ba.jpeg)

原因是Android Studio的Profiler生成的dump檔案不是標準格式，我們可以使用位於路徑SDK/platform-tools/hprof-conv.exe的工具將其轉換為標準格式，轉換命令為：

```java
hprof-conv.exe <in-file> <out-file>

```

將轉換後的dump檔案透過MAT開啟，在其中找到Bitmap物件的byte\[\]屬性，將其複製為image01.data檔案。

![](https://static001.geekbang.org/infoq/89/8912505bad9928701b735ebe1f4a2a37.jpeg)

> Tip: 可以看到這裡image01.data檔案的尺寸是2.44MB，也正是在執行時圖片所佔用的記憶體。

然後用[GIMP](https://www.gimp.org/downloads/)工具開啟該檔案，在格式那裡選擇RGBA（大部分Bitmap都使用這種格式），寬與高可以在MAT中看到，筆者這裡是800 * 800。設定好格式和寬高後，就可以看到圖片的真實面目了。

![](https://static001.geekbang.org/infoq/32/327dece8e1c11f3bcfe1c39aa064f6b6.jpeg)

# 二、圖片記憶體佔用計算公式

在上一章節我們知道一個透過網路下載的36KB圖片，在被載入到記憶體中時，需要2.4MB的空間。接下來解釋這其中的換算關係，讓我們記住一個公式：

> 圖片佔用記憶體 = 圖片質量 \* 寬 \* 高

這裡面有“圖片質量”、“寬”、“高”三個因素，它涉及到圖片載入框架的實現，不同的框架，對於這三者的預設取值是不一樣的，我們以當前最流行的Picasso和Glide為例。

**Picasso**

在Picasso中，圖片預設顯示的寬高與原始圖片寬高一致。仍然以這張鋼鐵俠為例，圖片本身是350px * 350px，當我們把它載入到200px * 200px的ImageView當中時，佔用空間是**0.49MB**。

![](https://static001.geekbang.org/infoq/0d/0daf64a596ad8272c220fafbc615cd9a.png)

因此，在目標ImageView小於圖片尺寸的情況下，好的做法是使用不超過ImageView尺寸的圖片源，一方面可以縮短圖片下載時間，另一方面有助於最佳化記憶體佔用。

**Glide**

Glide則採用截然不同的處理方式，它最終使用的寬高是目標ImageView的寬高。如果我們把同樣一張圖片載入到200px * 200px的ImageView中，佔用空間只有0.16MB。

![](https://static001.geekbang.org/infoq/ce/ce2ec93e22d583df696cb848a936f6e0.png)

**使Picasso達到與Glide同樣的效果**

Picasso的設計者也發現了這一缺點，提供一系列方法用來調整最終載入出來的圖片尺寸，其一就是fit()，透過這個方法可以達到與Glide同樣的效果。

```java
Picasso().get().load(IMAGE_URL).fit().into(imageVIEW)

```

**相反場景：小圖載入到大ImageView中**

通常為了提供更清晰的介面，防止圖片拉伸後失真模糊，設計師提供的圖片都是高解析度的，我們所面臨的場景是將大圖載入到小ImageView中。但也不排除相反的可能：將小圖載入到大ImageView裡面。這時Glide預設採用的記憶體策略是存在不足的：它採用目標ImageView的尺寸作為最終的寬和高。

舉例說明，當把350 * 350的鋼鐵俠圖片載入到600 * 600的ImageView中時，佔用的記憶體高達1.41MB。

> 600 * 600 * 4bytes = 1.41MB

有沒有一種方法，可以兼顧原圖片與目標ImageView不同的大小關係呢？——有的，這就是centerInside()。

```java
Glide.with(this).load(IMAGE_URL).centerInside().into(imageView)

```

藉助centerInside()方法，可以達到“在原圖片和目標ImageView中取最小寬高作為最終載入圖片的尺寸”這樣的效果。

# 三、圖片質量

什麼是“圖片質量”？簡單說就是用多少位元組來表示一個畫素點的顏色，它的學名叫做“**位深度**”，在圖片屬性當中可以看到。

圖片位深度通常有1位、8位、16位、24位、32位。

![](https://static001.geekbang.org/infoq/fa/faed08045fe303bde4deb0ce4a639f73.jpeg)

PNG格式有8位、24位、32位三種形式，其中8位PNG支援兩種不同 的透明形式（索引透明和alpha透明），24位PNG不支援透明，32位 PNG 在24位基礎上增加了8位透明通道，因此可展現256級透明程度。

![](https://static001.geekbang.org/infoq/af/af4b3784b242d039d9b7389348e695f6.png)

Glide和Picasso預設採用的圖片質量都是ARGB_8888、也就是帶透明度的32位深度，一個畫素點需要佔用4bytes的記憶體，這也解釋了為什麼上文中的計算都是採用寬_高_4bytes的公式。

> 注：v4開始，Glide將ARGB\_8888作為預設配置。在那之前它一直預設使用RGB\_565。

對客戶端使用的大部分圖片來說，32位深度、16位深度的顯示質量是肉眼較難分辨的，但它們在佔用記憶體上相差了整整一倍。因此，筆者建議在大部分場景下，使用**RGB_565**作為載入圖片的模式。以下兩種場景除外：

![](https://static001.geekbang.org/infoq/08/0843f986c744659cf15e25380fa14eda.png)

1）含透明部分的圖片：如果採用RGB_565圖片格式來顯示圖片，是無法正常展現透明區域的。比如上方這個鋼鐵俠圖片，原本透明的部分會被顯示為黑色。

2）含漸變色並且對顯示質量要求高的圖片：32位比16位可以支援更多的顏色，在漸變的顯示上呈現更加自然的過渡（如下圖）。這時我們應當在顯示質量和應用效能之間作取捨。對於低端裝置，應用的穩定性比顯示質量更加重要，筆者強烈建議採用16位深度來顯示。

![](https://static001.geekbang.org/infoq/2e/2e87ae0efc888a84159d6ca327ec0187.png)

# 四、drawable目錄下圖片載入方式

專案的資源目錄下，一般都有drawable-mdpi、drawable-hdpi、drawable-xhdpi、drawable-xxhdpi、drawable-xxxhdpi目錄，它們是用來匹配不同顯示密度的裝置的，對應表格如下。

![](https://static001.geekbang.org/infoq/c6/c6406aea63a02fe96cb71cdc20bf9570.png)

透過adb shell wm density可以獲取當前裝置的dpi，對Nexus 6P模擬器執行後，可以讀取到它的dpi是560，屬於xxxhdpi。

```java
$ adb shell wm densityPhysical density: 560

```

那麼同一個圖片放在不同目錄下，對分配記憶體是否有影響呢？答案是有的，基於兩步簡單的推導：

-   圖片所在資源目錄、裝置密度兩者決定圖片最終顯示在螢幕上的畫素尺寸；
    
-   畫素尺寸、圖片質量共同決定分配記憶體。

其中第2點已經在上文講解過，這裡主要分析第1點。使用圖片編輯軟體，將原本是350 * 350的鋼鐵俠圖片放大至700 * 700，並分別放入xhdpi、xxxhdpi兩個目錄下。

為什麼使用這樣的組合呢？因為從上表得知，xhdpi與xxxhdpi的顯示密度是1:2，意味著一臺xxxhdpi的裝置在顯示drawable-xhdpi目錄下的圖片時，會將其放大為2倍進行展示。因此我們將350 * 350的骨片放入drawable-xhdpi，將700 * 700的圖片放入drawable-xxxhdpi，預期它們最終在螢幕上顯示的尺寸相同。

![](https://static001.geekbang.org/infoq/48/4881926a543949d5906f23683b81cbe9.png)

在佈局裡建立兩個ImageView，觀察這兩張圖片最終的顯示效果，以及分配記憶體情況。

```java
<framelayout xmlns:android="http://schemas.android.com/apk/res/android" android:layout_width="match_parent" android:layout_height="match_parent" android:background="#000000">

<imageview android:id="@+id/iv_image_1" android:layout_width="wrap_content" android:layout_height="wrap_content" android:padding="40dp" android:src="@drawable/iron_man_350_square_xhdpi"></imageview>

<imageview android:id="@+id/iv_image_2" android:layout_width="wrap_content" android:layout_height="wrap_content" android:padding="40dp" android:layout_gravity="bottom" android:src="@drawable/iron_man_700_square_xxxhdpi"></imageview>

</framelayout>

```

顯示效果以及記憶體分配如下：

![](https://static001.geekbang.org/infoq/e3/e3b699cb2b2ddb12dc0c7b08dcfbd2a2.jpeg)

可以分析得出以下結論：

> 對於顯示尺寸613 * 613的圖片，其佔據記憶體為613 * 613 * 4 = 1,503,076B ≈ 1.5MB，符合上文中我們對圖片記憶體的分析；
> 
> 決定圖片佔用記憶體的是其最終顯示在螢幕上的尺寸，與圖片本身解析度、在哪個drawable目錄下沒有直接關係；
> 
> 由於xxxhdpi密度是xhdpi密度的兩倍，故在螢幕密度屬於xxxhdpi的Nexus 6P裝置上，drawable-xxxhdpi目錄下的圖片被以近似於原畫素尺寸（700px）進行顯示（顯示為613px），而位於drawable-xhdpi目錄下的圖片被放大至2倍顯示，最終顯示尺寸同樣是613px。

# 五、最佳化策略

在實際的開發中，我們希望中高階機型載入更清晰的圖片（ARGB\_8888），以提升使用者體驗，對於低端機型則希望載入佔用記憶體更小的圖片（RGB\_565），以降低OOM發生的機率。可以在初始化Glide時進行這樣的配置。需要留意的是不要對含透明區域的圖片採用這種最佳化方案。

```java
@GlideModule
class MyGlideModule : AppGlideModule() {

override fun applyOptions(context: Context, builder: GlideBuilder) {
        builder.setDefaultRequestOptions(RequestOptions().format(getBitmapQuality()))
    }

private fun getBitmapQuality(): DecodeFormat {
        return if (Build.VERSION.SDK_INT < Build.VERSION_CODES.N || hasLowRam()) {
            // 低端機型採用RGB_565以節約記憶體
            DecodeFormat.PREFER_RGB_565
        } else {
            DecodeFormat.PREFER_ARGB_8888
        }
    }
}

```

# 六、小結

藉助一些開源工具，我們可以便捷地定位大圖，如滴滴開源的[DoKit](https://github.com/didi/DoraemonKit)，篇幅原因不進行詳細介紹。最後，對於我們日常開發總結幾點建議，希望大家的應用穩定性節節攀升。

-   在多圖的場景（比如RecyclerView）注意及時釋放圖片資源；
    
-   使用佔據記憶體更小的圖片格式；
    
-   圖片原始檔尺寸應當與目標ImageView相近；
    
-   優先滿足xxhdpi、xxxhdpi的圖片資源需求；
    
-   根據裝置效能，採用不同的圖片載入策略。

> 作者：vivo網際網路客戶端團隊-Li Lei</out-file></in-file>

Android系統Bitmap記憶體分配原理與最佳化

相關文章