Flutter-Provider-迄今为止最深最全最新的源码分析

29次阅读

共计 21236 个字符,预计需要花费 54 分钟才能阅读完成。

回顾

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 providers
    MultiProvider(
      providers: [ChangeNotifierProvider(create: (_) => Counter()),
      ],
      child: MyApp(),),
  );
}

step 3

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

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return const MaterialApp(home: MyHomePage(),
    );
  }
}

class MyHomePage extends StatelessWidget {const MyHomePage({Key key}) : super(key: key);

  @override
  Widget 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);

  @override
  Widget 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);

  @override
  Widget 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 的 Provider
  ChangeNotifierProvider.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] 的 Provider
  ListenableProvider.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] 从树中被释放时,将自动释放数据 value
  InheritedProvider({
    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);

  /// 暴漏给子孙一个已存在的数据 value
  InheritedProvider.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;

  @override
  void debugFillProperties(DiagnosticPropertiesBuilder properties) {super.debugFillProperties(properties);
    _delegate.debugFillProperties(properties);
  }

  @override
  _InheritedProviderElement<T> createElement() {return _InheritedProviderElement<T>(this);
  }

  @override
  Widget 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;

  @override
  bool 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 InheritedElement
    implements 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 依赖变更的时候都会被设置为 true
  bool _isBuildFromExternalSources = false;
/// 委托类的状态(我们猜测对了,owner: this 就是为了拿到上层的委托类)_DelegateState<T, _Delegate<T>> _delegateState;

  @override
  _InheritedProviderScope<T> get widget =>
      super.widget as _InheritedProviderScope<T>;

  @override
  void updateDependencies(Element dependent, Object aspect) {final dependencies = getDependencies(dependent);
    // once subscribed to everything once, it always stays subscribed to everything
    if (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 everything
      setDependencies(dependent, const Object());
    }
  }

  @override
  void 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();
    }
  }

  @override
  void performRebuild() {if (_firstBuild) {
      _firstBuild = false;
      _delegateState = widget.owner._delegate.createState()..element = this;}
    super.performRebuild();}

  @override
  void update(_InheritedProviderScope<T> newWidget) {
    _isBuildFromExternalSources = true;
    _updatedShouldNotify =
        _delegateState.willUpdateDelegate(newWidget.owner._delegate);
    super.update(newWidget);
    _updatedShouldNotify = false;
  }

  @override
  void updated(InheritedWidget oldWidget) {super.updated(oldWidget);
    if (_updatedShouldNotify) {notifyClients(oldWidget);
    }
  }

  @override
  void didChangeDependencies() {
    _isBuildFromExternalSources = true;
    super.didChangeDependencies();}

  @override
  Widget 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();}

  @override
  void unmount() {_delegateState.dispose();
    super.unmount();}

  @override
  bool get hasValue => _delegateState.hasValue;

  @override
  void markNeedsNotifyDependents() {if (!_isNotifyDependentsEnabled) return;

    markNeedsBuild();
    _shouldNotifyDependents = true;
  }

  @override
  T get value => _delegateState.value;

  @override
  InheritedWidget 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 {
  @override
  void 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] 并将强制 rebuild
  void 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 {
 
/// 构造函数,必传 builder
  Consumer({
    Key key,
    @required this.builder,
    Widget child,
  })  : assert(builder != null),
        super(key: key, child: child);

  /// 根据 [Provider<T>] 提供的 value,构建的 widget
  final Widget Function(BuildContext context, T value, Widget child) builder;

  @override
  Widget 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
@override
  T 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();
  ...
}

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

  @override
  Widget 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 函数,这个函数做了啥?

 @override
  InheritedWidget dependOnInheritedElement(InheritedElement ancestor, { Object aspect}) {
    ...
    ancestor.updateDependencies(this, aspect);
    return ancestor.widget;
  }
 @override
  void updateDependencies(Element dependent, Object aspect) {print("updateDependencies===================dependent ${dependent.toString()}");
    final dependencies = getDependencies(dependent);
  ...
     setDependencies(dependent, const Object());
  ...
}
  ///    to manage dependency values.
  @protected
  void setDependencies(Element dependent, Object value) {_dependents[dependent] = value;
  }
  final Map<Element, Object> _dependents = HashMap<Element, Object>();

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

最后通过如下代码更新

 @override
  void 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 里面,我已经带你趟了一遍,剩下的就靠你自己了,加油。

结语

大家还有没有喜欢的 Flutter 状态管理框架,如果你想看到更多的状态管理框架源码分析,请你关注我哦,如果你读到最后,如果你觉得还不错,也请你点个赞,感谢?

正文完
 0