flutte状态管理 Provider 简单原理介绍

　今天简单说一下flutter中的状态管理，我们这次使用provider；

　　ps：先说一个概念，Model，模型，这里面定义了我们准备全局使用的数据，或者方法；

　　举个栗子：我们有一个User类，用来储存用户的信息，比如登录之后，我们会拿到用户的一些个人数据，那么这些数据就可以作为属性写在Model里，同时我们在User内部，还会提供一个upUser方法，用来更新用户信息，那么这个方法也可以写在Model中，OK，以上就是我们准备的User Model;

　　下面是正题，go，go，go

　　一、Provider的三个好兄弟：

　　　　老大 -- MultiProvider

　　　　老二 -- Providers

　　　　老三 -- Provider.of<T>(context)  /  Widget Consumer

　　二、三兄弟的组合拳：

　　　　其实很好理解，我们不去说精髓，先把拳法说一下，靠着拳法去揣摩精髓，会简单很多；

　　　　1、老大 MultiProvider 

  Widget build(BuildContext context) {
    return MultiProvider(
      providers: [], ///先不考虑这一句
      child: MaterialApp(
        title: 'Provider Demo',
        initialRoute: '/',
      ),
    );
  }

　　上面这段代码想必大家很熟悉，一个根widget（先不考虑这一句 providers: [] ），老大的任务就是包裹根节点，将我们准备好的Model和View建立联系；可以想象成一只巨大章鱼包裹了一棵大树，他可以将触手随意的伸向某一节树枝；

　　2、老二 Providers登场：

　　　　其实也很好理解，既然老大可以将我们准备好的各个Model输送到各个节点，那前提是不是老大得知道都有哪些Model需要被送走呢，老二出现了，他就负责预先定义好，需要被共享的Model；

　　　　那老二该如何定义呢，我们上面“先不考虑”的那一句就该出现了，providers，老二是个数组，providers中的s也很明显是个复数，他和老大一起使用，老二就是货源，老大就是供货商，那么老三就是消费者了；

　　　　当然老二这个数组里面不会这么简单，providers：[provider，provider，providers]，它肯定不会是这个样子，因为我们使用Model的需求不同，老二这个数组里装的儿子有好几种，下面我们就说一下，老二几个常用的儿子：

　　　　大儿子：provider  不需要被监听，有的常量或者方法，根本不需要“牵一发而动全身”，也就是说他们不会被要求随着变动而变动，这样的需求就用大儿子定义；

　　　　二儿子： ChangeNotifierProvider  对这个儿子父亲要求的就比较多了，它会随着某些数据改变而被通知更新，也就是说，比如这个Model被用在多个page，那么当其中一处被改变时，他就应该告诉其他的地方，改更新了，这样的需求就是用二儿子定义；

　　　　三儿子： ChangeNotifierProxyProvider   对这个儿子要求就更高了，所以它的名字都比老二长一截，他不仅要像老二一样，通知更新，还要协调Model与Model之间的更新，比如一个ModelA依赖另一个ModelB，ModelB更新，他就要让依赖它的ModelA也随之更新，这就是老三的活；

　　　　具体写法呢，也很简单，官网走起；

　　3、老三这个人有点怪

　　　　我们上面说了老三是消费者，也就是说，他就是负责从各个节点取出数据来使用的；

　　　　为什么说他怪，因为他有两种形态，一种是需要绑定在widget中展示用的，另一种则不是，只是需要作为数据去使用；

　　　　变身一

 var foo = Provider.of<T>(context);

　　　　T是你需要的Model，只需如此，你的foo就取出来了；

　　　　变身二

Consumer<T>(
    builder: (context,foo, child) => Text('$foo.text')
)

　　　　widget展示，foo如上，也是从Model中取出的数据，随意使用；

　　　　OK，三兄弟基本介绍完毕，我也是今天刚刚看到的Provider，如果理解的不对，请你也假装对，哈哈哈，开玩笑，希望大家共同进步；