这确实是一个一致性问题，因为方法onStop()仍然可以修改示例状态。
将onSaveInstanceState()移动到时间线末尾时，这些更改不会丢失。

虽然我不是Google的员工，也没有对此做出贡献，但如果我没有记错的话，这一更改也影响了活动，我可以想象，原因与以下事实有关：在此更改之前，如果/当框架认为onPause之后某种程度上合适时，可能会发生保存状态的调用。
这种行为是不可预测的，并且使得生命周期方法不可靠。
随着（Google Devs）对整个FragmentManager及其行为的重构，这种变化很可能是由一致性驱动的。（我不知道，也许还有其他我们不熟悉的技术细节）。
简而言之，框架现在在调用中是一致的，因为它们保证发生在 * onStop之后 *（对于API 28+），这确保了当您重新创建Activity/片段时，状态将是正确的（并被保存）。
就像我在一开始提到的，我不是一个Google开发人员，但是它以前的方式是一个不确定性的集群，这个变化带来了一些希望，使片段api免于最终的灭亡。
有时候，使用多个Activity已经不再酷了，我们都希望一个Activity包含许多片段，并且导航组件可以无缝地跨堆栈移动（不必担心原始设计中的“缺陷”），因为这一点和许多其他细节都是经过完善的，如果你想使用的话，我们可以使用更稳定的片段平台。
在所有这些“修复”之前，Framework API容易出现许多错误和不一致，有时会导致运行时崩溃。我可以想象，这一修复和许多其他修复是如何旨在将此API简化为一个完美的功能特性的，以便其他工具（如导航组件、生命周期、ViewModels等）都可以和谐地工作，而不必担心“哦，片段是特殊的并且需要进一步的逻辑来处理它的错误行为”。
尽管如此，随着越来越多的应用程序开始加入Jetpack Compose，Fragments正在慢慢地开始成为“一个老东西”。