Flutter中状态管理的理解

###一、状况办理认知

1、中心解耦

我了解的状况办理中心思维是解耦。 和别的结构相同，Flutter中的状况办理首要是对逻辑、数据等进行解耦，以适应杂乱事务的开发及保护。

2、比照其它结构

最经典的解耦便是MVC了，划分为三个模块：

• Model层：数据层
• View层：页面UI
• Controller：逻辑处理 现在很多也在用这一经典的形式，MVC形式能够处理大部分的耦合问题，但也存在 Controller过于臃肿的情况，所以后面开展而来了 MVVM、MVP等形式，用于在不同的场景下更好的解耦。

3、Flutter状况办理

Flutter中的状况办理首要是对逻辑层、状况层、页面层、行为层等进行划分：

• view：界面层，首要是UI
• Logic：逻辑层，首要处理事务逻辑
• State：状况层，首要处理页面所需数据状况
• Action：行为层，首要处理交互事情
• Reducer：这个层级，是专门用于处理数据变化的

不同的解耦层能够组合成不同的形式，如MVC是由逻辑层、数据层、页面层组成，在Flutter中能够分为极简形式(页面层+逻辑层)、规范形式（页面层+逻辑层+状况层）、严厉形式（页面层+逻辑层+状况层+行为层）、强迫症形式（页面层+逻辑层+状况层+行为层+ Reducer层），几种形式各有优缺陷，下面我会结合详细的状况办理结构详细的讲下这几种形式。

###二、状况办理形式

2.1、极简形式

从上图能够看出极简形式由逻辑层+页面层组成，各自的责任如图所示，十分的简练，关于不是太杂乱的事务运用与用该形式开发，假如一些简略的页面也用杂乱的形式感觉有点生搬硬套了，有的分层完全是不需求的，也造成了内存的糟蹋。 现在较为盛行的状况办理结构也是依照极简形式划分的，如provider、getx，两者的差异不大，不过在挑选运用时选provider或许需求能hold的住InheritedWidget，选getx或许需求能hold的住依靠注入，回收GetXController。

2.2、规范形式

从上图能够看出规范形式由 逻辑层+页面层+状况层组成，各自的责任如图所示，比较极简形式，规范格式多了状况层，状况层首要是存储所需的状况变量。规范形式类似于经典的MVC的分层，用的十分普遍，能够很好的解耦。 常见的结构有cubit、provider和getx。

2.3、严厉形式

从上图能够看出规范形式由 逻辑层+页面层+状况层+行为层组成，各自的责任如图所示，比较规范形式，严厉格式多了一个行为层，行为层从图中能够清楚的看出首要是为了处理交互事情，那为什么要多出这一层呢？其实在Flutter中运用规范形式时会存在一个问题，很多的交互事情都是深埋在各个widget中，查找起来十分不变，事情少了还好，假如后续越来越杂乱事情越来越多那就成了一团麻了。有了行为性这一分层，能够很好的处理交互事情，页面有什么交互事情，交互事情如何处理只需到Action文件中查找即可，关于后期的保护来说十分便利。 常见的状况办理结构：Bloc、Redux和fish_redux。

2.4、强迫症形式

从上图能够看出规范形式由 逻辑层+页面层+状况层+行为层+Reducer层组成，各自的责任如图所示，比较严厉形式，强迫症形式多了一个Reducer层，Reducer层首要是对数据进行处理并更新后改写页面。从上图来看这个结构现已有点杂乱了，为了解耦数据改写这一层次，付出了巨大的本钱 常见的状况办理结构：Redux、fish_redux。

###三、状况办理结构比照

3.1、Bloc

BLoC是谷歌提出的一种规划形式，运用stream流的方法完成界面的异步渲染和重绘，咱们能够十分顺利的经过BLoC完成事务与界面的分离。在运用BLoC前需求了解三个重要的概念，分别是 Cubit、 BlocObserver和BLoC。

3.1.1、Cubit

Cubit是办理状况数据的 BlocBase 子类，它能够办理恣意类型的数据，包含根本类型到杂乱目标。在Cubit调用 emit 构建新的状况数据前需求给状况数据一个初始值。当状况数据产生改变的时分，会触发 Cubit 的 onChange 回调，假如出现错误则会触发 onError 回调。

class CounterCubit extends Cubit<int> {
  CounterCubit() : super(0);
  void increment() => emit(state + 1);
  void decrement() => emit(state - 1);
  @override
  void onChange(Change<int> change) {
    super.onChange(change);
    print(change);
  }
  @override
  void onError(Object error, StackTrace stackTrace) {
    print('$error, $stackTrace');
    super.onError(error, stackTrace);
  }
}

3.1.2、BlocObserver

BlocObserver 能够监听所有的Cubit的变化，然后使得咱们能够一起监听多个Cubit。

3.1.3、Bloc

Bloc也是承继 BlocBase 的类，但比较 Cubit 来说更为高档一些。它运用的是 events 而不是露出的函数来更新状况。在 Bloc 内部，有一个onEvent 方法，在这个方法里，经过 EventTransformer将 event转换为更新状况的方法来改写状况数据。每个event都能够有对应的 EventHandler来处理该 event，完成后再经过 emit 触发告诉状况更新。当状况改变前会调用 onTransition，在这里会有当时的状况，触发更新的 event 和下一个状况。

从 Bloc 的规划来看，运用了函数Cubit形式和事情Bloc形式的方法来驱动状况数据更新，然后再经过emit告诉状况更新，经过这种方法解耦 UI 界面和事务逻辑。

优缺陷剖析：

长处：

• BLoC的目录结构明晰，完全符合mvvm的习气。关于工程化项目来说会比较受欢迎，团队协作起来会削减犯错的概率，大家都跟着一个形式去做，保护性也提高了；

缺陷：

• BLoC运用起来相对杂乱，需求创建多个文件。虽然官方引入了cubit，把event组合到bloc文件中，但激烈的结构化依然让不少初学者难以入门；
• 颗粒度的把控相对困难。经过BlocBuilder构建的视图，在state改变时，视图都会rebuild，想要控制颗粒度只能把bloc再拆细，这会极大的添加代码杂乱度和工作量；不过这个问题可经过引入freezed生成代码，然后经过buildWhen等方法削减视图改写的频次。

3.2、Provider

Provider是Flutter官方开发保护的，也是近些年官方最为推荐的状况办理库。它对InheritedWidget进行了上层封装，致力处理原生setState方案的props臃肿、展示与逻辑耦合问题。运用时需在项目中引入provider这个库。

Provider将页面分为事务和视图两层，并定义Notifier、Consumer两个中心概念：Notifier担任完成事务逻辑，且在数据更新时发出告诉。Consumer担任完成界面逻辑，并在数据更新时更新本身，以及用户交互时调用Notifier方法。

优缺陷剖析：

长处：

• 根据官方InheritedWidget的封装，不存在任何风险，很安稳且不会给功用方面加担负；
• 方案涉及概念少，上手本钱低；

缺陷：

• 数据流分为事务、视图两层。项目规模变大时，事务层杂乱度容易指数级增长；
• context强相关，有Flutter开发经历的都知道，context大多时分根本都是在widget中才干获取到，在其他当地想随时获取 BuildContext 是不切实际的，也就意味着大多时分只能在view层去获取到Provider供给的信息。

3.3、GetX

GetX 是 Flutter 上的一个轻量且强壮的处理方案，也是我现在项目中正在运用的结构，在Flutter状况办理中绝对算是异军突起，一经发布就因其简略且全面的优势，引得一大批簇拥者。GetX能够称之为全家桶式的结构，具有以下多种功用：

• 主题切换：比如深色形式切换；
• 多语言：能够经过装备 Map 搞定多语言；
• 弹窗提醒：包含了 SnackBar 和对话框；
• 路由：无需 context 的路由跳转；
• 离线存储：不依靠原生的key-value 存储组件的离线存储 GetStorage；
• 状况办理：快速接入的响应式状况办理；
• 东西类：例如表单验证东西，获取体系参数（平台类型，屏幕尺寸等）；
• 依靠注入容器：运用简略的 put 和 find 方法完成容器目标的注册和获取；
• 网络恳求：能够运用 GetConnect 完成网络恳求。

3.3.1、路由办理

GetX内部完成了路由办理，这个是十分重要的，这样咱们就不需求运用其他第三插件，并且GetX的路由办理十分简略，代码也简练。

/// 跳转新页面
/// 第一种方法 进入新页面 直接页面
Get.to(TestPage());
/// 第二种方法 进入新页面 装备路由名称  主张这种一致装备
Get.toNamed(Routes.TestPage);
/// 弹出当时页，并将一个新的[page]推入仓库，便是删去就页面，运用新页面
Get.off(TestPage());
/// Push a [page]和弹出几个页面在仓库中，便是进入新页面，删去之行进栈的页面。比如场景（注册-手机号-其他注册信息-注册完了直接到主页，之前页面全部删掉。）
Get.offAll(TestPage());
/// 同上，便是传路由名称
Get.offAllNamed(FXRoutes.TestPage);
/// 回来上一面 就一句
Get.back()

3.3.2、状况办理

运用getx的状况办理，我一般一个page对应一个logic， logic需求承继 GetxController，该logic来处理逻辑并控制page，目录如下：

将页面和logic办理起来GetX运用的是依靠注入，有两种方法能够完成： 1、在view中运用依靠注入和logic相关，然后在获取到logic中的state，然后view中的交互事情直接调取logic中的方法进行处理，state用于改写页面UI。

final logic = Get.put(TestPageLogic());
final state = Get.find<TestPage>().state;

2、在路由中绑定

GetPage(
        name: FXRoutes.TestPage,
        page: () => TestPage(),
        /// 首要代码是这个 绑定
        binding: BindingsBuilder(() => {
              Get.lazyPut<TestPageLogic>(
                  () => TestPageLogic())
            })),

运用GetView能够直接运用logic

/// 页面承继GetView<> 传依靠注入的控制器 这样就能够直接运用了，会发现这边没有 Get.put，或者Git.find， 运用的时分直接logic。 看源码能够知道GetView内部现已帮咱们完成了。
class TestPage extends GetView<TestPageLogic> {
 @override
  Widget build(BuildContext context) {
  }
}

优缺陷剖析：

长处：

• 运用简略，用起来的确很简略，极易上手；脱离context，随时随地想用就用，处理了BLoC和Provider的痛点；
• 全家桶式功用，运用GetX后，咱们无需再单独去做路由办理、国际化、主题、全局context等;

缺陷：

• 运用 GetX 的导航需求运用自定义的 MaterialApp 或 CupertinoApp，也便是咱们需求运用 GetMeterialApp 或 GetCupertinoApp 包裹使用才干够在页面跳转时无需运用 BuildContext。对使用的侵入性比较强；
• 运用GetX的话需求能hold住依靠注入。

3.4、fish_redux

fish_redux是阿里咸鱼团队开发的一个状况办理结构，是根据 Redux 数据办理的拼装式 flutter 使用结构， 它特别适用于构建中大型的杂乱使用。

它的特点是装备式拼装。 一方面咱们将一个大的页面，对视图和数据层层拆解为互相独立的 Component|Adapter，上层担任拼装，基层担任完成； 另一方面将 Component|Adapter 拆分为 View，Reducer，Effect 等彼此独立的上下文无关函数，结构十分明晰，合适团队开发，易与后期的保护。

运用fish_redux进行开发，拆分的文件目录为：

• action.dart 事情转发动作类；
• effect.dart 网络恳求、逻辑处理；
• page.dart 做一些装备工作；
• reducer.dart 简略的对数据的操作及更新；
• state.dart 数据办理类；
• view.dart 视图类。

在开发中可下载 FishReduxTemplate插件，可快速生成对应的文件：

fish_redux比较其它结构多了action和reducer层，其间action层首要是行为层，一致转发处理交互事情，我认为这一层仍是很有必要的，多了一层从结构端来说杂乱度是提高了，可是关于运用者来说却是结构明晰了，假如没有行为层，交互事情大多都埋在各种widget中，这样找起来十分不便利，并且随着后期的迭代也会变得越来越难保护，有了行为层就明晰多了。关于reducer层我保留意见，或许是水平达不到，我没有感受到这层妙处在哪。

优缺陷剖析：

长处：

• 结构明晰，合适团队开发，也利于后期保护；

缺陷：

• 更新速度较差，咱们项目已放弃fish_redux，由于3.0版本还没有适配空安全；
• 结构会较为杂乱，上手难度大，学习本钱较高。

[注]：挑选哪种状况办理结构没有精确的答案，其受难易程度、可保护性、开发本钱、功用、使用场景、团队技能栈等要素的影响，所以合适自己的才是最好的。