Flutter 路由原理解析

最新推荐文章于 2024-09-11 00:50:03 发布

2401_85700009

最新推荐文章于 2024-09-11 00:50:03 发布

阅读量646

点赞数 15

文章标签： flutter

本文链接：https://blog.csdn.net/2401_85700009/article/details/140099350

版权

我们看看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());
…
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 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 push(Route 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 route, Route 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()) 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 push(BuildContext context, Route 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())
: context.ancestorStateOfType(const TypeMatcher());
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(

尾声

对于很多初中级Android工程师而言，想要提升技能，往往是自己摸索成长，不成体系的学习效果低效漫长且无助。整理的这些架构技术希望对Android开发的朋友们有所参考以及少走弯路，本文的重点是你有没有收获与成长，其余的都不重要，希望读者们能谨记这一点。

最后想要拿高薪实现技术提升薪水得到质的飞跃。最快捷的方式，就是有人可以带着你一起分析，这样学习起来最为高效，所以为了大家能够顺利进阶中高级、架构师，我特地为大家准备了一套高手学习的源码和框架视频等精品Android架构师教程，保证你学了以后保证薪资上升一个台阶。

当你有了学习线路，学习哪些内容，也知道以后的路怎么走了，理论看多了总要实践的。