Flutter 路由原理解析

前言

这一次，我尝试以不贴一行源代码的方式向你介绍 Flutter 路由的实现原理，同时为了提升你阅读源码的积极性，除了原理介绍之外，又补充了两个新的模块：从源码中学习到的编程技巧，以及 阅读源码以后对实际应用开发带来的帮助。

但愿这样1+2的模式，能够诱导你以很是积极的心态，很轻松的学习到 Flutter 路由相关的知识。

固然，不贴一行源代码，纯白话的讲解必然会隐藏不少细节知识，渴望知识的你必定不会知足的，因此我在原理介绍结束以后，又补充了一篇番外：贴了大段大段的纯源码解析的《Flutter 路由源码解析》，知道大概原理的你再去读源码，必定会轻松不少吧，但愿这样的模式能够有效的帮助到你！

本文大纲：

• Flutter 路由实现

  • Flutter 路由实现的底层依赖
  • Flutter 路由过程
  • 番外：《Flutter 路由源码解析》

• Navigator 源码里很是值得学习的 Flutter 编程技巧

  • Flutter中的“命令式编程”：对象引用查找与远程局部更新
  • 元素自治
  • 私有类包装：隔离逻辑与Widget

• 阅读 Navigator 源码以后对实际应用开发的帮助

  • 路由动态监听
  • 路由监听中，识别 弹窗 or Page
  • 动态添加 Widget
  • 易踩的坑：多Navigator嵌套状况下的错误路由查找

Flutter 路由实现

Flutter 路由实现的底层依赖

若是你对 Flutter 的Widget Tree有些了解。应该知道 Flutter 中的根 Widget 是RenderObjectToWidgetAdapter,根 Widget 的 child 就是咱们在void runApp(Widget app)中传入的自定义 Widget。

从runApp开始，Flutter的列车便轰隆隆开动了。彷佛一切都瓜熟蒂落，直到咱们开始思考，执行Navigator.push()方法开启新的页面是如何实现的？

再继续分析以前，咱们不妨先本身想一想：若是让你来设计，你会如何设计Navigator? 若是是个人话，我大概会这样设计, 而后把这个 MyNavigator 放到 Widget 树的根部：

// 伪代码
class MyNavigator extends StatefulWidget{
  ...
  Map<String,Page> pageMap = ...;
  String currentPage = "one";
  
  void setCurrentPage(String pageName){
    setState(() {
      currentPage = pageName;
    });
  }

  @override
  Widget build(BuildContext context) {
    return pageMap[currentPage];
  }
}
复制代码

那Flutter是如何实现的呢？

咱们先看一个最普通的Flutter App 的 Widget 树结构：

哈哈，这个图乍一眼看有点懵，陌生的 Widget 可能有点多，挨个简单解释一下：

• RenderObjectToWidgetAdapter： Flutter 中的 root widget。

• MyApp： 咱们在void runApp(Widget app)中传入的自定义 Widget。

• MaterialApp ： 就是那个Flutter 官方的 MaterialApp组件，一般咱们会在自定义的根布局使用它，不用它的话不少官方Widget就没办法使用了。

• Navigator: 实现路由跳转用的就是它，它也是一个Widget，已经早早的嵌入了 WidgetTree 中。它维护了一个Route集合，你调用push，pop方法时，Navigator都会以栈的方式对这个集合进行添加或删除，就是你所熟悉的界面栈。 （和咱们所想的方案几乎同样是否是？）

• Overlay: 顾名思义，一个能够实现一层层向上覆盖 Widget 的组件,它持有了一个集合List<OverlayEntry>，你能够获取这个 Widget 的引用来向集合中添加组件，使得新的组件覆盖在已有的组件上面。在Navigator体系中，你的Route对象，都将转化为OverlayEntry对象存入这个集合。

• OverlayEntry: OverlayEntry在图中没有，由于它不是一个 Widget，而是一个纯纯的 Dart 类。Overlay维护的是一个纯 Dart 类集合，最后再根据这个 Dart 类集合去建立 Widget。为何这样作呢？由于直接操做Widget并非一件优雅安全的事情，这一点咱们再下一节会将。

• _Theatre: 这是一个私有类，而且只有Overlay使用了它。它的名字很是形象的表达了它的功能：剧院。你有不少组件以一层层覆盖的模式绘制在界面上，若是其中某一层的组件以全屏不透明的模式绘制在界面上，那它下层的组件就不须要再进行绘制了（下面的彻底看不到了还绘制啥呀~）。_Theatre就在作这样的事，须要绘制的组件放置在“舞台之上”，其余不须要绘制的组件做为观众放置台下，仅 build 但不绘制。

• Stack: 相似 Android 里的FrameLayout, 顺序绘制它的 child,第一个child被绘制在最底端，后面的依次在前一个child的上面。

• _OverlayEntry: 上面咱们有提到OverlayEntry，这个纯 Dart 类最终会以 _OverlayEntry的形式进入 Widget 树中。Overlay是以_OverlayEntry为最小 Widget 单位向Stack中添加 child 的。_OverlayEntry包裹了咱们的自定义 Page。

• MyPage：就是你自定义的页面。

听起来Overlay和Stack功能彻底同样？

了解这个以前，你须要知道每一个经过路由展现在界面的上的 Page 或 PopupWindow,都有两个状态值：

• opaque：是不是全屏不透明的，当一个组件opaque=true时，那么能够认为它之下的组件都不须要再绘制了。通常状况下，一个 Page 的opaque=true， 不是全屏的 PopupWindow opaque=false。
• maintainState：一个已经不可见(被上面的盖住彻底看不到啦~)的组件，是否还须要保存状态。当maintainState=true时，会让这个组件继续活着，但不会再进行绘制操做了。若是maintainState=false，则不会继续维持这个 Widget 的生存状态了。

画个图来解释下，线框表明屏幕，长条表明一个个层叠绘制在屏幕上的组件。蓝色表明须要被绘制，黄色表明须要维持它活着但不须要绘制，灰色表明能够被抛弃的。

好了，知道这两个知识点之后，咱们继续讲Overlay和Stack。

Overlay 的能力趋向因而一种逻辑管理，它维护了全部准备要绘制到界面上的组件。并倒序（后加入的组件绘制到最上方）遍历这些组件，最开始每一个组件都有成为“演员的机会”，直到某个组件的opaque 的值为 true , 后面的组件便只有作 “观众” 的机会了，对于剩下的组件，判断他们的maintainState 值，为 true 的才有机会作观众，为false的没有入场机会了，他们这一阶段的生命周期将结束。以后将分类完成的“演员”和“观众”交给 _Theatre。

_Theatre维护了两个属性：onstage和offstage，onstage里又持有了一个Stack，将全部的“演员”加入Stack中，依次覆盖绘制。offstage维护了全部的“观众”，只build他们，但不绘制。

Overlay 管理OverlayEntry 的逻辑相似下面这张图：

可能你会比较好奇_Theatre中 offstage 是如何作到不绘制的。

你应该知道 Element 树的是经过其内部的mout方法将本身挂载到父 Element 上的。_Theatre的 mout方法不太同样， onstage走正常的挂载流程，加入到Element 树中； offstage集合中的 Widget 仅建立了对应的 Element，并无挂载到 Element 树中。没有进入到Element中，也就不会进入到 RenderObject树中，也就不走到绘制流程了。

这样你应该能理解Overlay实际上是Stack的扩展。Overlay预先进行过滤，从而避免了无用的绘制。

Flutter 路由过程

通过上面讲的 Widget 树结构以及Overlay的能力和原理，你大概能猜到Navigator就是在Overlay的基础上扩展实现的。那具体是怎样一个过程呢？

你已经知道Navigator维护了一个 Route 集合（就是一个很普通的 List）。你调用push方法向集合中增长一个 Route时， 也同时会建立出两个对应的OverlayEntry, 一个是遮罩（对原理解释并非很重要，后面咱们会忽略它，你只要知道就行了），一个表明 Page 自己。

咱们看下当路由中只有一个 Page 时的示意图：

Navigator 持有一个 Route 集合，里面只有一个 Page。一样的，Navigator内部的Overlay也持有一个OverlayEntry集合，而且有与 Page 对应的OverlayEntry。须要提醒的是，Route与OverlayEntry并非一一对应的，而是1:2，上面咱们讲了还有一个遮罩，只是这里为了图示简单，省略了它。

由于只有一个 Page 须要展现，因此它在_Theatre的onstage的Stack里，最终将被绘制。此时offstage为空。

咱们再看下当路由中又被 push 进一个 Page时的状况：

由于一般 Page 的 opaque=true, maintainState=true,因此 Page2 进入 onstage， Page1 不在须要被绘制，但须要保持状态，进入了offstage。

当咱们再次向路由中 push 一个 Page：

咱们已经看了3个 Page 的状况，再看一个 popupWindow（dialog） 的状况，由于一般 popupWindow（dialog） 的 opaque=false,咱们再向路由中 push 一个 dialog:

由于 dialog 并非全屏不透明的，它下面仍是要展现Page的一部分，因此它要和 Page 一块儿绘制在屏幕上，只不过 dialog 在最上层。

pop 的过程就是 push的反向，把4张图倒着看一遍就ok啦。

这里只讲了最简单的 push ，Navigator还提供了丰富的push和pop方法，但最终只是最基础的push或pop的扩展。

好比pushNamed,其实就是经过字符串匹配建立出对应的Route，而后调用push方法；pushReplacement其实就是push的同时pop出旧的Route,以你的聪明才智，必定很轻易就能猜到实现逻辑的，这里我就很少介绍啦。

番外：《Flutter 路由源码解析》

求知欲如此之强的你，必定渴望更多的细节。若是你还精力旺盛，就继续跟我去看看源码吧~

番外：《Flutter 路由源码解析》

不阅读源码不影响接下来的阅读哦~，但若是读过以后，下面的内容会更香！

Navigator 源码里很是值得学习的Flutter 编程技巧

Navigator 体系的源码，阅读理解起来，不是特别难，但也有必定的复杂性。因此其中包含了一些很是值得学习的 Flutter风格编程技巧。

Flutter中的“命令式编程”：对象引用查找与远程局部更新

区别于Androdi&iOS的命令式编程范式，Flutter 声明式的编程范式早期会给开发者带来极大的不适。最大的改变在于UI的更新是经过 rebuild 来实现的，以及对象引用的概念被弱化了（若是每一次都是从新建立，那持有一个 Widget 的引用也就不是很重要了）。

这样的改变较为容易引发你不适的点在于：

• 1.在 Widget 树中，对某个 Widget 的引用获取。

  偶尔依然会有获取某个Widget引用的需求；

• 2.参数层层传递问题。

  若是顶层持有的某个参数须要被传递到底层，层层传递是一件很是痛苦的事。若是能直接拿到上层 Widget 的引用，获取该 Widget 持有的参数的话就很方便了。

• 3.当触发更新的点和要被更新的点在代码上距离较远时。

  若没有借助 Redux 等框架, 一般咱们会将【触发更新的点】和【被更新的点】封装在尽量小的范围里（封装在一个范围最小的StatefulWidget中）。但总有十万八千里的两个有缘人，这个时候触发大范围，甚至整颗Widget树的rebuild的话就不是很优雅了。

那这三个点如何解决呢？

在 Navigator 的源码体系里，有两个关键对象对外提供了全局引用的能力，分别是：Navigator 和 Overlay，借助的均是 BuildContext的 ancestor*方法向上查找。

BuildContext 是 Element 的抽象类，因此BuildContext的查找也就是在 Element 树中遍历查找须要的元素。

咱们看看BuildContext都提供了哪些方法：

ancestorInheritedElementForWidgetOfExactType --- 向上查找最近的InheritedWidget的 InheritedElement
inheritFromWidgetOfExactType --- 向上查找最近的InheritedWidget
ancestorRenderObjectOfType   --- 向上查找最近的给定类型的RenderObject
ancestorStateOfType --- 向上查找最近的给定类型的StatefulWidget的State对象
ancestorWidgetOfExactType   --- 向上查找最近的给定类型的Widget
findRenderObject  --- 向下查找当前的RenderObject
rootAncestorStateOfType  --- 向上查找最顶层的给定类型的 State

visitAncestorElements（bool visitor（Element element）） --- 向上遍历 Ancestor
复制代码

向上查找较为简单，传入对应类型便可，向下BuildContext也提供了遍历 child的方法：

visitChildElements（ElementVisitor visitor）  --- 向下遍历 child
复制代码

以Overlay的静态方法of方法为例(Navigator也有相似的of方法),传入须要查找的类型对象TypeMatcher,向上查找到最近的OverlayState,使得Overlay无需层层向下传递本身的引用，底层 Widget 遍能够在任何地方拿到Overlay引用，并调用它的方法或属性，这解决1``2的问题：

class Overlay {
...
static OverlayState of(BuildContext context, { Widget debugRequiredFor }) {
    final OverlayState result = context.ancestorStateOfType(const TypeMatcher<OverlayState>());
    ...
    return result;
}
...
复制代码

那么对于相聚千里以外的有缘人，如何通知对方 rebuild 呢？ Overlay也给了咱们很好的示例，以 OverlayState的insert方法为例：

经过Overlay的静态方法of获取到OverlayState引用以后，调用insert,其内部直接调用了setState(() {} 方法修改了本身的数据内容，并触发了本身范围内的 rebuild 。

void insert(OverlayEntry entry, { OverlayEntry above }) {
    entry._overlay = this;
    setState(() {
      final int index = above == null ? _entries.length : _entries.indexOf(above) + 1;
      _entries.insert(index, entry);
    });
  }
复制代码

这样，1``2``3点便有了相应的解决方案，开发过程当中不妨考虑用这样的方式优化你的代码。

但在Element树中遍历查找引用以及操做，毕竟不是一件高效和安全的事情，因此在某些场景下，能够考虑下面的一个技巧：“元素自治”。

元素自治

最佳示例依然来自于Overlay。

传统编程思惟方式中，集合负责存储元素，元素持有数据，某个 Manager 负责操做集合与集合里的元素。

OverlayState提供了三个操做集合的方法：

void insert(OverlayEntry entry, { OverlayEntry above }) 
  void insertAll(Iterable<OverlayEntry> entries, { OverlayEntry above }) 
  void _remove(OverlayEntry entry) 
复制代码

受限于 Flutter 声明式的编程方式，对象引用的查找成本较高，Manager 的实如今这个场景里也不够优雅。因此虽然insert方法依然须要经过Overlay的静态方法of查找OverlayState引用来调用。 但_remove倒是一个私有方法，不容许你直接经过OverlayState来调用。

OverlayEntry的删除只能由OverlayEntry本身来执行：

class OverlayEntry {
  ...
  void remove() {
    final OverlayState overlay = _overlay;
    _overlay = null;
    if (SchedulerBinding.instance.schedulerPhase == SchedulerPhase.persistentCallbacks) {
      SchedulerBinding.instance.addPostFrameCallback((Duration duration) {
        overlay._remove(this);
      });
    } else {
      overlay._remove(this);
    }
  }
  ...
复制代码

这样的编程方式，既保证了元素“安全”，又避免了在树中的查找的损耗。

安全的理由是：元素的删除不只是从集合中删除就结束了，还有一系列“卸载”和回调的须要被执行，元素自治屏蔽了外部直接操做集合删除元素的可能。

私有类包装：隔离逻辑与Widget

若是须要你来自定义一个Widget，这个Widget内部持有了多个children，这些children都是在不断变化的。你会怎么维护这个children列表呢？

直接建立一个 List<Widget> 集合吗？不，这并不优雅也不安全！

咱们知道 Widget 是 Flutter 里的基础基石，每个Widget在run起来以后都有无限的延伸，多是短命不可复用的可能又是长期存在的，它们不但能够产出Element和RenderObject，还包括了完整的生命周和体系内的各类回调。

你能够保证能照顾好他们吗？

Flutter 世界里的一个潜规则是：Wideget的建立，尽量只在build方法中进行！将Wideget的建立和销毁交给Flutter 系统来维护！

那么该如何作呢？

第三个示例仍是来自于Overlay， Overlay的设计真的不错！

Overlay 内部也持有了多个children：List<OverlayEntry> ，但OverlayEntry并非一个Widget，它只是一个普通的 Dart 类。它持有了建立Widget必要的属性以及一些逻辑。

而Overlay在build时真正建立的 Widget 是_OverlayEntry：

class _OverlayEntry extends StatefulWidget {
  _OverlayEntry(this.entry)
    : assert(entry != null),
      super(key: entry._key);

  final OverlayEntry entry;

  @override
  _OverlayEntryState createState() => _OverlayEntryState();
}

class _OverlayEntryState extends State<_OverlayEntry> {
  @override
  Widget build(BuildContext context) {
    return widget.entry.builder(context);
  }

  void _markNeedsBuild() {
    setState(() { /* the state that changed is in the builder */ });
  }
}
复制代码

能够看到_OverlayEntry是一个私有类，它的代码很是简单，构造方法里传入一个OverlayEntry,build 时执行的是entry.builder(context)方法。

因此：若是你须要对一个Widget或Widget集合作频繁的操做，建议的作法是将逻辑和属性抽离出来，维护一个不变的逻辑对象，让Widget根据逻辑对象进行build或rebuild。 尽可能避免直接操做一个Widget以及改变它内部的属性。

阅读 Navigator 源码以后对实际应用开发的帮助

源代码的阅读每每能够加深对系统执行过程的理解，在未来的某一天可能会起到相当重要的做用，却也可能永远用不到。这种收益的不肯定性和源码阅读的枯燥性，每每会让大部分人望而却步。

因此在文章的最后，我简单的列出一些在源码阅读以后，对实际应用开发的帮助。由此，来增长你对源码学习的积极性。

路由动态监听

随着开发复杂度的上升，你必定会有监听路由变化的需求。若是你对MaterialApp有些许研究，会知道在构建MaterialApp时能够传入一个navigatorObservers的参数，大概像这样：

Widget build(BuildContext context) {
    return new MaterialApp(
      navigatorObservers: [new MyNavigatorObserver()],
      home: new Scaffold(
        body: new MyPage(),
      ),
    );
  }
复制代码

navigatorObservers是一个List<NavigatorObserver>集合，每当navigator发生变更时，都会遍历这个集合回调对应的方法。

即便你不知道MaterialApp有这样一个属性，在阅读NavigatorState源码时，pop,push等方法内部都有下面这样的代码, 了解到路由的变化是提供了observer的：

@optionalTypeArgs
  Future<T> push<T extends Object>(Route<T> route) {
  	...
    for (NavigatorObserver observer in widget.observers)
      observer.didPush(route, oldRoute);
	...
  }
复制代码

另外一个问题来了！

一个标准的工程，每每会将MaterialApp申明在最顶层，而大部分须要监听路由变更的场景，都在下层的业务代码里。笨办法是将监听函数层层传递，但这绝对是一个极其痛苦的过程。

一个相对优雅的解决方案是：动态添加路由监听。那如何实现呢？

Navigator和NavigatorState并无直接暴露添加监听的接口（是官方并不建议吗？），但看过源码的你会知道，最终回调的observers是由Navigator持有的observers对象，幸亏它是一个public属性。

因此，动态添加路由监听的方法能够这样实现：

MyNavigatorObserver myObserver = MyNavigatorObserver();

  @override
  void initState() {
    super.initState();
    //建议在initState时动态添加Observer，而不是build时，避免重复添加
    Navigator.of(context).widget.observers.add(myObserver);
  }

  @override
  void dispose() {
    super.dispose();
    //dispose时记得移除监听
    Navigator.of(context).widget.observers.remove(myObserver);
  }
  
复制代码

路由监听中，识别 弹窗 or Page

一个较为困扰的事情是，在 Flutter 的世界中，不管是页面仍是弹窗，都是以路由的方式来实现的，因此在路由监听的回调中，弹窗的展现和消失也会触发回调。

若是你想识别回调中的路由是弹窗仍是Page该怎么办？ 有没有什么较为优雅的方式？

读过源码的你必定记得，在OverlayState的 build 方法中，经过OverlayEntry的opaque属性，将全部将要进入_Theatre组件中的entry区分为了onstageChildren和offstageChildren。

opaque意义在哪呢？它决定了当前的Widget是不是一个“全屏不透明”的Widget，Page通常状况下占用所有屏幕，因此他是“全屏不透明的”，弹窗通常状况下只占用所有屏幕的一部分，因此它的“全屏透明的”。

读过源码的你会知道，Route的子类TransitionRoute持有了opaque属性，而且全部的"PageRoute"opaque=true,"PopupRoute"opaque=false。

那么事情就很简单了：

class MyNavigatorObserver extends NavigatorObserver {
  @override
  void didPush(Route<dynamic> route, Route<dynamic> previousRoute) {
    if ((previousRoute is TransitionRoute) && previousRoute.opaque) {
      //全屏不透明，一般是一个page
    } else {
      //全屏透明，一般是一个弹窗
    }
  }
}
复制代码

值得注意的是，opaque值并不能彻底表明它是一个Page或弹窗，老是会有特殊状况的。因此对这一点的理解，更准确的说法是：识别previousRoute是否会占据所有屏幕，致使本来的route不可见。

动态添加 Widget

受限于Flutter 独特的编程方式，想要在代码中随时插入一个 Widget 仍是比较困难的。

但读过源码的你已经知道了，在MaterialApp中已经预先内置了一个Overlay,虽然它是给 Navigator服务的，但你也彻底能够拿来用：

//获取最近的一个Overlay进行操做，若是你没有添加自定义的，一般是`Navigator`的那个
Overlay.of(context).insert(entry);

//获取最靠近根部的Overlay进行操做，一般是`Navigator`的那个
(context.rootAncestorStateOfType(const TypeMatcher<OverlayState>()) as OverlayState).insert(entry);

复制代码

易踩的坑：多Navigator嵌套状况下的错误路由查找

成也 Widget，败也 Widget。万物皆 Widget 能够有无限的组合，但也可能致使 Widget 的滥用。

MaterialApp 在 Flutter 世界中的地位相似于 Android 中的 Application + BaseActivity。 理论上一个项目中只应该在顶层有惟一的一个MaterialApp ，但 Flutter 却也不限制你在 Widget 树中任意地方使用多个MaterialApp。

另外Navigator也是一个 Widget，你也能够在树中的任意地方插入任意多个Navigator。

这会形成什么问题呢？假设咱们有这样一个 Widget 树：

- MaterialApp
	- ...
		-  Navigator
			- ...
				-  MaterialApp
				-  Navigator
					- ...
					- MaterialApp
复制代码

你猜这个 Widget 树里有多少个 Navigator? 看过源码你知道每一个MaterialApp内部都包含一个Navigator,因此这棵树里有5个Navigator。 这么多Navigator的问题在哪呢？

看下Navigator的push方法：

static Future<T> push<T extends Object>(BuildContext context, Route<T> route) {
    return Navigator.of(context).push(route);
  }
复制代码

默认调用的是单个参数的Navigator.of(context),在看下of内部：

static NavigatorState of(
    BuildContext context, {
      bool rootNavigator = false,
      bool nullOk = false,
    }) {
    final NavigatorState navigator = rootNavigator
        ? context.rootAncestorStateOfType(const TypeMatcher<NavigatorState>())
        : context.ancestorStateOfType(const TypeMatcher<NavigatorState>());
    return navigator;
}
复制代码

默认状况下，向上查找的不是根节点的NavigatorState,而是最近的一个。这将致使你在树中任意位置push或pop操做的可能不是同一个NavigatorState对象，他们维护的也不是同一个 route栈，这将致使不少问题。

因此合适的作法是：

• 1.尽量保证你的代码中，MaterialApp在项目中有且只有一个，且在Widget 树的顶层。

• 2.你不能保证代码中只有一个Navigator, 因此对于全局的Page管理，建议将push或pop封装，使用Navigator.of(context, rootNavigator:true)代码去保证你拿的是根部的Navigator。

而对于真的有须要去获取树中的某个Navigator而不是根Navigator，你要严格 check Navigator.of(context) 中你所使用的 BuildContext，要保证它是在你要获取的 Navigator 之下的。

一个 badcase:

class MyWidget extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return Stack(
      children: <Widget>[
        MyNavigator(), 
        GestureDetector(
          onTap: (){
            Navigator.of(context);
          },
          child: Text("ClickMe"),
        )
      ],
    );
  }
}
复制代码

MyNavigator是咱们自定义的Navigator,咱们须要点击“ClickMe”来在树中查找到MyNavigator的引用，那么，你以为能查的到吗？

答案是不能！由于咱们是基于MyWidget的BuildContext（BuildContext就是Element的抽象）去在Element树中向上查找的，但很明显MyWidget在 MyNavigator上层，固然不会获得你想要的结果啦~