Android编译libjpeg-turbo so高效压缩图片
https://www.jianshu.com/p/8ebe0ddd21f7
https://www.jianshu.com/p/f305fb008ab6
一 . 圖片的基本知識
圖像是由像素組成的，而像素實際上是帶著坐標(biāo)的位置和顏色信息的。它是有若干行和若干列的點組成的，他們相交就會有無數(shù)個點。假如我們隨便取出一個點A 那個這個點可以表示為
A[m,n] = [blue,green,red]
m和n 就是圖像中的第m行和n列
blue 表示藍(lán)色，是三原色（RGB）的第一個值
green 表示綠色，是三原色（RGB）的第二個值
red 表示紅色，是三原色（RGB）的第三個值
我們通常說圖片分辨率其實就是指像素數(shù)，通俗的說是橫向多少個像素 x 縱向多個像素 。那什么是像素： 每張圖片是有色點組成的，每個色點就稱之為像素。比如一張圖片有10萬個色點構(gòu)成，那么這個圖片像素就是 10W。
我們舉個例子：一張圖片分辨率為 500x400 ，那么圖片是有橫向 500個像素、縱向 400個像素，（合計20000像素點）構(gòu)成。
我們在實際項目開開發(fā)中遇到比較多的圖片格式 一般有 .PNG、.JPG、.JPEG、 .WebP 、.GIF、.SVG 等等
PNG：它是一種無損數(shù)據(jù)壓縮位圖圖形文件格式。這也就是說PNG 只支持無損壓縮。對于PNG 格式是有8 位、24位、32位的三種形式的。區(qū)別就是對透明度的支持。
JPG：其實就是 JPEG的另一種叫法
JPEG：它是一種有損壓縮的圖片格式
WebP：Google 開發(fā)出的一種支持alpha 通道的有損壓縮。同等質(zhì)量情況下比 JPEG和PNG小 25%~45%.
GIF：它是動態(tài)圖片的一種格式，和PNG 一樣是一種無損壓縮。
**SVG **: 是一種無損、矢量圖（放大不失真）
就目前來說，Android 原生支持的格式只有 JPEG、PNG、GIF、WEBP（android 4.0 加入）、BMP。而在android層代碼中我們只能調(diào)用的編碼方式只有PNG、JPEG、和WEBP 三種。不過目前來說android 還不支持對GIF 這種的動態(tài)編碼。
注意 ：我們?nèi)粘Ｋ械?.png、.jpg、.jpeg 等等指的是圖像數(shù)據(jù)經(jīng)過壓縮編碼后在媒體上的封存形式，是不能和PNG 、JPG、JEPG 混為一談的。
我們不是說圖片怎么壓縮的嗎？為什么要說圖片格式。因為他們之間是存在聯(lián)系的，比如其中 PNG是無損壓縮格式的圖片，JPEG是有損壓縮格式的圖片，所以對應(yīng)的也有各自的壓縮算法，比如在android中PNG壓縮使用的就是 libpng 進(jìn)行壓縮的，而JPEG的壓縮是用libjepg（7.0之前） 壓縮的，7.0 之后改為libjpeg-turbo是基于libjepg修改的，而比libjepg更快。最大的變化就是相同質(zhì)量的下7.0之后的機器比7.0之前的機器壓縮的圖片要小。
二 . Bitmap
對于開發(fā)android的 小伙伴，對Bitmap肯定是不陌生的，甚至有的小伙伴被它虐的“體無完膚”。在Android中任何圖片資源的顯示對象都是通過bitmap 來顯示的（XML資源通Canvas繪制除外）。
Bitmap 它是圖像處理中的一個非常重要對象。
1.何為bitmap？
我們可以稱之為位圖，是一種存儲像素的數(shù)據(jù)結(jié)構(gòu)，通過這個對象我們可以獲取到一系列和圖片相關(guān)的屬性， 并且可以對圖像進(jìn)行處理，比如切割，放大等等，相關(guān)操作。
2.bitmap 存儲空間
隨著android系統(tǒng)的不斷升級，bitmap的存儲空間也在發(fā)生變成，而bitmap 的存儲空間主要有三個地方：
1）Native Memory
在android 2.3 以下的版本，bitmap像素數(shù)據(jù)是存儲在 Native 空間中，如果需要釋放是要主動調(diào)用 recycle()方法
2）Dalvik Heap
在Android 3.0 以上版本，bitmap的像素數(shù)據(jù)存儲在虛擬機堆中，不需要我們再去主動調(diào)用recycle()方法，gc會幫我們?nèi)セ厥铡?/p>
3）Ashmem
很多小伙伴可能不知道這個是什么，它是匿名共享存儲空間。我們在實際開發(fā)中使用圖片加載庫中，有一個庫就是利用這個一個空間來進(jìn)行bitmap 對象的存儲的，他就是大名鼎鼎的Fresco 圖片加載庫。
不過這里需要注意一點: 在Android 4.4 以前的版本中 Ashmem 是和App 進(jìn)程空間是隔離的互相不影響，而在Android 4.4以后的版本中，Ashmemk空間是包含在App所占用的內(nèi)存空間。
說了這么多我們還是不知道bitmap 在內(nèi)存空間中到底是占用多大的，其實bitmap 在內(nèi)存空間中所占用的內(nèi)存計算是這樣的：
pixelWidth x pixelHeight x bytesPerPixel（bitmap 的寬 x 高 x 每個像素所占的字節(jié)），所有如果相同的Bitmap對象， 每個像素所占用的字節(jié)大小，決定了這個bitmap 在內(nèi)存中所占用的內(nèi)存大小。
上面既然說了，所占用的字節(jié)大小決定bitmap內(nèi)存大小，那么怎么樣能讓每個像素所占的字節(jié)變小。在我們Bitmap對象中有一個比較重要的枚舉類 Config ，這個Config 是用來設(shè)置顏色配置信息的。對于Config配置有四個變量。
Config 配置：
alpha_8 ： 占用8位，1個字節(jié)，顏色信息只由透明組成。
argb_4444: 占用16位，2個字節(jié)，顏色有透明度和R (red)G(green)B(blue)組成。
3.argb_8888: 占用34位，4個字節(jié)，顏色有透明度和R (red)G(green)B(blue)組成。
這里可能有人會問為什么 argb_4444和 argb_8888都是 有ARGB組成為什么所占的字節(jié)不同，因為每個部分所占用的字節(jié)是不同的，argb_4444每個部分占用4個字節(jié)，而argb_8888每個部分占用8位。
4.rgb_565: 占用16位，2個字節(jié)，顏色有R (red)G(green)B(blue)組成。
提示：我們通常在操作bitmap 的時候，是必須要和這個配置打交道的，搞明白對使用bitmap的時候，提供幫助。特別是防止OOM，有很大作用。如果我們平時對圖片處理，如多對圖片的透明度沒特別要求，比較建議使用 rgb_565 這個配置，因為他和其它幾個比較，性價比最高的。比argb_4444 顯示圖片清晰，argb_8888占用內(nèi)存少一半，而alpha_8只有透明度，對圖片沒什么意思。既然我們知道這寫參數(shù)的意義了，我們就可以通過設(shè)置該配置，來讓我們bitmap 占用內(nèi)存空間變小。
說了這么多，那么Bitmap在內(nèi)存究竟占用多少內(nèi)存？使用Android Api的 getByteCount 方法即可。
通過這個方法，我們就可以獲取當(dāng)前運行的 bitmap 占用的內(nèi)存。
三. 壓縮
既然我們知道了，bitmap在內(nèi)存中占用空間 = bitmap 的寬 x 高 x 每個像素所占的字節(jié)數(shù)。那么Bitmap 壓縮都是圍繞這個來做文章的。這里的三個參數(shù)我們，減少任意一個的值，就可能會達(dá)到了我們壓縮的效果了。
圖片存在大致可以分為三種形式：
file形式 ，我們存在硬盤上的 都是以file 文件的形式存在的。
bitmap或 stream 形式，圖片在內(nèi)存中要么以bitmap形式要么已 stream形式存在的。
stream 形式，我們圖片在網(wǎng)絡(luò)傳輸?shù)倪^程中，都是已stream 形式存在。
那么在android中 圖片文件主要是有png，jpg，webP，gif 等幾種類型格式進(jìn)行存儲的。其實我們圖片壓縮也是在幾個類型中做處理。
我們?yōu)槭裁匆f圖片存在的形式，這會對我們以后開發(fā)過程中對圖片處理需要有一定的幫助的。
在介紹壓縮之前我們先看下相關(guān)api吧，讓我們在使用的時候更加方便和選擇合適的pai來做相關(guān)操作。
我們再對圖片進(jìn)行相關(guān)操作的時候，主要涉及的類有 Bitmap，BitmapFactory，Matrix。等
Bitmap//將位圖壓縮到指定的outputstream中boolean compress (Bitmap.CompressFormat format, int quality, OutputStream stream)// 創(chuàng)建一個Bitmap 對象 ，該方法有個重載函數(shù)Bitmap createBitmap (Bitmap src)//根據(jù)新配置 拷貝一份新的bitmap ，第二次參數(shù)的意思 他的像素是否可以修改//返回的位圖具有與原圖相同的密度和顏色空間Bitmap copy (Bitmap.Config config, boolean isMutable)//創(chuàng)建一個新的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)信息是和程序運行的設(shè)備有關(guān)的。
什么意思：就是將一張圖片放到不同的 drawable 目錄下，在不同屏幕密度的設(shè)置上運行，獲取到的結(jié)果是不同的，這個是和android資源加載機制有關(guān)系的，感興趣的小伙伴可以去研究研究。
BitmapFactory.Options.inSampleSize
圖片縮放的倍數(shù)，主要這個只必須大于1，這個值很重要，后面說到的尺寸壓縮，就是對這個值的計算，也就是對原圖進(jìn)行采樣，最后放回一個較小的圖片放到內(nèi)存中的。例如 inSampleSize == 2 的時候返回一個圖像，那它的寬和高 就是原圖的 1/2 , 像素就是原來的 1/4。 這里inSampleSize 最終值必須是2的冪，任何其他值都將四舍五入到接近2的冪的值。
BitmapFactory.Options.inPreferredConfig
表示一個像素需要多大的空間存儲，設(shè)置解碼器色彩模式 ，默認(rèn)模式為ARGB_8888 前面我們說了每個模式下占的字節(jié)數(shù)，通過改字段控制bitmap 最后在內(nèi)存中占用多大內(nèi)存。不過有點需要注意的是，就算我們設(shè)置了別的模式，也有可能還是默認(rèn)模式的。為什么了，官方是這么解釋的 ： 解碼器將嘗試根據(jù)系統(tǒng)的屏幕深度選擇最佳匹配配置，以及原始圖像的特征，比如它是否具有每個像素的 alpha值。
Matrix
//對圖片進(jìn)行旋轉(zhuǎn)
setRotate(float degrees, float px, float py)
//對圖片進(jìn)行縮放
setScale(float sx, float sy)
//對圖片進(jìn)行平移
setTranslate(float dx, float dy)
3.圖片壓縮
說了這么多總算說到正題了，對于圖片壓縮按照分類的話，大概可以分為兩類吧，一種為質(zhì)量壓縮，一種為尺寸壓縮。我們這里不管說的是那種壓縮，其實用的都是 google 在android 中封裝好了的壓縮算法，我們只是使用封裝好api進(jìn)行講解，和一些我們做壓縮的時候的一些經(jīng)驗吧。
1）質(zhì)量壓縮
何為質(zhì)量壓縮，在文章開頭摘要中就簡單的介紹了，這里我們再詳細(xì)的說下質(zhì)量壓縮，前面提到過，質(zhì)量壓縮其實是不改變原圖片的尺寸的前提下改變圖片的透明度和位深，原圖尺寸不改變，像素自然也是沒有改變的。隨著他壓縮圖片文件大小變小，可是在bitmap內(nèi)存中占用的內(nèi)存是不會改變的和原圖相比。它雖然沒有改變圖片的像素，可是它壓縮了圖片中每個像素的質(zhì)量，這樣就會出現(xiàn)，如果質(zhì)量比較低，那么這個圖片就會變得非常模糊，色彩失真很嚴(yán)重的。我在開發(fā)中對圖片壓縮的時候，一個壓縮好的bitmap對象，在寫入文件的時候，因為我設(shè)置圖片CompressFormat 屬性為 Bitmap.CompressFormat.PNG，結(jié)果寫入到文件中的圖片體積比原圖還大。這里一定要注意的就是，png格式的圖片是不適合質(zhì)量壓縮的，不管你壓縮質(zhì)量多低，內(nèi)部壓縮算法根本是不會對其進(jìn)行壓縮的，為什么? 我們前面在說圖片格式的時候說過，png 圖片是一種無損的圖片壓縮格式，這也是為什么在說圖片壓縮之前，對圖片的一些基本知識做個簡單介紹。在需求上，這種壓縮非常不適合做縮略圖，也不適合想通過壓縮圖片來減小對內(nèi)存的使用。個人認(rèn)為這個只適合，既想保證圖片的尺寸或像素，而同時又希望減小文件大小的需求而已。說了這么多，那么在android中質(zhì)量壓縮通過什么api來實現(xiàn)的了，其實google 一下這種代碼滿屏都是的，為了減少看到這個文章的小伙伴去查閱代碼的時間，就貼上一小段代碼吧：
2）尺寸壓縮
尺寸壓縮 其實就是針對圖片的尺寸進(jìn)行修改，這個過程就是一個圖片重新采樣。在android 中圖片重采樣是提供了兩種方法的，一種是臨近采樣，也是我們比較熟悉，通過改變 inSampSize 值，也叫這采樣率壓縮。第二種叫做雙線性采樣。前面我們在介紹Api是時候?qū)@個字段進(jìn)行詳細(xì)介紹了。這個方法也是android 開發(fā)小伙伴人人皆知的辦法了，還有很多比較出名的壓縮庫都說是通過該方法來做的。其實我個人認(rèn)為，采樣壓縮其實是比較粗暴的。
這樣的圖片是一個綠色的像素隔著一個黃色的像素，官方給我的解釋是 x （x為2的倍數(shù)）個像素最后對應(yīng)一個像素，由于采樣率設(shè)置為1/2,所以是兩個像素生成一個像素，另一個自己就被拋棄了，如果只選擇綠色，黃色被拋棄，造成圖片只有一種顏色綠色了。
那到底怎么樣獲取采樣率了？
將BitmapFactory.Options的inJustDecodeBounds參數(shù)設(shè)置為true并加載圖片
從BitmapFactory.Options取出圖片的原始寬高信息, 他們對應(yīng)于outWidth和outHeight參數(shù)
根據(jù)采樣率的規(guī)則并結(jié)合目標(biāo)View的所需大小計算出采樣率inSampleSize
將BitmapFactory.Options的inJustDecodeBounds參數(shù)設(shè)為false, 然后重新加載.
通過以上的四個步驟，我們最終獲取到一個最接近我們想要的圖片。在上面步驟中最重要的就是計算 inSampleSize的值，我們下官方推薦我們的計算做法是怎么寫的，看代碼：
這個就不做過多解釋了，應(yīng)該都能看得懂的，很簡單，就是根據(jù)需要的寬和高，和圖片的原始寬和高，一直循環(huán)算出一個合適的 inSampleSize 的值。
雙線性采樣使用的是雙線性內(nèi)插算法，這個算法不像臨近采樣那樣粗暴，它是參考了源像素對應(yīng)的位置周圍 2*2個點的值根據(jù)相對位置取對應(yīng)的權(quán)重，經(jīng)過計算之后得到目標(biāo)圖像。
雙線性采樣在android使用方式 一般有兩種，我們看實現(xiàn)代碼：
其實第一種，在最終也是使用了第二種方式的 matrix 進(jìn)行縮放的。我們發(fā)現(xiàn) createScaledBitmap 函數(shù)的源碼中
還是使用matrix進(jìn)行縮放的
上面兩種也是android中圖片尺寸壓縮中最常見的兩種方法了。對臨近采樣它的方式是最快的，因為我們說過它是直接選擇其中一個像素作為生成像素，生成的圖片可能會相對比較失真，壓縮的太厲害會產(chǎn)生明顯的鋸齒。而雙線性采樣相對來說失真就沒有這樣嚴(yán)重。這里可能有小伙伴就要問了，既然雙線性采樣比臨近采樣要好。為什么很多壓縮框架都是采用臨近采樣來做的？問的好，我也查閱過相關(guān)資料和官方文檔，可惜沒有找到比較有權(quán)威的說法來證明這點。我說說我對這個觀點的看法吧，如果我們要是使用雙線性采樣對圖片尺寸壓縮的話，不管是采用第一種還是第二種，我們都必須要有個bitmap對象，而再拿到這個bitmap對象的時候，我們是要寫入到內(nèi)存中的，而如果圖片太大的話，在decode的時候，程序就已經(jīng)OOM了，特別是處理大圖的時候，這個方法肯定是不合適的。而臨近采樣是可以在圖片不decode到內(nèi)存的情況下，對圖片進(jìn)行壓縮處理，最后獲取到的bitmap 是很小的，基本不會導(dǎo)致OOM的。
3.LibJpeg壓縮
通過Ndk調(diào)用LibJpeg庫進(jìn)行壓縮，保留原有的像素，清晰度。這個庫廣泛的使用在開源的圖片壓縮上的。
4.壓縮策略
其實對于壓縮策略，我認(rèn)為無法肯定的說一定是1，或者2。它其實是看需求的，根據(jù)需求來定一個合理的壓縮策略。我個人認(rèn)為網(wǎng)上的 luban 壓縮庫，他的策略在某種程度上還算比較具有通用性的，適合大部分需求吧。對應(yīng) luban的壓縮 算法，我這里簡單的介紹下，他是將圖片的比例值（短邊除以長邊）分為了三個區(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)
然后再去判斷圖片的最長的邊是否超過這個區(qū)間的邊界值，然后再去計算這個臨近采樣的 inSampleSize的值。如果想要具體的了解這個策略，去github 上下載源碼去研究研究，代碼還是很簡單的。在實際的開發(fā)的過程中我們可以根據(jù)我們需求，結(jié)合上面幾種壓縮機制，自己制定一個比較適合自己的壓縮策略。不過一般情況都不需要我們自己制定圖片的壓縮策略，采樣壓縮 ，基本已經(jīng)滿足我們的需求的
為什么Android上的圖片就不如IOS上的
libjpeg是廣泛使用的開源JPEG圖像庫，安卓也依賴libjpeg來壓縮圖片。但是安卓并不是直接封裝的libjpeg，而是基于了另一個叫Skia的開源項目來作為的圖像處理引擎。Skia是谷歌自己維 護(hù)著的一個大而全的引擎，各種圖像處理功能均在其中予以實現(xiàn)，并且廣泛的應(yīng)用于谷歌自己和其它公司的產(chǎn)品中（如：Chrome、Firefox、 Android等）。Skia對libjpeg進(jìn)行了良好的封裝，基于這個引擎可以很方便為操作系統(tǒng)、瀏覽器等開發(fā)圖像處理功能。
libjpeg在壓縮圖像時，有一個參數(shù)叫optimize_coding，關(guān)于這個參數(shù)，libjpeg.doc有如下解釋：
就是上面那個解釋optimize_coding這段
這段話大概的意思就是如果設(shè)置optimize_coding為TRUE，將會使得壓縮圖像過程中基于圖像數(shù)據(jù)計算哈弗曼表（關(guān)于圖片壓縮中的哈弗曼表，請自行查閱相關(guān)資料），由于這個計算會顯著消耗空間和時間，默認(rèn)值被設(shè)置為FALSE。
谷歌的Skia項目工程師們最終沒有設(shè)置這個參數(shù)，optimize_coding在Skia中默認(rèn)的等于了FALSE，這就意味著更差的圖片質(zhì)量和更大的圖片文件，而壓縮圖片過程中所耗費的時間和空間其實反而是可以忽略不計的。那么，這個參數(shù)的影響究竟會有多大呢？
經(jīng)我們實測，使用相同的原始圖片，分別設(shè)置optimize_coding=TRUE和FALSE進(jìn)行壓縮，想達(dá)到接近的圖片質(zhì)量（用Photoshop 放大到像素級逐塊對比），FALSE時的圖片大小大約是TRUE時的5-10倍。換句話說，如果我們想在FALSE和TRUE時壓縮成相同大小的JPEG 圖片，FALSE的品質(zhì)將大大遜色于TRUE的（雖然品質(zhì)很難量化，但我們不妨說成是差5-10倍）。
什么意思呢？意思就是現(xiàn)在設(shè)備發(fā)達(dá)啦，是時候?qū)ptimize_coding設(shè)置成true了，但是問題來了，Android系統(tǒng)代碼對于APP來說修改不了，我們有沒有什么辦法將這個參數(shù)進(jìn)行設(shè)置呢？答案肯定是有的，那就是自己使用自己的so庫，不用系統(tǒng)的不就完了。
分析源碼
既然外國基友都說了是Android系統(tǒng)集成了這個庫，但是參數(shù)沒設(shè)置好，咱也不明白為啥Android就是不改…但是我們也得驗證一下外國基友說的對不對是吧。
那我們就從Bitmap.compress這個方法說起
public boolean compress (Bitmap.CompressFormat format, int quality, OutputStream stream)這個方法進(jìn)行質(zhì)量壓縮，而且可能失去alpha精度
我們看到quality只能是0-100的值
利用流和byte數(shù)組生成SkJavaOutputStream對象
相關(guān)更多內(nèi)容查看
https://www.jianshu.com/p/072b6defd938
至此壓縮就完成了，我們也就看出Android系統(tǒng)是通過libjpeg進(jìn)行壓縮的。
但是Android集成的libjpeg和我們使用的也有一些不一樣，所以我建議使用自己編譯開元so進(jìn)行操作，這樣可以根據(jù)我們需求來定制參數(shù)達(dá)到更好的符合我們項目的目的。
小結(jié)：
我們已經(jīng)知道Android系統(tǒng)中是使用skia庫進(jìn)行壓縮的，skia庫中又是使用其他開元庫進(jìn)行壓縮對于jpg的壓縮就是使用libjpeg這個庫。
我們經(jīng)常因為圖片太大導(dǎo)致oom，但是很多小伙伴，只是借鑒網(wǎng)上的建議和方法，并不知道原因，那么我們接下來就大致分析一下圖片在Android中加載由那些因素決定呢？
getByteCount()
表示存儲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.
如果一個bitmap被復(fù)用更小尺寸的bitmap編碼，或者手工重新配置。那么實際尺寸可能偏小。具體看reconfigure(int, int, Config), setWidth(int), setHeight(int), setConfig(Bitmap.Config), and BitmapFactory.Options.inBitmap.如果不牽扯復(fù)用否是新產(chǎn)生的，那么就和getByteContent()相同。
這個值在bitmap生命周期內(nèi)不會改變
所以從代碼看mBuffer.length就是緩沖區(qū)真是長度
public final int getAllocationByteCount() {if (mBuffer == null) {//mBuffer 代表存儲 Bitmap 像素數(shù)據(jù)的字節(jié)數(shù)組。return getByteCount();}return mBuffer.length; }然后我們看看占用內(nèi)存如何計算的
Bitamp 占用內(nèi)存大小 = 寬度像素 x （inTargetDensity / inDensity） x 高度像素 x （inTargetDensity / inDensity）x 一個像素所占的內(nèi)存
那么一個像素占用的內(nèi)存多大呢？這個就和配置的規(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也就是一個像素占用四個字節(jié)大小
- ARGB_8888：每個像素占四個字節(jié)，A、R、G、B 分量各占8位，是 Android 的默認(rèn)設(shè)置；
- RGB_565：每個像素占兩個字節(jié)，R分量占5位，G分量占6位，B分量占5位；
- ARGB_4444：每個像素占兩個字節(jié)，A、R、G、B分量各占4位，成像效果比較差；
- Alpha_8: 只保存透明度，共8位，1字節(jié)；
于此同時呢，在BitmapFactory 的內(nèi)部類 Options 有兩個成員變量 inDensity 和 inTargetDensity其中
- inDensity 就 Bitmap 的像素密度，也就是 Bitmap 的成員變量 mDensity默認(rèn)是設(shè)備屏幕的像素密度，可以通過 Bitmap#setDensity(int) 設(shè)置
- inTargetDensity 是圖片的目標(biāo)像素密度，在加載圖片時就是 drawable 目錄的像素密度
當(dāng)資源加載的時候會進(jìn)行這兩個值的初始化
調(diào)用的是 BitmapFactory#decodeResource 方法，內(nèi)部調(diào)用的是 decodeResourceStream 方法
public static Bitmap decodeResourceStream(Resources res, TypedValue value,InputStream is, Rect pad, Options opts) {//實際上，我們這里的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的值如果對應(yīng)資源目錄為hdpi的話，就是240}}//請注意，inTargetDensity就是當(dāng)前的顯示密度，比如三星s6時就是640if (opts.inTargetDensity == 0 && res != null) {opts.inTargetDensity = res.getDisplayMetrics().densityDpi;}return decodeStream(is, pad, opts);}會根據(jù)設(shè)備屏幕像素密度到對應(yīng) drawable 目錄去尋找圖片，這個時候 inTargetDensity/inDensity = 1，圖片不會做縮放，寬度和高度就是圖片原始的像素規(guī)格，如果沒有找到，會到其他 drawable 目錄去找，這個時候 drawable 的屏幕像素密度就是 inTargetDensity，會根據(jù) inTargetDensity/inDensity 的比例對圖片的寬度和高度進(jìn)行縮放。
所以歸結(jié)上面影響圖片內(nèi)存的原因有：
3.圖片的幾種壓縮辦法
質(zhì)量壓縮
public boolean compress (Bitmap.CompressFormat format, int quality, OutputStream stream)
注意這種方式，是通過改變alpha通道，改變色彩度等方式達(dá)到壓縮圖片的目的，壓縮使得存儲大小變小，但是并不改變加載到內(nèi)存的大小，也就是說，如果你從1M壓縮到了1K，解壓縮出來在內(nèi)存中大小還是1M。而且有個很坑的問題，就是如果設(shè)置quality=100，這個圖片存儲大小會增大，而且會小幅度失真。具體原因，我在上面分析源碼的時候還沒仔細(xì)研究，初步判斷可能是利用傅里葉變換導(dǎo)致。
尺寸壓縮
尺寸壓縮在使用的時候BitmapFactory.Options 類型的參數(shù)當(dāng)置 BitmapFactory.Options.inJustDecodeBounds=true只讀取圖片首行寬高等信息，并不會將圖片加載到內(nèi)存中。設(shè)置 BitmapFactory.Options 的 inSampleSize 屬性可以真實的壓縮 Bitmap 占用的內(nèi)存，加載更小內(nèi)存的 Bitmap。
設(shè)置 inSampleSize 之后，Bitmap 的寬、高都會縮小 inSampleSize 倍。
inSampleSize 比1小的話會被當(dāng)做1，任何 inSampleSize 的值會被取接近2的冪值
色彩模式壓縮
也就是我們在色彩模式上進(jìn)行變換，通過設(shè)置通過 BitmapFactory.Options.inPreferredConfig改變不同的色彩模式，使得每個像素大小改變，從而圖片大小改變
Matrix 矩陣變換
使用:
其實這個操作并不是節(jié)省內(nèi)存，他只是結(jié)合我們對尺寸壓縮進(jìn)行補充，我們進(jìn)行尺寸壓縮之后難免不會滿足我們對尺寸的要求，所以我們就借助Matrix進(jìn)行矩陣變換，改變圖片的大小。
這個也是和Matrix一個道理，都是進(jìn)行縮放。不改變內(nèi)存。
3.圖片壓縮的最終解決方案
我們通過上面的總結(jié)我們歸納出，圖片的壓縮目的有兩種：
- 壓縮內(nèi)存，防止產(chǎn)生OOM
- 壓縮存儲空間，目的節(jié)約空間，但是解壓到內(nèi)存中大小不變。還是原來沒有壓縮圖片時候的大小。
那么我們應(yīng)該怎么壓縮才合理呢，其實這個需要根據(jù)需求來定，可能有人就會說我說的是廢話，但是事實如此。我提供一些建議： - 使用libjpeg開源項目，不使用Android集成的libjpeg，因為我們可以根據(jù)需要修改參數(shù)，更符合我們項目的效果。
- 合理通過尺寸變換和矩陣變換在內(nèi)存上優(yōu)化。
- 對不同屏幕分辨率的機型壓縮進(jìn)行壓縮的程度不一樣。
那么我們就開始我們比較難的一個環(huán)節(jié)就是集成開源庫。
4.編譯libjpeg生成so庫
libjpeg項目下載地址
首先確保我們安裝了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來個腳本豈不更好
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
這個腳本是根據(jù)config文件寫的，那里面有我們需要的參數(shù)還有注釋，所以我們要能看懂那個才可以。一般情況出了問題我們在研究那個吧
引用https://blog.csdn.net/lincyang/article/details/51085737
- 構(gòu)建libjpeg-turbo.so
- 這個時候就可以得到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使用的時候一定java的類名要和jni里面方法前面的單詞要對上
static {
System.loadLibrary("jpegpi");System.loadLibrary("pijni");}
所以如果不改項目的話類名必須為com.pi.common.util.NativeUtil
5.庫函數(shù)的介紹
所以我們最后的核心就是使用saveBitmap就會將圖片壓縮并且保存在sd卡上。而且我們獲取圖片的時候也對內(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項目中如何使用libjpeg-trubo
首先你要安裝ndk，如果不知道ndk是什么，建議你先從一些簡單的Android知識開始補這文章可能不太適合你；
第二你要安裝git(如果不會請google)
git clone git://git.linaro.org/people/tomgall/libjpeg-turbo/libjpeg-turbo.git -b linaro-android把最新的版本克隆下來
2、編譯
克隆下來的文件夾名為libjpeg-turbo，所以我們在使用NDK編譯前需要將文件夾命名為JNI：
mv libjpeg-turbo jni使用NDK編譯時，這里需要注意的是APP_ABI這個參數(shù)，若需要在不同的平臺下運行，則需要設(shè)置平臺參數(shù)，如例所示，將編譯出兩個cpu平臺的so庫，不同的平臺用逗號分隔
ndk-build APP_ABI=armeabi-v7a,armeabi這時就可以看到在jni同目錄下會生成libs與objs兩個文件夾，生成的.so類庫就在libs文件夾內(nèi)。
====以上內(nèi)容來自http://blog.csdn.net/talkxin/article/details/50696511 ========
你還需要把頭文件找齊，都在我們剛剛克隆下來的代碼目錄里
cderror.h cdjpeg.h config.h jconfig.h jerror.h jinclude.h jmorecfg.h jpeglib.h jversion.h好了，接下來是怎么編寫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交錯#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++) { //每個分量分別處理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對for循環(huán)進(jìn)行并線處理，感興趣的同學(xué)可以去google一下，這里只簡單介紹一下怎么用
首先 建立一個項目 吧那個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ù)制所有下載號的源碼
https://github.com/libjpeg-turbo/libjpeg-turbo 下載地址
然后就重新編譯就行了 SO庫在
總結(jié)
以上是生活随笔為你收集整理的Android编译libjpeg-turbo so高效压缩图片的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Facebook开源 PyTorch版
- 下一篇： elemnt的Table 表格使用注意事