阿里妹導讀：目前，跨平臺、高效能的渲染引擎逐漸成為大前端領域的一個熱點。作為其中的明星， Flutter有很大的機會成為下一代主流的跨端解決方案。 閒魚技術基於Flutter 深耕，開源了2億使用者背後的Flutter應用框架：Fish Redux。接下來，我們就一起深入解讀 Fish Redux ，瞭解它的函式式的程式設計模型、可預測的狀態管理、可插拔的元件體系、最佳的效能表現。
此外，今天晚上，閒魚工程師將做客阿里技術直播間，與你聊聊移動開發和Fish Redux，歡迎觀看。
開源地址
https://github.com/alibaba/fish-redux
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 簽名的函式。
關於Effect
Effect 是對非修改資料行為的標準定義，它是一個函式簽名: (Context, Action) => Object，它主要包含四方面的資訊：
接收來自 View 的“意圖”，也包括對應的生命週期的回撥，然後做出具體的執行。
它的處理可能是一個非同步函式，資料可能在過程中被修改，所以我們不崇尚持有資料，而通過上下文來獲取最新資料。
它不修改資料， 如果修要，應該發一個 Action 到 Reducer 裡去處理。
它的返回值僅限於 bool or Future， 對應支援同步函式和協程的處理流程。 比如：良好的協程的支援。
關於Reducer
Reducer 是一個完全符合 Redux 規範的函式簽名:(T,Action) => T，一個符合簽名的 Reducer。
同時我們以顯式配置的方式來完成大元件所依賴的小元件、介面卡的註冊，這份依賴配置稱之為 Dependencies。
所以有這樣的公式 ：
Component = View + Effect(可選) + Reducer(可選) + Dependencies(可選)。
一個典型的組裝：
通過 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
推薦的目錄結構會是這樣：
上層負責組裝，下層負責實現, 同時會有一個外掛提供， 便於我們快速填寫。以閒魚的詳情場景為例的組裝：
元件和元件之間，元件和容器之間都完全的獨立。
Communication Mechanism
元件|介面卡內通訊
元件|介面卡間內通訊
簡單的描述：採用的是帶有一段優先處理的廣播， self-first-broadcast。 發出的 Action，自己優先處理，否則廣播給其他元件和 Redux 處理。 最終我們通過一個簡單而直觀的 dispatch 完成了元件內，元件間（父到子，子到父，兄弟間等）的所有的通訊訴求。
Refresh Mechanism
資料重新整理
1.區域性資料修改，自動層層觸發上層資料的淺拷貝，對上層業務程式碼是透明的。
2.層層的資料的拷貝：
一方面是對 Redux 資料修改的嚴格的 follow。
另一方面也是對資料驅動展示的嚴格的 follow。
檢視重新整理
扁平化通知到所有元件，元件通過 shouldUpdate 確定自己是否需要重新整理。
優點
1.資料的集中管理：通過 Redux 做集中化的可觀察的資料管理。我們將原汁原味地保留所有的 Redux 的優勢，同時在 Reducer 的合併上，變成由框架代理自動完成，大大簡化了使用 Redux 的繁瑣度。
2.元件的分治管理：元件既是對檢視的分治，也是對資料的分治。通過逐層分治，我們將複雜的頁面和資料切分為相互獨立的小模組。這將利於團隊內的協作開發。
3.View、Effect、Reducer隔離：將元件拆分成三個無狀態的互不依賴的函式。因為是無狀態的函式，它更易於編寫、除錯、測試、維護。同時它帶來了更多的組合、複用和創新的可能。
4.宣告式配置組裝：元件、介面卡通過自由的宣告式配置組裝來完成。包括它的 View、Reducer、Effect 以及它所依賴的子項。
5.良好的擴充套件性：核心框架保持自己的核心的三層關注點，不做核心關注點以外的事情，同時對上層保持了靈活的擴充套件性。
框架甚至沒有任何的一行的列印的程式碼，但我們可通過標準的 Middleware 來觀察到資料的流動，元件的變化。
在框架的核心三層外，也可以通過 dart 的語言特性 為 Component 或者 Adapter 新增 mixin，來靈活的組合式地增強他們的上層使用上的定製和能力。
框架和其他中介軟體的打通，諸如自動曝光、高可用等，各中介軟體和框架之間都是透明的，由上層自由組裝。
6.精小、簡單、完備：
它非常小，僅僅包含 1000 多行程式碼。
它使用簡單，完成幾個小的函式，完成組裝，即可執行。
它是完備的。
Fish Redux 目前已在阿里巴巴閒魚技術團隊內多場景深入應用，期待和業界小夥伴攜手共同完善。