关于Android图片资源瘦身的奇思妙想

版权声明：本文由况鹰原创文章，转载请注明出处:
文章原文链接：https://www.qcloud.com/community/article/77

分析大部分apk，可以发现在android中图片应用较多的主要包括jpg和png两种资源类型。对于颜色很多尺寸大的图片一般用jpg，主要适用场景是用于做背景展示，这类图片除了调整压缩参数做有损压缩外，无损压缩可优化的空间则一般不会太大。相对而言，png图片的应用场景更多，一方面是由于其拥有透明值，另一方面也因为其可以方便缩放（九宫格）。png这部分资源一般在apk中占用了比较大的体积，很多时候可以通过tinypng有损压缩减少颜色表来减少体积，但容易被像素眼的设计师挑战；另一种方案是无损压缩，常规方法包括转换为索引图片、改变编码方式、提升压缩级别等，相较而言体积小了但效果一样，本文也将就这一方面结合源码对其在Android的实践和问题进行阐述。

一.选择压缩工具

首先是选择压缩工具的问题,在这之前先看下系统是如何做的。android的aapt在编译阶段其实是会对png图片进行压缩的，用的则是libpng和zlib，这个可以用aapt的源码佐证：

用libpng对图片进行预处理
用zlib对预处理后的图片进行压缩生成新图片

可以看到aapt对图片的压缩等级使用了最高等级9，期间系统也会做颜色表转换，这样可以减少很大一部分图片的体积，但系统的压缩方案是不是完美无缺呢?目前常用的无损压缩大概有Pngrewrite、pngcrush、optipng、advancecom、pngout，参考了很多文章，得出的结果是pngout仍然是王者，毕竟是Ken神童（据说Doom and Quake的作者John都尊敬他，做游戏的肯定都知道John ）写的。另外由于pngout可以很好的支持命令行，方便放到编译脚本中自动化，所以暂时选它好了。

二.实践案例

压缩工具选好了，第二步便是实验了。拿手Q为例，直接对手Q中的所有png压一遍，Pngout的速度确实一般，对4千张图片全部处理一遍大概需要13分钟，不过这个过程只需要在本地做一遍，所以可以忍受，但处理完的结果不理想，因为没什么效果，减小量为十几KB~~ 仔细分析得知这里面犯浑作怪的竟然是aapt，由于先调pngout再调aapt会导致压缩效果覆盖。那么可不可以关闭aapt呢？查看aapt的参数，关于压缩相关的只有下面这两个参数：

其中crunch便是预处理资源了，但是没有关闭crunch的参数。。。。有点技穷了对不对。只能去源码中找灵感了，看aapt的源码：

google把它隐藏了，没有打印出来给用户~打开这个参数，在手Q中资源打包脚本处分别加入--no-crunch参数，便可以把系统压缩给屏蔽掉了，样式如下：

至于为什么设置了这个参数就可以屏蔽呢，其实源码调用过程如下：

第1步 (Main.cpp)

第2步 (Command.cpp)

第3步 (Resource.cpp)

终结： (Resource.cpp)

可是实验还没有结束，因为这样屏蔽掉会出现奇葩的景象，得到的手Q画面效果如下：

为什么呢？仔细分析发现九宫格图片被压出问题了，aapt在处理png图片时会判断是不是九宫格图片，如果是则做特殊预处理：

do_9patch其实主要的是九宫格信息弄出来，写入到info9Patch字段，并最终写入nptc的chunk中：

到这里又回到第一步为什么我说Ken是神童了，因为Pngout可以选择chunk进行压缩，所以解决方案便是：对于九宫格图片，我们单独拎出来，先用aapt的aapt crunch进行预处理得到npTc字段，再用pngout在压缩时调用"knptc"参数保护一下npTc块，这样便得到了正确的九宫格图片，安装包的效果图也就正常了。

三.总结

上面大概就是png无损压缩在android中应用的基本思路和遇到的问题，归纳为一句话便是：替换掉系统的压缩算法。如果你不嫌麻烦和喜欢折腾的话可以在你的apk使用一下，效果还是非常显著的。不改变安装包内图片像素内容，轻轻松松减少几百K体积，何乐而不为呢？