Flutter Provider 迄今为止最深、最全、最新的源码分析（一）-阿里云开发者社区

回顾

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，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的缺点它规避了吗？

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

我们多加两个子WIdget进去，排在Consumer的后面，OtherWidget什么都不干，不去订阅Counter，OtherWidget2通过context.watch().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 create 是个通用函数typedef Create = T Function(BuildContext context)用于创建T类，这里负责创建ChangeNotifier
bool lazy 是否懒加载
TransitionBuilder builder 当builder存在时将不会用child做为子Widget，追踪到源码实现可以看到如下图

Widget child builder不存在时就用child

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

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 = void Function(BuildContext context, T value); 是个回调，应该是当页面被销毁时触发（等再深入了源码才能认证，目前只是猜测，我们继续看）

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

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是个无状态组件对吗？那么它要变更状态肯定要依赖于别人，而它创建出一个_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 updateShouldNotify, void Function(T value) debugCheckInvalidValueType, StartListening startListening, Dispose 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);
  }
}

Flutter Provider 迄今为止最深、最全、最新的源码分析（一）

回顾

本期内容

如何使用

step 1

step 2

step 3

源码分析

ChangeNotifier

ChangeNotifierProvider

热门文章

最新文章

相关课程

相关电子书

相关实验场景

热门

活动广场

任务中心

开发者评测

高校计划

乘风者计划

训练营

阿里云MVP

话题

直播

下载

镜像站

技术资料

插件

Flutter Provider 迄今为止最深、最全、最新的源码分析（一）

回顾

本期内容

如何使用

step 1

step 2

step 3

源码分析

ChangeNotifier

ChangeNotifierProvider

热门文章

最新文章

相关课程

相关电子书

相关实验场景