欧美bbbwbbbw肥妇,免费乱码人妻系列日韩,一级黄片

flutter 路由機制的實現(xiàn)

 更新時間:2021年07月13日 10:35:41   作者:無若葉  
本文主要介紹 flutter 中的路由實現(xiàn)原理,包括初始化時的頁面加載、切換頁面的底層機制等。具有一定的參考價值,感興趣的小伙伴們可以參考一下

整個 flutter 應用的運行都只是基于原生應用中的一個 view,比如 android 中的 FlutterView,flutter 中的頁面切換依賴于它的路由機制,也就是以 Navigator 為中心的一套路由功能,使得它能夠完成與原生類似且能夠自定義的頁面切換效果。

下面將介紹 flutter 中的路由實現(xiàn)原理,包括初始化時的頁面加載、切換頁面的底層機制等。

實現(xiàn)基礎

flutter 應用的運行需要依賴 MaterialApp/CupertinoApp 這兩個 Widget,他們分別對應著 android/ios 的設計風格,同時也為應用的運行提供了一些基本的設施,比如與路由相關(guān)的主頁面、路由表等,再比如跟整體頁面展示相關(guān)的 theme、locale 等。

其中與路由相關(guān)的幾項配置有 home、routes、initialRoute、onGenerateRoute、onUnknownRoute,它們分別對應著主頁面 widget、路由表(根據(jù)路由找到對應 widget)、首次加載時的路由、路由生成器、未知路由代理(比如常見的 404 頁面)。

MaterialApp/CupertinoApp 的子結(jié)點都是 WidgetsApp,只不過他們給 WidgetsApp 傳入了不同的參數(shù),從而使得兩種 Widget 的界面風格不一致。Navigator 就是在 WidgetsApp 中創(chuàng)建的,

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 中第一個創(chuàng)建的就是 Navigator,主要看一下它的參數(shù),首先,_navigator 是一個 GlobalKey,使得 WidgetsApp 可以通過 key 調(diào)用 Navigator 的函數(shù)進行路由切換,也就是在 WidgetsBinding 中處理 native 的路由切換信息的時候,最終是由 WidgetsApp 完成的。另外這里的 _navigator 應該只在 WidgetsApp 中有使用,其他地方需要使用一般是直接調(diào)用 Navigator.of 獲取,這個函數(shù)會沿著 element 樹向上查找到 NavigatorState,所以在應用中切換路由是需要被 Navigator 包裹的,不過由于 WidgetsApp 中都有生成 Navigator,開發(fā)中也不必考慮這些。

另外,就是關(guān)于底層獲取上層 NavigatorElement 實例的方式,在 Element 樹中有兩種方式可以從底層獲取到上層的實例,一種方式是使用 InheritedWidget,另一種就是直接沿著樹向上查找(ancestorXXXOfExactType 系列),兩種方式的原理基本是一致的,只不過 InheritedWidget 在建立樹的過程中會一層層向下傳遞,而后者是使用的時候才向上查找,所以從這個角度來說使用 InheritedWidget 會高效些,但是 InheritedWidget 的優(yōu)勢不止如此,它是能夠在數(shù)據(jù)發(fā)生改變的時候通知所有依賴它的結(jié)點進行更新,這也是 ancestorXXXOfExactType 系列所沒有的。

然后 initialRoute 規(guī)定了初始化時候的頁面,由 WidgetsBinding.instance.window.defaultRouteName 和 widget.initialRoute 來決定,不過前者優(yōu)先級更高,因為這個是 native 中指定的,以 android 為例,在啟動 FlutterActivity 的時候可以傳入 route 字段指定初始化頁面。

onGenerateRoute 和 onUnknownRoute 是獲取 route 的策略,當 onGenerateRoute 沒有命中時會調(diào)用 onUnknownRoute 給定一個默認的頁面,onGenerateInitialRoutes 用于生產(chǎn)啟動應用時的路由列表,它有一個默認實現(xiàn) defaultGenerateInitialRoutes,會根據(jù)傳遞的 initialRouteName 選擇不同的 Route,如果傳入的 initialRouteName 并不是默認的主頁面路由 Navigator.defaultRouteName,flutter 并不會將 initRoute 作為主頁面,而是將默認路由入棧了之后再入棧 initRoute 對應的頁面,所以如果在這之后再調(diào)用 popRoute,是會返回到主頁面的

observers 是路由切換的監(jiān)聽列表,可以由外部傳入,在路由切換的時候做些操作,比如 HeroController 就是一個監(jiān)聽者。
Navigator 是一個 StatefulWidget,在 NavigatorState 的 initState 中完成了將 initRoute 轉(zhuǎn)換成 Route 的過程,并調(diào)用 push 將其入棧,生成 OverlayEntry,這個會繼續(xù)傳遞給下層負責顯示頁面的 Overlay 負責展示。

在 push 的過程中,route 會被轉(zhuǎn)換成 OverlayEntry 列表存放,每一個 OverlayEntry 中存儲一個 WidgetBuilder,從某種角度來說,OverlayEntry 可以被認為是一個頁面。所有的頁面的協(xié)調(diào)、展示是通過 Overlay 完成的,Overlay 是一個類似于 Stack 的結(jié)構(gòu),它可以展示多個子結(jié)點。在它的 initState 中,

void initState() {
  super.initState();
  insertAll(widget.initialEntries);
}

會將 initialEntries 都存到 _entries 中。

Overlay 作為一個能夠根據(jù)路由確定展示頁面的控件,它的實現(xiàn)其實比較簡單:

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 函數(shù)中,將所有的 OverlayEntry 分成了可見與不可見兩部分,每一個 OverlayEntry 生成一個 _OverlayEntry,這是一個 StatefulWidget,它的作用主要是負責控制當前頁重繪,都被封裝成 然后再用  _Theatre 展示就完了,在 _Theatre 中,可見/不可見的子結(jié)點都會轉(zhuǎn)成 Element,但是在繪制的時候,_Theatre 對應的 _RenderTheatre 只會把可見的子結(jié)點繪制出來。

判斷某一個 OverlayEntry 是否能夠完全遮擋上一個 OverlayEntry 是通過它的 opaque 變量判斷的,而 opaque 又是由 Route 給出的,在頁面動畫執(zhí)行時,這個值會被設置成 false,然后在頁面切換動畫執(zhí)行完了之后就會把 Route 的 opaque 參數(shù)賦值給它的 OverlayEntry,一般情況下,窗口對應的 Route 為 false,頁面對應的 Route 為 true。

所以說在頁面切換之后,上一個頁面始終都是存在于 element 樹中的,只不過在 RenderObject 中沒有將其繪制出來,這一點在 Flutter Outline 工具里面也能夠體現(xiàn)。從這個角度也可以理解為,在 flutter 中頁面越多,需要處理的步驟就越多,雖然不需要繪制底部的頁面,但是整個樹的基本遍歷還是會有的,這部分也算是開銷。

_routeNamed

flutter 中進行頁面管理主要的依賴路由管理系統(tǒng),它的入口就是 Navigator,它所管理的東西,本質(zhì)上就是承載著用戶頁面的 Route,但是在 Navigator 中有很多函數(shù)是 XXXName 系列的,它們傳的不是 Route,而是 RouteName,據(jù)個人理解,這個主要是方便開發(fā)引入的,我們可以在 MaterialApp/CupertinoApp 中直接傳入路由表,每一個名字對應一個 WidgetBuilder,然后結(jié)合 pageRouteBuilder(這個可以自定義,不過 MaterialApp/CupertinoApp 都有默認實現(xiàn),能夠?qū)?WidgetBuilder 轉(zhuǎn)成 Route),便可以實現(xiàn)從 RouteName 到 Route 的轉(zhuǎn)換。

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,調(diào)用 onGenerateRoute 從路由表中拿到對應的路由,如果無命中,就調(diào)用 onUnknownRoute 給一個類似于 404 頁面的東西。

onGenerateRoute 和 onUnknownRoute 在構(gòu)建 Navigator 時傳入,在 WidgetsApp 中實現(xiàn),

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 頁面(如果有),否則就直接到路由表查,所以本質(zhì)上這里的 home 頁面更多的是一種象征,身份的象征,沒有也無所謂。另外路由表主要的產(chǎn)出是 WidgetBuilder,它需要經(jīng)過一次包裝,成為 Route 才是成品,或者如果不想使用路由表這種,也可以直接實現(xiàn) onGenerateRoute 函數(shù),根據(jù) RouteSetting 直接生成 Route,這個就不僅僅是返回 WidgetBuilder 這么簡單了,需要自己包裝。

onUnknownRoute 主要用于兜底,提供一個類似于 404 的頁面,它也是需要直接返回 Route。

_flushHistoryUpdates

不知道從哪一個版本開始,flutter 的路由管理引入了狀態(tài),與之前每一個 push、pop 都單獨實現(xiàn)不同,所有的路由切換操作都是用狀態(tài)表示,同時所有的 route 都被封裝成 _RouteEntry,它內(nèi)部有著關(guān)于 Route 操作的實現(xiàn),但都被劃分為比較小的單元,且都依靠狀態(tài)來執(zhí)行。

狀態(tài)是一個具有遞進關(guān)系的枚舉,每一個 _RouteEntry 都有一個變量存放當前的狀態(tài),在 _flushHistoryUpdates 中會遍歷所有的 _RouteEntry 然后根據(jù)它們當前的狀態(tài)進行處理,同時處理完成之后會切換它們的狀態(tài),再進行其他處理,這樣的好處很明顯,所有的路由都放在一起處理之后,整個流程會變得更加清晰,且能夠很大程度上進行代碼復用,比如 push 和 pushReplacement 兩種操作,這在之前是需要在兩個方法中單獨實現(xiàn)的,而現(xiàn)在他們則可以放在一起單獨處理,不同的只有后者比前者會多一個 remove 的操作。

關(guān)于 _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);
}

以上是除了狀態(tài)處理之外,一次 _flushHistoryUpdates 的全過程,首先它會遍歷整個路由列表,根據(jù)狀態(tài)做不同的處理,不過一般能夠處理到的也不過最上層一兩個,其余的多半是直接跳過的。處理完了之后,調(diào)用 _flushRouteAnnouncement 進行路由之間的前后鏈接,比如進行動畫的聯(lián)動等,

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;
  }
}

其實現(xiàn)也比較清晰,對每一個 _RouteEntry,通過調(diào)用 didChangeNext 和 didChangePrevious 來建立聯(lián)系,比如在 didChangeNext 中綁定當前 Route 的 secondaryAnimation 和下一個路由的 animation 進行動畫聯(lián)動,再比如在 didChangePrevious 中獲取上一個路由的 title,這個可以用于 CupertinoNavigationBar 中 back 按鈕展示上一頁面的 title。
然后調(diào)用 maybeNotifyRouteChange 發(fā)出通知,指定當前正在處于展示狀態(tài)的 Route。

最后,遍歷 toBeDisposed 執(zhí)行 _RouteEntry 的銷毀,這個列表會保存上面循環(huán)處理過程中,確定需要移出的 _RouteEntry,通過調(diào)用 OverlayEntry remove 函數(shù)(它會將自己從 Overlay 中移除)和 OverlayEntry dispose 函數(shù)(它會調(diào)用 Route 的 dispose,進行資源釋放,比如 TransitionRoute 中 AnimationController 銷毀)。

最后再看關(guān)于狀態(tài)的處理,以下是所有的狀態(tài):

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
}

本質(zhì)上這些狀態(tài)分為三類,add(處理初始化的時候直接添加),push(與 add 類似,但是增加了動畫的處理),pop(處理頁面移出),remove(移出某個頁面,相對 pop 沒有動畫,也沒有位置限制)。

add

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 得來的所有初始路由轉(zhuǎn)成 _RouteEntry 加入到 _history,此時它們的狀態(tài)是 _RouteLifecycle.add,然后就是調(diào)用 _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 路線主要會調(diào)用兩個函數(shù),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 函數(shù)可以看作是 Route 的初始化函數(shù),比如在 ModalRoute 中創(chuàng)建 ProxyAnimation 來管理一些動畫的執(zhí)行,在 TransitionRoute 中創(chuàng)建了用于執(zhí)行切換動畫的 AnimationController,在 OverlayRoute 中完成了當前 Route 的 OverlayEntry 的創(chuàng)建及插入。createOverlayEntries 用于創(chuàng)建 OverlayEntry,其實現(xiàn)在 ModalRoute,

Iterable<OverlayEntry> createOverlayEntries() sync* {
  yield _modalBarrier = OverlayEntry(builder: _buildModalBarrier);
  yield OverlayEntry(builder: _buildModalScope, maintainState: maintainState);
}

每一個 Route 都能生成兩個 OverlayEntry,一個是 _buildModalBarrier,它可以生成兩個頁面之間的屏障,我們可以利用它給新頁面設置一個背景色,同時還支持動畫過渡,另一個是 _buildModalScope,它生成的就是這個頁面真正的內(nèi)容,外部會有多層包裝,最底層就是 WidgetBuilder 創(chuàng)建的 widget。

大致看下兩個函數(shù)的實現(xiàn),

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 的作用是為了在執(zhí)行切換動畫的時候無法響應時間。

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 函數(shù)可以看到在 widget.route.buildPage 出用戶定義的頁面之上有很多層,可以一層一層看下大致作用:

  • _ModalScopeStatus,繼承自 InheritedWidget,用于給底層結(jié)點提供數(shù)據(jù)
  • Offstage,可以通過 offstage 變量控制是否繪制
  • PageStorage,它提供了一種存儲策略,也就是 PageStorageBucket,這個類可以給某一個 BuildContext 綁定特定的數(shù)據(jù),支持寫入和讀取,可用于某一個 widget 的狀態(tài)存儲等
  • FocusScope,用于焦點管理用,一般只有獲取焦點的控件才能接收到按鍵信息等
  • RepaintBoundary,控制重繪范圍,意在減少不必要的重繪
  • AnimatedBuilder,動畫控制 Widget,會根據(jù) animation 進行 rebuild
  • widget.route.buildTransitions,它在不同的 Route 中可以有不同的實現(xiàn),比如 Android 的默認實現(xiàn)是自下向上漸入,ios 的默認實現(xiàn)是自右向左滑動,另外也可以通過自定義 Route 或自定義 ThemeData 實現(xiàn)自定義的切換動畫,還有一點需要說明,Route 中的動畫分為 animation 和 secondaryAnimation,其中 animation 定義了自己 push 時的動畫,secondaryAnimation 定義的是新頁面 push 時自己的動畫,舉個例子,在 ios 風格中,新頁面自右向左滑動,上一個頁面也會滑動,此時控制上一個頁面滑動的動畫就是 secondaryAnimation
  • IgnorePointer,同樣是用于頁面切換動畫執(zhí)行中,禁止用戶操作
  • RepaintBoundary,這里的考量應該是考慮到上層有一個動畫執(zhí)行,所以這里包一下避免固定內(nèi)容重繪
  • Builder,Builder 的唯一作用應該是提供 BuildContext,雖然說每一個 build 函數(shù)都有 BuildContext 參數(shù),但這個是當前 Widget 的,而不是直屬上級的,這可能有點抽象,比如說下面的 buildPage 需要使用 BuildContext 作為參數(shù),那么如果它需要使用 context 的 ancestorStateOfType 的話,實際上就是從 _ModalScopeState 開始向上查找,而不是從 Builder 開始向上查找
  • widget.route.buildPage,這個函數(shù)內(nèi)部就是使用 Route 的 WidgetBuilder 創(chuàng)建用戶界面,當然不同的 Route 可能還會在這里再次進行包裝

以上就是一個頁面中,從 Overlay(說是 Overlay 不是那么合理,但是在此先省略中間的 _Theatre 等) 往下的布局嵌套。新的 OverlayEntry 創(chuàng)建完成之后,會把它們都傳遞到 Overlay 中,且在這個過程中會調(diào)用 Overlay 的 setState 函數(shù),請求重新繪制,在 Overlay 中實現(xiàn)新舊頁面的切換。

以上是 install 的整個過程,執(zhí)行完了之后把 currentState 置為 adding 返回。

此處有一點需要注意,while 循環(huán)會自上往下遍歷所有的 _RouteEntry,但是當一個連續(xù)操作尚未完成時,它是不會去執(zhí)行下一個 _RouteEntry 的,其實現(xiàn)就在于代碼中的 continue 關(guān)鍵字,這個關(guān)鍵字會直接返回執(zhí)行下一次循環(huán),但是并沒有更新當前 _RouteEntry,所以實際處理的還是同一個路由,這種一般用于 _RouteEntry 狀態(tài)發(fā)生變化,且需要連續(xù)處理的時候,所以對于 add 來說,執(zhí)行完了之后會立刻執(zhí)行 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 函數(shù)表示這個路由已經(jīng)添加完成,它會做一些收尾處理,比如在 TransitionRoute 中更新 AnimationController 的值到最大,并設置透明等。然后 didAdd 將狀態(tài)置為 idle,并調(diào)用所有監(jiān)聽者的 didPush。idle 表示一個 _RouteEntry 已經(jīng)處理完畢,后續(xù)只有 pop、replace 等操作才會需要重新處理,add 過程到這里也可以結(jié)束了。

push

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 中并調(diào)用 _flushHistoryUpdates,它的初始狀態(tài)時 push,并在最后返回 route.popped,這是一個 Future 對象,可以用于前一個頁面接收新的頁面的返回結(jié)果,這個值是在當前路由 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 都歸為了一類,它會先調(diào)用 handlePush,這個函數(shù)中其實包含了 add 過程中的 handleAdd、didAdd 兩個函數(shù)的功能,比如調(diào)用 install、調(diào)用 didPush,不同的是,push/pushReplace 會有一個過渡的過程,即先執(zhí)行切換動畫,此時它的狀態(tài)會變?yōu)?pushing,并在動畫執(zhí)行完時切到 idle 狀態(tài)并調(diào)用 _flushHistoryUpdates 更新,而 replace 則直接調(diào)用 didReplace 完成頁面替換,從這里看,這個應該是沒有動畫過渡的。后面還是一樣,調(diào)用通知函數(shù)。

pop

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);
}

就是調(diào)用 _RouteEntry 的 pop,在這個函數(shù)中它會調(diào)用 Route 的 didPop,完成返回值的傳遞、移出動畫啟動等。但是在  OverlayRoute 中:

bool didPop(T result) {
  final bool returnValue = super.didPop(result);
  assert(returnValue);
  if (finishedWhenPopped)
    navigator.finalizeRoute(this);
  return returnValue;
}

finalizeRoute 的調(diào)用需要依賴 finishedWhenPopped 的值,這個值在子類中可以被修改,比如 TransitionRoute 中它就是 false,理解也很簡單,在 TransitionRoute 中執(zhí)行 didPop 之后也不能直接就銷毀 Route,而是先要執(zhí)行移出動畫,而如果不需要執(zhí)行動畫,則可以直接調(diào)用,否則就在動畫執(zhí)行完再執(zhí)行,這一點是通過監(jiān)聽動畫狀態(tài)實現(xiàn)的,在 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 過程中,如果是,就說明此刻是直接調(diào)用的 finalizeRoute,那就需要先執(zhí)行 pop 狀態(tài)的操作,再執(zhí)行 dispose 操作,將狀態(tài)切換到 dispose 進行處理,如果不是,就說明調(diào)用這個函數(shù)的時候,是動畫執(zhí)行完的時候,那么此刻 pop 狀態(tài)處理已經(jīng)完成,所以跳過了 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 將狀態(tài)切換到 poping(動畫執(zhí)行過程),然后發(fā)出通知,而 poping 狀態(tài)不作處理,因為這是一個過渡狀態(tài),在動畫執(zhí)行完之后會自動切換到 dispose 狀態(tài),同樣的,上面的 pushing 狀態(tài)也是,而在 dispose 分支中,就是將 _RouteEntry 從 _history 移除并加入到 toBeDisposed,然后在遍歷結(jié)束之后統(tǒng)一銷毀。

remove

remove 的邏輯就是先從 _history 中找到一個跟傳進來的一致的 _RouteEntry,將它的狀態(tài)設為 remvoe,再調(diào)用 _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;
  }
  // ...
}

首先會調(diào)用 handleRemoval,調(diào)用通知,并將狀態(tài)切換到 removing,在 removing 階段再將狀態(tài)切到 dispose,然后就是將其加入 toBeDisposed,所以整個過程中是不涉及動畫的,一般只用來移出非正在展示的頁面,否則還是推薦用 pop。

總結(jié)

以上是路由機制的實現(xiàn)原理,就其整體而言,最給人耳目一新的就是狀態(tài)管理的加入,通過將一個頁面的進出劃分到不同狀態(tài)處理,是能夠有效降低代碼的復雜度的,不過從目前的結(jié)果來看,這一個過程執(zhí)行的還不夠精煉,比如狀態(tài)的劃分不夠合理,從這些狀態(tài)的設計來看,add/push/pop 都有對應的 ing 形式表示正在執(zhí)行中,但是 adding 的存在我暫時沒有看到必要性,還有就是感覺代碼的組織上還是有點問題,比如 handleAdd 與 handPush 實際上還有很大部分的代碼重復的,這部分不知道以后會不會優(yōu)化。

另外還有一點感覺做的不到位,就是 _routeNamed 這個函數(shù)沒有對外開放,而且并不是所有的路由操作都提供了 name 為入?yún)⒌陌b,比如 removeRoute,在這種情況下就沒法很方便的調(diào)用。

到此這篇關(guān)于flutter 路由機制的實現(xiàn)的文章就介紹到這了,更多相關(guān)flutter 路由機制內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!

相關(guān)文章

最新評論