來了！閒魚技術團隊開源 Flutter 應用框架 Fish Redux

阿里技術_發表於2019-03-06

640?wx_fmt=jpeg

阿里妹導讀：目前，跨平臺、高效能的渲染引擎逐漸成為大前端領域的一個熱點。作為其中的明星， Flutter有很大的機會成為下一代主流的跨端解決方案。閒魚技術基於Flutter 深耕，開源了2億使用者背後的Flutter應用框架：Fish Redux。接下來，我們就一起深入解讀 Fish Redux ，瞭解它的函式式的程式設計模型、可預測的狀態管理、可插拔的元件體系、最佳的效能表現。

此外，今天晚上，閒魚工程師將做客阿里技術直播間，與你聊聊移動開發和Fish Redux，歡迎觀看。

開源地址

https://github.com/alibaba/fish-redux

3月6日（週三）晚19:30，歡迎做客阿里技術直播間，深入瞭解閒魚開源 Flutter應用框架：Fish Redux，一起先睹為快！

640?wx_fmt=jpeg

本次直播，你將瞭解到：Flutter及應用框架；應用框架的設計原則和分層架構思想；閒魚的Fish Redux應用框架實踐等精彩內容。

直播觀看方式：

直接觀看：掃描上方圖片二維碼，或點選本文末尾的“閱讀原文”，在瀏覽器中（記住！一定要用瀏覽器開啟，手機或PC均可）開啟直播連結，收藏起來，定好鬧鐘，3月6日（週三）準時觀看。
釘釘群觀看：使用“釘釘”搜尋交流群號 23379655，加入Flutter交流群，既可到時觀看直播，也可與嘉賓、行業同仁互動探討。

640?wx_fmt=png

Fish Redux 是一個基於 Redux 資料管理的組裝式 Flutter 應用框架，特別適用於構建中大型的複雜應用。它的最大特點是配置式組裝，它會非常乾淨，易編寫、易維護、易協作。

Fish Redux 的靈感主要來自於 Redux、React、Elm、Dva 這樣的優秀框架，而 Fish Redux 站在巨人的肩膀上，將集中，分治，複用，隔離做的更進一步。

分層架構圖

架構圖，主體自底而上，分三層，每一層用來解決不同層面的問題和矛盾，下面依次來展開。

Redux

Redux 是來自前端社群的一個資料管理框架，對 Native 開發同學來說可能會有一點陌生，我們做一個簡單的介紹。

Redux做什麼的？

Redux 是一個用來做[可預測][集中式][易除錯][靈活性]的資料管理的框架。所有對資料的增刪改查等操作都由 Redux 來集中負責。

Redux是怎麼設計和實現的？

Redux 是一個函式式的資料管理的框架。傳統 OOP 做資料管理，往往是定義一些 Bean，每一個 Bean 對外暴露一些 Public-API 用來操作內部資料（充血模型）。函式式的做法是更上一個抽象的緯度，對資料的定義是一些 Struct（貧血模型），而運算元據的方法都統一到具有相同函式簽名 (T, Action) => T 的 Reducer 中。

FP：Struct（貧血模型） + Reducer = OOP:Bean（充血模型）同時 Redux 加上了 FP 中常用的 Middleware（AOP）模式和 Subscribe 機制，給框架帶了極高的靈活性和擴充套件性。貧血模型、充血模型參考文末連結。

Redux的缺點？

Redux 核心僅僅關心資料管理，不關心具體什麼場景來使用它，這是它的優點同時也是它的缺點。

在我們實際使用 Redux 中面臨兩個具體問題：

Redux 的集中和 Component 的分治之間的矛盾。
Redux 的 Reducer 需要一層層手動組裝，帶來的繁瑣性和易錯性。

Fish Redux的改良？

Fish Redux 通過 Redux 做集中化的可觀察的資料管理。然不僅於此，對於傳統 Redux 在使用層面上的缺點，在面向端側 Flutter 頁面緯度開發的場景中，我們通過更好更高的抽象，做了改良。

一個元件需要定義一個資料（Struct）和一個 Reducer。同時元件之間存在著父依賴子的關係。通過這層依賴關係，我們解決了“集中”和“分治”之間的矛盾，同時對 Reducer 的手動層層 Combine 變成由框架自動完成，大大簡化了使用 Redux 的困難。我們得到了理想的集中的效果和分治的程式碼。

對社群標準的follow

State、Action、Reducer、Store、Middleware 以上概念和社群的 ReduxJS 是完全一致的。我們將原汁原味地保留所有的 Redux 的優勢。

如果想對 Redux 有更近一步的理解，參考文末連結。

Component

元件是對區域性的展示和功能的封裝。基於 Redux 的原則，我們對功能細分為修改資料的功能(Reducer)和非修改資料的功能(副作用 Effect)。

於是我們得到了，View、 Effect、Reducer 三部分，稱之為元件的三要素，分別負責了元件的展示、非修改資料的行為、修改資料的行為。

這是一種面向當下，也面向未來的拆分。在面向當下的 Redux 看來，是資料管理和其他。在面向未來的 UI-Automation 看來是 UI 表達和其他。

UI 的表達對程式設計師而言即將進入黑盒時代，研發工程師們會把更多的精力放在非修改資料的行為、修改資料的行為上。

元件是對檢視的分治，也是對資料的分治。通過逐層分治，我們將複雜的頁面和資料切分為相互獨立的小模組。這將利於團隊內的協作開發。

關於View

View 僅僅是一個函式簽名:

(T,Dispatch,ViewService) => Widget，

它主要包含三方面的資訊：

檢視是完全由資料驅動。
檢視產生的事件、回撥，通過 Dispatch 發出“意圖”，不做具體的實現。
需要用到的元件依賴等，通過 ViewService 標準化呼叫。比如一個典型的符合 View 簽名的函式。

640?wx_fmt=png

關於Effect

Effect 是對非修改資料行為的標準定義，它是一個函式簽名: (Context, Action) => Object，它主要包含四方面的資訊：

接收來自 View 的“意圖”，也包括對應的生命週期的回撥，然後做出具體的執行。
它的處理可能是一個非同步函式，資料可能在過程中被修改，所以我們不崇尚持有資料，而通過上下文來獲取最新資料。
它不修改資料，如果修要，應該發一個 Action 到 Reducer 裡去處理。
它的返回值僅限於 bool or Future，對應支援同步函式和協程的處理流程。比如：良好的協程的支援。

640?wx_fmt=png

關於Reducer

Reducer 是一個完全符合 Redux 規範的函式簽名:(T,Action) => T，一個符合簽名的 Reducer。

640?wx_fmt=png

同時我們以顯式配置的方式來完成大元件所依賴的小元件、介面卡的註冊，這份依賴配置稱之為 Dependencies。

所以有這樣的公式：

Component = View + Effect(可選) + Reducer(可選) + Dependencies(可選)。

一個典型的組裝：

640?wx_fmt=png

通過 Component 的抽象，我們得到了完整的分治，多緯度的複用，更好的解耦。

Adapter

Adapter 也是對區域性的展示和功能的封裝。它為 ListView 高效能場景而生，它是 Component 實現上的一種變化。

1.它的目標是解決 Component 模型在 flutter-ListView 的場景下的 3 個問題：

將一個"Big-Cell"放在 Component 裡，無法享受 ListView 程式碼的效能優化。
Component 無法區分 appear|disappear 和 init|dispose 。
Effect 的生命週期和 View 的耦合，在 ListView 的場景下不符合直觀的預期。概括的講，我們想要一個邏輯上的 ScrollView，效能上的 ListView ，這樣的一種區域性展示和功能封裝的抽象。做出這樣獨立一層的抽象是，我們看實際的效果，我們對頁面不使用框架，使用框架 Component，使用框架 Component+Adapter 的效能基線對比。

2.Reducer is long-lived, Effect is medium-lived, View is short-lived. 我們通過不斷的測試做對比，以某 android 機為例。

3.使用框架前我們的詳情頁面的 FPS，基線在 52FPS。

4.使用框架，僅使用 Component 抽象下，FPS 下降到 40，遭遇“Big-Cell”的陷阱。

5.使用框架，同時使用 Adapter 抽象後，FPS 提升到 53，回到基線以上，有小幅度的提升。

Dictionary

推薦的目錄結構會是這樣：

640?wx_fmt=png

上層負責組裝，下層負責實現, 同時會有一個外掛提供，便於我們快速填寫。以閒魚的詳情場景為例的組裝：

640?wx_fmt=png

元件和元件之間，元件和容器之間都完全的獨立。

Communication Mechanism

元件|介面卡內通訊
元件|介面卡間內通訊

640?wx_fmt=jpeg

簡單的描述：採用的是帶有一段優先處理的廣播， self-first-broadcast。發出的 Action，自己優先處理，否則廣播給其他元件和 Redux 處理。最終我們通過一個簡單而直觀的 dispatch 完成了元件內，元件間（父到子，子到父，兄弟間等）的所有的通訊訴求。

Refresh Mechanism

資料重新整理

1.區域性資料修改，自動層層觸發上層資料的淺拷貝，對上層業務程式碼是透明的。

2.層層的資料的拷貝：

一方面是對 Redux 資料修改的嚴格的 follow。
另一方面也是對資料驅動展示的嚴格的 follow。

640?wx_fmt=png

檢視重新整理

扁平化通知到所有元件，元件通過 shouldUpdate 確定自己是否需要重新整理。

640?wx_fmt=png

優點

1.資料的集中管理：通過 Redux 做集中化的可觀察的資料管理。我們將原汁原味地保留所有的 Redux 的優勢，同時在 Reducer 的合併上，變成由框架代理自動完成，大大簡化了使用 Redux 的繁瑣度。

2.元件的分治管理：元件既是對檢視的分治，也是對資料的分治。通過逐層分治，我們將複雜的頁面和資料切分為相互獨立的小模組。這將利於團隊內的協作開發。

3.View、Effect、Reducer隔離：將元件拆分成三個無狀態的互不依賴的函式。因為是無狀態的函式，它更易於編寫、除錯、測試、維護。同時它帶來了更多的組合、複用和創新的可能。

4.宣告式配置組裝：元件、介面卡通過自由的宣告式配置組裝來完成。包括它的 View、Reducer、Effect 以及它所依賴的子項。

5.良好的擴充套件性：核心框架保持自己的核心的三層關注點，不做核心關注點以外的事情，同時對上層保持了靈活的擴充套件性。

框架甚至沒有任何的一行的列印的程式碼，但我們可通過標準的 Middleware 來觀察到資料的流動，元件的變化。
在框架的核心三層外，也可以通過 dart 的語言特性為 Component 或者 Adapter 新增 mixin，來靈活的組合式地增強他們的上層使用上的定製和能力。
框架和其他中介軟體的打通，諸如自動曝光、高可用等，各中介軟體和框架之間都是透明的，由上層自由組裝。

6.精小、簡單、完備：