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接口而已。
感谢阅读,希望能帮助到大家,谢谢大家对本站的支持!