Flutter 入門與實戰（四十六）：狀態管理有N 種寫法，你知道麼？

這是我參與8月更文挑戰的第9天，活動詳情查看：8月更文挑戰

楔子

話說孔乙己轉行作了程序員，聽聞近年來大前端比較火，也跟風學了一陣。什麼 Vue，React，Angular 都瞭解一點。這段時間，行業巨頭谷歌出了個 Flutter，號稱要一套代碼搞定整個前端，孔乙己天然不肯放過。

這天孔乙己逛到了掘金社區，裏面大佬太多，他怕本身太業餘露餡。知道不能和他們談天，便只好向初學者說話。有一回在個人評論區問道，「你學過 Flutter麼？」 我略略回了個表情。 他說，「學過，……我便考你一考。Flutter的狀態管理，怎樣寫的？」 我想，水平和我同樣的人，也配考我麼？便沒有回消息，再也不理會。 孔乙己等了許久，再一次評論道，「不能寫罷？……我教給你，記着！Flutter 狀態管理應該這樣寫。未來作高級工程師的時候，作架構要用。」 我暗想我和高級工程師的等級還很遠呢，並且咱們總監也從不用 Flutter 開發應用；又可笑，又不耐煩，懶懶的答他道，「誰要你教，不就是用一個 setState 方法麼？」 孔乙己顯出極高興的樣子，發了一個 耶的勝利表情，點頭說，「對呀對呀！……狀態管理有N 種寫法，你知道麼？」 我天然是沒有回答，但他本身卻真的列了出來。

Provider

在 Pub 上最受歡迎的狀態管理插件之一，憑藉簡潔、易用、高性能受到了不少 Flutter 開發者的喜好，更是成爲了官方首要推薦的狀態管理工具。咱們在Flutter 入門與實戰（四十）：以購物車爲例初探狀態管理其實已經介紹過。插件pub地址：Provider package。本質上，Provider是在 InheritedWidget 基礎上的封裝，使用Provider具備以下特性：

• 簡化資源的分配和銷燬；
• 懶加載；
• 減小了大量建立狀態管理相關類代碼的工做；
• 通用的方式去消費 InheritedWidget 共享的數據；
• 對於複雜度顯著上升的監聽鏈路，提供了高可擴展性。

setState

最爲初級的狀態管理方法，官方的Hello World示例用的就是這種方式，優勢是簡單，缺點嘛——參照其餘狀態管理的優勢，那些都是針對這種方式的缺點改進的。

InheritedWidget 和 InheritedModel

前面介紹的 ModelBinding就是這種方式，Provider其實也是這種方式。對 InheritedWidget 進行封裝，實現數據在組件樹上傳遞，進而達到狀態數據共享和局部刷新的目的。

Redux

相似 React 的狀態管理工具Redux，本質上是一個狀態容器，pub地址：Flutter-Redux package。關鍵在於提供了3種 Widget：

• StoreProvider：基礎 Widget，它會把指定的Redux狀態數據（Redux Store） 傳遞給須要的下級組件；
• StoreBuilder：一個從 StoreProvider 獲取狀態的下級組件，它會將獲取到的狀態傳遞給一個返回 Widget 的 builder 方法。
• StoreConnector：一個從最臨近的 StoreProvider 祖先組件獲取狀態的下級組件，而後利用 指定的 converter將狀態轉換爲 ViewModel 對象後給到 builder 方法。任什麼時候候，狀態發出一個更改事件後，該組件會被自動重建，從而無需主動管理事件訂閱。

Fish Redux

閒魚出品的一個基於 Redux 的總體應用框架，對於構建大中型應用來講很合適，pub 地址：Fish-Redux package。與 Redux 的區別是，Fish Redux 是一個應用框架，解決了如應用分治、通訊、數據驅動、解耦等問題。做爲一個應用框架，優勢是能夠爲團隊創建一套統一的規範，固然缺點也有，好比對於小應用來講可能過於龐大，靈活性不足，可能會影響開閥發效率。

BLoC / Rx

一個基於Stream / Observable 範式的系列，關於介紹能夠看官方的文檔：Flutter BLoC。

GetIt

GetIt 其實是一個基於狀態管理的服務管理工具，優勢是不須要 BuildContext。若是想使用依賴注入、面向接口編程的方式來實現代碼解耦和應用管理則十分適合。對應的 pub 包和文檔以下：

• GetIt package：基礎的服務管理工具，提供了容器幫助代碼找到對應的服務提供對象。
• GetIt Mixin：GetIt 的擴展，使得 GetIt 能夠徹底應用於狀態管理。
• GetIt Hooks：GetIt 的另外一個擴展，能夠用於 flutter_hooks 的場景。
• Flutter state management for minimalist：一篇介紹 Flutter 狀態管理與應用架構的文章，值得仔細閱讀。

MobX

基於觀察者模式和響應式模式的狀態管理庫，GitHub 地址：MobX。 MobX 的目標是將應用的界面和響應式數據鏈接起來。這種方式是徹底自動的，並且感受很天然（相似雙向綁定）。對於開發者而言，只須要關注界面須要消費的響應式數據，而不用擔憂保持兩者的同步。

Flutter Commands

基於 ValueNotifier,使用命令模式實現的響應式狀態管理庫。最佳的實踐是與 GetIt 結合，也可使用 Provider或其餘容器配合。pub 地址：Flutter Command。

Binder

基於 InheritedWidget 的狀態管理包，仿照的是recoil，目標是想將業務、狀態和界面分離解耦，pub 地址：Binder package。

GetX

一個簡化的狀態管理解決方案，pub 地址：GetX package。GetX 是一個超輕量、但很強大的 Flutter 解決方案，提供了高性能的狀態管理，智能依賴注入和快速可用的路由管理工具。GetX因爲簡化了不少實現代碼，目前的流行度已經超過了 Provider。

States Rebuilder

States Rebuilder 是高性能，知足預期和可控的狀態管理工具。支持可變和不可變的狀態，實現了嚴格的狀態控制，而且支持自動清除狀態。並且還能夠在 StatelessWidget 中使用 setState（狀態數據模型類的 setState，） 更新界面，一樣也支持無需 BuildContext 的頁面導航和消息提示。GitHub 地址： States Rebuilder。

尾聲

等到孔乙己寫完以後，我居然有點驚到了，難道這些他都會？但礙於顏面，又很差意思問他。只好本身按照他寫的那些去搜了一下。至於他是否是都會，也就無從知道了！

總結

因爲 Dart 語言和 Javascript有不少共同之處，所以在 pub 上有不少相似 Javascript 的庫，譬如 Redux，MobX 等。實際上，沒有最好的狀態管理工具，只有最合適的狀態管理工具。具體如何選擇能夠參考如下幾點：

• 更新維護及時性：Flutter 自己的迭代速度很快，所以有些插件若是不及時維護的話意味着你以後的代碼所有須要更改，尤爲是狀態管理這類涉及到整個應用架構的插件。
• 使用者數量：能夠經過 pub 的評分和 Github 的評分來評估使用者的狀況，使用人數很少意味着你可能會須要本身踩坑排雷，對於本身玩的話無所謂，可是對於產品開發就可能會影響整個產品的開發進度。
• 團隊適應性：若是是你一我的開發，那能夠忽略這一點，可是若是團隊有多人，那須要考慮一個你們都可以快速上手的插件。
• 原生依賴度：有很多插件是須要依賴原生的，而有些原生自己就是第三方的開源代碼，若是這些開源代碼中止維護了極可能致使 Flutter 的插件也沒法更新。所以，除非是官方插件，對於第三方插件要特別當心，若是第三方插件依賴於原生甚至是第三方開源代碼，那麼就須要注意要慎重選擇。若是能夠，儘量選擇純 Dart 的插件。

---

我是島上碼農，微信公衆號同名，這是Flutter 入門與實戰的專欄文章。

👍🏻：以爲有收穫請點個贊鼓勵一下！

🌟：收藏文章，方便回看哦！

💬：評論交流，互相進步！