快捷導(dǎo)航

Android Data Binding 在 library module 中遇到錯(cuò)誤及解決辦法

更新時(shí)間：2017年03月17日 08:39:31 作者：魔都三帥

這篇文章主要介紹了Android Data Binding 在 library module 中遇到錯(cuò)誤及解決辦法的相關(guān)資料,需要的朋友可以參考下

記一次 Data Binding 在 library module 中遇到的大坑

使用 Data Binding 也有半年多了，從最初的 setVariable，替換 findViewById，到比較高級(jí)的雙向綁定，自定義 Adapter、Component，查看源碼了解編譯、運(yùn)行流程，也算是小有成果，且沒有碰到 Data Binding 本身實(shí)現(xiàn)上的問題。

然而，最近在一次重構(gòu)組件化（見 MDCC 上馮森林的《回歸初心，從容器化到組件化》）的過程中，碰到了一個(gè)比較嚴(yán)重的 BUG。已經(jīng)提交 issue（#224048）到了 AOSP，雖然改起來是不麻煩，但是因?yàn)槭?gradle plugin，所以 - -，還是讓 Google 自己來吧。希望能早日修復(fù)。

Library module 生成 class

在 library module 下啟用 Data Binding 很簡(jiǎn)單，跟 application module 一樣，加上:

android { 
 dataBinding {
  enabled = true
 }
}

對(duì)應(yīng)生成的 binding 類會(huì)在 manifest 里面指定的 package name 下的 databinding 包下。

坑

于是坑的地方就在這里了，編譯不過了…

為啥呢？報(bào)錯(cuò)說 symbol 找不到…于是在 module 的 build 下查看生成的 Binding 類…？！怎么是 abstract 的？怎么都找不到那些 get 方法了？雖然我也不知道為什么我們會(huì)從 binding 類里面去拿之前 set 進(jìn)去的 ViewModel。

WTF?!

What happened

究竟怎么回事還是要研究一下的。

是我們姿勢(shì)錯(cuò)了？Dagger2 生成哪里出問題了？還是 Data Binding 的 bug 呢？

因?yàn)橹耙惭芯窟^ data binding 生成部分的代碼，所以找到問題所在沒有花太多時(shí)間，這里不多啰嗦，直接看對(duì)應(yīng)位置。

在 CompilerChief 的 writeViewBinderInterfaces 中:

public void writeViewBinderInterfaces(boolean isLibrary) {
 ensureDataBinder();
 mDataBinder.writerBaseClasses(isLibrary);
}

對(duì)應(yīng) DataBinder:

public void writerBaseClasses(boolean isLibrary) {
 for (LayoutBinder layoutBinder : mLayoutBinders) {
  try {
   Scope.enter(layoutBinder);
   if (isLibrary || layoutBinder.hasVariations()) {
    String className = layoutBinder.getClassName();
    String canonicalName = layoutBinder.getPackage() + "." + className;
    if (mWrittenClasses.contains(canonicalName)) {
     continue;
    }
    L.d("writing data binder base %s", canonicalName);
    mFileWriter.writeToFile(canonicalName,
      layoutBinder.writeViewBinderBaseClass(isLibrary));
    mWrittenClasses.add(canonicalName);
   }
  } catch (ScopedException ex){
   Scope.defer(ex);
  } finally {
   Scope.exit();
  }
 }
}

這里調(diào)用了 LayoutBinder（真正的實(shí)現(xiàn)類會(huì)調(diào)用 writeViewBinder）:

public String writeViewBinderBaseClass(boolean forLibrary) {
 ensureWriter();
 return mWriter.writeBaseClass(forLibrary);
}

可以看到如果是 library module，我們會(huì)做特殊的編譯，而不會(huì)生成真正的實(shí)現(xiàn):

public fun writeBaseClass(forLibrary : Boolean) : String =
 kcode("package ${layoutBinder.`package`};") {
  Scope.reset()
  nl("import android.databinding.Bindable;")
  nl("import android.databinding.DataBindingUtil;")
  nl("import android.databinding.ViewDataBinding;")
  nl("public abstract class $baseClassName extends ViewDataBinding {")
  layoutBinder.sortedTargets.filter{it.id != null}.forEach {
   tab("public final ${it.interfaceClass} ${it.fieldName};")
  }
  nl("")
  tab("protected $baseClassName(android.databinding.DataBindingComponent bindingComponent, android.view.View root_, int localFieldCount") {
   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) {
    val type = ModelAnalyzer.getInstance().applyImports(it.userDefinedType, model.imports)
    tab("public abstract void ${it.setterName}($type ${it.readableName});")
   }
  }
  tab("public static $baseClassName inflate(android.view.LayoutInflater inflater, android.view.ViewGroup root, boolean attachToRoot) {") {
   tab("return inflate(inflater, root, attachToRoot, android.databinding.DataBindingUtil.getDefaultComponent());")
  }
  tab("}")
  tab("public static $baseClassName inflate(android.view.LayoutInflater inflater) {") {
   tab("return inflate(inflater, android.databinding.DataBindingUtil.getDefaultComponent());")
  }
  tab("}")
  tab("public static $baseClassName bind(android.view.View view) {") {
   if (forLibrary) {
    tab("return null;")
   } else {
    tab("return bind(view, android.databinding.DataBindingUtil.getDefaultComponent());")
   }
  }
  tab("}")
  tab("public static $baseClassName inflate(android.view.LayoutInflater inflater, android.view.ViewGroup root, boolean attachToRoot, android.databinding.DataBindingComponent bindingComponent) {") {
   if (forLibrary) {
    tab("return null;")
   } else {
    tab("return DataBindingUtil.<$baseClassName>inflate(inflater, ${layoutBinder.modulePackage}.R.layout.${layoutBinder.layoutname}, root, attachToRoot, bindingComponent);")
   }
  }
  tab("}")
  tab("public static $baseClassName inflate(android.view.LayoutInflater inflater, android.databinding.DataBindingComponent bindingComponent) {") {
   if (forLibrary) {
    tab("return null;")
   } else {
    tab("return DataBindingUtil.<$baseClassName>inflate(inflater, ${layoutBinder.modulePackage}.R.layout.${layoutBinder.layoutname}, null, false, bindingComponent);")
   }
  }
  tab("}")
  tab("public static $baseClassName bind(android.view.View view, android.databinding.DataBindingComponent bindingComponent) {") {
   if (forLibrary) {
    tab("return null;")
   } else {
    tab("return ($baseClassName)bind(bindingComponent, view, ${layoutBinder.modulePackage}.R.layout.${layoutBinder.layoutname});")
   }
  }
  tab("}")
  nl("}")
 }.generate()
}

那么問題來了，這里的這個(gè)只是用來使 library module 編譯能通過的 abstract class，只生成了所有 variable 的 setter 方法啊，getter 呢？坑爹呢？

看來是 Google 壓根沒考慮到還需要這個(gè)。寫 Kotlin 的都少根筋嗎？

規(guī)避方案

為了讓 library module 能編譯通過（這樣才能在 application module 生成真正的 Binding 實(shí)現(xiàn)），只好避免使用 getter 方法，幸而通過之前開發(fā)的 DataBindingAdapter 和 lambda presenter 確實(shí)能規(guī)避使用 getter 去拿 viewmodel。

不管怎么說，希望 Google 能在下個(gè)版本修復(fù)這個(gè)問題。就是 iterator 一下，寫個(gè) abstract 接口而已。

感謝閱讀，希望能幫助到大家，謝謝大家對(duì)本站的支持！

您可能感興趣的文章: