在 Android 中實現 Redux 的一點經驗

簡評:Redux 是一個用於應用程序狀態管理的開源JavaScript庫,其核心是通過可管理和控制的狀態來描述一個系統。這意味著其思想其實是可以應用於任何類型應用的開發的,包括移動應用。

Redux 架構基於一個嚴格的單向數據流,應用中的所有數據都是通過組件在一個方向上流動。Redux 希望確保應用的視圖是根據確定的狀態來呈現的。意思就是,在任何時間點,你應用的狀態總是確定、有效的,並且可以轉換到另一個可預測和有效的狀態。而 UI 將根據所處的狀態來進行呈現。

關於 Redux 在網上已經有很多相關的資料,這裡就只介紹下 Redux 核心的三個組件:

1. Store:保存應用的狀態並提供一些幫助方法來存取狀態,分髮狀態以及註冊監聽。

2. Actions:簡單說 Actions 就是事件,包含要傳遞給 store 的信息,表明我們希望怎樣改變應用的狀態。比如,定義如下的一個 action:

data class AddTodoAction(val text: String)

由 store 來進行分發:

store.dispatch(AddTodoAction("Write blog post"))

3. Reducers:進行狀態的轉變。類似這樣:

fun reduce(oldState: AppState, action: Action) : AppState { return when (action) { is AddToDoAction -> { oldState.copy(todo = ...) } else -> oldState }}

介紹完核心組件,下面來看一下它們是怎麼組合到一起的:

Redux flow

Redux 的流程很簡單,你的應用根據當前狀態呈現 UI,用戶的交互觸發 action,並交給 reducer 來更新狀態。

最近,作者在一個還挺大的項目上試了下 Redux 架構,所以這裡就分享下從中總結的一些經驗。

1. 應用里最好不要有多個 store

針對不同模塊有不同的 store 似乎是個不錯的主意,但從上面的圖可以看到每個 store 和其數據流是一個閉環系統,這就使得不同 store 之間的狀態難以同步。這樣你就通常需要在一個狀態的變更響應中去進行另一個 store 的 action 分發,而這很容易造成無限循環。

另一個原因是多 store 的架構是非常僵化的,難以靈活的改動。

更好的做法是維護一個包含多個子狀態的全局應用狀態,由一個 store 來表示:

data class AppState(val LoginState, val HomeScreenState, val GridState )

2. 保持應用的狀態層級儘可能少

因為 Redux 中 state 是不可變的,因此深層次嵌套的 state 會產生很多的樣板代碼,並且難以更新。比如,考慮下面的一組數據模型:

data class State(val sections: List<Section>)open class Section(val articles: List<Article>)class Home(articles: List<Article>) : Section(articles)class Discover(articles: List<Article>) : Section(articles)class Article

實例化和更新狀態對象:

val state = State(sections = listOf( Home(listOf(article1, article2)), Discover(listOf(article1, article2))))

即使是用了 Kotlin 的 copy 機制,更新深層嵌套的屬性(比如上面的 Article)也是非常單調乏味的:

val newHome = Home(listOf(newArticle, state.sections[0].articles[1]))state.copy(sections = listOf(newHome, state.sections[1]))

3. Reducers 只是純函數

Reduce 的作用只是處理 action 並返回新的 state 到 store 的,需要保證相同的輸入總會得到一樣的輸出。Reduce 自身不應該有狀態和執行任何額外工作,而只是做狀態轉換。

class Reducer { fun reduce(state: State, action: Action) : State { ... }}

如果你需要響應某個 action,並執行一些操作,那應該考慮使用 Middleware。

4. 只用 Kotlin

Redux 很大部分受到 Flux 的啟發,而關於 Flux 最常見的抱怨就是需要寫一大堆的樣板代碼。而所選擇的語言很大程度會決定你管理樣板代碼的便利性。

Kotlin 中類似 data class,when 語句之類的特性,能讓你的代碼清晰很多。例如,在 Reducer 中匹配 action 時,可以選擇用 instanceof 方法實現。

if (action instanceof AddTodoAction) { return reduceAddTodoAction(oldState, action);} else if (action instanceof RemoveTodoAction) { return reduceRemoveTodoAction(oldState, action);} else if (...) { ...}return oldState;

當 action 很多時,這種寫法就很痛苦了。如果用 Kotlin 就是這樣的:

return when (action) { is AddTodoAction -> reduceAddTodoAction(oldState, action) is RemoveTodoAction -> reduceRemoveTodoAction(oldState, action) else -> oldState}

結論

雖然,Redux 主要是被用於 Web 應用開發,但其思想我們還是可以學習並引入到 Android 中。但 Redux 也不是「銀彈」,事實上也沒有什麼架構是,其在 Android 上的應用還很新,但我們還是很希望能看到它的逐漸成熟。

如果你對 Redux 在 Android 上運用有興趣,可以看看 Redux 和 ReKotlin 這兩個庫。

原文:Lessons learned implementing Redux on Android - Pusher Blog

日報擴展閱讀:

  • 用 ConstraintLayout 和 ConstraintSet 實現 Android 關鍵幀動畫

推薦閱讀:

從 SQLite 逐步遷移到 Room
千元機和旗艦機相比,究竟哪裡縮水了?
Android應用程序通用自動脫殼方法研究

TAG:Android | Android开发 |