FlutterDojo设计之道—状态管理之路(四)

在Flutter中,跨Widget的数据共享,能够以下图这样表示。android

当Child Widget想要跨Widget拿到其它Widget的数据时,一般就须要使用构造函数,将数据一层层传递到Child Widget,这显然不是一个好的解决方案,不只让Widget之间有了很大的耦合,也产生不少的冗余数据。web

为了解决这个问题,Flutter SDK提供了InheritedWidget这个Widget,InheritedWidget是除了StatefulWidget和StatelessWidget以外的第三个经常使用的Widget。当把InheritedWidget做为Widget Tree的根节点时,这个Widget Tree就具备了一些新的功能,例如,Child Widget能够根据BuildContext找到最近的指定类型的InheritedWidget,而不是经过Widget Tree的构造函数一层层进行传递,以下图所示。微信

InheritedWidget的使用其实很是简单,即共享数据给Child。因此它的核心点,其实就是两个。less

  • 须要共享的数据
  • 从新updateShouldNotify的条件

经过BuildContext的dependOnInheritedWidgetOfExactType函数,就能够直接获取父Widget中的InheritedWidget。因此在InheritedWidget内部,一般会有一个of函数,用过调用BuildContext的dependOnInheritedWidgetOfExactType函数来获取对应的父InheritedWidget。编辑器

只读的InheritedWidget

InheritedWidget默认状况下都是只读的,即只能将某个数据共享给Child Widget,而不能让Child Widget对数据作更新。下面这个例子演示了一个最基本的InheritedWidget是如何共享数据的。ide

class InheritedWidgetReadOnlyWidget extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return ReadOnlyRoot(
      count: 1008,
      child: ChildReadOnly(),
    );
  }
}

class ChildReadOnly extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    debugPrint('build');
    ReadOnlyRoot root = ReadOnlyRoot.of(context);
    return Column(
      children: <Widget>[
        SubtitleWidget('InheritedWidget自己不具备写数据的功能,须要结合State来获取数据修改的能力'),
        Text(
          'show ${root.count}',
          style: TextStyle(fontSize: 20),
        ),
      ],
    );
  }
}

// 仅支持读取属性
class ReadOnlyRoot extends InheritedWidget {
  static ReadOnlyRoot of(BuildContext context) => context.dependOnInheritedWidgetOfExactType<ReadOnlyRoot>();

  final int count;

  ReadOnlyRoot({
    Key key,
    @required this.count,
    @required Widget child,
  }) : super(key: key, child: child);

  @override
  bool updateShouldNotify(ReadOnlyRoot oldWidget) => count != oldWidget.count;
}

给InheritedWidget增长读写功能

数据的状态一般状况下都是保存在StatefulWidget的State中的,因此,InheritedWidget必需要结合StatefulWidget才能具备修改数据的能力,所以,思路就是在InheritedWidget中持有一个StatefulWidget的State实例,同时,使用一个StatefulWidget,将本来的Child Widget之上,插入这个InheritedWidget,这样就能够借助StatefulWidget来完成数据的修改能力,经过InheritedWidget来实现数据的共享能力。函数

class RootContainer extends StatefulWidget {
  final Widget child;

  RootContainer({
    Key key,
    this.child,
  }) : super(key: key);

  @override
  _RootContainerState createState() => _RootContainerState();

  static _RootContainerState of(BuildContext context) => context.dependOnInheritedWidgetOfExactType<Root>().state;
}

class _RootContainerState extends State<RootContainer> {
  int count = 0;

  void incrementCounter() => setState(() => count++);

  @override
  Widget build(BuildContext context) {
    return Root(state: this, child: widget.child);
  }
}

// 同时支持读取和写入
class Root extends InheritedWidget {
  final _RootContainerState state;

  Root({
    Key key,
    @required this.state,
    @required Widget child,
  }) : super(key: key, child: child);

  // 判断是否须要更新
  @override
  bool updateShouldNotify(Root oldWidget) => true;
}

在这种写法中,InheritedWidget(Root)是在StatefulWidget(RootContainer)中初始化的,当使用StatefulWidget(RootContainer)的setState函数时,InheritedWidget(Root)重建了,可是其child并不会重建,由于它是widget.child,并不会由于State的重建而重建。flex

要注意的是,虽然这里的StatefulWidget经过setState来修改数据了,但其子Widget并不会所有重绘,由于InheritedWidget的存在,Child Widget会有选择性的进行重绘。ui

在这基础上,使用就比较简单了,代码以下所示。this

class InheritedWidgetWidget extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return RootContainer(
      child: Column(
        children: <Widget>[
          Widget1(),
          Widget2(),
          Widget3(),
        ],
      ),
    );
  }
}

class Widget1 extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    debugPrint('build Widget1');
    return SubtitleWidget('InheritedWidget自己不具备写数据的功能,须要结合State来获取数据修改的能力');
  }
}

class Widget2 extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    debugPrint('build Widget2');
    return Text(
      'show ${RootContainer.of(context).count}',
      style: TextStyle(fontSize: 20),
    );
  }
}

class Widget3 extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    debugPrint('build Widget3');
    return RaisedButton(
      onPressed: () {
        RootContainer.of(context).incrementCounter();
      },
      child: Text('Add'),
    );
  }
}

相关代码 Flutter Dojo-Widgets-Async-InheritedWidget

在上面这个Demo中,Widget二、3分别获取和修改了InheritedWidget中的共享数据,实现了跨Widget的数据共享。

经过Log咱们能够发现,初始化的时候,Widget一、二、3都执行了build,但点击的时候,只有Widget二、3从新build了,可是Widget1并不会从新build。

这是什么缘由呢?

其实这就是RootContainer.of(context)致使的。

当咱们执行RootContainer.of(context)这个函数的时候,实际上调用的是context.dependOnInheritedWidgetOfExactType函数,这个函数不只仅会返回指定类型的InheritedWidget,同时也会将Context对应的Widget添加到订阅者列表中,也就是说,即便你调用这个函数,只是为了执行某个函数,并非想刷新UI,可是系统依然认为你须要刷新,从而致使Widget二、3都会执行rebuild。而Widget1,因为没有调用过of函数,因此不会被添加到订阅者列表中,因此不会执行rebuild。

要想解决这个问题也很是简单,那就是在不须要监听的时候,使用findAncestorWidgetOfExactType便可,这个函数只会返回指定类型的Widget,而不会将监听加入订阅者列表中。

static _RootContainerState ofNoBuild(BuildContext context) => context.findAncestorWidgetOfExactType<Root>().state;

点击按钮的函数,只须要调用上面的这个函数,在点击的时候,Widget3就不会执行rebuild了。

除了这种方式之外,还有一个方式,那就是经过const关键字,将一个Widget设置为常量Widget,即不会发生改变,这个时候rebuild的时候,系统会发现const Widget并无发生改变,就不会rebuild了,这也是为何在Flutter中,不少不须要改变的Padding、Margin、Theme、Size等参数须要尽量设置为const的缘由,这样能够在rebuild的时候,提升效率。

在Flutter中,Theme的实现,就是采用的这种方式。

Widget Tree的遍历

前面提到了两种方式来获取Widget Tree中的InheritedWidget,dependOnInheritedWidgetOfExactType和findAncestorWidgetOfExactType,从调用结果上来看,一种是会被加入订阅者名单,一种只是单纯的查找。

下面再来继续仔细的看看这两个函数的区别。

findAncestorWidgetOfExactType

首先来看下这个函数的注释。

从中咱们能够提取几个关键信息。

  • 不会触发rebuild
  • O(n)复杂度
  • 最好在didChangeDependencies中调用

因此findAncestorWidgetOfExactType有几个比较经常使用的使用场景。

  • 在断言中判断父Widget的使用条件
  • 获取父Widget对象,调用其方法

例如在一些Widget中,能够经过Assert来判断当前是否有使用该Widget的条件,例如Hero Widget。

dependOnInheritedWidgetOfExactType

首先也来看下这个函数的注释。

  • 会触发rebuild
  • O(1)复杂度
  • 最好在didChangeDependencies中调用

能够发现,其实他跟findAncestorWidgetOfExactType是很是相似的,主要的区别仍是在因而否会rebuild,另外,dependOnInheritedWidgetOfExactType的效率很高。

项目地址 Flutter Dojo


本文分享自微信公众号 - Android群英传(android_heroes)。
若有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一块儿分享。

相关文章
相关标签/搜索