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

一、由來(lái)

在我們編寫(xiě) Android 程序的時(shí)候，幾乎永遠(yuǎn)逃避不了圖片壓縮的難題。除了應(yīng)用圖標(biāo)之外，我們所要顯示的圖片基本上只有兩個(gè)來(lái)源：

來(lái)自網(wǎng)絡(luò)下載
本地相冊(cè)中加載

不管是網(wǎng)上下載下來(lái)的也好，還是從系統(tǒng)圖片庫(kù)中讀取的圖片，都有一個(gè)相同的特點(diǎn)：像素一幫較高。同時(shí)我們都知道，Android 系統(tǒng)分配給我們每個(gè)應(yīng)用的內(nèi)存是有限的，由于解析、加載一張圖片，需要占用的內(nèi)存大小，是遠(yuǎn)大于圖片自身大小的。所以，這時(shí)程序就可能因?yàn)檎加昧诉^(guò)多的內(nèi)存，從而出現(xiàn)OOM 現(xiàn)象。那么什么是 OOM 呢？

OOM 即 OutOfMemory 異常，也就是我們所說(shuō)的內(nèi)存溢出，其一般表現(xiàn)為應(yīng)用閃退等現(xiàn)象。那么我們?cè)撊绾蜗率秩ソ鉀Q呢？

二、解決方案

首先我們發(fā)現(xiàn)，我們所加載的這些圖片的分辨率，要比我們手機(jī)屏幕高得多，更有甚者，我們?cè)谝粋€(gè)拇指大的控件上，去加載一個(gè) 4k 大圖是完全沒(méi)有必要的，也就是說(shuō)，如果我們能讓每個(gè)控件上都去顯示相應(yīng)大小的圖片，那么這個(gè)問(wèn)題也就迎刃而解了

那么，要怎樣才能達(dá)到圖片與控件的對(duì)號(hào)入座？這時(shí)我們就引進(jìn)了圖片壓縮的方案：

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

那么就讓我們開(kāi)始吧：

三、獲取原圖大小

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

其中：

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

其他的方法這里就不多說(shuō)了，因?yàn)樵谠创a中我們可有i看到，幾乎所有的方法，最后都會(huì)將圖片解析為流的形式，最后調(diào)用 decodeStream() 方法，實(shí)例化出我們的 Bitmap 對(duì)象。

雖然這些方法對(duì)我們是再熟悉不過(guò)的了，但對(duì)于某些初學(xué)者而言，卻經(jīng)常忽略了一個(gè)重要的內(nèi)部類(lèi) ：BitmapFactory.Options ，然而他確實(shí)我們圖片壓縮必不可少的，為什么需要這個(gè)參數(shù)呢？Options 的對(duì)象用于確定需要生成的 Bitmap 即目標(biāo)圖片的參數(shù)。

他的用法很簡(jiǎn)單，我們先 new 一個(gè) BitmapFactory.Options 對(duì)象。再去調(diào)用含有 Options參數(shù)的方法，如

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)

調(diào)用完之后我們發(fā)現(xiàn)，除了方法放回給我們一個(gè)實(shí)例化出來(lái)的 Bitmap 圖片之外，這個(gè) Options 對(duì)象中長(zhǎng)度、寬度、類(lèi)型等等屬性，也都被設(shè)置成了了我們圖片的相應(yīng)屬性。所以，我們很容易想到：通過(guò)將 Options 對(duì)象傳入，來(lái)獲得圖片的原始尺寸，為后期的壓縮做準(zhǔn)備，說(shuō)干就干，我們將 Options 對(duì)象，和 Resources中一張 4k 圖片的id 一塊傳入上訴方法中，來(lái)嘗試獲得它的尺寸，結(jié)果我們發(fā)現(xiàn)：程序 OOM 崩潰了！

為什么會(huì)發(fā)生這種情況？首先我們想想我們?yōu)槭裁匆@得這個(gè)Options 對(duì)象？時(shí)為了獲得圖片的尺寸大小；那我們?yōu)槭裁匆@得原圖尺寸大小？是為了按照原圖尺寸和控件尺寸的比例，將其壓縮為適合顯示的大小？那我們又為什么要去壓縮它為合適的大小呢？是因?yàn)槿绻凑赵笮∪フ{(diào)用相應(yīng)的 decode...()方法解析圖片，會(huì)導(dǎo)致內(nèi)存占有率過(guò)高觸發(fā)OOM 異常，進(jìn)而導(dǎo)致程序崩潰啊！沒(méi)想到的是：結(jié)果我們?yōu)榱双@得 Options 而調(diào)用了相應(yīng)的 decode...() 方法，的確 Options 是復(fù)制了，但由于該方法適用于生成圖片，也就是 Bitmap 對(duì)象的。所以程序也在解析這張超大圖的過(guò)程中OOM 崩潰了

那么難道就沒(méi)方法了嗎？

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

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

但這恰恰是被很多人所忽略的一點(diǎn)。

好了，現(xiàn)在給出具體的實(shí)現(xiàn)：

大家可能發(fā)現(xiàn)，這里只將 inJustDecodeBounds 設(shè)為true卻沒(méi)有改回false ，這是因?yàn)楂@得 Options 只是圖片壓縮的第一步，我們?cè)诤罄m(xù)方法中將會(huì)進(jìn)行修改

四、如何進(jìn)行壓縮

我們繼續(xù)看 Options 的構(gòu)成。我們發(fā)現(xiàn)，其中有個(gè)名為 inSampleSize 的數(shù)據(jù)成員，他就是關(guān)鍵所在，那么他有著什么意義呢？

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

當(dāng)我們把 inSampleSize 的值設(shè)為 4時(shí)，最后生成出來(lái)的圖片大小將會(huì)是：1000 x 250 像素
當(dāng)我們把inSampleSize 的值設(shè)為5時(shí)，最后生成出來(lái)的圖片大小將會(huì)是：800 x 200 像素。這是個(gè)什么概念？

這不僅僅是長(zhǎng)寬都變?yōu)樵瓉?lái)四分之一或者五分之一這么簡(jiǎn)單，而是其圖片大小，直接變?yōu)樵瓐D的 1/(n^2)！也就是說(shuō)：

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

那么下面我就給出這個(gè)方法的具體實(shí)現(xiàn)：

我們發(fā)現(xiàn)，這里我先計(jì)算出了，原圖尺寸與目標(biāo)大小大比例，在三目運(yùn)算符中，將inSamplesize 賦值為較大的一個(gè)。為什么不用小的那一個(gè)呢？這里我就賣(mài)個(gè)關(guān)子，大家可以在評(píng)論區(qū)中發(fā)表自己的想法

五、生成目標(biāo)圖片

經(jīng)過(guò)前面的兩個(gè)步驟，想必大家已經(jīng)能勾勒處這最后一步的做法了，思路非常簡(jiǎn)單：

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

具體實(shí)現(xiàn)如下

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

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

最求完美的我們可能會(huì)有個(gè)想法：如果調(diào)用我們方法的人，或者說(shuō)特殊時(shí)候的我們。不想用這個(gè)已經(jīng)寫(xiě)好的 decodeBitmapById方法，而是像自己通過(guò)前兩個(gè)方法：calculateOptionsById calculateInSamplesizeByOptions 來(lái)實(shí)現(xiàn)圖片壓縮功能，這是問(wèn)題就出現(xiàn)了：

調(diào)用 calculateOptionsById 前可能忘記，設(shè)置 inJustDecodeBound 為 true ，進(jìn)而導(dǎo)致計(jì)算超大圖時(shí)，直接發(fā)生 OOM
調(diào)用完 calculateInSamplesizeByOptions 后可能忘記，設(shè)置inJustDecodeBounds 為 false，進(jìn)而導(dǎo)致無(wú)法獲得Bitmap 對(duì)象，一臉懵逼
啥都做了結(jié)果調(diào)用完 calculateInSamplesizeByOptions 沒(méi)把沒(méi)回的值賦給 options.inSampleSize ，白忙活一場(chǎng)

所以，我們需要在優(yōu)化一下：

首先，在calculateOptionsById中，默認(rèn)將 options.inJustDecodeBounds 設(shè)置為true：

其次，在 calculateInSamplesizeByOptions最后，默認(rèn)將 options.inJustDecodeBounds設(shè)置為false：

為什么不在該方法后面，對(duì) options.inSampleSize進(jìn)行賦值呢？這主要是防止，有時(shí)我們可能只想得到計(jì)算相應(yīng)比例來(lái)做其他操作，而不想改變?cè)袑傩裕允欠褓x值，就交給用戶去選擇吧

總結(jié)

好了，到這里為止，歷時(shí)有關(guān)圖片壓縮的所有坑坑洼洼都已經(jīng)總結(jié)好了，我們從頭理以邊思路：

借助options.inJustDecodeBounds 參數(shù)賦值true時(shí)，不生成圖片的特性，將原圖尺寸保存在 Options 中
通過(guò) options 中原圖尺寸與目標(biāo)（控件）尺寸的比例，對(duì) options.inSampleSize 進(jìn)行設(shè)置
生成目標(biāo)圖片
壓縮的問(wèn)題解決了，但是每次打開(kāi)圖片都?jí)嚎s也太麻煩了！下面我將針對(duì)這個(gè)問(wèn)題進(jìn)行更有效地解決，有興趣可以繼續(xù)關(guān)注 _yuanhao 的編程世界