关于android:Flutter-Riverpod-全面深入解析为什么官方推荐它

随着 Flutter 的倒退，这些年 Flutter 上的状态治理框架如“雨后春笋”般层出不穷，而 近一年以来最受官网举荐的状态治理框架无疑就是 Riverpod，甚至曾经超过了 Provider，事实上 Riverpod 官网也称本人为“Provider，但不同凡响”。

Provider 自身用它本人的话来说是“InheritedWidget 的封装，但更简略且复用能力更强。”，而 Riverpod 就是在 Provider 的根底上重构了新的可能。

对于过来一年状态治理框架的比照能够看《2021 年的 Flutter 状态治理：如何抉择？》，本文次要是带你解剖 RiverPod 的外部是如何实现，了解它的工作原理，以及如何做到比 Provider 更少的模板和不依赖 BuildContext。

前言

如果说 Riverpod 最显著的特点是什么，那就是内部不依赖 BuildContext (其实就是换了另外一种依赖状态)，因为不依赖 BuildContext，所以它能够比较简单做到相似如下的成果：

也就是 Riverpod 中的 Provider 能够随便写成全局，并且不依赖 BuildContext 来编写咱们须要的业务逻辑。

⚠️ 提前申明下，这里和后续的 Provider，和第三方库 provider 没有关系。

那 Riverpod 具体外部是怎么实现的呢？接下来让咱们开始摸索 Riverpod 的实现原理。

Riverpod 的实现绝对还是比较复杂，所以还急躁往下看，因为本篇是逐渐解析，所以如果看的过程有些蛊惑能够先不用在意，通篇看完再回过来翻阅可能就会更加清朗。

从 ProviderScope 开始

在 Flutter 里只有应用了状态治理，就肯定避不开 InheritedWidget，Riverpod 里也一样，在 Riverpod 都会有一个 ProviderScope，个别只须要注册一个顶级的 ProviderScope。

如果对于 InheritedWidget 还有疑难，能够看我掘金：《全面了解 State 与 Provider》

先从一个例子开始，如下图所示，是官网的一个简略的例子，能够看到这里：

• 嵌套一个顶级 ProviderScope；
• 创立了一个全局的 StateProvider；
• 应用 ConsumerWidget 的 ref 对创立的 counterProvider 进行 read 从而读取 State，获取到 int 值进行减少；
• 应用另一个 Consumer 的 ref 对创立的 counterProvider 进行 watch，从而读取到每次扭转后的 int 值；

很简略的例子，能够看到没有任何 of(context)，而全局的 counterProvider 里的数据，就能够通过 ref 进行 read/watch，并且正确地读取和更新。

那这是怎么实现的呢？counterProvider 又是如何被注入到 ProviderScope 外面？为什么没有看到 context？带着这些疑难咱们持续往下摸索。

首先咱们看 ProviderScope，它是惟一的顶级 InheritedWidget，所以 counterProvider 必然是被寄存在这里：

在 RiverPod 里，ProviderScope 最大的作用就是提供一个 ProviderContainer。

更具体地说，就是通过外部嵌套的 UncontrolledProviderScope 提供，所以到这里咱们能够晓得：ProviderScope 能够往下提供状态共享，因为它外部有一个 InheritedWidget，而次要往下共享的是 ProviderContainer 这个类。

所以首先能够猜想：咱们定义的各种 Providers，比方下面的 counterProvider，都是被存到 ProviderContainer 中，而后往下共享。

事实上官网对于 ProviderContainer 的定义就是：_用于保留各种 Providers 的 State，并且反对 override 一些非凡 Providers 的行为_。

ProviderContainer

这里呈现了一个新的类，叫 ProviderContainer，其实个别状况下应用 RiverPod 你都不须要晓得它，因为你不会间接操作和应用它，然而你应用 RiverPod 的每个行为都会波及到它的实现，例如：

• ref.read 会须要它的 Result read<Result>；
• ref.watch 会须要它的 ProviderSubscription<State> listen<State>；
• ref.refresh 会须要它的 Created refresh<Created>

就算是各种 Provider 的保留和读取根本也和它有关系，所以它作为一个对各种 Provider 的外部治理的类，实现了 RiverPod 里很要害的一些逻辑。

“Provider”和“Element”

那后面咱们晓得 ProviderScope 往下共享了 ProviderContainer 之后，Provider 又是怎么工作的呢？为什么 ref.watch/ ref.read 会能够读取到它 Provider 里的值？

持续后面的代码，这里只是定义了 StateProvider，并且应用了 ref.watch，为什么就能够读取到外面的 state 值？

首先 StateProvider 是一个非凡的 Provider，在它的外部还有一个叫 _NotifierProvider 的帮它实现了一层转换，所以咱们先用最根底的 Provider 类作为剖析对象。

根本是各种相似的 Provider 都是 ProviderBase 的子类，所以咱们先解析 ProviderBase。

在 RiverPod 外部，每个 ProviderBase 的子类都会有其对应的 ProviderElementBase 子类实现，例如后面代码应用的 StateProvider 是 ProviderBase 的之类，同样它也有对应的 StateProviderElement 是 ProviderElementBase 的子类；

所以 RiverPod 里根本是每一个“Provider”都会有一个本人的“Element”。

⚠️这里的“Element”不是 Flutter 概念里三棵树的 Element，它是 RiverPod 里 Ref 对象的子类。Ref 次要提供 RiverPod 内的“Provider”之间交互的接口，并且提供一些形象的生命周期办法，所以它是 RiverPod 里的独有的“Element”单位。

那“Provider”和“Element”的作用是什么？

首先，在下面例子里咱们 构建 StateProvider 时传入的 (ref) => 0，其实就是 Create<State, StateProviderRef<State>> 函数，咱们就从这个 Create 函数作为入口来摸索。

Create<T, R extends Ref> = T Function(R ref)

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

如果在下面代码的根底上减少了 <int> 就更显著，事实上后面咱们始终在说的 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 的即视感。

分步骤来说就是：

• 构建 Provider 时咱们传入了一个 Create 函数；
• Create 函数会被 ProviderElementBase 外部的 setState 所调用，失去一个 Reuslt；
• Reuslt 内的 requireState 就能够让咱们在应用 read() 的时候，获取到咱们定义的 泛型 State 的值。

WidgetRef

后面介绍了那么多，但还是没有说 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 的“魔法”之一。

read

所以后面咱们曾经理清了 ProviderScope、Provider、ProviderElementBase、ProviderContainer、ConsumerWidget（_ConsumerStatefulElement_）和 WidgetRef 等的关系和性能，那最初咱们就能够开始理分明 read 的整个工作链条。

咱们理清和晓得了 的概念与作用之后，联合 ref.read 来做一个流程剖析，那整体就是：

• ConsumerWidget 会通过外部的 ConsumerStatefulElement 获取到顶层 ProviderScope 内共享的 ProviderContainer；
• 当咱们通过 ref 调用 read/watch 时，其实就是通过 ConsumerStatefulElement 去调用 ProviderContainer 内的 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 外部：

• 1、首先会依据 read 时传入的 provider 构建失去一个 _StateReader；
• 2、以 provider 为 key，_StateReader 为 value 存入 _stateReaders 这个 Map，并返回 _StateReader；
• 3、通过 _StateReader 的 getElement() 获取或者创立到 ProviderElementBase；

这里的以 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<State>，次要在 FutureProvider 里应用。

AsyncValue

在 RiverPod 里失常状况下的 create 办法定义是如下所示：

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

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

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

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

autoDispose & family

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

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

其实 FutureProvider.autoDispose 次要就是 AutoDisposeFutureProvider，以此类推根本每个 Provider 都有本人的 autoDispose 实现，family 也是同理。

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

从名字能够看进去：

• AlwaysAliveProviderBase 是一只沉闷的；
• AutoDisposeProviderBase 天然就是不 listened 的时候就销毁；

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

简略了解就是用“完即焚烧”。

比方后面咱们介绍调用 read 的时候，都会调用 mayNeedDispose 去尝试销毁:

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

同样的 family 对应是 ProviderFamily，它的作用是：应用额定的参数构建 provider，也即是减少一个参数。

例如默认是把：

final tagThemeProvider  = Provider<TagTheme> 

能够变成

final tagThemeProvider2  = Provider.family<TagTheme, Color>

而后你就能够应用额定的参数，在 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<TagTheme, Color>' can't be assigned to the parameter type'ProviderListenable<dynamic>'. 

是的，因为这里是 Provider 嵌套 Provider，咱们先失去是的 ProviderFamily<TagTheme, Color>，所以咱们须要改为 ref.watch(tagThemeProvider2(Colors.red));。

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

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

这就波及到 Dart 语言的个性，如果有趣味能够看：juejin.cn/post/696836…

首先这里拿到的是一个 ProviderFamily<TagTheme, Color>，在 Dart 中所有函数类型都是 Function 的子类型，所以函数都固有地具备 call 办法。

咱们执行 tagThemeProvider2(Colors.red) 其实就是执行了 ProviderFamily 得 call 办法，从而执行了 create 办法，失去 FamilyProvider<State>，FamilyProvider 也就是 ProviderBase 的子类。

⚠️留神这里有点容易看错的中央，一个是 ProviderFamily，一个是 FamilyProvider，咱们从 ProviderFamily 外面失去了 FamilyProvider，作为 ProviderBase 给 ref.watch。

最初

很久没有写这么长的源码剖析了，人不知; 鬼不觉就写到了中午凌晨，其实相对来说，整个 Riverpod 更加简单，所以浏览起来也更加麻烦，然而应用起来反而会绝对更便捷，特地是 没有了 BuildContext 的限度，然而同时也是带来了 ConsumerWidget 的依赖，所有利弊只能看你本人的需要，然而整体 Riverpod 必定是一个优良的框架，值得一试。