经常看到有人问：“安卓版微信发出去的图片怎么那么渣！比 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 还有性能上的好处，这里就不再赘述了）
最后，附上我们团队在 github 上的开源项目地址，供参考：https://github.com/bither