Flutter中 Redux和Provider的比较

在flutter中，跨组件状态共享是一个非常重要的课题，在一切皆为widget的前提下，一般的原则是：如果状态是组件私有的，则应该由组件自己管理；如果状态要跨组件共享，则该状态应该由各个组件共同的父元素来管理。对于组件私有的状态管理很好理解，但对于跨组件共享的状态，管理的方式就比较多了，这里讨论两个最火的框架，Redux和Provider。

Redux

Redux 的思想来自于前端，作为android 开发的我，掌握起来有点费劲，好在思路比较清晰，反复理解几遍后，也能理解的七七八八。Redux的状态流转图可以参考如下:

对这张图进行一下说明。

• 所有的状态都存储在Store里。这个Store会放在根Widget.
• View拿到Store的状态数据会映射成视图渲染.
• Redux不直接让view操作数据，通过dispatch一个action通知Reducer,状态变更
• Reducer接收到这个action，根据action状态，生成新的状态，并替换在Store的旧状态.
• Store存储了新的状态后，就通知所有使用到了这个状态的View更新（类似setState）。这样我们就能够同步不同view中的状态了.

网上有很多介绍Redux的demo了，有个入门的教程Flutter 入门讲的非常透彻
这篇文章主要是对比，不侧重于普及某个技术。

理解了原理和敲完demo之后，对Redux应该有所了解了。除了dispatch action之外，Store的管理都得自己搞定。

Provider

Provider是官方推荐的状态管理框架，Flutter实战这本书阐述了原理，书的地址是https://book.flutterchina.club，也是flutter中文网的首选入门书籍，这里讲跨组件共享的时候，先理解了InheritWidget，它的天生特性就是能绑定InheritedWidget与依赖它的子孙组件的依赖关系，并且当InheritedWidget数据发生变化时，可以自动更新依赖的子孙组件！因为Provider就是对这一层进行了封装。大概的流程图如下：

具体的用法已经在书籍中了，我就不重新造轮子了。

比较

1. 流程上还是Provider比较清晰，有点类似观察者的味道，熟悉观察者设计模式的同学，看到之后会觉得熟悉的味道，熟悉的配方。Redux的设计理念就不是那么容易懂.
2. Redux思想来源于前端，对于前端同学掌握比较简单。从代码量来说，Redux要做的比较多，需要自己实现Store,Reducer。Provider基本只要实现继承于ChangeNotifier即可。
3. 从使用共享状态来说，两者都差不多，一个是StoreConnector,一个是Consumer，两者都可以控制刷新力度，但据我实测，StoreConnector之外的FlattonButton的dispatch了action，这个FlattonButton还是会重新build，这个令人有点诧异
4. 不管哪个框架，最终思想就是子组件共享父组件中的数据，方式不同，目的相同。