這是我參與8月更文挑戰的第28天，活動詳情檢視：8月更文挑戰
前言
我們花了7篇介紹了 Redux 在 Flutter 中的應用，以及特點，本篇對這一系列進行總結，然後我們再介紹其他狀態管理外掛。
Redux 的基本元素
Redux 的基本元素有4個：Store，Action，Reducer和 View，4個元素直接的資料流動是單向的，如下圖所示：
Store儲存View所需的狀態資料；View在接收到使用者互動事件後，排程Action；Action會被傳遞到Reducer中，Reducer根據Action處理對應的業務，然後返回新的狀態資料。- 新的狀態資料通過
Store驅動檢視View進行更新。
關於 Redux 的基本介紹和示例的請看這篇：Flutter入門與實戰（五十八）： 看 Flutter 如何分享 React 的 Redux狀態管理。由於 Redux 本身是從 React來的，因此想深入瞭解的也可以參考 Redux 的官網：Redux - A Predictable State Container for JS Apps。
中介軟體
在某些場景下，我們在處理 Action 前可能需要做一些前置處理或非同步處理，這個時候就可以使用中介軟體。中介軟體其實就是攔截器的概念。有了中介軟體後，Redux 的資料流變成了下面的樣子：
在中介軟體中，可以發起新的
Action（比如獲取到新的狀態資料後），也可以什麼都不做（比如僅僅是發起一個無需確認的後端請求，或者僅僅是儲存離線資料）。關於中介軟體可以閱讀如下篇章：
中介軟體程式碼優化
中介軟體最簡單的寫法是使用不同的if...else，但是如果 Action 很多的時候，會導致 if...else 過多甚至巢狀，程式碼難以維護。這個時候可以利用TypedMiddleware將中介軟體方法與對應的Action進行繫結，從而無需使用 if...else 進行Action型別判斷，增強程式碼的可維護性。我們開發了一個通用的購物車數量加減元件來演示TypedMiddleware的使用：Flutter 入門與實戰（六十二）：開發一個通用的購物車數量加減元件。
多元件狀態共享
和 Provider 類似，如果多個元件要共享一個 Redux 的 Store物件，這些元件需要在 StoreProvider 下的子元件中。對於全域性的 Store 共享資料（例如登入使用者資訊），可以將 StoreProvider放置在頂級應用。我們通過購物清單這個應用講述了多個元件如何共享 Store 狀態：Flutter 入門與實戰（六十）：以購物清單為例講述 Redux 的狀態如何多元件共享。當然，從效能考慮，非必要時，儘快使用區域性的Store。
效能優化
在實際測試中發現，StoreConnector在狀態發生改變的時候，只會重新整理它的下級元件，而不是 Store 的下級元件。這使得我們有了一個效能優化的原則 —— 儘可能地縮小 StoreConnector 覆蓋的元件範圍，從而避免過多的元件重新整理，進而提高效能。我們也從原始碼角度分析了為什麼能夠達到這樣的效果：Flutter 入門與實戰（六十四）：這篇很長，為了效能，你忍一下 —— 從原始碼看 flutter_redux精準重新整理。
對於頂級 Store，如同我們在Flutter 入門與實戰（六十三）：Redux之利用 distinct 屬性進行效能優化這一篇介紹的，頂級Store 可能會導致全域性重新整理，因此最好是將 distinct 屬性設定為 true，並且實現 Store 狀態物件類的==和 hashCode 方法，從而可以避免每次 Action 都引起全域性的元件重新整理。前面提到的將 distinct 屬性設定為 true，並且實現 Store 狀態物件類的==和 hashCode 方法，也能夠避免無謂的全域性重新整理，提高效能。
總結
Redux因為單向資料流的機制，以及各個元素的相互分工協作，使得使用 Redux 編寫的程式碼會更規範，也易於理解。因此，更適用於中大型應用。加上flutter_redux 的封裝，極大地簡化了 Redux 在 Flutter 中的使用。實際上，Redux 還有更多內容等待我們去發掘，建議通過閱讀原始碼和官網文件，去了解更多關於 Redux 的應用和特點。
我是島上碼農，微信公眾號同名，這是Flutter 入門與實戰的專欄文章，對應原始碼請看這裡：Flutter 入門與實戰專欄原始碼。
??：覺得有收穫請點個贊鼓勵一下！
?：收藏文章，方便回看哦！
?：評論交流，互相進步！