Android Data Binding 在 library module 中遇到错误及解决办法
记一次DataBinding在librarymodule中遇到的大坑
使用DataBinding也有半年多了，从最初的setVariable，替换findViewById，到比较高级的双向绑定，自定义Adapter、Component，查看源码了解编译、运行流程，也算是小有成果，且没有碰到DataBinding本身实现上的问题。
然而，最近在一次重构组件化（见MDCC上冯森林的《回归初心，从容器化到组件化》）的过程中，碰到了一个比较严重的BUG。已经提交issue（#224048）到了AOSP，虽然改起来是不麻烦，但是因为是gradleplugin，所以--，还是让Google自己来吧。希望能早日修复。
Librarymodule生成class
在librarymodule下启用DataBinding很简单，跟applicationmodule一样，加上:
android{
dataBinding{
enabled=true
}
}
对应生成的binding类会在manifest里面指定的packagename下的databinding包下。
坑
于是坑的地方就在这里了，编译不过了…
为啥呢？报错说symbol找不到…于是在module的build下查看生成的Binding类…卧槽？！怎么是abstract的？怎么都找不到那些get方法了？虽然我也不知道为什么我们会从binding类里面去拿之前set进去的ViewModel。
WTF?!
Whathappened
Fuck归fuck，究竟怎么回事还是要研究一下的。
是我们姿势错了？Dagger2生成哪里出问题了？还是DataBinding的bug呢？
因为之前也研究过databinding生成部分的代码，所以找到问题所在没有花太多时间，这里不多啰嗦，直接看对应位置。
在CompilerChief的writeViewBinderInterfaces中:
publicvoidwriteViewBinderInterfaces(booleanisLibrary){
ensureDataBinder();
mDataBinder.writerBaseClasses(isLibrary);
}
对应DataBinder:
publicvoidwriterBaseClasses(booleanisLibrary){
for(LayoutBinderlayoutBinder:mLayoutBinders){
try{
Scope.enter(layoutBinder);
if(isLibrary||layoutBinder.hasVariations()){
StringclassName=layoutBinder.getClassName();
StringcanonicalName=layoutBinder.getPackage()+"."+className;
if(mWrittenClasses.contains(canonicalName)){
continue;
}
L.d("writingdatabinderbase%s",canonicalName);
mFileWriter.writeToFile(canonicalName,
layoutBinder.writeViewBinderBaseClass(isLibrary));
mWrittenClasses.add(canonicalName);
}
}catch(ScopedExceptionex){
Scope.defer(ex);
}finally{
Scope.exit();
}
}
}
这里调用了LayoutBinder（真正的实现类会调用writeViewBinder）:
publicStringwriteViewBinderBaseClass(booleanforLibrary){
ensureWriter();
returnmWriter.writeBaseClass(forLibrary);
}
可以看到如果是librarymodule，我们会做特殊的编译，而不会生成真正的实现:
publicfunwriteBaseClass(forLibrary:Boolean):String=
kcode("package${layoutBinder.`package`};"){
Scope.reset()
nl("importandroid.databinding.Bindable;")
nl("importandroid.databinding.DataBindingUtil;")
nl("importandroid.databinding.ViewDataBinding;")
nl("publicabstractclass$baseClassNameextendsViewDataBinding{")
layoutBinder.sortedTargets.filter{it.id!=null}.forEach{
tab("publicfinal${it.interfaceClass}${it.fieldName};")
}
nl("")
tab("protected$baseClassName(android.databinding.DataBindingComponentbindingComponent,android.view.Viewroot_,intlocalFieldCount"){
layoutBinder.sortedTargets.filter{it.id!=null}.forEach{
tab(",${it.interfaceClass}${it.constructorParamName}")
}
}
tab("){"){
tab("super(bindingComponent,root_,localFieldCount);")
layoutBinder.sortedTargets.filter{it.id!=null}.forEach{
tab("this.${it.fieldName}=${it.constructorParamName};")
}
}
tab("}")
nl("")
variables.forEach{
if(it.userDefinedType!=null){
valtype=ModelAnalyzer.getInstance().applyImports(it.userDefinedType,model.imports)
tab("publicabstractvoid${it.setterName}($type${it.readableName});")
}
}
tab("publicstatic$baseClassNameinflate(android.view.LayoutInflaterinflater,android.view.ViewGrouproot,booleanattachToRoot){"){
tab("returninflate(inflater,root,attachToRoot,android.databinding.DataBindingUtil.getDefaultComponent());")
}
tab("}")
tab("publicstatic$baseClassNameinflate(android.view.LayoutInflaterinflater){"){
tab("returninflate(inflater,android.databinding.DataBindingUtil.getDefaultComponent());")
}
tab("}")
tab("publicstatic$baseClassNamebind(android.view.Viewview){"){
if(forLibrary){
tab("returnnull;")
}else{
tab("returnbind(view,android.databinding.DataBindingUtil.getDefaultComponent());")
}
}
tab("}")
tab("publicstatic$baseClassNameinflate(android.view.LayoutInflaterinflater,android.view.ViewGrouproot,booleanattachToRoot,android.databinding.DataBindingComponentbindingComponent){"){
if(forLibrary){
tab("returnnull;")
}else{
tab("returnDataBindingUtil.<$baseClassName>inflate(inflater,${layoutBinder.modulePackage}.R.layout.${layoutBinder.layoutname},root,attachToRoot,bindingComponent);")
}
}
tab("}")
tab("publicstatic$baseClassNameinflate(android.view.LayoutInflaterinflater,android.databinding.DataBindingComponentbindingComponent){"){
if(forLibrary){
tab("returnnull;")
}else{
tab("returnDataBindingUtil.<$baseClassName>inflate(inflater,${layoutBinder.modulePackage}.R.layout.${layoutBinder.layoutname},null,false,bindingComponent);")
}
}
tab("}")
tab("publicstatic$baseClassNamebind(android.view.Viewview,android.databinding.DataBindingComponentbindingComponent){"){
if(forLibrary){
tab("returnnull;")
}else{
tab("return($baseClassName)bind(bindingComponent,view,${layoutBinder.modulePackage}.R.layout.${layoutBinder.layoutname});")
}
}
tab("}")
nl("}")
}.generate()
}
那么问题来了，这里的这个只是用来使librarymodule编译能通过的abstractclass，只生成了所有variable的setter方法啊，getter呢？坑爹呢？
看来是Google压根没考虑到还需要这个。写Kotlin的都少根筋吗？
规避方案
为了让librarymodule能编译通过（这样才能在applicationmodule生成真正的Binding实现），只好避免使用getter方法，幸而通过之前开发的DataBindingAdapter和lambdapresenter确实能规避使用getter去拿viewmodel。
不管怎么说，希望Google能在下个版本修复这个问题。就是iterator一下，写个abstract接口而已。
感谢阅读，希望能帮助到大家，谢谢大家对本站的支持！