推荐先仔细看一下这个：https://developer.android.com/studio/build/shrink-code.html
先介绍一下问题背景：项目中有一些调用了Resources.getIdentifier()动态反射资源的场景，为了防止资源在构建时被shrink，所以我们在想有没有办法保证keep住我们需要反射的资源，同时shrink无用的资源。
首先明确我们最终的目的是apk的瘦身
然后我们来做一些测试哈：
我们先打一个googleRelease的包：size：36.1M
然后我们打开shrinkResources true然后再打包：36.1M
大小没变？应该是调用getIdentifier()的原因。这时我们拆包看确实我们通过反射拿到的资源都在
这时我们把项目中的调用的getIdentifier()方法都注释掉。再打包。包大小仍然没有变化：仍然是36.1M
如果我们没有调用getIdentifie()按理来说应该是把bubble..给shrink掉了，但事实没有。（这里不排除第三方库调用了getIdentifier()）这个怎么搞呢。)
项目比较复杂，我们写一个简单的Demo来测试。。到底什么时候会被shrink掉资源。。。来总结一下规律
写这样一个Demo
场景一：
shrinkResources true
getResources().getIdentifier("p4","drawable", "com.example.zhangtao.shrinkapp");
//先调用getResources().getIdentifier()正常传入res名称p4。
毫无疑问资源不会被顺掉。。
场景二：
shrinkResources true
//下面是需要运行时才知道结果 是不是p4谁都不知道
getResources().getIdentifier(builder.append(getPackageName()).append(getClassLoader().getClass().getName()).toString(),"drawable", "com.example.zhangtao.shrinkapp");
//发现原本很大的资源不见了
但是我们发现了这样一个东西？？？
为什么会有这么一个文件呢，这是干啥用的。。
具体的说明我也没找到，但是我找到了这个，在output/mapping/release/resources.txt 下这个文件记录了shrink resource的信息。有这么一行。。。
意思就是“报告长官，发现了一个没有被用到的资源，文件名是p4，我们把它换成了一个空壳子文件也叫p4”。
想一想这个叫shrink，意思是收缩，压缩。是资源压缩，是没有删除的意思。。。所以说以后注意了，没用到的资源最好还是删了，不要太指望shrink，他会留下“空壳子”
场景三：
shrinkResources true
//我们就写这么一句话，涉及到了一个常量"test_pic_p4" 这里我们改个名，因为结果比较意外。。
findViewById(R.id.image).setId(Integer.parseInt("test_pic_p4"));
//不调用getIdentifier
这个结果有点意外。。。拆包看看。。
我们发现了test_pic_p4的原图。这个东西有点坑啊，资源是否被顺好像和getIdentifier没啥关系呀。。。这里只能猜了，可能sdk调用了。。无从验证。。
查看一下resources.txt，会发现这么一行。。
意思是：drawable test_pic_p4 匹配到了string pool的常量“test_pic_p4”
这个稍微有一点坑人啊。。。再来一个更想不到的。。。
场景四：
shrinkResources true
//这里使用资源名的子串：
findViewById(R.id.image).setId(Integer.parseInt("test_pic"));
//不调用getIdentifier
还是能看到。。。查看resources.txt 发现：
意思是：drawable test_pic_p4 匹配到了string pool的常量“test_pic”
这还做的是模糊匹配呢、、、可以理解google为了保证安全，防止资源找不到，尽可能shink安全的资源，任何有可能用到的资源都会保留。
说到这我就感觉shrinkResources有点不太靠谱了，很多没用到的资源都可能匹配到导致不被压缩，所以资源最好还是自己删。
场景五：
启用严格匹配：
定义文件在 res/raw/keep.xml 内容启用严格引用检查：
//引用字符串
findViewById(R.id.image).setId(Integer.parseInt("test_pic_p4"));
//调用getIdentifier 但传入的东西不知道肯定不是test_pic_p4，但编译器不知道。
getResources().getIdentifier(builder.append(getPackageName()).append(getClassLoader().getClass().getName()).toString(),"drawable", "com.example.zhangtao.shrinkapp");
图片被压缩了。
如果这么写：getResources().getIdentifier("test_pic_p4","drawable", "com.example.zhangtao.shrinkapp");
这个东西也会被压缩。。。再回去读一下文档对strict的说明。
这些是默认情况下启用的安全压缩模式的示例。但您可以停用这一“有备无患”处理方式，并指定资源压缩器只保留其确定已使用的资源
也就是说如果你调用了getIdentifier动态加载资源 肯定是不能有tools:shrinkMode="strict"，反射的资源肯定是找不到的，除非keep。（上面也有说就算没有tools:shrinkMode="strict"，也有可能找不到）
下面来总结规律：（个人总结）
1.模糊匹配使得shrinkResources压缩的力度不大。
shrinkResources true 很大的可能 没使用的资源没被压缩（会有各种各样的匹配原则），包大小很可能没多大变化。如果调用getIdentifier可能找到资源，也可能找不到资源。
2.建议确定不用的资源手动删除shrinkResources true会留下空壳子。
3.严格模式下，只有正常使用的资源会保留，其他的都会被压缩。
4.shrinkResources true不管是否严格模式，不能使用getIdentifier（除非你配置keep住所有要使用的资源）。
5.关于混淆的原则
我们在ShrinkResourcesTransform 中可以找到这样一段（ResourceUsageAnalyzer）
策略是
.9 图会用33的一个.9图替换掉。
png会用11的png替换掉
部分
既然有了上面的结论，我们也就知道为什么我们开启了shrinkResources true不管是否调用getIdentifier 包大小都没有明显变化。
下面来说推荐方案：
推荐方案一：
shrinkResources false; 手动删除项目中所有的没用到的资源。
推荐方案二：
shrinkResources true；启用严格模式，把所有反射的资源都放到keep.xml下(这样包里会有shrink壳子)。
对于方案一和二，都可以正常使用getIdentifier。
其实如果方案二实现了也就相当于把方案一做了，有一个转换方法。方案二做完后，查看resources.txt就可以看到所有被shrink的资源，这样再把每一个资源删除，就变成方案一了、