滴滴Booster移动APP质量优化框架 学习之旅 二
推荐阅读：
续写滴滴Booster移动APP质量优化框架学习之旅，上篇文章分析内置的transform：booster-transform-shrink booster-transform-shared-preferences，今天分析booster-task-compression以及定制task对资源索引文件resource.asrc进行优化（重复资源优化、无用资源优化）。
booster-task-compression
该task对针对资源的压缩和删除，减少了apk包的大小。原理主要对资源编译打包过程进行了hook干涉,添加了三个Task:
removeRedundantResources、compressAssets、compressResources,其先相关task依赖关系图谱如下：
且在processResources任务 doTask阶段进行compressProcessedRes。
这四个动作作用依次如下：
①：removeRedundantResources 删除多余图片，保留最大尺寸
②：compressResources 对可编译资源目录res下的图片进行压缩
③：compressAssets 对不可编译资源asserts目录下的图片进行压缩
④：compressProcessedRes 对resource*._ap进行压缩
执行顺序：① > ② > ④，③ > ④ 动作②和③无相关，动作④在动作②和③都完成后才执行。
①：removeRedundantResources
AndroidStudio3.0以后是默认开启aapt2,Booster对没有开启aapt2的情况没有进行冗余图片的操作。在aapt2的模式下，mergeResource Task的产物是一些.flat文件，如下图：
removeRedundantResources 主要的逻辑代码实现如下：
override fun run() {
//搜索满足AAPT2 container format ：
//magic = 0x54504141 && version > 0 && count > 0 && type = RES_FILE val resources = sources().parallelStream().map { it to it.metadata }.collect(Collectors.toSet()) resources.filter {
//过滤情况 ResourcesInternal.CompileFile = null的情况 it.second != null }.groupBy({
//根据资源名分组 it.second!!.resourceName.substringBeforeLast('/') }, { it.first to it.second }).forEach { entry -> //根据资源名分组
entry.value.groupBy({ it.second!!.resourceName.substringAfterLast('/') }, { it.first to it.second!! }).map { group -> //组内根据density降序排序，再排除最高density的资源
group.value.sortedByDescending { it.second.config.density }.takeLast(group.value.size - 1) }.flatten().parallelStream().forEach { try {
//对除最高density的其他density资源文件进行删除 if (it.first.delete()) { val original = File(it.second.sourcePath) results.add(CompressionResult(it.first, original.length(), 0, original)) } else { logger.error("Cannot delete file `${it.first}`") } } catch (e: IOException) { logger.error("Cannot delete file `${it.first}`", e) } } } } }
该task的逻辑为搜索满足条件magic = 0x54504141 && version > 0 && count > 0 && type = RES_FILE的资源文件，根据资源名分组，组内根据config.density排序，排除掉最高的density的资源，其他density的资源文件都删除。
也许有些同学对AAPT2 Container format不熟悉，见 APPT2源码文档 便知悉该Task的搜索过滤条件了，从文档介绍，RES_FILE类型可以是PNG file, binary XML, PNG file, binary XML, or aapt.pb.XmlNode，那是不是搜索过滤条件最好加上后缀为png.flat，以免造成误删。
集成该task，进行打包，console打印文件删除失败log，如下图：
猜测跟文件流操作有关系，前面读取.flat文件元数据信息(magic、count、type等)，已在github提了issue39。
②：compressResources
有损压缩图片资源，内置两种压缩方案：
1.pngquant 有损压缩（需要自行安装 pngquant 命令行工具）
2.cwebp 有损压缩（已内置）
在构建过程中，Booster会根据配置智能选择合适的压缩器Compressor
/** * Select the best compressor */ fun get(project: Project): CompressionTool? { val pngquant = project.findProperty(PROPERTY_PNGQUANT)?.toString() val compressor = project.findProperty(PROPERTY_COMPRESSOR)?.toString() val binDir = project.buildDir.file(SdkConstants.FD_OUTPUT).absolutePath val minSdkVersion = project.getAndroid<BaseExtension>().defaultConfig.minSdkVersion.apiLevel project.logger.info("minSdkVersion: $minSdkVersion$") project.logger.info("$PROPERTY_COMPRESSOR: $compressor") project.logger.info("$PROPERTY_PNGQUANT: $pngquant") return when (compressor) { Cwebp.PROGRAM -> Cwebp(binDir) Pngquant.PROGRAM -> Pngquant(pngquant) else -> when { minSdkVersion >= 18 -> Cwebp(binDir) minSdkVersion in 15..17 -> Cwebp(binDir, true) else -> Pngquant(pngquant).let { if (it.isInstalled) it else null } } } }
配置了可识别的Compressor，就使用该Compressor，否则根据minSdkVersion选择合适的Compressor，Compressor再根据是否开启aapt2创建合适的CompressImage任务
//Cweb override fun newCompressionTaskCreator() = SimpleCompressionTaskCreator(this) { aapt2 -> when (aapt2) { true -> when (opaque) { true -> CwebpCompressOpaqueFlatImages::class else -> CwebpCompressFlatImages::class } else -> when (opaque) { true -> CwebpCompressOpaqueImages::class else -> CwebpCompressImages::class } } } //pngquant override fun newCompressionTaskCreator() = SimpleCompressionTaskCreator(this) { aapt2 -> if (aapt2) PngquantCompressFlatImages::class else PngquantCompressImages::class }
当开启aapt2时，aapt2的compile阶段的产物为.flat文件，使用Cweb / pngquant 压缩原图片后，还需要通过aapt2编译压缩生成后的图片，生成对应的.flat文件
//PngquantCompressFlatImages override fun run() { ... sources().parallelStream().map { it to it.metadata }.filter { it.second != null }.map { val output = compressedRes.file("${it.second!!.resourcePath.substringBeforeLast('.')}$DOT_PNG") Aapt2ActionData(it.first, it.second!!, output, listOf(pngquant, "--strip", "--skip-if-larger", "-f", "-o", output.absolutePath, "-s", "1", it.second!!.sourcePath), listOf(aapt2, "compile", "-o", it.first.parent, output.absolutePath)) }.forEach { it.output.parentFile.mkdirs() val s0 = File(it.metadata.sourcePath).length() val rc = project.exec { spec -> spec.isIgnoreExitValue = true spec.commandLine = it.cmdline } ... } }
//CwebpCompressFlatImages
override fun compress(filter: (File) -> Boolean) {
...
sources().parallelStream().map {
it to it.metadata
}.filter {
//在android15 - 17 还不支持透明的webp，过滤掉应用图标
it.second != null && isNotLauncherIcon(it.first, it.second!!) && filter(File(it.second!!.sourcePath))
}.map {
val output = compressedRes.file("${it.second!!.resourcePath.substringBeforeLast('.')}.webp")
Aapt2ActionData(it.first, it.second!!, output,
listOf(cwebp, "-mt", "-quiet", "-q", "80", it.second!!.sourcePath, "-o", output.absolutePath),
listOf(aapt2, "compile", "-o", it.first.parent, output.absolutePath))
}.forEach {
it.output.parentFile.mkdirs()
val s0 = File(it.metadata.sourcePath).length()
//cwep压缩
val rc = project.exec { spec ->
spec.isIgnoreExitValue = true
spec.commandLine = it.cmdline
}
when (rc.exitValue) {
0 -> {
val s1 = it.output.length()
if (s1 > s0) {
//cwebp压缩后的产物文件大小比原图片还大，则使用原图
results.add(CompressionResult(it.input, s0, s0, File(it.metadata.sourcePath),Compression))
it.output.delete()
} else {
...
}
}
...
}
}
}
③：compressAssets
对不可编译资源资源的压缩，跟动作②compressResources共用相同的compressor，选择没开启的aapt2的CompressImage任务处理。
④：compressProcessedRes
processResources任务完成生成的的产物：resources*.ap_，路径如下图：
resources*.ap_是个压缩文件，resources*.ap_中zip条目归档到apk中，通过 aapt l -v xxx.apk > log.txt 查看APK文件归档类信息 ，可以看到APK中很多资源是以Stored来存储的()，，根据Zip的文件格式中对压缩方式的描述Compression_methods可以看出这些文件是没有压缩的，那为什么它们没有被压缩呢？从AAPT的源码分别从aapt和aapt2中找到以下描述：
/********************aapt Package.cpp****************************/
/* these formats are already compressed, or don't compress well */ static const char* kNoCompressExt[] = { ".jpg", ".jpeg", ".png", ".gif", ".wav", ".mp2", ".mp3", ".ogg", ".aac", ".mpg", ".mpeg", ".mid", ".midi", ".smf", ".jet", ".rtttl", ".imy", ".xmf", ".mp4", ".m4a", ".m4v", ".3gp", ".3gpp", ".3g2", ".3gpp2", ".amr", ".awb", ".wma", ".wmv", ".webm", ".mkv" };
/********************aapt2 Link.cpp****************************/
// Populate some default no-compress extensions that are already compressed.
options.extensions_to_not_compress.insert(
{".jpg", ".jpeg", ".png", ".gif", ".wav", ".mp2", ".mp3", ".ogg",
".aac", ".mpg", ".mpeg", ".mid", ".midi", ".smf", ".jet", ".rtttl",
".imy", ".xmf", ".mp4", ".m4a", ".m4v", ".3gp", ".3gpp", ".3g2",
".3gpp2", ".amr", ".awb", ".wma", ".wmv", ".webm", ".mkv"});
从描述中都没有找到webp格式，是不是webp图片可以以Deflate来存储在apk？那么看Booster做了什么？
compressProcessedRes逻辑关键代码如下：
//同aapt源码的no-compress格式同出一辙
private val NO_COMPRESS = setOf(
"jpg", "jpeg", "png", "gif",
"wav", "mp2", "mp3", "ogg", "aac",
"mpg", "mpeg", "mid", "midi", "smf", "jet",
"rtttl", "imy", "xmf", "mp4", "m4a",
"m4v", "3gp", "3gpp", "3g2", "3gpp2",
"amr", "awb", "wma", "wmv", "webm", "mkv"
)
private fun BaseVariant.compressProcessedRes(results: CompressionResults) {
//搜索resources-*.ap_文件 val files = scope.processedRes.search { it.name.startsWith(SdkConstants.FN_RES_BASE) && it.extension == SdkConstants.EXT_RES } files.parallelStream().forEach { ap_ -> val s0 = ap_.length() ap_.repack {
//过滤掉 不压缩存储的图片格式 !NO_COMPRESS.contains(it.name.substringAfterLast('.')) } val s1 = ap_.length() results.add(CompressionResult(ap_, s0, s1, ap_)) } } private fun File.repack(shouldCompress: (ZipEntry) -> Boolean) { val dest = File.createTempFile(SdkConstants.FN_RES_BASE + SdkConstants.RES_QUALIFIER_SEP, SdkConstants.DOT_RES) ZipOutputStream(dest.outputStream()).use { output -> ZipFile(this).use { zip -> zip.entries().asSequence().forEach { origin -> val target = ZipEntry(origin.name).apply { size = origin.size crc = origin.crc comment = origin.comment extra = origin.extra
//不压缩的格式，保持原有的ZipEntry.method,显然webp格式的图片的method method = if (shouldCompress(origin)) ZipEntry.DEFLATED else origin.method } output.putNextEntry(target) zip.getInputStream(origin).use { it.copyTo(output) } output.closeEntry() } } } if (this.delete()) { if (!dest.renameTo(this)) { dest.copyTo(this, true) } } }
其逻辑为搜索resources*.ap_，保存NO_COMPRESS格式的条目method,其他格式的ZipEntry method修改为deflated，显然resources*.ap_文件中webp图片和resources.arsc资源索引文件的method改为了deflated，做了压缩存储，可以aapt命令查看经Booster compression处理的apk zip条目信息进行验证。
对于resources.arsc的压缩是否对apk运行时性能有影响，大佬们也有这样的讨论，见 resources.arsc压缩会影响性能吗？ 、Google I/O 2016 笔记：APK 瘦身的正确姿势，尚未定论。
针对resources.arsc的优化，美团还提出如下手段：
1.开启资源混淆
2.对重复的资源优化
3.对被shrinkResources优化掉的资源进行处理
对重复的资源优化和对被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,把把这些重复的资源都重定向到没有被删除的第一个资源
5.按照同ZipEntry.method把改动后的resources.arsc添加到ap_文件中
验证： 分别在App/lib module显示三张图片，重复资源如下：
查看没集成重复的资源优化的apk，如图：
使用工具查看集成重复的资源优化的apk，如图：
集成重复的资源优化打包，控制和输出报告都可以看到如下输出：
可以知道删除哪些重复资源，压缩包减少了多少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进行分类，在按照重复资源优化处理
源码见:doRemoveUnusedResources1方法
集成无用资源优化打包，控制和输出报告都可以看到如下输出：
可以知道删除哪些无用资源，压缩包减少了多少kb，无用资源优化减少的size并没有多少。
以上重复资源优化和无用资源优化，没有经过大量设备测试，仅供参考，源码传送门：Boosterstudy
参考阅读：
如果您对博主的更新内容持续感兴趣，请关注公众号！
