状态管理

简介

因为，React、Vue等前端框架大行其道，响应式编程的理念也随之流行，在具体的项目中描述好UI和状态之间的关系后，我们只需要专注于状态的改变就好了，而框架将会根据我们的描述，自动根据状态来更新UI。不像在Android端常见的命令式编程，需要我们手动去指定控件展示的内容。

Flux、Redux、Fish_Redux

对于如何理解“状态管理”这个概念我还是想以追本溯源的方式来解释给大家听，首先，当前我们使用Flutter开发的项目用到的状态管理框架是阿里巴巴咸鱼团队开源的Fish_Redux, 而Fish_Redux的基本思想又是来源于React技术栈下的Redux，从Redux再往前推就是最初与React一同登场的Flux。

Flux : 缘起

Facebook消息提示问题

一般社交类产品除了主屏上的动态列表，通常还会在明显的位置摆放一个查看消息的入口，这个入口上会有小红点表示当前有多少条未读消息。

当时有些用户发现在使用Facebook的过程中消息入口上有小红点，但是点击进消息列表却没有未读消息的情况。用户看到红点进入消息页没有未读消息，小红点消失，过一会儿小红点再次出现，进入消息页依旧没有未读消息。就这样循环往复，开发团队也是在修复bug再次出现这个bug中循环往复。

不可预测的MVC

我们先来看看当时当时Facebook项目的架构，对于小型项目来说的MVC模型，看起来似乎还挺可靠的

但是随着业务量的增大，MVC的问题越来越明显，依赖关系和各种层级的更新经常在大型MVC应用程序中发生，从而导致数据流错综复杂和不可预期的结果，前面的bug也是在这样的项目结构下，出现循环引用而导致的。

解决方案

为此，facebook的工程师打算将项目架构推倒重来，目标是为了更快的开发效率和更高的代码质量，为了做到这两点需要的是可预测的代码，也就因此最后分别开发出了响应式UI框架React来达到UI的可预测，状态管理框架Flux达到数据的可预测。

Flux

Action是由ActionCreators提供给Dispactcher，通常是由用户与视图的交互产生的
Dispactcher将会根据Action的类型来通知Store触发页面初始化时在Store中注册的回调
Store响应Dispactcher的请求对其内所维护的状态进行相关操作，操作完成后将会通过Event Handler告诉View有数据发生改变
View监听到数据改变并从Event Handler中获取对应的数据以此来刷新UI

Redux : 优化Flux

Redux在Flux的基础上做出了一些改进，在Flux中Store包含了状态改变的逻辑和当前应用的状态，而在Redux中将Store的两个部分拆分为处理状态改变逻辑的Reducer和状态State，在Flux中没有提供给开发则监听单向数据流的拓展，而Redux将Dispactcher改名为Dispatch，并在其中提供了用于监听数据流拓展接口。Redux具体流程和Flux类似，其中需要注意的是Reducer响应Dispatch时不仅会收到Action的信息还会有当前状态的拷贝，Reducer对拷贝的状态操作完成后，传递给State并由此更新。

Redux特性

热重载：在开发应用程序时，通常是一个接一个的小改动。您看到较小更改的效果的速度越快，开发就会越快。热重载的优点在于，可以实时的将修改的逻辑代码更新到应用中，而应用程序的状态却不会重置。虽然React配合Flux也可以热重载，但是因为Store中包含了应用状态和逻辑代码，如果对Store的代码热重载将会丢失当前的状态。在Redux中将Store拆分后，即可对操作状态的逻辑代码进行热重载了。

时间旅行：通过拷贝状态的方式，可以得到一连串的状态切片，每个切片又由对应的Action触发，有了这些切片，我们在调试程序的过程中，可以进行时间回溯，重新加载出现错误时的前一个状态。例如，在测试的过程中执行了某个操作导致出现异常，我可以回退到上一步，重新来一次。

可拓展接口：可以通过Dispatch监听所有经过它的Action，可以用来打印日志，用来埋点等等。