Flutter Riverpod 全面深入解析，为什么官方推荐它？

RiverPod 里构建 “Provider” 时都会传入一个 Create 函数，而这个函数里一遍我们会写一些需要的业务逻辑，比如 counterProvider 里的 ()=> 0 就是初始化时返回一个 int 为 0 的值，更重要的是决定了 State 的类型。

如果在上面代码的基础上增加了 就更明显，事实上前面我们一直在说的 State 就是一个泛型，而我们定义 “Provider” 就需要定义这个泛型 State 的类型，比如这里的 int 。

回归到普通 Provider 的调用，我们传入的 Create 函数，其实就是在 ProviderElementBase 里被调用执行。

如上图所示，简单来说当 ProviderElementBase 执行 “setState” 时，就会调用 Create 函数，从而执行获取到我们定义的泛型 State，得到 Result 然后通知并更新 UI。

⚠️ 这里的 “setState” 也不是 Flutter Framework 里的 setState ，而是 RiverPod 内自己首先的一个 “setState” 函数，和 Flutter 框架里的 State 无关。

所以每个 “Provider” 都会有自己的 “Element” ，而构建 “Provider” 时是传入的 Create 函数会在 “Element” 内通过 setState 调用执行。

“Element” 里的 setState 主要是通过新的 newState 去得到一个 RiverPod 里的 Result 对象，然后通过 _notifyListeners 去把得到 Result 更新到 watch 的地方。

Result 的作用主要是通过 Result.data 、Result.error、 map 和 requireState 等去提供执行结果，一般情况下状态都是通过 requireState 获取，具体在 RiverPod 体现为:

我们调用 read() 时，其实最后都调用到 element.readSelf(); ，也就是返回 requireState （其实一般也就是我们的泛型 State） 。

是不是有点乱？

简单点理解就是：构建出 “Provider” 之后， “Element” 里会执行setState(_provider.create(this)); 调用我们传入的 Create 函数，并把 “Element” 自己作为 ref 传入进入，所以我们使用的 ref 其实就是 ProviderElementBase。

所以 RiverPod 里的起名是有原因的，这里的 “Provider” 和 “Element” 的关系就很有 Flutter 里 Widget 和 Element 的即视感。

分步骤来说就是：

前面介绍了那么多，但还是没有说 StateProvider 怎么和 ProviderScope 关联到一起，也就是 “Provider” 怎么和 ProviderContainer 关联到一起，凭什么 ref.read 就可以读到 State ？

那么前面代码里，我们用到的 ConsumerWidget 和 Consumer 都是同个东西，而这个 ref 就是前面我们一直说的 “Element” ，或者说是 ProviderElementBase 。

在源码里可以看到， ConsumerWidget 的逻辑主要在 ConsumerStatefulElement， 而ConsumerStatefulElement 继承了 StatefulElement，并实现了 WidgetRef 接口。

如上代码就可以看到前面很多熟悉的身影了： ProviderScope 、ProviderContainer 、 WidgetRef 。

首先我们看 ProviderScope.containerOf(this) ，终于看到我们熟悉的 BuildContext 有没有，这个方法其实就是以前我们常用的 of(context) ，但是它被放到了 ConsumerStatefulElement 使用，用于获取 ProviderScope 往下共享的 ProviderContainer。

所以我们看到了，ConsumerWidget 里的 ConsumerStatefulElement 获取到了 ProviderContainer ，所以 ConsumerStatefulElement 可以调用到 ProviderContainer 的 read/watch 。

然后回过头来看，ConsumerStatefulElement 实现了 WidgetRef 接口，所以 我们使用的 WidgetRef 就是 ConsumerStatefulElement 本身

也就是 ref.read 就是执行 ConsumerStatefulElement 的 read ， 从而执行到 ProviderContainer 的 read。

所以我们可以总结： BuildContext 是 Element ， 然后 Element 又实现了 WidgetRef ，所以此时的 WidgetRef 就是 BuildContext 的替代。

这里不要把 Flutter 的 Element 和 RiverPod 里的 “ProviderElementBase” 搞混了。

所以 WidgetRef 这个接口成为了 Element 的抽象，替代了 BuildContext ，所以这就是 Riverpod 的“魔法”之一 。

所以前面我们已经理清了 ProviderScope 、 Provider 、 ProviderElementBase、 ProviderContainer 、 ConsumerWidget（ConsumerStatefulElement） 和 WidgetRef 等的关系和功能，那最后我们就可以开始理清楚 read 的整个工作链条。

我们理清和知道了 的概念与作用之后，结合 ref.read 来做一个流程分析，那整体就是：

那最后就是 ProviderContainer 内的 read 函数如何读取到 State？

这就要结合前面我们同样介绍过的 ProviderElementBase ， 事实上 ProviderContainer 在执行 read 函数时会调用 readProviderElement 。

readProviderElement 顾名思义就是通过 Provider 去获取到对应的 Element，例如 ：

ref.read(counterProvider),

一般情况下 read/watch 简单来说就是从 ProviderContainer 里用 proivder 做 key 获取得到 ProviderElementBase 这个 “Element”，这个过程又有一个新的对象需要简单介绍下，就是：_StateReader。

readProviderElement 其中一个关键就是获取 _StateReader ，在 ProviderContainer 里有一个 _stateReaders 的内部变量，它就是用于缓存 _StateReader 的 Map 。

所以在 ProviderContainer 内部：

这里的以 ProviderBase 为 Key ， _StateReader 为 value 存入 _stateReaders ，其实就是把 “provider” 存入到了 ProviderContainer，也就是和 ProviderScope 关联起来，也就是自此 “provider” 和 ProviderScope 就绑定到一起。

没用使用到明面上的 BuildContext 和多余的嵌套，就让 Provider 和 ProviderScope 关联起来。
另外这里可以看到，在 ref.read 时，如何通过 provider 构建或者获取到 ProviderElementBase。

得到 ProviderElementBase 还记得前面我们介绍 “Provider” 和 “Element” 的部分吗？ProviderElementBase 会调用 setState 来执行我们传入的 Create 函数，得到 Result 返回 State 。

可以看到，这里获取的 ProviderElementBase 之后 return element.readSelf() ，其实就是返回了 requireState 。

自从整个 RiverPod 里最简单的 ref.read 流程就全线贯通了：

ProviderScope 往下共享 ProviderContainer ；

ConsumerWidget 内部的 ConsumerStatefulElement 通过 BuildContext 读取到 ProviderContainer， 并且实现 WidgetRef 接口；

通过 WidgetRef 接口的 read(provider) 调用到 ProviderContainer 里的 read；

ProviderContainer 通过 read 方法的 provider 创建或者获取得到 ProviderElementBase

ProviderElementBase 会执行 provider 里的 Create 函数，来得到 Result 返回 State ；

其他的watch，refresh 流程大同小异，就是一些具体内部实现逻辑更复杂而已，比如刷新时：

通过 ref.refresh 方法， 其实触发的就是 ProviderContainer 的 refresh ，然后最终还是会通过 _buildState 去触发 setState(_provider.create(this)) 的执行。

而从这个流程分析，也看到了 RiverPod 如何不暴露使用 BuildContext 实现全线关联的逻辑。

前面基本介绍完整个调用流程，这里在额外介绍一些常见的调用时如何实现，比如在 Riverpod 里面会看到很多 “Element” ，比如 ProviderElement 、StreamProviderElement 、 FutureProviderElement 等这些 ProviderElementBase 的子类。

我们结果过它们并不是 Flutter 里的 Element ，而是 Riverpod 里的的 State 单位，用于处理 Provider 的状态，比如 FutureProviderElement 就是在 ProviderElementBase 的基础上提供一个 AsyncValue，主要在 FutureProvider 里使用。

在 RiverPod 里正常情况下的 create 方法定义是如下所示：

而在 FutureProvider 下是多了一个 _listenFuture，这个 Function 执行后的 value 就会是 AsyncValue 的 State 类型。

从 _listenFuture 的执行上看， 内部会对这个 future() 执行，会先进入 AsyncValue.loading() 之后，根据 Future 的结果返回决定返回AsyncValue.data 或者 AsyncValue.error 。

所以比如在 read / watch 时，返回的泛型 requireState 其实变成了 AsyncValue。

而针对 AsyncValue 官方做了一些 extension ，在 AsyncValueX 上，其中出了获取 AsyncData 的data \ asData 和 T value 之外，最主要提供了起那么所说的不同状态的构建方法，比如 when 方法：

在 Riverpod 里应该还很常见一个叫 autoDispose 和 family 的静态变量，几乎每个 Provider 都有，又是用来干什么的呢？

举个例子，前面代码里我们有个 FutureProvider， 我们用到了里的 autoDispose：

其实 FutureProvider.autoDispose 主要就是 AutoDisposeFutureProvider ，以此类推基本每个 Provider 都有自己的 autoDispose 实现，family 也是同理。

如果说正常的 Provider 是继承了 AlwaysAliveProviderBase，那 AutoDisposeProvider 就是继承于 AutoDisposeProviderBase :

从名字可以看出来：

也就是内部 _listeners 、_subscribers、_dependents 都是空的时候，当然它还有另外一个 maintainState 的控制状态，默认它就是 false 的时候，就可以执行销毁。

简单理解就是用“完即焚烧” 。

比如前面我们介绍调用 read 的时候，都会调用 mayNeedDispose 去尝试销毁:

销毁也就是调用 element.dispose()和从 _stateReaders 这个 map 里移除等等。

同样的 family 对应是 ProviderFamily，它的作用是：使用额外的参数构建 provider ，也即是增加一个参数。

例如默认是把 ：

final tagThemeProvider  = Provider 

可以变成

final tagThemeProvider2  = Provider.family

然后你就可以使用额外的参数，在 read/watch 的时候 ：

final questionsCountProvider = Provider.autoDispose((ref) {
  return ref
      .watch(tagThemeProvider2(Colors.red));
});

之所以可以实现这个功能，就要看它的实现 ProviderFamily ，对比一般 Provider 默认的 create ，ProviderFamily 的是：

可以看到 create 的是新的一个 Provider，也就是 family 下其实是 Provider 嵌套 Provider。

所以从上面的例子出发，以前我们是通过 ref.watch(tagThemeProvider);就可以了，因为我们的 tagThemeProvider 的直接就是 ProviderBase。

但是如果使用 ref.watch(tagThemeProvider2); 就会看到错误提示

The argument type 'ProviderFamily' can't be assigned to the parameter type 'ProviderListenable'. 

是的，因为这里是 Provider 嵌套 Provider ，我们先得到是的 ProviderFamily ，所以我们需要改为 ref.watch(tagThemeProvider2(Colors.red)); 。

通过 tagThemeProvider2(Colors.red) 执行一次变为我们需要的 ProviderBase。

那 tagThemeProvider2 这个 ProviderFamily 为什么是这样执行？ ProviderFamily 明明没有这样的构造函数。

这就涉及到 Dart 语言的特性，如果有兴趣可以看 ： https://juejin.cn/post/6968369768596242469

首先这里拿到的是一个 ProviderFamily ，在 Dart 中所有函数类型都是 Function 的子类型，所以函数都固有地具有 call 方法。

我们执行 tagThemeProvider2(Colors.red) 其实就是执行了 ProviderFamily 得 call方法，从而执行了 create 方法，得到 FamilyProvider ，FamilyProvider 也就是 ProviderBase 的子类 。

⚠️注意这里有点容易看错的地方，一个是 ProviderFamily ， 一个是 FamilyProvider， 我们从 ProviderFamily 里面得到了 FamilyProvider， 作为 ProviderBase 给 ref.watch 。

很久没有写这么长的源码分析了，不知不觉就写到了半夜凌晨，其实相对来说，整个 Riverpod 更加复杂，所以阅读起来也更加麻烦，但是使用起来反而会相对更便捷，特别是没有了 BuildContext 的限制，但是同时也是带来了 ConsumerWidget 的依赖，所有利弊只能看你自己的需求，但是整体 Riverpod 肯定是一个优秀的框架，值得一试。