前言
状态管理
首先我们来说说什么是状态管理？举个例子
当我们想在多个页面（组件/Widget）之间共享状态（数据），或者一个页面（组件/Widget）中的多个子组件之间共享状态（数据），这个时候我们就可以用 Flutter中的状态管理来管理统一的状态（数据），实现不同组件直接的传值和数据共享抽离状态（数据）与UI，UI只负责页面展示，状态管理层负责状态（数据）的逻辑处理与维护。
Flutter中主流的状态管理工具
setState (Dart 和 Flutter 内置支持)
Provider（官方推荐的全局状态管理工具）
Redux（flutter_redux）
InheritedWidget
scoped_model
Provider
下面我们来针对最火热的Provider和Redux来聊一聊
Provider
他是一种轻量级的，并且是又官方提供的状态管理解决方案，他有一下几个重要的概念：
- ChangeNotifier（被观察对象）
- Provider（被观察对象提供者）
- Consumer（观察者）
- Provider.of
ChangeNotifier：它用于向监听器发送通知
换言之，如果被定义为 ChangeNotifier，你可以订阅它的状态变化；所以说，他是一种状态管理类，用于处理和管理状态（数据），来看一下下面的例子
我们创建了一个Counter类，mixin了ChangeNotifier，其中有一个简单的+1方法，它会监听value的状态，在发生变化时通知他的订阅者。
Provider：状态对象提供者，是一个widget，提供可被监控的状态对象
上图中可以看到，Provider提供了Counter对象一共监控。常用的Provider有一下这些：
-Provider：最基础的provider,它会获取一个值并将它暴露出来
-ListenableProvider：用来暴露可监听的对象，该provider将会监听对象的改变以便及时更新组件状态
-ChangeNotifierProvider：ListerableProvider的子类，依托于ChangeNotifier实现，它将会在需要的时候自动调用ChangeNotifier.dispose方法
-ChangeNotifierProxyProvider：将多个值组合到一个新对象中，只要新提供者之一的依赖更新，该新对象就会被更新
-StreamProvider：监听一个流，并且暴露出其最近发送的值
-FutureProvider：接受一个Future作为参数，在这个Future完成的时候更新依赖
-MultiProvider：可以同时多个上述几种Provider提供多个被监听对象
我们来看一下Provider在源码中的注释是如何描述的，如下图
通过注释可以看到，provider是创建一个值，储存他，并且将它暴露给其子孙，可以使用dispose来释放value值，dispose的调用时机是在provider从widget树卸载时。Provider是继承于InheritProvider，而InheritProvider本质上是一个InheritWidget，所以Provider本质上是依托于InheritProvider的机制来实现的widget树的状态共享。
ChangeNotifierProvider也是一个widget，他可以向其子孙节点暴露一个 ChangeNotifier ，来看一下他的实现
他继承了ListenableProvider，其实ListenableProvider最终也是继承的InheritWidget。可以看到ChangeNotifierProvider有一个静态的dispose方法，这个方法的内容是调用ChangeNotifier实例的dispose方法，同时这个静态方法作为构造函数的dispose的默认传参，也就是说，当ChangeNotifierProvider从widget树卸载时会自动调用这个静态方法，以释放资源。
ChangeNotifierProxyProvider：如果某个状态类A的改变依赖于另一个状态类B，且需要监听状态类a的改变来刷新ui，此时就需要用到ChangeNotifierProxyProvider了。
他从widget树卸载时会调用刚才提到的ChangeNotifierProvider中的静态方法来释放资源。其底层同样是依托与InheritWidget实现的状态共享。
Consumer：是一个widget，用于监听ChangeNotifier变化，并作出相应的UI处理
我们来介绍一下Consumer的刷新作用域
Consumer的默认刷新作用域，是其所有的子widget，但是Consumer提供了一个child参数作为优化，图一中Consumer有一个子widget ：barwidget，所以当监听的状态变更时，barwidget及其子widget将会刷新；下图中，Consumer作为FooWidget的父节点，状态变更时，默认情况下FooWidget及其子节点barwidget都会刷新，但当barwidget作为child参数时，刷新就只涉及到FooWidget层，barwidget及其子节点不会刷新。
Provider.of：是一个静态方法，不与UI绑定，可动态获取ChangeNotifier状态，或调用ChangeNotifier方法
Provider.of 与 Consumer的区别是，Consumer是个wiget，Provider.of是个静态方法，前者是与ui绑定的；Consumer 是进行局部刷新，而使用Provider.of获取监听状态时，与Provider.of相关的context下的widget都会被rebuild；Provider.of可以通过设置listen false 不监听状态变化从而不刷新页面，只获取当前最新状态或者调用改变状态的方法。
使用方法
好了，介绍完了一下基础感念，我们来看看如何使用Provider吧，他的使用步骤可以归结为下面四步：
1.创建ChangeNotifier
创建一个ChangeNotifier类，也即创建一个可被状态管理的数据类
2.暴露一个值
暴露一个值，即根据需要，使用相应的provider提供一个可供管理的状态对象，provider的作用域是所有子widget，需要全局管理的状态需要在widget树的根节点进行提供（如果用户登录信息，主题）。
3.读取一个值
读取一个值，即获取状态类对象中的状态，两种方法，使用Consumer包裹需要针对状态变化的ui，或者直接使用Provider.of对ui进行处理。
4.改变一个值
前面的状态创建、提供、以及监听绑定已经完成，最后一步就是需要状态的变化来触发页面刷新了。
到此，针对Provider的介绍就告一段落了。
Redux
Redux: 是一个单项数据流架构，前端应用中非常成熟
flutter_redux: 是基于InheritedWidget封装的用于Widget树的数据传递与共享的的一套框架，它能高效的完成数据共享，进而达到ui及时更新等目的。
Redux有四个重要的概念，那就是：
-Widget
-Store
-Action
-Reducer
看图说话!
1.我们在Redux中，所有的状态都储存在Store里。这个Store会放在App顶层。
2.widget拿到Store储存的状态(State)来用作ui处理。 widget还会与用户进行交互，用户点击按钮滑动屏幕等等，这时会因为交互需要数据发生改变。
3.Redux让我们不能让widget直接操作数据，而是通过发起一个action来告诉Reducer，状态得改变啦。
4.这时候Reducer接收到了这个action，他就回去遍历action表，然后找到那个匹配的action，根据action生成新的状态并把新的状态放到Store中,替换原有状态。
5.Store丢弃了老的状态对象，储存了新的状态对象后，就通知所有使用到了这个状态的widget更新（类似setState）。这样我们就能够同步不同view中的状态了。
使用方法
1.创建State
状态是由reducer生成并储存在Store里面的。Store更新状态的时候，并不是更改原来的状态对象，而是直接将reducer生成的新的状态对象替换掉老的状态对象。所以，我们的状态应该是immutable的。
2.定义Action Types枚举
action到底是什么？View如何发出action。其实，action只是我们对状态进行操作方法的一个代号而已。在我们这个应用中，唯一的一个功能就是让count的值+1，所以我们这里只有一个action。
3.创建reducer
reducer是我们的状态生成器，它接收一个我们原来的状态，然后接收一个action，再匹配这个action生成一个新的状态。
4.创建
store
Store接收一个reducer，以及初始化State，flutter_redux提供了一个很棒的widget叫做StoreProvider，它的用法也很简单，接收一个store，和child Widget,对其子widget提供store
5.
状态获取
使用storeConnector在子页面中获取store中的state。
首先这里需要强制声明类型，S代表我们需要从store中获取什么类型的state，ViewModel指的是我们使用这个State时的实际类型；然后我们需要声明一个converter<S,ViewModel>，它的作用是将Store转化成实际ViewModel将要使用的信息，比如我们这里实际上要使用的是count，所以这里将count提取出来。 builder是我们实际根据state创建Widget的地方，它接收一个上下文context，以及刚才我们转化出来的ViewModel，所以我们就只需要把拿到的count放进Text Widget中进行渲染就好了。
6.发送action
我们还是使用StoreConnector<S,ViewModel>。这里由于是发出了一个动作，所以是VoidCallback。 store.dispatch发起一个action，操作将被发送到给定的reducer生成新的状态，并更新状态树。
总结
Provider
- 流程上比较清晰，类似观察者模式
- 代码量少，除了ChangeNotifier需要手动实现外，其余的都已经封装好
- 可控制刷新范围
Redex
- Flutter_redex脱胎于前端的Redex框架，相对成熟
- 适合业务复杂、状态数量大的场景
- 相对于Provider代码量比较大，许多内容需要手动实现
- 可控制刷新范围
