每個人都要學的圖片壓縮終極奧義,有效解決 Android 程式 OOM
- 2019 年 10 月 3 日
- 筆記
# 由來
在我們編寫
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~ 謝謝!