【AliFlutter】Flutter Fish Redux 2.0 架構演進實踐

阿里巴巴移動技術發表於2021-09-01
FlutterRedux架構

Fish-Redux開源以來，已經在閒魚核心鏈路上做了大量驗證。從初期的寶貝詳情頁，釋出頁面開始，Fish-Redux在閒魚的使用程度逐漸提高。Fish-Redux框架的使用極大提升了複雜頁面場景下的開發效率。特別是通過框架提供的元件複用和狀態管理能力，我們大幅降低了程式碼冗餘也簡化了頁面複雜度。

Fish-Redux GitHub：github.com/alibaba/fis…

然而隨著頁面複雜度的不斷提升，現有能力已無法支撐新業務場景的述求。特別是

  • 頁面編排
  • 動態AB
  • 靈活性不足

於是我們基於Fish-Redux現有框架做了新一輪架構演進。通過對現有介面卡能力的升級，進一步提高了架構的靈活性。Fish-Redux的2.0版本正式誕生！

閒魚Fish-Redux現狀

Fish-Redux已經在閒魚核心鏈路大量落地。Fish-Redux核心收益如下：

  1. 元件複用以閒魚的商品詳情頁開發為例。以核心的服務型別商品和交易型別商品為基礎。藉助Fish-Redux框架，我們衍生出了普通寶貝，租賃寶貝，玩家號寶貝等10多個寶貝詳情頁面。這些不同型別的詳情頁面，不僅有自己獨立的業務模組，也最大可能的複用了共同的元件模組。
  2. 狀態管理在釋出這種強互動場景開發中，我們使用Fish-Redux高效管理了大量的頁面事件，極大提升了元件通訊的效率。繁多的業務場景下也保證得了邏輯元件化。
  3. 程式碼結構管理Fish-Redux為我們提供了很好的檔案程式碼規範。這保證我們在開發的時候，無論是程式碼風格還是專案結構，都有著高度一致性。釋出鏈路我們多人蔘與開發，負責對應的模組，針對對應的元件部分進行開發。特別是人員流轉以後，可以快速上手，這極大的提高了多人協同開發的效率。

Fish-Redux面臨的挑戰

需要保持Fish-Redux的特性前提下暴露出動態編排能力的Adpater，滿足上訴能力才能支撐為未來所需要的業務場景。

簡單介紹下目前adapter所存在的一些短板和不足：

已有靜態編排：StaticFlowAdapter

StaticFlowAdapter({
    @required List<Dependent<T>> slots,
    Reducer<T> reducer,
    Effect<T> effect,
    ReducerFilter<T> filter,
  })


  （Dependent = connector + component）
複製程式碼

FlowAdapter由Dependent陣列決定頁面展現順序。頁面的展示順序直接取決於 solts，並且能直接控制各個自元件之間的資料流轉，利用這一點優勢去編寫複雜頁面，各種資料分治的邏輯，很大程度的提高來程式碼的可維護性。這種形式也存在某些弊端，我們無法對slots動態的進行修改，缺失動態編排能力。

已有動態編排：DynamicFlowAdapter

 final Map<String, AbstractLogic<Object>> pool;
  final AbstractConnector<T, List<ItemBean>> connector;


  DynamicFlowAdapter({
    @required this.pool,
    @required this.connector,
    ReducerFilter<T> filter,
    Reducer<T> reducer,
    Effect<T> effect,
    @deprecated Object Function(T) key,
  })
複製程式碼

DynamicFlowAdapter提供的核心入參是“pool”，“connector”。pool 提供的adapter的元件池，connector提供元件key，state。從列表元件靜態展示轉變為資料來源動態控制頁面列表UI。多元件，重複展示的列表提供來便利。

DynamicFlowAdapter也存在一些不便的地方，所有的元件資料處理都歸一到了一個connector之中，Fish-Redux資料分治的亮點就難以得到體現。對於我們去編寫複雜動態頁面列表也不是很方便。

無論是StaticFlowAdapter還是DynamicFlowAdapter都無法同時滿足動態編排加上資料分治的特性，我們對Fish-Redux做了進一步的演進。

Fish-Redux演進

第一個版本是基於Fish-Redux的能力我們做了一層腳手架 effective_redux，針對我們上訴的需求對於DynamicFlowAdapter進行包裝（元件註冊+資料來源處理）完成了data對映component邏輯，實現了對應的動態編排能力。

  1. 腳手架中內建了一些了通用基礎模版，動態模版，列表模版等，來支援一些緊急的業務需求；
  2. 對fish redux做了ListAdapter功能增強，提出了Section的概念。來滿足對資料不同資料集合型別展示的需求。

但是做完第一個版本後引發了一些思考：

  1. 動態編排能力是否使用fish redux的使用者也需要
  2. 針對頁面改動修改了頁面框架的外觀是否增加學習成本，開發人員的不習慣
  3. 技術帶動業務發展，業務需求是否能反補技術框架能力等

第二個版本我們決定將部分能力反補至fish redux中。經過一些思考和目前存在的Adapter一些功能實現對比，總結了目前我們能反補到fish redux的能力部分。並且統一化了FlowAdapter，同時提供了動態編排的能力。

改進後的編排：FlowAdapter

Dependent = connector(資料描述)+component(UI描述配置)

重新思考了Adapter的核心思想：Dependent集合的中轉站，處理集合內的資料流轉，元件的重新整理邏輯。同時將處理後的集合轉換成UI介面特定資料。

動態編排實現：FlowAdapater不再以靜態的形式獲取組合的Dependent列表，由靜態引數List 轉變為 FlowDependencies 獲取的動態回撥。我們可以在FlowDependencies中做一系列擴充套件，例如頁面展示動態編排，元件的AB功能等等。

分治資料特性：動態獲取的List為connector+component的資料集合，不再是單一的做資料對映UI的邏輯處理，將真正的資料處理過程交回到各個connector中，保持了adapter內元件的資料處理分治特性。

當然我們也做了adapter的規整。上訴介紹的兩種adapter其實我們會發現內部的實現邏輯是保持不一致的，static adapter， dynamic adapter真正去處理元件集合的拉平邏輯是不同的。

針對這種我們把StaticFlowAdapter，DynamicFlowAdapter功能實現遷移至我們的新版FlowAdapter中。保證Adapter能力實現一致，外觀保持一致，降低學習成本，也能統一做一些效能上的優化。

效果展示

fish redux完成架構升級後，我們的詳情&釋出鏈路做了對應的程式碼修改。

內建模版註冊，根據服務端下發的配置資訊決定頁面的編排順序。基於框架提供出對應的動態編排能力，我們能做到我們提出的一些業務可能性。

  • 【動態編排能力】我們的編排順序，展示資料是由服務端返回的配置資訊資料決定的。也就是說頁面的展示是有服務端確定的。我們後續對模組之間的順序調整不再依賴於客戶端本地修改後進行發包修改。同時我們也做了對應資料一場的兜底方案，標準的頁面展示順序；
  • 【元件AB能力】元件AB的能力可以交付到服務端前置處理，同時也可以原生程式碼中增加動態替換的程式碼，根據不同的配置分桶做一些定製化的處理；
  • 【動態模版】動態模版的增加為了滿足產品快速驗證某個業務模組是否可行，直接線上做測試校驗，不需要客戶端發版本。

詳情的效果展示：基於價格模組的位置調整，上下架進行了一些嘗試。我們能很快的進行一些線上調整動作。

展望

這次我們針對fish redux的adapter做規整，對於編排資料獲取的思路轉變，更加明確了adapter的功能職責。在根本之處對adapter做了優化處理，更加適應業務場景。此次的優化修改後續會合並至fish redux release之中，為大家帶來更多的使用便捷之處。

基於這次框架的演進，為我們帶來了fish redux針對不同容器下更多的思考，我們不單單隻滿足於普通列表的adapter適配，fish redux針對不同容器展示，我們也在著手準備。對於瀑布流場景或者其他的容器內也能有很好的落地。也會在fish redux層面做出一些對PowerScrollView的適配。

對於一些業務的解決方案，動態模版，AB能力我也期望輸出到fish redux的擴充套件包中，不單單解決框架層面的一些問題，最終是一個框架平臺的形式讓使用者更加簡易。對fish redux的能力擴充套件也是我們後續的一個重要命題。

最後，歡迎大家積極嘗試fish redux，並在社群中發出聲音，提出問題或者改進建議，以及貢獻程式碼。

我們相信未來fish redux會在更多的場景，能力上使用出現在螢幕上，讓大家感受到fish redux的美妙之處。

相關文章