Facebook移動架構(gòu)：Android Flux架構(gòu)詳解
要為Android應(yīng)用找到一個好的架構(gòu)不是一件容易的事情。谷歌似乎不太在乎這個事情，因此在設(shè)計模式上，除了Activity 生命周期管理之外，再也沒有官方的推薦。
但是，為你的應(yīng)用打造一個架構(gòu)是非常重要的。不管你是否喜歡，任何應(yīng)用最終都會有一個架構(gòu)。因此你***是成為一個架構(gòu)的奠基人，而不是等著它出現(xiàn)。
今天: Clean Architecture
目前的趨勢是采用Uncle Bob在2012年對web應(yīng)用提出的建議： Clean Architecture。
但是我發(fā)現(xiàn)Clean Architecture對于絕大多數(shù)安卓應(yīng)用來說都有點過度設(shè)計了。
通常移動應(yīng)用要比web應(yīng)用的生命短。移動端技術(shù)的發(fā)展太快，以至于今天發(fā)行的app可能在一年后已經(jīng)完全過時。
移動應(yīng)用所做的事情很少。絕大多數(shù)的用例都只是數(shù)據(jù)信息流的消費。從API獲取數(shù)據(jù)，顯示數(shù)據(jù)給用戶，很少有輸入與寫入。
所以它的業(yè)務(wù)邏輯并不復(fù)雜。至少不如后端一樣的復(fù)雜。雖然你要處理很多平臺上的問題：內(nèi)存，存儲，暫停，恢復(fù)，網(wǎng)絡(luò)，定位等等，但是這些都不是業(yè)務(wù)邏輯。所有app都有這些東西。
因此，絕大多數(shù)app似乎都無法從類似于復(fù)雜的分層或者工作執(zhí)行優(yōu)先級隊列中獲益。
他們也許只是需要一種組織代碼的簡單方式，能高效的一起工作，更容易的發(fā)現(xiàn)bug。
Flux 架構(gòu)介紹
Flux 架構(gòu) 被Facebook使用來構(gòu)建他們的客戶端web應(yīng)用。跟Clean Architecture一樣，它不是為移動應(yīng)用設(shè)計的，但是它的特性和簡單可以讓我們很好的在安卓項目中采用。
要理解Flux，有兩個關(guān)鍵的特點
-
數(shù)據(jù)流總是單向的一個單向的數(shù)據(jù)流 是 Flux 架構(gòu)的核心，也是它簡單易學(xué)的原因。就如下面討論的，在進行應(yīng)用測試的時候，它提供了非常大的幫助。
-
應(yīng)用被分成三個主要部分：
-
View: 應(yīng)用的界面。這里創(chuàng)建響應(yīng)用戶操作的action。
-
Dispatcher: 中心樞紐，傳遞所有的action，負責把它們運達每個Store。
-
Store: 維護一個特定application domain的狀態(tài)。它們根據(jù)當前狀態(tài)響應(yīng)action，執(zhí)行業(yè)務(wù)邏輯，同時在完成的時候發(fā)出一個change事件。這個事件用于view更新其界面。
-
這三個部分都是通過Action來通信的：一個簡單的基本對象，以類型來區(qū)分，包含了和操作相關(guān)的數(shù)據(jù)。
Flux Android 架構(gòu)
在Android開發(fā)中使用Flux設(shè)計規(guī)范的目的是建立一個在簡單性與易擴展易測試之間都比較平衡的架構(gòu)。
***步是找到Flux元素和安卓app組件之間的映射。
其中兩個元素非常容易找到與實現(xiàn)。
-
View: Activity o或者Fragment
-
Dispatcher: 一個事件總線（ event bus），在我的例子中將使用Otto，但是其它任何實現(xiàn)都應(yīng)該是ok的。
Actions
Actions也不復(fù)雜。它們的實現(xiàn)和POJO一樣簡單，有兩個主要屬性：
-
Type: 一個String，定義了事件的類型。
-
Data: 一個map，裝載了本次操作。
比如，一個顯示用戶詳情的典型action如下：
Bundle data = new Bundle();
data.put("USER_ID", id);
Action action = new ViewAction("SHOW_USER", data);
Stores
這可能是Flux理論中最難的部分。
如果你之前使用過Clean Architecture，你可能難以接受。因為Stores承擔了原本被分成多層的責任Stores包含了application的狀態(tài)與它的業(yè)務(wù)邏輯。它們類似于rich data models但是可以管理多個對象的狀態(tài)，而不僅僅是一個對象。
Stores響應(yīng)Dispatcher發(fā)出的Action，執(zhí)行業(yè)務(wù)邏輯并發(fā)送change事件。
Stores的唯一輸出是這單一的事件：change。其它對Store內(nèi)部狀態(tài)感興趣的組件必須監(jiān)聽這個事件，同時使用它獲取需要的數(shù)據(jù)。
系統(tǒng)中不再需要任何其它組建去了解application的任何狀態(tài)信息。
***，stores必須對外公開一個獲取application狀態(tài)的接口。這樣，view元素可以查詢Stores然后相應(yīng)的更新UI。
比如，在一個Pub Discovery App 中，SearchStore被用來跟蹤被搜索的item，搜索結(jié)果以及搜索歷史。在同一個應(yīng)用中，一個ReviewedStore同樣包含了瀏覽pub的列表以及必要的邏輯比如根據(jù)review排序。
但是有一個重要的概念需要記住：Stores并不是倉庫。它們的職責不是從一個外部源（API或者數(shù)據(jù)庫）獲取數(shù)據(jù)，而是跟蹤actions提供的數(shù)據(jù)。
那么，F(xiàn)lux application是如何獲得數(shù)據(jù)的呢？
網(wǎng)絡(luò)請求與異步調(diào)用
在***幅Flux示意圖中我有意跳過了一部分：網(wǎng)絡(luò)調(diào)用。接下來的示意圖完善***幅圖并添加了更多細節(jié)：
異步網(wǎng)絡(luò)調(diào)用是被一個Actions Creator觸發(fā)的。一個Network 適配器完成相應(yīng)API的異步調(diào)用并且返回結(jié)果給Actions Creator。
最終Actions Creator分發(fā)帶有返回數(shù)據(jù)的相應(yīng)類型的Action。
把所有網(wǎng)絡(luò)工作和異步工作獨立于Stores之外有兩個主要的優(yōu)點：
-
你的Stores是完全同步的：這讓Store中的邏輯更容易跟蹤。Bug也更容易跟蹤。同時，因為所有的狀態(tài)變化都是同步的，那么Store的測試變會的非常簡單：啟動actions然后等待期望的結(jié)果。
-
所有的action都是從一個Action Creator觸發(fā)的：在一處單一的點創(chuàng)建與發(fā)起所有用戶操作可以大大簡化尋找錯誤的過程。忘掉在多個類中尋找某個操作的源頭吧 ，所有的事情都是在這里發(fā)生的。同時，因為異步調(diào)用發(fā)生在這之前，所有來自于ActionCreator的東西都是同步的。這大大提高了代碼的可跟蹤與可 測試性。
演示代碼：To－Do應(yīng)用
在這個例子中，你將看到一個使用Flux架構(gòu)的典型的To-Do應(yīng)用。
我讓項目盡量簡單，只演示這個架構(gòu)如何能夠產(chǎn)生組織良好的app。
對于實現(xiàn)的一些評價：
-
Dispatcher的實現(xiàn)是通過Otto Bus。但是幾乎任何bus都是可以的。Flux架構(gòu)本身在事件上有一定限制，我在這里沒有采用。原本Flux的定義中，前一個事件沒有完成之前就開始分發(fā)下一個事件是不允許的，會拋出一個異常。為了讓項目簡單，我沒有采用。
-
有一個ActionsCreator類幫助創(chuàng)建Action，并把它們post給Dispatcher。這在Flux中時相當普遍的模式，可以讓事情變的有序。
-
Actions類型只是String常量。也許這不是***的實現(xiàn)，但是它快速并且有助于事情的簡單化。
同樣的還有Actions數(shù)據(jù)：它們只是以String類型為key，Object為值的HashMap。這會導(dǎo)致Stores中轉(zhuǎn)換成實際數(shù)據(jù)的時候發(fā)生丑陋的類型轉(zhuǎn)換。而且顯然這也不是類型安全的，但這也是為了讓我們的例子更好理解。
總結(jié)
在安卓應(yīng)用中其實不存在***架構(gòu)的說法。不過存在適合你當前app的***架構(gòu)。這個架構(gòu)可以讓你和團隊其他成員協(xié)作起來更輕松，按時完成項目，盡可能的保持高質(zhì)量與較少的bug。
我相信Flux對于以上提到的特點都有很好的支持。
源碼
https://github.com/lgvalle/android-flux-todo-app
擴展閱讀:
感謝
特別感謝我們的同事Michele Bertoli 花時間向我介紹Flux與校對這篇文章。
