在开发具有多个标签页或屏幕的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表面上看很简单，但它的真正优势在于那些用户体验至关重要的复杂应用中。它能够避免不必要的重新构建操作，保持用户界面的状态不变，从而让交互过程更加流畅。
不过请务必谨慎使用它——它并不能替代导航系统或状态管理机制，而只是作为一种补充工具。
如果你能将其与嵌套导航结构及恰当的状态管理策略正确结合在一起，那么你就能构建出一种对用户来说使用起来非常顺滑、且随着应用程序的发展依然易于维护的架构。
