Android编译libjpeg-turbo so高效压缩图片
https://www.jianshu.com/p/8ebe0ddd21f7
https://www.jianshu.com/p/f305fb008ab6
一 . 圖片的基本知識(shí)
圖像是由像素組成的，而像素實(shí)際上是帶著坐標(biāo)的位置和顏色信息的。它是有若干行和若干列的點(diǎn)組成的，他們相交就會(huì)有無(wú)數(shù)個(gè)點(diǎn)。假如我們隨便取出一個(gè)點(diǎn)A 那個(gè)這個(gè)點(diǎn)可以表示為
A[m,n] = [blue,green,red]
m和n 就是圖像中的第m行和n列
blue 表示藍(lán)色，是三原色（RGB）的第一個(gè)值
green 表示綠色，是三原色（RGB）的第二個(gè)值
red 表示紅色，是三原色（RGB）的第三個(gè)值
我們通常說(shuō)圖片分辨率其實(shí)就是指像素?cái)?shù)，通俗的說(shuō)是橫向多少個(gè)像素 x 縱向多個(gè)像素 。那什么是像素： 每張圖片是有色點(diǎn)組成的，每個(gè)色點(diǎn)就稱之為像素。比如一張圖片有10萬(wàn)個(gè)色點(diǎn)構(gòu)成，那么這個(gè)圖片像素就是 10W。
我們舉個(gè)例子：一張圖片分辨率為 500x400 ，那么圖片是有橫向 500個(gè)像素、縱向 400個(gè)像素，（合計(jì)20000像素點(diǎn)）構(gòu)成。
我們?cè)趯?shí)際項(xiàng)目開(kāi)開(kāi)發(fā)中遇到比較多的圖片格式 一般有 .PNG、.JPG、.JPEG、 .WebP 、.GIF、.SVG 等等
PNG：它是一種無(wú)損數(shù)據(jù)壓縮位圖圖形文件格式。這也就是說(shuō)PNG 只支持無(wú)損壓縮。對(duì)于PNG 格式是有8 位、24位、32位的三種形式的。區(qū)別就是對(duì)透明度的支持。
JPG：其實(shí)就是 JPEG的另一種叫法
JPEG：它是一種有損壓縮的圖片格式
WebP：Google 開(kāi)發(fā)出的一種支持alpha 通道的有損壓縮。同等質(zhì)量情況下比 JPEG和PNG小 25%~45%.
GIF：它是動(dòng)態(tài)圖片的一種格式，和PNG 一樣是一種無(wú)損壓縮。
**SVG **: 是一種無(wú)損、矢量圖（放大不失真）
就目前來(lái)說(shuō)，Android 原生支持的格式只有 JPEG、PNG、GIF、WEBP（android 4.0 加入）、BMP。而在android層代碼中我們只能調(diào)用的編碼方式只有PNG、JPEG、和WEBP 三種。不過(guò)目前來(lái)說(shuō)android 還不支持對(duì)GIF 這種的動(dòng)態(tài)編碼。
注意 ：我們?nèi)粘Ｋ械?.png、.jpg、.jpeg 等等指的是圖像數(shù)據(jù)經(jīng)過(guò)壓縮編碼后在媒體上的封存形式，是不能和PNG 、JPG、JEPG 混為一談的。
我們不是說(shuō)圖片怎么壓縮的嗎？為什么要說(shuō)圖片格式。因?yàn)樗麄冎g是存在聯(lián)系的，比如其中 PNG是無(wú)損壓縮格式的圖片，JPEG是有損壓縮格式的圖片，所以對(duì)應(yīng)的也有各自的壓縮算法，比如在android中PNG壓縮使用的就是 libpng 進(jìn)行壓縮的，而JPEG的壓縮是用libjepg（7.0之前） 壓縮的，7.0 之后改為libjpeg-turbo是基于libjepg修改的，而比libjepg更快。最大的變化就是相同質(zhì)量的下7.0之后的機(jī)器比7.0之前的機(jī)器壓縮的圖片要小。
二 . Bitmap
對(duì)于開(kāi)發(fā)android的 小伙伴，對(duì)Bitmap肯定是不陌生的，甚至有的小伙伴被它虐的“體無(wú)完膚”。在Android中任何圖片資源的顯示對(duì)象都是通過(guò)bitmap 來(lái)顯示的（XML資源通Canvas繪制除外）。
Bitmap 它是圖像處理中的一個(gè)非常重要對(duì)象。
1.何為bitmap？
我們可以稱之為位圖，是一種存儲(chǔ)像素的數(shù)據(jù)結(jié)構(gòu)，通過(guò)這個(gè)對(duì)象我們可以獲取到一系列和圖片相關(guān)的屬性， 并且可以對(duì)圖像進(jìn)行處理，比如切割，放大等等，相關(guān)操作。
2.bitmap 存儲(chǔ)空間
隨著android系統(tǒng)的不斷升級(jí)，bitmap的存儲(chǔ)空間也在發(fā)生變成，而bitmap 的存儲(chǔ)空間主要有三個(gè)地方：
1）Native Memory
在android 2.3 以下的版本，bitmap像素?cái)?shù)據(jù)是存儲(chǔ)在 Native 空間中，如果需要釋放是要主動(dòng)調(diào)用 recycle()方法
2）Dalvik Heap
在Android 3.0 以上版本，bitmap的像素?cái)?shù)據(jù)存儲(chǔ)在虛擬機(jī)堆中，不需要我們?cè)偃ブ鲃?dòng)調(diào)用recycle()方法，gc會(huì)幫我們?nèi)セ厥铡?/p>
3）Ashmem
很多小伙伴可能不知道這個(gè)是什么，它是匿名共享存儲(chǔ)空間。我們?cè)趯?shí)際開(kāi)發(fā)中使用圖片加載庫(kù)中，有一個(gè)庫(kù)就是利用這個(gè)一個(gè)空間來(lái)進(jìn)行bitmap 對(duì)象的存儲(chǔ)的，他就是大名鼎鼎的Fresco 圖片加載庫(kù)。
不過(guò)這里需要注意一點(diǎn): 在Android 4.4 以前的版本中 Ashmem 是和App 進(jìn)程空間是隔離的互相不影響，而在Android 4.4以后的版本中，Ashmemk空間是包含在App所占用的內(nèi)存空間。
說(shuō)了這么多我們還是不知道bitmap 在內(nèi)存空間中到底是占用多大的，其實(shí)bitmap 在內(nèi)存空間中所占用的內(nèi)存計(jì)算是這樣的：
pixelWidth x pixelHeight x bytesPerPixel（bitmap 的寬 x 高 x 每個(gè)像素所占的字節(jié)），所有如果相同的Bitmap對(duì)象， 每個(gè)像素所占用的字節(jié)大小，決定了這個(gè)bitmap 在內(nèi)存中所占用的內(nèi)存大小。
上面既然說(shuō)了，所占用的字節(jié)大小決定bitmap內(nèi)存大小，那么怎么樣能讓每個(gè)像素所占的字節(jié)變小。在我們Bitmap對(duì)象中有一個(gè)比較重要的枚舉類 Config ，這個(gè)Config 是用來(lái)設(shè)置顏色配置信息的。對(duì)于Config配置有四個(gè)變量。
Config 配置：
alpha_8 ： 占用8位，1個(gè)字節(jié)，顏色信息只由透明組成。
argb_4444: 占用16位，2個(gè)字節(jié)，顏色有透明度和R (red)G(green)B(blue)組成。
3.argb_8888: 占用34位，4個(gè)字節(jié)，顏色有透明度和R (red)G(green)B(blue)組成。
這里可能有人會(huì)問(wèn)為什么 argb_4444和 argb_8888都是 有ARGB組成為什么所占的字節(jié)不同，因?yàn)槊總€(gè)部分所占用的字節(jié)是不同的，argb_4444每個(gè)部分占用4個(gè)字節(jié)，而argb_8888每個(gè)部分占用8位。
4.rgb_565: 占用16位，2個(gè)字節(jié)，顏色有R (red)G(green)B(blue)組成。
提示：我們通常在操作bitmap 的時(shí)候，是必須要和這個(gè)配置打交道的，搞明白對(duì)使用bitmap的時(shí)候，提供幫助。特別是防止OOM，有很大作用。如果我們平時(shí)對(duì)圖片處理，如多對(duì)圖片的透明度沒(méi)特別要求，比較建議使用 rgb_565 這個(gè)配置，因?yàn)樗推渌鼛讉€(gè)比較，性價(jià)比最高的。比argb_4444 顯示圖片清晰，argb_8888占用內(nèi)存少一半，而alpha_8只有透明度，對(duì)圖片沒(méi)什么意思。既然我們知道這寫參數(shù)的意義了，我們就可以通過(guò)設(shè)置該配置，來(lái)讓我們bitmap 占用內(nèi)存空間變小。
說(shuō)了這么多，那么Bitmap在內(nèi)存究竟占用多少內(nèi)存？使用Android Api的 getByteCount 方法即可。
通過(guò)這個(gè)方法，我們就可以獲取當(dāng)前運(yùn)行的 bitmap 占用的內(nèi)存。
三. 壓縮
既然我們知道了，bitmap在內(nèi)存中占用空間 = bitmap 的寬 x 高 x 每個(gè)像素所占的字節(jié)數(shù)。那么Bitmap 壓縮都是圍繞這個(gè)來(lái)做文章的。這里的三個(gè)參數(shù)我們，減少任意一個(gè)的值，就可能會(huì)達(dá)到了我們壓縮的效果了。
圖片存在大致可以分為三種形式：
file形式 ，我們存在硬盤上的 都是以file 文件的形式存在的。
bitmap或 stream 形式，圖片在內(nèi)存中要么以bitmap形式要么已 stream形式存在的。
stream 形式，我們圖片在網(wǎng)絡(luò)傳輸?shù)倪^(guò)程中，都是已stream 形式存在。
那么在android中 圖片文件主要是有png，jpg，webP，gif 等幾種類型格式進(jìn)行存儲(chǔ)的。其實(shí)我們圖片壓縮也是在幾個(gè)類型中做處理。
我們?yōu)槭裁匆f(shuō)圖片存在的形式，這會(huì)對(duì)我們以后開(kāi)發(fā)過(guò)程中對(duì)圖片處理需要有一定的幫助的。
在介紹壓縮之前我們先看下相關(guān)api吧，讓我們?cè)谑褂玫臅r(shí)候更加方便和選擇合適的pai來(lái)做相關(guān)操作。
我們?cè)賹?duì)圖片進(jìn)行相關(guān)操作的時(shí)候，主要涉及的類有 Bitmap，BitmapFactory，Matrix。等
Bitmap//將位圖壓縮到指定的outputstream中boolean compress (Bitmap.CompressFormat format, int quality, OutputStream stream)// 創(chuàng)建一個(gè)Bitmap 對(duì)象 ，該方法有個(gè)重載函數(shù)Bitmap createBitmap (Bitmap src)//根據(jù)新配置 拷貝一份新的bitmap ，第二次參數(shù)的意思 他的像素是否可以修改//返回的位圖具有與原圖相同的密度和顏色空間Bitmap copy (Bitmap.Config config, boolean isMutable)//創(chuàng)建一個(gè)新的bitmap ，根據(jù)傳入的寬和高進(jìn)行縮放。Bitmap createScaledBitmap (Bitmap src, int dstWidth, int dstHeight, boolean filter)// 表示圖片以什么格式的算法進(jìn)行壓縮，壓縮后為何格式Bitmap.CompressFormat . JPEG / PNG/ WEBPBitmapFactory// 根據(jù)文件路徑解碼成位圖Bitmap decodeFile (String pathName, BitmapFactory.Options opts)//根據(jù) 留解碼成位圖Bitmap decodeStream (InputStream is)//根據(jù) 資源解碼成為位圖Bitmap decodeResource (Resources res, int id, BitmapFactory.Options opts)//根據(jù) 數(shù)組解碼成位圖Bitmap decodeByteArray (byte[] data, int offset, int length, BitmapFactory.Options opts)// opts.inJustDecodeBounds表示是否將圖片加載到內(nèi)存中 true 不加載但可以獲取圖片的寬高等相關(guān)信息 ，false 加載這里另外需要注意的是， BitmapFactory 獲取圖片的寬/高和圖片位置相關(guān)信息是和程序運(yùn)行的設(shè)備有關(guān)的。
什么意思：就是將一張圖片放到不同的 drawable 目錄下，在不同屏幕密度的設(shè)置上運(yùn)行，獲取到的結(jié)果是不同的，這個(gè)是和android資源加載機(jī)制有關(guān)系的，感興趣的小伙伴可以去研究研究。
BitmapFactory.Options.inSampleSize
圖片縮放的倍數(shù)，主要這個(gè)只必須大于1，這個(gè)值很重要，后面說(shuō)到的尺寸壓縮，就是對(duì)這個(gè)值的計(jì)算，也就是對(duì)原圖進(jìn)行采樣，最后放回一個(gè)較小的圖片放到內(nèi)存中的。例如 inSampleSize == 2 的時(shí)候返回一個(gè)圖像，那它的寬和高 就是原圖的 1/2 , 像素就是原來(lái)的 1/4。 這里inSampleSize 最終值必須是2的冪，任何其他值都將四舍五入到接近2的冪的值。
BitmapFactory.Options.inPreferredConfig
表示一個(gè)像素需要多大的空間存儲(chǔ)，設(shè)置解碼器色彩模式 ，默認(rèn)模式為ARGB_8888 前面我們說(shuō)了每個(gè)模式下占的字節(jié)數(shù)，通過(guò)改字段控制bitmap 最后在內(nèi)存中占用多大內(nèi)存。不過(guò)有點(diǎn)需要注意的是，就算我們?cè)O(shè)置了別的模式，也有可能還是默認(rèn)模式的。為什么了，官方是這么解釋的 ： 解碼器將嘗試根據(jù)系統(tǒng)的屏幕深度選擇最佳匹配配置，以及原始圖像的特征，比如它是否具有每個(gè)像素的 alpha值。
Matrix
//對(duì)圖片進(jìn)行旋轉(zhuǎn)
setRotate(float degrees, float px, float py)
//對(duì)圖片進(jìn)行縮放
setScale(float sx, float sy)
//對(duì)圖片進(jìn)行平移
setTranslate(float dx, float dy)
3.圖片壓縮
說(shuō)了這么多總算說(shuō)到正題了，對(duì)于圖片壓縮按照分類的話，大概可以分為兩類吧，一種為質(zhì)量壓縮，一種為尺寸壓縮。我們這里不管說(shuō)的是那種壓縮，其實(shí)用的都是 google 在android 中封裝好了的壓縮算法，我們只是使用封裝好api進(jìn)行講解，和一些我們做壓縮的時(shí)候的一些經(jīng)驗(yàn)吧。
1）質(zhì)量壓縮
何為質(zhì)量壓縮，在文章開(kāi)頭摘要中就簡(jiǎn)單的介紹了，這里我們?cè)僭敿?xì)的說(shuō)下質(zhì)量壓縮，前面提到過(guò)，質(zhì)量壓縮其實(shí)是不改變?cè)瓐D片的尺寸的前提下改變圖片的透明度和位深，原圖尺寸不改變，像素自然也是沒(méi)有改變的。隨著他壓縮圖片文件大小變小，可是在bitmap內(nèi)存中占用的內(nèi)存是不會(huì)改變的和原圖相比。它雖然沒(méi)有改變圖片的像素，可是它壓縮了圖片中每個(gè)像素的質(zhì)量，這樣就會(huì)出現(xiàn)，如果質(zhì)量比較低，那么這個(gè)圖片就會(huì)變得非常模糊，色彩失真很嚴(yán)重的。我在開(kāi)發(fā)中對(duì)圖片壓縮的時(shí)候，一個(gè)壓縮好的bitmap對(duì)象，在寫入文件的時(shí)候，因?yàn)槲以O(shè)置圖片CompressFormat 屬性為 Bitmap.CompressFormat.PNG，結(jié)果寫入到文件中的圖片體積比原圖還大。這里一定要注意的就是，png格式的圖片是不適合質(zhì)量壓縮的，不管你壓縮質(zhì)量多低，內(nèi)部壓縮算法根本是不會(huì)對(duì)其進(jìn)行壓縮的，為什么? 我們前面在說(shuō)圖片格式的時(shí)候說(shuō)過(guò)，png 圖片是一種無(wú)損的圖片壓縮格式，這也是為什么在說(shuō)圖片壓縮之前，對(duì)圖片的一些基本知識(shí)做個(gè)簡(jiǎn)單介紹。在需求上，這種壓縮非常不適合做縮略圖，也不適合想通過(guò)壓縮圖片來(lái)減小對(duì)內(nèi)存的使用。個(gè)人認(rèn)為這個(gè)只適合，既想保證圖片的尺寸或像素，而同時(shí)又希望減小文件大小的需求而已。說(shuō)了這么多，那么在android中質(zhì)量壓縮通過(guò)什么api來(lái)實(shí)現(xiàn)的了，其實(shí)google 一下這種代碼滿屏都是的，為了減少看到這個(gè)文章的小伙伴去查閱代碼的時(shí)間，就貼上一小段代碼吧：
2）尺寸壓縮
尺寸壓縮 其實(shí)就是針對(duì)圖片的尺寸進(jìn)行修改，這個(gè)過(guò)程就是一個(gè)圖片重新采樣。在android 中圖片重采樣是提供了兩種方法的，一種是臨近采樣，也是我們比較熟悉，通過(guò)改變 inSampSize 值，也叫這采樣率壓縮。第二種叫做雙線性采樣。前面我們?cè)诮榻BApi是時(shí)候?qū)@個(gè)字段進(jìn)行詳細(xì)介紹了。這個(gè)方法也是android 開(kāi)發(fā)小伙伴人人皆知的辦法了，還有很多比較出名的壓縮庫(kù)都說(shuō)是通過(guò)該方法來(lái)做的。其實(shí)我個(gè)人認(rèn)為，采樣壓縮其實(shí)是比較粗暴的。
這樣的圖片是一個(gè)綠色的像素隔著一個(gè)黃色的像素，官方給我的解釋是 x （x為2的倍數(shù)）個(gè)像素最后對(duì)應(yīng)一個(gè)像素，由于采樣率設(shè)置為1/2,所以是兩個(gè)像素生成一個(gè)像素，另一個(gè)自己就被拋棄了，如果只選擇綠色，黃色被拋棄，造成圖片只有一種顏色綠色了。
那到底怎么樣獲取采樣率了？
將BitmapFactory.Options的inJustDecodeBounds參數(shù)設(shè)置為true并加載圖片
從BitmapFactory.Options取出圖片的原始寬高信息, 他們對(duì)應(yīng)于outWidth和outHeight參數(shù)
根據(jù)采樣率的規(guī)則并結(jié)合目標(biāo)View的所需大小計(jì)算出采樣率inSampleSize
將BitmapFactory.Options的inJustDecodeBounds參數(shù)設(shè)為false, 然后重新加載.
通過(guò)以上的四個(gè)步驟，我們最終獲取到一個(gè)最接近我們想要的圖片。在上面步驟中最重要的就是計(jì)算 inSampleSize的值，我們下官方推薦我們的計(jì)算做法是怎么寫的，看代碼：
這個(gè)就不做過(guò)多解釋了，應(yīng)該都能看得懂的，很簡(jiǎn)單，就是根據(jù)需要的寬和高，和圖片的原始寬和高，一直循環(huán)算出一個(gè)合適的 inSampleSize 的值。
雙線性采樣使用的是雙線性內(nèi)插算法，這個(gè)算法不像臨近采樣那樣粗暴，它是參考了源像素對(duì)應(yīng)的位置周圍 2*2個(gè)點(diǎn)的值根據(jù)相對(duì)位置取對(duì)應(yīng)的權(quán)重，經(jīng)過(guò)計(jì)算之后得到目標(biāo)圖像。
雙線性采樣在android使用方式 一般有兩種，我們看實(shí)現(xiàn)代碼：
其實(shí)第一種，在最終也是使用了第二種方式的 matrix 進(jìn)行縮放的。我們發(fā)現(xiàn) createScaledBitmap 函數(shù)的源碼中
還是使用matrix進(jìn)行縮放的
上面兩種也是android中圖片尺寸壓縮中最常見(jiàn)的兩種方法了。對(duì)臨近采樣它的方式是最快的，因?yàn)槲覀冋f(shuō)過(guò)它是直接選擇其中一個(gè)像素作為生成像素，生成的圖片可能會(huì)相對(duì)比較失真，壓縮的太厲害會(huì)產(chǎn)生明顯的鋸齒。而雙線性采樣相對(duì)來(lái)說(shuō)失真就沒(méi)有這樣嚴(yán)重。這里可能有小伙伴就要問(wèn)了，既然雙線性采樣比臨近采樣要好。為什么很多壓縮框架都是采用臨近采樣來(lái)做的？問(wèn)的好，我也查閱過(guò)相關(guān)資料和官方文檔，可惜沒(méi)有找到比較有權(quán)威的說(shuō)法來(lái)證明這點(diǎn)。我說(shuō)說(shuō)我對(duì)這個(gè)觀點(diǎn)的看法吧，如果我們要是使用雙線性采樣對(duì)圖片尺寸壓縮的話，不管是采用第一種還是第二種，我們都必須要有個(gè)bitmap對(duì)象，而再拿到這個(gè)bitmap對(duì)象的時(shí)候，我們是要寫入到內(nèi)存中的，而如果圖片太大的話，在decode的時(shí)候，程序就已經(jīng)OOM了，特別是處理大圖的時(shí)候，這個(gè)方法肯定是不合適的。而臨近采樣是可以在圖片不decode到內(nèi)存的情況下，對(duì)圖片進(jìn)行壓縮處理，最后獲取到的bitmap 是很小的，基本不會(huì)導(dǎo)致OOM的。
3.LibJpeg壓縮
通過(guò)Ndk調(diào)用LibJpeg庫(kù)進(jìn)行壓縮，保留原有的像素，清晰度。這個(gè)庫(kù)廣泛的使用在開(kāi)源的圖片壓縮上的。
4.壓縮策略
其實(shí)對(duì)于壓縮策略，我認(rèn)為無(wú)法肯定的說(shuō)一定是1，或者2。它其實(shí)是看需求的，根據(jù)需求來(lái)定一個(gè)合理的壓縮策略。我個(gè)人認(rèn)為網(wǎng)上的 luban 壓縮庫(kù)，他的策略在某種程度上還算比較具有通用性的，適合大部分需求吧。對(duì)應(yīng) luban的壓縮 算法，我這里簡(jiǎn)單的介紹下，他是將圖片的比例值（短邊除以長(zhǎng)邊）分為了三個(gè)區(qū)間值：
[1, 0.5625) 即圖片處于 [1:1 ~ 9:16) 比例范圍內(nèi)
[0.5625, 0.5) 即圖片處于 [9:16 ~ 1:2) 比例范圍內(nèi)
[0.5, 0) 即圖片處于 [1:2 ~ 1:∞) 比例范圍內(nèi)
然后再去判斷圖片的最長(zhǎng)的邊是否超過(guò)這個(gè)區(qū)間的邊界值，然后再去計(jì)算這個(gè)臨近采樣的 inSampleSize的值。如果想要具體的了解這個(gè)策略，去github 上下載源碼去研究研究，代碼還是很簡(jiǎn)單的。在實(shí)際的開(kāi)發(fā)的過(guò)程中我們可以根據(jù)我們需求，結(jié)合上面幾種壓縮機(jī)制，自己制定一個(gè)比較適合自己的壓縮策略。不過(guò)一般情況都不需要我們自己制定圖片的壓縮策略，采樣壓縮 ，基本已經(jīng)滿足我們的需求的
為什么Android上的圖片就不如IOS上的
libjpeg是廣泛使用的開(kāi)源JPEG圖像庫(kù)，安卓也依賴libjpeg來(lái)壓縮圖片。但是安卓并不是直接封裝的libjpeg，而是基于了另一個(gè)叫Skia的開(kāi)源項(xiàng)目來(lái)作為的圖像處理引擎。Skia是谷歌自己維 護(hù)著的一個(gè)大而全的引擎，各種圖像處理功能均在其中予以實(shí)現(xiàn)，并且廣泛的應(yīng)用于谷歌自己和其它公司的產(chǎn)品中（如：Chrome、Firefox、 Android等）。Skia對(duì)libjpeg進(jìn)行了良好的封裝，基于這個(gè)引擎可以很方便為操作系統(tǒng)、瀏覽器等開(kāi)發(fā)圖像處理功能。
libjpeg在壓縮圖像時(shí)，有一個(gè)參數(shù)叫optimize_coding，關(guān)于這個(gè)參數(shù)，libjpeg.doc有如下解釋：
就是上面那個(gè)解釋optimize_coding這段
這段話大概的意思就是如果設(shè)置optimize_coding為TRUE，將會(huì)使得壓縮圖像過(guò)程中基于圖像數(shù)據(jù)計(jì)算哈弗曼表（關(guān)于圖片壓縮中的哈弗曼表，請(qǐng)自行查閱相關(guān)資料），由于這個(gè)計(jì)算會(huì)顯著消耗空間和時(shí)間，默認(rèn)值被設(shè)置為FALSE。
谷歌的Skia項(xiàng)目工程師們最終沒(méi)有設(shè)置這個(gè)參數(shù)，optimize_coding在Skia中默認(rèn)的等于了FALSE，這就意味著更差的圖片質(zhì)量和更大的圖片文件，而壓縮圖片過(guò)程中所耗費(fèi)的時(shí)間和空間其實(shí)反而是可以忽略不計(jì)的。那么，這個(gè)參數(shù)的影響究竟會(huì)有多大呢？
經(jīng)我們實(shí)測(cè)，使用相同的原始圖片，分別設(shè)置optimize_coding=TRUE和FALSE進(jìn)行壓縮，想達(dá)到接近的圖片質(zhì)量（用Photoshop 放大到像素級(jí)逐塊對(duì)比），FALSE時(shí)的圖片大小大約是TRUE時(shí)的5-10倍。換句話說(shuō)，如果我們想在FALSE和TRUE時(shí)壓縮成相同大小的JPEG 圖片，FALSE的品質(zhì)將大大遜色于TRUE的（雖然品質(zhì)很難量化，但我們不妨說(shuō)成是差5-10倍）。
什么意思呢？意思就是現(xiàn)在設(shè)備發(fā)達(dá)啦，是時(shí)候?qū)ptimize_coding設(shè)置成true了，但是問(wèn)題來(lái)了，Android系統(tǒng)代碼對(duì)于APP來(lái)說(shuō)修改不了，我們有沒(méi)有什么辦法將這個(gè)參數(shù)進(jìn)行設(shè)置呢？答案肯定是有的，那就是自己使用自己的so庫(kù)，不用系統(tǒng)的不就完了。
分析源碼
既然外國(guó)基友都說(shuō)了是Android系統(tǒng)集成了這個(gè)庫(kù)，但是參數(shù)沒(méi)設(shè)置好，咱也不明白為啥Android就是不改…但是我們也得驗(yàn)證一下外國(guó)基友說(shuō)的對(duì)不對(duì)是吧。
那我們就從Bitmap.compress這個(gè)方法說(shuō)起
public boolean compress (Bitmap.CompressFormat format, int quality, OutputStream stream)這個(gè)方法進(jìn)行質(zhì)量壓縮，而且可能失去alpha精度
我們看到quality只能是0-100的值
利用流和byte數(shù)組生成SkJavaOutputStream對(duì)象
相關(guān)更多內(nèi)容查看
https://www.jianshu.com/p/072b6defd938
至此壓縮就完成了，我們也就看出Android系統(tǒng)是通過(guò)libjpeg進(jìn)行壓縮的。
但是Android集成的libjpeg和我們使用的也有一些不一樣，所以我建議使用自己編譯開(kāi)元so進(jìn)行操作，這樣可以根據(jù)我們需求來(lái)定制參數(shù)達(dá)到更好的符合我們項(xiàng)目的目的。
小結(jié)：
我們已經(jīng)知道Android系統(tǒng)中是使用skia庫(kù)進(jìn)行壓縮的，skia庫(kù)中又是使用其他開(kāi)元庫(kù)進(jìn)行壓縮對(duì)于jpg的壓縮就是使用libjpeg這個(gè)庫(kù)。
我們經(jīng)常因?yàn)閳D片太大導(dǎo)致oom，但是很多小伙伴，只是借鑒網(wǎng)上的建議和方法，并不知道原因，那么我們接下來(lái)就大致分析一下圖片在Android中加載由那些因素決定呢？
getByteCount()
表示存儲(chǔ)bitmap像素所占內(nèi)存
getAllocationByteCount()
Returns the size of the allocated memory used to store this bitmap’s pixels.
返回bitmap所占像素已經(jīng)分配的大小
This can be larger than the result of getByteCount() if a bitmap is reused to decode other bitmaps of smaller size, or by manual reconfiguration. See reconfigure(int, int, Config), setWidth(int), setHeight(int), setConfig(Bitmap.Config), and BitmapFactory.Options.inBitmap. If a bitmap is not modified in this way, this value will be the same as that returned by getByteCount().
This value will not change over the lifetime of a Bitmap.
如果一個(gè)bitmap被復(fù)用更小尺寸的bitmap編碼，或者手工重新配置。那么實(shí)際尺寸可能偏小。具體看reconfigure(int, int, Config), setWidth(int), setHeight(int), setConfig(Bitmap.Config), and BitmapFactory.Options.inBitmap.如果不牽扯復(fù)用否是新產(chǎn)生的，那么就和getByteContent()相同。
這個(gè)值在bitmap生命周期內(nèi)不會(huì)改變
所以從代碼看mBuffer.length就是緩沖區(qū)真是長(zhǎng)度
public final int getAllocationByteCount() {if (mBuffer == null) {//mBuffer 代表存儲(chǔ) Bitmap 像素?cái)?shù)據(jù)的字節(jié)數(shù)組。return getByteCount();}return mBuffer.length; }然后我們看看占用內(nèi)存如何計(jì)算的
Bitamp 占用內(nèi)存大小 = 寬度像素 x （inTargetDensity / inDensity） x 高度像素 x （inTargetDensity / inDensity）x 一個(gè)像素所占的內(nèi)存
那么一個(gè)像素占用的內(nèi)存多大呢？這個(gè)就和配置的規(guī)格有關(guān)系
SkBitmap.cpp
static int SkColorTypeBytesPerPixel(SkColorType ct) {static const uint8_t gSize[] = {0, // Unknown1, // Alpha_82, // RGB_5652, // ARGB_44444, // RGBA_88884, // BGRA_88881, // kIndex_8};常用的就是RGBA_8888也就是一個(gè)像素占用四個(gè)字節(jié)大小
- ARGB_8888：每個(gè)像素占四個(gè)字節(jié)，A、R、G、B 分量各占8位，是 Android 的默認(rèn)設(shè)置；
- RGB_565：每個(gè)像素占兩個(gè)字節(jié)，R分量占5位，G分量占6位，B分量占5位；
- ARGB_4444：每個(gè)像素占兩個(gè)字節(jié)，A、R、G、B分量各占4位，成像效果比較差；
- Alpha_8: 只保存透明度，共8位，1字節(jié)；
于此同時(shí)呢，在BitmapFactory 的內(nèi)部類 Options 有兩個(gè)成員變量 inDensity 和 inTargetDensity其中
- inDensity 就 Bitmap 的像素密度，也就是 Bitmap 的成員變量 mDensity默認(rèn)是設(shè)備屏幕的像素密度，可以通過(guò) Bitmap#setDensity(int) 設(shè)置
- inTargetDensity 是圖片的目標(biāo)像素密度，在加載圖片時(shí)就是 drawable 目錄的像素密度
當(dāng)資源加載的時(shí)候會(huì)進(jìn)行這兩個(gè)值的初始化
調(diào)用的是 BitmapFactory#decodeResource 方法，內(nèi)部調(diào)用的是 decodeResourceStream 方法
public static Bitmap decodeResourceStream(Resources res, TypedValue value,InputStream is, Rect pad, Options opts) {//實(shí)際上，我們這里的opts是null的，所以在這里初始化。/**public Options() {inDither = false;inScaled = true;inPremultiplied = true;}*/if (opts == null) {opts = new Options();}if (opts.inDensity == 0 && value != null) {final int density = value.density;if (density == TypedValue.DENSITY_DEFAULT) {opts.inDensity = DisplayMetrics.DENSITY_DEFAULT;} else if (density != TypedValue.DENSITY_NONE) {opts.inDensity = density;//這里density的值如果對(duì)應(yīng)資源目錄為hdpi的話，就是240}}//請(qǐng)注意，inTargetDensity就是當(dāng)前的顯示密度，比如三星s6時(shí)就是640if (opts.inTargetDensity == 0 && res != null) {opts.inTargetDensity = res.getDisplayMetrics().densityDpi;}return decodeStream(is, pad, opts);}會(huì)根據(jù)設(shè)備屏幕像素密度到對(duì)應(yīng) drawable 目錄去尋找圖片，這個(gè)時(shí)候 inTargetDensity/inDensity = 1，圖片不會(huì)做縮放，寬度和高度就是圖片原始的像素規(guī)格，如果沒(méi)有找到，會(huì)到其他 drawable 目錄去找，這個(gè)時(shí)候 drawable 的屏幕像素密度就是 inTargetDensity，會(huì)根據(jù) inTargetDensity/inDensity 的比例對(duì)圖片的寬度和高度進(jìn)行縮放。
所以歸結(jié)上面影響圖片內(nèi)存的原因有：
3.圖片的幾種壓縮辦法
質(zhì)量壓縮
public boolean compress (Bitmap.CompressFormat format, int quality, OutputStream stream)
注意這種方式，是通過(guò)改變alpha通道，改變色彩度等方式達(dá)到壓縮圖片的目的，壓縮使得存儲(chǔ)大小變小，但是并不改變加載到內(nèi)存的大小，也就是說(shuō)，如果你從1M壓縮到了1K，解壓縮出來(lái)在內(nèi)存中大小還是1M。而且有個(gè)很坑的問(wèn)題，就是如果設(shè)置quality=100，這個(gè)圖片存儲(chǔ)大小會(huì)增大，而且會(huì)小幅度失真。具體原因，我在上面分析源碼的時(shí)候還沒(méi)仔細(xì)研究，初步判斷可能是利用傅里葉變換導(dǎo)致。
尺寸壓縮
尺寸壓縮在使用的時(shí)候BitmapFactory.Options 類型的參數(shù)當(dāng)置 BitmapFactory.Options.inJustDecodeBounds=true只讀取圖片首行寬高等信息，并不會(huì)將圖片加載到內(nèi)存中。設(shè)置 BitmapFactory.Options 的 inSampleSize 屬性可以真實(shí)的壓縮 Bitmap 占用的內(nèi)存，加載更小內(nèi)存的 Bitmap。
設(shè)置 inSampleSize 之后，Bitmap 的寬、高都會(huì)縮小 inSampleSize 倍。
inSampleSize 比1小的話會(huì)被當(dāng)做1，任何 inSampleSize 的值會(huì)被取接近2的冪值
色彩模式壓縮
也就是我們?cè)谏誓Ｊ缴线M(jìn)行變換，通過(guò)設(shè)置通過(guò) BitmapFactory.Options.inPreferredConfig改變不同的色彩模式，使得每個(gè)像素大小改變，從而圖片大小改變
Matrix 矩陣變換
使用:
其實(shí)這個(gè)操作并不是節(jié)省內(nèi)存，他只是結(jié)合我們對(duì)尺寸壓縮進(jìn)行補(bǔ)充，我們進(jìn)行尺寸壓縮之后難免不會(huì)滿足我們對(duì)尺寸的要求，所以我們就借助Matrix進(jìn)行矩陣變換，改變圖片的大小。
這個(gè)也是和Matrix一個(gè)道理，都是進(jìn)行縮放。不改變內(nèi)存。
3.圖片壓縮的最終解決方案
我們通過(guò)上面的總結(jié)我們歸納出，圖片的壓縮目的有兩種：
- 壓縮內(nèi)存，防止產(chǎn)生OOM
- 壓縮存儲(chǔ)空間，目的節(jié)約空間，但是解壓到內(nèi)存中大小不變。還是原來(lái)沒(méi)有壓縮圖片時(shí)候的大小。
那么我們應(yīng)該怎么壓縮才合理呢，其實(shí)這個(gè)需要根據(jù)需求來(lái)定，可能有人就會(huì)說(shuō)我說(shuō)的是廢話，但是事實(shí)如此。我提供一些建議： - 使用libjpeg開(kāi)源項(xiàng)目，不使用Android集成的libjpeg，因?yàn)槲覀兛梢愿鶕?jù)需要修改參數(shù)，更符合我們項(xiàng)目的效果。
- 合理通過(guò)尺寸變換和矩陣變換在內(nèi)存上優(yōu)化。
- 對(duì)不同屏幕分辨率的機(jī)型壓縮進(jìn)行壓縮的程度不一樣。
那么我們就開(kāi)始我們比較難的一個(gè)環(huán)節(jié)就是集成開(kāi)源庫(kù)。
4.編譯libjpeg生成so庫(kù)
libjpeg項(xiàng)目下載地址
首先確保我們安裝了ndk環(huán)境，不管是Linux還是windows還是macOs都可以編譯，只要我們有ndk
我們必須知道我們NDK能夠使用，并且可以調(diào)用到我們ndk里面的工具，這就要求我們要配置環(huán)境變量，當(dāng)然Linux和windows不一樣，macOS由于我這種窮逼肯定買不起所以我也布吉島怎么弄。但是思想就是要能用到ndk工具
- windows是在我們環(huán)境變量中進(jìn)行配置
- Linux
當(dāng)然Linux還可以寫.sh來(lái)個(gè)腳本豈不更好
NDK=/opt/ndk/android-ndk-r12b/ PLATFORM=$NDK/platforms/android-15/arch-arm/ PREBUILT=$NDK/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86/ CC=$PREBUILT/bin/arm-linux-androideabi-gcc ./configure --prefix=/home/linc/jpeg-9b/jni/dist --host=arm CC="$CC --sysroot=$PLATFORM"最執(zhí)行寫的.sh
這個(gè)腳本是根據(jù)config文件寫的，那里面有我們需要的參數(shù)還有注釋，所以我們要能看懂那個(gè)才可以。一般情況出了問(wèn)題我們?cè)谘芯磕莻€(gè)吧
引用https://blog.csdn.net/lincyang/article/details/51085737
- 構(gòu)建libjpeg-turbo.so
- 這個(gè)時(shí)候就可以得到libjpegpi.so在…/libjpeg-turbo-android/libjpeg-turbo/libs/armeabi和armeabi-v7a目錄下復(fù)制我們的libjpegpi.so到 …/bither-android-lib/libjpeg-turbo-android/use-libjpeg-turbo-android/jni
得到 libjpegpi.so and libpijni.so
jni使用的時(shí)候一定java的類名要和jni里面方法前面的單詞要對(duì)上
static {
System.loadLibrary("jpegpi");System.loadLibrary("pijni");}
所以如果不改項(xiàng)目的話類名必須為com.pi.common.util.NativeUtil
5.庫(kù)函數(shù)的介紹
所以我們最后的核心就是使用saveBitmap就會(huì)將圖片壓縮并且保存在sd卡上。而且我們獲取圖片的時(shí)候也對(duì)內(nèi)存做了判斷，防止產(chǎn)生oom
https://www.jianshu.com/p/072b6defd938
https://github.com/AndroidHensen/BitmapCompress
https://blog.csdn.net/qq_25412055/article/details/53878655
https://blog.csdn.net/talkxin/article/details/50696511
https://www.cnblogs.com/mc-ksuu/p/6443254.html
https://www.jianshu.com/p/8f21d88d4439
在Android項(xiàng)目中如何使用libjpeg-trubo
首先你要安裝ndk，如果不知道ndk是什么，建議你先從一些簡(jiǎn)單的Android知識(shí)開(kāi)始補(bǔ)這文章可能不太適合你；
第二你要安裝git(如果不會(huì)請(qǐng)google)
git clone git://git.linaro.org/people/tomgall/libjpeg-turbo/libjpeg-turbo.git -b linaro-android把最新的版本克隆下來(lái)
2、編譯
克隆下來(lái)的文件夾名為libjpeg-turbo，所以我們?cè)谑褂肗DK編譯前需要將文件夾命名為JNI：
mv libjpeg-turbo jni使用NDK編譯時(shí)，這里需要注意的是APP_ABI這個(gè)參數(shù)，若需要在不同的平臺(tái)下運(yùn)行，則需要設(shè)置平臺(tái)參數(shù)，如例所示，將編譯出兩個(gè)cpu平臺(tái)的so庫(kù)，不同的平臺(tái)用逗號(hào)分隔
ndk-build APP_ABI=armeabi-v7a,armeabi這時(shí)就可以看到在jni同目錄下會(huì)生成libs與objs兩個(gè)文件夾，生成的.so類庫(kù)就在libs文件夾內(nèi)。
====以上內(nèi)容來(lái)自http://blog.csdn.net/talkxin/article/details/50696511 ========
你還需要把頭文件找齊，都在我們剛剛克隆下來(lái)的代碼目錄里
cderror.h cdjpeg.h config.h jconfig.h jerror.h jinclude.h jmorecfg.h jpeglib.h jversion.h好了，接下來(lái)是怎么編寫c代碼
#include <stdint.h> #include <stdio.h> #include <stdlib.h> #include "jpeg/jpeglib.h" #import <omp.h>#ifdef ANDROID#include <jni.h> #include <android/log.h>#define LOGE(format, ...) __android_log_print(ANDROID_LOG_ERROR, " (>_<)", format, ##__VA_ARGS__) #define LOGI(format, ...) __android_log_print(ANDROID_LOG_INFO, "(^_^)", format, ##__VA_ARGS__) #else #define LOGE(format, ...) printf("(>_<) " format "\n", ##__VA_ARGS__) #define LOGI(format, ...) printf("(^_^) " format "\n", ##__VA_ARGS__) #endifint write_JPEG_file(const char *filename, unsigned char *yData, unsigned char *uData,unsigned char *vData, int quality, int image_width, int image_height);void Java_${這里替換成類的全路徑}_writeJpegFile(JNIEnv *env, jobject jobj,jstring fileName,jobject yBuffer,jint yLen,jobject cbBuffer,jint cbLen,jobject crBuffer,jint uvStride,jint quality,jint width, jint height) {char *filename[500] = {0};sprintf(filename, "%s", (*env)->GetStringUTFChars(env, fileName, NULL));jbyte *y = (*env)->GetDirectBufferAddress(env, yBuffer);jbyte *cb = (*env)->GetDirectBufferAddress(env, cbBuffer);jbyte *cr = (*env)->GetDirectBufferAddress(env, crBuffer);uint8_t *uData = malloc(cbLen);uint8_t *vData = malloc(cbLen);int j, k;int uLimit = 0;int vLimit = 0;if (uvStride == 2) { // yuv420 sp uv交錯(cuò)#pragma omp parallel for num_threads(4)for (j = 0; j < cbLen; j++) {if (j % 2 == 0) {uData[uLimit++] = cb[j];} else {vData[vLimit++] = cb[j];}}#pragma omp parallel for num_threads(4)for (k = 0; k < cbLen; k++) {if (k % 2 == 0) {uData[uLimit++] = cr[k];} else {vData[vLimit++] = cr[k];}}write_JPEG_file(filename, y, uData, vData, quality, width, height);} else { // yuv420pwrite_JPEG_file(filename, y, cb, cr, quality, width, height);}free(uData);free(vData); }int write_JPEG_file(const char *filename, unsigned char *yData, unsigned char *uData,unsigned char *vData, int quality, int image_width, int image_height) { struct jpeg_compress_struct cinfo; struct jpeg_error_mgr jerr;FILE *outfile;JSAMPIMAGE buffer;unsigned char *pSrc, *pDst;int band, i, buf_width[3], buf_height[3];cinfo.err = jpeg_std_error(&jerr);jpeg_create_compress(&cinfo); if ((outfile = fopen(filename, "wb")) == NULL) {return -1;}jpeg_stdio_dest(&cinfo, outfile);cinfo.image_width = image_width; // image width and height, in pixelscinfo.image_height = image_height;cinfo.input_components = 3; // # of color components per pixelcinfo.in_color_space = JCS_RGB; //colorspace of input imagejpeg_set_defaults(&cinfo);jpeg_set_quality(&cinfo, quality, TRUE);cinfo.raw_data_in = TRUE;cinfo.jpeg_color_space = JCS_YCbCr;cinfo.comp_info[0].h_samp_factor = 2;cinfo.comp_info[0].v_samp_factor = 2;jpeg_start_compress(&cinfo, TRUE);buffer = (JSAMPIMAGE) (*cinfo.mem->alloc_small)((j_common_ptr) &cinfo,JPOOL_IMAGE, 3 * sizeof(JSAMPARRAY));#pragma omp parallel for num_threads(4)for (band = 0; band < 3; band++) {buf_width[band] = cinfo.comp_info[band].width_in_blocks * DCTSIZE;buf_height[band] = cinfo.comp_info[band].v_samp_factor * DCTSIZE;buffer[band] = (*cinfo.mem->alloc_sarray)((j_common_ptr) &cinfo,JPOOL_IMAGE, buf_width[band], buf_height[band]);}unsigned char *rawData[3];rawData[0] = yData;rawData[1] = uData;rawData[2] = vData;int src_width[3], src_height[3];#pragma omp parallel for num_threads(4)for (i = 0; i < 3; i++) {src_width[i] = (i == 0) ? image_width : image_width / 2;src_height[i] = (i == 0) ? image_height : image_height / 2;}int max_line = cinfo.max_v_samp_factor * DCTSIZE;int counter;#pragma omp parallel for num_threads(4)for (counter = 0; cinfo.next_scanline < cinfo.image_height; counter++) {//buffer image copy.#pragma omp parallel for num_threads(4)for (band = 0; band < 3; band++) { //每個(gè)分量分別處理int mem_size = src_width[band];//buf_width[band];pDst = (unsigned char *) buffer[band][0];pSrc = (unsigned char *) rawData[band] + counter * buf_height[band] *src_width[band];//buf_width[band]; //yuv.data[band]分別表示YUV起始地址#pragma omp parallel for num_threads(4)for (i = 0; i < buf_height[band]; i++) { //處理每行數(shù)據(jù)memcpy(pDst, pSrc, mem_size);pSrc += src_width[band];//buf_width[band];pDst += buf_width[band];}}jpeg_write_raw_data(&cinfo, buffer, max_line);}jpeg_finish_compress(&cinfo);fclose(outfile);jpeg_destroy_compress(&cinfo);return 0; }這里面用到了openMP對(duì)for循環(huán)進(jìn)行并線處理，感興趣的同學(xué)可以去google一下，這里只簡(jiǎn)單介紹一下怎么用
首先 建立一個(gè)項(xiàng)目 吧那個(gè)C++啥的勾上 然后當(dāng)前Moudlegradle配置
apply plugin: 'com.android.application'android { compileSdkVersion 28 defaultConfig {applicationId "com.example.a15735.test"minSdkVersion 15targetSdkVersion 28versionCode 1versionName "1.0"testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"externalNativeBuild {cmake {cppFlags ""abiFilters 'arm64-v8a', 'armeabi-v7a'}}}buildTypes {release {minifyEnabled falseproguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'} } externalNativeBuild {cmake {//這里選你復(fù)制在jni 文件下的自帶的CMakeLists.txtpath "src/main/jni/CMakeLists.txt"} }}dependencies { implementation fileTree(dir: 'libs', include: ['*.jar']) implementation 'com.android.support:appcompat-v7:28.0.0-rc02' implementation 'com.android.support.constraint:constraint-layout:1.1.3' testImplementation 'junit:junit:4.12' androidTestImplementation 'com.android.support.test:runner:1.0.2' androidTestImplementation 'com.android.support.test.espresso:espresso-core:3.0.2'復(fù)制所有下載號(hào)的源碼
https://github.com/libjpeg-turbo/libjpeg-turbo 下載地址
然后就重新編譯就行了 SO庫(kù)在
總結(jié)
以上是生活随笔為你收集整理的Android编译libjpeg-turbo so高效压缩图片的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： Facebook开源 PyTorch版
- 下一篇： Android如何在免Root下自动Pa