Flutter完整开发实战详解(十五、全面理解State与Pro

作者: 恋猫月亮 | 来源:发表于2019-06-16 20:25 被阅读18次

本篇将带你深入理解 Flutter 中 State 的工作机制，并通过对状态管理框架 Provider 解析加深理解，看完这一篇你将更轻松的理解你的 “State 大后宫” 。

前文：

一、 Dart语言和Flutter基础

二、快速开发实战篇

三、打包与填坑篇

四、 Redux、主题、国际化

五、深入探索

六、深入Widget原理

七、深入布局原理

八、实用技巧与填坑

九、深入绘制原理

十、深入图片加载流程

十一、全面深入理解Stream

十二、全面深入理解状态管理设计

十三、全面深入触摸和滑动原理

十四、混合开发打包 Android 篇


⚠️第十二篇中更多讲解状态的是管理框架，本篇更多讲解 Flutter 本身的状态设计。

一、State

1、State 是什么？

我们知道 Flutter 宇宙中万物皆 Widget ，而 Widget 是 @immutable 即不可变的，所以每个 Widget 状态都代表了一帧。

在这个基础上， StatefulWidget 的 State 帮我们实现了在 Widget 的跨帧绘制 ，也就是在每次 Widget 重绘的时候，通过 State 重新赋予 Widget 需要的绘制信息。

2、State 怎么实现跨帧共享？

这就涉及 Flutter 中 Widget 的实现原理，在之前的篇章我们介绍过，这里我们说两个涉及的概念：

Flutter 中的 Widget 在一般情况下，是需要通过 Element 转化为 RenderObject 去实现绘制的。
Element 是 BuildContext 的实现类，同时 Element 持有 RenderObject 和 Widget ，我们代码中的 Widget build(BuildContext context) {} 方法，就是被 Element 调用的。

了解这个两个概念后，我们先看下图，在 Flutter 中构建一个 Widget ，首先会创建出这个 Widget 的 Element ，而事实上 State 实现跨帧共享，就是将 State 保存在Element 中，这样 Element 每次调用 Widget build() 时，是通过 state.build(this); 得到的新 Widget ，所以写在 State 的数据就得以复用了。

那 State 是在哪里被创建的？

如下图所示，StatefulWidget 的 createState 是在 StatefulElement 的构建方法里创建的， 这就保证了只要 Element 不被重新创建，State 就一直被复用。

同时我们看 update 方法，当新的 StatefulWidget 被创建用于更新 UI 时，新的 widget 就会被重新赋予到 _state 中，而这的设定也导致一个常被新人忽略的问题。

我们先看问题代码，如下图所示：

1、在 _DemoAppState 中，我们创建了 DemoPage , 并且把 data 变量赋给了它。
2、DemoPage 在创建 createState 时，又将 data 通过直接传入 _DemoPageState 。
3、在 _DemoPageState 中直接将传入的 data 通过 Text 显示出来。

运行后我们一看也没什么问题吧？ 但是当我们点击 4 中的 setState 时，却发现 3 中 Text 没有发现改变， 这是为什么呢？

问题就在于前面 StatefulElement 的构建方法和 update 方法：

State 只在 StatefulElement 的构建方法中创建，当我们调用 setState 触发 update 时，只是执行了 _state.widget = newWidget，而我们通过 _DemoPageState(this.data) 传入的 data ，在传入后执行setState 时并没有改变。

如果我们采用上图代码中 3 注释的 widget.data 方法，因为 _state.widget = newWidget 时，State 中的 Widget 已经被更新了，Text 自然就被更新了。

3、setState 干了什么？

我们常说的 setState ，其实是调用了 markNeedsBuild ，markNeedsBuild 内部会标记 element 为 diry，然后在下一帧 WidgetsBinding.drawFrame 才会被绘制，这可以也看出 setState 并不是立即生效的。

4、状态共享

前面我们聊了 Flutter 中 State 的作用和工作原理，接下来我们看一个老生常谈的对象： InheritedWidget 。

状态共享是常见的需求，比如用户信息和登陆状态等等，而 Flutter 中 InheritedWidget 就是为此而设计的，在第十二篇我们大致讲过它：

在 Element 的内部有一个 Map<Type, InheritedElement> _inheritedWidgets; 参数，_inheritedWidgets 一般情况下是空的，只有当父控件是 InheritedWidget 或者本身是 InheritedWidgets 时，它才会有被初始化，而当父控件是 InheritedWidget 时，这个 Map 会被一级一级往下传递与合并。

所以当我们通过 context 调用 inheritFromWidgetOfExactType 时，就可以通过这个 Map 往上查找，从而找到这个上级的 InheritedWidget 。

噢，是的，InheritedWidget 共享的是 Widget ，只是这个 Widget 是一个 ProxyWidget ，它自己本身并不绘制什么，但共享这个 Widget 内保存有的值，却达到了共享状态的目的。

如下代码所示，Flutter 内 Theme 的共享，共享的其实是 _InheritedTheme 这个 Widget ，而我们通过 Theme.of(context) 拿到的，其实就是保存在这个 Widget 内的 ThemeData 。

  static ThemeData of(BuildContext context, { bool shadowThemeOnly = false }) {
    final _InheritedTheme inheritedTheme = context.inheritFromWidgetOfExactType(_InheritedTheme);
    if (shadowThemeOnly) {
      /// inheritedTheme 这个 Widget 内的 theme
      /// theme 内有我们需要的 ThemeData
      return inheritedTheme.theme.data;
    }
    ···
  }

这里有个需要注意的点，就是 inheritFromWidgetOfExactType 方法刚了什么？

我们直接找到 Element 中的 inheritFromWidgetOfExactType 方法实现，如下关键代码所示：

首先从 _inheritedWidgets 中查找是否有该类型的 InheritedElement 。
查找到后添加到 _dependencies 中，并且通过 updateDependencies 将当前 Element 添加到 InheritedElement 的 _dependents 这个Map 里。
返回 InheritedElement 中的 Widget 。

  @override
  InheritedWidget inheritFromWidgetOfExactType(Type targetType, { Object aspect }) {
    /// 在共享 map _inheritedWidgets 中查找
    final InheritedElement ancestor = _inheritedWidgets == null ? null : _inheritedWidgets[targetType];
    if (ancestor != null) {
      /// 返回找到的 InheritedWidget ，同时添加当前 element 处理
      return inheritFromElement(ancestor, aspect: aspect);
    }
    _hadUnsatisfiedDependencies = true;
    return null;
  }

  @override
  InheritedWidget inheritFromElement(InheritedElement ancestor, { Object aspect }) {
    _dependencies ??= HashSet<InheritedElement>();
    _dependencies.add(ancestor);
   /// 就是将当前 element（this） 添加到  _dependents 里
   /// 也就是 InheritedElement 的 _dependents
   /// _dependents[dependent] = value;
    ancestor.updateDependencies(this, aspect);
    return ancestor.widget;
  }

  @override
  void notifyClients(InheritedWidget oldWidget) {
    for (Element dependent in _dependents.keys) {
      notifyDependent(oldWidget, dependent);
    }
  }

这里面的关键就是 ancestor.updateDependencies(this, aspect); 这个方法：

我们都知道，获取 InheritedWidget 一般需要 BuildContext ，如Theme.of(context) ，而 BuildContext 的实现就是 Element ，所以当我们调用 context.inheritFromWidgetOfExactType 时，就会将这个 context 所代表的 Element 添加到 InheritedElement 的 _dependents 中。

这代表着什么？

比如当我们在 StatefulWidget 中调用 Theme.of(context).primaryColor 时，传入的 context 就代表着这个 Widget 的 Element，在 InheritedElement 里被“登记”到 _dependents 了。

而当 InheritedWidget 被更新时，如下代码所示，_dependents 中的 Element 会被逐个执行 notifyDependent ，最后触发 markNeedsBuild ，这也是为什么当 InheritedWidget 被更新时，通过如 Theme.of(context).primaryColor 引用的地方，也会触发更新的原因。

下面开始实际分析 Provider 。

二、Provider

为什么会有 Provider ？

因为 Flutter 与 React 技术栈的相似性，所以在 Flutter 中涌现了诸如flutter_redux 、flutter_dva 、 flutter_mobx 、 fish_flutter 等前端式的状态管理，它们大多比较复杂，而且需要对框架概念有一定理解。

而作为 Flutter 官方推荐的状态管理 scoped_model ，又因为其设计较为简单，有些时候不适用于复杂的场景。

所以在经历了一端坎坷之后，今年 Google I/O 大会之后， Provider 成了 Flutter 官方新推荐的状态管理方式之一。

它的特点就是： 不复杂，好理解，代码量不大的情况下，可以方便组合和控制刷新颗粒度 ，而原 Google 官方仓库的状态管理 flutter-provide 已宣告GG ， provider 成了它的替代品。

⚠️注意，`provider` 比 `flutter-provide` 多了个 `r`。

题外话：以前面试时，偶尔会被面试官问到“你的开源项目代码量也不多啊”这样的问题，每次我都会笑而不语，虽然代码量能代表一些成果，但是我是十分反对用代码量来衡量贡献价值，这和你用加班时长来衡量员工价值有什么区别？

0、演示代码

如下代码所示，实现的是一个点击计数器，其中：

_ProviderPageState 中使用MultiProvider 提供了多个 providers 的支持。
在 CountWidget 中通过 Consumer 获取的 counter ，同时更新 _ProviderPageState 中的 AppBar 和 CountWidget 中的 Text 显示。

class _ProviderPageState extends State<ProviderPage> {
  @override
  Widget build(BuildContext context) {
    return MultiProvider(
      providers: [
        ChangeNotifierProvider(builder: (_) => ProviderModel()),
      ],
      child: Scaffold(
        appBar: AppBar(
          title: LayoutBuilder(
            builder: (BuildContext context, BoxConstraints constraints) {
              var counter =  Provider.of<ProviderModel>(context);
              return new Text("Provider ${counter.count.toString()}");
            },
          )
        ),
        body: CountWidget(),
      ),
    );
  }
}

class CountWidget extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return Consumer<ProviderModel>(builder: (context, counter, _) {
      return new Column(
        children: <Widget>[
          new Expanded(child: new Center(child: new Text(counter.count.toString()))),
          new Center(
            child: new FlatButton(
                onPressed: () {
                  counter.add();
                },
                color: Colors.blue,
                child: new Text("+")),
          )
        ],
      );
    });
  }
}

class ProviderModel extends ChangeNotifier {
  int _count = 0;

  int get count => _count;

  void add() {
    _count++;
    notifyListeners();
  }
}

所以上述代码中，我们通过 ChangeNotifierProvider 组合了 ChangeNotifier (ProviderModel) 实现共享；利用了 Provider.of 和 Consumer 获取共享的 counter 状态；通过调用 ChangeNotifier 的 notifyListeners(); 触发更新。

这里几个知识点是：

1、 Provider 的内部 DelegateWidget 是一个 StatefulWidget ，所以可以更新且具有生命周期。
2、状态共享是使用了 InheritedProvider 这个 InheritedWidget 实现的。
3、巧妙利用 MultiProvider 和 Consumer 封装，实现了组合与刷新颗粒度控制。

接着我们逐个分析

1、Delegate

既然是状态管理，那么肯定有 StatefulWidget 和 setState 调用。

在 Provider 中，一系列关于 StatefulWidget 的生命周期管理和更新，都是通过各种代理完成的，如下图所示，上面代码中我们用到的 ChangeNotifierProvider 大致经历了这样的流程：

设置到 ChangeNotifierProvider 的 ChangeNotifer 会被执行 addListener 添加监听 listener。
listener 内会调用 StateDelegate 的 StateSetter 方法，从而调用到 StatefulWidget 的 setState。
当我们执行 ChangeNotifer 的 notifyListeners 时，就会最终触发 setState 更新。

而我们使用过的 MultiProvider 则是允许我们组合多种 Provider ，如下代码所示，传入的 providers 会倒序排列，最后组合成一个嵌套的 Widget tree ，方便我们添加多种 Provider ：

  @override
  Widget build(BuildContext context) {
    var tree = child;
    for (final provider in providers.reversed) {
      tree = provider.cloneWithChild(tree);
    }
    return tree;
  }

  /// Clones the current provider with a new [child].
  /// Note for implementers: all other values, including [Key] must be
  /// preserved.
  @override
  MultiProvider cloneWithChild(Widget child) {
    return MultiProvider(
      key: key,
      providers: providers,
      child: child,
    );
  }

通过 Delegate 中回调出来的各种生命周期，如 Disposer，也有利于我们外部二次处理，减少外部 StatefulWidget 的嵌套使用。

2、InheritedProvider

状态共享肯定需要 InheritedWidget ，InheritedProvider 就是InheritedWidget 的子类，所有的 Provider 实现都在 build 方法中使用 InheritedProvider 进行嵌套，实现 value 的共享。

3、Consumer

Consumer 是 Provider 中比较有意思的东西，它本身是一个 StatelessWidget , 只是在 build 中通过 Provider.of<T>(context) 帮你获取到 InheritedWidget 共享的 value 。

  final Widget Function(BuildContext context, T value, Widget child) builder;

 @override
  Widget build(BuildContext context) {
    return builder(
      context,
      Provider.of<T>(context),
      child,
    );
  }

那我们直接使用 Provider.of<T>(context) ，不使用 Consumer 可以吗？

当然可以，但是你还记得前面，我们在介绍 InheritedWidget 时所说的：

传入的 context 代表着这个 Widget 的 Element 在 InheritedElement 里被“登记”到 _dependents 了。

Consumer 做为一个单独 StatelessWidget ，它的好处就是 Provider.of<T>(context) 传入的 context 就是 Consumer 它自己。 这样的话，我们在需要使用 Provider.value 的地方用 Consumer 做嵌套， InheritedWidget 更新的时候，就不会更新到整个页面 , 而是仅更新到 Consumer 这个 StatelessWidget 。

所以 Consumer 贴心的封装了 context 在 InheritedWidget 中的“登记逻辑”，从而控制了状态改变时，需要更新的精细度。

同时库内还提供了 Consumer2 ～ Consumer6 的组合，感受下：


  @override
  Widget build(BuildContext context) {
    return builder(
      context,
      Provider.of<A>(context),
      Provider.of<B>(context),
      Provider.of<C>(context),
      Provider.of<D>(context),
      Provider.of<E>(context),
      Provider.of<F>(context),
      child,
    );

这样的设定，相信用过 BLoC 模式的同学会感觉很贴心，以前正常用做 BLoC 时，每个 StreamBuilder 的 snapShot 只支持一种类型，多个时要不就是多个状态合并到一个实体，要不就需要多个StreamBuilder嵌套。

当然，如果你想直接利用 LayoutBuilder 搭配 Provider.of<T>(context) 也是可以的：

LayoutBuilder(
            builder: (BuildContext context, BoxConstraints constraints) {
              var counter =  Provider.of<ProviderModel>(context);
              return new Text("Provider ${counter.count.toString()}");
            }

其他的还有 ValueListenableProvider 、FutureProvider 、StreamProvider 等多种 Provider ，可见整个 Provider 的设计上更贴近 Flutter 的原生特性，同时设计也更好理解，并且兼顾了性能等问题。

Provider 的使用指南上，更详细的 Vadaski 的
《Flutter | 状态管理指南篇——Provider》已经写过，我就不重复写轮子了，感兴趣的可以过去看看。

自此，第十五篇终于结束了！(///▽///)

资源推荐

Github ： https://github.com/CarGuo
本文Demo ：https://github.com/CarGuo/state_manager_demo
完整项目：https://github.com/CarGuo/GSYGithubAppFlutter

Flutter完整开发实战详解(十五、全面理解State与Pro

一、State

1、State 是什么？

2、State 怎么实现跨帧共享？

3、setState 干了什么？

4、状态共享

二、Provider

0、演示代码

1、Delegate

2、InheritedProvider

3、Consumer

资源推荐

完整开源项目推荐：

相关文章

网友评论

延伸阅读

深度阅读

栏目导航

热点阅读

Android开发经验谈

跨平台开发公交站

Android开发

Android开发

Android技术知识

Flutter

Flutter

Flutter学习