Flutter Provider 原理解析

Posted 2022-02-20 一叶飘舟

阅读本文可收获

1. 知晓Flutter中InheritedWidget的使用场景和基本原理
2. 知晓现在市面上的Provider的实现方案
3. 实现一个简易版的 MiniProvider

Flutter Provider的主要功能

1. 数据共享
2. 局部刷新

要实现以上两个功能点，首先要来了解一下Flutter中的InheritedWidget

InheritedWidget简介

Flutter Widget 简介

Everything is a widget. Widget是『描述』 Flutter UI 的基本单元，通过Widget可以做到：

• 描述UI的层级结构 （Widget嵌套）
• 定制UI的具体样式 （如：font color等）
• 指导UI的布局过程 （如：center padding等）

按照功能划分Widget可大致分为三类 

• 「Component Widget」 —— 组合类 Widget，这类 Widget 都直接或间接继承于StatelessWidget或StatefulWidget，Widget 设计上遵循组合大于继承的原则，通过组合功能相对单一的 Widget 可以得到功能更为复杂的 Widget。平常的业务开发主要是在开发这一类型的 Widget；

• 「Proxy Widget」 —— 代理类 Widget，正如其名，「Proxy Widget」本身并不涉及 Widget 内部逻辑，只是为「Child Widget」提供一些附加的中间功能。典型的如：InheritedWidget用于在「Descendant Widgets」间传递共享信息、ParentDataWidget用于配置「Descendant Renderer Widget」的布局信息；

• 「Renderer Widget」 —— 渲染类 Widget，是最核心的Widget类型，会直接参与后面的「Layout」、「Paint」流程，无论是「Component Widget」还是「Proxy Widget」最终都会映射到「Renderer Widget」上，否则将无法被绘制到屏幕上。这 3 类 Widget 中，只有「Renderer Widget」有与之一一对应的「Render Object」

InheritedWidget属于Proxies用于在Widget间传递共享数据

InheritedWidget是Flutter中非常重要的一个功能型组件，它提供了一种数据在widget树中从上到下传递、共享的方式，比如我们在应用的根widget中通过InheritedWidget共享了一个数据，那么我们便可以在任意子widget中来获取该共享的数据！这个特性在一些需要在widget树中共享数据的场景中非常方便！如Flutter SDK中正是通过InheritedWidget来共享应用主题（Theme）和Locale (当前语言环境)信息的

InheritedWidget的信息传递方向是从上到下的

InheritedWidget共有两个方法

1. createElement() （创建对应的Element）
2. updateShouldNotify(covariant InheritedWidget oldWidget)

  /// Whether the framework should notify widgets that inherit from this widget.
  ///
  /// When this widget is rebuilt, sometimes we need to rebuild the widgets that
  /// inherit from this widget but sometimes we do not. For example, if the data
  /// held by this widget is the same as the data held by `oldWidget`, then we
  /// do not need to rebuild the widgets that inherited the data held by
  /// `oldWidget`.
  ///
  /// The framework distinguishes these cases by calling this function with the
  /// widget that previously occupied this location in the tree as an argument.
  /// The given widget is guaranteed to have the same [runtimeType] as this
  /// object.
  @protected
  bool updateShouldNotify(covariant InheritedWidget oldWidget);
复制代码

大致意思就是：当该Widget rebuild之后是否通知依赖该Widget数据的子孙刷新数据

在InheritedElement中_dependents用来维护依赖子孙的Widget

/// An [Element] that uses an [InheritedWidget] as its configuration.
class InheritedElement extends ProxyElement 
  /// Creates an element that uses the given widget as its configuration.
  InheritedElement(InheritedWidget widget) : super(widget);

  @override
  InheritedWidget get widget => super.widget;

  final Map<Element, Object> _dependents = HashMap<Element, Object>();

  @override
  void _updateInheritance() 
    assert(_active);
    final Map<Type, InheritedElement> incomingWidgets = _parent?._inheritedWidgets;
    if (incomingWidgets != null)
      _inheritedWidgets = HashMap<Type, InheritedElement>.from(incomingWidgets);
    else
      _inheritedWidgets = HashMap<Type, InheritedElement>();
    _inheritedWidgets[widget.runtimeType] = this;
  
复制代码

子孙Widget怎么注册数据依赖呢？ BuildContext中的dependOnInheritedWidgetOfExactType方法就是增加依赖

T dependOnInheritedWidgetOfExactType<T extends InheritedWidget>( Object aspect );
复制代码

可能有人会问，如果子孙Widget使用了InheritedWidget中的数据但又不想在之后的数据变化中更新数据那怎么办呢？

InheritedElement getElementForInheritedWidgetOfExactType<T extends InheritedWidget>();
复制代码

下面是一个使用例子

  //定义一个便捷方法，方便子树中的widget获取共享数据
  //添加一个listen参数，表示是否建立依赖关系
  static T of<T>(BuildContext context, bool listen = true) 
    final provider = listen
        ? context.dependOnInheritedWidgetOfExactType<InheritedProvider<T>>()
        : context
            .getElementForInheritedWidgetOfExactType<InheritedProvider<T>>()
            ?.widget as InheritedProvider<T>;
    return provider.data;
  
复制代码

StatefulWidget的State对象有一个didChangeDependencies回调，它会在“依赖”发生变化时被Flutter Framework调用。而这个“依赖”指的就是子widget是否使用了父widget中InheritedWidget的数据！如果使用了，则代表子widget依赖有依赖InheritedWidget；如果没有使用则代表没有依赖。这种机制可以使子组件在所依赖的InheritedWidget变化时来更新自身！比如当主题、locale(语言)等发生变化时，依赖其的子widget的didChangeDependencies方法将会被调用,didChangeDependencies方法内调用了markNeedBuild然后进入了rebuild流程。

以上InheritedWidget特性，我们可以在Provider的局部刷新部分使用。 它的天生特性就是能绑定InheritedWidget与依赖它的子孙组件的依赖关系，并且当InheritedWidget数据发生变化时，可以自动更新依赖的子孙组件！利用这个特性，我们可以将需要跨组件共享的状态保存在InheritedWidget中，然后在子组件中引用InheritedWidget即可。

MiniProvider实现

Flutter社区著名的Provider包正是基于这个思想实现的一套跨组件状态共享解决方案，接下来我们便详细介绍一下Provider的用法及原理。

实现Provider，首先我们需要一个保存共享数据的InheritedWidget，由于具体业务数据类型不可预期，为了通用性，我们使用泛型，定义一个通用的InheritedProvider类，它继承自InheritedWidget：

// 一个通用的InheritedWidget，保存任需要跨组件共享的状态
class InheritedProvider<T> extends InheritedWidget 
  InheritedProvider(@required this.data, Widget child) : super(child: child);

  //共享状态使用泛型
  final T data;

  @override
  bool updateShouldNotify(InheritedProvider<T> old) 
    //在此简单返回true，则每次更新都会调用依赖其的子孙节点的`didChangeDependencies`。
    return true;
  

复制代码

数据保存的地方有了，那么接下来我们需要做的就是在数据发生变化的时候来重新构建InheritedProvider，那么现在就面临两个问题：

1. 数据发生变化怎么通知？
2. 谁来重新构建InheritedProvider？

第一个问题其实很好解决，我们当然可以使用之前介绍的EventBus来进行事件通知，但是为了更贴近Flutter开发，我们使用Flutter SDK中提供的ChangeNotifier类 ，它继承自Listenable，也实现了一个Flutter风格的发布者-订阅者模式，ChangeNotifier定义大致如下：

class ChangeNotifier implements Listenable 
  List listeners=[];
  @override
  void addListener(VoidCallback listener) 
     //添加监听器
     listeners.add(listener);
  
  @override
  void removeListener(VoidCallback listener) 
    //移除监听器
    listeners.remove(listener);
  

  void notifyListeners() 
    //通知所有监听器，触发监听器回调 
    listeners.forEach((item)=>item());
  

  ... //省略无关代码

复制代码

我们可以通过调用addListener()和removeListener()来添加、移除监听器（订阅者）；通过调用notifyListeners() 可以触发所有监听器回调。

现在，我们将要共享的状态放到一个Model类中，然后让它继承自ChangeNotifier，这样当共享的状态改变时，我们只需要调用notifyListeners() 来通知订阅者，然后由订阅者来重新构建InheritedProvider，这也是第二个问题的答案！接下来我们便实现这个订阅者类：

class ChangeNotifierProvider<T extends ChangeNotifier> extends StatefulWidget 
  ChangeNotifierProvider(
    Key key,
    this.data,
    this.child,
  );

  final Widget child;
  final T data;

  //定义一个便捷方法，方便子树中的widget获取共享数据
  static T of<T>(BuildContext context) 
    final type = _typeOf<InheritedProvider<T>>();
    final provider =  context.dependOnInheritedWidgetOfExactType<InheritedProvider<T>>();
    return provider.data;
  

  @override
  _ChangeNotifierProviderState<T> createState() => _ChangeNotifierProviderState<T>();

复制代码

该类继承StatefulWidget，然后定义了一个of()静态方法供子类方便获取Widget树中的InheritedProvider中保存的共享状态(model)，下面我们实现该类对应的_ChangeNotifierProviderState类：

class _ChangeNotifierProviderState<T extends ChangeNotifier> extends State<ChangeNotifierProvider<T>> 
  void update() 
    //如果数据发生变化（model类调用了notifyListeners），重新构建InheritedProvider
    setState(() => );
  

  @override
  void didUpdateWidget(ChangeNotifierProvider<T> oldWidget) 
    //当Provider更新时，如果新旧数据不"=="，则解绑旧数据监听，同时添加新数据监听
    if (widget.data != oldWidget.data) 
      oldWidget.data.removeListener(update);
      widget.data.addListener(update);
    
    super.didUpdateWidget(oldWidget);
  

  @override
  void initState() 
    // 给model添加监听器
    widget.data.addListener(update);
    super.initState();
  

  @override
  void dispose() 
    // 移除model的监听器
    widget.data.removeListener(update);
    super.dispose();
  

  @override
  Widget build(BuildContext context) 
    return InheritedProvider<T>(
      data: widget.data,
      child: widget.child,
    );
  

复制代码

可以看到_ChangeNotifierProviderState类的主要作用就是监听到共享状态（model）改变时重新构建Widget树。注意，在_ChangeNotifierProviderState类中调用setState()方法，widget.child始终是同一个，所以执行build时，InheritedProvider的child引用的始终是同一个子widget，所以widget.child并不会重新build，这也就相当于对child进行了缓存！当然如果ChangeNotifierProvider父级Widget重新build时，则其传入的child便有可能会发生变化。

现在我们所需要的各个工具类都已完成，下面我们通过一个购物车的例子来看看怎么使用上面的这些类。

购物车示例

我们需要实现一个显示购物车中所有商品总价的功能：

1. 向购物车中添加新商品时总价更新

定义一个Item类，用于表示商品信息：

class Item 
  Item(this.price, this.count);
  double price; //商品单价
  int count; // 商品份数
  //... 省略其它属性

复制代码

定义一个保存购物车内商品数据的CartModel类:

class CartModel extends ChangeNotifier 
  // 用于保存购物车中商品列表
  final List<Item> _items = [];

  // 禁止改变购物车里的商品信息
  UnmodifiableListView<Item> get items => UnmodifiableListView(_items);

  // 购物车中商品的总价
  double get totalPrice =>
      _items.fold(0, (value, item) => value + item.count * item.price);

  // 将 [item] 添加到购物车。这是唯一一种能从外部改变购物车的方法。
  void add(Item item) 
    _items.add(item);
    // 通知监听器（订阅者），重新构建InheritedProvider， 更新状态。
    notifyListeners();
  

复制代码

CartModel即要跨组件共享的model类。最后我们构建示例页面：

class ProviderRoute extends StatefulWidget 
  @override
  _ProviderRouteState createState() => _ProviderRouteState();


class _ProviderRouteState extends State<ProviderRoute> 
  @override
  Widget build(BuildContext context) 
    return Center(
      child: ChangeNotifierProvider<CartModel>(
        data: CartModel(),
        child: Builder(builder: (context) 
          return Column(
            children: <Widget>[
              Builder(builder: (context)
                var cart=ChangeNotifierProvider.of<CartModel>(context);
                return Text("总价: $cart.totalPrice");
              ),
              Builder(builder: (context)
                print("RaisedButton build"); //在后面优化部分会用到
                return RaisedButton(
                  child: Text("添加商品"),
                  onPressed: () 
                    //给购物车中添加商品，添加后总价会更新
                    ChangeNotifierProvider.of<CartModel>(context).add(Item(20.0, 1));
                  ,
                );
              ),
            ],
          );
        ),
      ),
    );
  

复制代码

运行示例后效果如图7-2所示：

每次点击”添加商品“按钮，总价就会增加20，我们期望的功能实现了！可能有些读者会疑惑，我们饶了一大圈实现这么简单的功能有意义么？其实，就这个例子来看，只是更新同一个路由页中的一个状态，我们使用ChangeNotifierProvider的优势并不明显，但是如果我们是做一个购物APP呢？由于购物车数据是通常是会在整个APP中共享的，比如会跨路由共享。如果我们将ChangeNotifierProvider放在整个应用的Widget树的根上，那么整个APP就可以共享购物车的数据了，这时ChangeNotifierProvider的优势将会非常明显。

虽然上面的例子比较简单，但它却将Provider的原理和流程体现的很清楚，图7-3是Provider的原理图：

 Model变化后会自动通知ChangeNotifierProvider（订阅者），ChangeNotifierProvider内部会重新构建InheritedWidget，而依赖该InheritedWidget的子孙Widget就会更新。

我们可以发现使用Provider，将会带来如下收益：

我们的业务代码更关注数据了，只要更新Model，则UI会自动更新，而不用在状态改变后再去手动调用setState()来显式更新页面。 数据改变的消息传递被屏蔽了，我们无需手动去处理状态改变事件的发布和订阅了，这一切都被封装在Provider中了。这真的很棒，帮我们省掉了大量的工作！ 在大型复杂应用中，尤其是需要全局共享的状态非常多时，使用Provider将会大大简化我们的代码逻辑，降低出错的概率，提高开发效率

优化

我们上面实现的ChangeNotifierProvider是有两个明显缺点：代码组织问题和性能问题，下面我们一一讨论。

代码组织问题

我们先看一下构建显示总价Text的代码：

Builder(builder: (context)
  var cart=ChangeNotifierProvider.of<CartModel>(context);
  return Text("总价: $cart.totalPrice");
)
复制代码

这段代码有两点可以优化：

1. 需要显式调用ChangeNotifierProvider.of，当APP内部依赖CartModel很多时，这样的代码将很冗余。
2. 语义不明确；由于ChangeNotifierProvider是订阅者，那么依赖CartModel的Widget自然就是订阅者，其实也就是状态的消费者，如果我们用Builder 来构建，语义就不是很明确；如果我们能使用一个具有明确语义的Widget，比如就叫Consumer，这样最终的代码语义将会很明确，只要看到Consumer，我们就知道它是依赖某个跨组件或全局的状态。

为了优化这两个问题，我们可以封装一个Consumer Widget，实现如下：

// 这是一个便捷类，会获得当前context和指定数据类型的Provider
class Consumer<T> extends StatelessWidget 
  Consumer(
    Key key,
    @required this.builder,
    this.child,
  )  : assert(builder != null),
        super(key: key);

  final Widget child;

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

  @override
  Widget build(BuildContext context) 
    return builder(
      context,
      ChangeNotifierProvider.of<T>(context), //自动获取Model
    );
  

复制代码

Consumer实现非常简单，它通过指定模板参数，然后再内部自动调用ChangeNotifierProvider.of获取相应的Model，并且Consumer这个名字本身也是具有确切语义（消费者）。现在上面的代码块可以优化为如下这样：

Consumer<CartModel>(
  builder: (context, cart)=> Text("总价: $cart.totalPrice");
)
复制代码

是不是很优雅

性能问题

上面的代码还有一个性能问题，就在构建”添加按钮“的代码处：

Builder(builder: (context) 
  print("RaisedButton build"); // 构建时输出日志
  return RaisedButton(
    child: Text("添加商品"),
    onPressed: () 
      ChangeNotifierProvider.of<CartModel>(context).add(Item(20.0, 1));
    ,
  );

复制代码

我们点击”添加商品“按钮后，由于购物车商品总价会变化，所以显示总价的Text更新是符合预期的，但是”添加商品“按钮本身没有变化，是不应该被重新build的。但是我们运行示例，每次点击”添加商品“按钮，控制台都会输出"RaisedButton build"日志，也就是说”添加商品“按钮在每次点击时其自身都会重新build！这是为什么呢？如果你已经理解了InheritedWidget的更新机制，那么答案一眼就能看出：这是因为构建RaisedButton的Builder中调用了ChangeNotifierProvider.of，也就是说依赖了Widget树上面的InheritedWidget（即InheritedProvider ）Widget，所以当添加完商品后，CartModel发生变化，会通知ChangeNotifierProvider, 而ChangeNotifierProvider则会重新构建子树，所以InheritedProvider将会更新，此时依赖它的子孙Widget就会被重新构建。

问题的原因搞清楚了，那么我们如何避免这不必要重构呢？既然按钮重新被build是因为按钮和InheritedWidget建立了依赖关系，那么我们只要打破或解除这种依赖关系就可以了。那么如何解除按钮和InheritedWidget的依赖关系呢？我们上一节介绍InheritedWidget时已经讲过了：调用dependOnInheritedWidgetOfExactType() 和 getElementForInheritedWidgetOfExactType()的区别就是前者会注册依赖关系，而后者不会。所以我们只需要将ChangeNotifierProvider.of的实现改为下面这样即可：

//添加一个listen参数，表示是否建立依赖关系
  static T of<T>(BuildContext context, bool listen = true) 
    final type = _typeOf<InheritedProvider<T>>();
    final provider = listen
        ? context.dependOnInheritedWidgetOfExactType<InheritedProvider<T>>()
        : context.getElementForInheritedWidgetOfExactType<InheritedProvider<T>>()?.widget
            as InheritedProvider<T>;
    return provider.data;
  
复制代码

然后我们将代码改为：

Column(
    children: <Widget>[
      Consumer<CartModel>(
        builder: (BuildContext context, cart) =>Text("总价: $cart.totalPrice"),
      ),
      Builder(builder: (context) 
        print("RaisedButton build");
        return RaisedButton(
          child: Text("添加商品"),
          onPressed: () 
            // listen 设为false，不建立依赖关系
            ChangeNotifierProvider.of<CartModel>(context, listen: false)
                .add(Item(20.0, 1));
          ,
        );
      )
    ],
  )
复制代码

修改后再次运行上面的示例，我们会发现点击”添加商品“按钮后，控制台不会再输出"RaisedButton build"了，即按钮不会被重新构建了。而总价仍然会更新，这是因为Consumer中调用ChangeNotifierProvider.of时listen值为默认值true，所以还是会建立依赖关系。

至此我们便实现了一个迷你的Provider，它具备Pub上Provider Package中的核心功能；但是我们的迷你版功能并不全面，如只实现了一个可监听的ChangeNotifierProvider，并没有实现只用于数据共享的Provider；另外，我们的实现有些边界也没有考虑的到，比如如何保证在Widget树重新build时Model始终是单例等。所以建议读者在实战中还是使用Provider Package，而本节实现这个迷你Provider的主要目的主要是为了帮助读者了解Provider Package底层的原理。

其他状态管理包

现在Flutter社区已经有很多专门用于状态管理的包了，在此我们列出几个相对评分比较高的：

包名	介绍
Provider & ScopedModel	这两个都是基于inheredWidget 原理相似
Redux	是Web开发中React生态链中Redux包的Flutter实现
Mobx	是Web开发中React生态链中MobX的Flutter实现
BLoC	是BLoC模式Flutter的实现

总结

通过介绍InheritedWidget，了解了状态的共享的思想，然后基于该思想实现了一个简单的Provider，在实现的过程中也更深入的探索了InheritedWidget与其依赖项的注册机制和更新机制。通过本文的学习，读者应该达到两个目标，首先是对InheritedWidget彻底吃透，其次是Provider的设计思想。