常常看到有人問:「安卓版微信發出去的圖片怎麼那麼渣!比iPhone的差遠了!」。不僅是微信,不少應用安卓版的圖片質量就是要比iPhone版遜色不少,這究竟是怎麼回事? 咱們團隊最初也糾結過這個問題,費了半天勁、繞了好大圈,直到最後才發現,原來這是谷歌犯得一個「小」錯誤,並且一直錯到了今天。 谷歌的錯就在於:libjpeg。 libjpeg是普遍使用的開源JPEG圖像庫(參考 http://en.wikipedia.org/wiki/Libjpeg ),安卓也依賴libjpeg來壓縮圖片。經過查看源碼,咱們會發現安卓並非直接封裝的libjpeg,而是基於了另外一個叫Skia的開源項目 (http://en.wikipedia.org/wiki/Skia_Graphics_Engine)來做爲的圖像處理引擎。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又進行了進一步的優化,壓縮出來的圖片細節上更柔和、更平滑。 以上試驗,咱們嘗試過多個原圖、多種壓縮比例,試驗結果均相似,若有興趣,您不妨也自行進行嘗試。