在公司遇到了對圖片壓縮儲存的問題，發現這個問題還挺深，而且網上資料比較有限大多數的都是BitmapFactory的操作，而且在使用bitmap中 容易出現OOM，因此自己深入研究了一下，在此記錄: ##自己也有兩個問題： 1.為何Android圖片壓縮效率比IOS的底而且質量差？ 2.Android系統是如何編碼壓縮儲存圖片的？
解答
- 為什麼Android的圖片壓縮質量要比iPhone的壓縮質量差很多，這是因為Android底層犯的一個小錯誤：libjpeg。並且這個錯誤一直持續到了今天。libjpeg是廣泛使用的開源JPEG影象庫（參考 en.wikipedia.org/wiki/Libjpe… ），安卓也依賴libjpeg來壓縮圖片。通過檢視原始碼，我們會發現安卓並不是直接封裝的libjpeg，而是基於了另一個叫Skia的開源專案（en.wikipedia.org/wiki/Skia_G…）來作為的影象處理引擎。Skia是谷歌自己維 護著的一個大而全的引擎，各種影象處理功能均在其中予以實現，並且廣泛的應用於谷歌自己和其它公司的產品中（如：Chrome、Firefox、 Android等）。Skia對libjpeg進行了良好的封裝，基於這個引擎可以很方便為作業系統、瀏覽器等開發影象處理功能。 libjpeg在壓縮影象時，有一個引數叫optimize_coding，關於這個引數，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.
這段話大概的意思就是如果設定optimize_coding為TRUE，將會使得壓縮影象過程中基於影象資料計算哈弗曼表（關於圖片壓縮中的哈弗曼表，請自行查閱相關資料），由於這個計算會顯著消耗空間和時間，預設值被設定為FALSE。 這段解釋乍看起來沒有任何問題，libjpeg的程式碼也經受了十多年的考驗，健壯而高效。但很多人忽略了這一點，那就是，這段解釋是十多年前寫的，對於當 時的計算裝置來說，空間和時間的消耗可能是顯著的，但到今天，這似乎不應再是問題，相反，我們應該更多的考慮圖片的品質（越來越好的顯示技術）和圖片的大 小（越來越依賴於雲服務）。 谷歌的Skia專案工程師們最終沒有設定這個引數，optimize_coding在Skia中預設的等於了FALSE，這就意味著更差的圖片質量和更大的圖片檔案，而壓縮圖片過程中所耗費的時間和空間其實反而是可以忽略不計的。那麼，這個引數的影響究竟會有多大呢？ 經我們實測，使用相同的原始圖片，分別設定optimize_coding=TRUE和FALSE進行壓縮，想達到接近的圖片質量（用Photoshop 放大到畫素級逐塊對比），FALSE時的圖片大小大約是TRUE時的5-10倍。換句話說，如果我們想在FALSE和TRUE時壓縮成相同大小的JPEG 圖片，FALSE的品質將大大遜色於TRUE的（雖然品質很難量化，但我們不妨說成是差5-10倍）。 我們又對Android和iOS進行了對比（均使用標準的JPEG壓縮方法），兩個系統都沒有提供設定optimize_coding的介面（通過閱讀源 碼，我們已經知道Android是FALSE，iOS不詳），當壓縮相同的原始圖片時，結果也是一樣，iOS完勝。想要品質接近，檔案大小就會差出 5-10倍，而如果要壓縮出相同大小的檔案，Android的壓縮品質簡直就是慘不忍睹。 結果說明，蘋果很清楚optimize_coding引數和哈弗曼表的意義，這裡需要特別指出，蘋果使用的哈弗曼表演算法與libjpeg（及我們後來自行 採用的libjpeg-turbo）不同，畫素級可以看出區別，蘋果似乎基於libjpeg又進行了進一步的優化，壓縮出來的圖片細節上更柔和、更平滑。 2.但是一談到Android上的圖片壓縮儲存，基本都會想到android.graphics.Bitmap這個類，它提供了一個非常方便（事實上也只有這一個）的方法： 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; } 看來需要對libjpeg 進行深層的研究