在開發具有多個標簽頁或屏幕的Flutter應用程序時，你將會面臨的一個最常見的問題就是：如何在導航過程中保持狀態的一致性，同時又不會破壞用戶體驗。當用戶切換標簽頁時，如果突然丟失了滾動位置、表單輸入內容或之前加載的數據，這個問題就會變得非常明顯。
這個問題的產生并不是因為Flutter效率低下，而通常是由于在導航過程中組件會被重新構建所導致的。
一個實用且常常被忽視的解決方案就是使用IndexedStack組件。它允許你在切換屏幕的同時保持它們的狀態不變，從而使得導航過程更加流暢，性能也更好。
本文將深入探討IndexedStack的工作原理、它的重要性以及如何在實際應用程序中正確使用它。
目錄
先決條件
為了能夠順利跟隨學習流程，你應當已經了解Flutter部件的工作原理，尤其是StatelessWidget與StatefulWidget之間的區別。
你還應該熟悉Scaffold、BottomNavigationBar，以及當狀態發生變化時Flutter是如何重新構建部件的。
最后，對部件樹的工作方式有一個基本的了解，將有助于你更清晰地理解相關概念。
標簽頁導航存在的真正問題
實現標簽頁導航的一種常見方法是這樣的：
body: _tabs[_currentIndex],乍一看，這種方式似乎很合理，也適用于簡單的情況。但實際上，每當索引發生變化時，系統內部都會發生一些重要的操作。
Flutter會將當前顯示的部件從組件樹中移除，然后重新創建一個新的部件。這意味著之前的標簽頁會被徹底銷毀，新的標簽頁會從頭開始構建。
這種做法會導致許多問題：滾動位置會丟失，文本輸入框的內容會重置，網絡請求可能會再次被觸發。總體來說，這種體驗會讓用戶感到不一致，甚至有些令人沮喪。
理解默認行為
如果沒有任何狀態保存機制，切換標簽頁時的操作過程如下：
用戶選擇一個新的標簽頁
當前標簽頁會被從內存中清除
新的標簽頁會重新被創建
在任何時候，內存中只會有一個標簽頁被保留下來，其他所有的標簽頁都會被丟棄。
了解IndexedStack的工作原理
IndexedStack徹底改變了這種行為模式。它不會重新構建所有部件，而是讓它們都保持活躍狀態，只改變哪個部件是可見的。
在內部，它會存儲所有的子部件，并通過索引來決定哪個部件應該被顯示出來。
下面是一個簡單的思維模型，用來說明它的運作方式：
IndexedStack
├── 標簽頁0
├── 標簽頁1
├── 標簽頁2
└── 標簽頁3
只有其中一個標簽頁是可見的
所有標簽頁都保留在內存中這意味著，當你切換標簽頁時，沒有任何部件會被銷毀，只是界面的顯示狀態發生了變化而已。
為什么IndexedStack能提升用戶體驗
最直接的好處就是狀態能夠被保留下來。如果用戶在某個標簽頁中滾動到列表的中間位置，然后切換到另一個標簽頁，再返回原來的標簽頁，之前的滾動位置會完好無損地保留下來。
對于表單輸入、動畫效果，以及任何原本會被重置的用戶界面狀態來說，這一機制也同樣適用。
另一個好處是性能更加穩定。由于部件不會被反復重新構建，應用程序就可以避免進行不必要的操作。當標簽頁中包含復雜的用戶界面元素或需要執行耗時較長的操作（比如API調用）時，這一點尤為重要。
構建任務管理器示例
為了使這個例子更具實用性，讓我們來看一個擁有四個標簽頁的任務管理器應用程序。這些標簽頁分別代表“今日任務”、“即將進行的任務”、“已完成的任務”以及“設置”。
以下是使用IndexedStack實現的完整代碼示例：
import 'package:flutter/material.dart';
void main() {
runApp(const MyApp());
}
class MyApp extends StatelessWidget {
const MyApp({super.key});
@override
Widget build(BuildContext context) {
return MaterialApp(
title: '任務管理器',
theme: ThemeData(
primarySwatch: Colors.blue,
),
home: const TaskManagerScreen(),
);
}
}
class TaskManagerScreen extends StatelessWidget {
const TaskManagerScreen({super.key});
@override
State createState() => _TaskManagerScreenState();
}
class _TaskManagerScreenState extends State {
int _currentIndex = 0;
final List _tabs = [
TodayTasksTab(),
UpcomingTasksTab(),
CompletedTasksTab(),
SettingsTab(),
];
void _onTabTapped(int index) {
setState(() {
_currentIndex = index;
});
}
@override
Widget build(BuildContext context) {
return Scaffold(
appBar: AppBar(
title: const Text('任務管理器'),
),
body: IndexedStack(
index: _currentIndex,
children: _tabs,
),
bottomNavigationBar: BottomNavigationBar(
currentIndex: _currentIndex,
onTap: _onTabTapped,
items: const [
BottomNavigationBarItem(
icon: Icon'icon_today),
label: '今日任務',
),
BottomNavigationBarItem(
icon: Icon'icon.upcoming),
label: '即將進行的任務',
),
BottomNavigationBarItem(
icon: Icon'icon.done),
label: '已完成的任務',
),
BottomNavigationBarItem(
icon: Icon'icon.settings),
label: '設置',
),
],
),
);
}
}
class TodayTasksTab extends StatelessWidget {
@override
Widget build(BuildContext context) {
return ListView.builder(
itemCount: 50,
itemBuilder: (context, index) {
return ListTile(title: Text('今日任務 $index'));
},
);
}
}
class UpcomingTasksTab extends StatelessWidget {
@override
Widget build(BuildContext context) {
return Center(child: Text('即將進行的任務'));
}
}
class CompletedTasksTab extends StatelessWidget {
@override
Widget build(BuildContext context) {
return Center(child: Text('已完成的任務'));
}
}
class SettingsTab extends StatelessWidget {
@override
Widget build(BuildContext context) {
return Center(child: Text('設置'));
}
}
這個Flutter應用程序首先運行MyApp，從而創建一個包含標題、主題的MaterialApp，并將TaskManagerScreen設置為首頁。在這個頁面中，一個有狀態的組件會管理當前選中的標簽頁索引，并使用IndexedStack來顯示四個標簽頁中的一個，同時確保所有標簽頁都保留在內存中。
BottomNavigationBar允許用戶在各個標簽頁之間切換，而每個標簽頁實際上都是一個獨立的無狀態組件，它會自行渲染相應的內容（例如，用于顯示今日任務的滾動列表，或用于展示其他內容的簡單文本視圖）。
處理每個標簽頁的獨立導航功能
你會很快遇到這樣一個限制：雖然IndexedStack能夠保留每個標簽頁的狀態，但它并不會自動為每個標簽頁分配獨立的導航系統。
在實際應用中，每個標簽頁通常都需要擁有自己的內部導航機制。例如，在任務管理器中，“今日”標簽頁可能會跳轉到任務詳情頁面，而“設置”標簽頁則會跳轉到偏好設置頁面。這些導航流程不應該互相干擾。
為了解決這個問題，你可以將IndexedStack與每個標簽頁對應的Navigator結合使用。
概念結構
IndexedStack
├── Navigator (標簽頁0)
│ ├── 頁面A
│ └── 頁面B
├── Navigator (標簽頁1)
├── Navigator (標簽頁2)
└── Navigator (標簽頁3)
現在，每個標簽頁都可以獨立地管理自己的導航歷史記錄。
實現方式
class TaskManagerScreen extends StatefulWidget {
const TaskManagerScreen({super.key});
@override
State createState() => _TaskManagerScreenState();
}
class _TaskManagerScreenState extends State {
int _currentIndex = 0;
final _navigatorKeys = List.generate(
4,
(index) => GlobalKey,
);
void _onTabTapped(int index) {
if (_currentIndex == index) {
_navigatorKeys[index]
.currentState
?.popUntil((route) => route.isFirst);
} else {
setState(() {
_currentIndex = index;
});
}
}
Widget _buildNavigator(int index, Widget child) {
return Navigator(
key: _navigatorKeys[index],
onGenerateRoute: (routeSettings) {
return MaterialPageRoute(
builder: (_) => child,
);
},
);
}
@override
Widget build(BuildContext context) {
final tabs = [
_buildNavigator(0, const TodayTasksTab()),
_buildNavigator(1, const UpcomingTasksTab()),
_buildNavigator(2, const CompletedTasksTab()),
_buildNavigator(3, const SettingsTab()),
];
return Scaffold(
body: IndexedStack(
index: _currentIndex,
children: tabs,
),
bottomNavigationBar: BottomNavigationBar(
currentIndex: _currentIndex,
onTap: _onTabTapped,
items: const [
BottomNavigationBarItem'icon: IconIcons.today), label: '今日',
BottomNavigationBarItem ICON: IconIcons.upcoming), label: '即將進行的任務',
BottomNavigationBarItem(icon: IconIcons.done), label: '已完成的任務',
BottomNavigationBarItemICON: IconIcons.settings), label: '設置',
],
),
);
}
}
TaskManagerScreen的這種實現方式使用了一個具有狀態功能的組件來管理標簽頁導航：它通過維護當前的標簽頁索引，并為每個標簽頁使用唯一的GlobalKey來創建一個獨立的Navigator》，從而確保每個標簽頁都能擁有自己的獨立導航棧。
_onTabTapped方法會在用戶點擊標簽頁時切換標簽頁，或者如果再次點擊當前標簽頁，則將其導航棧重置到起始狀態。IndexedStack能夠保證所有標簽頁的導航組件都保留在內存中，而只有被選中的標簽頁才會顯示出來，這樣一來，用戶的瀏覽狀態就能得到保留，標簽頁之間的切換也會非常流暢。
這種實現方式能解決什么問題
現在，每個標簽頁都像一個獨立的小應用一樣運行。在一個標簽頁內進行操作不會影響到其他標簽頁。當用戶切換標簽頁后再返回時，他們會回到上次離開的位置，包括那些嵌套的界面。
這種設計模式被廣泛應用于銀行應用、社交平臺以及數據面板等實際生產環境中。
將IndexedStack與狀態管理結合使用
開發者們常常會犯一個錯誤，那就是將IndexedStack當作一種完整的狀態管理解決方案來使用。但實際上并非如此。
IndexedStack確實能夠保留組件的狀態，但它并不能負責處理業務邏輯或共享數據。
對于那些需要擴展性的應用程序來說，仍然應該使用像BLoC、Provider或者Riverpod這樣的專業狀態管理工具。
使用BLoC的示例
每個標簽頁都可以獨立接收自己的數據流，同時這些數據也會被保留在內存中。
class TodayTasksTab extends StatelessWidget {
const TodayTasksTab({super.key});
@override
Widget build(BuildContext context) {
return StreamBuilder<List<>String>>>(
stream: getTasksStream(),
builder: (context, snapshot) {
if (!snapshot.hasData) {
return const Center(child: CircularProgressIndicator());
}
final tasks = snapshot.data!;
return ListView.builder(
itemCount: tasks.length,
itemBuilder: (context, index) {
return ListTile(title: Text(tasks[index]));
},
);
},
);
}
}
由于標簽頁不會被重新創建，因此數據流的訂閱狀態也會保持穩定，不會出現不必要的重啟情況。
性能方面的考慮
在這里，開發者需要謹慎行事。IndexedStack會保留所有組件的狀態，這意味著每個標簽頁都會增加內存占用量。
內部工作原理
所有的子組件都只會被構建一次，
之后就會一直保持掛載狀態，
只有可見性會發生變化。這種設計在提升交互體驗方面非常有效，但在占用內存方面卻不一定理想。
何時會出現問題
如果每個標簽頁都包含大量的組件，比如長列表、圖片或者復雜的動畫效果，那么內存消耗量就會顯著增加。
在極端情況下，這可能會導致低端設備出現幀率下降甚至應用程序崩潰。
實際應用策略
對于數量較少的核心標簽頁，可以使用IndexedStack。通常三到五個標簽頁是比較合適的范圍。
如果你發現需要添加更多的頁面，那么應該重新考慮導航結構，而不是強行將所有內容都納入同一個棧中。
常見錯誤
一個常見的誤解是認為IndexedStack會延遲組件的生成。實際上并非如此，所有的子組件都會立即被創建出來。
另一個錯誤是將IndexedStack與那些需要重新構建組件的邏輯混合使用。由于組件會被保留下來，因此某些生命周期方法的行為可能會發生異常。
開發者有時還會忘記，使用IndexedStack會導致內存被持續占用，從而在后續引發性能問題（正如我們剛才討論的那樣）。
Navigator → 負責控制頁面切換 IndexedStack → 負責控制持久組件的可見性 狀態管理 → 負責管理數據和邏輯流程
一旦你把這些功能區分開來，你的應用程序架構就會變得更加清晰，也更容易進行擴展。
可視化對比
要想真正理解這兩種方式之間的區別，就需要對它們進行比較。
不使用IndexedStack時：
切換標簽頁
→ 當前頁面被銷毀
→ 新頁面被重新創建
→ 數據狀態丟失使用IndexedStack時：
切換標簽頁
→ 所有頁面都保持存活狀態
→ 只有相關組件的可見性會發生變化
→ 數據狀態保持不變重要的權衡因素
需要記住的是，IndexedStack》會同時將所有子組件保留在內存中。
對于數量較少的標簽頁來說，這種設計通常沒有問題；但如果每個標簽頁都包含大量的組件或龐大的數據量，那么內存使用量就會顯著增加。
因此，選擇哪種方式并不只是為了方便性，而是要根據具體的應用場景來挑選最適合的工具。
如果你的標簽頁體積較小且需要保留狀態信息，IndexedStack是一個不錯的選擇；但如果標簽頁內容較多且很少被訪問，那么重新構建這些組件可能反而更合適。
總結來說：
-
當每個標簽頁都有獨立的狀態，并且用戶需要頻繁地在它們之間切換時，
IndexedStack是非常理想的選擇。它在儀表盤、任務管理器、金融應用以及社交應用中尤為有用，因為這些場景非常強調連續性。 -
如果你的應用程序包含大量的頁面，或者每個頁面都會占用大量內存，那么讓所有頁面都保持存活狀態可能會導致效率低下。在這種情況下，使用結合了適當狀態管理機制的導航系統（如BLoC、Provider或Riverpod）可能會是更好的解決方案。
結論
IndexedStack表面上看很簡單，但它的真正優勢在于那些用戶體驗至關重要的復雜應用中。它能夠避免不必要的重新構建操作，保持用戶界面的狀態不變，從而讓交互過程更加流暢。
不過請務必謹慎使用它——它并不能替代導航系統或狀態管理機制，而只是作為一種補充工具。
如果你能將其與嵌套導航結構及恰當的狀態管理策略正確結合在一起，那么你就能構建出一種對用戶來說使用起來非常順滑、且隨著應用程序的發展依然易于維護的架構。
