對於開發來說，其實應該遵從兩點，對於好的產品和代碼就必須承認是好的，對於不認同的就是認爲像狗屎一樣
一、 一千個人心中可以有一千個哈姆萊特，但技術它不行！
任何事物都不是唯一的，大家都可以有自己的想法，我也是認同的，但是技術方面，不能是這樣也不會是這樣的
1.1 本文想說點什麼？
- Databinding
- Databinding 帶給開發的快感
- Databinding 帶來的影響
- kotlin 和jetpack 下Databinding 存在的意義
1.1.1 Databinding
Databinding 是谷歌官方發佈的一個基於頁面數據和業務邏輯分離、直接在頁面佈局中綁定數據的MVVM框架，可以直接在xml中綁定數據、綁定事件、進行邏輯處理、進行數據雙向綁定… 減少findViewById代碼等
1.1.2 在實際的開發中那些功能是重要的呢？
- 減少findViewById()
- 直接數據綁定xml 與控制層業務分離
- …
當然 Databinding的出現是具有時代意義的，是google出的對於MVVM 數據分離的官方框架，但是我在之前是沒有使用的，後來在去結合kotlin和jetpack以及別人開發中總結出來的Databinding的缺點，我是不建議使用Databinding 的，爲什麼呢？
1.1.3 Databinding 帶給開發的影響
首先；在過去的開發中，總結性的將開發的模式大致分爲：
- 開發模式
- MVC
- MVP
- MVVM
- 混合使用
- 框架使用
- 模塊化
- 組件化
- 插件化
爲什麼說以上兩個呢？因爲他們和Databinding 的實際應用是密不可分的
對於開發模式來說最終的目的就是爲了使業務層和數據層的分離，就是對於耦合度的解耦，使業務更加明確、清晰
對於框架來說決定着以後開發的模式、
- 按部就班的傳統項目
之前剛開始的時候是沒有使用框架的，直接是在一個項目中一股腦的寫，經常會出現代碼修改重複、編譯超級慢、需求變動影響大，對於新增的需求還好、對於刪除的不確定需求來說簡直就是噩夢，代碼管理中全是各種版本。
- 模塊化
後續出現了模塊化的開發，將一個項目發展爲各種功能獨立的模塊，然後依賴到主模塊中，這樣就解決了需求刪改等問題，項目也可以由多人開發，每個開發的模塊之間的每個人都需要一個host才能運行
把常用的功能、控件、基礎類、第三方庫、權限、資源等公共的部分全部分離出來，然後讓所有的業務組件之間相互依賴
- 組件化
組件化將一個app的代碼拆分成獨立的幾個組件，組件之間低耦合、可以單獨編譯打包、也可以將多個組件打包到一個apk
- 插件化
將一個apk根據業務功能拆分成不同的子apk，每個子apk獨立編譯打包，最後發佈上線的是集成後的apk 。在使用插件的時候都是動態加載的，插件也可以進行熱修復、更新等
⚠️ 爲什麼要扯這些呢？
因爲在多模塊開發的使用Databinding 會出現問題
- 子模塊使用了DataBinding 那麼主模塊必須在gradle裏面配置databinding
- 主模塊和子模塊添加上databinding 的配置，在編譯的時候子模塊xml產生的Binding類除了自己的build裏面會有在主模塊下也會有一份，
- 主模塊和子模塊的佈局文件名稱一樣的時候，主模塊生成的Binding 類就是子模塊文件生成的
- 子模塊的某個xml文件使用一些第三方的控件，主模塊由於也會生成這個類的Binding類，那豬模塊就需要引入同樣的引用
說完這些還有嗎？
- 首先編譯延遲
在編譯時我們需要每次進行rebuild 之後才能使用我們本次添加後的Binding類
- 佈局文件變得複雜
- 代碼的可讀性變得比較差
1.1.4 kotlin 和jetpack 下Databinding 存在的意義
那在目前kotlin的大趨勢下，再加上google出的開發框架，我們還需要DataBinding嗎？
- kotlin xml中的組建的id 直接使用kotlinx 引入，比Databingding更加簡單易用
- jetpack 中的ViewModel、Lifecycles、ViewModel 等，在多個角度對耦合度解耦提供了很大的幫助，特別是viewModel數據變化監聽，完全能和DataBinding的數據綁定媲美，並且對於數據和生命週期的管理非常智能
當然DataBinding火及一時，之前是有很多項目使用到的，假如需要，我們需要維護，好好學習一下