Flutter架构组件(FAC)——Flutter解耦架构模型和跨组件状态管理

2,918 阅读7分钟

FAC(Flutter Architecture Components)

FAC Flutter 架构组件(Flutter Architecture Components) 致力于解决Flutter跨组件刷新和集中化状态管理、关注点分离、构建高性能Flutter页面;

源码请查看:Github

Feature

与Provider相比:

  • FAC提供了强大了解耦装置ViewModel
  • 更为简洁的状态关联方式;
  • 以页面或APP纬度的集中化状态管理ViewModelStore
  • 更高效的刷新机制(支持LiveState对状态隔离,memo过滤参数列表)
  • 在initState中可以触发状态更新,比如加载数据,初始化页面数据等

FAC架构组件模型

  • 简单的抽象模型 可以将数据放于VM中进行集中化管理,通过LiveState将UI和数据进行关联;
  • 类比AAC image.png

没错,FAC看起来与AAC(Android Architecture Components)框架如出一辙,我们构建了带有生命周期监听的可观察数据对象LiveState,用于实现状态和UI控制器绑定;并实现ViewModelStoreProxyWidget用来存储和卸载ViewModel对象——当然在业务开发中,我们并不需要关注它的存在,会在架构层合适的位置进行注入;

这一切,对熟悉Android原生AAC组件的开发者来说,是一个福音;因为相对大而笨重的Provider,复杂的Redux框架来说,对FAC的学习是零成本!

使用场景

  • 组件状态共享,组件间状态可被观察
  • 跨组件通信/刷新
  • 任意代码位置获取目标组件状态并刷新
  • 某个组件需要改变全局状态
  • 构建大型复杂业务及多页面嵌套场景

安装 FAC

修改 pubspec.yaml

dependencies:
  pikach_fac: ^1.0.3

使用

三步搞定企业级复杂业务场景、代码分层和状态管理:

  • 1.定义ViewModel和Model数据类型
class PageViewModel extends ViewModel {
  LiveState<PageModel> pageModel = LiveState<PageModel>(PageModel());

  ///定义静态方法,便于任意位置获取PageViewModel的实例(可选)
  static PageViewModel get(BuildContext context) {
    return ViewModel.of<PageViewModel>(
      context,
      builder: () => PageViewModel(),
    );
  }
  ///定义业务的实现
  void onCountClick(BuildContext context) {
    PageViewModel.get(context).pageModel.setState((value, _) {
      _.state.count++;
    });
  }

}

  • 2.定义LiveState
LiveState<PageModel> pageModel = LiveState<PageModel>(PageModel());
  • 3.UI和状态绑定
  ///建立数据和UI的绑定关系
  PageViewModel.get(context).pageModel.buildWithObserve((ctx, _state) {

    return Padding(
      padding: const EdgeInsets.all(8.0),
      child: new Row(
        children: <Widget>[
          Text(
            '刷新优化,只有count变化才刷新: ${_state.count}',
          ),
        ],
      ),
    );
  }, memo: (value) => [value.count])

详细代码请查阅Github

数据流

image.png

架构设计背景

架构设计的初衷,是为了解决Flutter在复杂的嵌套页面场景下,能够有效的管理页面的状态和刷新效率;对于简单的业务场景,同样有友好的代码分层和状态管理能力!

以下是业务中采用FAC开发的Flutter页面: image.png

组件

1. LiveState组件

LiveState:可被观察的数据组件;称之为Live的原理,是因为它可以感知Widget组件的生命周期!

LiveState 可用于构建可被观察的数据对象,即构建model;在数据发生变更时,并且在生命周期合法的情况,能够及时通知到观察者;用于分发或转发数据对象(MediatorLiveState可以用作转发或合并数据源);

LiveState可以单独使用,去构建跨组件刷新模型; 但是我们更推荐将其放在 ViewModel 组件中,这样可以将model对象转化成 ViewModel ,从而构建 UI 和 Model 分离的代码结构!

//在ViewModel中实例化LiveState对象
LiveState<ReportRequestModel> _reportRequest;

LiveState<ReportRequestModel> get reportRequest =>
  _reportRequest ??= LiveState<ReportRequestModel>(ReportRequestModel());

其他接口

LiveState提供其它相关接口,用于响应式编程开发;

  • StateOwner 用于提供state的整体变更
class StateOwner<T> {
  T state;
} 
  • MediatorLiveState 用于合并多个LiveState数据源,更利于构建响应式应用 image.png
  • Transformations 用于LiveState数据源变化,由于dart不支持反射,可能并没有那么好用,建议直接用 MediatorLiveState 替代

2. ViewModel组件

ViewModel:分离数据和 UI,专注于逻辑处理,构建数据和UI的双向绑定;

另外,该类中提供appContext用于navigation等与element无关的调用,该context来自于VMS!

1.生命周期安全

ViewModel 的声明周期与当前页面周期是一致的,不需要担心内存泄漏或关注回收的工作;

2.数据和UI解耦

直接使用 Provider,需要手动构建 ViewModel 构建数据和 UI 的解耦模型;而 ViewModel 组件为解决该问题应运而生! ViewModel 可以用来管理UI所需的相关数据,承担UI和Model之间的交互和处理业务逻辑。 在页面的任何位置,我们可以通过ViewModel.of<T>(context)获取相应的 ViewModel 实例,从而建立UI和Model的双向关联! ViewModel 可以胜任各种复杂的交互、业务逻辑、异步调用等;我们所有的修改都基于model,model 会自动关联注册的UI对象(Flutter Widget),从而构建一个单一数据源的模型; 因为组件的刷新是通过Model自动关联的(而不是调用 State 中的 setState() 方法),我们更期望通过仅使用StatelessWidget去构建应用!

3.构建跨组件通信接口

ViewModel用来提供自定义组件刷新接口 比如一个 AppBar需要提供title改变的接口,或 AppBar 的右侧Action中提供一个购物车数量指示。典型的跨组件刷新问题,可以通过 ViewModel 向往提供接口,开发者可以按需调用!

3. ViewModelStoreProxyWidget 组件

类似Redux中Store但是 ViewModelStoreProxyWidget 中共享的数据是当前页面相关的;开发者往往不需要关注它的存在,因为我们会通过框架在合适的位置注入。

_ViewModelStore 数据存储组件

类似Android中 lifecycle-viewmodel 组件包里的 ViewModelStore 组件,ViewModelStoreProxyWidget 作为页面顶级Widget,通过 InheritedWidget 共享页面的数据!当然,它的存储方式和原生端 VMS 如出一辙,采用Map<Type, dynamic>()对ViewModel进行存储;另外,我们为了适应复杂的大型应用场景,增加了final _factoriesByName = Map<String, dynamic>();的存储方式,可以存储多个同名的 ViewModel,使得单页面中的同组件类型接口问题得以解决!

设计原理

image.png

代理拦截与代理穿透

  • 代理拦截

我们在任何位置可以轻松获取数据源并刷新UI的便利很大程度来源于代理拦截机制。如下,ViewModel.of<CountViewModel>(context).model

所谓的代理机制,原理很简单,我们会通过Provider在合适位置注册VMS进行节点拦截,因为inheritWidget会在最近位置通过泛型获取数据,从而达到拦截的目的。 收益:

  • 防止外层页面和当前子页面数据混用

  • 在任何位置可以获取数据并刷新UI

  • 代理穿透

供代理拦截机制后,我们如何获取外层组件数据呢? ViewModel提供了一种代理穿透的方式获取更外层数据。

代理拦截和代理穿透模式如下 image.png

代理截断的场景.png

代理穿透演示 image.png

共享Stroe

页面通过 instanceName 参数,可以在一个VMS下面共享多个同类型ViewModel;从而在一个页面下面,可以嵌套多个同类型组件,并调用不同组件的方法;

拓展

自定义组件接口

自定义组件如何对外提供组件刷新接口?

直接使用Provider

Provider的方式是通过在上层节点上挂载Provider通过ChangeNotifier构建的Model刷新 Provider 实例刷新Consumer下的子组件。这个过程对于我而言,异常的漫长,且过于耦合;不能提供一个对外跨组件刷新的接口。

使用FAC

有没有什么方式能通过,提供自定义组件的同时,提供组件的对外刷新接口,且这个组件刷新接口可以在代码的任何位置被调用?比如 AppBar 提供标题修改的接口,购物车提供商品数量变化的接口;

  • LoadingPage实现
    LoadingPage是页面状态管理组件,有页面加载、错误、空数据、显示等状态;

由于使用FAC时,可以在页面任意位置获取ViewModel的实例,我们可以在开发自定义Widget LoadingPage的时候提供一个VM接口;外部可以使用该接口进行刷新:

PkcPageViewModel.get(context, instance: instance).pageLiveData.setState((value, _) {
        value.pageState = PkcPageState.state_loading;
      });

请查阅关于LoadingPage的组件实现Github

  • AppBar刷新和购物车接口 image.png image.png

参考