一、前言

Glide 是 Google 官方推薦的一款圖片加載庫(kù)，使用起來(lái)也非常的簡(jiǎn)單便利，Glide 它幫我們完成了很多很重要，但是卻通用的功能，例如：圖片的加載壓縮、展示、加載圖片的內(nèi)存管理等等。

對(duì) Glide 還不熟悉的朋友，可以參考 《 一篇好文，助你上手 Glide 》

但是，在使用 Glide 的時(shí)候，有一些小技巧，可以讓你的內(nèi)存更優(yōu)化，避免可能出現(xiàn)的 OOM。例如：雖然 Glide 會(huì)根據(jù)加載的控件大小，優(yōu)化加載后的圖片尺寸，可如果加載的是一張全屏的大圖，依然會(huì)是一個(gè)占用內(nèi)存空間非常大的操作。

具體一張 Bitmap 到底占用了多少內(nèi)存空間，可以參考《 Bitmap 比你想的更費(fèi)內(nèi)存 | 吊打 OOM 》

本文有些建議來(lái)自 Android TV App，而 Android TV 眾多的智能電視和智能盒子，實(shí)際上硬件條件非常的惡劣，而 Android TV 的 App ，為了美化，會(huì)用到大部分的圖片，所以在圖片使用方面，OOM 的問題就會(huì)被放大，而下面介紹的一些優(yōu)化方案，在 Android 手機(jī)硬件條件非常好的環(huán)境下，不使用影響也不大。

二、開始優(yōu)化

2.1 配置好 TrimMemory 和 LowMemory

Glide 幫我們做了大部分內(nèi)存管理方面的事情，實(shí)際上它還支持做的更好。

對(duì)于一個(gè) App 而言，在系統(tǒng)內(nèi)存環(huán)境不足的情況下，會(huì)回調(diào)一些 onTrimMemory() 或者 onLowMemory() 等方法，這些都是在提醒開發(fā)者，當(dāng)前設(shè)備的內(nèi)存環(huán)境已經(jīng)發(fā)生了變化，你***調(diào)整你的內(nèi)存使用策略，避免被系統(tǒng)清理掉或者出現(xiàn) OOM 。

關(guān)于 onTrimMemroy() 相關(guān)內(nèi)容，不了解的可以先參考《 Android 開發(fā)，跳不過(guò)的內(nèi)存管理 》

而 Glide 也為我們提供了類似方法的接口，開發(fā)者只需要調(diào)用即可，它在內(nèi)部會(huì)隨著不同的內(nèi)存情況，幫我們對(duì)緩存的圖片進(jìn)行優(yōu)化。

在這里，你主要用到 Glide 的 trimMemory() 和 cleanMemroy() 方法，它們一個(gè)用來(lái)裁剪 Glide 緩存的圖片內(nèi)存空間，一個(gè)用來(lái)清理 Glide 緩存的內(nèi)存空間。

在使用 onTrimMemory() 之前，一般是實(shí)現(xiàn) ComponentCallbacks2 接口，然后在 Application 中，通過(guò) registerComponentCallbacks() 方法進(jìn)行注冊(cè)。當(dāng)然，如果你嫌麻煩，還可以直接在 Application 中，重寫對(duì)應(yīng)的方法。

了解了這些，就可以根據(jù)我們的需要來(lái)配置在何時(shí)調(diào)用 Glide 的對(duì)應(yīng)方法，我推薦的配置：

1. 在 lowMemory 的時(shí)候，調(diào)用 Glide.cleanMemroy() 清理掉所有的內(nèi)存緩存。

2. 在 App 被置換到后臺(tái)的時(shí)候，調(diào)用 Glide.cleanMemroy() 清理掉所有的內(nèi)存緩存。

3. 在其它情況的 onTrimMemroy() 回調(diào)中，直接調(diào)用 Glide.trimMemory() 方法來(lái)交給 Glide 處理內(nèi)存情況。

那么對(duì)應(yīng)的代碼，如下：

既然知道需要調(diào)用 Glide 的這兩個(gè)方法，我們還是需要了解到它內(nèi)部到底幫我們做了什么。先來(lái)看看 Glide 對(duì)應(yīng)的源碼。

在 Glide 的這些方法內(nèi)，可以看到，它們都會(huì)去操作 memoryCache 和 bitmapPool 這兩個(gè)對(duì)象，實(shí)際上它們是兩個(gè)接口，這里如果做特殊處理，操作的都是 Glide 對(duì)它們的默認(rèn)實(shí)現(xiàn)， LruResourceCache 和 LruBitmapPool 。從名稱上可以看出來(lái)，它們都是遵循 Lru 算法的。

就 Glide 而言，Memory Cache 是 Glide 用來(lái)在內(nèi)存中緩存圖片資源，使其在需要使用的時(shí)候立刻就可以使用，而不必執(zhí)行磁盤的 I/O 操作，而 BitmatPool 則是 Glide 維護(hù)了一個(gè)圖片復(fù)用池，LruBitmapPool 使用 Lru 算法保留最近使用的尺寸的 Bitmap，這不是本文的重點(diǎn)，大家了解一下即可。

其實(shí) LruResourceCache 和 LruBitmapPool 中，對(duì) clearMemory() 和 trimMemory() 的操作是類似的，這里就以 LruBitmapPool 舉例。

在 LruBitmapPool 中，會(huì)根據(jù)回調(diào)的方法以及參數(shù)，調(diào)用 clearMemory() 或者 trimToSize()，其實(shí)最終都是調(diào)用的 trimToSize() 方法。它用于裁剪當(dāng)前緩存資源的個(gè)數(shù)。

可以看到，根據(jù)裁剪的目標(biāo)尺寸，會(huì)去回收多余的 Bitmap 到合適的目標(biāo)大小，以達(dá)到清理內(nèi)存的目的。

2.2 配置 GlideModule

GlideModule是 Glide 提供的一個(gè)配置接口，它會(huì)在***次使用 Glide 的時(shí)候被調(diào)用，用于進(jìn)行 Glide 的一些初始的配置。

具體 GlideModule 的使用，可以參見官方文檔：

https://github.com/bumptech/glide/wiki/Configuration

GlideModule是一個(gè)接口，需要實(shí)現(xiàn)其對(duì)應(yīng)的方法。

這里我們只需要使用 applyOptions() 這個(gè)方法，它用于在 Glide 的默認(rèn)配置的基礎(chǔ)上，追加一些我們需要的配置。

而在這里，我們可以根據(jù)當(dāng)前設(shè)備的內(nèi)存情況，對(duì)其進(jìn)行一個(gè)設(shè)定，使用 ActivityManager 獲取當(dāng)前設(shè)備的內(nèi)存情況，如果是處于 lowMemory 的時(shí)候，將圖片的 DecodeFormat 設(shè)置為 RGB_565 ， RGB_565 和默認(rèn)的 ARGB_8888 比，每個(gè)像素會(huì)少 2 個(gè)byte，這樣，等于一張同樣的圖片，加載到內(nèi)存中會(huì)少一半內(nèi)存的占用（ ARGB_8888 每個(gè)像素占 4 byte）。

2.3 避免使用圓角的ImageView

在實(shí)際項(xiàng)目?jī)?nèi)，經(jīng)常會(huì)用到一些帶圓角的圖片，或者直接就是圓形的圖片。圓形的圖片，多數(shù)用于一些用戶的頭像之類的顯示效果。

而在 Android 下，也有大量的類似 XxxImageView 的開源控件，用于操作 Bitmap 以達(dá)到一個(gè)圓角圖片的效果，例如 Github 上比較火的 RoundedImageView 。

它們大部分的原理，是接收到你傳遞的 Bitmap ，然后再輸出一個(gè)與原來(lái) Bitmap 等大的新 Bitmap ，在此基礎(chǔ)之上，進(jìn)行圓角的一些處理，這就導(dǎo)致了，實(shí)際上會(huì)在內(nèi)存中，多持有一個(gè) Bitmap ，一下一張圖片占用的內(nèi)存就被加倍了。

所以既然已經(jīng)選擇使用 Glide ，推薦使用 glide-transformations 這個(gè)開源庫(kù)配合使用，glide-transformations 利用 Glide 的 bitmapTransfrom() 接口，實(shí)現(xiàn)對(duì)加載的 Bitmap 的進(jìn)行一些變換操作。

glide-transformations 的 Github 地址如下：

https://github.com/wasabeef/glide-transformations

glide-transformations 提供一系類對(duì)加載的圖片的變換操作，從形狀變換到色彩變換，全部支持，基本上滿足大部分開發(fā)需要，并且它會(huì)復(fù)用 Glide 的 BitmapPool ，來(lái)達(dá)到節(jié)約內(nèi)存的目的。

具體 glide-transformations 的使用，可以查看 Github 上的文檔，下面是它的一個(gè)效果圖。

2.4 根據(jù)內(nèi)存情況，裁剪你的圖片

前面的介紹的一些優(yōu)化點(diǎn)，都是一些推薦的通用做法，基本上用了前面介紹的辦法，圖片導(dǎo)致的 OOM 應(yīng)該會(huì)大幅度減少。

接下來(lái)介紹一個(gè)在 Android TV 上，加載全屏大圖的時(shí)候，優(yōu)化內(nèi)存問題的一個(gè)解決辦法。

首先要明確一點(diǎn)，國(guó)內(nèi) Android TV 的硬件環(huán)境非常的不好，二百三百的智能盒子到處都在賣，畢竟也是跑的 Android 系統(tǒng)，你想想你使用的是一款 299 的 Android 手機(jī)，你對(duì)它也不會(huì)有什么期待了。但是 Android TV 又是為了電視做的，所以大部分情況下，它都是需要支持 1920 * 1280 之類的屏幕尺寸，導(dǎo)致它如果加載一張全屏的大圖，消耗的內(nèi)存是不忍直視的，如果在內(nèi)存環(huán)境不好的情況下，可能就直接 OOM 崩潰了。

所以，對(duì)于這種極端的情況，我想到了一個(gè)辦法，根據(jù)當(dāng)前的內(nèi)存環(huán)境，按比例縮小需要顯示的全屏圖片，這樣加載到內(nèi)存中的圖片，就是按比例縮小的。

在這里就需要用到 DrawableRequestBuilder 的 override() 這個(gè) Api 了，它可以接受一個(gè) width 和 height ，來(lái)重新指定加載圖片的尺寸。

既然 Glide 已經(jīng)提供了標(biāo)準(zhǔn)的 Api ，那么我們還需要獲取到當(dāng)前運(yùn)行設(shè)備的寬高。

這里推薦使用 getRealSize() 的方式獲取屏幕的寬高，它可以真實(shí)的拿到當(dāng)前屏幕的尺寸。其它 Api 在部分智能電視和盒子上，拿到的尺寸會(huì)小，因?yàn)闆]有計(jì)算 StatusBar 或者 NavigationBar的高度，這些都是經(jīng)驗(yàn)之談。

同時(shí)，我們也需要用到 ComponentCallbacks2 這個(gè)接口，前面已經(jīng)介紹過(guò)了，就不再贅述了。

在其中，記錄 trim 的 level 這個(gè)值，反應(yīng)當(dāng)前的內(nèi)存級(jí)別，在使用的時(shí)候，通過(guò) getBitmapSize() 裁剪出一個(gè)符合當(dāng)前內(nèi)存環(huán)境的尺寸。

例子中只是對(duì) TRIM_MENORY_RUNNING_LOW 進(jìn)行了處理，會(huì)根據(jù)屏幕尺寸，縮放到 0.8f 倍的狀態(tài)。如果要做的更多，可以將其它幾個(gè) level 也加上，調(diào)整不同的縮放倍數(shù)。

兩個(gè)都輸出一下，看看差別，同一張全屏的圖片，不縮放和縮放 0.8f 的差別。

I/cxmyDev: bgImage byteCount : 8294400
I/cxmyDev: bgImage byteCount : 5308416

可以看到，優(yōu)化的目的還是達(dá)到了?？梢怨?jié)約大概 3MB 左右的內(nèi)存空間，而圖片又不至于模糊到無(wú)法看的地步。

三、小結(jié)

優(yōu)化是沒有終點(diǎn)的，今天先聊到這里，之后有想到的再補(bǔ)充。如果你有什么更好的建議，可以在文末留言一起討論一下。

iOS 長(zhǎng)按打賞