即將開源 | 2億使用者背後的Flutter應用框架Fish Redux

Fish Redux 是為解決上面問題上層應用框架，它是一個基於 Redux 資料管理的組裝式 flutter 應用框架， 特別適用於構建中大型的複雜應用。

它的最大特點是配置式組裝， 它會非常乾淨，易編寫、易維護、易協作。

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

分層架構圖

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

Redux

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

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

• Redux 是一個函式式的資料管理的框架。 傳統 OOP 做資料管理，往往是定義一些 Bean，每一個 Bean 對外暴露一些 Public-API 用來操作內部資料（充血模型）。 函式式的做法是更上一個抽象的緯度，對資料的定義是一些 Struct（貧血模型），而運算元據的方法都統一到具有相同函式簽名 (T, Action) => T 的 Reducer 中。 FP:Struct（貧血模型） + Reducer = OOP:Bean（充血模型） 同時 Redux 加上了 FP 中常用的 Middleware（AOP） 模式和 Subscribe 機制，給框架帶了極高的靈活性和擴充套件性。 貧血模型、充血模型 參考： oldJava_object

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

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

• Redux 的集中和 Component 的分治之間的矛盾。

• Redux 的 Reducer 需要一層層手動組裝，帶來的繁瑣性和易錯性。

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

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

• 如果想對 Redux 有更近一步的理解，請參考  

  Component

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

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

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

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

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

• 檢視是完全由資料驅動。

• 檢視產生的事件／回撥，透過 Dispatch 發出“意圖”，不做具體的實現。

• 需要用到的元件依賴等，透過 ViewService 標準化呼叫。 比如一個典型的符合 View 簽名的函式

  

• 接收來自 View 的“意圖”，也包括對應的生命週期的回撥，然後做出具體的執行。

• 它的處理可能是一個非同步函式，資料可能在過程中被修改，所以我們不崇尚持有資料，而透過上下文來獲取最新資料。

• 它不修改資料， 如果修要，應該發一個 Action 到 Reducer 裡去處理。

• 它的返回值僅限於 bool or Future， 對應支援同步函式和協程的處理流程。 比如：良好的協程的支援

  

 一些符合簽名的 Reducer

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

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

一個典型的組裝

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

Adapter

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

• 1）將一個"Big-Cell"放在 Component 裡，無法享受 ListView 程式碼的效能最佳化。

• 2）Component 無法區分 appear|disappear 和 init|dispose 。

• 3）Effect 的生命週期和 View 的耦合，在 ListView 的場景下不符合直觀的預期。 概括的講，我們想要一個邏輯上的 ScrollView，效能上的 ListView ，這樣的一種區域性展示和功能封裝的抽象。 做出這樣獨立一層的抽象是， 我們看實際的效果， 我們對頁面不使用框架，使用框架 Component，使用框架 Component+Adapter 的效能基線對比

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

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

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

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

  Dictionary

sample_page-- action.dart-- page.dart-- view.dart-- effect.dart-- reducer.dart-- state.dartcomponentssample_component-- action.dart-- component.dart-- view.dart-- effect.dart-- reducer.dart-- state.dart

上層負責組裝，下層負責實現,   同時會有一個外掛提供， 便於我們快速填寫。

以閒魚的詳情場景為例的組裝：

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

Communication Mechanism

元件|介面卡內通訊

• 元件|介面卡間內通訊 

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

• 區域性資料修改，自動層層觸發上層資料的淺複製，對上層業務程式碼是透明的。

• 層層的資料的複製

• 一方面是對 Redux 資料修改的嚴格的 follow。

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

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

優點

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

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

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

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

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

• 框架甚至沒有任何的一行的列印的程式碼，但我們可透過標準的 Middleware 來觀察到資料的流動，元件的變化。

• 在框架的核心三層外，也可以透過 dart 的語言特性 為 Component 或者 Adapter 新增 mixin，來靈活的組合式地增強他們的上層使用上的定製和能力。

• 框架和其他中介軟體的打通，諸如自動曝光、高可用等，各中介軟體和框架之間都是透明的，由上層自由組裝。

• 它非常小，僅僅包含 1000 多行程式碼。

• 它使用簡單，完成幾個小的函式，完成組裝，即可執行。

• 它是完備的。

Fish Redux 目前已在阿里巴巴閒魚技術團隊內多場景，深入應用。 Talk is cheap, Show me the code，我們即將開源。