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與校對這篇文章。