滴滴Booster移动APP质量优化框架 学习之旅 二

时间:2019-06-12
本文章向大家介绍滴滴Booster移动APP质量优化框架 学习之旅 二,主要包括滴滴Booster移动APP质量优化框架 学习之旅 二使用实例、应用技巧、基本知识点总结和需要注意事项,具有一定的参考价值,需要的朋友可以参考一下。

推荐阅读:

滴滴Booster移动App质量优化框架-学习之旅 一

Android 模块Api化演练

不一样视角的Glide剖析(一)

续写滴滴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优化掉的资源进行处理

资源混淆见微信开源的资源混淆库AndResGuard

对重复的资源优化和对被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_文件中

源码见:doRemoveRepeatResources方法

验证: 分别在App/lib module显示三张图片,重复资源如下:

查看没集成重复的资源优化的apk,如图:

使用工具查看集成重复的资源优化的apk,如图:

集成重复的资源优化打包,控制和输出报告都可以看到如下输出:

可以知道删除哪些重复资源,压缩包减少了多少kb。

二、无用资源优化

通过shrinkResources true来开启资源压缩,资源压缩工具会把无用的资源替换成预定义的版本而不是移除, 如果采用人工移除的方式会带来后期的维护成本,在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.

无用资源优化的代码实现整体思路:

1.从ap_文件中解压出resources.arsc条目,并收集该条目的ZipEntry.method,为后续按照同ZipEntry.method 把改动后的resources.arsc添加到ap_文件中

2.收集无用资源

3.根据收集的无用资源,从删除ap_文件中对应zipEntry

4.使用通过[android-chunk-utils]修改resources.arsc,把未使用的资源从对应的stringPool中删除

5.按照同ZipEntry.method把改动后的resources.arsc添加到ap_文件中

源码见:doRemoveUnusedResources方法

集成无用资源优化打包,控制和输出报告都可以看到如下输出:

可以知道删除哪些无用资源,压缩包减少了多少kb。

源码传送门:Boosterstudy



booster-transform-thread

参考阅读:

滴滴Booster学习之旅 

Booster 官方文档

美团-Android App包瘦身优化实践

如果您对博主的更新内容持续感兴趣,请关注公众号!

原文地址:https://www.cnblogs.com/sihaixuan/p/10978222.html