回顾

Flutter State Management状态管理全面分析
上期我们对Flutter的状态管理有了全局的认知，也知道了如何分辨是非好坏，不知道也没关系哦，我们接下来还会更加详细的分析，通过阅读Provider源码，来看看框架到底如何组织的，是如何给我们提供便利的。

本期内容

通过官方我们已经知道其实Provider就是对InheritedWidget的包装，只是让InheritedWidget用起来更加简单且高可复用。我们也知道它有一些缺点，如

• 容易造成不必要的刷新
• 不支持跨页面(route)的状态，意思是跨树，如果不在一个树中，我们无法获取
• 数据是不可变的，必须结合StatefulWidget、ChangeNotifier或者Steam使用

我特别想弄明白，这些缺点在Provider的设计中是如何规避的，还有一个是Stream不会主动的close掉流的通道，不得不结合StatefulWidget使用，而Provider提供了dispose回调，你可以在该函数中主动关闭，好厉害，如何做到的呢？带着这些疑问，我们去寻找答案

如何使用

我们先来使用它，然后在根据用例分析源码，找到我们想要的答案，先看一个简单的例子

step 1

第一步定义一个ChangeNotifier，来负责数据的变化通知

class Counter with ChangeNotifier {int _count = 0;int get count => _count;void increment() {_count++;notifyListeners();}}

step 2

第二步，用ChangeNotifierProvider来订阅Counter，不难猜出，ChangeNotifierProvider肯定是InheritedWidget的包装类，负责将Counter的状态共享给子Widget，我这里将ChangeNotifierProvider放到了Main函数中，并在整个Widget树的顶端，当然这里是个简单的例子，我这么写问题不大，但你要考虑，如果是特别局部的状态，请将ChangeNotifierProvider放到局部的地方而不是全局，希望你能明白我的用意

void main() {runApp(/// Providers are above [MyApp] instead of inside it, so that tests/// can use [MyApp] while mocking the providersMultiProvider(providers: [ChangeNotifierProvider(create: (_) => Counter()),],child: MyApp(),),);
}

step 3

第三步，接收数据通过Consumer<Counter>，Consumer是个消费者，它负责消费ChangeNotifierProvider生产的数据

class MyApp extends StatelessWidget {@overrideWidget build(BuildContext context) {return const MaterialApp(home: MyHomePage(),);}
}class MyHomePage extends StatelessWidget {const MyHomePage({Key key}) : super(key: key);@overrideWidget build(BuildContext context) {print('MyHomePage build');return Scaffold(appBar: AppBar(title: const Text('Example'),),body: Center(child: Column(mainAxisSize: MainAxisSize.min,mainAxisAlignment: MainAxisAlignment.center,children: <Widget>[const Text('You have pushed the button this many times:'),/// Extracted as a separate widget for performance optimization./// As a separate widget, it will rebuild independently from [MyHomePage].////// This is totally optional (and rarely needed)./// Similarly, we could also use [Consumer] or [Selector].Consumer<Counter>(builder: (BuildContext context, Counter value, Widget child) {return Text('${value.count}');},),OtherWidget(),const OtherWidget2()],),),floatingActionButton: FloatingActionButton(/// Calls `context.read` instead of `context.watch` so that it does not rebuild/// when [Counter] changes.onPressed: () => context.read<Counter>().increment(),tooltip: 'Increment',child: const Icon(Icons.add),),);}
}

通过这个例子，可以判断出Provider封装的足够易用，而且Counter作为Model层使用的with ChangeNotifier 而不是extends ，所以说侵入性也比较低，感觉还不错，那么InheritedWidget的缺点它规避了吗？

1. 容易造成不必要的刷新（解决了吗？）

我们多加两个子WIdget进去，排在Consumer的后面，OtherWidget什么都不干，不去订阅Counter，OtherWidget2通过context.watch<Counter>().count函数监听而不是Consumer，来看下效果一样不，然后在build函数中都加入了print

class OtherWidget extends StatelessWidget {const OtherWidget({Key key}) : super(key: key);@overrideWidget build(BuildContext context) {print('OtherWidget build');
//    Provider.of<Counter>(context);return Text(/// Calls `context.watch` to make [MyHomePage] rebuild when [Counter] changes.'OtherWidget',style: Theme.of(context).textTheme.headline4);}
}class OtherWidget2 extends StatelessWidget {const OtherWidget2({Key key}) : super(key: key);@overrideWidget build(BuildContext context) {print('OtherWidget2 build');return Text(/// Calls `context.watch` to make [MyHomePage] rebuild when [Counter] changes.'${context.watch<Counter>().count}',style: Theme.of(context).textTheme.headline4);}
}

项目运行看下效果，跑起来是这样的
print日志
点击刷新后
分析结论如下：

• Consumer、context.watch都可以监听Counter变化
• Consumer只会刷新自己
• context.watch所在子widget不管是否是const都被重建后刷新数据
• OtherWidget并没有被重建，因为它没有订阅Counter

局部刷新确实实现了但要通过Consumer，第二个问题不支持跨页面(route)的状态，这个可以确定的说不支持，第三个问题数据是不可变的（只读），经过这个例子可以分辨出数据确实是可变的对吧，那么数据是如何变化的呢？留个悬念，下面分析源码中来看本质。

当然要想更完整的理解ChangeNotifier、ChangeNotifierProvider、Consumer的关系
请看图
设计模式真是无处不在哈，ChangeNotifier与ChangeNotifierProvider实现了观察者模式，ChangeNotifierProvider与Consumer又实现了生产者消费者模式，这里不具体聊这俩个模式，如果还不了解，请你自行搜索学习哦。下面直接源码分析

源码分析

ChangeNotifier

在包package:meta/meta.dart下，是flutter sdk的代码，并不属于Provider框架的一部分哦，通过下方代码可以看出，这是一个标准的观察者模型，而真正的监听者就是typedef VoidCallback = void Function(); 是dart.ui包下定义的一个函数，没人任何返回参数的函数。ChangerNotifier实现自抽象类Listenable，通过源码的注释我们看到Listenable是一个专门负责维护监听列表的一个抽象类。

ChangeNotifierProvider

class ChangeNotifierProvider<T extends ChangeNotifier>extends ListenableProvider<T> {static void _dispose(BuildContext context, ChangeNotifier notifier) {notifier?.dispose();}/// 使用`create`创建一个[ChangeNotifier]/// 当ChangeNotifierProvider从树中被移除时，自动取消订阅通过/// notifier?.dispose();ChangeNotifierProvider({Key key,@required Create<T> create,bool lazy,TransitionBuilder builder,Widget child,}) : super(key: key,create: create,dispose: _dispose,lazy: lazy,builder: builder,child: child,);/// 生成一个已存在ChangeNotifier的ProviderChangeNotifierProvider.value({Key key,@required T value,TransitionBuilder builder,Widget child,}) : super.value(key: key,builder: builder,value: value,child: child,);
}

分析下构造

• Create<T> create

是个通用函数typedef Create<T> = T Function(BuildContext context)用于创建T类，这里负责创建ChangeNotifier

• bool lazy

是否懒加载

• TransitionBuilder builder

当builder存在时将不会用child做为子Widget，追踪到源码实现可以看到如下图

• Widget child

builder不存在时就用child

继承自ListenableProvider<T>，来继续分析它的源码

class ListenableProvider<T extends Listenable> extends InheritedProvider<T> {///  使用 [create] 创建一个 [Listenable] 订阅它/// [dispose] 可以选择性的释放资源当 [ListenableProvider] 被移除树的时候/// [create] 不能为空ListenableProvider({Key key,@required Create<T> create,Dispose<T> dispose,bool lazy,TransitionBuilder builder,Widget child,})  : assert(create != null),super(key: key,startListening: _startListening,create: create,dispose: dispose,debugCheckInvalidValueType: kReleaseMode? null: (value) {if (value is ChangeNotifier) {// ignore: invalid_use_of_protected_member...}},lazy: lazy,builder: builder,child: child,);/// 生成已存在 [Listenable] 的ProviderListenableProvider.value({Key key,@required T value,UpdateShouldNotify<T> updateShouldNotify,TransitionBuilder builder,Widget child,}) : super.value(key: key,builder: builder,value: value,updateShouldNotify: updateShouldNotify,startListening: _startListening,child: child,);static VoidCallback _startListening(InheritedContext<Listenable> e,Listenable value,) {value?.addListener(e.markNeedsNotifyDependents);return () => value?.removeListener(e.markNeedsNotifyDependents);}
}

• Listenable 上面已经分析，它是负责管理观察者列表的抽象
• 它比子类ChangeNotifierProvider多了一个构造参数dispose，这个函数是typedef Dispose<T> = void Function(BuildContext context, T value); 是个回调，应该是当页面被销毁时触发（等再深入了源码才能认证，目前只是猜测，我们继续看）

又继承自InheritedProvider<T> ，别放弃，来跟我一起往下看

class InheritedProvider<T> extends SingleChildStatelessWidget {/// 创建数据value并共享给子Widget/// 当 [InheritedProvider] 从树中被释放时，将自动释放数据valueInheritedProvider({Key key,Create<T> create,T update(BuildContext context, T value),UpdateShouldNotify<T> updateShouldNotify,void Function(T value) debugCheckInvalidValueType,StartListening<T> startListening,Dispose<T> dispose,TransitionBuilder builder,bool lazy,Widget child,})  : _lazy = lazy,_builder = builder,_delegate = _CreateInheritedProvider(create: create,update: update,updateShouldNotify: updateShouldNotify,debugCheckInvalidValueType: debugCheckInvalidValueType,startListening: startListening,dispose: dispose,),super(key: key, child: child);/// 暴漏给子孙一个已存在的数据valueInheritedProvider.value({Key key,@required T value,UpdateShouldNotify<T> updateShouldNotify,StartListening<T> startListening,bool lazy,TransitionBuilder builder,Widget child,})  : _lazy = lazy,_builder = builder,_delegate = _ValueInheritedProvider(value: value,updateShouldNotify: updateShouldNotify,startListening: startListening,),super(key: key, child: child);InheritedProvider._constructor({Key key,_Delegate<T> delegate,bool lazy,TransitionBuilder builder,Widget child,})  : _lazy = lazy,_builder = builder,_delegate = delegate,super(key: key, child: child);final _Delegate<T> _delegate;final bool _lazy;final TransitionBuilder _builder;@overridevoid debugFillProperties(DiagnosticPropertiesBuilder properties) {super.debugFillProperties(properties);_delegate.debugFillProperties(properties);}@override_InheritedProviderElement<T> createElement() {return _InheritedProviderElement<T>(this);}@overrideWidget buildWithChild(BuildContext context, Widget child) {assert(_builder != null || child != null,'$runtimeType used outside of MultiProvider must specify a child',);return _InheritedProviderScope<T>(owner: this,child: _builder != null? Builder(builder: (context) => _builder(context, child),): child,);}
}

构造中多出来的参数

• T update(BuildContext context, T value) 该函数返回数据变更值value，具体实现在_CreateInheritedProvider类中，说白了InheritedProvider<T>是个无状态组件对吗？那么它要变更状态肯定要依赖于别人，而它创建出一个_CreateInheritedProvider类，_CreateInheritedProvider是_Delegate的实现类，_Delegate就是一个状态的代理类，来看下_Delegate具体实现

@immutable
abstract class _Delegate<T> {_DelegateState<T, _Delegate<T>> createState();void debugFillProperties(DiagnosticPropertiesBuilder properties) {}
}abstract class _DelegateState<T, D extends _Delegate<T>> {_InheritedProviderScopeElement<T> element;T get value;D get delegate => element.widget.owner._delegate as D;bool get hasValue;bool debugSetInheritedLock(bool value) {return element._debugSetInheritedLock(value);}bool willUpdateDelegate(D newDelegate) => false;void dispose() {}void debugFillProperties(DiagnosticPropertiesBuilder properties) {}void build(bool isBuildFromExternalSources) {}
}

这是用到了委托模式，这里就有点类似StatefulWidget和State的关系，同样的_DelegateState提供了类似生命周期的函数，如willUpdateDelegate更新新的委托，dispose注销等

• UpdateShouldNotify<T> updateShouldNotify,
  void Function(T value) debugCheckInvalidValueType,
  StartListening<T> startListening,
  Dispose<T> dispose, 这些函数全部交给了委托类
• 最关键的实现来了，到目前位置还没看到InheritedWidget的逻辑对吧，它来了Widget buildWithChild(BuildContext context, Widget child)，我们传入的Widget就被叫_InheritedProviderScope的类给包裹了，看下源码

class _InheritedProviderScope<T> extends InheritedWidget {_InheritedProviderScope({this.owner,@required Widget child,}) : super(child: child);final InheritedProvider<T> owner;@overridebool updateShouldNotify(InheritedWidget oldWidget) {return false;}@override_InheritedProviderScopeElement<T> createElement() {return _InheritedProviderScopeElement<T>(this);}
}

至此你有没有发现一个特点，所有的函数都被_Delegate带走了，剩下的只有Widget交给了_InheritedProviderScope，这里设计的也很好，毕竟InheritedWidget其实也就只能做到数据共享，跟函数并没有什么关系对吧。唯一有关系的地方，我猜测就是在InheritedWidget提供的Widget中调用

一个细节 owner: this 在 buildWithChild函数中，将InheritedProvider本身传递给InheritedWidget，应该是为了方便调用它的_Delegate委托类，肯定是用来回调各种函数。

... 快一点了，睡了，明天再更

继续分享，_InheritedProviderScope唯一特殊的地方，我们发现它自己创建了一个Element实现通过覆盖createElement函数，返回_InheritedProviderScopeElement实例，flutter三板斧 Widget、Element、RenderObject，该框架自己实现一层Element，我们都知道Widget是配置文件只有build和rebuild以及remove from the tree，而Element作为一层虚拟Dom，主要负责优化，优化页面刷新的逻辑，那我们来详细的分析一下_InheritedProviderScopeElement，看它都做了什么？

/// 继承自InheritedElement，因为InheritedWidget对应的Element就是它
/// 实现 InheritedContext，InheritedContext继承自BuildContext，多了个T范型
class _InheritedProviderScopeElement<T> extends InheritedElementimplements InheritedContext<T> {/// 构造函数，将Element对应的widget传进来_InheritedProviderScopeElement(_InheritedProviderScope<T> widget): super(widget);
/// 是否需要通知依赖的Element变更bool _shouldNotifyDependents = false;
/// 是否允许通知变更bool _isNotifyDependentsEnabled = true;
/// 第一次构建bool _firstBuild = true;
/// 是否更新newWidget的Delegate委托bool _updatedShouldNotify = false;
/// 这个变量就是控制的数据变更，在Widget变更和Element依赖变更的时候都会被设置为truebool _isBuildFromExternalSources = false;
/// 委托类的状态（我们猜测对了， owner: this 就是为了拿到上层的委托类）_DelegateState<T, _Delegate<T>> _delegateState;@override_InheritedProviderScope<T> get widget =>super.widget as _InheritedProviderScope<T>;@overridevoid updateDependencies(Element dependent, Object aspect) {final dependencies = getDependencies(dependent);// once subscribed to everything once, it always stays subscribed to everythingif (dependencies != null && dependencies is! _Dependency<T>) {return;}if (aspect is _SelectorAspect<T>) {final selectorDependency =(dependencies ?? _Dependency<T>()) as _Dependency<T>;if (selectorDependency.shouldClearSelectors) {selectorDependency.shouldClearSelectors = false;selectorDependency.selectors.clear();}if (selectorDependency.shouldClearMutationScheduled == false) {selectorDependency.shouldClearMutationScheduled = true;SchedulerBinding.instance.addPostFrameCallback((_) {selectorDependency..shouldClearMutationScheduled = false..shouldClearSelectors = true;});}selectorDependency.selectors.add(aspect);setDependencies(dependent, selectorDependency);} else {// subscribes to everythingsetDependencies(dependent, const Object());}}@overridevoid notifyDependent(InheritedWidget oldWidget, Element dependent) {final dependencies = getDependencies(dependent);var shouldNotify = false;if (dependencies != null) {if (dependencies is _Dependency<T>) {for (final updateShouldNotify in dependencies.selectors) {try {assert(() {_debugIsSelecting = true;return true;}());shouldNotify = updateShouldNotify(value);} finally {assert(() {_debugIsSelecting = false;return true;}());}if (shouldNotify) {break;}}} else {shouldNotify = true;}}if (shouldNotify) {dependent.didChangeDependencies();}}@overridevoid performRebuild() {if (_firstBuild) {_firstBuild = false;_delegateState = widget.owner._delegate.createState()..element = this;}super.performRebuild();}@overridevoid update(_InheritedProviderScope<T> newWidget) {_isBuildFromExternalSources = true;_updatedShouldNotify =_delegateState.willUpdateDelegate(newWidget.owner._delegate);super.update(newWidget);_updatedShouldNotify = false;}@overridevoid updated(InheritedWidget oldWidget) {super.updated(oldWidget);if (_updatedShouldNotify) {notifyClients(oldWidget);}}@overridevoid didChangeDependencies() {_isBuildFromExternalSources = true;super.didChangeDependencies();}@overrideWidget build() {if (widget.owner._lazy == false) {value; // this will force the value to be computed.}_delegateState.build(_isBuildFromExternalSources);_isBuildFromExternalSources = false;if (_shouldNotifyDependents) {_shouldNotifyDependents = false;notifyClients(widget);}return super.build();}@overridevoid unmount() {_delegateState.dispose();super.unmount();}@overridebool get hasValue => _delegateState.hasValue;@overridevoid markNeedsNotifyDependents() {if (!_isNotifyDependentsEnabled) return;markNeedsBuild();_shouldNotifyDependents = true;}@overrideT get value => _delegateState.value;@overrideInheritedWidget dependOnInheritedElement(InheritedElement ancestor, {Object aspect,}) {return super.dependOnInheritedElement(ancestor, aspect: aspect);}
}

• void update(_InheritedProviderScope<T> newWidget) 让页面重新build的是在这里，因为InheritedElement 继承自ProxyElement，而ProxyElement的update函数调用了两个函数updated（已更新完成），rebuild函数触发重新build逻辑，下面为跟踪到的代码

abstract class ProxyElement extends ComponentElement {@overridevoid update(ProxyWidget newWidget) {final ProxyWidget oldWidget = widget;assert(widget != null);assert(widget != newWidget);super.update(newWidget);assert(widget == newWidget);updated(oldWidget);_dirty = true;rebuild();}
}

• performRebuild() 是在update触发真正调用rebuild之后被调用
• updateDependencies、notifyDependent处理Element依赖逻辑
• update、updated处理的widget更新逻辑
• didChangeDependencies当此State对象的依赖项更改时调用，子类很少重写此方法，因为框架总是在依赖项更改后调用build。一些子类确实重写了此方法，因为当它们的依存关系发生变化时，它们需要做一些昂贵的工作（例如，网络获取），并且对于每个构建而言，这些工作将太昂贵。
• build() 构建需要的widget，Element在调用build的时候也会触发Widget的build
• void unmount() 这里看到了_delegateState.dispose();的调用，现在找到了吧，当Element从树中移除的时候，回掉了dispose函数。

来看一个生命周期的图，辅助你理解源码的调用关系

此图引自大佬Reactive，他记录了很详细的生命周期图，感谢作者的贡献

• notifyClients 这个函数干嘛的？它是InheritedElement中实现的函数，通过官方文档了解到，它是通过调用Element.didChangeDependencies通知所有从属Element此继承的widget已更改，此方法只能在构建阶段调用，通常，在重建inherited widget时会自动调用此方法，还有就是InheritedNotifier，它是InheritedWidget的子类，在其Listenable发送通知时也调用此方法。
• markNeedsNotifyDependents 如果你调用它，会强制build后 通知所以依赖Element刷新widget，看下面代码，发现该函数在InheritedContext中定义，所以我们可以通过InheritedContext上下文来强制页面的构建

abstract class InheritedContext<T> extends BuildContext {///  [InheritedProvider] 当前共享的数据/// 此属性是延迟加载的，第一次读取它可能会触发一些副作用，T get value;/// 将[InheritedProvider]标记为需要更新依赖项/// 绕过[InheritedWidget.updateShouldNotify]并将强制rebuildvoid markNeedsNotifyDependents();/// setState是否至少被调用过一次/// [DeferredStartListening]可以使用它来区分/// 第一次监听，在“ controller”更改后进行重建。bool get hasValue;
}

小结一下
我们先回顾一下我们是如何使用InheritedWidget的，为了能让InheritedWidget的子Widget能够刷新，我们不得不依赖于Statefulwidget，并通过State控制刷新Element，调用setState刷新页面，其实底层是调用的_element.markNeedsBuild() 函数，这样我们明白了，其实最终控制页面的还是Element，那么Provider 它也巧妙的封装了自己的_delegateState，是私有的，并没有给我们公开使用，也没有提供类似setState，但可以通过markNeedsNotifyDependents函数达到了和setState一样的调用效果，一样的都是让所有子Widget进行重建，可我们要的局部刷新呢？是在Consumer里?，来吧，不要走开，没有广告，精彩继续，接下来研究Consumer源码

Consumer

class Consumer<T> extends SingleChildStatelessWidget {/// 构造函数，必传builderConsumer({Key key,@required this.builder,Widget child,})  : assert(builder != null),super(key: key, child: child);/// 根据 [Provider<T>] 提供的value，构建的widgetfinal Widget Function(BuildContext context, T value, Widget child) builder;@overrideWidget buildWithChild(BuildContext context, Widget child) {return builder(context,Provider.of<T>(context),child,);}
}

• 这里源码稍微有一点绕，Widget child传给了父类SingleChildStatelessWidget，最终通过buildWithChild函数的参数child传递回来，而builder函数有收到了此child，然后再组合child和需要刷新的widget组合一个新的widget给Consumer。一句话就是说Consumer的构造函数可以传两个widget一个是builder，一个是child，最终是通过builder构建最终的widget，如果child不为空，那么你需要自己组织child和builder中返回widget的关系。
• Provider.of<T>(context) 获取了共享数据value

Provider.of<T>(context) 是如何获取数据的呢？继续看源码

/// 调用_inheritedElementOf函数
static T of<T>(BuildContext context, {bool listen = true}) {assert(context != null);final inheritedElement = _inheritedElementOf<T>(context);if (listen) {context.dependOnInheritedElement(inheritedElement);}return inheritedElement.value;}static _InheritedProviderScopeElement<T> _inheritedElementOf<T>(BuildContext context) {_InheritedProviderScopeElement<T> inheritedElement;if (context.widget is _InheritedProviderScope<T>) {// An InheritedProvider<T>'s update tries to obtain a parent provider of// the same type.context.visitAncestorElements((parent) {inheritedElement = parent.getElementForInheritedWidgetOfExactType<_InheritedProviderScope<T>>() as _InheritedProviderScopeElement<T>;return false;});} else {inheritedElement = context.getElementForInheritedWidgetOfExactType<_InheritedProviderScope<T>>() as _InheritedProviderScopeElement<T>;}if (inheritedElement == null) {throw ProviderNotFoundException(T, context.widget.runtimeType);}return inheritedElement;}

• 通过 visitAncestorElements 往父级查找_InheritedProviderScope的实现类也就是InheritedWidget，当找到是就返回_InheritedProviderScopeElement，而_InheritedProviderScopeElement正好可以拿到value，这个value也就是 _delegateState的value

@overrideT get value => _delegateState.value;

走到这其实只是实现了读取数据，那么数据到底是如何刷新的呢？我们回过头来看下面几段代码

1. Model数据调用ChangeNotifier提供的函数notifyListeners

  void notifyListeners() {assert(_debugAssertNotDisposed());if (_listeners != null) {final List<VoidCallback> localListeners = List<VoidCallback>.from(_listeners);for (final VoidCallback listener in localListeners) {try {if (_listeners.contains(listener))listener();} catch (exception, stack) {FlutterError.reportError(FlutterErrorDetails(exception: exception,stack: stack,library: 'foundation library',context: ErrorDescription('while dispatching notifications for $runtimeType'),informationCollector: () sync* {yield DiagnosticsProperty<ChangeNotifier>('The $runtimeType sending notification was',this,style: DiagnosticsTreeStyle.errorProperty,);},));}}}}

这个时候遍历所有的监听，然后执行函数listener()，这里其实等于执行VoidCallback的实例，那这个listener到底是哪个函数？

1. 在ChangeNotifierProvider父类ListenableProvider的静态函数中，自动订阅了为观察者

前面说了观察者就是个普通函数，而e.markNeedsNotifyDependents就是InheritedContext的一个函数，当你notifyListeners的时候执行的就是它markNeedsNotifyDependents，上面我们知道markNeedsNotifyDependents类似setState效果，就这样才实现了UI的刷新。

/// ListenableProvider 的静态函数static VoidCallback _startListening(InheritedContext<Listenable> e,Listenable value,) {value?.addListener(e.markNeedsNotifyDependents); /// 添加观察者return () => value?.removeListener(e.markNeedsNotifyDependents);}/// InheritedContext 上下文abstract class InheritedContext<T> extends BuildContext {...void markNeedsNotifyDependents();...
}

到此位置局部刷新是不是还没揭开面纱？到底是如何做的呢？跟我一起寻找，首先我们来看一个东西

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

Consumer通过Provider.of<T>(context)这句话我们才能监听到数据的对吧，而且刷新的内容也只是这一部分，我们再看下它的实现发现了另一个细节

  static T of<T>(BuildContext context, {bool listen = true}) {assert(context != null);final inheritedElement = _inheritedElementOf<T>(context);if (listen) {context.dependOnInheritedElement(inheritedElement);}return inheritedElement.value;}

它调用了BuildContext的dependOnInheritedElement函数，这个函数做了啥？

 @overrideInheritedWidget dependOnInheritedElement(InheritedElement ancestor, { Object aspect }) {...ancestor.updateDependencies(this, aspect);return ancestor.widget;}

 @overridevoid updateDependencies(Element dependent, Object aspect) {print("updateDependencies===================dependent ${dependent.toString()}");final dependencies = getDependencies(dependent);...setDependencies(dependent, const Object());...
}

  ///    to manage dependency values.@protectedvoid setDependencies(Element dependent, Object value) {_dependents[dependent] = value;}

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

触发updateDependencies，通过setDependencies，将Element缓存到_dependents Map中

最后通过如下代码更新

 @overridevoid notifyDependent(InheritedWidget oldWidget, Element dependent) {print("notifyDependent===================oldWidget ${oldWidget.toString()}");final dependencies = getDependencies(dependent);var shouldNotify = false;if (dependencies != null) {if (dependencies is _Dependency<T>) {for (final updateShouldNotify in dependencies.selectors) {try {assert(() {_debugIsSelecting = true;return true;}());shouldNotify = updateShouldNotify(value);} finally {assert(() {_debugIsSelecting = false;return true;}());}if (shouldNotify) {break;}}} else {shouldNotify = true;}}if (shouldNotify) {dependent.didChangeDependencies();  /// 更新方法}}

所以说整体流程是这样当notifyListeners的时候其实是触发了InheritedWidget的performRebuild，再到 build ，build后触发 notifyClients，notifyClients触发notifyDependent，notifyDependent这个时候通过getDependencies获取缓存好的Element，最终确定是否需要刷新然后调用dependent.didChangeDependencies();更新，哈哈，终于明白了，只要widget中通过Provider.of函数订阅后，就会被InheritedWidget缓存在一个Map中，然后刷新页面的时候，如果子Widget不在缓存的Map中，根本不会走刷新，而且如果shouldNotify变量是false也不会刷新，这个控制肯定是虽然子Widget订阅了，但它自己就是不刷新，可以更加细粒度的控制。

源码分析总结

至此明白

• Provider 通过缓存 inheritedElement 实现局部刷新
• 通过控制自己实现的Element 层来 更新UI
• 通过Element提供的unmount函数回调dispose，实现选择性释放

厉害吗？还不错哦。

冰山一角

其实我们明白了它的核心原理之后，剩下的就是扩展该框架了，我目前只分析了ChangeNotifierProvider、Consumer，其实它还有很多很多，来一张图吓吓你

图片很大，请看原图哦
看到这个图，是不是觉得冰山一角呢？哈哈，不过还好，核心原理就是在InheritedProvider里面，我已经带你趟了一遍，剩下的就靠你自己了，加油。