在Flutter组件构建浅析一文中介绍Widget组件时，曾将Widget分为三类，提到InheritedWidget是全局状态管理的重要组件，它在感知数据变动后会通知依赖的组件更新
- StatelessWidget、StatefullWidget 可以组合Widget，形成Widget树
- ProxyWidget 其子类InheritedWidget是全局状态管理的重要组件
- RenderObjectWidget 可以创建renderObject对象用于布局绘制
但在实际开发过程中InheritedWidget是很少直接使用的，一般我们会直接使用Provider、Riverpod这样的包，它们的底层都是基于InheritedWidget的，所以了解一下InheritedWidget有助于理解其工作原理。
Demo
首先通过一个demo看下如何使用InheritedWidget，这是一个抽象类，继承之后需要复写updateShouldNotify即可，除此之外
- count是持用共享的数据
- read、watch为工具方法，方便全局调用
- BuildContext是一个接口，Element实现了这个接口，StalessWidget和StatefulWidget的build方法的传参都是当前Element，使用接口而不是实现类具有更大的灵活性，看到BuildContext可以将他们看作Element
class ShareCountWidget extends InheritedWidget {
const ShareCountWidget(
{Key? key, required Widget child, required this.count})
: super(key: key, child: child);
final int count;
static int? watch(BuildContext context) {
return context
.dependOnInheritedWidgetOfExactType<ShareCountWidget>()
?.count;
}
static int? read<T>(BuildContext context) {
ShareCountWidget? widget = context
.getElementForInheritedWidgetOfExactType<ShareCountWidget>()
?.widget as ShareCountWidget;
return widget.count;
}
@override
bool updateShouldNotify(ShareCountWidget oldWidget) {
debugPrint("old=${oldWidget.count} vs new=${count}");
return oldWidget.count!=count;
}
}
InheritedWidget依赖rebuild感知数据变化，所以放在StatefulWidget中，ShareCountWidget的child为了避免重建，传参要来自外部，否则setState就重建了，不是我们想要的效果，后面分析会说到。现在每点击一次，有以下变化
- count自增
- 打印_ProviderWidgetState build
- GestureDetector、ShareCountWidget会new一个新的
不变的是
- widget.child参数
class ProviderWidget extends StatefulWidget {
const ProviderWidget({Key? key, required this.child})
: super(key: key);
final Widget child;
@override
State<ProviderWidget> createState() => _ProviderWidgetState();
}
class _ProviderWidgetState extends State<ProviderWidget> {
int count=0;
@override
Widget build(BuildContext context) {
debugPrint("_ProviderWidgetState build");
return GestureDetector(
child: ShareCountWidget(count: count, child: widget.child),
onTap: () => setState(() {count++;}),
);
}
}
最后整合到根页面上，每次点击屏幕，
- 第一个Text只显示初始化的0，既没有打印“build Text 1”，数字也不会变化，
- 第二个Text数字会加一，同时打印“build Text 2”
它们的不同在于一个用的read方法而另一个用的watch方法，有什么区别，这里为什么要用Builder包装Text，为什么用innerContext而不是上面的context
class Start extends StatelessWidget {
@override
Widget build(BuildContext context) {
return ProviderWidget(
child: MaterialApp(
home: Scaffold(
body: Center(
child: Row(
mainAxisAlignment: MainAxisAlignment.center,
children: [
Builder(builder: (BuildContext innerContext) {
debugPrint("build Text 1");
return Text(ShareCountWidget.read(innerContext)?.toString() ?? "");
}),
const SizedBox(width: 8),
Builder(builder: (BuildContext innerContext) {
debugPrint("build Text 2");
return Text(ShareCountWidget.watch(innerContext)?.toString() ?? "");
}),
],
),
),
),
));
}
}
InheritedWidget工作原理
Widget的设计都是轻量级的，InheritedWidget也是，其对应的InheritedElement才是重点，先看在Flutter组件构建浅析中提到的_updateInheritance方法，Element中的此方法就是直接指向父类中_inheritedWidgets，一般都是空
Element
Map<Type, InheritedElement>? _inheritedWidgets;
void mount(Element? parent, Object? newSlot) {
...
// inheritWidget相关
_updateInheritance();
...
}
void _updateInheritance() {
_inheritedWidgets = _parent?._inheritedWidgets;
}
在Element的子类中，InheritedElement对其进行了复写,内容也很明了：如果父类的不为空先复制过来，为空就初始化，再把当前InheritedElement和其关联的Widget以键值对的形式存在map中，随着Element树的构建，后面的子Element都指向这个map(单InheritedWidget)，这是状态能在全局共享的基础，所以要想数据服务范围广，InheritedWidget就要往树顶靠。
@override
void _updateInheritance() {
final Map<Type, InheritedElement>? incomingWidgets = _parent?._inheritedWidgets;
if (incomingWidgets != null) {
_inheritedWidgets = HashMap<Type, InheritedElement>.of(incomingWidgets);
} else {
_inheritedWidgets = HashMap<Type, InheritedElement>();
}
_inheritedWidgets![widget.runtimeType] = this;
}
那这个map是在哪使用的呢，搜索_inheritedWidgets会发现当前使用的两个方法就是我们前面封装的工具方法，两个方法都从map中获取InheritedElement，由于子Element都持用这个map，所以只要在InheritedElement之下，无论什么位置都能直接调用，
@override
T? dependOnInheritedWidgetOfExactType<T extends InheritedWidget>({Object? aspect}) {
final InheritedElement? ancestor = _inheritedWidgets == null ? null : _inheritedWidgets![T];
if (ancestor != null) {
// 比下面方法多这个调用
return dependOnInheritedElement(ancestor, aspect: aspect) as T;
}
_hadUnsatisfiedDependencies = true;
return null;
}
@override
InheritedElement? getElementForInheritedWidgetOfExactType<T extends InheritedWidget>() {
final InheritedElement? ancestor = _inheritedWidgets == null ? null : _inheritedWidgets![T];
return ancestor;
}
前面的demo为什么不用context，因为它在InheritedElement之上，为什么用Builder，其实就是为了使用innerContext参数，它在InheritedElement之下
class Start extends StatelessWidget {
@override
Widget build(BuildContext context) {
return ProviderWidget(
...
Builder(builder: (BuildContext innerContext) {
debugPrint("build Text 1");
return Text(ShareCountWidget.read(innerContext)?.toString() ?? "");
}),
...
}
}
上面两个方法的重要不同在于第一个多了dependOnInheritedElement方法调用，而这个调用很是关键，干了两件事
- 从调用者角度看，我这个Element依赖了谁， 通过 _dependencies!.add(ancestor)记录下这个InheritedElement
- 从InheritedElement角度看，谁依赖了我，通过ancestor.updateDependencies(this, aspect)记录下来这个Element，后面如有更新要通知它，这就是为什么demo里使用watch方法的Text有刷新
@override
InheritedWidget dependOnInheritedElement(InheritedElement ancestor, { Object? aspect }) {
_dependencies ??= HashSet<InheritedElement>();
_dependencies!.add(ancestor);
ancestor.updateDependencies(this, aspect);
return ancestor.widget as InheritedWidget;
}
InheritedElement
void updateDependencies(Element dependent, Object? aspect) {
setDependencies(dependent, null);
}
final Map<Element, Object?> _dependents = HashMap<Element, Object?>();
@protected
void setDependencies(Element dependent, Object? value) {
_dependents[dependent] = value;
}
那它又是如何通知的呢，下面这张图来自StatefulWidget，具体的构建流程不再重述了，图的右下角涉及InheritedElement
当setState触发rebuild，看InheritedElement的update是怎么更新的，update方法由InheritedElement的父类ProxyElement复写，其先调用updated方法，不要和update混淆了，这个updated方法被InheritedElement复写了，复写的目的就是先问问InheritedWidget这个更新要不要通知，比如数据都没变化就不要通知了
ProxyElement
@override
void update(ProxyWidget newWidget) {
final ProxyWidget oldWidget = widget as ProxyWidget;
super.update(newWidget);
// InheritedElement有复写
updated(oldWidget);
_dirty = true;
rebuild();
}
InheritedElement
@override
void updated(InheritedWidget oldWidget) {
if ((widget as InheritedWidget).updateShouldNotify(oldWidget)) {
super.updated(oldWidget);
}
}
如果InheritedWidget子类复写的这个updateShouldNotify方法判断要通知，才会调用了父类的updated方法，比如我们的demo就比较了新旧count不同时才通知。
@override
bool updateShouldNotify(ShareCountWidget oldWidget) {
debugPrint("old=${oldWidget.count} vs new=${count}");
return oldWidget.count!=count;
}
updated里面就是通知更新的实现了，前面说过_dependents保存了依赖这个InheritedElement的Elements，现在依次调用它们的didChangeDependencies就会引起Element重建了
@protected
void updated(covariant ProxyWidget oldWidget) {
// 这个方法又是子类实现的
notifyClients(oldWidget);
}
@override
void notifyClients(InheritedWidget oldWidget) {
for (final Element dependent in _dependents.keys) {
...
notifyDependent(oldWidget, dependent);
}
}
void notifyDependent(covariant InheritedWidget oldWidget, Element dependent) {
dependent.didChangeDependencies();
}
void didChangeDependencies() {
// 重建
markNeedsBuild();
}
StatefulElement对didChangeDependencies方法有复写，我们在StatefulWidget中关于初始化的第三点提到，InheritedElement会涉及_didChangeDependencies这个值就在这里，那么state.didChangeDependencies()的调用时机也就来源于此
StatefulElement
@override
void didChangeDependencies() {
super.didChangeDependencies();
_didChangeDependencies = true;
}
@override
void performRebuild() {
if (_didChangeDependencies) {
state.didChangeDependencies();
_didChangeDependencies = false;
}
super.performRebuild();
}
当依赖的Elements被标记需要重建后，下一帧会执行rebuild,但此后InheritedElement的rebuild是会向下传递的，如果子节点update时也依次rebuild了，上面的通知也就没什么意义了，所以在上面流程图中，我们希望子节点的update走下面的红色路线，维持现状，结束向下build流程，只有被通知的Elements重建从而实现局部刷新。
这就是为什么demo中ShareCountWidget直接接受外部的传参作为子节点，只要这个外部参数不变就实现了上面的红色路线。
参考 跨组件状态共享
