Android multiple back stacks导航的几种实现

• 2022 年 6 月 25 日
• 笔记
• Android, navigation

Android multiple back stacks导航

谈谈android中多栈导航的几种实现.

什么是multiple stacks

当用户在app里切换页面时, 会需要向后回退到上一个页面, 页面历史被保存在一个栈里.
在Android里我们经常说”back stack”.

有时候在app里我们需要维护多个back stack, 比较典型的场景是bottom navigation bar或者侧边的drawer.

如果需求要求在切换tab的时候保存每个tab上的历史, 这样当用户返回的时候还是返回到上次离开的地方, 这种就叫multiple stacks.

(与之对应的single stack行为是返回之后回到了tab首页.)

本文之后的内容都以bottom bar的多栈导航为例.

multi-stack的需求

首先还是讨论一下需求.

当bottom bar不支持多栈时, 当点击切换底部tab, 再返回原来的tab, 所有在之上打开的页面都会消失, 只有第一层(根)页面会显示.

这也是可以接受的, 甚至在material design里面作为Android平台的默认行为被提及: material design

但它同时也说了, 如果需要的话, 这个行为是可以被改的.

如果你想保留用户在上个tab看过的内容状态, 很可能就需要做multi-stack, 每个tab上的栈是独立退出, 分别保留的.

通常, 这还不是仅有的需求.

如果用户点击已选中的tab, 需要重置这个stack吗?

需要定制转场动画吗?

需要保留tab历史吗? 比如从tab A -> B -> C, 在C的根页面back, 是想回到B还是回到home tab?

在bottom navigation的默认实现中(用Android Studio创建一个Bottom Navigation的新项目), 在非home tab的根节点, 点击back, 总是先回到home tab, 再次back才会退出app.
因为这样是符合固定start destination的原则的. 用户在打开后和关闭前, 看到的是同一个页面.

但是如果你有保存tab历史的需求, 也可以考虑如何定制它.

当你更进一步地涉及到实现层面, 你会遇到更多实际操作的问题, 比如怎么把一个详情页push到一个指定的栈, 如何pop destination.

让我们列一下几个需求点:

• 维护多个栈.
• 切换tab: 手动点击tab或者其他tab内的交互. 比如dashboard跳转到某个内容tab.
• Push/pop destinations.
• 重选(reselect)tab会重置该栈. (clear history.)
• 转场动画
• tab历史.

技术背景

要进行导航的选型, 首先确定一下你的”destination”是什么.

是composable还是fragment, 或者干脆是View, 解决方案可能有很大的不同.

以这篇文章的scope来说, 我们就关注一个传统的android app, 用Activity和Fragment实现.
所以bottom tab上的tab内容, 是不同Fragment.

Fragment lifecycle

为什么这里要提一下Fragment的生命周期呢?

因为fragment的生命周期和它的ViewModel紧密关联, 进一步关系到了在导航过程中我们是否需要关注fragment的状态恢复和刷新.

首先复习一下Fragment生命周期的回调: 什么时候onDestroy会被调用?

• 当replacetransaction没有addToBackStack().
• 当fragment被removed或者被popBackStack().

当replacetransaction加上addToBackStack(), 旧的fragment会被压入栈, 但它的生命周期只调用到onDestroyView().
当在它之上的其他fragment pop出来以后, 旧的这个fragment实例依然是同一个, 它重新显示, 重新从onCreateView()开始走.

这是我们在single back stack下预期的行为.

ViewModel的生命周期和Fragment是对齐的, 也即Fragment的onDestroy()调用时, ViewModel的onCleared()被调用.

在导航切换目的地时, 如果fragment被destroy了, 我们可以保存一些关注的变量在saved instance bundle或者SavedStateHandle里, 用于之后的状态恢复.
但是如果fragment没有被destroy, 我们可以剩下不少力气做这些状态恢复.

所以理想的状态是, 压栈后的fragment实例不会被销毁重建.

Navigation库/可能的方案

为了比较不同的解决方案, 我把一些sample放在了一起: //github.com/mengdd/bottom-navigation-samples

Jetpack navigation component

官网: //developer.android.com/guide/navigation

即便在FragmentManager的文档 里, 也建议开发者使用jetpack的navigation library来处理app的navigation.

multiple back stack的支持是Navigation 2.4.0-alpha01 和 Fragment 1.4.0-alpha01才加的.

试了下这个 demo,
代码非常简单, 我们基本什么都不用做.

关于这里面的思想可以看这篇文章: //medium.com/androiddevelopers/multiple-back-stacks-b714d974f134

优点:

• 最知名, 毕竟是官方的库.
• 支持类型安全的参数.
• NavigationController支持pop到一个指定的destination.
• 可以和Compose navigation库一起使用.

缺点:

• Multi-stack的支持: 当切换tab时, 前一个tab上的所有fragment都会被destroy, 当返回tab时栈内fragment会重建. 所以状态会丢, 页面可能会刷新.
• 每个tab都需要是一个内嵌的navigation graph, 如果有一些common的destination, 需要include到每个graph中去. xml的navigation文件感觉很像一个大块的样板代码.

FragmentManager

如果我们想做更多的定制, 我们可以考虑用FragmentManager的新APIs自己手动实现.

在文档中doc 介绍的:

FragmentManager allows you to support multiple back stacks with the saveBackStack()
and restoreBackStack() methods. These methods allow you to swap between back stacks by saving one back stack and restoring a different one.

这是navigation component实现中实现多栈导航使用的方法.
所以也可以解释为什么切tab的时候fragment都被销毁了.

saveBackStack() works similarly to calling popBackStack() with the optional name
parameter: the specified transaction and all transactions after it on the stack are popped.
The difference is that saveBackStack() saves the state of all fragments in the popped transactions.

优点:

• 精细控制, 开发者获得更多控制, 也更明白到底是怎么回事.
• 如果我们当前项目没有采用任何navigation library, 都是手动跳转, 采用这种方法我们就不用考虑迁移navigation.

缺点:

• 要写很多fragment transaction的样板代码.
• 和navigation components一样: 多栈实现中在切换栈时, 在旧的tab上的Fragments会被销毁, 返回时全部重建.

Enro

//github.com/isaac-udy/Enro

对于多module的大型项目来说, 我很推荐这个库, 它可以帮助我们解耦module间的依赖.

multi-stack的demo

优点:

• 基于注解, 所以要写的代码很少, 导航使用很方便.
• 多module项目解耦.
• 传类型安全的参数和返回结果都很容易.
• 可以在ViewModel中获取navigation handle, 获取参数.
• 支持Compose做节点.
• 对Unit Test也有一个辅助测试的依赖.
• multi-stack support: 保持了切换tab的时候fragment实例.

缺点:

• 可能目前还不是很知名. 需要说服别人学和采用这个.
• Fragment的multi-stack: 不能rest stack到根节点. (尝试了一下定制这个行为, 有点难).

Simple-stack

//github.com/Zhuinden/simple-stack

这里推荐一下这个库作者的文章Creating a BottomNavigation Multi-Stack using child Fragments with Simple-Stack.
关于如何用simple-stack来做multi-stack.

最开始作者展示了一个不用任何库, 仅用child fragments来实现的版本.

这是手动实现的另一种思想了.

后来才引入了用simple-stack做的demo
这是采用了原作者提供的sample, 比较简单, 试了一下以后我发现可能还需要添加更多的代码, 来做实际的应用.
比如详情页需要获得某个tab的local stack的实例, 从而把自己push上去.

优点:

• 作者在社区十分活跃, 有很多视频和文章介绍simple-stack这个库. 所以社区支持挺好.
• multi-stack support: 保持了切换tab的时候fragment实例.
• 支持控制和清空栈的历史.
• 有compose的扩展.

缺点:

• 如果你的bottom bar当前是在activity的布局里, 你需要把bottom bar和相关的东西都挪进一个RootFragment, 作为总的节点.
• 作者提供的multi-stack sample还非常简单, 需要写更多的代码来或者当前正确的栈来做push和pop操作. 不了解这个库可能会写得很丑.

其他库

还有一些库, 不是通用的navigation解决方案, 而只是为多栈导航设计的小库.
比如:

• //github.com/DimaKron/Android-MultiStacks
• //github.com/JetradarMobile/android-multibackstack

这些库都自带sample.

优点:

• 实现简单, 只用几个类. 如果我们想定制我们可以用这个代码.
• 要改动的范围可以限制在bottom navigation的部分, 而不是整体改变navigation方案.

缺点:

• 这些库都不是很出名, 有不再维护的风险.
• 可能和其他的navigation方案不能兼容, 比如Navigation Components. 需要考虑整体.

总结

android (fragment实现) multi-stack navigation的可能解决方案:

注意:

• 整体方案: 表示该方案可以用于app整体的navigation解决方案, 而不仅仅是解决multi-stack的问题.
• Fragment被保存, 不被销毁: 当跳转或者切tab时, 被压入栈中的fragments不会被destroyed. 多栈支持的情况下, 尽管fragment被返回时都会被重建, 但是如果它不被销毁, 我们就不需要做额外的工作来缓存状态.

References:

• Sample: //github.com/mengdd/bottom-navigation-samples
• Jetpack Navigation Components
• Enro
• Simple-stack