Flutter的FishRedux架構如何演進2.0

Flutter的FishRedux架構如何演進2.0，相信很多沒有經驗的人對此束手無策，為此本文總結了問題出現的原因和解決方法，通過這篇文章希望你能解決這個問題。

Flutter Fish-Redux 編排優化

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

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

?頁面編排
?動態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> 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界面特定數據。

image.png

動態編排實現： 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的能力擴展也是我們后續的一個重要命題。

看完上述內容，你們掌握Flutter的FishRedux架構如何演進2.0的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注億速云行業資訊頻道，感謝各位的閱讀！