Flutter 路由原理解析

時間  2019-11-06
標籤 flutter 路由 原理 解析 欄目 系統網絡 简体版
原文   原文鏈接

前言

這一次，我嘗試以不貼一行源代碼的方式向你介紹 Flutter 路由的實現原理，同時爲了提升你閱讀源碼的積極性，除了原理介紹之外，又補充了兩個新的模塊：從源碼中學習到的編程技巧，以及 閱讀源碼以後對實際應用開發帶來的幫助。編程

但願這樣1+2的模式，能夠誘導你以很是積極的心態，很輕鬆的學習到 Flutter 路由相關的知識。安全

固然，不貼一行源代碼，純白話的講解必然會隱藏不少細節知識，渴望知識的你必定不會知足的，因此我在原理介紹結束以後，又補充了一篇番外：貼了大段大段的純源碼解析的《Flutter 路由源碼解析》，知道大概原理的你再去讀源碼，必定會輕鬆不少吧，但願這樣的模式能夠有效的幫助到你！bash

本文大綱：app

  • Flutter 路由實現框架

  • Navigator 源碼裏很是值得學習的 Flutter 編程技巧less

    • Flutter中的「命令式編程」：對象引用查找與遠程局部更新
    • 元素自治
    • 私有類包裝：隔離邏輯與Widget

  • 閱讀 Navigator 源碼以後對實際應用開發的幫助ide

    • 路由動態監聽
    • 路由監聽中，識別 彈窗 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 樹的根部：post

// 僞代碼
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 Tree

哈哈，這個圖乍一眼看有點懵，陌生的 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上層，固然不會獲得你想要的結果啦~

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程