API 28+中onSaveInstanceState与onStop执行顺序变更的原因、收益及其他因素咨询

1. 该变更带来的核心收益 #

• 彻底解决Fragment事务丢失/异常问题：在API 28之前，onSaveInstanceState()先于onStop()执行，开发者如果在onStop()中提交Fragment事务，要么触发IllegalStateException（系统禁止状态保存后提交事务），要么被迫用commitAllowingStateLoss()这种可能导致状态不一致的危险方法。调整顺序后，onStop()先执行，开发者可安全在此阶段处理Fragment事务，再由onSaveInstanceState()统一保存状态，完全规避这类问题。
• 状态保存更全面准确：旧顺序下，onStop()中完成的UI状态更新、数据调整可能来不及被onSaveInstanceState()捕获。现在先执行onStop()，该阶段的所有状态变更都能被后续的状态保存流程覆盖，保证恢复时状态的完整性。
• 简化开发者代码逻辑：无需额外判断生命周期阶段来规避事务提交限制，也不用为绕过异常使用不安全API，代码逻辑更简洁、可维护性更高。

2. 官方未明确提及的其他变更原因 #

• 对齐现代应用架构的生命周期最佳实践：随着Jetpack组件（如ViewModel、LiveData）的推广，官方倡导状态管理与UI操作分离。先执行onStop()（完成UI收尾、更新）再保存状态，符合“先完成UI清理，再持久化核心状态”的逻辑，和ViewModel的生命周期管理思路更契合。
• 适配后台应用限制的优化：API 28之后系统对后台应用行为限制更严格（比如后台启动Activity的限制），调整生命周期顺序后，系统可更合理调度状态保存时机，避免应用切换后台时因状态保存阻塞UI收尾流程，提升切换流畅度。
• 统一不同场景下的生命周期逻辑：早期Android版本中，屏幕旋转、内存回收、应用切后台等场景下，onSaveInstanceState()与onStop()的执行顺序存在细微差异，这次调整统一了所有场景的执行逻辑，减少开发者需要处理的特殊情况，降低踩坑概率。

内容的提问来源于stack exchange，提问作者Todor Kostov