简介

InheritedWidget是 Flutter 中非常重要的一个功能型组件，它提供了一种在 widget 树中从上到下共享数据的方式。

一、使用

先写一个最简单的例子来看看如何如何使用，创建InheritedWidget的子类

class ShareDataWidget extends InheritedWidget{

  ShareDataWidget({Key? key,required this.data,required Widget child}) : super(key: key,child: child);

  final int data;

  static ShareDataWidget? of(BuildContext context){
    return context.dependOnInheritedWidgetOfExactType<ShareDataWidget>();
    // return context.getElementForInheritedWidgetOfExactType<ShareDataWidget>()!.widget as ShareDataWidget;
  }

  @override
  bool updateShouldNotify(covariant ShareDataWidget oldWidget) {
    // TODO: implement updateShouldNotify
    return oldWidget.data != data;
  }
  
}

新增一个控件，使用ShareDataWidget的内容

class TestWidgetState extends State<TestWidget>{
  @override
  Widget build(BuildContext context) {
    // TODO: implement build
    return Text(ShareDataWidget.of(context)!.data.toString());
  }
 }

使用这个控件来达到内容的变更。

ShareDataWidget(data: _counter, child: TestWidget()),
GestureDetector(onTap: (){
  setState(() {
    _counter ++;
  });
},)

该示例仅仅为了展示InheritedWidget的使用，实际情况下想要实现这个效果可以不用使用InheritedWidget，另外这样的代码存在缺陷，一个缺陷是需要手动调用刷新，另外如果 TestWidget 里面存在多个控件，有的控件依赖了ShareDataWidget的数据，有的控件不依赖，但是当点击按钮时，所有的控件都刷新了，后文会解析原因并且优化。

二、原理篇

2.1 如何存储与获取

2.1.1 存储位置

abstract class Element extends DiagnosticableTree implements BuildContext {
……
PersistentHashMap<Type, InheritedElement>? _inheritedWidgets;//这里存储的是InheritedElement对象，会在取的时候获取对应的 Widget 对象
……
}

每一个InheritedWidget的子 Widget 控件对应的 Element 中都存有所有的父InheritedWidget对象。

2.1.2 存储过程

Element 存储_inheritedWidgets的时机是在 mount 方法中进行的

void mount(Element? parent, Object? newSlot) {
  ……
  _updateInheritance();
  ……
}
void _updateInheritance() {
  assert(_lifecycleState == _ElementLifecycle.active);
  _inheritedWidgets = _parent?._inheritedWidgets;//把父控件的_inheritedWidgets继承过来
}

InheritedElement重写了_updateInheritance方法，除了会把父控件的_inheritedWidgets继承过来，同时也会把自己添加到_inheritedWidgets中去：

void _updateInheritance() {
  assert(_lifecycleState == _ElementLifecycle.active);
  final PersistentHashMap<Type, InheritedElement> incomingWidgets =
      _parent?._inheritedWidgets ?? const PersistentHashMap<Type, InheritedElement>.empty();
  _inheritedWidgets = incomingWidgets.put(widget.runtimeType, this);
}

mount方法一层一层调用完毕后，就会把InheritedElement一级一级的赋值给所有的 element 对象。

2.1.3 获取

获取InheritedWidget的方法有两种

context.dependOnInheritedWidgetOfExactType<ShareDataWidget>()

context.getElementForInheritedWidgetOfExactType<ShareDataWidget>()!.widget as ShareDataWidget

这两个方法都是从_inheritedWidgets根据泛型获取对应是InheritedElement对象，然后获取 element 对应的 widget 对象，这样就可以做到数据共享了。 例如dependOnInheritedWidgetOfExactType代码如下：

T? dependOnInheritedWidgetOfExactType<T extends InheritedWidget>({Object? aspect}) {
  assert(_debugCheckStateIsActiveForAncestorLookup());
  final InheritedElement? ancestor = _inheritedWidgets == null ? null : _inheritedWidgets![T];
  if (ancestor != null) {
    return dependOnInheritedElement(ancestor, aspect: aspect) as T;
  }
  _hadUnsatisfiedDependencies = true;
  return null;
}

2.2 注册依赖关系和关于didChangeDependencies方法

上面两个获取InheritedWidget的方法有一个区别，一个dependOnInheritedWidgetOfExactType会触发didChangeDependencies方法，而另外一个不会，来看一下原因。

官方关于这个方法的解释是这样的：

/// Called when a dependency of this [State] object changes. /// /// For example, if the previous call to [build] referenced an /// [InheritedWidget] that later changed, the framework would call this /// method to notify this object about the change. /// /// This method is also called immediately after [initState]. It is safe to /// call [BuildContext.dependOnInheritedWidgetOfExactType] from this method. /// /// Subclasses rarely override this method because the framework always /// calls [build] after a dependency changes. Some subclasses do override /// this method because they need to do some expensive work (e.g., network /// fetches) when their dependencies change, and that work would be too /// expensive to do for every build.

里面提到，在initState方法后会直接调用，或者InheritedWidget发生改变后。直接调用是在element 的_firstBuild方法中进行的，该方法中会调用 state 的initState方法。然后调用didChangeDependencies方法，那InheritedWidget中又是如何触发didChangeDependencies的呢。

Element 中是根据_didChangeDependencies变量来控制performRebuild方法中是否要调用 state 的didChangeDependencies方法的，详细见performRebuild方法

上文提到，使用dependOnInheritedWidgetOfExactType方法获取 InheritedWidget 对象时，当内容发生变更，会触发 State 的didChangeDependencies方法，而另外一个不会，看来秘密在dependOnInheritedWidgetOfExactType方法中。使用dependOnInheritedWidgetOfExactType方法获取可以达到内容变更时调用didChangeDependencies方法，做了下面几件事情。

2.2.1 注册依赖关系

修改注册关系，在dependOnInheritedWidgetOfExactType方法中，除了从_inheritedWidges中获取InheritedWidget，还注册了父控件的依赖关系，存储在element（InheritedWidget的子控件的element）的Set<InheritedElement>? _dependencies;中，代码如下：

T? dependOnInheritedWidgetOfExactType<T extends InheritedWidget>({Object? aspect}) {
  assert(_debugCheckStateIsActiveForAncestorLookup());
  final InheritedElement? ancestor = _inheritedWidgets == null ? null : _inheritedWidgets![T];
  if (ancestor != null) {
    return dependOnInheritedElement(ancestor, aspect: aspect) as T;//注册依赖关系
  }
  _hadUnsatisfiedDependencies = true;
  return null;
}
@override
InheritedWidget dependOnInheritedElement(InheritedElement ancestor, { Object? aspect }) {
  assert(ancestor != null);
  _dependencies ??= HashSet<InheritedElement>();
  _dependencies!.add(ancestor);//这里是子控件来注册对父控件的依赖
  ancestor.updateDependencies(this, aspect);//这个方法用来在父控件中注册子控件的依赖，ancestor是父控件
  return ancestor.widget as InheritedWidget;
}

同时在InheritedElement的final Map<Element, Object?> _dependents中也注册了子控件的依赖，通过updateDependencies方法实现。

2.2.2 依赖关系 的存储位置

class InheritedElement extends ProxyElement {
  /// Creates an element that uses the given widget as its configuration.
  InheritedElement(InheritedWidget super.widget);
  /// 父 InheritedElement 中存储所有依赖了它的子 element
final Map<Element, Object?> _dependents = HashMap<Element, Object?>();
  ...
  }
abstract class Element extends DiagnosticableTree implements BuildContext {
  ...
Set<InheritedElement>? _dependencies;//子控件 element 中存有所有它依赖的 InheritedElement
...
}

2.2.3 修改_didChangeDependencies变量

第一步注册了依赖关系后，在这里就用到了，是否需要修改子控件element的_didChangeDependencies的变量值为true，取决于是否注册了依赖关系。在InheritedElement的update方法中，最终会调用notifyClients方法，在该方法中会遍历所有被注册了依赖关系的子控件（存在_dependents中），分别调用notifyDependent方法，在该方法中，会修改StatefulElement的中_didChangeDependencies属性，将它标记为true。

2.2.4 根据_didChangeDependencies判断是否调用

StatefulElement在调用performRebuild方法时,当_didChangeDependencies是true时，会调用state的didChangeDependencies方法，代码如下：

void performRebuild() {
  if (_didChangeDependencies) {
    state.didChangeDependencies();
    _didChangeDependencies = false;
  }
  super.performRebuild();
}

同理，由于getElementForInheritedWidgetOfExactType方法没有调用dependOnInheritedElement方法，则不会添加依赖关系，自然不会触发后面的步骤了，当刷新的时候，由于_didChangeDependencies是false，则state的didChangeDependencies方法不会调用。

修改_didChangeDependencies过程和刷新的流程，见下图。

2.3 Provider的刷新问题

2.3.1 现象

Provider 库使用，有如下代码：

ChangeNotifierProvider<CartModel>(
    create: (_) => CartModel(),
    child: Row(children: [
      Builder(builder: (context) {
        print("1、刷新其他控件");
        return Text("其他控件");
      }),
      Consumer<CartModel>(builder: (context, model, wiget) {
        print("2、刷新总数");
        return Text("总数:" + model.total.toString());
      }),
      Builder(builder: (context) {
        print("3、刷新添加按钮");
        return TextButton(
            onPressed: () {
              Provider.of<CartModel>(context,listen: false).add(Item(2, 4));
            },
            child: const Icon(Icons.add));
      }),
    ])),

当点击刷新按钮的时候，添加几行输出信息，控制台会有如下输出

看到控制台输出结果后，会有下面三个疑问：

1、其他控件为什么没有重新构建？

2、总数为什么可以刷新？

3、添加按钮为什么没有刷新？

2.3.2 原因

问题一，其他控件为什么没有重新构建？

先模仿 Provider库 实现一个简易版本的 ChangeNotifierProvider，方便分析问题

class ChangeNotifierProvider1<T extends ChangeNotifier> extends StatefulWidget{

  ChangeNotifierProvider1({Key? key, required this.child, required this.data});
  final Widget child;
  final T data;

  static T of<T>(BuildContext context,{bool listen = true}){
    final provider = listen == true ? context.dependOnInheritedWidgetOfExactType<InheritedProvider<T>>() : context.getElementForInheritedWidgetOfExactType<InheritedProvider<T>>()?.widget
    as InheritedProvider<T>;
    return provider!.data;
  }

  @override
  State<StatefulWidget> createState() {
    // TODO: implement createState
    return ChangeNotifierProviderState1<T>();
  }

  @override
  StatefulElement createElement() {
    // TODO: implement createElement
    return ChangeNotifierProviderElement(this);
  }

}

class ChangeNotifierProviderElement extends StatefulElement{
  ChangeNotifierProviderElement(super.widget);

  @override
  void update(covariant StatefulWidget newWidget) {
    // TODO: implement update
    super.update(newWidget);
  }
}


class ChangeNotifierProviderState1<T extends ChangeNotifier> extends State<ChangeNotifierProvider1<T>>{
  @override
  Widget build(BuildContext context) {
    // TODO: implement build
    print("调用ChangeNotifierProviderState的 build 方法");
    return InheritedProvider<T>(child: widget.child, data: widget.data);
  }

  @override
  void didUpdateWidget(ChangeNotifierProvider1<T> oldWidget){
    if(oldWidget != widget.child){
      widget.data.removeListener(update);
      widget.data.addListener(update);
    }
    super.didUpdateWidget(oldWidget);
  }

  @override
  void initState() {
    // TODO: implement initState
    widget.data.addListener(update);
    super.initState();
  }
  @override
  void dispose() {
    // TODO: implement dispose
    widget.data.removeListener(update);
    super.dispose();
  }

当 widget.data 数据变更时会调用ChangeNotifierProviderState1的 update 方法，会重新调用ChangeNotifierProviderElement的 rebuild 方法，最终调用到InheritedProviderElementd的 updateChild 方法上，堆栈信息如下图

updateChild 是 父类element的方法，它的核心代码如下：

/// Update the given child with the given new configuration.
///
/// This method is the core of the widgets system. It is called each time we
/// are to add, update, or remove a child based on an updated configuration.
///
/// The `newSlot` argument specifies the new value for this element's [slot].
///
/// If the `child` is null, and the `newWidget` is not null, then we have a new
/// child for which we need to create an [Element], configured with `newWidget`.
///
/// If the `newWidget` is null, and the `child` is not null, then we need to
/// remove it because it no longer has a configuration.
///
/// If neither are null, then we need to update the `child`'s configuration to
/// be the new configuration given by `newWidget`. If `newWidget` can be given
/// to the existing child (as determined by [Widget.canUpdate]), then it is so
/// given. Otherwise, the old child needs to be disposed and a new child
/// created for the new configuration.
///
/// If both are null, then we don't have a child and won't have a child, so we
/// do nothing.
///
/// The [updateChild] method returns the new child, if it had to create one,
/// or the child that was passed in, if it just had to update the child, or
/// null, if it removed the child and did not replace it.
///
/// The following table summarizes the above:
///
/// |                     | **newWidget == null**  | **newWidget != null**   |
/// | :-----------------: | :--------------------- | :---------------------- |
/// |  **child == null**  |  Returns null.         |  Returns new [Element]. |
/// |  **child != null**  |  Old child is removed, returns null. | Old child updated if possible, returns child or new [Element]. |
///
/// The `newSlot` argument is used only if `newWidget` is not null. If `child`
/// is null (or if the old child cannot be updated), then the `newSlot` is
/// given to the new [Element] that is created for the child, via
/// [inflateWidget]. If `child` is not null (and the old child _can_ be
/// updated), then the `newSlot` is given to [updateSlotForChild] to update
/// its slot, in case it has moved around since it was last built.
///
/// See the [RenderObjectElement] documentation for more information on slots.

Element? updateChild(Element? child, Widget? newWidget, Object? newSlot) {
if (child != null) {
  bool hasSameSuperclass = true;

  assert(() {
    final int oldElementClass = Element._debugConcreteSubtype(child);
    final int newWidgetClass = Widget._debugConcreteSubtype(newWidget);
    hasSameSuperclass = oldElementClass == newWidgetClass;
    return true;
  }());
  if (hasSameSuperclass && child.widget == newWidget) {
  //注释 1：如果 child 的 widget 和 newWidget 一样，则不刷新 child
    if (child.slot != newSlot) {
      updateSlotForChild(child, newSlot);
    }
    newChild = child;
  } else if (hasSameSuperclass && Widget.canUpdate(child.widget, newWidget)) {
   ...
   //注释 2：更新child 关联的 widget
    child.update(newWidget);
    ...
    newChild = child;
  } else {
    deactivateChild(child);
    assert(child._parent == null);
    //注释 3：  基于 newWidget创建新的 element
    newChild = inflateWidget(newWidget, newSlot);
  }
} else {
//注释 4：  基于 newWidget创建新的 element
  newChild = inflateWidget(newWidget, newSlot);
}
}

从上述注释1的地方可以看出，只要不刷新ChangeNotifierProvider1的父 Widget，不管如何刷新ChangeNotifierProviderState1内部的时候，他 对应Widget的child 没有变过（从构造函数传入的，也是这段代码里的newWidget），所以他的 child 不会刷新，所以 Row 控件不会刷新，他的子控件其他控件也不会刷新。

问题 2，既然 Row 不会刷新，那为什么总数控件可以刷新？

由于总数控件使用dependOnInheritedWidgetOfExactType获取ChangeNotifierProvider1，并且获取它存储的 data， 从 2.2 的关于 dependencies 的介绍的流程图里可以看出，当InheritedWidget 更新的时候，最终会调用 child 的markNeedsBuild方法，该方法会把当前 element 添加到 buildOwner 的_dirtyElements中，下一次刷新的时候会刷新这个控件。堆栈信息如下： 问题 3，为什么添加按钮没有刷新？ 既然都获取了ChangeNotifierProvider1，为什么添加按钮没有刷新呢，还是要回到2.2 部分 关于didChangeDependencies方法的介绍中，由于getElementForInheritedWidgetOfExactType方法不会注册InheritedElement 和当前 Element 的依赖关系，导致InheritedElement在notifyClients方法中没有调用添加按钮对应的 Element 的didChangeDependencies方法，该方法中的markNeedsBuild也没有调用，最终没有把当前 element 添加到 buildOwner 的_dirtyElements中，同时由于问题 1 中的提到的缓存机制，所以该控件没有刷新。

2.3.3 element 缓存

上文的 updateChild 方法中，有两个方法，update 和 inflateWidget，他们的区别如下：

1. update()：

   • 当调用update()方法时，Flutter会检查当前Element的类型是否与新widget的类型匹配。
   • 如果类型匹配，则Flutter会尝试重用现有的Element实例，以避免不必要的重建。
   • 通过重用现有Element实例，可以保留该元素的状态信息和相关上下文，以提高性能和效率。
   • 这种缓存机制确保了在更新相同类型的widget时，不会出现不及时的情况。

2. inflateWidget()：

   • 当调用inflateWidget()方法时，Flutter会创建一个新的Element实例，并将其添加到Element树中。
   • 新创建的Element实例不会重用现有的元素，而是完全新建一个。
   • 这意味着即使在更新相同类型的widget时调用inflateWidget()方法，也会创建一个新的Element实例，并在树中插入它，而不是重用之前的Element。
   • 这可能会导致一些额外的开销，尤其是在重复调用inflateWidget()时。

因此，在更新同一类型的widget时，使用update()方法，以确保更有效地利用缓存机制，避免不必要的重建。只有当需要在树中插入一个新的widget时，才使用inflateWidget()方法。