解读

国内面试中，这道题几乎必问，但大多数候选人只背“生命周期图”，却说不清“场景”和“底层代价”。面试官真正想确认两点：

1. 你是否理解“可见进程”与“冷/热启动”的差异；
2. 你能否据此推导出恢复页面时应做“最小化重建”还是“全量重建”。
   答不出“代价差异”或“内存复用”，就会被追问“为什么不用 onCreate 做恢复”。

知识点

1. 触发时机
   当 Activity 从“完全不可见”状态重新回到“可见”状态时，系统会先走 onRestart() → onStart() → onResume()。
   典型场景：

   • 用户按 Home 键退到桌面，再从最近任务返回；
   • 从当前 Activity 跳转到透明主题或对话框样式的 Activity，再关闭上层页面；
   • 分屏/折叠屏窗口模式切换，导致当前窗口从隐藏到重新显示；
   • 系统主题切换、权限弹窗、画中窗消失等配置变化未销毁 Activity 的情况。
     注意：若进程在后台被系统杀死，再点击图标回来，会重新走 Application → onCreate()，此时旧实例已不存在，不会调 onRestart()。

2. 与 onCreate() 的本质区别

   • 实例存亡：onCreate() 表示新实例诞生，需要 inflate 布局、初始化 ViewModel、注册监听器、请求初始数据；onRestart() 复用原实例，View 树、成员变量、FragmentManager 状态都在内存中。
   • 性能代价：onCreate() 伴随冷启动或重建，可能触发 IO、网络、大量反射；onRestart() 只做轻量级刷新，如重新注册广播、检查权限、刷新局部数据。
   • 状态来源：onCreate() 依赖 savedInstanceState 恢复；onRestart() 可直接使用内存中的缓存数据，也可结合 onStart() 内判断 intent 变化做增量更新。
   • 生命周期配对：onRestart() 只与 onStop() 成对出现，而不会与 onDestroy() 配对；onCreate() 与 onDestroy() 成对。

3. 国内“保活”误区
   部分厂商 ROM 会强制回收后台进程，开发者若在 onStop() 中释放大量资源，却在 onRestart() 不做懒加载，会导致返回时卡顿；正确姿势是在 onStop/onRestart 之间采用“轻量释放+延迟重建”策略，而非把初始化全写进 onCreate。

答案

onRestart() 仅在 Activity 实例未被销毁、从不可见重新变为可见时调用，常见场景包括用户从桌面返回、关闭透明页面、分屏窗口重新显示等。
onCreate() 则意味着系统新建了一个 Activity 实例，需要完整执行布局加载与初始数据准备；而 onRestart() 复用已有实例，只做轻量级刷新，因此性能开销远小于 onCreate()。简言之：onCreate() 是“生”，onRestart() 是“醒”。

拓展思考

1. 在折叠屏展开/收起时，同一 Activity 可能经历 onStop → onRestart 而不走 onDestroy，如何利用 onRestart() 快速校正布局方向与刷新 RecyclerView 缓存？
2. 若业务需要在返回时强制重新拉取网络数据，为何推荐把逻辑放在 onStart() 而非 onRestart()？（提示：onStart() 对首次可见和再次可见都统一回调，避免代码重复）
3. 结合 Android 13 的“前台服务权限”与“后台启动限制”，如何在 onRestart() 中判断应用是否具备自启动权限，从而决定是否弹窗引导用户手动授权？