每個人都要學的圖片壓縮終極奧義，有效解決 Android 程序 OOM

本文轉載自查看原文 2019-10-01 19:39 331 OutOfMemory/ Options/ Bitmap/ 圖片壓縮/ android/ OOM

學Android

由來

在我們編寫 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 。這種做法有兩個好處：

既能獲得圖片大小，由於后續操作
又成功避免了去解析圖片，導致程序 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 賦值為較大的一個。為什么不用小的那一個呢？這里我就賣個關子，大家可以在評論區中發表自己的想法

生成目標圖片

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

先生成一個 Options 對象
將 Options 的 inJustDecodeBounds 設置為 true
接着調用方法一calculateOptionsById獲得原圖尺寸到Options中
調用方法三 calculateInSamplesizeByOptions 獲得相應的 inSampleSize 對象
將 Options 的inJustDecodeBounds改回 false
再次調用 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 進行賦值呢？這主要是防止，有時我們可能只想得到計算相應比例來做其他操作，而不想改變原有屬性，所以是否賦值，就交給用戶去選擇吧

總結

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

借助 options.inJustDecodeBounds 參數賦值true時，不生成圖片的特性，將原圖尺寸保存在 Options 中
通過 options 中原圖尺寸與目標（控件）尺寸的比例，對 options.inSampleSize 進行設置
生成目標圖片
壓縮的問題解決了，但是每次打開圖片都壓縮也太麻煩了！下面我將針對這個問題進行更有效地解決，有興趣可以繼續關注 _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~ 謝謝！

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