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

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

Library module 生成 class

在 library module 下啟用 Data Binding 很簡單，跟 application module 一樣，加上:

對應生成的 binding 類會在 manifest 里面指定的 package name 下的 databinding 包下。

坑

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

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

WTF?!

What happened

Fuck 歸 fuck，究竟怎么回事還是要研究一下的。

是我們姿勢錯了？Dagger2 生成哪里出問題了？還是 Data Binding 的 bug 呢？

因為之前也研究過 data binding 生成部分的代碼，所以找到問題所在沒有花太多時間，這里不多啰嗦，直接看對應位置。

在 CompilerChief 的 writeViewBinderInterfaces 中:

對應 DataBinder:

這里調用了 LayoutBinder（真正的實現類會調用 writeViewBinder）:

可以看到如果是 library module，我們會做特殊的編譯，而不會生成真正的實現:

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

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

規避方案

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

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