android fragmentactivity fragment,QMUI实战(二)—Activity 和 Fragment，我们该选择谁？

在一开始， 官方只提供了 Activity 来作为 UI 界面的载体，因此我们也别无选择，只能用它。而在 Android 3.0 后，Fragment 也面世了，它一开始是用于适配平板的，以邮件列表与详情的适配为例，手机端够小，因此开始展示列表，点击进入详情，而平板够大，则可以列表显示在左侧，详情显示在右侧，点击列表只是切换详情。对于这种适配场景，列表页和详情页必须在同一个 Activity 里了，而这便是我所知道的 Fragment 诞生的场景了。但是随着 Fragment 框架的不断完善， 单 Activity 多 Fragment 的架构也被提出了，甚至现在官方的 navigation 库都是这种模式， 可见官方对 Fragment 是多么的青睐了。

当然，现在我们写 UI 也不只是这两种选择了， Reative Native， Flutter，以及将来的 compose 为我们写 UI 提供了很多很多的选择，同时我们学习的东西也越来越多了。今天我们只讨论一些 Activity 和 Fragment 相关的话题，对于另外的几个，我只是期待 compose 时代的早点到来。

Activity

提到 Activity，可能最容易犯的一个错误就是忘记在 AndroidManifest 里注册了吧，直到运行出错，才想起要去注册，然后再编译，时间就是这样没了的。对于 Activity 的使用，我们需要关注生命周期、启动模式、setContentView 外，我们还需要掌握的一个关键知识点就是 SaveState 了。

iOS 端、 Web 端都是不存在 SaveState 的，因而这几乎是 Android 独有的。因为 Android 最初的年代是比较看轻 View 的。 在 Android 眼里， View 是廉价的，数据、状态是宝贵的，View 是可以随时销毁，然后根据状态进行恢复的。例如在横竖屏旋转、Dark Mode 切换这些场景中，Android 就选择销毁掉当前 Activity，然后再重新创建，重新创建时会去 resource 里读当前配置下的资源，例如字体大小、颜色等等，这些资源都是可以根据不同状态在不同文件件里配置成不同的值，因而我们就不需要去写各种判断。但是问题来了，当 UI 显示出来后，大多数情况是有数据渲染或状态变更的，那么销毁重建后，我们的数据该如何恢复呢？ 这就要靠 SaveState 机制了：在销毁时，我们把数据保存下来，然后在重建时，我们再把数据恢复出来。

当然，你也可以选择不要让系统重建你 Activity，而是自己处理配置的变更。做法就是在 AndroidManifest 文件里为 Activity 的 configChanges 属性里加上你想要自己处理的配置。例如：

android:configChanges="orientation|keyboardHidden|screenSize|smallestScreenSize|screenLayout|uiMode"

具体的配置项可以看官方文档。 例如 orientation 便是横竖屏旋转， uiMode 可以用于接收 Dark Mode 的切换。当这些配置好后。 我们在 Activity 里可以通过重写 onConfigurationChanged 来接受配置的变更。

我们说回 SaveState。 当发生配置变更、或者因为内存等原因被系统杀死的 Activity, 会调用 onSaveInstanceState 来保存 UI 状态，默认情况下会遍历 View, 然后以 View 的 id 为键来收集 View 的状态。当然每个 View 都是可以重写 onSaveInstanceState 来更改默认行为， 例如 RecyclerView/ListView 就阻止了子 View 状态的保存。那么这里就有一个问题了。 如果同一个 Activity 里出现了两个 id 相同的 View࿰