关于flutter:Flutter状态管理-BLoCScopedModel和Provider的对比

Flutter的运行也是基于状态的变动触发绘制的。所以，Flutter开发个别是离不开这个主题的。

最常见的就是应用StatefulWidget和setState。然而，这样的用法无奈满足日渐增长的页面数量和暗藏在这些页面里的越来越简单的业务逻辑。于是，各路大神开发除了与之配套的模式和响应的库来简化App的状态治理。其中最显著的几个模式别离是BLoC、ScopedModel和Provider。上面咱们就一一的剖析和比照他们的异同。以此来帮忙开发者抉择适合的模式和库。

示例

本文中所应用的示例是Flutter Sample的Provider shopper, 这里能够看到。运行成果是这样的：

运行的成果是齐全一样的，只是在Provider的局部还是少许做了一点批改。本例应用的代码是为了表明Provider的一些根底用法。同一套代码适配到不同的模式下，才更有比照的价值。实现同一个性能，在不同的模式下该如何操作，不同点、共同点都特地显著。

笔者也是初学者，对各种模式的了解不免有不到位的中央。欢送各位读者指出谬误，或者一起探讨。

BLoC

这是一个模式，也有对应库。它最显著的特点就是有“流”。所以，要应用BLoC就要学会流。

说道流就会有很多的读者想到响应式编程。没错这的确是响应式编程的概念，不过Dart有本人的一套流的实现。咱们来具体关注一下Dart的实现。这里补充一点，如果你想用ReactiveX的一套实现也是没有问题的。

应用流控制器解决数据

Dart提供了一个叫做StreamController的类来治理流（Stream）。流控制器（StreamController）会放出一个两个成员来共开发者应用，别离能够读取流外面的值，或者向流增加数据。开发者能够通过StreamController#Stream实例来读取数据，通过StreamController#Sink`实例来增加数据。

在一个ViewModel里如何应用流控制器：

/// 这里去掉了不必要的代码class CartBloc extends BaseBloc {  // 实例化流控制器  final _controller = StreamController<Item>.broadcast();  // Stream间接作为public属性裸露进来  Stream<Item> get stream => _controller.stream;  void addItem(Item item) {    // 应用Sink增加数据    _controller.sink.add(item);  }  @override  void dispose() {    // 敞开流控制器，开释资源    _controller.close();  }}

在这个类外面，首先示例话了一个流控制器：final _controller = StreamController<Item>.broadcast();。申明了一个应用了一个stream getter：Stream<Item> get stream => _controller.stream;把流裸露给里面应用。同时有一个办法addItem用来接管新增加的数据，并在其外部实现里应用_controller.sink.add(item)增加数据。

在示例化流控制器的时候，是这样做的：StreamController<Item>.broadcast()。应用到了broadcast()。这里也能够是stream()。然而stream仅反对一个监听者，如果存在多个监听者的时候就会抛异样了。所以，个别都是应用stream()取得流控制器实例，如果有多个监听者的时候再应用broadcast()。简略说，就是始终用stream()直到呈现多个监听者报错的时候换boradcast()。

stream和sink基本上能够了解为一个管子的中间。应用sink给这个管子假数据，数据流过这个管子之后能够通过stream拿到数据。

应用StreamBuilder显示流数据

流控制器解决好数据之后，就要在界面上把数据展示进去。

Flutter提供了StreamBuilder来展现流的数据。代码如下：

  Widget build(BuildContext context) {    return Scaffold(        // StreamBuilder，须要一个stream，和一个builder        body: StreamBuilder<CatalogModel>(            stream: BlocProvider.of<CatalogBloc>(context).stream,            builder: (context, snapshot) {              // 数据能够从snapshot.data拿到              CatalogModel catalog = snapshot.data;              return CustomScrollView(                // 此处省略              );            }));  }

应用StreamBuilder只须要给它一个Stream和一个Builder办法即可。在获取每个传入给StreamBuilder的Stream的时候还有更加简化的办法。

本文应用了Flutter - BLoC模式入门所介绍的办法来实现Stream和StreamBuilder的连接。或者能够说应用了上文所述的办法简化了在Widget里获取流的办法。而没有应用BLoC库来简化。当然，有趣味的话你能够试着用bloc库从新实现一次下面的例子。

是先BLoC的整体流程

在后面的形容中，只是充电介绍了和BLoC间接相干的内容：流和StreamBuilder。如果要真正的开发一个App个别遵循的是MVVM的模式。

在定义ViewModel的时候须要管制粒度。因为，你不想一个简略的数据变动让整个页面都进入绘制周期，粒度管制个别是只让有关联的最小组件树从新绘制。个别是一个页面一个ViewModel，当然能够更小到如果网络申请，loading，数据展现都在一个按钮的的话，那么这个ViewModel也能够只在这个按钮上应用。

首先，要有实体类。这样能够结构化的把数据展现进去。

class CartModel {  /// The private field backing [catalog].  CatalogModel _catalog;  /// Internal, private state of the cart. Stores the ids of each item.  final List<int> _itemIds = [];  /// The current catalog. Used to construct items from numeric ids.  CatalogModel get catalog => _catalog;  set catalog(CatalogModel newCatalog) {    assert(newCatalog != null);    assert(_itemIds.every((id) => newCatalog.getById(id) != null),        'The catalog $newCatalog does not have one of $_itemIds in it.');    _catalog = newCatalog;  }  /// List of items in the cart.  List<Item> get items => _itemIds.map((id) => _catalog.getById(id)).toList();  /// The current total price of all items.  int get totalPrice =>      items.fold(0, (total, current) => total + current.price);  void add(Item item) {    _itemIds.add(item.id);  }}

定义ViewModel，并应用StreamBuilder展现数据

简洁版的形式在上文中曾经有提到过了。在ViewModel中定义也无逻辑相干的局部，以及：

裸露流给Widget应用
在更新数据的办法中应用Sink增加数据
开释资源

应用BlocProvider不便取得ViewModel

在Widget树种，StreamBuilder经常出现在靠近叶子节点的局部，也就是在Widget树比拟深的局部。最间接的体现就是它会呈现在十分扩散的文件中。每个StreamBuilder都须要ViewModel提供的流来展现数据。那么流的申明也要随着StreamBuilder呈现在这些扩散的文件中。更让代码难以保护的是，ViewModel实例将会从Widget树的根部始终传递到每个StreamBuilder。

BlockProvider正式来解决这个问题的，它就是胶水，让ViewModel里的流和StreamBuilder更好的联合在一起。在Widget中应用StreamBuilder如何可能让子Widget树不便的取得曾经实例化好的ViewModel呢？

先来看看这个胶水怎么起作用的。在main.dart里：

class MyApp extends StatelessWidget {  // This widget is the root of your application.  @override  Widget build(BuildContext context) {    // In this app, catalog will never change.    // But if catalog changes, the new catalog would pass through `snapshot`.    return BlocProvider<CatalogBloc>(      bloc: CatalogBloc(),      child: BlocProvider<CartBloc>(        bloc: CartBloc(),        child: MaterialApp(          title: 'Provider Demo',          theme: appTheme,          initialRoute: '/',          routes: {            '/': (context) => MyLogin(),            '/catalog': (context) => MyCatalog(),            '/cart': (context) => MyCart(),          },        ),      ),    );  }}

每个BlocProvider初始化的时候须要一个ViewModel和一个child，子组件。多个BlocProvider能够嵌套应用。在须要用到ViewModel实例的流的时候只须要一个静态方法就能够实现。

body: StreamBuilder<CatalogModel>(    stream: BlocProvider.of<CatalogBloc>(context).stream,    builder: (context, snapshot) {        return CustomScrollView(        );}));

只须要BlocProvider.of<CatalogBloc>(context)就能够取得ViewModel实例，同时就能够间接拿到stream了。

最初，为什么BlocProvider用到StatefulWidget呢？在本例中是为了能够应用这个类的dispose办法。

class _BlocProviderState extends State<BlocProvider> {  @override  Widget build(BuildContext context) => widget.child;  @override  void dispose() {    widget.bloc.dispose();    super.dispose();  }}

原理和本文的关系不是很大，有趣味的同学能够移步blocs/bloc_provider.dart。

ScopedModel

在开始ScopedModel之前先做一下回顾。流在BLoC模式中的作用就是应用Sink承受数据的变动，再通过Stream联合StreamBuilder展示在界面上，从而达到状态治理的成果。ScopedModel也有相似的机制。只是更加简略，没有用到流，那么对于初学者来说也就不须要花工夫去另外学习流的常识。

通用的开发模式也是MVVM。在咱们定义好与网络申请、本地存储对应的实体类之后就能够定义VM了。

在ScopedModel里咱们用了scoped_model库。在每个VM里继承Model之后就领有了登程状态变更的能力。

import 'package:scoped_model/scoped_model.dart';class BaseModel extends Model {}import 'base_model.dart';// 略掉了其余的impoortclass CartModel extends BaseModel {  // 略掉局部成员定义  set catalog(CatalogModel newCatalog) {    // 告诉状态变更    notifyListeners();  }  void addItem(Item item) {    assert(_cartInfo != null);    // 告诉状态变更    notifyListeners();  }}

下面的例子中，首先定义了一个BaseModel，每个对应的VM继承BaseModel之后能够在数据产生变更的时候应用notifyListeners办法来告诉状态产生了变动。

看起来在View Model的定义上简化了很多。那么状态的变动如何体现在界面上呢？咱们来看一下scoped_model_tutorial/lib/main.dart：

class MyApp extends StatelessWidget {  // This widget is the root of your application.  @override  Widget build(BuildContext context) {    return ScopedModel<CatalogModel>(      model: CatalogModel(),      child: ScopedModel<CartModel>(        model: CartModel(),        child: MaterialApp(            // 略        ),      ),    );  }}

提供View Model对象的形式根本一样，而且都存在嵌套的问题，至多是写法上。

代替StreamBuilder组件的就是ScopedModelDescendant组件了。

class MyCatalog extends StatelessWidget {  @override  Widget build(BuildContext context) {    return Scaffold(body: ScopedModelDescendant<CatalogModel>(builder: (context, child, model) {      CatalogModel catalog = model;           return CustomScrollView(        // 略      );    }));  }}

ScopedModelDescendant承受一个类型参数和一个builder办法，在这个办法的三个参数中，第三个就是类型参数的model实例。

如果不是在组成界面的时候须要用到model的实例要如何解决呢？看代码：

final cartBloc = ScopedModel.of<CartModel>(context);

只须要ScopedModel.of<CartModel>()办法即可。

ScopedModel应用notifyListeners()办法简化掉了BLoC模式中须要用到的流。只是在为界面提供ViewModel实例的时候仍然没有解脱嵌套的写法。上面来看下Provider模式能为开发者带来什么。

Provider

Provider模式里发动状态变更的仍然是ViewModel里的notifyListeners办法。咱们来看一下具体的实现步骤：

首先，咱们要思考引入Provider库了。具体步骤能够参考这里的文档。

接着来实现ViewModel。比方有一个CartModel，能够写成：

import 'catalog.dart';class CartModel extends ChangeNotifier {  CatalogModel _catalog;  final List<int> _itemIds = [];  CatalogModel get catalog => _catalog;  set catalog(CatalogModel newCatalog) {    _catalog = newCatalog;    notifyListeners();  }  List<Item> get items => _itemIds.map((id) => _catalog.getById(id)).toList();  int get totalPrice =>      items.fold(0, (total, current) => total + current.price);  void add(Item item) {    _itemIds.add(item.id);    notifyListeners();  }}

这里的ViewModel的实现十分之简略，只须要继承ChangeNotifier就能够失去notifyListeners办法。在须要扭转状态的中央调用这个办法即可。

把ViewModel粘到Widget树里。这部分须要关注一下lib/main.dart。

class MyApp extends StatelessWidget {  @override  Widget build(BuildContext context) {    // Using MultiProvider is convenient when providing multiple objects.    return MultiProvider(      providers: [        Provider(create: (context) => CatalogModel()),        ChangeNotifierProxyProvider<CatalogModel, CartModel>(          create: (context) => CartModel(),          update: (context, catalog, cart) {            cart.catalog = catalog;            return cart;          },        ),      ],      child: MaterialApp(        title: 'Provider Demo',          // 略      ),    );  }}

在界面中显示数据。有两种办法, 一种是应用Consumer，另一种是应用Provider.of()办法：

应用Consumer的形式：

Consumer<CartModel>(    builder: (context, cart, child) =>        Text('\?{cart.totalPrice}', style: hugeStyle))

Consumer会把ViewModel的实例传入到它的builder办法里。也就是上例中builder办法的第二个参数。这个时候再ViewModel发生变化的时候Consumer和它上面的子树就回重绘。

应用Provider.of()的形式：
在Consumer外部实现也是用的这个形式。代码如下：

class Consumer<T> extends SingleChildStatelessWidget {  @override  Widget buildWithChild(BuildContext context, Widget child) {    return builder(      context,      // 这里应用了`Provider.of`办法      Provider.of<T>(context),      child,    );  }}

在应用这个形式的时候须要留神一点，在传递参数的时候思考到只是须要获取这个view model实例，那么就须要屏蔽掉默认的注册行为，所以是这么用的：

var cart = Provider.of<CartModel>(context, listen: false);

listen: false就是用来屏蔽注册组件这个默认行为的。咱们要屏蔽的性能就是Consumer所领有的的，在状态变动之后重绘的性能。

这里有一个默认的，或者说是约定的做法。如果须要Provider下的某个子树在状态变动之后重绘，那么将这个子树放在Consumer组件下。如果只是把view model实例的数据读出来，或者触发状态变更，那么就用Provider.of<T>(context, listen: false)。间接在调用的时候屏蔽默认行为。

另外

Provider库还定义了另外一种更加简洁的形式。provider库用extension给Context增加了一些办法能够疾速的读取view model实例，或者读取的时候并注册组件响应状态更新。

context.watch<T>()：注册组件响应状态变更
context.read<T>()：只读取view model实例
context.select<T, R>(R cb(T value))：容许组件至相应view model的一个子集的变更

更多能够参考文档。

不同的Provider

最罕用的Provider都曾经呈现在下面的例子中了。

每个App里失常不会只有一个Provider，为了解决这个问题就有了MultiProvider。在providers数组里塞满app用到的provider即可。

    MultiProvider(      providers: [        Provider(create: (context) => CatalogModel()),        ChangeNotifierProxyProvider<CatalogModel, CartModel>(          create: // 略,          update: // 略，        ),      ]    )

它的外部还是嵌套的，只不过在写法上是一个数组。数组里的provider，从头到尾别离嵌套的从深到浅。

Provider只能提供一个ViewModel实例，没法响应状态的变动。在本例中这么用只是表明Cart对Catalog有依赖。

ChangeNotifierProvider

这是最罕用的一个provider类型，它的作用就是让view model的变动能够反映在界面上。只有在view model类里继承ChangeNotifier（作为mixin应用亦可），并在批改数据的办法里应用notifyListeners()办法。

ProxyProvider

当两个view model之间存在依赖关系的时候应用这个类型的provider。

ChangeNotifierProxyProvider

前两个类型的和就是ChangeNotifierProxyProvider。也是咱们在下面的代码里应用的provider类型。本类型和ProxyProvider的不同之处在，本类型会发送更新到ChangeNotifierProvider，ProxyProvider会把更新发送给Provider。

最重要的是，ProxyProvider不会监听任何的变动，而ChangeNtofierProxyProvider能够。

StreamProvider

StreamProvider能够简略的了解为是对StreamBulder的一层封装。如：

import 'package:flutter/material.dart';import 'package:provider/provider.dart';void main() => runApp(MyApp());class MyApp extends StatelessWidget {  @override  Widget build(BuildContext context) {    return StreamProvider<MyModel>( //                       <--- StreamProvider      initialData: MyModel(someValue: 'default value'),      create: (context) => getStreamOfMyModel(),      child: MaterialApp(        home: Scaffold(          appBar: AppBar(title: Text('My App')),          body: Row(            mainAxisAlignment: MainAxisAlignment.center,            children: <Widget>[              Container(                padding: const EdgeInsets.all(20),                color: Colors.green[200],                child: Consumer<MyModel>( //                    <--- Consumer                  builder: (context, myModel, child) {                    return RaisedButton(                      child: Text('Do something'),                      onPressed: (){                        myModel.doSomething();                      },                    );                  },                )              ),              Container(                padding: const EdgeInsets.all(35),                color: Colors.blue[200],                child: Consumer<MyModel>( //                    <--- Consumer                  builder: (context, myModel, child) {                    return Text(myModel.someValue);                  },                ),              ),            ],          ),        ),      ),    );      }}Stream<MyModel> getStreamOfMyModel() { //                        <--- Stream  return Stream<MyModel>.periodic(Duration(seconds: 1),          (x) => MyModel(someValue: '$x'))      .take(10);}class MyModel { //                                               <--- MyModel  MyModel({this.someValue});  String someValue = 'Hello';  void doSomething() {    someValue = 'Goodbye';    print(someValue);  }}

FutureProvider

FutureProvider也是对FutureBuilder的一层封装。如：

import 'package:flutter/material.dart';import 'package:provider/provider.dart';void main() => runApp(MyApp());class MyApp extends StatelessWidget {  @override  Widget build(BuildContext context) {    return FutureProvider<MyModel>( //                      <--- FutureProvider      initialData: MyModel(someValue: 'default value'),      create: (context) => someAsyncFunctionToGetMyModel(),      child: MaterialApp(        home: Scaffold(          appBar: AppBar(title: Text('My App')),          body: Row(            mainAxisAlignment: MainAxisAlignment.center,            children: <Widget>[              Container(                padding: const EdgeInsets.all(20),                color: Colors.green[200],                child: Consumer<MyModel>( //                    <--- Consumer                  builder: (context, myModel, child) {                    return RaisedButton(                      child: Text('Do something'),                      onPressed: (){                        myModel.doSomething();                      },                    );                  },                )              ),              Container(                padding: const EdgeInsets.all(35),                color: Colors.blue[200],                child: Consumer<MyModel>( //                    <--- Consumer                  builder: (context, myModel, child) {                    return Text(myModel.someValue);                  },                ),              ),            ],          ),        ),      ),    );      }}Future<MyModel> someAsyncFunctionToGetMyModel() async { //  <--- async function  await Future.delayed(Duration(seconds: 3));  return MyModel(someValue: 'new data');}class MyModel { //                                               <--- MyModel  MyModel({this.someValue});  String someValue = 'Hello';  Future<void> doSomething() async {    await Future.delayed(Duration(seconds: 2));    someValue = 'Goodbye';    print(someValue);  }}

StreamProvider和FutureProvider都是对于某些非凡状况的定制的Provider，在平时应用Provider模式的时候对于返回数据的Future和Stream状况做专门的解决，能够让开发者少些很多自定义代码。

总结

BLoC模式在应用前须要对流或者更大的一点说，须要对响应式编程有肯定的了解。咱们这里给出的例子还在十分根底的阶段，尽管在尽量靠近产品级别，然而还是有差距。所以看起来非常简单。如果你想用这个模式，那么最好能多花工夫钻研一下响应式编程。

ScopedModel曾经成为历史。各位也看到，它和Provider的写法很靠近。那是因为后者就是从ScopedModel进化来的。ScopedModel曾经实现了它的历史使命。

Provider能够说是最简洁的一种模式了。尽管每次都给最小变动子树上加了另外的一个组件。然而联合Flutter号称能够达到亚线性复杂度的构建算法，其实对性能的影响很小。最要害的是，它是加载最小变动子树上的。在某些状况下，如果应用组件之外的一个微小的状态树，开发者稍有不慎，那么就是很大范畴的重绘。这样对开发者驾驭微小状态树的能力有很高的要求。个人观点是应用Provider也比拟省心。

当然笔者程度无限，对Flutter很多深度只是也还在摸索中。欢送拍砖！

参考

https://github.com/flutter/sa...
https://www.raywenderlich.com...
https://medium.com/flutter-co...