问题
问题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<out BaseVariant>) {
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的话就真的尴尬了。
尾语
下班、回家。
网友评论