滴滴Booster 内置的资源压缩 task booster-task-compression实现了如下功能:
1.删除冗余资源,保留尺寸最大的图片
2.有损压缩图片资源,内置两种压缩方案:
1.pngquant 有损压缩(需要自行安装 pngquant 命令行工具)
2.cwebp 有损压缩(已内置)
3.修改资源索引文件resources.arsc、webp图片等的zipEntry method,置为DEFLATED,减少压缩包大小
运行demo的时候发现删除冗余资源的时候,console提示删除图片失败,如下图:
win7系统 booster_version = '0.8.0' ,该问题已提issue#19
Booster对资源索引文件resources.arsc的压缩,只是单一设置ZipEntry.method,这是否运行时性能有影响,有大佬 这样讨论过: resources.arsc压缩会影响性能吗? 、 Google I/O 2016 笔记:APK 瘦身的正确姿势,尚未定论。
针对resources.arsc的优化,美团还提出如下手段:
1.开启资源混淆
2.对重复的资源优化
3.无用资源优化
对重复的资源优化和对被shrinkResources优化掉的资源进行处理的原理见:美团博客 Android App包瘦身优化实践
这里根据美团讲述的原理在Booster定制task实现对重复的资源优化和对无用资源优化,详见工程module TaskCompression。
一、对重复的资源优化
重复资源的筛选条件为 资源的zipEntry.crc相等,最先出现的资源压缩包产物ap_文件是在processResTask中,尽可能早的删除重复资源, 可以减少后续task的执行时间,hook在processResTask之后,如下:
variant.processResTask?.doLast{
variant.removeRepeatResources(it.logger,results)
}
这里我按照同zipEntry.crc和同资源目录(不同资源目录可能有相同的crc资源,造成误删,不过可能性较小)去分类收集重复资源:
private fun File.findDuplicatedResources():Map<Key,ArrayList<DuplicatedOrUnusedEntry>>{
var duplicatedResources = HashMap<Key,ArrayList<DuplicatedOrUnusedEntry>>(100)
ZipFile(this).use { zip ->
zip.entries().asSequence().forEach { entry ->
val lastIndex : Int = entry.name.lastIndexOf('/')
val key = Key(entry.crc.toString(),if(lastIndex == -1) "/" else entry.name.substring(0,lastIndex))
if(!duplicatedResources.containsKey(key)){
val list : ArrayList<DuplicatedOrUnusedEntry> = ArrayList(20)
duplicatedResources[key] = list
}
val list = duplicatedResources[key]
list?.add(DuplicatedOrUnusedEntry(entry.name,entry.size,entry.compressedSize,DuplicatedOrUnusedEntryType.duplicated))
}
}
duplicatedResources.filter {
it.value.size >= 2
}.apply{
duplicatedResources = this as HashMap<Key, ArrayList<DuplicatedOrUnusedEntry>>
}
return duplicatedResources
}
重复的资源优化的实现整体思路:
1.从ap_文件中解压出resources.arsc条目,并收集该条目的ZipEntry.method,为后续按照同ZipEntry.method 把改动后的resources.arsc添加到ap_文件中
2.收集重复资源
3.根据收集的重复资源,保留重复资源的第一个,从删除ap_文件中删除其他重复资源的zipEntry
4.使用通过[android-chunk-utils]修改resources.arsc全局StringChunk,把这些重复的资源都重定向到没有被删除的第一个资源
5.按照同ZipEntry.method把改动后的resources.arsc添加到ap_文件中
验证: 分别在App/lib module显示三张图片,重复资源如下:
查看没集成重复的资源优化的apk,如图:
使用工具查看集成重复的资源优化的apk,如图: text
集成重复的资源优化打包,控制和输出报告都可以看到如下输出:
可以知道删除哪些重复资源,压缩包减少了多少kb。
二、无用资源优化
通过shrinkResources true来开启资源压缩,资源压缩工具会把无用的资源替换成预定义的版本而不是移除, 那么google出于什么原因这样做了? ResourceUsageAnalyzer 注释是这样说的的:
/**
* Whether we should create small/empty dummy files instead of actually
* removing file resources. This is to work around crashes on some devices
* where the device is traversing resources. See http://b.android.com/79325 for more.
*/
注释上说了适配解决某些设备crash问题,查看issue,发现发生crash的设备基本上都是三星手机,如果删除无用资源,需要考虑该issue问题。
如果采用人工移除的方式会带来后期的维护成本,在Android构建工具执行package${flavorName}Task之前通过修改 Compiled Resources来实现自动去除无用资源。
具体流程如下: * 收集资源包(Compiled Resources的简称)中被替换的预定义版本的资源名称,通过查看资源包 (Zip格式)中每个ZipEntry的CRC-32 checksum来寻找被替换的预定义资源,预定义资源的CRC-32定义在 ResourceUsageAnalyzer, 下面是它们的定义:
// A 1x1 pixel PNG of type BufferedImage.TYPE_BYTE_GRAY
public static final long TINY_PNG_CRC = 0x88b2a3b0L;
// A 3x3 pixel PNG of type BufferedImage.TYPE_INT_ARGB with 9-patch markers
public static final long TINY_9PNG_CRC = 0x1148f987L;
// The XML document <x/> as binary-packed with AAPT
public static final long TINY_XML_CRC = 0xd7e65643L;
// The XML document <x/> as a proto packed with AAPT2
public static final long TINY_PROTO_XML_CRC = 3204905971L;
从定义中没有看到webp、jpg、jpeg相关的crc,那么这些没有定义crc-32的资源在ZipEntry中crc为多少了,用预定义资源替换未使用的地方的实现如下:
private void replaceWithDummyEntry(JarOutputStream zos, ZipEntry entry, String name)throws IOException {
// Create a new entry so that the compressed len is recomputed.
byte[] bytes;
long crc;
if (name.endsWith(DOT_9PNG)) {
bytes = TINY_9PNG;
crc = TINY_9PNG_CRC;
} else if (name.endsWith(DOT_PNG)) {
bytes = TINY_PNG;
crc = TINY_PNG_CRC;
} else if (name.endsWith(DOT_XML)) {
switch (format) {
case BINARY:
bytes = TINY_BINARY_XML;
crc = TINY_BINARY_XML_CRC;
break;
case PROTO:
bytes = TINY_PROTO_XML;
crc = TINY_PROTO_XML_CRC;
break;
default:
throw new IllegalStateException("");
}
} else {
//没有预定资源格式,crc =0,数据为空
bytes = new byte[0];
crc = 0L;
}
JarEntry outEntry = new JarEntry(name);
if (entry.getTime() != -1L) {
outEntry.setTime(entry.getTime());
}
if (entry.getMethod() == JarEntry.STORED) {
outEntry.setMethod(JarEntry.STORED);
outEntry.setSize(bytes.length);
outEntry.setCrc(crc);
}
zos.putNextEntry(outEntry);
zos.write(bytes);
zos.closeEntry();
...
}
可以得出筛选无使用资源的条件为crc in如下集合中:
val unusedResourceCrcs = longArrayOf(
ResourceUsageAnalyzer.TINY_PNG_CRC,
ResourceUsageAnalyzer.TINY_9PNG_CRC,
ResourceUsageAnalyzer.TINY_BINARY_XML_CRC,
ResourceUsageAnalyzer.TINY_PROTO_XML_CRC,
0 //jpg、jpeg、webp等
)
如果集成了
打印packageAndroidTask的inputFiles,如下:
分别查看箭头目录下的文件,有*.ap_文件,
而从上面两图中可以了解到shrinkResources 影响到packageAndroidTask的inputFiles,没有开启shrinkResources, packageAndroidTask从processedResTask产物中读取ap_文件,开启shrinkResources,从res_stripped目录下读取ap_文件, 根据其stripped名,也猜测出ap_文件中已经进行了预定资源替换未使用资源了,可以压缩软件查看未使用资源的zipEntry.crc 进行验证,如下图:
可以看到没有使用的webp、jpg资源的ZipEntry.crc为0;如果集成了Booster内置的booster-task-compression, 会把png格式转换成webp格式,没使用的png最后的crc会变为0.
删除无用资源方案想到两种:
方案一:删除所有无用资源文件,以及删除资源索引文件resources.arsc中global StringChunk有关无用资源的数据项。
缺点:删除了global StringChunk中的数据项,改变了后续数据项的索引值,好比删除List中的元素,后续的元素索引值减一一样,牵一发动全身,需要同步其他chunk索引到global StringChunk数据项的索引值。否则会出现资源显示混乱,甚至crash;同时需要考虑上述issue问题。对resources.arsc越大出现问题的概率越大
方案二:无用资源根据crc分类,再按照重复资源优化,没有删除global StringChunk数据项,没有改变数据项的索引值,不需要改动其他chunk,同时不会出现上述issue问题。
下面对方案二具体实现,方案一就不做讨论了。
无用资源优化的代码实现整体思路:
1.从ap_文件中解压出resources.arsc条目,并收集该条目的ZipEntry.method,为后续按照同ZipEntry.method 把改动后的resources.arsc添加到ap_文件中
2.收集无用资源
3.把收集的无用资源根据crc进行分类,在按照重复资源优化处理
集成无用资源优化打包,控制和输出报告都可以看到如下输出:
可以知道删除哪些无用资源,压缩包减少了多少kb,无用资源优化减少的size没多少。
以上重复资源优化和无用资源优化,没有经过大量设备测试,仅供参考学习。
推荐阅读:
关注公众号:
