Flutter | 状态管理探索篇——BLoC(三)
前言
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上的实践，敬请期待。
