在公司遇到了對(duì)圖片壓縮保存的問題，發(fā)現(xiàn)這個(gè)問題還挺深列疗，而且網(wǎng)上資料比較有限大多數(shù)的都是BitmapFactory的操作滑蚯，而且在使用bitmap中 容易出現(xiàn)OOM，因此自己深入研究了一下抵栈，在此記錄:
自己也有兩個(gè)問題：
1.為何Android圖片壓縮效率比IOS的底而且質(zhì)量差？
2.Android系統(tǒng)是如何編碼壓縮保存圖片的坤次？
解答
- 為什么Android的圖片壓縮質(zhì)量要比iPhone的壓縮質(zhì)量差很多古劲，這是因?yàn)锳ndroid底層犯的一個(gè)小錯(cuò)誤：libjpeg。并且這個(gè)錯(cuò)誤一直持續(xù)到了今天缰猴。libjpeg是廣泛使用的開源JPEG圖像庫（參考 http://en.wikipedia.org/wiki/Libjpeg ）产艾，安卓也依賴libjpeg來壓縮圖片。通過查看源碼滑绒，我們會(huì)發(fā)現(xiàn)安卓并不是直接封裝的libjpeg闷堡，而是基于了另一個(gè)叫Skia的開源項(xiàng)目（http://en.wikipedia.org/wiki/Skia_Graphics_Engine）來作為的圖像處理引擎。Skia是谷歌自己維 護(hù)著的一個(gè)大而全的引擎疑故，各種圖像處理功能均在其中予以實(shí)現(xiàn)杠览，并且廣泛的應(yīng)用于谷歌自己和其它公司的產(chǎn)品中（如：Chrome、Firefox纵势、 Android等）踱阿。Skia對(duì)libjpeg進(jìn)行了良好的封裝管钳，基于這個(gè)引擎可以很方便為操作系統(tǒng)、瀏覽器等開發(fā)圖像處理功能软舌。
libjpeg在壓縮圖像時(shí)才漆，有一個(gè)參數(shù)叫optimize_coding，關(guān)于這個(gè)參數(shù)佛点，libjpeg.doc有如下解釋：
boolean optimize_coding
TRUE causes the compressor to compute optimal Huffman coding tables
for the image. This requires an extra pass over the data and
therefore costs a good deal of space and time. The default is
FALSE, which tells the compressor to use the supplied or default
Huffman tables. In most cases optimal tables save only a few percent
of file size compared to the default tables. Note that when this is
TRUE, you need not supply Huffman tables at all, and any you do
supply will be overwritten.
這段話大概的意思就是如果設(shè)置optimize_coding為TRUE醇滥，將會(huì)使得壓縮圖像過程中基于圖像數(shù)據(jù)計(jì)算哈弗曼表（關(guān)于圖片壓縮中的哈弗曼表，請(qǐng)自行查閱相關(guān)資料）超营，由于這個(gè)計(jì)算會(huì)顯著消耗空間和時(shí)間鸳玩，默認(rèn)值被設(shè)置為FALSE。
這段解釋乍看起來沒有任何問題糟描，libjpeg的代碼也經(jīng)受了十多年的考驗(yàn)怀喉，健壯而高效。但很多人忽略了這一點(diǎn)船响，那就是躬拢，這段解釋是十多年前寫的，對(duì)于當(dāng) 時(shí)的計(jì)算設(shè)備來說见间，空間和時(shí)間的消耗可能是顯著的聊闯，但到今天，這似乎不應(yīng)再是問題米诉，相反菱蔬，我們應(yīng)該更多的考慮圖片的品質(zhì)（越來越好的顯示技術(shù)）和圖片的大 小（越來越依賴于云服務(wù)）史侣。
谷歌的Skia項(xiàng)目工程師們最終沒有設(shè)置這個(gè)參數(shù)拴泌，optimize_coding在Skia中默認(rèn)的等于了FALSE，這就意味著更差的圖片質(zhì)量和更大的圖片文件惊橱，而壓縮圖片過程中所耗費(fèi)的時(shí)間和空間其實(shí)反而是可以忽略不計(jì)的蚪腐。那么，這個(gè)參數(shù)的影響究竟會(huì)有多大呢税朴？
經(jīng)我們實(shí)測(cè)回季，使用相同的原始圖片，分別設(shè)置optimize_coding=TRUE和FALSE進(jìn)行壓縮正林，想達(dá)到接近的圖片質(zhì)量（用Photoshop 放大到像素級(jí)逐塊對(duì)比）泡一，F(xiàn)ALSE時(shí)的圖片大小大約是TRUE時(shí)的5-10倍。換句話說觅廓，如果我們想在FALSE和TRUE時(shí)壓縮成相同大小的JPEG 圖片鼻忠，F(xiàn)ALSE的品質(zhì)將大大遜色于TRUE的（雖然品質(zhì)很難量化，但我們不妨說成是差5-10倍）哪亿。
我們又對(duì)Android和iOS進(jìn)行了對(duì)比（均使用標(biāo)準(zhǔn)的JPEG壓縮方法）粥烁，兩個(gè)系統(tǒng)都沒有提供設(shè)置optimize_coding的接口（通過閱讀源 碼贤笆，我們已經(jīng)知道Android是FALSE，iOS不詳）讨阻，當(dāng)壓縮相同的原始圖片時(shí)芥永，結(jié)果也是一樣，iOS完勝钝吮。想要品質(zhì)接近埋涧，文件大小就會(huì)差出 5-10倍，而如果要壓縮出相同大小的文件奇瘦，Android的壓縮品質(zhì)簡(jiǎn)直就是慘不忍睹棘催。
結(jié)果說明，蘋果很清楚optimize_coding參數(shù)和哈弗曼表的意義耳标，這里需要特別指出醇坝，蘋果使用的哈弗曼表算法與libjpeg（及我們后來自行 采用的libjpeg-turbo）不同，像素級(jí)可以看出區(qū)別次坡，蘋果似乎基于libjpeg又進(jìn)行了進(jìn)一步的優(yōu)化呼猪，壓縮出來的圖片細(xì)節(jié)上更柔和、更平滑砸琅。
2.但是一談到Android上的圖片壓縮保存宋距，基本都會(huì)想到android.graphics.Bitmap這個(gè)類，它提供了一個(gè)非常方便（事實(shí)上也只有這一個(gè)）的方法：
public boolean compress (Bitmap.CompressFormat format, int quality, OutputStream stream)
public boolean compress(CompressFormat format, int quality, OutputStream stream) {
checkRecycled("Can't compress a recycled bitmap");
// do explicit check before calling the native method
if (stream == null) {
throw new NullPointerException();
}
if (quality < 0 || quality > 100) {
throw new IllegalArgumentException("quality must be 0..100");
}
Trace.traceBegin(Trace.TRACE_TAG_RESOURCES, "Bitmap.compress");
boolean result = nativeCompress(mFinalizer.mNativeBitmap, format.nativeInt,
quality, stream, new byte[WORKING_COMPRESS_STORAGE]);
Trace.traceEnd(Trace.TRACE_TAG_RESOURCES);
return result;
}
看來需要對(duì)libjpeg 進(jìn)行深層的研究
