问题
问题1：子module里的R.java为何不是常量？
问题2：ButterKnife是怎么解决的？
问题3：由于ButterKnife的R2.java存在，导致java compile替换了注解中的常量，为何实际运行时没出现问题？
解答
问题1 子module里的R.java为何不是常量？
在模块开发时大家都会发现module中的R.java是没有final关键字的，如:
public static int icon_awesome_arrow=0x7f020188;
public static int icon_awesome_close=0x7f020189;
public static int icon_awesome_large=0x7f02018a;
public static int icon_awesome_small=0x7f02018b;
这样导致我们使用switch-case也好，注解也好，凡是语法规定必须要使用常量的地方都无法直接R.drawable了，这是为何呢？
那么我们来假设如果有final的话会出现什么问题，每个module各自打成aar的时候AAPT会单独生成R.java，那么在执行java compile成class的时候会将常量直接替换成具体的值，如:
@BindView(2131755430)
protected FrameLayout errorViewParent;
由于各个module间无法保证R.java中变量对应着的数值不同，所以如果出现相同的岂不是尴尬了？当然假如相同也没关系，可以反过来取到int数值后去找对应的resName，然后再去app的大R.java里去取，再将各个module的替换掉。mdzz想着就麻烦，索性不给module的R.java定义为常量了。
俗话说的好，天王盖地虎，小鸡炖蘑菇，没有什么是他们那些大佬无法解决的，比如ButterKnife就提供了一个方案。
问题2：ButterKnife是怎么解决的？
mmp，既然官方搞得R.java不是常量，那我们就copy一份R.java，搞个R2.java，然后把所有变量都加上final关键字，然后相关地方直接引用R2不就得了咯。没错，就是这么简单，让我们来看看相关gradle plugin是怎样做的。
private fun applyPlugin(variants: DomainObjectSet) {
variants.all { variant ->
variant.outputs.forEach { output ->
val processResources = output.processResources
// TODO proper task registered as source-generating?
processResources.doLast {
val pathToR = processResources.packageForR.replace('.', File.separatorChar)
val rFile = processResources.sourceOutputDir.resolve(pathToR).resolve("R.java")
FinalRClassBuilder.brewJava(rFile, processResources.sourceOutputDir,
processResources.packageForR, "R2")
}
}
}
}
看到没，与R.java一样的目录，一样的包名，然后改成R2，我水土都不服舅服你。mmp again，突然发现这个文件用kotlin写了？
关于FinalRClassBuilder怎么生成的文件我就不写了，代码都在。
问题3：由于ButterKnife的R2.java存在，导致java compile替换了注解中的常量，为何实际运行时没出现问题？
一般这个问题会去思考的人比较少，可能大佬们觉得太简单，那我等菜比就来瞅瞅。module实际打成aar的时候是没有把R.java打进来的，各位可以自行解压你们aar中的classes.jar，我就不截图了。大家会发现，R.java没有，但是R2.java有啊，那么我们之前在module中的注解里使用的R2.drawable，在javac的时候直接替换成具体的int值了，那岂不是打包后要蹦蹦蹦啊。然而，并没有，这是为啥呢？
我们来看ButterKnife的APT生成的ViewBinding的代码:
public BazhangActivity_ViewBinding(T target, View source) {
this.target = target;
target.parentLayout = Utils.findRequiredViewAsType(source, R.id.parent_layout, "field 'parentLayout'", ViewGroup.class);
target.contentLayout = Utils.findRequiredViewAsType(source, R.id.content, "field 'contentLayout'", FrameLayout.class);
}
擦，发现了吧，实际findViewById取得并不是我们注解里的int值，而仍然是R.id，也就是说注解里传的R.id在编译时已经把该做的都做完了，APT生成的代码取得还是AAPT最终为app生成的R.java，那么也就是最终app打包后BazhangActivity_ViewBinding里的值和原BazhangActivity的值基本都是不同的。假如还在用反射去取注解里的int值来实现findViewById的话就真的尴尬了。
