要為Android應(yīng)用找到一個(gè)好的架構(gòu)不是一件容易的事情。谷歌似乎不太在乎這個(gè)事情，因此在設(shè)計(jì)模式上，除了Activity 生命周期管理之外，再也沒(méi)有官方的推薦。

但是，為你的應(yīng)用打造一個(gè)架構(gòu)是非常重要的。不管你是否喜歡，任何應(yīng)用最終都會(huì)有一個(gè)架構(gòu)。因此你***是成為一個(gè)架構(gòu)的奠基人，而不是等著它出現(xiàn)。

今天: Clean Architecture

目前的趨勢(shì)是采用Uncle Bob在2012年對(duì)web應(yīng)用提出的建議： Clean Architecture。

但是我發(fā)現(xiàn)Clean Architecture對(duì)于絕大多數(shù)安卓應(yīng)用來(lái)說(shuō)都有點(diǎn)過(guò)度設(shè)計(jì)了。

通常移動(dòng)應(yīng)用要比web應(yīng)用的生命短。移動(dòng)端技術(shù)的發(fā)展太快，以至于今天發(fā)行的app可能在一年后已經(jīng)完全過(guò)時(shí)。

移動(dòng)應(yīng)用所做的事情很少。絕大多數(shù)的用例都只是數(shù)據(jù)信息流的消費(fèi)。從API獲取數(shù)據(jù)，顯示數(shù)據(jù)給用戶，很少有輸入與寫入。

所以它的業(yè)務(wù)邏輯并不復(fù)雜。至少不如后端一樣的復(fù)雜。雖然你要處理很多平臺(tái)上的問(wèn)題：內(nèi)存，存儲(chǔ)，暫停，恢復(fù)，網(wǎng)絡(luò)，定位等等，但是這些都不是業(yè)務(wù)邏輯。所有app都有這些東西。

因此，絕大多數(shù)app似乎都無(wú)法從類似于復(fù)雜的分層或者工作執(zhí)行優(yōu)先級(jí)隊(duì)列中獲益。

他們也許只是需要一種組織代碼的簡(jiǎn)單方式，能高效的一起工作，更容易的發(fā)現(xiàn)bug。

Flux 架構(gòu)介紹

Flux 架構(gòu) 被Facebook使用來(lái)構(gòu)建他們的客戶端web應(yīng)用。跟Clean Architecture一樣，它不是為移動(dòng)應(yīng)用設(shè)計(jì)的，但是它的特性和簡(jiǎn)單可以讓我們很好的在安卓項(xiàng)目中采用。

要理解Flux，有兩個(gè)關(guān)鍵的特點(diǎn)

• 數(shù)據(jù)流總是單向的一個(gè)單向的數(shù)據(jù)流 是 Flux 架構(gòu)的核心，也是它簡(jiǎn)單易學(xué)的原因。就如下面討論的，在進(jìn)行應(yīng)用測(cè)試的時(shí)候，它提供了非常大的幫助。

• 應(yīng)用被分成三個(gè)主要部分：

  • View: 應(yīng)用的界面。這里創(chuàng)建響應(yīng)用戶操作的action。

  • Dispatcher: 中心樞紐，傳遞所有的action，負(fù)責(zé)把它們運(yùn)達(dá)每個(gè)Store。

  • Store: 維護(hù)一個(gè)特定application domain的狀態(tài)。它們根據(jù)當(dāng)前狀態(tài)響應(yīng)action，執(zhí)行業(yè)務(wù)邏輯，同時(shí)在完成的時(shí)候發(fā)出一個(gè)change事件。這個(gè)事件用于view更新其界面。

這三個(gè)部分都是通過(guò)Action來(lái)通信的：一個(gè)簡(jiǎn)單的基本對(duì)象，以類型來(lái)區(qū)分，包含了和操作相關(guān)的數(shù)據(jù)。

Flux Android 架構(gòu)

在Android開發(fā)中使用Flux設(shè)計(jì)規(guī)范的目的是建立一個(gè)在簡(jiǎn)單性與易擴(kuò)展易測(cè)試之間都比較平衡的架構(gòu)。

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

其中兩個(gè)元素非常容易找到與實(shí)現(xiàn)。

• View: Activity o或者Fragment

• Dispatcher: 一個(gè)事件總線（ event bus），在我的例子中將使用Otto，但是其它任何實(shí)現(xiàn)都應(yīng)該是ok的。

Actions

Actions也不復(fù)雜。它們的實(shí)現(xiàn)和POJO一樣簡(jiǎn)單，有兩個(gè)主要屬性：

• Type: 一個(gè)String，定義了事件的類型。

• Data: 一個(gè)map，裝載了本次操作。

比如，一個(gè)顯示用戶詳情的典型action如下：

Bundle data = new Bundle(); 
data.put("USER_ID", id); 
Action action = new ViewAction("SHOW_USER", data);

Stores

這可能是Flux理論中最難的部分。

如果你之前使用過(guò)Clean Architecture，你可能難以接受。因?yàn)镾tores承擔(dān)了原本被分成多層的責(zé)任Stores包含了application的狀態(tài)與它的業(yè)務(wù)邏輯。它們類似于rich data models但是可以管理多個(gè)對(duì)象的狀態(tài)，而不僅僅是一個(gè)對(duì)象。

Stores響應(yīng)Dispatcher發(fā)出的Action，執(zhí)行業(yè)務(wù)邏輯并發(fā)送change事件。

Stores的唯一輸出是這單一的事件：change。其它對(duì)Store內(nèi)部狀態(tài)感興趣的組件必須監(jiān)聽這個(gè)事件，同時(shí)使用它獲取需要的數(shù)據(jù)。

系統(tǒng)中不再需要任何其它組建去了解application的任何狀態(tài)信息。

***，stores必須對(duì)外公開一個(gè)獲取application狀態(tài)的接口。這樣，view元素可以查詢Stores然后相應(yīng)的更新UI。

比如，在一個(gè)Pub Discovery App 中，SearchStore被用來(lái)跟蹤被搜索的item，搜索結(jié)果以及搜索歷史。在同一個(gè)應(yīng)用中，一個(gè)ReviewedStore同樣包含了瀏覽pub的列表以及必要的邏輯比如根據(jù)review排序。

但是有一個(gè)重要的概念需要記?。篠tores并不是倉(cāng)庫(kù)。它們的職責(zé)不是從一個(gè)外部源（API或者數(shù)據(jù)庫(kù)）獲取數(shù)據(jù)，而是跟蹤actions提供的數(shù)據(jù)。

那么，F(xiàn)lux application是如何獲得數(shù)據(jù)的呢？

網(wǎng)絡(luò)請(qǐng)求與異步調(diào)用

在***幅Flux示意圖中我有意跳過(guò)了一部分：網(wǎng)絡(luò)調(diào)用。接下來(lái)的示意圖完善***幅圖并添加了更多細(xì)節(jié)：

異步網(wǎng)絡(luò)調(diào)用是被一個(gè)Actions Creator觸發(fā)的。一個(gè)Network 適配器完成相應(yīng)API的異步調(diào)用并且返回結(jié)果給Actions Creator。

最終Actions Creator分發(fā)帶有返回?cái)?shù)據(jù)的相應(yīng)類型的Action。

把所有網(wǎng)絡(luò)工作和異步工作獨(dú)立于Stores之外有兩個(gè)主要的優(yōu)點(diǎn)：

• 你的Stores是完全同步的：這讓Store中的邏輯更容易跟蹤。Bug也更容易跟蹤。同時(shí)，因?yàn)樗械臓顟B(tài)變化都是同步的，那么Store的測(cè)試變會(huì)的非常簡(jiǎn)單：?jiǎn)?dòng)actions然后等待期望的結(jié)果。

• 所有的action都是從一個(gè)Action Creator觸發(fā)的：在一處單一的點(diǎn)創(chuàng)建與發(fā)起所有用戶操作可以大大簡(jiǎn)化尋找錯(cuò)誤的過(guò)程。忘掉在多個(gè)類中尋找某個(gè)操作的源頭吧 ，所有的事情都是在這里發(fā)生的。同時(shí)，因?yàn)楫惒秸{(diào)用發(fā)生在這之前，所有來(lái)自于ActionCreator的東西都是同步的。這大大提高了代碼的可跟蹤與可 測(cè)試性。

演示代碼：To－Do應(yīng)用

在這個(gè)例子中，你將看到一個(gè)使用Flux架構(gòu)的典型的To-Do應(yīng)用。

我讓項(xiàng)目盡量簡(jiǎn)單，只演示這個(gè)架構(gòu)如何能夠產(chǎn)生組織良好的app。

對(duì)于實(shí)現(xiàn)的一些評(píng)價(jià)：

• Dispatcher的實(shí)現(xiàn)是通過(guò)Otto Bus。但是幾乎任何bus都是可以的。Flux架構(gòu)本身在事件上有一定限制，我在這里沒(méi)有采用。原本Flux的定義中，前一個(gè)事件沒(méi)有完成之前就開始分發(fā)下一個(gè)事件是不允許的，會(huì)拋出一個(gè)異常。為了讓項(xiàng)目簡(jiǎn)單，我沒(méi)有采用。

• 有一個(gè)ActionsCreator類幫助創(chuàng)建Action，并把它們post給Dispatcher。這在Flux中時(shí)相當(dāng)普遍的模式，可以讓事情變的有序。

• Actions類型只是String常量。也許這不是***的實(shí)現(xiàn)，但是它快速并且有助于事情的簡(jiǎn)單化。

同樣的還有Actions數(shù)據(jù)：它們只是以String類型為key，Object為值的HashMap。這會(huì)導(dǎo)致Stores中轉(zhuǎn)換成實(shí)際數(shù)據(jù)的時(shí)候發(fā)生丑陋的類型轉(zhuǎn)換。而且顯然這也不是類型安全的，但這也是為了讓我們的例子更好理解。

總結(jié)

在安卓應(yīng)用中其實(shí)不存在***架構(gòu)的說(shuō)法。不過(guò)存在適合你當(dāng)前app的***架構(gòu)。這個(gè)架構(gòu)可以讓你和團(tuán)隊(duì)其他成員協(xié)作起來(lái)更輕松，按時(shí)完成項(xiàng)目，盡可能的保持高質(zhì)量與較少的bug。

我相信Flux對(duì)于以上提到的特點(diǎn)都有很好的支持。

源碼

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

擴(kuò)展閱讀:

• Facebook Flux Overview

• Testing Flux Applications

• Flux architecture Step by Step

• Async Requests and Flux

• Flux and Android

感謝

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