再不点蓝字关注，机会就要飞走了哦
Apk包大小是Android优化的一项重要指标，本文主要从资源方面着手，提出一些优化的新思路。
无用资源精简
项目随着开发迭代，会遗留大量的无用代码和资源，今天主要说一下无用资源如何精简。
资源精简最重要的是无用资源的检索，常规检索方式有lint 的unused resource ，gradle 开启shrinkResources 。但用lint 仅仅检测出了十几个，效果不明显，开启shrinkResources 后，对包大小的影响也在几K级别。Google把shrinkResources 集成到了打包流程中，为什么很多无用资源都检索不出来呢，带着这些疑问，我决定仔细研究一下原理。
开启shrinkResources 后，打包过程会新增task transformClassesWithShrinkResFor{variant} ，gradle1.5 之后只需要注册一个tranform 就会产生一个对应的task ，查看源码发现对应的tranfrom 在com.android.build.gradle.internal.transforms.ShrinkResourcesTransform ，此类中调用com.android.build.gradle.tasks.ResourceUsageAnalyzer的analyze 方法进行分析无用资源。
该方法首先会根据R 文件来生成资源表，然后利用asm 遍历所有的class 分析class 中用到的R ，然后将资源表中相应资源标记为可达，接着分析Mainfest ，Res 文件找出资源文件中引用的其它资源。最终调用keepPossiblyReferencedResources ，此方法是标记可能会引用的资源，项目中调用了getIdentifier ，参数是通配符，资源名称只要匹配就会标记为可用。
查看编译后的文件build/outputs/mapping/release/resources.txt ，shrinkResources 相关的日志都会在此文件中，有大量资源因为keepPossiblyReferencedResources 被标记为可达。
从原理上分析，这种查找无用资源的方式是可行的，只是需要稍微改动。默认情况下shrinkResources 是安全模式，可能会被使用的资源也被标记为了可达；关闭安全模式，开启严格模式，只有真正通过代码或是资源文件引用的资源才被标记为可达。混淆配置添加**-dontshrink -dontoptimize** ，系统是分析混淆后的类，如果一个类被压缩掉了，它引用的资源就会被标志为不可达，这时候如果仅仅删除资源，后续就编译通不过了。
在res 目录中添加keep.xml ,设置严格模式。
经过上述配置改动后，重新编译查看输出文件，可以看到大量的无用资源。打包过程是将其替换为了一个同名的空文件，但我们可以解析这个文件，找到无用资源，用脚本批量删除。
头条app客户端原始15M，通过脚本批量删除了600+资源，包大小减小0.47M。不同项目效果不同。
重复资源精简
Android开发推崇根据业务拆分多个模块,模块间为了防止资源覆盖，会给每一个模块的资源加一个前缀，同样的资源就会在apk包中出现多次。阅读微信资源混淆源码时发现，它将每个资源Chunk 中的资源路径替换为了一个较短的路径。那么对于重复资源，仅仅保留一份，修改arsc文件，重定向Chunk 对应的资源路径，就可以解决重复资源问题。
打包过程中ProcessAndroidResources 这个Task会生成资源文件**/build/intermediates/res/resources-release.ap_** ,该文件是一个zip文件，解压后包括AndroidManifest.xml,res,resources.arsc 几部分。res 目录中的文件即是最终要打入到apk中的，resources.arsc 即为最终的arsc 文件。
解压ap_ 文件，遍历res 目录中的文件，根据每个文件的md5 值，找出重复的文件。最终发现主要有两种重复的情况，一种是文件名相同，但在不同的dpi 目录下；一种是内容相同，名字不同。删除重复文件，保留一份，然后利用ChunkUtil 这个库来修改arsc 文件，ChunkUtil 是一个arsc 编辑库。
重复资源处理，作为一个gradle 插件，后续会开源给大家作为参考。
重复资源处理后，资源映射如下所示,每个资源代码一个chunk ，假如以下3个chunk 中的资源相同，则处理后它们会指向相同的路径。
经过打包期间删除重复资源，共删除了300+资源，包大小减小了0.28M，不同的项目效果不同。
重复资源处理与微信资源混淆冲突
项目中如果使用了微信资源混淆，打包失败。如果你的项目中没使用微信资源混淆，就没必要看后面的问题了。
根据错误堆栈可以定位到微信资源混淆出现的位置。阅读微信资源混淆源码，发现映射关系如下：从res/drawable/icon.png 到r/a/c.png 是一一映射的。每个资源路径可变的有两部分，一是资源类型如drawable ，color ；另一个是资源名称。映射过程有以下规则，同类型资源会映射到相同目录中，资源id 相同也即是同名资源映射后的资源名相同。如下图中，资源1和2是名字相同，映射后的名字都是c.png ，资源2和资源3资源类型相同，映射后的资源都在r/b 目录下。
这时候将重复资源处理和微信混淆流程串联起来如下所示：
资源1和资源2映射后的目标路径相同。微信资源混淆会遍历每个chunk ，把每个chunk 中的资源从原始目录copy到目标目录并重新命名为映射后的文件，copy前check目标文件是否存在，如果存在会出现上述错误。
微信资源混淆的目标路径映射规则是根据id值映射的，不是根据原始路径。因此我们需要改变默认的映射规则，如果原始路径相同，则映射到相同的目标路径，并且不做后续的copy工作。修改了映射逻辑后，资源3最终映射的路径也变为了r/a/c.png 。
重新打包，发现还是出现上述错误，只是出错的资源不同。这时候如果有第四个资源,和前面3个资源内容不相同。资源类型和资源1相同，所以映射成了r/a/ 目录,名称和资源3相同，所以最终映射成了r/a/c.png ，又导致了上述目标地址重复的问题。这种情况需要对路径进行remapping 。
对微信资源处理的逻辑全在com.tencent.mm.androlib.res.decoder.ARSCDecoder 的readValue 函数中。
长按识别二维码，关注今日头条技术团队