在flutter开发中状态管理框架Provider应该大家都接触过,这里我就结合我在使用过程中,出现的疑惑,以及一步一步找到答案的过程,来详细的介绍一下Provider框架实现的原理
大家应该都知道Provider是基于InheritedWidget实现的,所以我最开始的思路完全是按照InheritedWidget来理解这个框架的,如果对InheritedWidget不是很了解,可以看看之前的文章InheritedWidget
Provider中value是一个ChangeNotifier,然后在需要刷新的时候调用notifyListeners来刷新,结合InheritedWidget,我的思路是ChangeNotifier监听InheritedWidget的父Element,notifyListeners来调用父Element的markNeedsBuild,实现数据刷新
但是通过源码发现,Provider内部并没有给InheritedWidget包裹Widget,而是直接监听的InheritedWidget(InheritedElement),调用的也是InheritedElement的markNeedsBuild
class ChangeNotifierProvider<T extends ChangeNotifier?>
extends ListenableProvider<T>
在ListenableProvider的构造函数中,有一个_startListening,这个方法中实现了回调监听,一旦ChangeNotifier执行了notifyListeners,_startListening就会被调用
class ListenableProvider<T extends Listenable?> extends InheritedProvider<T> {
/// Creates a [Listenable] using [create] and subscribes to it.
///
/// [dispose] can optionally passed to free resources
/// when [ListenableProvider] is removed from the tree.
///
/// [create] must not be `null`.
ListenableProvider({
Key? key,
required Create<T> create,
Dispose<T>? dispose,
bool? lazy,
TransitionBuilder? builder,
Widget? child,
}) : super(
key: key,
startListening: _startListening,
create: create,
dispose: dispose,
lazy: lazy,
builder: builder,
child: child,
);
static VoidCallback _startListening(
InheritedContext e,
Listenable? value,
) {
value?.addListener(e.markNeedsNotifyDependents);
return () => value?.removeListener(e.markNeedsNotifyDependents);
}
而markNeedsNotifyDependents本质就是调用了markNeedsBuild
@override
void markNeedsNotifyDependents() {
if (!_isNotifyDependentsEnabled) {
return;
}
markNeedsBuild();
_shouldNotifyDependents = true;
}
因为最"正宗"的使用InheritedWidget,是通过重新创建一个InheritedWidget,并且调用上层的setState这个方法去刷新,会调用InheritedWidget(InheritedElement)的update方法,进而调用notifyClients,这个方法会将使用InheritedWidget的element设置成_dirty,从而实现引用的组件刷新,这里没有父组件的刷新,因此也不会执行update方法,那Provider是如何跳过update而执行notifyClients的呢,透过源码我们发现performRebuild -> build -> notifyClients,这样一条调用路线,结合上面说的ChangeNotifier用来将ProviderInheritedElement.markNeedsBuild 置为 true,这样会导致ProviderInheritedElement rebuild,进而调用performRebuild,最终实现notifyClients的调用
void performRebuild() {
Widget? built;
try {
assert(() {
_debugDoingBuild = true;
return true;
}());
built = build();
assert(() {
_debugDoingBuild = false;
return true;
}());
debugWidgetBuilderValue(widget, built);
} catch (e, stack) {
_debugDoingBuild = false;
built = ErrorWidget.builder(
_reportException(
ErrorDescription('building $this'),
e,
stack,
informationCollector: () => <DiagnosticsNode>[
if (kDebugMode)
DiagnosticsDebugCreator(DebugCreator(this)),
],
),
);
} finally {
// We delay marking the element as clean until after calling build() so
// that attempts to markNeedsBuild() during build() will be ignored.
super.performRebuild(); // clears the "dirty" flag
}
try {
_child = updateChild(_child, built, slot);
assert(_child != null);
} catch (e, stack) {
built = ErrorWidget.builder(
_reportException(
ErrorDescription('building $this'),
e,
stack,
informationCollector: () => <DiagnosticsNode>[
if (kDebugMode)
DiagnosticsDebugCreator(DebugCreator(this)),
],
),
);
_child = updateChild(null, built, slot);
}
}
Provider 重写了build方法,这里边执行了notifyClients,去将监听的element强制刷新的
@override
Widget build() {
if (widget.owner._lazy == false) {
value; // this will force the value to be computed.
}
_delegateState.build(
isBuildFromExternalSources: _isBuildFromExternalSources,
);
_isBuildFromExternalSources = false;
if (_shouldNotifyDependents) {
_shouldNotifyDependents = false;
notifyClients(widget);
}
return super.build();
}
到这里其实大概的原理就解释通了,
- ChangeNotifier负责数据以及刷新InheritedElement
- InheritedElement负责向下传递数据以及更新使用数据的Element,但是是对InheritedElement做了小小的改动的
补充:
其实这样做还有一个好处,就是本身InheritedWidget重新创建逻辑会导致下面所有的Widget重构,但是Provider直接通过_dirty来刷新,只是重新调用了InheritedElement 的 build,而大多数情况下,build中直接使用的是InheritedWidget的child属性,我们知道对于相同的child是不会再次调用child的build的,所以就避免了这一重构灾难(虽然创建widget tree 不是很消耗资源和性能),可以尽量做到那里需要刷新就刷新那里,也算是一个亮点吧
