Facebook移動架構：Android Flux架構詳解

要為Android應用找到一個好的架構不是一件容易的事情。谷歌似乎不太在乎這個事情，因此在設計模式上，除了Activity 生命周期管理之外，再也沒有官方的推薦。

但是，為你的應用打造一個架構是非常重要的。不管你是否喜歡，任何應用最終都會有一個架構。因此你最好是成為一個架構的奠基人，而不是等著它出現。

今天: Clean Architecture

目前的趨勢是采用Uncle Bob在2012年對web應用提出的建議： Clean Architecture。

但是我發現Clean Architecture對於絕大多數安卓應用來說都有點過度設計了。

通常移動應用要比web應用的生命短。移動端技術的發展太快，以至於今天發行的app可能在一年後已經完全過時。

移動應用所做的事情很少。絕大多數的用例都只是數據信息流的消費。從API獲取數據，顯示數據給用戶，很少有輸入與寫入。

所以它的業務邏輯並不復雜。至少不如後端一樣的復雜。雖然你要處理很多平台上的問題：內存，存儲，暫停，恢復，網絡，定位等等，但是這些都不是業務邏輯。所有app都有這些東西。

因此，絕大多數app似乎都無法從類似於復雜的分層或者工作執行優先級隊列中獲益。

他們也許只是需要一種組織代碼的簡單方式，能高效的一起工作，更容易的發現bug。

Flux 架構介紹

Flux 架構 被Facebook使用來構建他們的客戶端web應用。跟Clean Architecture一樣，它不是為移動應用設計的，但是它的特性和簡單可以讓我們很好的在安卓項目中采用。

要理解Flux，有兩個關鍵的特點

• 數據流總是單向的一個單向的數據流 是 Flux 架構的核心，也是它簡單易學的原因。就如下面討論的，在進行應用測試的時候，它提供了非常大的幫助。
• 應用被分成三個主要部分：
  • View: 應用的界面。這裡創建響應用戶操作的action。
  • Dispatcher: 中心樞紐，傳遞所有的action，負責把它們運達每個Store。
  • Store: 維護一個特定application domain的狀態。它們根據當前狀態響應action，執行業務邏輯，同時在完成的時候發出一個change事件。這個事件用於view更新其界面。

這三個部分都是通過Action來通信的：一個簡單的基本對象，以類型來區分，包含了和操作相關的數據。

Flux Android 架構

在Android開發中使用Flux設計規范的目的是建立一個在簡單性與易擴展易測試之間都比較平衡的架構。

第一步是找到Flux元素和安卓app組件之間的映射。

其中兩個元素非常容易找到與實現。

• View: Activity o或者Fragment
• Dispatcher: 一個事件總線（ event bus），在我的例子中將使用Otto，但是其它任何實現都應該是ok的。

Actions

Actions也不復雜。它們的實現和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的狀態與它的業務邏輯。它們類似於rich data models但是可以管理多個對象的狀態，而不僅僅是一個對象。

Stores響應Dispatcher發出的Action，執行業務邏輯並發送change事件。

Stores的唯一輸出是這單一的事件：change。其它對Store內部狀態感興趣的組件必須監聽這個事件，同時使用它獲取需要的數據。

系統中不再需要任何其它組建去了解application的任何狀態信息。

最後，stores必須對外公開一個獲取application狀態的接口。這樣，view元素可以查詢Stores然後相應的更新UI。

比如，在一個Pub Discovery App 中，SearchStore被用來跟蹤被搜索的item，搜索結果以及搜索歷史。在同一個應用中，一個ReviewedStore同樣包含了浏覽pub的列表以及必要的邏輯比如根據review排序。

但是有一個重要的概念需要記住：Stores並不是倉庫。它們的職責不是從一個外部源（API或者數據庫）獲取數據，而是跟蹤actions提供的數據。

那麼，Flux application是如何獲得數據的呢？

網絡請求與異步調用

在第一幅Flux示意圖中我有意跳過了一部分：網絡調用。接下來的示意圖完善第一幅圖並添加了更多細節：

異步網絡調用是被一個Actions Creator觸發的。一個Network 適配器完成相應API的異步調用並且返回結果給Actions Creator。

最終Actions Creator分發帶有返回數據的相應類型的Action。

把所有網絡工作和異步工作獨立於Stores之外有兩個主要的優點：

• 你的Stores是完全同步的：這讓Store中的邏輯更容易跟蹤。Bug也更容易跟蹤。同時，因為所有的狀態變化都是同步的，那麼Store的測試變會的非常簡單：啟動actions然後等待期望的結果。
• 所有的action都是從一個Action Creator觸發的：在一處單一的點創建與發起所有用戶操作可以大大簡化尋找錯誤的過程。忘掉在多個類中尋找某個操作的源頭吧 ，所有的事情都是在這裡發生的。同時，因為異步調用發生在這之前，所有來自於ActionCreator的東西都是同步的。這大大提高了代碼的可跟蹤與可測試性。

演示代碼：To－Do應用

在這個例子中，你將看到一個使用Flux架構的典型的To-Do應用。

我讓項目盡量簡單，只演示這個架構如何能夠產生組織良好的app。

對於實現的一些評價：

• Dispatcher的實現是通過Otto Bus。但是幾乎任何bus都是可以的。Flux架構本身在事件上有一定限制，我在這裡沒有采用。原本Flux的定義中，前一個事件沒有完成之前就開始分發下一個事件是不允許的，會拋出一個異常。為了讓項目簡單，我沒有采用。
• 有一個ActionsCreator類幫助創建Action，並把它們post給Dispatcher。這在Flux中時相當普遍的模式，可以讓事情變的有序。
• Actions類型只是String常量。也許這不是最好的實現，但是它快速並且有助於事情的簡單化。

同樣的還有Actions數據：它們只是以String類型為key，Object為值的HashMap。這會導致Stores中轉換成實際數據的時候發生丑陋的類型轉換。而且顯然這也不是類型安全的，但這也是為了讓我們的例子更好理解。

總結

在安卓應用中其實不存在最佳架構的說法。不過存在適合你當前app的最佳架構。這個架構可以讓你和團隊其他成員協作起來更輕松，按時完成項目，盡可能的保持高質量與較少的bug。

我相信Flux對於以上提到的特點都有很好的支持。

源碼

https://github.com/lgvalle/android-flux-todo-app

擴展閱讀:

• Facebook Flux Overview
• Testing Flux Applications
• Flux architecture Step by Step
• Async Requests and Flux
• Flux and Android

感謝

特別感謝我們的同事Michele Bertoli 花時間向我介紹Flux與校對這篇文章。