• 一、scoped_model
    • InheritedWidget
  • 二、BloC
  • 三、flutter_redux
  • 四、fish_redux
    • 资源推荐
      • 完整开源项目推荐：
      • 文章

    作为系列文章的第十二篇，本篇将通过 scope_model 、 BloC 设计模式、flutter_redux 、 fish_redux 来全面深入分析， Flutter 中大家最为关心的状态管理机制，理解各大框架中如何设计实现状态管理，从而选出你最为合适的 state “大管家”。

    前文：

    • 一、Dart语言和Flutter基础
    • 二、 快速开发实战篇
    • 三、 打包与填坑篇
    • 四、 Redux、主题、国际化
    • 五、 深入探索
    • 六、 深入Widget原理
    • 七、 深入布局原理
    • 八、 实用技巧与填坑
    • 九、 深入绘制原理
    • 十、 深入图片加载流程
    • 十一、全面深入理解Stream

    在所有 响应式编程 中，状态管理一直老生常谈的话题，而在 Flutter 中，目前主流的有 scope_model 、BloC 设计模式 、flutter_redux 、fish_redux 等四种设计，它们的 复杂度 和 上手难度 是逐步递增的，但同时 可拓展性 、解耦度 和 复用能力 也逐步提升。

    基于前篇，我们对 Stream 已经有了全面深入的理解，后面可以发现这四大框架或多或少都有 Stream 的应用，不过还是那句老话，合适才是最重要，不要为了设计而设计 。

    本文Demo源码

    GSYGithubFlutter 完整开源项目

    一、scoped_model

    scoped_model 是 Flutter 最为简单的状态管理框架，它充分利用了 Flutter 中的一些特性，只有一个 dart 文件的它，极简的实现了一般场景下的状态管理。

    如下方代码所示，利用 scoped_model 实现状态管理只需要三步 ：

    • 定义 Model 的实现，如 CountModel ，并且在状态改变时执行 notifyListeners() 方法。
    • 使用 ScopedModel Widget 加载 Model 。
    • 使用 ScopedModelDescendant 或者 ScopedModel.of<CountModel>(context) 加载 Model 内状态数据。

    是不是很简单？那仅仅一个 dart 文件，如何实现这样的效果的呢？后面我们马上开始剥析它。

    1. class ScopedPage extends StatelessWidget {
    2.   final CountModel _model = new CountModel();
    4.   @override
    5.   Widget build(BuildContext context) {
    6.     return Scaffold(
    7.         appBar: AppBar(
    8.           title: new Text("scoped"),
    9.         ),
    10.         body: Container(
    11.           child: new ScopedModel<CountModel>(
    12.             model: _model,
    13.             child: CountWidget(),
    14.           ),
    15.         ));
    16.   }
    17. }
    19. class CountWidget extends StatelessWidget {
    20.   @override
    21.   Widget build(BuildContext context) {
    22.     return new ScopedModelDescendant<CountModel>(
    23.         builder: (context, child, model) {
    24.         return new Column(
    25.           children: <Widget>[
    26.             new Expanded(child: new Center(child: new Text(model.count.toString()))),
    27.             new Center(
    28.               child: new FlatButton(
    29.                   onPressed: () {
    30.                     model.add();
    31.                   },
    32.                   color: Colors.blue,
    33.                   child: new Text("+")),
    34.             ),
    35.           ],
    36.         );
    37.       });
    38.   }
    39. }
    41. class CountModel extends Model {
    42.   static CountModel of(BuildContext context) =>
    43.       ScopedModel.of<CountModel>(context);
    45.   int _count = 0;
    47.   int get count => _count;
    49.   void add() {
    50.     _count++;
    51.     notifyListeners();
    52.   }
    53. }

    如下图所示，在 scoped_model 的整个实现流程中，ScopedModel 这个 Widget 很巧妙的借助了 AnimatedBuildler 。

    因为 AnimatedBuildler 继承了 AnimatedWidget ，在 AnimatedWidget 的生命周期中会对 Listenable 接口添加监听，而 Model 恰好就实现了 Listenable 接口，整个流程总结起来就是：

    • Model 实现了 Listenable 接口，内部维护一个 Set<VoidCallback> _listeners 。
    • 当 Model 设置给 AnimatedBuildler 时， Listenable 的 addListener 会被调用，然后添加一个 _handleChange 监听到 _listeners 这个 Set 中。
    • 当 Model 调用 notifyListeners 时，会通过异步方法 scheduleMicrotask 去从头到尾执行一遍 _listeners 中的 _handleChange。
    • _handleChange 监听被调用，执行了 setState({}) 。

    image.png

    整个流程是不是很巧妙，机制的利用了 AnimatedWidget 和 Listenable 在 Flutter 中的特性组合，至于 ScopedModelDescendant 就只是为了跨 Widget 共享 Model 而做的一层封装，主要还是通过 ScopedModel.of<CountModel>(context) 获取到对应 Model 对象，这这个实现上，scoped_model 依旧利用了 Flutter 的特性控件 InheritedWidget 实现。

    InheritedWidget

    在 scoped_model 中我们可以通过 ScopedModel.of<CountModel>(context) 获取我们的 Model ，其中最主要是因为其内部的 build 的时候，包裹了一个 _InheritedModel 控件，而它继承了 InheritedWidget 。

    为什么我们可以通过 context 去获取到共享的 Model 对象呢？

    首先我们知道 context 只是接口，而在 Flutter 中 context 的实现是 Element ，在 Element 的 inheritFromWidgetOfExactType 方法实现里，有一个 Map<Type, InheritedElement> _inheritedWidgets 的对象。

    _inheritedWidgets 一般情况下是空的，只有当父控件是 InheritedWidget 或者本身是 InheritedWidgets 时才会有被初始化，而当父控件是 InheritedWidget 时，这个 Map 会被一级一级往下传递与合并 。

    所以当我们通过 context 调用 inheritFromWidgetOfExactType 时，就可以往上查找到父控件的 Widget，从在 scoped_model 获取到 _InheritedModel 中的Model 。

    二、BloC

    BloC 全称 Business Logic Component ，它属于一种设计模式，在 Flutter 中它主要是通过 Stream 与 SteamBuilder 来实现设计的，所以 BloC 实现起来也相对简单，关于 Stream 与 SteamBuilder 的实现原理可以查看前篇，这里主要展示如何完成一个简单的 BloC 。

    如下代码所示，整个流程总结为：

    • 定义一个 PageBloc 对象，利用 StreamController 创建 Sink 与 Stream。
    • PageBloc 对外暴露 Stream 用来与 StreamBuilder 结合；暴露 add 方法提供外部调用，内部通过 Sink 更新 Stream。
    • 利用 StreamBuilder 加载监听 Stream 数据流，通过 snapShot 中的 data 更新控件。

    当然，如果和 rxdart 结合可以简化 StreamController 的一些操作，同时如果你需要利用 BloC 模式实现状态共享，那么自己也可以封装多一层 InheritedWidgets 的嵌套，如果对于这一块有疑惑的话，推荐可以去看看上一篇的 Stream 解析。

    1. class _BlocPageState extends State<BlocPage> {
    2.   final PageBloc _pageBloc = new PageBloc();
    3.   @override
    4.   void dispose() {
    5.     _pageBloc.dispose();
    6.     super.dispose();
    7.   }
    8.   @override
    9.   Widget build(BuildContext context) {
    10.     return Scaffold(
    11.       body: Container(
    12.         child: new StreamBuilder(
    13.             initialData: 0,
    14.             stream: _pageBloc.stream,
    15.             builder: (context, snapShot) {
    16.               return new Column(
    17.                 children: <Widget>[
    18.                   new Expanded(
    19.                       child: new Center(
    20.                           child: new Text(snapShot.data.toString()))),
    21.                   new Center(
    22.                     child: new FlatButton(
    23.                         onPressed: () {
    24.                           _pageBloc.add();
    25.                         },
    26.                         color: Colors.blue,
    27.                         child: new Text("+")),
    28.                   ),
    29.                   new SizedBox(
    30.                     height: 100,
    31.                   )
    32.                 ],
    33.               );
    34.             }),
    35.       ),
    36.     );
    37.   }
    38. }
    39. class PageBloc {
    40.   int _count = 0;
    41.   ///StreamController
    42.   StreamController<int> _countController = StreamController<int>();
    43.   ///对外提供入口
    44.   StreamSink<int> get _countSink => _countController.sink;
    45.   ///提供 stream StreamBuilder 订阅
    46.   Stream<int> get stream => _countController.stream;
    47.   void dispose() {
    48.     _countController.close();
    49.   }
    50.   void add() {
    51.     _count++;
    52.     _countSink.add(_count);
    53.   }
    54. }

    三、flutter_redux

    相信如果是前端开发者，对于 redux 模式并不会陌生，而 flutter_redux 可以看做是利用了 Stream 特性的 scope_model 升级版，通过 redux 设计模式来完成解耦和拓展。

    当然，更多的功能和更好的拓展性，也造成了代码的复杂度和上手难度 ，因为 flutter_redux 的代码使用篇幅问题，这里就不展示所有代码了，需要看使用代码的可直接从 demo 获取，现在我们直接看 flutter_redux 是如何实现状态管理的吧。

    十二、全面深入理解状态管理设计 - 图2

    如上图，我们知道 redux 中一般有 Store 、 Action 、 Reducer 三个主要对象，之外还有 Middleware 中间件用于拦截，所以如下代码所示：

    • 创建 Store 用于管理状态 。
    • 给 Store 增加 appReducer 合集方法，增加需要拦截的 middleware，并初始化状态。
    • 将 Store 设置给 StoreProvider 这个 InheritedWidget 。
    • 通过 StoreConnector / StoreBuilder 加载显示 Store 中的数据。

    之后我们可以 dispatch 一个 Action ，在经过 middleware 之后，触发对应的 Reducer 返回数据，而事实上这里核心的内容实现，还是 Stream 和 StreamBuilder 的结合使用 ，接下来就让我们看看这个流程是如何联动起来的吧。

    1. class _ReduxPageState extends State<ReduxPage> {
    3.   ///初始化store
    4.   final store = new Store<CountState>(
    5.     /// reducer 合集方法
    6.     appReducer,
    7.     ///中间键
    8.     middleware: middleware,
    9.     ///初始化状态
    10.     initialState: new CountState(count: 0),
    11.   );
    13.   @override
    14.   Widget build(BuildContext context) {
    15.     return Scaffold(
    16.         appBar: AppBar(
    17.           title: new Text("redux"),
    18.         ),
    19.         body: Container(
    20.           /// StoreProvider InheritedWidget
    21.           /// 加载 store 共享
    22.           child: new StoreProvider(
    23.             store: store,
    24.             child: CountWidget(),
    25.           ),
    26.         ));
    27.   }
    28. }

    如下图所示，是 flutter_redux 从入口到更新的完整流程图，整理这个流程其中最关键有几个点是：

    • StoreProvider 是 InheritedWidgets ，所以它可以通过 context 实现状态共享。
    • StreamBuilder / StoreConnector 的内部实现主要是 StreamBuilder 。
    • Store 内部是通过 StreamController.broadcast 创建的 Stream ，然后在 StoreConnector 中通过 Stream 的 map 、transform 实现小状态的变换，最后更新到 StreamBuilder 。

    那么现在看下图流程有点晕？下面我们直接分析图中流程。

    十二、全面深入理解状态管理设计 - 图3

    可以看出整个流程的核心还是 Stream ，基于这几个关键点，我们把上图的流程整理为：

    • 1、 Store 创建时传入 reducer 对象和 middleware 数组，同时通过 StreamController.broadcast 创建了 _changeController 对象。
    • 2、 Store 利用 middleware 和 _changeController 组成了一个 NextDispatcher 方法数组 ，并把 _changeController 所在的 NextDispatcher 方法放置在数组最后位置。
    • 3、 StoreConnector 内通过 Store 的 _changeController 获取 Stream ，并进行了一系列变换后，最终 Stream 设置给了 StreamBuilder。
    • 4、当我们调用 Stroe 的 dispatch 方法时，我们会先进过 NextDispatcher 数组中的一系列 middleware 拦截器，最终调用到队末的 _changeController 所在的 NextDispatcher。
    • 5、最后一个 NextDispatcher 执行时会先执行 reducer 方法获取新的 state ，然后通过 _changeController.add 将状态加载到 Stream 流程中，触发 StoreConnector 的 StreamBuilder 更新数据。

    如果对于 Stream 流程不熟悉的还请看上篇。

    现在再对照流程图会不会清晰很多了？

    在 flutter_redux 中，开发者的每个操作都只是一个 Action ，而这个行为所触发的逻辑完全由 middleware 和 reducer 决定，这样的设计在一定程度上将业务与UI隔离，同时也统一了状态的管理。

    比如你一个点击行为只是发出一个 RefrshAction ，但是通过 middleware 拦截之后，在其中异步处理完几个数据接口，然后重新 dispatch 出 Action1、Action2 、Action3 去更新其他页面， 类似的 redux_epics 库就是这样实现异步的 middleware 逻辑。

    四、fish_redux

    如果说 flutter_redux 属于相对复杂的状态管理设置的话，那么闲鱼开源的 fish_redux 可谓 “不走寻常路” 了，虽然是基于 redux 原有的设计理念，同时也有使用到 Stream ，但是相比较起来整个设计完全是 超脱三界，如果是前面的都是简单的拼积木，那是 fish_redux 就是积木界的乐高。

    十二、全面深入理解状态管理设计 - 图4

    因为篇幅原因，这里也只展示部分代码，其中 reducer 还是我们熟悉的存在，而闲鱼在这 redux 的基础上提出了 Comoponent 的概念，这个概念下 fish_redux 是从 Context 、Widget 等地方就开始全面“入侵”你的代码，从而带来“超级赛亚人”版的 redux 。

    如下代码所示，默认情况我们需要：

    • 继承 Page 实现我们的页面。
    • 定义好我们的 State 状态。
    • 定义 effect 、 middleware 、reducer 用于实现副作用、中间件、结果返回处理。
    • 定义 view 用于绘制页面。
    • 定义 dependencies 用户装配控件，这里最骚气的莫过于重载了 + 操作符，然后利用 Connector 从 State 挑选出数据，然后通过 Component 绘制。

    现在看起来使用流程是不是变得复杂了？

    但是这带来的好处就是 复用的颗粒度更细了，装配和功能更加的清晰。 那这个过程是如何实现的呢？后面我们将分析这个复杂的流程。

    1. class FishPage extends Page<CountState, Map<String, dynamic>> {
    2.   FishPage()
    3.       : super(
    4.           initState: initState,
    5.           effect: buildEffect(),
    6.           reducer: buildReducer(),
    7.           ///配置 View 显示
    8.           view: buildView,
    9.           ///配置 Dependencies 显示
    10.           dependencies: Dependencies<CountState>(
    11.               slots: <String, Dependent<CountState>>{
    12.                 ///通过 Connector() 从 大 state 转化处小 state
    13.                 ///然后将数据渲染到 Component
    14.                 'count-double': DoubleCountConnector() + DoubleCountComponent()
    15.               }
    16.           ),
    17.           middleware: <Middleware<CountState>>[
    18.             ///中间键打印log
    19.             logMiddleware(tag: 'FishPage'),
    20.           ]
    21.   );
    22. }
    24. ///渲染主页
    25. Widget buildView(CountState state, Dispatch dispatch, ViewService viewService) {
    26.   return Scaffold(
    27.       appBar: AppBar(
    28.         title: new Text("fish"),
    29.       ),
    30.       body: new Column(
    31.         children: <Widget>[
    32.           ///viewService 渲染 dependencies
    33.           viewService.buildComponent('count-double'),
    34.           new Expanded(child: new Center(child: new Text(state.count.toString()))),
    35.           new Center(
    36.             child: new FlatButton(
    37.                 onPressed: () {
    38.                   ///+
    39.                   dispatch(CountActionCreator.onAddAction());
    40.                 },
    41.                 color: Colors.blue,
    42.                 child: new Text("+")),
    43.           ),
    44.           new SizedBox(
    45.             height: 100,
    46.           )
    47.         ],
    48.       ));
    49. }

    如下大图所示，整个联动的流程比 flutter_redux 复杂了更多（ 如果看不清可以点击大图 ），而这个过程我们总结起来就是：

    • 1、Page 的构建需要 State 、Effect 、Reducer 、view 、dependencies 、 middleware 等参数。

    • 2、Page 的内部 PageProvider 是一个 InheritedWidget 用户状态共享。

    • 3、Page 内部会通过 createMixedStore 创建 Store 对象。

    • 4、Store 对象对外提供的 subscribe 方法，在订阅时会将订阅的方法添加到内部 List<_VoidCallback> _listeners 。

    • 5、Store 对象内部的 StreamController.broadcast 创建出了 _notifyController 对象用于广播更新。

    • 6、Store 对象内部的 subscribe 方法，会在 ComponentState 中添加订阅方法 onNotify，如果调用在 onNotify 中最终会执行 setState更新UI。

    • 7、Store 对象对外提供的 dispatch 方法，执行时内部会执行 4 中的 List<_VoidCallback> _listeners，触发 onNotify。

    • 8、Page 内部会通过 Logic 创建 Dispatch ，执行时经历 Effect -> Middleware -> Stroe.dispatch -> Reducer -> State -> _notifyController -> _notifyController.add(state) 等流程。

    • 9、以上流程最终就是 Dispatch 触发 Store 内部 _notifyController ， 最终会触发 ComponentState 中的 onNotify 中的setState更新UI

    十二、全面深入理解状态管理设计 - 图5

    是不是有很多对象很陌生？

    确实 fish_redux 的整体流程更加复杂，内部的 ContxtSys 、Componet 、ViewSerivce 、 Logic 等等概念设计，这里因为篇幅有限就不详细拆分展示了，但从整个流程可以看出 fish_redux 从控件到页面更新，全都进行了新的独立设计，而这里面最有意思的，莫不过 dependencies 。

    如下图所示，得益于fish_redux 内部 ConnOpMixin 中对操作符的重载，我们可以通过 DoubleCountConnector() + DoubleCountComponent() 来实现Dependent 的组装。

    十二、全面深入理解状态管理设计 - 图6

    Dependent 的组装中 Connector 会从总 State 中读取需要的小 State 用于 Component 的绘制，这样很好的达到了 模块解耦与复用 的效果。

    而使用中我们组装的 dependencies 最后都会通过 ViewService 提供调用调用能力，比如调用 buildAdapter 用于列表能力，调用 buildComponent 提供独立控件能力等。

    可以看出 flutter_redux 的内部实现复杂度是比较高的，在提供组装、复用、解耦的同时，也对项目进行了一定程度的入侵，这里的篇幅可能不能很全面的分析 flutter_redux 中的整个流程，但是也能让你理解整个流程的关键点，细细品味设计之美。

    自此，第十二篇终于结束了！(///▽///)

    资源推荐

    • Github ： https://github.com/CarGuo
    • 本文Demo ：https://github.com/CarGuo/state_manager_demo
    • 本文代码 ：https://github.com/CarGuo/GSYGithubAppFlutter
    完整开源项目推荐：
    • GSYGithubApp Flutter
    • GSYGithubApp React Native
    • GSYGithubAppWeex
    文章

    《Flutter完整开发实战详解(一、Dart语言和Flutter基础)》

    《Flutter完整开发实战详解(二、 快速开发实战篇)》

    《Flutter完整开发实战详解(三、 打包与填坑篇)》

    《Flutter完整开发实战详解(四、Redux、主题、国际化)》

    《Flutter完整开发实战详解(五、 深入探索)》

    《Flutter完整开发实战详解(六、 深入Widget原理)》

    《Flutter完整开发实战详解(七、 深入布局原理)》

    《Flutter完整开发实战详解(八、 实用技巧与填坑)》

    《Flutter完整开发实战详解(九、 深入绘制原理)》

    《Flutter完整开发实战详解(十、 深入图片加载流程)》

    《Flutter完整开发实战详解(十一、全面深入理解Stream)》

    《Flutter完整开发实战详解(十二、全面深入理解状态管理设计)》

    《跨平台项目开源项目推荐》

    《移动端跨平台开发的深度解析》

    我们还会再见吗？