点击右上角关注开源中国OSC头条号，获取最新技术资讯。

前言

Provider 被设计为ScopedModel 的替代品，使我们能够更灵活地处理数据类型和数据。但首先，我们来谈谈陈词滥调的国家管理。

为什么需要状态管理

当我们第一次构建应用程序时，它可能很简单。我们有一些状态，只需将它们直接映射到视图即可。这样一个简单的应用程序可能不需要状态管理。

但随着功能的增加，您的应用程序将具有数十种甚至数百种状态。此时您的应用程序应该如下所示。

这时候我们就迫切需要一个结构来帮助我们理清这些关系，状态管理框架就应运而生了。

什么是提供

与Scoped_model 一样，Provide 也使用InheritWidget 将共享状态放置在顶级MaterialApp 之上。底层组件通过Provier获取这个状态，并通过混合的ChangeNotifier通知依赖这个状态的组件进行刷新。

Provide还提供了Provide.stream，它允许我们以流的方式处理数据。但仍然存在一些问题，不推荐使用。

Lets do it！

这里我们以一个简单的应用程序为例，详细介绍Provide的使用方法。这就涉及到共享状态以及如何管理多个状态。

两个页面都依赖于计数器和切换器的两种不同状态。并且当一个页面改变状态后，另一页面的状态也会相应改变。

项目完整代码已放在Github上

第1 步：添加依赖项

在pubspec.yaml 中添加Provide 依赖项。

实际添加请参考：https://pub.dartlang.org/packages/provide#-installing-tab - 如果由于版本冲突导致添加失败，请参考： https://juejin.im/post/5b8958d351882542b03e6d57 第二步：创建模型

这里它实际上承担了State的职责，但称为model是为了与正式的State相区别。

导入'package:flutter/material.dart';带有ChangeNotifier 的类计数器{ int value=0;增量（）{值++;通知监听器（）； }}这里我们可以看到数据和操作数据的方法都在模型中，我们可以把业务清晰的分开。

对比Scoped_model，我们可以发现Provide模式下的模型不再需要继承Model类，而只需要实现Listenable即可。我们在这里混合了ChangeNotifier，所以不需要管理监听器。

通过notifyListeners我们可以通知监听器刷新。

步骤3：将状态置于顶层

无效主（）{

var 计数器=Counter();

var 提供者=提供者();

//将计数器对象添加到提供者

provider.provide(ProviderCounter.value(counter));

运行应用程序（

提供者节点(

child: MyApp(),

提供商：个提供商），

）；

}

ProviderNode封装了InheritWidget并提供了一个用于放置状态的providers容器。

Providers内部通过MapType和Providerdynamic存储Providers。存储时，可以通过传入ProviderScope('name')来指定key。

ProviderCounter.value 将计数器包装到_ValueProvider 中。并且它内部提供了一个StreamController来实现对数据的流式操作。

第4 步：获取状态

同样Provide也提供了两种获取State的方法。我们先介绍第一个，通过ProvideT小部件获取。

ProvideCounter( builder: (context, child, counter) { return Text( '${counter.value}', style: Theme.of(context).textTheme.display1, ); }, )，每次刷新通知数据时， builder 将重建小部件。

构建器方法接收三个参数。这里主要介绍第二个和第三个参数。

第二个参数child：如果这个widget足够复杂，并且内部的一些widget不会改变，那么我们可以将这些widget写在Provide的child属性中，这样构建器就不会重复创建这些widget。以提高性能。第三个参数counter：这个参数代表我们获取到的顶级provider中的状态T。 scope：通过指定ProviderScope获取key对应的状态。当需要使用同一类型的多个状态时使用。

第二种获取方式：Provide.valueT(context)

最终currentCounter=Provide.valueCounter(context);这个方法实际上是调用context.inheritFromWidgetOfExactType来查找顶级_InheritedProviders来获取顶级provider中的状态。

如何组织多个状态

与scoped_model不同，在提供模式下您可以轻松组织多个状态。只需向提供商提供状态即可。

void main() { var counter=Counter(); var switcher=Switcher(); var 提供者=提供者();提供商.provide(ProviderCounter.value(counter)) .provide(ProviderSwitcher.value(switcher)); runApp( ProviderNode( child: MyApp(),providers:providers) );} 获取数据流

包装器在向提供者添加计数器的过程中执行。我们刚刚通过分析源码得知，这个操作可以让我们处理流数据。

数据流可以通过Provide.streamT(context)获取。

StreamBuilderCounter(initialData: currentCounter，stream: Provide.streamCounter(context) .where((counter)=counter.value % 2==0), builder: (context, snapshot)=Text('最后一个偶数值： ${snapshot.data.value} '))，但在我的使用中，streamTransformer 失败了。将相同的代码应用于firstScreen和secondScreen。第二屏的where方法可以生效，过滤掉奇数数据，而第一屏接收完整的数据。具体原因还没找到，但是可以肯定这个流是广播流。如果我的理解有问题，还请大家指出，谢谢。

Provide功能还可以和rxdart结合使用，让我们可以更灵活地组织数据，用起来非常有趣。

基于多个状态重建小部件

当视图可能依赖于多个状态进行重建时，可以使用ProvideMulti 小部件。

写在最后

距离上次写状态管理扩展文章Rxdart已经过去三个月了。很久没有发表总结了，在此表示歉意。对于我来说，状态管理本身就是一个新事物，所以任何没有经过大规模应用测试的总结都是空谈。这也是我很久没有开始写总结的原因。但在这里我可以分享一些自己的感受，供大家参考。

在过去的几个月里，我更多地使用了BLoC。它在组织数据方面确实非常灵活，可以轻松实现延迟加载等操作。此外，编写的有状态小部件越来越少。缺点是入门门槛比较高，我花了很多时间才了解StreamTransformer以及为什么需要pipe。使用集体思维需要进行重大改变。我见过很多人在项目中使用bloc，但是他们用的很奇怪，而且还在用以前的思维模式来思考。而且，bloc仅组织数据。 InheritWidget通常用于共享状态，这确实需要大量额外的工作。

其次，我更喜欢scoped_model，因为它简单易用。学习成本很低，而且没有模板代码可写。

我最不想使用的状态管理方法是redux。一是上手比较困难，而且异步数据处理我也觉得比较麻烦。不过闲鱼团队很喜欢redux，未来会开源闲鱼的状态管理框架fish_redux。所以，可能是我写的应用程序还不够复杂，所以我才会有这样的感觉。 Redux可以在复杂的应用中更清晰地划分职责，并且单向的数据流和状态是不可变的特性，这些都是redux的好处。

最后我要谈谈Provide。 Provide 给我的整体体验和Scoped 非常接近，简单易用，功能也更强大。模型不再需要继承，只需实现Listenable即可使其不再具有侵入性。同时增加了stream的特性，有点类似于bloc。如果您使用过Scoped_model，您会很快上手。

但可以说的是，Provide是一种非常优秀的状态管理方法，值得使用。