背景

在使用 Flutter 開(kāi)發(fā)過(guò)程中，我們遇到了業(yè)務(wù)代碼耦合嚴(yán)重，代碼可維護(hù)性糟糕，如入泥濘。對(duì)于閑魚(yú)這樣的負(fù)責(zé)業(yè)務(wù)場(chǎng)景，我們需要一個(gè)統(tǒng)一的應(yīng)用框架來(lái)擺脫當(dāng)下的開(kāi)發(fā)困境，而這也是 Flutter 領(lǐng)域空缺的一塊。

Fish Redux 是為解決上面問(wèn)題上層應(yīng)用框架，它是一個(gè)基于 Redux 數(shù)據(jù)管理的組裝式 flutter 應(yīng)用框架， 特別適用于構(gòu)建中大型的復(fù)雜應(yīng)用。

它的一大特點(diǎn)是配置式組裝， 一方面將一個(gè)大的頁(yè)面，對(duì)視圖和數(shù)據(jù)層層拆解為互相獨(dú)立的 Component|Adapter，上層負(fù)責(zé)組裝，下層負(fù)責(zé)實(shí)現(xiàn)，另一方面將 Component|Adapter 拆分為 View，Reducer，Effect 等相互獨(dú)立的上下文無(wú)關(guān)函數(shù)。所以它會(huì)非常干凈，易編寫(xiě)、易維護(hù)、易協(xié)作。

Fish Redux 的靈感主要來(lái)自于 Redux、React、Elm、Dva 這樣的優(yōu)秀框架，而 Fish Redux 站在巨人的肩膀上，將集中，分治，復(fù)用，隔離做的更進(jìn)一步。

分層架構(gòu)圖

架構(gòu)圖，主體自底而上，分三層，每一層用來(lái)解決不通層面的問(wèn)題和矛盾，下面依次來(lái)展開(kāi)。

Redux

• Redux 是來(lái)自前端社區(qū)的一個(gè)數(shù)據(jù)管理框架， 對(duì) Native 開(kāi)發(fā)同學(xué)來(lái)說(shuō)可能會(huì)有一點(diǎn)陌生，我們做一個(gè)簡(jiǎn)單的介紹。

Redux 做什么的？

• Redux 是一個(gè)用來(lái)做可預(yù)測(cè)易調(diào)試的數(shù)據(jù)管理的框架。所有對(duì)數(shù)據(jù)的增刪改查等操作都由 Redux 來(lái)集中負(fù)責(zé)。

Redux 是怎么設(shè)計(jì)和實(shí)現(xiàn)的？

• Redux 是一個(gè)函數(shù)式的數(shù)據(jù)管理的框架。

傳統(tǒng) OOP 做數(shù)據(jù)管理，往往是定義一些 Bean，每一個(gè) Bean 對(duì)外暴露一些 Public-API 用來(lái)操作內(nèi)部數(shù)據(jù)（充血模型）。
函數(shù)式的做法是更上一個(gè)抽象的緯度，對(duì)數(shù)據(jù)的定義是一些 Struct（貧血模型），而操作數(shù)據(jù)的方法都統(tǒng)一到具有相同函數(shù)簽名 (T, Action) => T 的 Reducer 中。
FP:Struct（貧血模型） + Reducer = OOP:Bean（充血模型）
同時(shí) Redux 加上了 FP 中常用的 Middleware（AOP） 模式和 Subscribe 機(jī)制，給框架帶了極高的靈活性和擴(kuò)展性。
貧血模型、充血模型 參考：
[https://en.wikipedia.org/wiki/Plain_old_Java_object](https://en.wikipedia.org/wiki/Plain_old_Java_object)

Redux 的缺點(diǎn)

• Redux 核心僅僅關(guān)心數(shù)據(jù)管理，不關(guān)心具體什么場(chǎng)景來(lái)使用它，這是它的優(yōu)點(diǎn)同時(shí)也是它的缺點(diǎn)。
• 在我們實(shí)際使用 Redux 中面臨兩個(gè)具體問(wèn)題
• Redux 的集中和 Component 的分治之間的矛盾。
• Redux 的 Reducer 需要一層層手動(dòng)組裝，帶來(lái)的繁瑣性和易錯(cuò)性。

Fish Redux 的改良

Fish Redux 通過(guò) Redux 做集中化的可觀察的數(shù)據(jù)管理。然不僅于此，對(duì)于傳統(tǒng) Redux 在使用層面上的缺點(diǎn)，在面向端側(cè) flutter 頁(yè)面緯度開(kāi)發(fā)的場(chǎng)景中，我們通過(guò)更好更高的抽象，做了改良。

一個(gè)組件需要定義一個(gè)數(shù)據(jù)（Struct）和一個(gè) Reducer。同時(shí)組件之間存在著父依賴(lài)子的關(guān)系。通過(guò)這層依賴(lài)關(guān)系，

我們解決了【集中】和【分治】之間的矛盾，同時(shí)對(duì) Reducer 的手動(dòng)層層 Combine 變成由框架自動(dòng)完成，大大簡(jiǎn)化了使用 Redux 的困難。

我們得到了理想的集中的效果和分治的代碼。

對(duì)社區(qū)標(biāo)準(zhǔn)的 follow

• State、Action、Reducer、Store、Middleware 以上概念和社區(qū)的 ReduxJS 是完全一致的。我們將原汁原味地保留所有的 Redux 的優(yōu)勢(shì)。
• 如果想對(duì) Redux 有更近一步的理解，請(qǐng)參考 https://github.com/reduxjs/redux

Component

組件是對(duì)局部的展示和功能的封裝。 基于 Redux 的原則，我們對(duì)功能細(xì)分為修改數(shù)據(jù)的功能(Reducer)和非修改數(shù)據(jù)的功能(副作用 Effect)。

于是我們得到了，View、 Effect、Reducer 三部分，稱(chēng)之為組件的三要素，分別負(fù)責(zé)了組件的展示、非修改數(shù)據(jù)的行為、修改數(shù)據(jù)的行為。

這是一種面向當(dāng)下，也面向未來(lái)的拆分。在面向當(dāng)下的 Redux 看來(lái)，是數(shù)據(jù)管理和其他。在面向未來(lái)的 UI-Automation 看來(lái)是 UI 表達(dá)和其他。

UI 的表達(dá)對(duì)程序員而言即將進(jìn)入黑盒時(shí)代，研發(fā)工程師們會(huì)把更多的精力放在非修改數(shù)據(jù)的行為、修改數(shù)據(jù)的行為上。

組件是對(duì)視圖的分治，也是對(duì)數(shù)據(jù)的分治。通過(guò)逐層分治，我們將復(fù)雜的頁(yè)面和數(shù)據(jù)切分為相互獨(dú)立的小模塊。這將利于團(tuán)隊(duì)內(nèi)的協(xié)作開(kāi)發(fā)。

關(guān)于 View

View 僅僅是一個(gè)函數(shù)簽名: (T,Dispatch,ViewService) => Widget

它主要包含三方面的信息

• 視圖是完全由數(shù)據(jù)驅(qū)動(dòng)。
• 視圖產(chǎn)生的事件／回調(diào)，通過(guò) Dispatch 發(fā)出“意圖”，不做具體的實(shí)現(xiàn)。
• 需要用到的組件依賴(lài)等，通過(guò) ViewService 標(biāo)準(zhǔn)化調(diào)用。

比如一個(gè)典型的符合 View 簽名的函數(shù)![image.png](https://img.alicdn.com/tfs/TB1ymUNCgHqK1RjSZFPXXcwapXa-1198-1098.png) 

關(guān)于 Effect

Effect 是對(duì)非修改數(shù)據(jù)行為的標(biāo)準(zhǔn)定義，它是一個(gè)函數(shù)簽名: (Context, Action) => Object

它主要包含四方面的信息

• 接收來(lái)自 View 的“意圖”，也包括對(duì)應(yīng)的生命周期的回調(diào)，然后做出具體的執(zhí)行。
• 它的處理可能是一個(gè)異步函數(shù)，數(shù)據(jù)可能在過(guò)程中被修改，所以我們不崇尚持有數(shù)據(jù)，而通過(guò)上下文來(lái)獲取新數(shù)據(jù)。
• 它不修改數(shù)據(jù)， 如果修要，應(yīng)該發(fā)一個(gè) Action 到 Reducer 里去處理。
• 它的返回值僅限于 bool or Future， 對(duì)應(yīng)支持同步函數(shù)和協(xié)程的處理流程。

比如：良好的協(xié)程的支持![image.png](https://img.alicdn.com/tfs/TB1bTgVChYaK1RjSZFnXXa80pXa-1256-944.png)

關(guān)于 Reducer

Reducer 是一個(gè)完全符合 Redux 規(guī)范的函數(shù)簽名:(T,Action) => T

一些符合簽名的 Reducer

同時(shí)我們以顯式配置的方式來(lái)完成大組件所依賴(lài)的小組件、適配器的注冊(cè)，這份依賴(lài)配置稱(chēng)之為 Dependencies。

所以有這樣的公式 Component = View + Effect(可選) + Reducer(可選) + Dependencies(可選)。

一個(gè)典型的組裝

通過(guò) Component 的抽象，我們得到了完整的分治，多緯度的復(fù)用，更好的解耦。

Adapter

Adapter 也是對(duì)局部的展示和功能的封裝。它為 ListView 高性能場(chǎng)景而生，它是 Component 實(shí)現(xiàn)上的一種變化。

• 它的目標(biāo)是解決 Component 模型在 flutter-ListView 的場(chǎng)景下的 3 個(gè)問(wèn)題
• 1）將一個(gè)"Big-Cell"放在 Component 里，無(wú)法享受 ListView 代碼的性能優(yōu)化。
• 2）Component 無(wú)法區(qū)分 appear|disappear 和 init|dispose 。
• 3）Effect 的生命周期和 View 的耦合，在 ListView 的場(chǎng)景下不符合直觀的預(yù)期。

概括的講，我們想要一個(gè)邏輯上的 ScrollView，性能上的 ListView ，這樣的一種局部展示和功能封裝的抽象。
做出這樣獨(dú)立一層的抽象是，
我們看實(shí)際的效果， 我們對(duì)頁(yè)面不使用框架，使用框架 Component，使用框架 Component+Adapter 的性能基線對(duì)比

• Reducer is long-lived, Effect is medium-lived, View is short-lived.
• 我們通過(guò)不斷的測(cè)試做對(duì)比，以某 android 機(jī)為例：
• 使用框架前 我們的詳情頁(yè)面的 FPS，基線在 52FPS。
• 使用框架， 僅使用 Component 抽象下，F(xiàn)PS 下降到 40， 遭遇“Big-Cell”的陷阱。
• 使用框架，同時(shí)使用 Adapter 抽象后，F(xiàn)PS 提升到 53，回到基線以上，有小幅度的提升。

Directory

推薦的目錄結(jié)構(gòu)會(huì)是這樣

sample_page
-- action.dart
-- page.dart
-- view.dart
-- effect.dart
-- reducer.dart
-- state.dart
components
sample_component
-- action.dart
-- component.dart
-- view.dart
-- effect.dart
-- reducer.dart
-- state.dart

上層負(fù)責(zé)組裝，下層負(fù)責(zé)實(shí)現(xiàn), 同時(shí)會(huì)有一個(gè)插件提供， 便于我們快速填寫(xiě)。

以閑魚(yú)的詳情場(chǎng)景為例的組裝：

組件和組件之間，組件和容器之間都完全的獨(dú)立。

Communication Mechanism

• 組件|適配器內(nèi)通信
• 組件|適配器間內(nèi)通信

![image.png](https://img.alicdn.com/tfs/TB1GrISCkzoK1RjSZFlXXai4VXa-1846-986.png)
簡(jiǎn)單的描述：采用的是帶有一段優(yōu)先處理的廣播， self-first-broadcast。
發(fā)出的 Action，自己優(yōu)先處理，否則廣播給其他組件和 Redux 處理。
最終我們通過(guò)一個(gè)簡(jiǎn)單而直觀的 dispatch 完成了組件內(nèi)，組件間（父到子，子到父，兄弟間等）的所有的通信訴求。

Refresh Mechanism

數(shù)據(jù)刷新

• 局部數(shù)據(jù)修改，自動(dòng)層層觸發(fā)上層數(shù)據(jù)的淺拷貝，對(duì)上層業(yè)務(wù)代碼是透明的。
• 層層的數(shù)據(jù)的拷貝
• 一方面是對(duì) Redux 數(shù)據(jù)修改的嚴(yán)格的 follow。
• 另一方面也是對(duì)數(shù)據(jù)驅(qū)動(dòng)展示的嚴(yán)格的 follow。

![image.png](https://img.alicdn.com/tfs/TB1BjQLCkvoK1RjSZFNXXcxMVXa-1714-828.png)

視圖刷新

• 扁平化通知到所有組件，組件通過(guò) shouldUpdate 確定自己是否需要刷新

![image.png](https://img.alicdn.com/tfs/TB1PkgHCbPpK1RjSZFFXXa5PpXa-1380-620.png)

優(yōu)點(diǎn)

數(shù)據(jù)的集中管理

• 通過(guò) Redux 做集中化的可觀察的數(shù)據(jù)管理。我們將原汁原味地保留所有的 Redux 的優(yōu)勢(shì)，同時(shí)在 Reducer 的合并上，變成由框架代理自動(dòng)完成，大大簡(jiǎn)化了使用 Redux 的繁瑣度。

組件的分治管理

• 組件既是對(duì)視圖的分治，也是對(duì)數(shù)據(jù)的分治。通過(guò)逐層分治，我們將復(fù)雜的頁(yè)面和數(shù)據(jù)切分為相互獨(dú)立的小模塊。這將利于團(tuán)隊(duì)內(nèi)的協(xié)作開(kāi)發(fā)。

View、Reducer、Effect 隔離

• 將組件拆分成三個(gè)無(wú)狀態(tài)的互不依賴(lài)的函數(shù)。因?yàn)槭菬o(wú)狀態(tài)的函數(shù)，它更易于編寫(xiě)、調(diào)試、測(cè)試、維護(hù)。同時(shí)它帶來(lái)了更多的組合、復(fù)用和創(chuàng)新的可能。

聲明式配置組裝

• 組件、適配器通過(guò)自由的聲明式配置組裝來(lái)完成。包括它的 View、Reducer、Effect 以及它所依賴(lài)的子項(xiàng)。

良好的擴(kuò)展性

• 核心框架保持自己的核心的三層關(guān)注點(diǎn)，不做核心關(guān)注點(diǎn)以外的事情，同時(shí)對(duì)上層保持了靈活的擴(kuò)展性。
• 框架甚至沒(méi)有任何的一行的打印的代碼，但我們可通過(guò)標(biāo)準(zhǔn)的 Middleware 來(lái)觀察到數(shù)據(jù)的流動(dòng)，組件的變化。
• 在框架的核心三層外，也可以通過(guò) dart 的語(yǔ)言特性 為 Component 或者 Adapter 添加 mixin，來(lái)靈活的組合式地增強(qiáng)他們的上層使用上的定制和能力。
• 框架和其他中間件的打通，諸如自動(dòng)曝光、高可用等，各中間件和框架之間都是透明的，由上層自由組裝。

精小、簡(jiǎn)單、完備

• 它非常小，僅僅包含 1000 多行代碼。
• 它使用簡(jiǎn)單，完成幾個(gè)小的函數(shù)，完成組裝，即可運(yùn)行。
• 它是完備的。

Fish Redux 目前已在阿里巴巴閑魚(yú)技術(shù)團(tuán)隊(duì)內(nèi)多場(chǎng)景，深入應(yīng)用。