編輯:關於Android編程
經常看到有人問:“安卓版微信發出去的圖片怎麼那麼渣!比 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 又進行了進一步的優化,壓縮出來的圖片細節上更柔和、更平滑。
以上試驗,我們嘗試過多個原圖、多種壓縮比例,試驗結果均類似,如有興趣,您不妨也自行進行嘗試。
最終我們決定,不再使用安卓系統原生的 JPEG 壓縮方法,而是基於 libjpeg-turbo 自行編譯了一版 native 的安卓庫,專門用來壓縮圖片,這樣在我們的產品中,就做到了僅僅用1/5 的圖片大小,就能讓用戶得到不遜色甚至更優的圖片品質,對於我們團隊來說,費了半天勁、繞了好大圈是非常值得的。(使用 libjpeg-turbo 還有性能上的好處,這裡就不再贅述了)
之前的文章一直在介紹OC,最近也是在找急忙慌的學習IOS,所以Android方面的知識分享就有點中斷了,但是我現在還是要靠Android吃飯,所以不能Android的工作
Toolbar在前面的博文《Android開發筆記(二十)頂部導航欄》中,我們學習了ActionBar的用法,可是ActionBar著實是不怎麼好用,比如文字風格不能定制
Java源文件通過Java編譯器生成CLASS文件,再通過dx工具轉換為classes.dex文件。DEX文件從整體上來看是一個索引的結構,類名、方法名、字段名等信息都存
本文實例講述了android通過Location API顯示地址信息的實現方法。分享給大家供大家參考。具體如下:android的Locatin API,可以通過Geoco