目前，跨平台、高性能的渲染引擎逐漸成為大前端領域的一個熱點。作為其中的明星， Flutter有很大的機會成為下一代主流的跨端解決方案。 閑魚技術基於Flutter 深耕，開源了2億用戶背后的Flutter應用框架：Fish Redux。接下來，我們就一起深入解讀 Fish Redux ，了解它的函數式的編程模型、可預測的狀態管理、可插拔的組件體系、最佳的性能表現。
此外，今天晚上，閑魚工程師將做客阿里技術直播間，與你聊聊移動開發和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 簽名的函數。
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
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.精小、簡單、完備：
它非常小，僅僅包含 1000 多行代碼。
它使用簡單，完成幾個小的函數，完成組裝，即可運行。
它是完備的。
Fish Redux 目前已在阿里巴巴閑魚技術團隊內多場景深入應用，期待和業界小伙伴攜手共同完善。
對移動開發感興趣的同學，歡迎加入Fish Redux開發者交流群，今晚看直播、與閑魚技術團隊直接交流！