# 由來

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

• 來自網路下載
• 本地相簿中載入

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

Exception java.lang.OutOfMemoryError: Failed to allocate a 916 byte allocation with 8388608 free bytes and 369MB until OOM; failed due to fragmentation (required continguous free 65536 bytes for a new buffer where largest contiguous free 32768 bytes)
java.nio.CharBuffer.allocate (CharBuffer.java:54)
java.nio.charset.CharsetDecoder.allocateMore (CharsetDecoder.java:226)
java.nio.charset.CharsetDecoder.decode (CharsetDecoder.java:188)
org.java_websocket.util.Charsetfunctions.stringUtf8 (Charsetfunctions.java:77)
org.java_websocket.WebSocketImpl.decodeFrames (WebSocketImpl.java:375)
org.java_websocket.WebSocketImpl.decode (WebSocketImpl.java:158)
org.java_websocket.client.WebSocketClient.run (WebSocketClient.java:185)
java.lang.Thread.run (Thread.java:818)
 

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

# 解決方案

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

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

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

那麼就讓我們開始吧：

# 獲取原圖大小

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

public static Bitmap decodeResource(Resources res, int id)

public static Bitmap decodeFile(String pathName)

public static Bitmap decodeStream(InputStream is)

其中：

• 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 。這種做法有兩個好處：

1. 既能獲得圖片大小，由於後續操作
2. 又成功避免了去解析圖片，導致程式 OOM 而崩潰。

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

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

    public static void calculateOptionsById(@NonNull Resources res,@NonNull BitmapFactory.Options options, int imgId) {
        BitmapFactory.decodeResource(res, imgId, options);
    }

大家可能發現，這裡只將 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 都不到的小圖啊！

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

    public static int calculateInSamplesizeByOptions(@NonNull BitmapFactory.Options options, int reqWidth, int reqHeight) {
        int inSamplesize   = 1;
        int originalWidth  = options.outWidth;
        int originalHeight = options.outHeight;
        if (originalHeight > reqHeight || originalWidth > reqWidth) {
            int heightRatio = originalHeight / reqHeight;
            int widthRatio  = originalWidth  / reqWidth;
            inSamplesize = heightRatio > widthRatio ? heightRatio : widthRatio;
        }
        return inSamplesize;
    }

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

# 生成目標圖片

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

1. 先生成一個 Options物件
2. 將 Options 的 inJustDecodeBounds設定為true
3. 接著呼叫方法一calculateOptionsById獲得原圖尺寸到Options中
4. 呼叫方法三calculateInSamplesizeByOptions 獲得相應的inSampleSize 物件
5. 將 Options的inJustDecodeBounds改回 false
6. 再次呼叫 decode...()方法（這裡是 decodeResource ）獲得壓縮後的 Bitmap物件

具體實現如下

    public static Bitmap decodeBitmapById (@NonNull Resources res, int resId, int reqWidth, int reqHeight) {
        BitmapFactory.Options options = new BitmapFactory.Options();
        options.inJustDecodeBounds = true;
        calculateOptionsById(res, options, resId);
        options.inSampleSize = calculateInSamplesizeByOptions(options, reqWidth, reqHeight);
        options.inJustDecodeBounds = false;
        Bitmap bitmap = BitmapFactory.decodeResource(res, resId, options);
        return bitmap;
    }

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

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

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

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

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

首先，在calculateOptionsById中，預設將 options.inJustDecodeBounds 設定為true：

    public static void calculateOptionsById(@NonNull Resources res,@NonNull BitmapFactory.Options options, int imgId) {
        options.inJustDecodeBounds = true;
        BitmapFactory.decodeResource(res, imgId, options);
    }

其次，在 calculateInSamplesizeByOptions最後，預設將 options.inJustDecodeBounds設定為false：

    public static int calculateInSamplesizeByOptions(@NonNull BitmapFactory.Options options, int reqWidth, int reqHeight) {
        int inSamplesize   = 1;
        int originalWidth  = options.outWidth;
        int originalHeight = options.outHeight;
        if (originalHeight > reqHeight || originalWidth > reqWidth) {
            int heightRatio = originalHeight / reqHeight;
            int widthRatio  = originalWidth  / reqWidth;
            inSamplesize = heightRatio > widthRatio ? heightRatio : widthRatio;
        }
        options.inJustDecodeBounds = false;
        return inSamplesize;
    }

為什麼不在該方法後面，對 options.inSampleSize進行賦值呢？這主要是防止，有時我們可能只想得到計算相應比例來做其他操作，而不想改變原有屬性，所以是否賦值，就交給使用者去選擇吧

# 總結

好了，到這裡為止，歷時有關圖片壓縮的所有坑坑窪窪都已經總結好了，我們從頭理以邊思路：

1. 藉助options.inJustDecodeBounds 引數賦值true時，不生成圖片的特性，將原圖尺寸儲存在 Options 中
2. 通過 options 中原圖尺寸與目標（控制元件）尺寸的比例，對 options.inSampleSize 進行設定
3. 生成目標圖片
4. 壓縮的問題解決了，但是每次開啟圖片都壓縮也太麻煩了！下面我將針對這個問題進行更有效地解決 ，有興趣可以繼續關注 _yuanhao 的程式設計世界

相關文章

---

Android 讓你的 Room 搭上 RxJava 的順風車 從重複的程式碼中解脫出來
ViewModel 和 ViewModelProvider.Factory：ViewModel 的建立者
單例模式-全域性可用的 context 物件，這一篇就夠了
縮放手勢 ScaleGestureDetector 原始碼解析，這一篇就夠了
Android 屬性動畫框架 ObjectAnimator、ValueAnimator ，這一篇就夠了
看完這篇再不會 View 的動畫框架，我跪搓衣板
看完這篇還不會 GestureDetector 手勢檢測，我跪搓衣板！
android 自定義控制元件之-繪製鐘表盤
Android 進階自定義 ViewGroup 自定義佈局
看完這篇還不會自定義 View ，我跪搓衣板

歡迎關注_yuanhao的部落格園！

---

定期分享Android開發溼貨，追求文章幽默與深度的完美統一。

原始碼 Demo 連結：Drop 我第一次寫的 Android 專案，希望大家點歌 star~ 謝謝！

請點贊！因為你的鼓勵是我寫作的最大動力！

相關推薦