作者：閒魚技術——啊丘
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<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的美妙之處。