啥是资源冲突覆盖，就是两个不同的文件，有着相同的文件名，在打包apk后引起的系列问题。本文将从情景、解决思路、延伸，三个方面展开。
先简单介绍下背景，App在线上跑了将近7年（历史悠久~），从早期的导购社区，到社区电商，再到社区、电商和直播三驾马车齐驱，也就是三大业务团队。
UI不合预期问题
首先，我们建一个壳工程app，建两个业务工程，分别是电商业务biz_shopping和直播业务biz_live，如下，
接着在电商工程建一个页面layout/activity_shopping.xml，
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android">
<TextView
android:id="@ id/textView"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:text="我是电商页面"
android:textSize="30dp" />
<ImageView
android:id="@ id/imageView"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
app:srcCompat="@drawable/icon_goods" />
</LinearLayout>
其中图标资源drawable/icon_goods如下，
然后有一天，直播团队在直播工程建了一个页面layout/activity_live.xml，
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android">
<TextView
android:id="@ id/textView"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:text="我是直播页面"
android:textSize="30dp" />
<ImageView
android:id="@ id/imageView"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
app:srcCompat="@drawable/icon_goods" />
</LinearLayout>
然后他们引入了一些素材，假设是直播带货相关业务，所以引入了一个商品图标drawable/icon_goods如下，
可以发现，这个图标和电商工程的图标名字相同，但是内容不同，接着运行壳工程，分别打开电商页面和直播页面，
由于同名的图标只会保留一份，导致电商页面无法按预期展示我是商城icon，而展示成了我是直播icon，
相似的，像string资源也一样。
电商工程values/strings.xml，
<resources>
<string name="buy">电商页买买买</string>
</resources>
直播工程values/strings.xml，
<resources>
<string name="buy">直播页买买买</string>
</resources>
打包后也只会保留一份name为buy的字符串，造成另一方的UI不合预期。
那么UI不合预期问题会带来哪些影响呢？
假设这个版本两个团队的功能改动都在热页面（核心页面，在QA测试范围内），那么这个问题是能在各部门集成后的回归测试环节发现的；那如果电商这个页面是冷页面（年久失修，链路深，QA不会去测），那问题就可能会带到线上，直到用户反馈才能把问题暴露出来。
findViewById问题
首先在电商工程新建页面layout/activity_goods_list.xml，里面有一个list，id为shopping_goods_list，
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android">
<ListView
android:id="@ id/shopping_goods_list"
android:layout_width="wrap_content"
android:layout_height="wrap_content" />
</LinearLayout>
接着，直播团队要在直播间带货，也建了一个名字相同的页面layout/activity_goods_list.xml，里面也有一个list，但是id不同，为live_goods_list，
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android">
<ListView
android:id="@ id/live_goods_list"
android:layout_width="wrap_content"
android:layout_height="wrap_content" />
</LinearLayout>
两个工程的Activity在findViewById时分别用自己的id，由于打包只会保留一份activity_goods_list.xml，必有其中一方，会在Activity里，findViewById得到的ListView为null，引发空指针，运行壳工程如下，
发现直播list页面是好的，但是电商list页面报了空指针，
电商团队开始慌了，为什么受伤的总是我？
显然，这个问题如果发生在冷页面，是极有可能带到线上，直到个别用户进到冷页面发生crash触发报警，开发团队才会发现问题，P1故障警告！（当然，crash问题比UI问题严重多了，会有QA自动化覆盖页面来避免，这里暂不讨论）
解决思路首先我们会想到的就是，给每个团队的工程文件加上前缀约束不就行了嘛？又或者人为约束靠不住的话，加个Android的resourcePrefix资源前缀限定，
//resourcePrefix资源前缀限定，只能限定布局文件名和value资源的key，并不能限定图片资源的文件名
android {
//给电商工程加上前缀约束shopping_
resourcePrefix "shopping_"
}
android {
//给直播工程加上前缀约束live_
resourcePrefix "live_"
}
但开头提到过，项目在线上跑了多年，历史包袱贼重，一个App已经有了三四百个子工程，这时再来批量改名，即便使用脚本，也是需要一定的人力投入且有风险的，因为任一图标文件、字符串资源都可能正被多处引用着，再者，有些基础能力组件（如登录），还可能被其他App（如商家版）引用着。
因此，无论从人力投入、还是引入的风险来看，ROI都是不划算的。
那能不能先把目标降低，只做基本的扫描检测？比如通过gradle构建项目的时候来搞点事情？
开源项目CheckResourceConflict
查了些资料，还真发现了一个开源项目CheckResourceConflict，来看看人家是怎么做的。
首先依赖插件，
classpath 'com.orzangleli:checkresourceconflict:0.0.2'
然后在app/build.gradle使用插件，
apply plugin: 'CheckResourcePrefixPlugin'
sync一下，然后运行插件，
运行后，生成html报告，可以在浏览器中查看，可见，冲突的图标、布局文件、字符串资源都被列出来了。
项目分析
首先插件要求项目的Android Gradle Plugin版本为不低于3.3，对应的gradle版本不低于4.10.1，因为新版本有一个接口BaseVariantImpl.allRawAndroidResources.files可以在编译期间获取到所有的资源文件，附上一张Android gradle plugin和gradle的版本对照，
然后看到项目核心类，
class CheckResourcePrefixPlugin implements Plugin<Project> {
@Override
void apply(Project project) {
project.afterEvaluate {
variants.forEach { variant ->
variant as BaseVariantImpl
//任务名字
def thisTaskName = "checkResource${variant.name.capitalize()}"
//创建任务
def thisTask = project.task(thisTaskName)
//给任务指定一个group
thisTask.group = "check"
//在Execution阶段，获取资源文件
thisTask.doLast {
def files = variant.allRawAndroidResources.files
}
}
}
}
}
点击allRawAndroidResources进去看看，
public interface BaseVariant {
/**
* Returns file collection containing all raw Android resources, including the ones from
* transitive dependencies.
*
* <p><strong>This is an incubating API, and it can be changed or removed without
* notice.</strong>
*/
//返回包含所有原始Android资源的文件集合，包括来自传递依赖项的资源
//这是一个正在孵化的API，可以更改或删除它，恕不另行通知
@Incubating
@NonNull
FileCollection getAllRawAndroidResources();
}
嗯，符合Android gradle一贯的拥抱变化的作风，
@Incubating的接口我们随时可以改，通不通知，文档里更不更新，我们看心情 --“Android gradle团队”
开个玩笑啦，不过每当升级gradle都确实会带来一堆问题，什么接口没了，一些老的插件又要改造之类的，真是苦了开发者啊！不过，哈迪建的demo用的是Android gradle 4.0.0，也还没啥问题。
拿到资源文件后，
Map<String, Resource> mResourceMap
Map<String, List<Resource>> mConflictResourceMap
//在Execution阶段，获取资源文件
thisTask.doLast {
def files = variant.allRawAndroidResources.files
//遍历Set<File>，将value资源、file资源存进mResourceMap，发生冲突的资源则存进mConflictResourceMap
files.forEach { file -> traverseResources(file)
}
//用mConflictResourceMap，生成资源对象树，然后转成json字符串
//把json字符串塞给html模板，生成报表
}
下面看看是怎么判断文件冲突的，
void recordResource(Resource resource) {
//获取资源id，
//value资源id："value@" lastDirectory "/" resName
//file资源id："file@" lastDirectory "/" fileName
def uniqueId = resource.getUniqueId()
if (mResourceMap.containsKey(uniqueId)) {
Resource oldOne = mResourceMap.get(uniqueId)
//如果id相同，但是内容不同，则发生冲突（内容比较：value资源比较字符值；file资源比较md5）
if (oldOne != null && !oldOne.compare(resource)) {
List<Resource> resources = mConflictResourceMap.get(uniqueId)
if (resources == null) {
resources = new ArrayList<Resource>()
resources.add(oldOne)
}
//把冲突的几个资源存进list，方便对照
resources.add(resource)
//存进冲突map
mConflictResourceMap.put(uniqueId, resources)
}
}
//存进总map
mResourceMap.put(uniqueId, resource)
}
大致流程如下，
到这里，可能会有一个问题，就是项目太老，很多插件用的gradle版本很低，gradle一升级这些插件就废怎么办？哈迪大致熟悉了一下内部的持续集成体系（ci平台 Jenkins）后，想到了一个迷你主客的思路，就是壳工程的阉割版，自建一个迷你主客，只引入compile或implementation的依赖，忽略所有老插件，将gradle版本升高，迷你主客虽跑不起来，但是可以进行资源编译和运行CheckResourceConflict插件，大致思路如下，
当然啦，如果有足够人力投入，直接魔改一发老插件，把gradle版本升起来就行了，毕竟高版本的gradle支持增量编译，构建速度提升了不少~
延伸冗余资源
既然可以检测出啥是资源冲突覆盖，就是两个不同的文件，有着相同的文件名，在打包apk后引起的系列问题。本文将从情景、解决思路、延伸，三个方面展开。
先简单介绍下背景，App在线上跑了将近7年（历史悠久~），从早期的导购社区，到社区电商，再到社区、电商和直播三驾马车齐驱，也就是三大业务团队。
首先，我们建一个壳工程app，建两个业务工程，分别是电商业务biz_shopping和直播业务biz_live，如下，
接着在电商工程建一个页面layout/activity_shopping.xml，
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android">
<TextView
android:id="@ id/textView"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:text="我是电商页面"
android:textSize="30dp" />
<ImageView
android:id="@ id/imageView"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
app:srcCompat="@drawable/icon_goods" />
</LinearLayout>
其中图标资源drawable/icon_goods如下，
然后有一天，直播团队在直播工程建了一个页面layout/activity_live.xml，
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android">
<TextView
android:id="@ id/textView"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:text="我是直播页面"
android:textSize="30dp" />
<ImageView
android:id="@ id/imageView"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
app:srcCompat="@drawable/icon_goods" />
</LinearLayout>
然后他们引入了一些素材，假设是直播带货相关业务，所以引入了一个商品图标drawable/icon_goods如下，
可以发现，这个图标和电商工程的图标名字相同，但是内容不同，接着运行壳工程，分别打开电商页面和直播页面，
由于同名的图标只会保留一份，导致电商页面无法按预期展示我是商城icon，而展示成了我是直播icon，
相似的，像string资源也一样。
电商工程values/strings.xml，
<resources>
<string name="buy">电商页买买买</string>
</resources>
直播工程values/strings.xml，
<resources>
<string name="buy">直播页买买买</string>
</resources>
打包后也只会保留一份name为buy的字符串，造成另一方的UI不合预期。
那么UI不合预期问题会带来哪些影响呢？
假设这个版本两个团队的功能改动都在热页面（核心页面，在QA测试范围内），那么这个问题是能在各部门集成后的回归测试环节发现的；那如果电商这个页面是冷页面（年久失修，链路深，QA不会去测），那问题就可能会带到线上，直到用户反馈才能把问题暴露出来。
findViewById问题首先在电商工程新建页面layout/activity_goods_list.xml，里面有一个list，id为shopping_goods_list，
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android">
<ListView
android:id="@ id/shopping_goods_list"
android:layout_width="wrap_content"
android:layout_height="wrap_content" />
</LinearLayout>
接着，直播团队要在直播间带货，也建了一个名字相同的页面layout/activity_goods_list.xml，里面也有一个list，但是id不同，为live_goods_list，
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android">
<ListView
android:id="@ id/live_goods_list"
android:layout_width="wrap_content"
android:layout_height="wrap_content" />
</LinearLayout>
两个工程的Activity在findViewById时分别用自己的id，由于打包只会保留一份activity_goods_list.xml，必有其中一方，会在Activity里，findViewById得到的ListView为null，引发空指针，运行壳工程如下，
发现直播list页面是好的，但是电商list页面报了空指针，
电商团队开始慌了，为什么受伤的总是我？
显然，这个问题如果发生在冷页面，是极有可能带到线上，直到个别用户进到冷页面发生crash触发报警，开发团队才会发现问题，P1故障警告！（当然，crash问题比UI问题严重多了，会有QA自动化覆盖页面来避免，这里暂不讨论）
解决思路首先我们会想到的就是，给每个团队的工程文件加上前缀约束不就行了嘛？又或者人为约束靠不住的话，加个Android的resourcePrefix资源前缀限定，
//resourcePrefix资源前缀限定，只能限定布局文件名和value资源的key，并不能限定图片资源的文件名
android {
//给电商工程加上前缀约束shopping_
resourcePrefix "shopping_"
}
android {
//给直播工程加上前缀约束live_
resourcePrefix "live_"
}
但开头提到过，项目在线上跑了多年，历史包袱贼重，一个App已经有了三四百个子工程，这时再来批量改名，即便使用脚本，也是需要一定的人力投入且有风险的，因为任一图标文件、字符串资源都可能正被多处引用着，再者，有些基础能力组件（如登录），还可能被其他App（如商家版）引用着。
因此，无论从人力投入、还是引入的风险来看，ROI都是不划算的。
那能不能先把目标降低，只做基本的扫描检测？比如通过gradle构建项目的时候来搞点事情？
开源项目CheckResourceConflict查了些资料，还真发现了一个开源项目CheckResourceConflict，来看看人家是怎么做的。
首先依赖插件，
classpath 'com.orzangleli:checkresourceconflict:0.0.2'
然后在app/build.gradle使用插件，
apply plugin: 'CheckResourcePrefixPlugin'
sync一下，然后运行插件，
运行后，生成html报告，可以在浏览器中查看，可见，冲突的图标、布局文件、字符串资源都被列出来了。
首先插件要求项目的Android Gradle Plugin版本为不低于3.3，对应的gradle版本不低于4.10.1，因为新版本有一个接口BaseVariantImpl.allRawAndroidResources.files可以在编译期间获取到所有的资源文件，附上一张Android gradle plugin和gradle的版本对照，
然后看到项目核心类，
class CheckResourcePrefixPlugin implements Plugin<Project> {
@Override
void apply(Project project) {
project.afterEvaluate {
variants.forEach { variant ->
variant as BaseVariantImpl
//任务名字
def thisTaskName = "checkResource${variant.name.capitalize()}"
//创建任务
def thisTask = project.task(thisTaskName)
//给任务指定一个group
thisTask.group = "check"
//在Execution阶段，获取资源文件
thisTask.doLast {
def files = variant.allRawAndroidResources.files
}
}
}
}
}
点击allRawAndroidResources进去看看，
public interface BaseVariant {
/**
* Returns file collection containing all raw Android resources, including the ones from
* transitive dependencies.
*
* <p><strong>This is an incubating API, and it can be changed or removed without
* notice.</strong>
*/
//返回包含所有原始Android资源的文件集合，包括来自传递依赖项的资源
//这是一个正在孵化的API，可以更改或删除它，恕不另行通知
@Incubating
@NonNull
FileCollection getAllRawAndroidResources();
}
嗯，符合Android gradle一贯的拥抱变化的作风，
@Incubating的接口我们随时可以改，通不通知，文档里更不更新，我们看心情 --“Android gradle团队”
开个玩笑啦，不过每当升级gradle都确实会带来一堆问题，什么接口没了，一些老的插件又要改造之类的，真是苦了开发者啊！不过，哈迪建的demo用的是Android gradle 4.0.0，也还没啥问题。
拿到资源文件后，
Map<String, Resource> mResourceMap
Map<String, List<Resource>> mConflictResourceMap
//在Execution阶段，获取资源文件
thisTask.doLast {
def files = variant.allRawAndroidResources.files
//遍历Set<File>，将value资源、file资源存进mResourceMap，发生冲突的资源则存进mConflictResourceMap
files.forEach { file -> traverseResources(file)
}
//用mConflictResourceMap，生成资源对象树，然后转成json字符串
//把json字符串塞给html模板，生成报表
}
下面看看是怎么判断文件冲突的，
void recordResource(Resource resource) {
//获取资源id，
//value资源id："value@" lastDirectory "/" resName
//file资源id："file@" lastDirectory "/" fileName
def uniqueId = resource.getUniqueId()
if (mResourceMap.containsKey(uniqueId)) {
Resource oldOne = mResourceMap.get(uniqueId)
//如果id相同，但是内容不同，则发生冲突（内容比较：value资源比较字符值；file资源比较md5）
if (oldOne != null && !oldOne.compare(resource)) {
List<Resource> resources = mConflictResourceMap.get(uniqueId)
if (resources == null) {
resources = new ArrayList<Resource>()
resources.add(oldOne)
}
//把冲突的几个资源存进list，方便对照
resources.add(resource)
//存进冲突map
mConflictResourceMap.put(uniqueId, resources)
}
}
//存进总map
mResourceMap.put(uniqueId, resource)
}
大致流程如下，
到这里，可能会有一个问题，就是项目太老，很多插件用的gradle版本很低，gradle一升级这些插件就废怎么办？哈迪大致熟悉了一下内部的持续集成体系（ci平台 Jenkins）后，想到了一个迷你主客的思路，就是壳工程的阉割版，自建一个迷你主客，只引入compile或implementation的依赖，忽略所有老插件，将gradle版本升高，迷你主客虽跑不起来，但是可以进行资源编译和运行CheckResourceConflict插件，大致思路如下，
当然啦，如果有足够人力投入，直接魔改一发老插件，把gradle版本升起来就行了，毕竟高版本的gradle支持增量编译，构建速度提升了不少~
延伸冗余资源
既然可以检测出名字相同但内容不同的文件引起的冲突覆盖，那有没有想过，内容相同但名字不同引起的冗余问题呢？比如，电商工程和直播工程都有一个相同的图标，但由于命名不一样，打包时就会打包进两份文件增大包体积。
方案一：使用GitHub - AndResGuard，如
1. classpath 'com.tencent.mm:AndResGuard-gradle-plugin:1.2.18'
2. apply plugin: 'AndResGuard'
3. andResGuard {
// 打开这个开关会合并所有哈希值相同的资源，但请不要过度依赖这个功能去除去冗余资源
mergeDuplicatedRes = true
}
sync一下，然后在直播工程拷贝一份drawable/icon_goods命名为drawable/icon_goods2，即完全一样的图标文件用了不同的名字，导致资源冗余，然后运行，
在app/build/outputs/apk/debug/AndResGuard_app-debug下得到apk文件和一些映射文件，其中merge_duplicated_res_mapping_app-debug.txt，
res filter path mapping:
//...
//icon_goods2指向了icon_goods
res/drawable-xhdpi-v4/icon_goods2.png : res/drawable-xhdpi-v4/cb.png -> res/drawable-xhdpi-v4/icon_goods.png : res/drawable-xhdpi-v4/ca.png (size:8.2KB)
removed: count(8), totalSize(10.5KB)
或者，把app-debug_unsigned.apk拖进Android studio查看，可以发现我是直播icon这个图标只剩下一张了。
AndResGuard大致思路：输入apk文件、解析并改写resources.arsc、重新打包。
//ARSCDecoder.java
private MergeDuplicatedResInfo mergeDuplicated(File resRawFile, File resDestFile,
String compatibaleraw, String result){
MergeDuplicatedResInfo filterInfo = null;
//大小相同的文件被缓存在同一个list里，加快查找
List<MergeDuplicatedResInfo> mergeDuplicatedResInfoList =
mMergeDuplicatedResInfoData.get(resRawFile.length());
if (mergeDuplicatedResInfoList != null) {
//遍历这个list
for (MergeDuplicatedResInfo mergeDuplicatedResInfo : mergeDuplicatedResInfoList) {
if (mergeDuplicatedResInfo.md5 == null) {
mergeDuplicatedResInfo.md5 =
Md5Util.getMD5Str(new File(mergeDuplicatedResInfo.filePath));
}
String resRawFileMd5 = Md5Util.getMD5Str(resRawFile);
//查找md5值相同的文件
if (!resRawFileMd5.isEmpty() && resRawFileMd5.equals(mergeDuplicatedResInfo.md5)) {
filterInfo = mergeDuplicatedResInfo;
filterInfo.md5 = resRawFileMd5;
break;
}
}
}
if (filterInfo != null) {
//把冗余文件和替代文件的映射写入mapping.txt，如icon_goods2指向了icon_goods
generalFilterResIDMapping(compatibaleraw, result, filterInfo.originalName,
filterInfo.fileName, resRawFile.length());
//统计文件数量和大小
mMergeDuplicatedResCount ;
mMergeDuplicatedResTotalSize = resRawFile.length();
} else {
//还没有相同的文件，new个对象缓存起来就行
MergeDuplicatedResInfo info = new MergeDuplicatedResInfo.Builder()
.setFileName(result)
.setFilePath(resDestFile.getAbsolutePath())
.setOriginalName(compatibaleraw)
.create();
info.fileName = result;
info.filePath = resDestFile.getAbsolutePath();
info.originalName = compatibaleraw;
if (mergeDuplicatedResInfoList == null) {
mergeDuplicatedResInfoList = new ArrayList<>();
mMergeDuplicatedResInfoData.put(resRawFile.length(), mergeDuplicatedResInfoList);
}
mergeDuplicatedResInfoList.add(info);
}
//filterInfo = mergeDuplicatedResInfo，即返回值要么为null，要么为第一个被发现的icon_goods
return filterInfo;
}
再看到调用这个方法的地方，
//ARSCDecoder.java
private void readValue(boolean flags, int specNamesId) throws IOException, AndrolibException {
MergeDuplicatedResInfo filterInfo = null;
//获取gradle中的mergeDuplicatedRes配置
boolean mergeDuplicatedRes = mApkDecoder.getConfig().mMergeDuplicatedRes;
if (mergeDuplicatedRes) {
//如果有开启冗余资源的过滤，调用mergeDuplicated拿到第一个被发现的icon_goods
filterInfo = mergeDuplicated(resRawFile, resDestFile, compatibaleraw, result);
if (filterInfo != null) {
resDestFile = new File(filterInfo.filePath);
result = filterInfo.fileName;
}
}
//将目标统统指向第一个被发现的icon_goods
mTableStringsResguard.put(data, result);
}
具体实现可见ARSCDecoder.mergeDuplicated。
方案二：使用android-chunk-utils，详见美团 - Android App包瘦身优化实践，思路跟方案一基本一致，都是改写resources.arsc。
