今天小編就爲大家分享一篇關於安卓圖片反覆壓縮後爲什麼普遍會變綠而不是其它顏色？，小編覺得內容挺不錯的，現在分享給大家，具有很好的參考價值，需要的朋友一起跟隨小編來看看吧
業餘版概要：
安卓的一個核心的部分的代碼，爲了優化執行速度進行了魔改，結果寫錯了代碼。結果導致 JPG 圖片壓縮發綠、崩壞。與安卓上的應用無關，它們是受害者
專業版概要：
問題出在 Android 提供的壓縮圖片接口上，準確的說是一個 Android 裏一個叫做 Skia 的庫上。而這個 bug 在 2016 年 4 月中旬被修復了，如果按照 Android 的發行來看，那就是從 Android 7 (Nougat) 開始才消除這個問題。
問題出在 RGB 色彩空間轉換到 YUV 的時候。但問題不僅僅是精度下降，最大的問題是，錯誤的舍入（向下取整）。
現在就要說到 Android 系統到底爲什麼出了這個問題了。Android 系統自起誕生以來就引入了名爲 Skia 的圖像庫（Google 自家產品），用於處理圖像，其中包括把圖片壓縮成 JPEG（平時說的 JPG）。而 Skia 又是調用libjpeg-turbo 來實現真正的壓縮過程的。爲了達到更好的壓縮效果，JPEG 算法本身，將通常屏幕上表示顏色的 RGB（紅綠藍）數值，轉換爲 YUV 數值（亮度，藍色分量，紅色分量）。正常情況下這個算法是輕微有損的。
但是 Skia 不走尋常路，在將這個變換算法的各個常數複製到自己的代碼裏的時候（當然是合法地），降低了精度，以達到更高的速度（專業準確地說，從 16 位定點數，降低到了 8 位定點數），這導致了更大的損傷。
最可怕的是……在進行這個變換運算的最後一步，需要除以 256，而代碼中，採用了右移操作代替除法以提高執行速度。
假如我們是 Skia 開發者，如何修復這個問題？
交回給 libjpeg-turbo 庫自己來做色彩空間變換，把原本 Skia 庫 YUV 轉換代碼全部刪掉了，把這個過程留給整個過程最底層的 libjpeg-turbo庫自己來做，並且用默認的 JDCT_ISLOW 方法代替JDCT_IFAST 方法。
總結
以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作具有一定的參考學習價值，謝謝大家對神馬文庫的支持。如果你想了解更多相關內容請查看下面相關鏈接