随着版本的迭代，业务的增加，QQ音乐apk的大小已经超过25M，其中res目录占用的大小超过5.5M，所以提出了对安装包进行瘦身的技术需求。业务的增加导致图片越来越多，通过分析可以知道PNG格式图片是项目中数量最多的图片，关于PNG图片的介绍可以参考：PNG文件格式详解。为了实现减包任务，对图片进行压缩是很重要的一部分。
为了实现PNG图片的压缩，之前的处理方式是先在本地进行压缩，然后提交到SVN，再打包发布。一般采用在线压缩工具处理，将res目录下的PNG图片批量手动处理，这种方式容易出现的问题是：
1) 为了追求高的压缩率，容易出现一张图片重复压缩的情况，导致图片严重失真；
2) 不能自定义参数开发，无法满足开发需求；
3) 压缩效率比较低，每次发布时都需要人为进行一次图片的压缩。
1）结合Vector_quantization算法生成高质量的色彩范围；
2）独特的自适应抖动算法，比标准的FloydSteinberg算法具有更强的抗噪性；
3）易与集成，提供了shell脚本，图形化界面，服务端库，PS插件；
4）具有快速模式，用于处理大批图片。源码库地址为pngquant。
1）John Wong的PNG图片极限压缩，介绍了ImageAlpha和ImageOptim两种压缩方法；
2）图片优化的那些工具，介绍了pngcrush、optipng、pngout、pngnq等。
各压缩工具的对比表格如下：
根据资料显示，tinypng、pngquant、ImageAlpha、pngnq都是有损压缩，基本采用的都是quantization算法，将24位的PNG图片转换为8位的PNG图片，减少图片的颜色数；pngcrush、optipng、pngout、adV**g都是无损压缩，采用的都是基于LZ/Huffman的DEFLATE算法，减少图片IDAT chunk区域的数据。一般有损压缩的压缩率会大大高于无损压缩。
从表格中可以知道，tinypng的压缩率大概比pngquant的压缩率会高10%左右。其中pngquant压缩过程会出现比原来图片大的情况，所以在实际利用脚本压缩过程中需要对压缩后的图片和原来图片大小进行对比，如果出现变大的情况应该舍弃。
由于项目中存在大量的PNG格式图片，所以不可能单个单个进行压缩，需要通过批量压缩来进行，tinypng的批量压缩目前只能是在官网进行(由于在线API的开发会有图片数量受限以及开发网环境受限等)，而pngquant的批量压缩可以通过自己完全自定义开发，调用压缩脚本进行压缩，在官网上可以下载windows和linux版本下的运行文件。
选取项目中大小4KB以上的106个PNG图片进行压缩实现，效果对比如下：(pngquant使用默认压缩品质)
从表格中可以知道，tinypng工具由于是采用网站在线压缩的方式，所以批量上传过程中容易出现上传不成功等错误，而pngquant采用的是本地脚本压缩，所以这个问题可以有效避免。由于tinypng采用了多种压缩算法，压缩效果会好于pngquant，大概可以多压缩12%左右，不过由于是有损压缩，所以在追求尽可能增加压缩比率的同时也应该考虑压缩后图片的显示效果。
使用pngquant脚本压缩资源目录res下的drawable、drawable-hdpi、drawable-ldpi、drawable-mdpi、drawable-xhdpi、drawable-xhdpi-v21、drawable-xxhdpi、drawable-xxxhpi等8个文件夹，在多线程的情况下，共耗时17s940ms。主线48322版本的资源目录采用各种压缩品质(通过设置—quality参数实现)进行压缩，对比效果如下图，综合考虑压缩率和压缩后效果，最终采用品质为90的压缩方案，可以减包1.97MB。
4.结论
在综合比较tinypng和pngquant的基础上，项目最终考虑使用pngquant来对PNG图片进行批量压缩，主要考虑有：
1）虽然在pngquant采用默认压缩品质的情况下压缩率会低于tinypng，但是tinypng是在线压缩工具，不好自定义控制与维护，tinypng压缩后的显示效果还有待进一步验证；
2）同时，pngquant脚本可以自定义压缩品质，采用压缩品质更低(比如90)的情况下，压缩率会高于tinypng，而且pngquant是开源的，容易维护，风险可控。
如果要做成gradle自动化编译，除了在gradle中加入上面代码外，还需要使用下面语句做成任务依赖，需要在编译apk之前执行压缩任务：
并且同时关闭Android编译工具AAPT自带的压缩效果：
自动化编译过程压缩脚本运行的流程为：
从压缩流程图中可以知道，在项目资源目录下PNG图片数据过多时，默认应该采用多线程执行压缩脚本，为了避免出现重复压缩的情况，在进行压缩之前需要读取图片的压缩信息，压缩过的不再压缩，同时，压缩完成后，需要对压缩处理过的图片写入压缩信息，方便下一次读取。由于pngquant脚本的特殊性，需要判断压缩后文件是否大于原始文件，大于则需要删除并记录。
使用pngquant自动压缩的优势主要有三点：
1）选择pngquant做为png图片压缩脚本，可以在不影响图片显示效果的基础上最大化压缩(采用压缩品质90)；
2）同时通过groovy脚本对图片进行批量压缩处理与加入额外压缩信息，可以提高压缩效率并防止重复压缩；
3）做成RDM自动化压缩后，可以有效减少开发人员的工作量，方便后期维护。
选取工程res目录下的49个JPG文件进行压缩对比，可以减少0.23MB，效果如下：
部分jar包PNG图片压缩减少的大小对比：
本次工程图片压缩过程，主要学习了PNG图片的主要压缩脚本(tinypng/pngquant/pngout)以及JPG图片的压缩工具(优图/tinyjpg)，经过对比最终选择pngquant与优图作为工程PNG和JPG图片的压缩工具。为了实现PNG图片压缩的自动化管理，将pngquant脚本集成到RDM编译，主要遇到的问题有：
1）groovy脚本执行Linux命令，Linux环境下运行bin文件，需要首先使用chmod赋予权限；
2）gradle的编译顺序问题，根据编译过程的依赖链关系，需要将compressImages任务放到最开始；
3）pngquant的运行需要依赖一些so库，所以需要通过重设“LD_LIBRARY_PATH”来定向加载so库，同时，通过ln命令来设置so库的软连接关系；
4）路径识别问题，一开始总是无法找到图片路径，后面发现是在压缩脚本路径引用的时候多加了双引号(“”)，导致在RDM平台无法识别；
5）RDM自动化编译时间增加的问题，由于res目录下的JPG图片和第三方jar包的PNG图片都是本地手动压缩处理的，不用考虑时间问题。res目录下的PNG图片是在RDM平台自动压缩处理的，要考虑时间成本，如下图所示，加上压缩脚本，大概会多耗时26秒左右。
通过本次图片压缩优化，可以达到以下几个目的：
1）res目录下的PNG可以减少1.97MB，PNG的减包效果如下图，res目录下的JPG图片可以减少200KB，第三方jar包(assets)目录的PNG图片大小可以减少40KB。总共可以减包2.22MB；
PNG压缩前：
PNG压缩后：
2）实现PNG图片自动化压缩处理，大大提高了开发效率，方便维护管理；
3）通过groovy脚本可以实现自定义压缩品质与写入压缩信息，有效控制压缩率和智能判断，避免二次压缩的出现。