为何不在Fragment的onCreateView中检查savedInstanceState，而推荐用onActivityCreated？

这个问题问到了Fragment生命周期设计的核心细节，我来给你掰扯清楚背后的原因：

• Activity状态未完全就绪：当onCreateView执行时，Fragment依附的Activity可能还没走完自己的onCreate流程。savedInstanceState里的恢复操作，有时不仅依赖Fragment自身的状态，还需要Activity已经初始化好的全局组件、数据源或者配置信息。这时候强行恢复状态，很容易因为Activity的依赖项未就绪，导致空指针或者状态不一致的异常。

• 视图层级未完全整合：onCreateView的核心职责是创建Fragment的视图结构，这时候视图刚被实例化出来，还没完成和Activity视图树的绑定，甚至连onViewCreated都还没执行（用来完成视图的初始化配置）。而onActivityCreated是在Activity的onCreate彻底完成后才触发的，此时Fragment的视图已经完全挂载，所有视图组件都处于可用状态，这时候恢复状态才不会出现“视图还没准备好就赋值”的问题。

• 官方生命周期的职责划分：Android官方对Fragment生命周期的设计里，onActivityCreated的定位就是处理依赖Activity初始化完成的操作，状态恢复正是其中典型场景。把状态恢复放在这里，能让onCreateView专注于视图创建，符合单一职责原则，代码逻辑更清晰，后期维护也更省心。

举个实际的例子：如果你的Fragment要从savedInstanceState恢复列表的滚动位置，而列表的Adapter依赖Activity提供的ViewModel数据源。在onCreateView时，Activity的ViewModel可能还没初始化完成，这时候去恢复滚动位置大概率会因为Adapter为空报错；但到了onActivityCreated，Activity的ViewModel已经就绪，Adapter也能正常获取数据，这时候恢复滚动位置就完全安全。

内容的提问来源于stack exchange，提问作者Kapil Jindal