使用Provider来管理你应用的状态
在学习Provider之前 我假设你已经了解什么是状态管理，以及为什么需要状态管理。本篇文章我会分为两个部分来写。 第一部分 API篇，主要想分享下
Provider中涉及的API，结合具体的业务场景的使用，也就是哪些情况下应该使用哪种类型的Proivder。其中涉及到ProviderChangeNotifierProviderListenableProviderFutureProviderStreamProviderProxyProvider,以及Consumer和Selector的使用。第二部分原理篇Provider的实现原理是什么，究竟是怎样管理状态的，了解实现原理，能让我们对API的使用更加得心应手。以及当功能不满足业务的情况下，我们如何改造源码来实现我们的需求。
本文所展示的所有代码全都放到了github上 点击这里获取
缘起
我希望通过这篇文章，让刚入坑FLutter的同学，彻底了解Provider到底是怎么回事，我们应该如何使用。毕竟这是官方推荐的状态管理方式。因为我觉得不管你的项目最终用不用Provider作为状态管理,Provider都应该成为Flutter开发人员入门的状态管理方式。
Provider和 ChangeNotifierProvider
Provider
切换App的主题已经成为大多数App的标配功能，下面我就以切换主题为例，详细说明Provider和 ChangeNotifierProvider的具体使用。首先我们先定义一个 AppTheme类，用于存放我们的主题颜色
class AppTheme{ final String theme; late Color primaryColor; AppTheme({ required this.theme, }){ if(this.theme == "dark"){ primaryColor = Colors.black; } if(this.theme == "light"){ primaryColor = Colors.white; } } } 复制代码对于主题颜色获取，我们当前希望在App的任意一个位置都能够便捷的获取到。为了实现这个目的我们可以在构建每一个子widgte的时候在构造器中去传递AppTheme,但是我们明显不会用如此扯淡的方式做，没有人会这样写代码。所以 Provider就是用来解决这种自上而下传值的问题，只要父widget是proivder，那么任意子节点的widget都可以获取到父widget使用provider管理的状态。 下面的代码演示了 Provider是怎样解决这个问题的。
void main() { runApp( Provider(create: (BuildContext context){ return AppTheme(theme: "dark"); }, child: MyApp(), ) ); } class MyApp extends StatelessWidget { const MyApp({Key? key}) : super(key: key); @override Widget build(BuildContext context) { return MaterialApp( home: Scaffold( appBar: AppBar( title: const Text('provider'), ), body: Center( child: SizedBox( width: 300, height: 300, child: ColoredBox(color: Provider.of<AppTheme>(context, listen:true).primaryColor), ), ) ) ); } } 复制代码运行上面这段代码你会在屏幕中间得到一个的矩形，这个矩形有着这个世界上最纯洁的颜色。凝视着这个颜色的同时，他仿佛也在凝视着你。显示的如此深邃，引人遐想。 这个颜色就是我们通过 Provider.of<AppTheme>(context,listen:true).primaryColor获取到的，我们打开AndroidStudio 的 DevTool 看一下当前widget的层级关系
通过上图可以发现
ColoredBox在深度为114的位置获取到了 从深度为2的Provider<AppTheme>的位置传递过来的颜色。也就是说 子widget可以获取到父widget使用provider管理的状态。这样就实现了一个基本的自上而下的状态传递。不过上面的代码有个问题，如果我想点击某个按钮来改变主题颜色，同时能刷新我当前的widget，那么我应该怎么做呢？对于这种状态的改变Provider显得力不从心，因为他无法改变状态。为了解决这个问题 ChangeNotifierProvider登场了。
ChangeNotifierProvider
为了解决能够随时更改状态的的问题，我们使用ChangeNotifierProvider来改造一下上面的代码。首先改造AppTheme这个类 我们给这个类添加一个 切换主题的方法 switchTheme
class AppTheme extends ChangeNotifier{ String theme; late Color primaryColor; AppTheme({ required this.theme, }){ _configTheme(); } void _configTheme(){ if(this.theme == "dark"){ primaryColor = Colors.black; } if(this.theme == "light"){ primaryColor = Colors.white; } } //用于切换主题 void switchTheme(){ this.theme = theme == "dark" ? "light" : "dark"; _configTheme(); notifyListeners(); } } 复制代码然后我们使用ChangeNotifierProvider作为我们的顶层widget,在右下角添加一个按钮用于调用 switchTheme 方法，达到切换主题的效果
void main() { runApp( ChangeNotifierProvider(create: (BuildContext context){ return AppTheme(theme: "dark"); }, child: MyApp(), ) ); } class MyApp extends StatelessWidget { const MyApp({Key? key}) : super(key: key); @override Widget build(BuildContext context) { return MaterialApp( home: Scaffold( appBar: AppBar( title: const Text('provider'), ), body: Center( child:Column( mainAxisAlignment: MainAxisAlignment.center, children: [ SizedBox( width: 300, height: 300, child: ColoredBox(color: Provider.of<AppTheme>(context,listen: true).primaryColor), ) ], ) ), floatingActionButton: FloatingActionButton( onPressed: (){ Provider.of<AppTheme>(context,listen: false).switchTheme(); }, ), ) ); } } 复制代码运行上面的代码，点击右下角的按钮。你会发现中间矩形的似乎要与背景融为一体，消失不见。但是仔细观察又显得若隐若现。如此单调的外表下， 谁又能知道他集所有颜色为一身。
在绝大多数的业务情况下，我们去管理一个可变的状态 使用ChangeNotifierProvider是可以满足我们的业务需求的，
ListenableProvider
这个类在实际的开发情况下用的比较少，因为ChangeNotifierProvider 基本上就能满足我们的需求了。在了解ListenableProvider 之前我们对比一下他和ChangeNotifierProvider的区别。请看下图
对比两个类我们可以看出来 ChangeNotifierProvider<T> 是继承了 ListenableProvider<T>, 而泛型 T ChangeNotifier 同样也实现了Listenable，这就说明 ChangeNotifierProvider 是对 ListenableProvider 一个更具体的实现。所以当 ChangeNotifierProvider 不能满足当前的业务需求的时候 你就需要自已实现 Listenable 这个抽象类，用于自己的业务，然后使用ListenableProvider 来管理这个状态。
FutureProvider和StreamProvider
从这个名字就可以看出来这两个provider是用于管理 异步情况下获取的状态。我们经常有这种业务场景，从服务获取数据然后转成model，最后刷新界面。那么从服务器请求网络数据这个过程是异步，如果直接使用 ChangeNotifierProvider 或者 Provider 那么可能处理不了这个业务。这个时候FutureProvider 和 StreamProvider 就派上用场了。
FutureProvider
同样还以跟新主题样式这个作为例子，假设当前用户的默认主题样式是 dark，然后需要从服务器获取light样式的主题，最后更新app。首先我们在 AppTheme 里面添加一个方法，用与请求服务器数据
class AppTheme { String theme; late Color primaryColor; AppTheme({ required this.theme, }) { _configTheme(); } void _configTheme() { if (this.theme == "dark") { primaryColor = Colors.black; } if (this.theme == "light") { primaryColor = Colors.white; } } ///从服务器获取主题样式 static Future<AppTheme> requestThemeStyle() async { Completer<AppTheme> _completer = Completer(); ///模拟请求从服务获取当前出题样式 await Future.delayed(Duration(seconds: 3), () { print(" 构造一个新的主题对象 用于更新当前正在显示的主题"); AppTheme _theme = AppTheme(theme: "light"); _completer.complete(_theme); }).catchError((_) { _completer.completeError("请求错误"); }); return _completer.future; } } 复制代码改造一下刚才的代码，使用FutureProvider获取服务器数据。在 initialData这个参数 我们传入一个默认的dark样式的主题。create方法用与请求服务器的数据
void main() { runApp(MyApp()); } class MyApp extends StatelessWidget { const MyApp({Key? key}) : super(key: key); @override Widget build(BuildContext context) { return FutureProvider<AppTheme>( create: (context){ return AppTheme.requestThemeStyle(); }, initialData: AppTheme(theme: "dark"), child: MaterialApp( home: Scaffold( appBar: AppBar( title: const Text('provider'), ), body: Center( child: Column( mainAxisAlignment: MainAxisAlignment.center, children: [ SizedBox( width: 300, height: 300, child: Builder(builder: (context) { return ColoredBox( color: Provider.of<AppTheme>(context, listen: true) .primaryColor); }), ) ], )), )), ); } } 复制代码执行上面的代码，你会看到3s以后，主题样式的变化。看到这里你可能会问，那如果我还想点击某个按钮，重新请求服务器数据，再次刷新当前主题呢？很遗憾 只依靠FutureProvider做不到，因为create方法，在生命周期之内只会被调用一次。无法再次执行requestThemeStyle方法。
我经常会有一种业务场景，就是用户从 A页面进入B页面，然后B页面请求网络数据，如果请求成功刷新页面，如果请求失败，我们再B页面上显示一个错误的图片并且提供一个重新加载按钮。获取用户可以下拉刷新重新发起请求。其实对于这种常见的业务，我们大可不必使用provider，因为我们要明白provider的重点是管理状态，而我们刚才描述的业务其实重点是如何获取状态。Flutter为了处理这种常见的业务情况其实提供了一个好用的组件叫做FutureBuilder 和 StreamBuilder，使用起来也是非常的简单。
StreamProvider
StreamProvider 和 FutureProvider的本质区别其实就是 Stream和Future的区别。两者都是dart给我们提供用于实现异步的方式。Future更侧重于单次获取数据，Stream的重点在于持续监听数据。上代码
这是一个计数器的demo,点击右下角的按钮，屏幕中央的数字就会+1。这个例子我特意用了 value的构造方式，value和create的区别会在下面详细说明.
ProxyProvider
这个类就厉害了，上面的ChangeNotifierProvider和ListenableProvider 和Provider都有Proxy的对应，比如说 ChangeNotifierProxyProvider ListenableProxyProvider。这个类主要用于如果你管理的状态有依赖关系。比如ModelA的构建需要用到ModelB，这个时候使用ProxyProvider在合适不过了。举个例子，张三正在上学，每个年龄段对应的年级都不一样，这时候如果我需要了解张三的年级信息，就需要知道张三的年龄，代码如下
然后我们通过
ProxyProvider来管理Student和School两个状态。
， 当
age增长的时候那么对应grade也在变化
这就是依赖状态。
MultiProvider 当我们有多个状态在同一层级的时候，嵌套的代码不太优雅，所以用MultiProvider来解决嵌套的问题
value 和 create 的区别
仔细观察你会发现上面所有的类的构造方法都提供了 value 和 create的构造方式.那这两种构造方式分别应该在什么情况下使用呢? 我就拿ChangeNotifierProvider为例，如下图
我们发现
value方式的构造 没有disppose方法。所以得到如下结论
使用
value方式的构造器，必须从外部传入一个已经创建好的对象，使用create方式的构造器，由create这个函数创建对象使用
value方式构造的状态，provider不管释放，使用create方式构造的状态，由provider管理释放。
根据内存管理的原则，对象谁创建谁释放，不要多管闲事。所以如果我想自己管理状态的生命周期，那么我们就使用 value这个构造器，如果我们希望provider销毁的时候 状态也随之销毁，由provider管理状态的生命周期，那么就使用create构造。
Consumer 到底是什么？
在上面所有的 Example中 我都没有用到Consumer,实际情况也可以不用。查看一下源码我们会发现 Consumer的本质其实就是 执行了Provider.of<T>(context,listen:true)这行代码。但是使用Consumer 我认为有两个好处
语义更加明确
你无需关心Provider.of<T>(context,listen:true)那个listen究竟什么时候传false什么收true。这个listen默认就是true。Consumer翻译成中文就是消费者的意思，也就是说哪里需要响应状态的变化(消费这个状态)哪里就使用Consumer包裹。 2. 确保使用的context就是当前需要响应变化的Widget对应的context，而不是父widget对应的cntext
也许你注意到我上面的代码Provider.of<T>(context,listen:true)有的会被Builder包裹，有的则没有。这样是为了避免意外使用了顶层被Provider包裹的context。
不过Provider 在4.1.0这个版本之后，就添加了context.watch<T>() 和 context.read<T>() 来表示listen=true 和 listen=false.可能作者认为使用watch 和 read能使语义更加明确。Consumer依然保留了下来。所以当你看到别人的代码里面有使用了 Consumer 或者是watch 和 read，你就知道这其中的缘由是什么了。
Selector 是什么？
在了解Selector 之前，我们要先了解使用 Consumer 会有什么问题？如下代码
当我点击右下角的按钮
Person这个类的年龄在增长，我只希望包裹年龄的的那个 Consumer被重新build 但是名字并没有变化，我不希望包裹名字的Consumer重新build。但实际情况确是两个都重新build了。这并不是我希望看到的，毕竟flutter中提高性能的原则之一就是避免无用的build。所以为了解决这个问题Selector应运而生了。 Selector有2个作用
避免无效的
build粒度控制数据
先看代码 运行上面代码你会发现当
age发生变化的时候 name不在build了。同时你可以根据你的业务情况，直接返回结果数据比如age或者name而不是直接返回Person对象。 在provider 4.1.0之后作者也提供了 context.select<T, R>(R cb(T value))方法，用于取代Selector，所以你也可以这样写
注意
Selector 这种写法的实现方式和使用context.select还是有区别的。
Selector这种方式是通过比较前后的值，如果一致那么直接返回内存缓存的对象，也就是源码中的Widget? cache。不一致则执行build方法context.select的实现流程相对来说有点复杂，简单来说如果通过对比前后的值一致那么就return了，啥也不执行，否则继续build。
这里有一个问题，就是如何比较前后两个值是否一致？
在provider最早期的版本里，就直接使用 !=简单粗暴的比较，在后来的版本中就使用了DeepCollectionEquality这个类用来比较两个值。哎，既然写到这了，那就顺便提一下，dart中是怎么比较两个值的。
dart 中如何比较两个值是否一致?
首先总结一下常用的数据类型
基本数据类型
intdouble字符串类型
String集合类型
SetMapListIterable自定义类型
基本数据类型就不聊了，直接比较大小就可以了。
==
对于String类型是判断每一个字符的 ASCII值，只要有一个不一致那么就返回false
对于
Map Set List Iterable 比较的是hasCode,那么这个hasCode又是咋生成的呢，是通过当前对象和一个随机数生成的。代码如下
对于自定义类型，你如果想要比较一致性要重载操作符
bool operator ==(Object other);,最好同时重写hasCode。因为==比较的不就是hasCode么。
DeepCollectionEquality
这个类主要是用于比较集合类型的数据，其他类型的比较和==是一致的。对于集合类型的数据MapSetListIterable。DeepCollectionEquality提供了一个equals的方法，用于比较集合中的每一个元素，都一样，返回true否则返回false。就拿Map为例
这种两个
for循环的写法，有利于降低时间复杂度，提高程序运行效率。
结尾
因为官方的example写的过于简单，也没有把所有用法都写出来。对于初次接触状态管理的小白来说不太友好，这篇文章写了所有Provider的用法和应用场景，希望能对你有所帮助。
作者：我做程序猿的那些年
链接：https://juejin.cn/post/7033707742929879076