有data binding之後，早先的Android應用架構還有用處嗎？

01-05

聲明：我的問題並不是認為「早先的Android應用架構沒有用處了」，而是我架構知識薄弱，所以確確實實產生了這種疑問。
Android的架構一直是比較麻煩的事情。Google也似乎沒有很上心，沒有指明方向。

客戶端開發以界面為核心。邏輯，數據，都不會太多。
而服務端可能是以邏輯或數據為核心的。這是很大的不同了。
後來網上有大神們開始推薦Android Flux。也就是Flux運用到Android上。似乎不錯。

看了看。想要用手上已經使用data binding的項目改造一下，使用Android Flux。
但改造過程中覺得有data binding之後，flux似乎有點雞肋（可能是我的經驗不足以理解flux真正的意義）。
覺得data binding已經解決了最麻煩的問題，使用了data binding之後，之前流行用於android app上的架構還有用嗎？

ps.android studio 2 已經進一步加入了對data binding的支持。比如xml調用各種代碼方便很多了。

目測我司 Android 團隊是國內第一個把 Flux for Android 實際應用到項目里的，前些天聽 @劉照雲講，去年他也用 Flux 幫人做了個應用，不過沒上線，我們現在是在用 Flux 重構，基本已經重構完成了。然後就是各種測試灰度了，再然後就上線了。所以還是第一個，嘎嘎！將近二十人的 Android 團隊，要引入一種全新的架構，還要確定粒度的每一個細節，真的挺不容易的。

在此之前，都是一直在寫 MVP，MVVM ，真正寫過的人會發現，其實並沒有哪一種架構（句子較長，手動停頓）是真正能夠完全徹底解決（句子較長，手動停頓）你在做任何一個 APP 所遇到的全部架構方面的問題的。MVP 的問題就不說了，MVVM 要求引入一個框架做綁定，不利於 View 的復用，也不好做複雜的狀態改變和交互處理；將 Flux 里的 Store 寫的很臃腫也是常見的事，還有為人詬病的 waitFor 。每一個問題，都讓人很頭疼。而至少我看到的現象，MVP 在 Android 開發圈子裡有被神化的趨勢。

任何一種技術的出現都是為了解決問題的，而不是為了創造出其他的問題，或者在解決一個問題的同時創造了另外的問題。應用簡單了，愛怎麼寫就怎麼寫，應用複雜了，就要分模塊，具體到每一個模塊，仍然是簡單的模塊，愛怎麼寫就怎麼寫（希望不要有人曲解我的意思）。

就連 MVP 本身，人們在爭論 Activity 到底是作為 View 還是作為 Presenter ，repository 到底是在 Model 里合適還是在 Presenter 里合適，我們還需要糾結到底哪種架構更有用，更適合 Android 開發嗎？不要被某一種架構局限了自己了思維。MVP 完全可以和 MVVM ，Flux 配合起來使用。

最後還要提一下，道理是這麼個道理，我個人還是更傾向於 Flux ，所以還是要吹一波。單向數據流讓調試變得極其容易，即便是第一次接觸到一份代碼，遇到了數據上的錯誤，也會非常容易的定位問題，更新狀態的元素只有唯一的一個 Store ，各個模塊高度解耦。當然，我們自己也在實踐，還沒經過嚴格的測試，對於 Flux 的單元測試也沒有定下來一個比較好的方案，等再過一段時間，相關方面有了更多的成果了，可以再分享。真正寫起來也要有自己的約束，官方的 Todo App 太過簡單，參考價值也不大，真正要用起來，還是得自己多寫多練。

最最後，還要說一句，不要再跟我問我 Flux 到底比 MVP ，MVVM 好到哪兒了，爭來爭去也不會有個結果，最後搞得大家都很煩。用什麼技術不是目的，解決問題才是目的。

從 Google 官方在 IO 大會上開源的 APP： GitHub - google/iosched: The Google I/O 2015 Android App

以及一群 Google 開發者維護的這個關於 Android 開發架構的 Collection：GitHub - googlesamples/android-architecture: A collection of samples to discuss and showcase different architectural tools and patterns for Android apps.

可以看出來，目前更流行的架構是 MVP，iosched 中更用 Fragment 來構建 Presenter，有很多值得學習的地方。

至於 MVVM，應該會有局限性的一些問題，Flux 的話思想很好，但是我沒看到比較好的具體實現，Github 上的一些 Sample 都太簡單了。

在 Web 前端世界裡 Redux 很火（Flux 的一種實現），Reducer 的概念設計得很好，給定 Action 和舊的 State 總能得到唯一的新的 State，它不改變外部變數（無副作用），是 Pure Function。這意味著我們只要給 View 設定好初始的狀態（State），然後將用戶的操作（Action）一同扔給 Reducer 總能返回新的唯一的 View State。

不過 MVVM 和 Flux 我都沒嘗試過，也不知道具體實現時會遇到哪些的細節問題，但如果對 MVP 架構有興趣的話，可以關注我的專欄 http://zhuanlan.zhihu.com/kotandroid 來一起探討一下。

其他框架基本上沒多大用處了，MVVM模式開發代碼更為優雅。不但徹底擺脫findview的噩夢，雙向數據綁定也大大加快了開發效率。且databinding由google官方支持，實在想不出什麼理由用其他的開發框架。

部分贊同一樓的答案，但要說"MVP 完全可以和 MVVM一起使用"就有顯得蛋疼了，就像你買了個藍光的光碟，還需要再買DVD嗎?

1. Android官方的DataBinding並不完善，甚至不好用，比如需要自己實現雙向綁定（這個不用有什麼區別）

2. MVVM又不是現在才有，第三方有很多可取的，比如Rx等

3. iOS上的MVVM比現階段Android的更成熟，但目前更多的還是MVP，就更不提替代了

4. 適合自己的才是最好的

之前很多問題都完善了，最新版的databinding還不錯。

但是還有個問題，感覺這個設計在處理同一個xml里有多個實體model，多個model又包含相同的欄位的時候，並不友好。目前好像只能綁定一個，而我想在用戶選擇改變某個textview的值之後，去改變兩個或更多個model里的值，這個暫時好像做不到。只能夠在代碼里binding.getxxx然後賦予別的model，這樣的話在這一步就失去了databinding的意義。

希望以後能有一個view-&>multi-model的的賦值~

可以了解下官方的MVP samples，有一個mvp-databinding，

https://github.com/googlesamples/android-architecture

不管什麼框架，用不用框架，主要看適不適合自己