时间:2021-08-21 09:11:03 | 栏目:Android代码 | 点击:次
整个 flutter 应用的运行都只是基于原生应用中的一个 view,比如 android 中的 FlutterView,flutter 中的页面切换依赖于它的路由机制,也就是以 Navigator 为中心的一套路由功能,使得它能够完成与原生类似且能够自定义的页面切换效果。
下面将介绍 flutter 中的路由实现原理,包括初始化时的页面加载、切换页面的底层机制等。
flutter 应用的运行需要依赖 MaterialApp/CupertinoApp 这两个 Widget,他们分别对应着 android/ios 的设计风格,同时也为应用的运行提供了一些基本的设施,比如与路由相关的主页面、路由表等,再比如跟整体页面展示相关的 theme、locale 等。
其中与路由相关的几项配置有 home、routes、initialRoute、onGenerateRoute、onUnknownRoute,它们分别对应着主页面 widget、路由表(根据路由找到对应 widget)、首次加载时的路由、路由生成器、未知路由代理(比如常见的 404 页面)。
MaterialApp/CupertinoApp 的子结点都是 WidgetsApp,只不过他们给 WidgetsApp 传入了不同的参数,从而使得两种 Widget 的界面风格不一致。Navigator 就是在 WidgetsApp 中创建的,
Widget build(BuildContext context) { Widget navigator; if (_navigator != null) { navigator = Navigator( key: _navigator, // If window.defaultRouteName isn't '/', we should assume it was set // intentionally via `setInitialRoute`, and should override whatever // is in [widget.initialRoute]. initialRoute: WidgetsBinding.instance.window.defaultRouteName != Navigator.defaultRouteName ? WidgetsBinding.instance.window.defaultRouteName : widget.initialRoute ?? WidgetsBinding.instance.window.defaultRouteName, onGenerateRoute: _onGenerateRoute, onGenerateInitialRoutes: widget.onGenerateInitialRoutes == null ? Navigator.defaultGenerateInitialRoutes : (NavigatorState navigator, String initialRouteName) { return widget.onGenerateInitialRoutes(initialRouteName); }, onUnknownRoute: _onUnknownRoute, observers: widget.navigatorObservers, ); } ... }
在 WidgetsApp 的 build 中第一个创建的就是 Navigator,主要看一下它的参数,首先,_navigator 是一个 GlobalKey,使得 WidgetsApp 可以通过 key 调用 Navigator 的函数进行路由切换,也就是在 WidgetsBinding 中处理 native 的路由切换信息的时候,最终是由 WidgetsApp 完成的。另外这里的 _navigator 应该只在 WidgetsApp 中有使用,其他地方需要使用一般是直接调用 Navigator.of 获取,这个函数会沿着 element 树向上查找到 NavigatorState,所以在应用中切换路由是需要被 Navigator 包裹的,不过由于 WidgetsApp 中都有生成 Navigator,开发中也不必考虑这些。
另外,就是关于底层获取上层 NavigatorElement 实例的方式,在 Element 树中有两种方式可以从底层获取到上层的实例,一种方式是使用 InheritedWidget,另一种就是直接沿着树向上查找(ancestorXXXOfExactType 系列),两种方式的原理基本是一致的,只不过 InheritedWidget 在建立树的过程中会一层层向下传递,而后者是使用的时候才向上查找,所以从这个角度来说使用 InheritedWidget 会高效些,但是 InheritedWidget 的优势不止如此,它是能够在数据发生改变的时候通知所有依赖它的结点进行更新,这也是 ancestorXXXOfExactType 系列所没有的。
然后 initialRoute 规定了初始化时候的页面,由 WidgetsBinding.instance.window.defaultRouteName 和 widget.initialRoute 来决定,不过前者优先级更高,因为这个是 native 中指定的,以 android 为例,在启动 FlutterActivity 的时候可以传入 route 字段指定初始化页面。
onGenerateRoute 和 onUnknownRoute 是获取 route 的策略,当 onGenerateRoute 没有命中时会调用 onUnknownRoute 给定一个默认的页面,onGenerateInitialRoutes 用于生产启动应用时的路由列表,它有一个默认实现 defaultGenerateInitialRoutes,会根据传递的 initialRouteName 选择不同的 Route,如果传入的 initialRouteName 并不是默认的主页面路由 Navigator.defaultRouteName,flutter 并不会将 initRoute 作为主页面,而是将默认路由入栈了之后再入栈 initRoute 对应的页面,所以如果在这之后再调用 popRoute,是会返回到主页面的
observers 是路由切换的监听列表,可以由外部传入,在路由切换的时候做些操作,比如 HeroController 就是一个监听者。
Navigator 是一个 StatefulWidget,在 NavigatorState 的 initState 中完成了将 initRoute 转换成 Route 的过程,并调用 push 将其入栈,生成 OverlayEntry,这个会继续传递给下层负责显示页面的 Overlay 负责展示。
在 push 的过程中,route 会被转换成 OverlayEntry 列表存放,每一个 OverlayEntry 中存储一个 WidgetBuilder,从某种角度来说,OverlayEntry 可以被认为是一个页面。所有的页面的协调、展示是通过 Overlay 完成的,Overlay 是一个类似于 Stack 的结构,它可以展示多个子结点。在它的 initState 中,
void initState() { super.initState(); insertAll(widget.initialEntries); }
会将 initialEntries 都存到 _entries 中。
Overlay 作为一个能够根据路由确定展示页面的控件,它的实现其实比较简单:
Widget build(BuildContext context) { // These lists are filled backwards. For the offstage children that // does not matter since they aren't rendered, but for the onstage // children we reverse the list below before adding it to the tree. final List<Widget> onstageChildren = <Widget>[]; final List<Widget> offstageChildren = <Widget>[]; bool onstage = true; for (int i = _entries.length - 1; i >= 0; i -= 1) { final OverlayEntry entry = _entries[i]; if (onstage) { onstageChildren.add(_OverlayEntry(entry)); if (entry.opaque) onstage = false; } else if (entry.maintainState) { offstageChildren.add(TickerMode(enabled: false, child: _OverlayEntry(entry))); } } return _Theatre( onstage: Stack( fit: StackFit.expand, children: onstageChildren.reversed.toList(growable: false), ), offstage: offstageChildren, ); }
build 函数中,将所有的 OverlayEntry 分成了可见与不可见两部分,每一个 OverlayEntry 生成一个 _OverlayEntry,这是一个 StatefulWidget,它的作用主要是负责控制当前页重绘,都被封装成 然后再用 _Theatre 展示就完了,在 _Theatre 中,可见/不可见的子结点都会转成 Element,但是在绘制的时候,_Theatre 对应的 _RenderTheatre 只会把可见的子结点绘制出来。
判断某一个 OverlayEntry 是否能够完全遮挡上一个 OverlayEntry 是通过它的 opaque 变量判断的,而 opaque 又是由 Route 给出的,在页面动画执行时,这个值会被设置成 false,然后在页面切换动画执行完了之后就会把 Route 的 opaque 参数赋值给它的 OverlayEntry,一般情况下,窗口对应的 Route 为 false,页面对应的 Route 为 true。
所以说在页面切换之后,上一个页面始终都是存在于 element 树中的,只不过在 RenderObject 中没有将其绘制出来,这一点在 Flutter Outline 工具里面也能够体现。从这个角度也可以理解为,在 flutter 中页面越多,需要处理的步骤就越多,虽然不需要绘制底部的页面,但是整个树的基本遍历还是会有的,这部分也算是开销。
flutter 中进行页面管理主要的依赖路由管理系统,它的入口就是 Navigator,它所管理的东西,本质上就是承载着用户页面的 Route,但是在 Navigator 中有很多函数是 XXXName 系列的,它们传的不是 Route,而是 RouteName,据个人理解,这个主要是方便开发引入的,我们可以在 MaterialApp/CupertinoApp 中直接传入路由表,每一个名字对应一个 WidgetBuilder,然后结合 pageRouteBuilder(这个可以自定义,不过 MaterialApp/CupertinoApp 都有默认实现,能够将 WidgetBuilder 转成 Route),便可以实现从 RouteName 到 Route 的转换。
Route<T> _routeNamed<T>(String name, { @required Object arguments, bool allowNull = false }) { if (allowNull && widget.onGenerateRoute == null) return null; final RouteSettings settings = RouteSettings( name: name, arguments: arguments, ); Route<T> route = widget.onGenerateRoute(settings) as Route<T>; if (route == null && !allowNull) { route = widget.onUnknownRoute(settings) as Route<T>; } return route; }
这个过程分三步,生成 RouteSettings,调用 onGenerateRoute 从路由表中拿到对应的路由,如果无命中,就调用 onUnknownRoute 给一个类似于 404 页面的东西。
onGenerateRoute 和 onUnknownRoute 在构建 Navigator 时传入,在 WidgetsApp 中实现,
Route<dynamic> _onGenerateRoute(RouteSettings settings) { final String name = settings.name; final WidgetBuilder pageContentBuilder = name == Navigator.defaultRouteName && widget.home != null ? (BuildContext context) => widget.home : widget.routes[name]; if (pageContentBuilder != null) { final Route<dynamic> route = widget.pageRouteBuilder<dynamic>( settings, pageContentBuilder, ); return route; } if (widget.onGenerateRoute != null) return widget.onGenerateRoute(settings); return null; }
如果是默认的路由会直接使用给定的 home 页面(如果有),否则就直接到路由表查,所以本质上这里的 home 页面更多的是一种象征,身份的象征,没有也无所谓。另外路由表主要的产出是 WidgetBuilder,它需要经过一次包装,成为 Route 才是成品,或者如果不想使用路由表这种,也可以直接实现 onGenerateRoute 函数,根据 RouteSetting 直接生成 Route,这个就不仅仅是返回 WidgetBuilder 这么简单了,需要自己包装。
onUnknownRoute 主要用于兜底,提供一个类似于 404 的页面,它也是需要直接返回 Route。
不知道从哪一个版本开始,flutter 的路由管理引入了状态,与之前每一个 push、pop 都单独实现不同,所有的路由切换操作都是用状态表示,同时所有的 route 都被封装成 _RouteEntry,它内部有着关于 Route 操作的实现,但都被划分为比较小的单元,且都依靠状态来执行。
状态是一个具有递进关系的枚举,每一个 _RouteEntry 都有一个变量存放当前的状态,在 _flushHistoryUpdates 中会遍历所有的 _RouteEntry 然后根据它们当前的状态进行处理,同时处理完成之后会切换它们的状态,再进行其他处理,这样的好处很明显,所有的路由都放在一起处理之后,整个流程会变得更加清晰,且能够很大程度上进行代码复用,比如 push 和 pushReplacement 两种操作,这在之前是需要在两个方法中单独实现的,而现在他们则可以放在一起单独处理,不同的只有后者比前者会多一个 remove 的操作。
关于 _flushHistoryUpdates 的处理步骤:
void _flushHistoryUpdates({bool rearrangeOverlay = true}) { assert(_debugLocked && !_debugUpdatingPage); // Clean up the list, sending updates to the routes that changed. Notably, // we don't send the didChangePrevious/didChangeNext updates to those that // did not change at this point, because we're not yet sure exactly what the // routes will be at the end of the day (some might get disposed). int index = _history.length - 1; _RouteEntry next; _RouteEntry entry = _history[index]; _RouteEntry previous = index > 0 ? _history[index - 1] : null; bool canRemoveOrAdd = false; // Whether there is a fully opaque route on top to silently remove or add route underneath. Route<dynamic> poppedRoute; // The route that should trigger didPopNext on the top active route. bool seenTopActiveRoute = false; // Whether we've seen the route that would get didPopNext. final List<_RouteEntry> toBeDisposed = <_RouteEntry>[]; while (index >= 0) { switch (entry.currentState) { // ... } index -= 1; next = entry; entry = previous; previous = index > 0 ? _history[index - 1] : null; } // Now that the list is clean, send the didChangeNext/didChangePrevious // notifications. _flushRouteAnnouncement(); // Announces route name changes. final _RouteEntry lastEntry = _history.lastWhere(_RouteEntry.isPresentPredicate, orElse: () => null); final String routeName = lastEntry?.route?.settings?.name; if (routeName != _lastAnnouncedRouteName) { RouteNotificationMessages.maybeNotifyRouteChange(routeName, _lastAnnouncedRouteName); _lastAnnouncedRouteName = routeName; } // Lastly, removes the overlay entries of all marked entries and disposes // them. for (final _RouteEntry entry in toBeDisposed) { for (final OverlayEntry overlayEntry in entry.route.overlayEntries) overlayEntry.remove(); entry.dispose(); } if (rearrangeOverlay) overlay?.rearrange(_allRouteOverlayEntries); }
以上是除了状态处理之外,一次 _flushHistoryUpdates 的全过程,首先它会遍历整个路由列表,根据状态做不同的处理,不过一般能够处理到的也不过最上层一两个,其余的多半是直接跳过的。处理完了之后,调用 _flushRouteAnnouncement 进行路由之间的前后链接,比如进行动画的联动等,
void _flushRouteAnnouncement() { int index = _history.length - 1; while (index >= 0) { final _RouteEntry entry = _history[index]; if (!entry.suitableForAnnouncement) { index -= 1; continue; } final _RouteEntry next = _getRouteAfter(index + 1, _RouteEntry.suitableForTransitionAnimationPredicate); if (next?.route != entry.lastAnnouncedNextRoute) { if (entry.shouldAnnounceChangeToNext(next?.route)) { entry.route.didChangeNext(next?.route); } entry.lastAnnouncedNextRoute = next?.route; } final _RouteEntry previous = _getRouteBefore(index - 1, _RouteEntry.suitableForTransitionAnimationPredicate); if (previous?.route != entry.lastAnnouncedPreviousRoute) { entry.route.didChangePrevious(previous?.route); entry.lastAnnouncedPreviousRoute = previous?.route; } index -= 1; } }
其实现也比较清晰,对每一个 _RouteEntry,通过调用 didChangeNext 和 didChangePrevious 来建立联系,比如在 didChangeNext 中绑定当前 Route 的 secondaryAnimation 和下一个路由的 animation 进行动画联动,再比如在 didChangePrevious 中获取上一个路由的 title,这个可以用于 CupertinoNavigationBar 中 back 按钮展示上一页面的 title。
然后调用 maybeNotifyRouteChange 发出通知,指定当前正在处于展示状态的 Route。
最后,遍历 toBeDisposed 执行 _RouteEntry 的销毁,这个列表会保存上面循环处理过程中,确定需要移出的 _RouteEntry,通过调用 OverlayEntry remove 函数(它会将自己从 Overlay 中移除)和 OverlayEntry dispose 函数(它会调用 Route 的 dispose,进行资源释放,比如 TransitionRoute 中 AnimationController 销毁)。
最后再看关于状态的处理,以下是所有的状态:
enum _RouteLifecycle { staging, // we will wait for transition delegate to decide what to do with this route. // // routes that are present: // add, // we'll want to run install, didAdd, etc; a route created by onGenerateInitialRoutes or by the initial widget.pages adding, // we'll want to run install, didAdd, etc; a route created by onGenerateInitialRoutes or by the initial widget.pages // routes that are ready for transition. push, // we'll want to run install, didPush, etc; a route added via push() and friends pushReplace, // we'll want to run install, didPush, etc; a route added via pushReplace() and friends pushing, // we're waiting for the future from didPush to complete replace, // we'll want to run install, didReplace, etc; a route added via replace() and friends idle, // route is being harmless // // routes that are not present: // // routes that should be included in route announcement and should still listen to transition changes. pop, // we'll want to call didPop remove, // we'll want to run didReplace/didRemove etc // routes should not be included in route announcement but should still listen to transition changes. popping, // we're waiting for the route to call finalizeRoute to switch to dispose removing, // we are waiting for subsequent routes to be done animating, then will switch to dispose // routes that are completely removed from the navigator and overlay. dispose, // we will dispose the route momentarily disposed, // we have disposed the route }
本质上这些状态分为三类,add(处理初始化的时候直接添加),push(与 add 类似,但是增加了动画的处理),pop(处理页面移出),remove(移出某个页面,相对 pop 没有动画,也没有位置限制)。
add 方式添加路由目前还只用于在应用初始化是添加初始化页面使用,对应的是在 NavigatorState 的 initState 中,
void initState() { super.initState(); for (final NavigatorObserver observer in widget.observers) { assert(observer.navigator == null); observer._navigator = this; } String initialRoute = widget.initialRoute; if (widget.pages.isNotEmpty) { _history.addAll( widget.pages.map((Page<dynamic> page) => _RouteEntry( page.createRoute(context), initialState: _RouteLifecycle.add, )) ); } else { // If there is no page provided, we will need to provide default route // to initialize the navigator. initialRoute = initialRoute ?? Navigator.defaultRouteName; } if (initialRoute != null) { _history.addAll( widget.onGenerateInitialRoutes( this, widget.initialRoute ?? Navigator.defaultRouteName ).map((Route<dynamic> route) => _RouteEntry( route, initialState: _RouteLifecycle.add, ), ), ); } _flushHistoryUpdates(); }
它会将从 onGenerateInitialRoutes 得来的所有初始路由转成 _RouteEntry 加入到 _history,此时它们的状态是 _RouteLifecycle.add,然后就是调用 _flushHistoryUpdates 进行处理。
void _flushHistoryUpdates({bool rearrangeOverlay = true}) { // ... while (index >= 0) { switch (entry.currentState) { case _RouteLifecycle.add: assert(rearrangeOverlay); entry.handleAdd( navigator: this, ); assert(entry.currentState == _RouteLifecycle.adding); continue; case _RouteLifecycle.adding: if (canRemoveOrAdd || next == null) { entry.didAdd( navigator: this, previous: previous?.route, previousPresent: _getRouteBefore(index - 1, _RouteEntry.isPresentPredicate)?.route, isNewFirst: next == null ); assert(entry.currentState == _RouteLifecycle.idle); continue; } break; case _RouteLifecycle.idle: if (!seenTopActiveRoute && poppedRoute != null) entry.handleDidPopNext(poppedRoute); seenTopActiveRoute = true; // This route is idle, so we are allowed to remove subsequent (earlier) // routes that are waiting to be removed silently: canRemoveOrAdd = true; break; // ... } index -= 1; next = entry; entry = previous; previous = index > 0 ? _history[index - 1] : null; } // ... }
add 路线主要会调用两个函数,handleAdd 和 didAdd,
void handleAdd({ @required NavigatorState navigator}) { assert(currentState == _RouteLifecycle.add); assert(navigator != null); assert(navigator._debugLocked); assert(route._navigator == null); route._navigator = navigator; route.install(); assert(route.overlayEntries.isNotEmpty); currentState = _RouteLifecycle.adding; }
install 函数可以看作是 Route 的初始化函数,比如在 ModalRoute 中创建 ProxyAnimation 来管理一些动画的执行,在 TransitionRoute 中创建了用于执行切换动画的 AnimationController,在 OverlayRoute 中完成了当前 Route 的 OverlayEntry 的创建及插入。createOverlayEntries 用于创建 OverlayEntry,其实现在 ModalRoute,
Iterable<OverlayEntry> createOverlayEntries() sync* { yield _modalBarrier = OverlayEntry(builder: _buildModalBarrier); yield OverlayEntry(builder: _buildModalScope, maintainState: maintainState); }
每一个 Route 都能生成两个 OverlayEntry,一个是 _buildModalBarrier,它可以生成两个页面之间的屏障,我们可以利用它给新页面设置一个背景色,同时还支持动画过渡,另一个是 _buildModalScope,它生成的就是这个页面真正的内容,外部会有多层包装,最底层就是 WidgetBuilder 创建的 widget。
大致看下两个函数的实现,
Widget _buildModalBarrier(BuildContext context) { Widget barrier; if (barrierColor != null && !offstage) { // changedInternalState is called if these update assert(barrierColor != _kTransparent); final Animation<Color> color = animation.drive( ColorTween( begin: _kTransparent, end: barrierColor, // changedInternalState is called if this updates ).chain(_easeCurveTween), ); barrier = AnimatedModalBarrier( color: color, dismissible: barrierDismissible, // changedInternalState is called if this updates semanticsLabel: barrierLabel, // changedInternalState is called if this updates barrierSemanticsDismissible: semanticsDismissible, ); } else { barrier = ModalBarrier( dismissible: barrierDismissible, // changedInternalState is called if this updates semanticsLabel: barrierLabel, // changedInternalState is called if this updates barrierSemanticsDismissible: semanticsDismissible, ); } return IgnorePointer( ignoring: animation.status == AnimationStatus.reverse || // changedInternalState is called when this updates animation.status == AnimationStatus.dismissed, // dismissed is possible when doing a manual pop gesture child: barrier, ); }
ModalBarrier 是两个 Route 之间的屏障,它可以通过颜色、拦截事件来表示两个 Route 的隔离,这些都是可以配置的,这里 IgnorePointer 的作用是为了在执行切换动画的时候无法响应时间。
Widget _buildModalScope(BuildContext context) { return _modalScopeCache ??= _ModalScope<T>( key: _scopeKey, route: this, // _ModalScope calls buildTransitions() and buildChild(), defined above ); } Widget build(BuildContext context) { return _ModalScopeStatus( route: widget.route, isCurrent: widget.route.isCurrent, // _routeSetState is called if this updates canPop: widget.route.canPop, // _routeSetState is called if this updates child: Offstage( offstage: widget.route.offstage, // _routeSetState is called if this updates child: PageStorage( bucket: widget.route._storageBucket, // immutable child: FocusScope( node: focusScopeNode, // immutable child: RepaintBoundary( child: AnimatedBuilder( animation: _listenable, // immutable builder: (BuildContext context, Widget child) { return widget.route.buildTransitions( context, widget.route.animation, widget.route.secondaryAnimation, IgnorePointer( ignoring: widget.route.animation?.status == AnimationStatus.reverse, child: child, ), ); }, child: _page ??= RepaintBoundary( key: widget.route._subtreeKey, // immutable child: Builder( builder: (BuildContext context) { return widget.route.buildPage( context, widget.route.animation, widget.route.secondaryAnimation, ); }, ), ), ), ), ), ), ), ); }
_ModalScope 需要承载用户界面的展示,它的 build 函数可以看到在 widget.route.buildPage 出用户定义的页面之上有很多层,可以一层一层看下大致作用:
以上就是一个页面中,从 Overlay(说是 Overlay 不是那么合理,但是在此先省略中间的 _Theatre 等) 往下的布局嵌套。新的 OverlayEntry 创建完成之后,会把它们都传递到 Overlay 中,且在这个过程中会调用 Overlay 的 setState 函数,请求重新绘制,在 Overlay 中实现新旧页面的切换。
以上是 install 的整个过程,执行完了之后把 currentState 置为 adding 返回。
此处有一点需要注意,while 循环会自上往下遍历所有的 _RouteEntry,但是当一个连续操作尚未完成时,它是不会去执行下一个 _RouteEntry 的,其实现就在于代码中的 continue 关键字,这个关键字会直接返回执行下一次循环,但是并没有更新当前 _RouteEntry,所以实际处理的还是同一个路由,这种一般用于 _RouteEntry 状态发生变化,且需要连续处理的时候,所以对于 add 来说,执行完了之后会立刻执行 adding 代码块,也就是 didAdd,
void didAdd({ @required NavigatorState navigator, @required bool isNewFirst, @required Route<dynamic> previous, @required Route<dynamic> previousPresent }) { route.didAdd(); currentState = _RouteLifecycle.idle; if (isNewFirst) { route.didChangeNext(null); } for (final NavigatorObserver observer in navigator.widget.observers) observer.didPush(route, previousPresent); }
Route 的 didAdd 函数表示这个路由已经添加完成,它会做一些收尾处理,比如在 TransitionRoute 中更新 AnimationController 的值到最大,并设置透明等。然后 didAdd 将状态置为 idle,并调用所有监听者的 didPush。idle 表示一个 _RouteEntry 已经处理完毕,后续只有 pop、replace 等操作才会需要重新处理,add 过程到这里也可以结束了。
Future<T> push<T extends Object>(Route<T> route) { assert(!_debugLocked); assert(() { _debugLocked = true; return true; }()); assert(route != null); assert(route._navigator == null); _history.add(_RouteEntry(route, initialState: _RouteLifecycle.push)); _flushHistoryUpdates(); assert(() { _debugLocked = false; return true; }()); _afterNavigation(route); return route.popped; }
push 过程就是将 Route 封装成 _RouteEntry 加入到 _history 中并调用 _flushHistoryUpdates,它的初始状态时 push,并在最后返回 route.popped,这是一个 Future 对象,可以用于前一个页面接收新的页面的返回结果,这个值是在当前路由 pop 的时候传递的。
void _flushHistoryUpdates({bool rearrangeOverlay = true}) { // ... while (index >= 0) { switch (entry.currentState) { // ... case _RouteLifecycle.push: case _RouteLifecycle.pushReplace: case _RouteLifecycle.replace: assert(rearrangeOverlay); entry.handlePush( navigator: this, previous: previous?.route, previousPresent: _getRouteBefore(index - 1, _RouteEntry.isPresentPredicate)?.route, isNewFirst: next == null, ); assert(entry.currentState != _RouteLifecycle.push); assert(entry.currentState != _RouteLifecycle.pushReplace); assert(entry.currentState != _RouteLifecycle.replace); if (entry.currentState == _RouteLifecycle.idle) { continue; } break; case _RouteLifecycle.pushing: // Will exit this state when animation completes. if (!seenTopActiveRoute && poppedRoute != null) entry.handleDidPopNext(poppedRoute); seenTopActiveRoute = true; break; case _RouteLifecycle.idle: if (!seenTopActiveRoute && poppedRoute != null) entry.handleDidPopNext(poppedRoute); seenTopActiveRoute = true; // This route is idle, so we are allowed to remove subsequent (earlier) // routes that are waiting to be removed silently: canRemoveOrAdd = true; break; // ... } index -= 1; next = entry; entry = previous; previous = index > 0 ? _history[index - 1] : null; } // ... }
这里将 push、pushReplace、replace 都归为了一类,它会先调用 handlePush,这个函数中其实包含了 add 过程中的 handleAdd、didAdd 两个函数的功能,比如调用 install、调用 didPush,不同的是,push/pushReplace 会有一个过渡的过程,即先执行切换动画,此时它的状态会变为 pushing,并在动画执行完时切到 idle 状态并调用 _flushHistoryUpdates 更新,而 replace 则直接调用 didReplace 完成页面替换,从这里看,这个应该是没有动画过渡的。后面还是一样,调用通知函数。
pop 的过程与上面两个不太一样,它在 NavigatorState.pop 中也有一些操作:
void pop<T extends Object>([ T result ]) { assert(!_debugLocked); assert(() { _debugLocked = true; return true; }()); final _RouteEntry entry = _history.lastWhere(_RouteEntry.isPresentPredicate); if (entry.hasPage) { if (widget.onPopPage(entry.route, result)) entry.currentState = _RouteLifecycle.pop; } else { entry.pop<T>(result); } if (entry.currentState == _RouteLifecycle.pop) { // Flush the history if the route actually wants to be popped (the pop // wasn't handled internally). _flushHistoryUpdates(rearrangeOverlay: false); assert(entry.route._popCompleter.isCompleted); } assert(() { _debugLocked = false; return true; }()); _afterNavigation<dynamic>(entry.route); }
就是调用 _RouteEntry 的 pop,在这个函数中它会调用 Route 的 didPop,完成返回值的传递、移出动画启动等。但是在 OverlayRoute 中:
bool didPop(T result) { final bool returnValue = super.didPop(result); assert(returnValue); if (finishedWhenPopped) navigator.finalizeRoute(this); return returnValue; }
finalizeRoute 的调用需要依赖 finishedWhenPopped 的值,这个值在子类中可以被修改,比如 TransitionRoute 中它就是 false,理解也很简单,在 TransitionRoute 中执行 didPop 之后也不能直接就销毁 Route,而是先要执行移出动画,而如果不需要执行动画,则可以直接调用,否则就在动画执行完再执行,这一点是通过监听动画状态实现的,在 TransitionRoute 中。
void finalizeRoute(Route<dynamic> route) { // FinalizeRoute may have been called while we were already locked as a // responds to route.didPop(). Make sure to leave in the state we were in // before the call. bool wasDebugLocked; assert(() { wasDebugLocked = _debugLocked; _debugLocked = true; return true; }()); assert(_history.where(_RouteEntry.isRoutePredicate(route)).length == 1); final _RouteEntry entry = _history.firstWhere(_RouteEntry.isRoutePredicate(route)); if (entry.doingPop) { // We were called synchronously from Route.didPop(), but didn't process // the pop yet. Let's do that now before finalizing. entry.currentState = _RouteLifecycle.pop; _flushHistoryUpdates(rearrangeOverlay: false); } assert(entry.currentState != _RouteLifecycle.pop); entry.finalize(); _flushHistoryUpdates(rearrangeOverlay: false); assert(() { _debugLocked = wasDebugLocked; return true; }()); }
在 finalizeRoute 中,它会判断是否正在 pop 过程中,如果是,就说明此刻是直接调用的 finalizeRoute,那就需要先执行 pop 状态的操作,再执行 dispose 操作,将状态切换到 dispose 进行处理,如果不是,就说明调用这个函数的时候,是动画执行完的时候,那么此刻 pop 状态处理已经完成,所以跳过了 pop 处理的步骤,如上。下面就看一下 pop 过程做的处理。
void _flushHistoryUpdates({bool rearrangeOverlay = true}) { // ... while (index >= 0) { switch (entry.currentState) { // ... case _RouteLifecycle.pop: if (!seenTopActiveRoute) { if (poppedRoute != null) entry.handleDidPopNext(poppedRoute); poppedRoute = entry.route; } entry.handlePop( navigator: this, previousPresent: _getRouteBefore(index, _RouteEntry.willBePresentPredicate)?.route, ); assert(entry.currentState == _RouteLifecycle.popping); canRemoveOrAdd = true; break; case _RouteLifecycle.popping: // Will exit this state when animation completes. break; case _RouteLifecycle.dispose: // Delay disposal until didChangeNext/didChangePrevious have been sent. toBeDisposed.add(_history.removeAt(index)); entry = next; break; case _RouteLifecycle.disposed: case _RouteLifecycle.staging: assert(false); break; } index -= 1; next = entry; entry = previous; previous = index > 0 ? _history[index - 1] : null; } // ... }
handlePop 将状态切换到 poping(动画执行过程),然后发出通知,而 poping 状态不作处理,因为这是一个过渡状态,在动画执行完之后会自动切换到 dispose 状态,同样的,上面的 pushing 状态也是,而在 dispose 分支中,就是将 _RouteEntry 从 _history 移除并加入到 toBeDisposed,然后在遍历结束之后统一销毁。
remove 的逻辑就是先从 _history 中找到一个跟传进来的一致的 _RouteEntry,将它的状态设为 remvoe,再调用 _flushHistoryUpdates。
void _flushHistoryUpdates({bool rearrangeOverlay = true}) { // ... while (index >= 0) { switch (entry.currentState) { // ... case _RouteLifecycle.remove: if (!seenTopActiveRoute) { if (poppedRoute != null) entry.route.didPopNext(poppedRoute); poppedRoute = null; } entry.handleRemoval( navigator: this, previousPresent: _getRouteBefore(index, _RouteEntry.willBePresentPredicate)?.route, ); assert(entry.currentState == _RouteLifecycle.removing); continue; case _RouteLifecycle.removing: if (!canRemoveOrAdd && next != null) { // We aren't allowed to remove this route yet. break; } entry.currentState = _RouteLifecycle.dispose; continue; case _RouteLifecycle.dispose: // Delay disposal until didChangeNext/didChangePrevious have been sent. toBeDisposed.add(_history.removeAt(index)); entry = next; break; case _RouteLifecycle.disposed: case _RouteLifecycle.staging: assert(false); break; } index -= 1; next = entry; entry = previous; previous = index > 0 ? _history[index - 1] : null; } // ... }
首先会调用 handleRemoval,调用通知,并将状态切换到 removing,在 removing 阶段再将状态切到 dispose,然后就是将其加入 toBeDisposed,所以整个过程中是不涉及动画的,一般只用来移出非正在展示的页面,否则还是推荐用 pop。
以上是路由机制的实现原理,就其整体而言,最给人耳目一新的就是状态管理的加入,通过将一个页面的进出划分到不同状态处理,是能够有效降低代码的复杂度的,不过从目前的结果来看,这一个过程执行的还不够精炼,比如状态的划分不够合理,从这些状态的设计来看,add/push/pop 都有对应的 ing 形式表示正在执行中,但是 adding 的存在我暂时没有看到必要性,还有就是感觉代码的组织上还是有点问题,比如 handleAdd 与 handPush 实际上还有很大部分的代码重复的,这部分不知道以后会不会优化。
另外还有一点感觉做的不到位,就是 _routeNamed 这个函数没有对外开放,而且并不是所有的路由操作都提供了 name 为入参的包装,比如 removeRoute,在这种情况下就没法很方便的调用。