A. android的Fragment知识点
frgment被创建的时候，相关的生命周期，
onAttach(), onCreate(), onCreateView(), onActivityCreated();
fragment对用户可见的时候，相关的生命周期，
onStrat(), onResume(),
fragment进入“后台模式”的时候，相关的生命周期，
onPause(), onStop(),
fragment被销毁的时候，相关的生命周期，
onPause(), onStop(), onDestroyView(), onDestroy(), onDetach()
可用onCreate()、onCreateView()、onActivityCreated()方法Bundle对象保存一个fragment的对象
onAttach()：Fragment和Activity相关联时调用，可以通过该方法获取Activity引用，还可以通过getArguments()获取参数。
onCreate():Fragment创建时被调用。
onCreateView():创建Fragment的布局。
onActivityCreated():当Activity完成onCreate时调用。
onStart():当Fragment可见时。
onResume():当Fragment可见，且可交互时调用。
onPause():当Fragment不可交互，但可见时。
onStop():当Fragment不可见时。
onDestroyView():当Fragment的UI从视图结构中移除时调用。
onDestroy()：销毁Fragment时
onDetach()：当Fragment和Activity解除关联时调用。
B. Android-ViewModel原理解析
在这四个方法中，其实唯一的区别就是要不要传Factory，当没有传自定义的Factory的时候，则会传入默认的Factory，我们看ViewModelProvider构造器的源码和部分of方法的源码：
在ViewModelProvider中需要传入一个VieModelStore对象，这个对象是由ViewModelStoreOwner来提供的，而在Activity或者Fragment中，是由Activity和Fragment来提供的，因为ViewModelStoreOwner是一个接口，而AppCompatActivity的祖父ComponentActivity和Fragment均实现了ViewModelStoreOwner接口。
但是ViewModelProviders在新的lifecycle-extensions库中，已经是属于被弃用的。新版的API直接使用ViewModelProvider，而不是ViewModelProviders。
比如：
可以如下的方式在baseActivity中添加，由子类Activity调用：
创建ViewModel对象，首先就需要先初始化一个ViewModelProvider对象
可以看出，ViewModelProvider构造函数其实最终都是需要两个参数，一个是ViewModelStoreOwner对象，一个是Factory。而ViewModelStoreOwner其实就是用来获取一个ViewModelStore对象来保存ViewModel对象的。而Factory就是用来创建ViewModel对象的。
这个接口的主要实现的作用就是返回一个ViewModelStore对象。在Android中，Activity和Fragment都会实现该接口，并且实现getViewModelStore()方法。
比如Activity就是在FragmentActivity的父类ComponentActivity中实现了ViewModelStoreOwner接口
Fragment的ViewModelStore其实是由FragmentManager进行管理获取
每个FragmentActivity都会有一个自己的FragmentManager对象，所以每个FragmentManagerViewModel对象，管理的是一个FragmentActivity中的所有的Fragment对应的ViewModel。具体看FragmentManagerViewModel的getViewModelStore方法
从这里可以看出，每个Fragment都会有自己的ViewModelStore对象，而ViewModelStore对象，是根据每个Fragment的唯一标识进行创建的。
ViewModelStore类对象，是每个Activity或者Fragment都有一个，目的是用于保存该页面的ViewModel对象，方便ViewModel的管理
从ViewModelProvider的get方法中，可以看出，get方法传入的是一个ViewModel.class的Class类型，然后通过这个类型，得到ViewModel的规范名称。将ViewModel对象缓存在ViewModelStore中的HashMap中。而ViewModel的创建，其实是通过ViewModelProvider.Factory来实现的
ViewModelProviders的of方法，用于返回一个ViewModelProvider对象
从这里我们可以看到，如果传入的Activity或者Fragment有方法实现，而factory为null的时候，则会通过创建对应的Factory，而如果没有的实现，那么就会调用NewInstanceFactory来创建对应的Factory，而NewInstanceFactory其实就是创建AndroidViewModelFactory对象。
最终ViewModel对象，其实就是通过AndroidViewModelFactory的create的方法实现来创建。一般就是通过Class.newInstance或者Class.getConstructor来创建对象。
而ViewModelProvider的第一个参数，其实最终传入的是ViewModelStore对象，这个对象内部是通过一个HashMap来保存ViewModel对象
而新版的源码，ViewModelStore对象是通过Fragment和FragmentActivity对象的getViewModelStore方法来获取，而原先的HolderFragment的功能都移植到了Fragment中
HolderFragment通过设置setRetainInstance(true)，使得自身能够不受到屏幕旋转等configuration
changes影响而存活，直到依附的Activity正常结束。
因为HolderFragment的生命周期，ViewModelStore对象保存在HolderFragment中，而ViewModel又存储在ViewModelStore中，这就是为什么我们说ViewModel类能够让数据在屏幕旋转等配置信息改变导致UI重建的情况下不被销毁。
ViewModelProvider的get方法：
在ViewModel中，有两种Factory，Factory是的类型是由ViewModelProvider在初始化的时候创建的，所以是由ViewModelProvider决定Factory的类型。在ViewModelProvider中，有两种Factory，一种是默认的Factory，默认的Factory是通过在ComponentActivity或者Fragment中实现接口，然后在()方法中初始化一个SavedStateViewModelFactory对象；另一种Factory则是NewInstanceFactory，这种是通过NewInstanceFactory.getInstance()的单例方式获取。
其实就是通过ViewModel的Class对象，然后通过反射创建ViewModel对象，然后保存到ViewModelStore中的Map集合中
从ViewModelProvider的get方法可以看出，在ViewModelProvider的get方法中会根据Factory的类型，进行不同方法的调用。SavedStateViewModelFactory是实现了ViewModelProvider.KeyedFactory接口的，所以在创建ViewModel的时候，调用的是SavedStateViewModelFactory的create方法。
AndroidViewModel和ViewModel的构造器参数Class
ViewModel保存和恢复数据
ComponentActivity和Fragment都将数据的保存和恢复逻辑转发给了SavedStateRegistryController。在在onCreate方法里通过调用performRestore来恢复数据，在onSaveInstanceState方法里通过调用performSave来保存数据。而SavedStateRegistryController中的SavedStateRegistry对象，就是实际进行数据的保存和恢复的，在SavedStateRegistry通过唯一的key获取到一个SavedStateProvider，而SavedStateProvider其实就是返回需要保存的数据，将对应的需要缓存的数据一一返回，然后保存在系统缓存时的回调到onSaveInstanceState的方法参数Bundle中进行保存。
SavedStateRegistry.performSave()
该方法是由ComponentActivity的onSaveInstanceState方法触发调用SavedStateRegistryController的performSave，进而调用的
在SavedStateRegistry恢复数据的时候，会把恢复后的数据都交给SavedStateHandle。希望保留的数据，可以通过两种方式向mRegular保存数据。
在ComponentActivity恢复数据的时候，会通过SavedStateRegistryController.performSave在Activity的onSaveInstanceState方法中进行数据的保存，然后在ComponentActivity的onCreate方法中，通过调用SavedStateRegistryController.performRestore方法进行数据的恢复，这些恢复的数据都会保存在SavedStateHandleController对象中的SavedStateHandle属性中，然后在Activity重新创建的时候，会通过反射创建对应的ViewModel对象的时候，将SavedStateHandleController中的SavedStateHandle赋值给对应的ViewModel进行数据恢复。
这块的源码分析可以参考：
从源码看 Jetpack（7）-SavedStateHandle源码详解
这里其实就是直接使用Class的newInstance直接创建对象。Activity和Fragment一般都是使用SavedStateViewModelFactory创建ViewModel对象。
ViewModel的销毁，要分为Activity和Fragment两部分。
首先看下ViewModel在销毁的时候做的事情
而ViewModel的clear()方法的调用，是在ViewModelStore中
Activity的销毁，是通过Lifecycle监听生命周期回调，当生命周期执行到onDestroy的时候，调用ViewModelStore的clear()方法进行ViewModel的销毁。
看ComponentActivity中构造器中的实现：
Fragment的生命周期管理，如下：
Fragment的生命周期，首先会依次增大，然后在从onResume变成onPause的时候，就开始状态码减小。即先升再降的一个状态变化。在当前状态码变成CREATED的时候，就会执行onDestroy。即调用
FragmentStateManager.destroy
在这里就会调用nonConfig.clearNonConfigState方法，nonConfig其实就是FragmentManagerViewModel对象。
FragmentManagerViewModel.clearNonConfigState
按照上面的逻辑，在Activity重建时会执行destory生命周期事件，那么为什么ViewModel没有销毁呢？
其实就是在屏幕旋转的时候，AMS通过Binder回调Activity的()方法，这个时候就会进行数据的保存，保存到一个NonConfigurationInstances对象；而在屏幕翻转结束之后，会再一次调用ViewModelProvider的构造函数，此时就会调用owner.getViewModelStore()，接着就会调用()，这里就会通过Activity中的NonConfigurationInstances对象取出保存的ViewModelStore对象。
所以数据保存就是通过()方法保存在NonConfigurationInstances对象，而再一次使用取出ViewModel的数据的时候，就是从nc对象中取出ViewModelStore对象，而ViewModelStore对象保存有ViewModel集合
通过对ComponentActivity的getViewModelStore()方法进行分析。可以找到这个问题的答案。
当mViewModelStore为null的时候，会从NonConfigurationInstances中获取ViewModelStore对象。
其实在ComponentActivity和Activity中都会有一个NonConfigurationInstances类，而Activity中的NonConfigurationInstances类结构如下：
这里的Object activity其实就是保存的ComponentActivity中的NonConfigurationInstances类对象，看Activity的下面的方法：
activity这个Object对象，其实是通过()方法返回值赋值，而()方法的实现是在ComponentActivity中。
看ComponentActivity中的下面方法：
因为这里会在ComponentActivity中的NonConfigurationInstances类对象中保存ViewModelStore对象，所以这也是Activity重建时不会销毁ViewModel的原因。
()方法除了被Activity的()调用以外，还会被LocalActivityManager的()方法调用
在分析ViewModel的销毁过程时，我们看到Activity与Fragment存储VieModel是分离的，那么同一个Activity下的Fragment是如何共享ViewModel的呢？
其实共享的是Activity的ViewModel。
而具体的实现逻辑，其实就是在FragmentViewModelLazy.kt中的：
在Fragment中可以直接调用，这是一个Fragment的扩展函数，通过实现requireActivity().viewModelStore，获取到了Activity的ViewModelStore对象后，这样就可以实现了Fragment共用Activity的ViewModel，从而实现了Fragment之间共享ViewModel。
Fragment之间共享ViewModel，需要引入
C. Android中打开其他应用（或者系统应用）Activity或者Fragment总结
最近在做项目适配工作，需要打开手机中设置页面进行设置。国内 rom 都是自己改过的，适配起来也是稍微的麻烦。同一个功能不同的手机品牌界面都不一样，纯粹的用 adb 命令以及 logcat 来查看每个手机对应的页面的 Activity 或者 Fragment 以及包名。简单的记录一下过程。
在控制台中输入一下命令，可以查看当前页面显示Activity的全部信息
拿小米手机 （Android 6.0， MIUI 9.2 ）的锁屏和密码这个功能页面来说。在控制台输入命令之后，可以看到一长串的信息。
可以看到当前的 Activity 的包名 com.android.settings 以及 Activity 的名称 SubSettings 。这样不久可以通过隐士调用打开页面了么？ 直接上手操作一波。
结果很尴尬的，打开的是空白页，这又是怎么回事？而且跳转了几个页面在同时输入上边命令，也是显示这个页面 SubSettings 。这样就开始疑惑了，想到这应该是小米在上边改动，通过Fragment来实现相关的功能了。先看看原生的系统源码。（网上源码地址： http://androidxref.com/ ）。打开源码，发现没有实现什么具体的东西。
但是看到源码中 protected boolean isValidFragment(String fragmentName) 确定了这其实就是一个 Fragment 的容器。好那再接着看 mpsys 命令的返回信息。
看到 Activie Fargment MiuiSecuritySettings 。 但是又不知道包名，因为手机厂商各种改，不一定包名就是 settings 。就有通过 Android Studio Logcat 找到了解决方案。链接手机的时候 Logcat 打印了各种系统的 log 。 Ctrl + F 直接搜索一下 MiuiSecuritySettings 。果然找到了
最后，通过如下的方法，启动小米系统的锁屏和密码设置界面
其他的页面，应该也是大同小异的处理思路，只能一个个手机来实际适配了，并没有找到一个很好的解决办法，挨。
D. Android——Fragment
Fragment必须总是被嵌入到一个activity之中，并且fragment的生命周期直接接受其宿主activity的生命周期的影响。你可以认为fragment是activity的一个模块零件，它有自己的生命周期，接收它自己的输入的事件，并且可以在activity运行时添加或者删除。
应该将每一个fragment设计为模块化和可复用化的activity组件。也就是说，你可以在多个activity中引用同一个fragment，因为fragment定义了它自己的布局，并且使用它本身生命周期回调的行为。
Fragment比Activity多了几个额外的生命周期回调方法：
管理fragment生命周期与管理activity生命周期很相像，像activity一样，fragment也有三种状态：
1、Resumed：
fragment在运行中的activity中可见。
2、Paused：
另一个activity处于前台且得到焦点，但是这个fragment所在的activtiy仍然可见（前台activity部分透明，或者没有覆盖全屏）。
3、Stopped：
fragment不可见。要么宿主activity已经停止，要么fragment已经从activity上移除，但已被添加到后台栈中。一个停止的fragment仍然活着（所有的状态和成员信息仍然由系统保留着）。但是，它对于用户来讲已经不再可见，并且如果activity被杀掉，它也将被杀掉。
如果activity的进程被杀掉了，在activity被重新创建时，你恢复fragment状态。可以执行fragment的onSaveIntanceState()来保存状态（注意：fragment是在onCreate(),onCreateView()或者onActivityCreate()中进行恢复）。
在生命周期方面，activity和fragment之间一个很重要的不同就是在各自的后台栈中是如何存储的。当activity停止时，默认情况下activity被安置在由系统管理的activity后台栈中；fragment仅当在一个事务被移除时，通过显式调用addToBackStack()请求保存的实例，该fragment才被置于由宿主activity管理的后台栈。
类似与Android系统为Activity维护一个任务栈，我们也可以通过Activity维护一个回退栈来保存每次Fragment事务发生的变化。
如果你将Fragment任务添加到回退栈，当用户点击后退按钮时，将看到上一次的保存的Fragment。一旦Fragment完全从后退栈中弹出，用户再次点击后退键，则退出当前Activity。
通过Arguments创建Fragment,不建议通过为Fragment添加带参数的构造函数
1、FragmentPagerAdapter：对于不再需要的fragment，选择调用detach方法，仅销毁视图，并不会销毁fragment实例。
2、FragmentStatePagerAdapter：会销毁不再需要的fragment，当当前事务提交以后，会彻底的将fragment从当前Activity的FragmentManager中移除。
3、懒加载，核心方法是 setUserVisibleHint()
原因1：横竖屏切换，造成Fragment重新实例化。
原因2：按下Home键，Activity处于后台，由于内存不足被销毁，重新唤醒时Fragment重新实例化。
注：出现的原因是在 API24 之前的 v4包 的源码问题，
解决方案：通过检查onCreate的参数Bundle savedInstanceState就可以判断，当前是否发生Activity的重新创建：
默认的savedInstanceState会存储一些数据，只有在savedInstanceState==null时，才进行创建Fragment实例：
E. Android 多返回栈技术详解
用户通过系统返回按钮导航回去的一组页面，在开发中被称为返回栈 (back stack)。多返回栈即一堆 "返回栈"，对多返回栈的支持是在 Navigation 2.4.0-alpha01 和 Fragment 1.4.0-alpha01 中开始的。本文将为您展开多返回栈的技术详解。
无论您在使用 Android 全新的 手势导航 还是传统的导航栏，用户的 "返回" 操作是 Android 用户体验中关键的一环，把握好返回功能的设计可以使应用更加贴近整个生态系统。
在最简单的应用场景中，系统返回按钮仅仅 finish 您的 Activity。在过去您可能需要覆写 Activity 的 onBackPressed() 方法来自定义返回操作，而在 2021 年您无需再这样操作。我们已经在 OnBackPressedDispatcher 中提供了 针对自定义返回导航的 API。实际上这与 FragmentManager 和 NavController 中 已经 添加的 API 相同。
这意味着当您使用 Fragments 或 Navigation 时，它们会通过 OnBackPressedDispatcher 来确保您调用了它们返回栈的 API，系统的返回按钮会将您推入返回栈的页面逐层返回。
多返回栈不会改变这个基本逻辑。系统的返回按钮仍然是一个单向指令 —— "返回"。这对多返回栈 API 的实现机制有深远影响。
在 surface 层级，对于 多返回栈的支持 貌似很直接，但其实需要额外解释一下 "Fragment 返回栈" 到底是什么。FragmentManager 的返回栈其实包含的不是 Fragment，而是由 Fragment 事务组成的。更准确地说，是由那些调用了 addToBackStack(String name) API 的事务组成的。
这就意味着当您调用 commit() 提交了一个调用过 addToBackStack() 方法的 Fragment 事务时， FragmentManager 会执行所有您在事务中所指定的操作 (比如 替换操作 )，从而将每个 Fragment 转换为预期的状态。然后 FragmentManager 会将该事务作为它返回栈的一部分。
当您调用 popBackStack() 方法时 (无论是直接调用，还是通过系统返回键以 FragmentManager 内部机制调用)，Fragment 返回栈的最上层事务会从栈中弹出 -- 比如新添加的 Fragment 会被移除，隐藏的 Fragment 会显示。这会使得 FragmentManager 恢复到最初提交 Fragment 事务之前的状态。
也就是说 popBackStack() 变成了销毁操作: 任何已添加的 Fragment 在事务被弹出的时候都会丢失它的状态。换言之，您会失去视图的状态，任何所保存的实例状态 (Saved Instance State)，并且任何绑定到该 Fragment 的 ViewModel 实例都会被清除。这也是该 API 和新的 saveBackStack() 方法之间的主要区别。 saveBackStack() 可以实现弹出事务所实现的返回效果，此外它还可以确保视图状态、已保存的实例状态，以及 ViewModel 实例能够在销毁时被保存。这使得 restoreBackStack() API 后续可以通过已保存的状态重建这些事务和它们的 Fragment，并且高效 "重现" 已保存的全部细节。太神奇了！
而实现这个目的必须要解决大量技术上的问题。
虽然 Fragment 总是会保存 Fragment 的视图状态，但是 Fragment 的 onSaveInstanceState() 方法只有在 Activity 的 onSaveInstanceState() 被调用时才会被调用。为了能够保证调用 saveBackStack() 时 SavedInstanceState 会被保存，我们 还 需要在 Fragment 生命周期切换 的正确时机注入对 onSaveInstanceState() 的调用。我们不能调用得太早 (您的 Fragment 不应该在 STARTED 状态下保存状态)，也不能调用得太晚 (您需要在 Fragment 被销毁之前保存状态)。
这样的前提条件就开启了需要 解决 FragmentManager 转换到对应状态的问题，以此来保障有一个地方能够将 Fragment 转换为所需状态，并且处理可重入行为和 Fragment 内部的状态转换。
在 Fragment 的重构工作进行了 6 个月，进行了 35 次修改时，发现 Postponed Fragment 功能已经严重损坏，这一问题使得被推迟的事务处于一个中间状态 —— 既没有被提交也并不是未被提交。之后的 65 个修改和 5 个月的时间里，我们几乎重写了 FragmentManager 管理状态、延迟状态切换和动画的内部代码，具体请参见我们之前的文章《全新的 Fragment: 使用新的状态管理器》。
随着技术问题的逐步解决，包括更加可靠和更易理解的 FragmentManager ，我们新增加了两个 API: saveBackStack() 和 restoreBackStack() 。
如果您不使用这些新增 API，则一切照旧: 单个 FragmentManager 返回栈和之前的功能相同。现有的 addToBackStack() 保持不变 —— 您可以将 name 赋值为 null 或者任意 name 。然而，当您使用多返回栈时， name 的作用就非常重要了: 在您调用 saveBackStack() 和之后的 restoreBackStack() 方法时，它将作为 Fragment 事务的唯一的 key。
举个例子，会更容易理解。比如您已经添加了一个初始的 Fragment 到 Activity，然后提交了两个事务，每个事务中包含一个单独的 replace 操作:
也就是说我们的 FragmentManager 会变成这样:
比如说我们希望将 profile 页换出返回栈，然后切换到通知 Fragment。这就需要调用 saveBackStack() 并且紧跟一个新的事务:
现在我们添加 ProfileFragment 的事务和添加 EditProfileFragment 的事务都保存在 "profile" 关键字下。这些 Fragment 已经完全将状态保存，并且 FragmentManager 会随同事务状态一起保持它们的状态。很重要的一点: 这些 Fragment 的实例并不在内存中或者在 FragmentManager 中 —— 存在的仅仅只有状态 (以及任何以 ViewModel 实例形式存在的非配置状态)。
替换回来非常简单: 我们可以在 "notifications" 事务中同样调用 saveBackStack() 操作，然后调用 restoreBackStack() :
这两个堆栈项高效地交换了位置:
维持一个单独且活跃的返回栈并且将事务在其中交换，这保证了当返回按钮被点击时， FragmentManager 和系统的其他部分可以保持一致的响应。实际上，整个逻辑并未改变，同之前一样，仍然弹出 Fragment 返回栈的最后一个事务。
这些 API 都特意按照最小化设计，尽管它们会产生潜在的影响。这使得开发者可以基于这些接口设计自己的结构，而无需通过任何非常规的方式保存 Fragment 的视图状态、已保存的实例状态、非配置的状态。
当然了，如果您不希望在这些 API 之上构建您的框架，那么可以使用我们所提供的框架进行开发。
Navigation Component 最初 是作为通用运行时组件进行开发的，其中不涉及 View、Fragment、Composable 或者其他屏幕显示相关类型及您可能会在 Activity 中实现的 "目的地界面"。然而，NavHost 接口 的实现中需要考虑这些内容，通过它添加一个或者多个 Navigator 实例时，这些实例 确实 清楚如何与特定类型的目的地进行交互。
这也就意味着与 Fragment 的交互逻辑全部封装在了 navigation-fragment 开发库和它其中的 FragmentNavigator 与 DialogFragmentNavigator 中。类似的，与 Composable 的交互逻辑被封装在完全独立的 navigation-compose 开发库和它的 ComposeNavigator 中。这里的抽象设计意味着如果您希望仅仅通过 Composable 构建您的应用，那么当您使用 Navigation Compose 时无需任何涉及到 Fragment 的依赖。
该级别的分离意味着 Navigation 中有两个层次来实现多返回栈:
仍需特别注意那些 尚未 更新的 Navigator ，它们无法支持保存自身状态。底层的 Navigator API 已经整体重写来支持状态保存 (您需要覆写新增的 navigate() 和 popBackStack() API 的重载方法，而不是覆写之前的版本)，即使 Navigator 并未更新， NavController 仍会保存 NavBackStackEntry 的状态 (在 Jetpack 世界中向后兼容是非常重要的)。
如果您仅仅在应用中使用 Navigation，那么 Navigator 这个层面更多的是实现细节，而不是您需要直接与之交互的内容。可以这么说，我们已经完成了将 FragmentNavigator 和 ComposeNavigator 迁移到新的 Navigator API 的工作，使其能够正确地保存和恢复它们的状态，在这个层面上您无需再做任何额外工作。
如果您正在使用 NavigationUI，它是用于连接您的 NavController 到 Material 视图组件的一系列专用助手，您会发现对于菜单项、 BottomNavigationView (现在叫 NavigationRailView ) 和 NavigationView ，多返回栈是 默认启用 的。这就意味着结合 navigation-fragment 和 navigation-ui 使用就可以。
NavigationUI API 是基于 Navigation 的其他公共 API 构建的，确保您可以准确地为自定义组件构建您自己的版本。保证您可以构建所需的自定义组件。启用保存和恢复返回栈的 API 也不例外，在 Navigation XML 中通过 NavOptions 上的新 API，也就是 navOptions Kotlin DSL，以及 popBackStack() 的重载方法可以帮助您指定 pop 操作保存状态或者指定 navigate 操作来恢复之前已保存的状态。
比如，在 Compose 中，任何全局的导航模式 (无论是底部导航栏、导航边栏、抽屉式导航栏或者任何您能想到的形式) 都可以使用我们在与 底部导航栏集成 所介绍的相同的技术，并且结合 saveState 和 restoreState 属性一起调用 navigate() :
对用户来说，最令人沮丧的事情之一便是丢失之前的状态。这也是为什么 Fragment 用一整页来讲解 保存与 Fragment 相关的状态，而且也是我非常乐于更新每个层级来支持多返回栈的原因之一:
如果您希望了解 更多使用该 API 的示例，请参考 NavigationAdvancedSample (它是最新更新的，且不包含任何用于支持多返回栈的 NavigationExtensions 代码)。
对于 Navigation Compose 的示例，请参考 Tivi。
如果您遇到任何问题，请使用官方的问题追踪页面提交关于 Fragment 或者 Navigation 的 bug，我们会尽快处理。
F. android, FragmentManager 能同时管理多个Fragment和ListFragment吗
能，可以看sdk自带的apidemos例程，在layout里放置多个framelayout做为fragment的容器，在oncreate时设置listfragment即可
G. Android中绑定Fragment与Activity用哪个方法
1、用FragmentActivity类，自带绑定管理类，绑定fragment。
2、在Activity中，用fragmentManager管理类，绑定fragment和Activity的关系。
H. android fragment能做什么
fragment的目的是适应众多分辨率，可以在不同屏幕上动态管理UI.可以将一个activty分成不同的区块来现实，大屏小屏实现很好的兼容 。
Android是在Android 3.0 (API level 11)开始引入Fragment的。
可以把Fragment想成Activity中的模块，这个模块有自己的布局，有自己的生命周期，单独处理自己的输入，在Activity运行的时候可以加载或者移除Fragment模块。
可以把Fragment设计成可以在多个Activity中复用的模块。
当开发的应用程序同时适用于平板电脑和手机时，可以利用Fragment实现灵活的布局，改善用户体验。
I. android fragment有什么用
自从Android 3.0中引入fragments 的概念，其目的是为了解决不同屏幕分辩率的动态和灵活UI设计。大屏幕如平板小屏幕如手机，平板电脑的设计使得其有更多的空间来放更多的UI组件，而多出来的空间存放UI使其会产生更多的交互，从而诞生了fragments 。
fragments 的设计不需要你来亲自管理view hierarchy 的复杂变化，通过将Activity 的布局分散到frament 中，可以在运行时修改activity 的外观，并且由activity 管理的back stack 中保存些变化。当一个片段指定了自身的布局时，它能和其他片段配置成不同的组合，在活动中为不同的屏幕尺寸修改布局配置（小屏幕可能每次显示一个片段，而大屏幕则可以显示两个或更多）。
ITjob网有关于Android的文章和帖子，如果你想了解的更细致的话，可以自己去看看。也可以去相关的论坛，或者大牛的博客看看。希望对你有帮助。
J. 关于Android中fragment的管理
底部使用fragment构建,用fragment元素组成一个集合,接下来使用activity把每个元素都添加进去.调用fragmentPagerAdapter作为适配器排版,然后调用viewpager显示界面,底下菜单使用button点击事件触发,,同时实现滑动与点击控制界面的效果