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

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

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

可以看出整个流程的核心还是 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 逻辑。