前言

Flutter的很多灵感来自于React，它的设计思想是数据与视图分离，由数据映射渲染视图。所以在Flutter中，它的Widget是immutable的，而它的动态部分全部放到了状态(State)中。

在之前的文章中，我们已经介绍了scoped model与redux两种状态管理方案在flutter中的应用。他们似乎都还不错，但都还是美中不足。今天我将介绍Google提出的一种全新的解决方案——BLoC。

在正式开始介绍前，我希望您已经阅读并理解了stream的相关知识，后面的内容都基于此。如果您还未了解过dart:stream 的话，我建议您先阅读这篇文章：Dart:什么是Stream。

BLoC

为什么需要状态管理

我们一直在找寻强大的状态管理方式。也许你并没有想过，flutter自身已经为我们提供了状态管理，而且你经常都在用到。

没错，它就是 Stateful widget。当我们接触到flutter的时候，首先需要了解的就是有些小部件是有状态的，有些则是无状态的。stateless widget 与 stateful widget。

在stateful widget中，我们widget的描述信息被放进了State，而stateful widget只是持有一些immutable的数据以及创建它的状态而已。它的所有成员变量都应该是final的，当状态发生变化的时候，我们需要通知视图重新绘制,这个过程就是setState。

这看上去很不错，我们改变状态的时候setState一下就可以了。
在我们一开始构建应用的时候，也许很简单，我们这时候可能并不需要状态管理。

image

但是随着功能的增加，你的应用程序将会有几十个甚至上百个状态。这个时候你的应用应该会是这样。

image

一旦当app的交互变得复杂，setState出现的次数便会显著增加，每次setState都会重新调用build方法，这势必对于性能以及代码的可阅读性带来一定的影响。

能不能不使用setState就能刷新页面呢？如何在多个页面中共享状态？我们希望有一种更加强大的方式，来管理我们的状态。

BLoC是什么

BLoC是一种利用reactive programming方式构建应用的方法，这是一个由流构成的完全异步的世界。

image

• 用StreamBuilder包裹有状态的部件，streambuilder将会监听一个流
• 这个流来自于BLoC
• 有状态小部件中的数据来自于监听的流。
• 用户交互手势被检测到，产生了事件。例如按了一下按钮。
• 调用bloc的功能来处理这个事件
• 在bloc中处理完毕后将会吧最新的数据add进流的sink中
• StreamBuilder监听到新的数据，产生一个新的snapshot，并重新调用build方法
• Widget被重新构建

BLoC能够允许我们完美的分离业务逻辑！再也不用考虑什么时候需要刷新屏幕了,一切交给StreamBuilder和BLoC!和StatefulWidget说拜拜！！

BLoC代表业务逻辑组件（Business Logic Component），由来自Google的两位工程师 Paolo Soares和Cong Hui设计，并在2018年DartConf期间（2018年1月23日至24日）首次展示。点击观看Youtube视频。。

Lets do it！

这里我们以一个最简单的CountApp举例。简单介绍BLoC的用法。该项目完整代码已上传Github。

这是一个在不同页面使用BLoC共享状态信息的app。这两个页面都依赖于一个数字，这个数字会随着我们按下按钮的次数而增加。

image

第一步：创建BLoC

我们这里的要求很简单，仅仅只是输出一个数字而已，然后有一个方法能够让数字加一。所以我们需要创建一条能够通过int类型数据的流。

import 'dart:async';

class CountBLoC {
 int _count;
 StreamController<int> _countController;

 CountBLoC() {
   _count = 0;
   _countController = StreamController<int>();
 }
 
 Stream<int> get value => _countController.stream;

 increment() {
   _countController.sink.add(++_count);
 }

 dispose() {
   _countController.close();
 }
}

为什么要使用私有变量“_”

一个应用需要大量开发人员参与，你写的代码也许在几个月之后被另外一个开发看到了，这时候假如你的变量没有被保护的话，也许同样是让count++，他会用countController.sink.add(++_count)这种方法，而不是调用 increment方法。

虽然两种方式的效果完全一样，但是第二种方式将会让我们的business logic零散的混入其他代码中，提高了代码耦合程度，非常不利于代码的维护以及阅读，所以为了让BLoC完全分离我们的业务逻辑，请务必使用私有变量。

第二步：创建BLoC实例

这里有三种方式创建bloc

• 全局单例创建
• 局部创建
• scoped

由于我们需要在两个屏幕中访问同一个bloc，所以我们只能选择全局单例模式或者scoped模式。

全局单例模式

全局单例我们只需要在bloc类的文件中创建一个bloc实例即可。不过我并不推荐这种做法，因为不需要用这个bloc的时候，我们应该释放它。

但是为了让我解释的尽量简单，后面我将会基于全局单例模式来介绍。

Scoped模式

创建一个bloc provider类,这里我们需要借助InheritWidget,实现of方法并让updateShouldNotify返回true。

class BlocProvider extends InheritedWidget {
  CountBLoC bLoC = CountBLoC();

  BlocProvider({Key key, Widget child}) : super(key: key, child: child);

  @override
  bool updateShouldNotify(_) => true;

  static CountBLoC of(BuildContext context) =>
      (context.inheritFromWidgetOfExactType(BlocProvider) as BlocProvider).bLoC;
}

小提示： 这里updateShouldNotify需要传入一个InheritedWidget oldWidget，但是我们强制返回true，所以传一个“_”占位。

第三步：在页面中使用StreamBuilder

这里以第一个页面为例，仅仅显示文字+数字。

StreamBuilder<int>(
            stream: bloc.value,
            initialData: 0,
            builder: (BuildContext context, AsyncSnapshot<int> snapshot) {
              return Text(
                'You hit me: ${snapshot.data} times',
                style: Theme.of(context).textTheme.display1,
              );
            })

• StreamBuilder中stream参数代表了这个stream builder监听的流，我们这里监听的是countBloc的value（它是一个stream）。
• initData代表初始的值，因为当这个控件首次渲染的时候，还未与用户产生交互，也就不会有事件从流中流出。所以需要给首次渲染一个初始值。
• builder函数接收一个位置参数BuildContext 以及一个snapshot。snapshot就是这个流输出的数据的一个快照。我们可以通过snapshot.data访问快照中的数据。也可以通过snapshot.hasError判断是否有异常，并通过snapshot.error获取这个异常。
• StreamBuilder中的builder是一个AsyncWidgetBuilder，它能够异步构建widget，当检测到有数据从流中流出时，将会重新构建。

在第二个页面中调用increment

floatingActionButton: FloatingActionButton(
          onPressed: ()=> bloc.increment(),
          child: Icon(Icons.add),
      )

由于这里并不涉及widget的重构，我们只需要调用bloc的功能即可。

处理广播流

我们构建好ui后，运行程序将会发现这件奇怪的事。

image

第二个页面的数字无法显示，而且控制台抛出了这个异常。

flutter: Bad state: Stream has already been listened to.

这是由于流被重复监听导致的。 两个页面中都需要显示这个数字，那么就使用了两个StreamBuilder。而StreamBuilder都监听的同一个流，所以导致了流被重复监听了。

还记得我们在Dart|什么是Stream中说的两种流吗。没错，我们创建StreamController的时候，默认是创建的单订阅流。所以我们需要将流改成广播流。

    _countController = StreamController.broadcast<int>();

只需要在创建StreamController的时候调用broadcast方法即可。

来看看效果

image
但是我们这里还有一个小问题，你发现了吗。

Q&A

为什么第二次进入UnderPage的时候，计数器显示为0，按了一下才好

这是由于我们在第一次pop UnderPage的时候，这个页面已经被销毁了。当我们再push进去的时候，StreamBuilder无法收听到最后一次事件（已经流过去了），只能显示initiaData。而再次点击时，正确的数字被add进了流，StreamController收听到了它，所以又能显示正确的数据了。

这个问题能够解决吗？

答案是肯定的，使用rxdart！rxdart极大的增强了流的功能，解决方法将会在后续rxdart篇介绍。

大型应用中应该如何组织BLoC

大型应用程序需要多个BLoC。一个好的模式是为每个屏幕使用一个顶级组件，并为每个复杂足够的小部件使用一个。但是，太多的BLoC会变得很麻烦。此外，如果您的应用中有数百个可观察量（流），则会对性能产生负面影响。换句话说：不要过度设计你的应用程序。

——Filip Hracek

一个更加复杂的app

image
filip提供了一个更复杂的BLoC样本。他将购物应用程序重新创建为一个更现实的例子，其中产品目录逐页从网络中获取，我们有无限的这些产品列表。此外，对于目录中的每个产品，我们希望在产品已在目录中时稍微更改ProductSquare的显示。

了解更多

下面有一些优秀的文章能够给您更多参考

• [译]Flutter响应式编程：Streams和BLoC
• Build reactive mobile apps in Flutter — companion article
• Technical Debt and Streams/BLoC (The Boring Flutter Development Show, Ep. 4)
• Using the BloC Pattern to Build Reactive Applications with Streams in Dart's Flutter Framework

写在最后

本次所用到的代码已经上传Github:https://github.com/OpenFlutter/Flutter-Notebook/tree/master/mecury_project/example/bloc_demo

bloc是一个优秀的状态管理方式，它能够帮助我们更好的构建复杂的大型应用。但是他还不是完美的（至少目前不是）。它在处理大量异步事件以及分离业务逻辑上表现很优秀，但是在共享状态上还有一些缺陷。

有人尝试将redux与bloc结合使用，试图找到突破口。这里有一个专门为它编写的库：rebloc。感兴趣的朋友可以自行了解一下。

如果你在使用bloc进行状态管理的时候有任何好的点子，或者是疑问，欢迎在下方评论区以及我的邮箱1652219550a@gmail.com留言，我会在24小时内与您联系！

下一篇文章将会为大家介绍Reactive Programming的最佳库RxDart在BLoC上的实践，敬请期待。