Flutter 开源状态管理插件一览

话说孔乙己转行做了程序员，听闻近年来大前端比较火，也跟风学了一阵。什么 Vue，React，Angular 都了解一点。这段时间，行业巨头谷歌出了个 Flutter，号称要一套代码搞定整个前端，孔乙己自然不愿放过。

这天孔乙己逛到了掘金社区，里面大佬太多，他怕自己太业余露馅。知道不能和他们谈天，便只好向初学者说话。有一回在我的评论区问道，“你学过 Flutter 么？”我略略回了个表情。他说，“学过，……我便考你一考。Flutter 的状态管理，怎样写的？”我想，水平和我一样的人，也配考我么？便没有回消息，不再理会。孔乙己等了许久，再一次评论道，“不能写罢？……我教给你，记着！Flutter 状态管理应该这样写。将来做高级工程师的时候，做架构要用。”我暗想我和高级工程师的等级还很远呢，而且我们总监也从不用 Flutter 开发应用；又好笑，又不耐烦，懒懒的答他道，“谁要你教，不就是用一个 setState 方法么？”孔乙己显出极高兴的样子，发了一个 耶的胜利表情，点头说，“对呀对呀！……状态管理有 N 种写法，你知道么？”我自然是没有回答，但他自己却真的列了出来。

Provider

在 Pub 上最受欢迎的状态管理插件之一，凭借简洁、易用、高性能受到了很多 Flutter 开发者的喜爱，更是成为了官方首要推荐的状态管理工具。插件 pub 地址：Provider package。本质上，Provider是在 InheritedWidget 基础上的封装，使用Provider具有如下特性：

• 简化资源的分配和销毁；

• 减少了大量创建状态管理相关类代码的工作；

• 通用的方式去消费 InheritedWidget 共享的数据；

• 对于复杂度显著上升的监听链路，提供了高可扩展性。

setState

最为初级、也是最简单粗暴的状态管理方法，官方的 Hello World 示例用的就是这种方式，优点是简单，缺点嘛 —— 其他状态管理的优点就是它的缺点，那些都是针对这种方式的缺点改进的。当然，也不是不能用，如果只是针对没有子组件或子组件很少的情况，用 setState 也没什么问题。

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 状态管理与应用架构的文章，值得仔细阅读。

基于观察者模式和响应式模式的状态管理库，GitHub 地址：MobX。 MobX 的目标是将应用的界面和响应式数据连接起来。这种方式是完全自动的，而且感觉很自然（类似双向绑定）。对于开发者而言，只需要关注界面需要消费的响应式数据，而不用担心保持二者的同步。

Flutter Commands

基于 ValueNotifier,使用命令模式实现的响应式状态管理库。最佳的实践是与 GetIt 结合，也可以使用 Provider 或其他容器配合。pub 地址：Flutter Command。

Binder

基于 InheritedWidget 的状态管理包，仿照的是 recoil，目标是想将业务、状态和界面分离解耦，pub 地址：Binder package。

一个简化的状态管理解决方案，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 的插件。

本文文字及图片出自 InfoQ