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版本还没有适配空安全；
结构会较为杂乱，上手难度大，学习本钱较高。

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

Flutter中状态管理的理解

1、中心解耦

2、比照其它结构

3、Flutter状况办理

2.1、极简形式

2.2、规范形式

2.3、严厉形式

2.4、强迫症形式

3.1、Bloc

3.1.1、Cubit

3.1.2、BlocObserver

3.1.3、Bloc

优缺陷剖析：

长处：

缺陷：

3.2、Provider

优缺陷剖析：

长处：

缺陷：

3.3、GetX

3.3.1、路由办理

3.3.2、状况办理

优缺陷剖析：

长处：

缺陷：

3.4、fish_redux

优缺陷剖析：

长处：

缺陷：

作者信息

推广

Flutter中状态管理的理解

1、中心解耦

2、比照其它结构

3、Flutter状况办理

2.1、极简形式

2.2、规范形式

2.3、严厉形式

2.4、强迫症形式

3.1、Bloc

3.1.1、Cubit

3.1.2、BlocObserver

3.1.3、Bloc

优缺陷剖析：

长处：

缺陷：

3.2、Provider

优缺陷剖析：

长处：

缺陷：

3.3、GetX

3.3.1、路由办理

3.3.2、状况办理

优缺陷剖析：

长处：

缺陷：

3.4、fish_redux

优缺陷剖析：

长处：

缺陷：

相关文章

如何在 Github 上规范的提交 PR（图文详解）

安卓开发基础——实现音频文件的播放

swift 自定义图片大小裁剪

个人免费使用的Github Copilot——AWS CodeWhisperer

作者信息

推广