Android 圖片壓縮策略詳解，有效解決 Android 程序 OOM

一、由來

在我們編寫 Android 程序的時候，幾乎永遠逃避不了圖片壓縮的難題。除了應用圖標之外，我們所要顯示的圖片基本上只有兩個來源：

來自網絡下載
本地相冊中加載

不管是網上下載下來的也好，還是從系統圖片庫中讀取的圖片，都有一個相同的特點：像素一幫較高。同時我們都知道，Android 系統分配給我們每個應用的內存是有限的，由于解析、加載一張圖片，需要占用的內存大小，是遠大于圖片自身大小的。所以，這時程序就可能因為占用了過多的內存，從而出現OOM 現象。那么什么是 OOM 呢？

OOM 即 OutOfMemory 異常，也就是我們所說的內存溢出，其一般表現為應用閃退等現象。那么我們該如何下手去解決呢？

二、解決方案

首先我們發現，我們所加載的這些圖片的分辨率，要比我們手機屏幕高得多，更有甚者，我們在一個拇指大的控件上，去加載一個 4k 大圖是完全沒有必要的，也就是說，如果我們能讓每個控件上都去顯示相應大小的圖片，那么這個問題也就迎刃而解了

那么，要怎樣才能達到圖片與控件的對號入座？這時我們就引進了圖片壓縮的方案：

首先，獲得原圖片大小
其次，獲取控件大小
接著，獲取我們圖片和控件的比例
最后，根據這一比例，將圖片壓縮為適合顯示的大小

那么就讓我們開始吧：

三、獲取原圖大小

我們都知道，Android 向我們提供了 BitmapFactory 這個類，在這個類中有著諸如：decodeResource() decodeFile() decodeStream() 等:

其中：

decodeResource() ：用于解析資源文件，即 res 文件夾下的圖片
decodeFile() ：用于解析系統相冊中的圖片
decodeStream() ：用于解析輸入輸出流中圖片通常，是采用 HttpClient 從下載的圖片

其他的方法這里就不多說了，因為在源碼中我們可有i看到，幾乎所有的方法，最后都會將圖片解析為流的形式，最后調用 decodeStream() 方法，實例化出我們的 Bitmap 對象。

雖然這些方法對我們是再熟悉不過的了，但對于某些初學者而言，卻經常忽略了一個重要的內部類：BitmapFactory.Options ，然而他確實我們圖片壓縮必不可少的，為什么需要這個參數呢？Options 的對象用于確定需要生成的 Bitmap 即目標圖片的參數。

他的用法很簡單，我們先 new 一個 BitmapFactory.Options 對象。再去調用含有 Options參數的方法，如

public static Bitmap decodeResource(Resources res, int id, Options opts)
public static Bitmap decodeResourceStream(@Nullable Resources res,@Nullable TypedValue value,@Nullable InputStream is, @Nullable Rect pad, @Nullable Options opts)

調用完之后我們發現，除了方法放回給我們一個實例化出來的 Bitmap 圖片之外，這個 Options 對象中長度、寬度、類型等等屬性，也都被設置成了了我們圖片的相應屬性。所以，我們很容易想到：通過將 Options 對象傳入，來獲得圖片的原始尺寸，為后期的壓縮做準備，說干就干，我們將 Options 對象，和 Resources中一張 4k 圖片的id 一塊傳入上訴方法中，來嘗試獲得它的尺寸，結果我們發現：程序 OOM 崩潰了！

為什么會發生這種情況？首先我們想想我們為什么要獲得這個Options 對象？時為了獲得圖片的尺寸大小；那我們為什么要獲得原圖尺寸大小？是為了按照原圖尺寸和控件尺寸的比例，將其壓縮為適合顯示的大小？那我們又為什么要去壓縮它為合適的大小呢？是因為如果按照原大小去調用相應的 decode...()方法解析圖片，會導致內存占有率過高觸發OOM 異常，進而導致程序崩潰啊！沒想到的是：結果我們為了獲得 Options 而調用了相應的 decode...() 方法，的確 Options 是復制了，但由于該方法適用于生成圖片，也就是 Bitmap 對象的。所以程序也在解析這張超大圖的過程中OOM 崩潰了

那么難道就沒方法了嗎？

有的，我之前說過：Option 內部有著眾多參數，其中有一個叫做： inJustDecodeBounds 。這個參數默認值為false 。但如果我們先把這個參數設置為 true 時，該方法便不在會去生成相應的 Bitmap ，而僅僅是去測量圖片的各種屬性，如長度、寬度、類型等等，然后放回一個 null 。所以，我們很容易想到：可以先通過將 inJustDecodeBounds 的值設為 true ，再去調用相應的相應的 decode...()方法，最后再將inJustDecodeBounds 的值改回 false。這種做法有兩個好處：

既能獲得圖片大小，由于后續操作
又成功避免了去解析圖片，導致程序 OOM 而崩潰。

但這恰恰是被很多人所忽略的一點。

好了，現在給出具體的實現：

大家可能發現，這里只將 inJustDecodeBounds 設為true卻沒有改回false ，這是因為獲得 Options 只是圖片壓縮的第一步，我們在后續方法中將會進行修改

四、如何進行壓縮

我們繼續看 Options 的構成。我們發現，其中有個名為 inSampleSize 的數據成員，他就是關鍵所在，那么他有著什么意義呢？

這里我給大家舉個例子，比如我這有張 4000*1000 像素的圖片：

當我們把 inSampleSize 的值設為 4時，最后生成出來的圖片大小將會是：1000 x 250 像素
當我們把inSampleSize 的值設為5時，最后生成出來的圖片大小將會是：800 x 200 像素。這是個什么概念？

這不僅僅是長寬都變為原來四分之一或者五分之一這么簡單，而是其圖片大小，直接變為原圖的 1/(n^2)！也就是說：

如果原圖 2MB，那么當 inSampleSize 賦值為4加載時就只需要 0.125MB
那如果 inSampleSize 賦值為 5 呢？只需要 0.08 MB！連100k 都不到的小圖啊！

那么下面我就給出這個方法的具體實現：

我們發現，這里我先計算出了，原圖尺寸與目標大小大比例，在三目運算符中，將inSamplesize 賦值為較大的一個。為什么不用小的那一個呢？這里我就賣個關子，大家可以在評論區中發表自己的想法

五、生成目標圖片

經過前面的兩個步驟，想必大家已經能勾勒處這最后一步的做法了，思路非常簡單：

先生成一個 Options對象
將 Options 的 inJustDecodeBounds設置為true
接著調用方法一calculateOptionsById獲得原圖尺寸到Options中
調用方法三calculateInSamplesizeByOptions 獲得相應的inSampleSize 對象
將 Options的inJustDecodeBounds改回 false
再次調用 decode...()方法（這里是 decodeResource ）獲得壓縮后的 Bitmap對象

具體實現如下

非常棒，我們趕緊看看效果：

太棒了，幾乎和原圖效果一摸一樣，但軟件運行的流暢性確大大提高了！但是，這真的就完美了嗎？

最求完美的我們可能會有個想法：如果調用我們方法的人，或者說特殊時候的我們。不想用這個已經寫好的 decodeBitmapById方法，而是像自己通過前兩個方法：calculateOptionsById calculateInSamplesizeByOptions 來實現圖片壓縮功能，這是問題就出現了：

調用 calculateOptionsById 前可能忘記，設置 inJustDecodeBound 為 true ，進而導致計算超大圖時，直接發生 OOM
調用完 calculateInSamplesizeByOptions 后可能忘記，設置inJustDecodeBounds 為 false，進而導致無法獲得Bitmap 對象，一臉懵逼
啥都做了結果調用完 calculateInSamplesizeByOptions 沒把沒回的值賦給 options.inSampleSize ，白忙活一場

所以，我們需要在優化一下：

首先，在calculateOptionsById中，默認將 options.inJustDecodeBounds 設置為true：