企业官网建设流程全解析

面试官一开口问“Activity生命周期”，你到底该怎么答

做Android面试官的这些年，几乎每一轮技术面我都会从“说说Activity的生命周期”切入。这个问题看似基础，却是淘汰率相当高的一道题。多数候选人能背出onCreate、onStart、onResume这一串方法名，但一旦追问“旋转屏幕时走了哪些回调”“A页面跳B页面，onPause和onStop各在什么时候触发”“单例模式下生命周期会有什么变化”，很多人就开始含糊其辞。

这篇内容写给正在准备Android面试的朋友，也写给带新人想系统梳理知识点的团队老人。我不会只罗列API，而是把Activity生命周期涉及的关键知识点、常见变体、面试官的追问逻辑，以及一套可以直接套用的答题框架，全部拆开讲透。你不需要背题，理解了底层逻辑之后，任何问法都能接住。

1. 面试开场第一问：别急着背七兄弟，先画出状态机

1.1 一张状态图回答“Activity到底是什么”

面试官问生命周期，实际上是在考察你对Activity这个组件的理解深度。Activity不是一个孤立的类，它是Android四大组件中和用户交互最直接的一个，背后由ActivityManagerService（AMS）和ActivityThread协同管理。你背下来的每一次回调，本质上是AMS和ActivityThread在一次完整交互链路中，发给你的一组状态通知。

对应到系统层面，Activity存在四种稳定的运行状态：

• 运行态（Resumed）：Activity位于栈顶，可见且可交互，这是唯一能响应用户输入的状态。
• 暂停态（Paused）：Activity仍然可见，但失去焦点，无法响应输入。典型场景是被一个透明Activity或Dialog部分遮挡。
• 停止态（Stopped）：Activity完全不可见，但对象和状态仍在内存中保留，系统可能在任何时候回收它。
• 销毁态（Destroyed）：Activity被销毁或所在进程被系统杀掉，状态不复存在。

要特别注意，Resumed和Paused的区别在于“是否有焦点”，Paused和Stopped的区别在于“是否完全不可见”，Stopped和Destroyed的区别在于“对象是否还存在”。这几组边界关系，是面试中频繁出现的高频考点。

1.2 重绘、可见、焦点：三个关键词帮你把生命周期讲得有条理

讲到具体回调时，可以围绕三条主线展开：是否已经完成创建（重绘相关）、是否对用户可见、是否获得了焦点可交互。这样讲比单纯背方法名更有逻辑感，面试官也更容易get到你是真懂还是死记硬背。

拿一次冷启动举例：点开应用图标，系统创建进程，然后依次创建Application、启动MainActivity。onCreate里做初始化、绑定布局、初始化ViewModel；onStart执行时Activity已经可见但还不能交互，此时的界面可能尚未完全绘制完成；等到onResume执行，界面完全可见并且拿到焦点，可以正常点击操作。

这里有个容易被忽略的细节：onStart和onResume之间的区别，很多候选人答不上来。onStart表示Activity已经不可见变为可见，但此时它不一定在前台，不一定拿到焦点；onResume表示Activity处于栈顶并且正在与用户交互。打个比方，你把手机屏幕从包里拿出来，看到界面那一刻相当于onStart，你把手指放上去准备点击的那一刻，才相当于onResume。

2. 正常场景下的调用时序：一张表记住三种完整路径

2.1 冷启动、跳转、退出的完整回调序列

面试中频率最高的问法，就是让你完整描述“A页面跳转B页面”时两个页面各自的回调顺序。很多候选人只记得A先onPause，B再onCreate、onStart、onResume，然后A再onStop，但细节顺序经常出错。

标准时序如下：

注意到没有，A跳B时，A先执行onPause，然后B才会创建并走上自己的生命周期，等B完全启动之后，A才执行onStop。这个顺序体现了一个重要机制：系统必须在旧页面完全让出焦点之后，新页面才能开始创建。这也是为什么官方一直警告不要在onPause中做耗时操作——你卡住onPause，后面的新页面就得等着。

再说一个很冷门但面试官可能会试探的知识点：从B返回A时，A走的是onRestart而不是重新走一遍onCreate。onRestart和onStart的区别在于，Activity之前只是被遮挡，并未销毁，所以只需要重新对用户可见，不需要重新创建对象。这个设计是为了性能考虑，避免来回跳转页面时反复创建和销毁对象。

2.2 onPause和onStop的区别：为什么面试官揪着这个问题不放

面试官特别喜欢拿onPause和onStop做文章，因为这个问题的答案能反映候选人是否理解“可见但不可交互”和“完全不可见”这两种状态在系统资源分配上的差异。

核心差异有两点：

第一，调用时机不同。onPause发生在新Activity启动之前，此时旧页面可能还被新页面的入场动画遮挡一部分；onStop发生在新Activity已经完全启动并覆盖旧页面之后。从A跳B的实际过程中，A的onPause调用时画面仍然可见，onStop调用时画面已经看不见了。

第二，对系统资源和用户感知的影响不同。onPause阶段系统仍在绘制旧页面，你不能在这里大量释放资源，否则会出现界面闪白或动画卡顿。onStop阶段页面已经不可见，适合释放独占性资源，比如传感器监听、GPS定位、相机预览等。

另外要注意Android 12（API 31）之后的一个行为变化：系统对onPause期间能执行的操作增加了限制，如果应用在onPause里执行了太重的任务，系统会直接判定为卡顿甚至ANR。所以现在比较稳妥的做法是，把轻量级的暂停操作（比如暂停动画、暂停视频播放）放在onPause，把重量级的资源释放放到onStop或者更晚。

3. 配置变更与系统回收：面试区分度的第一道分水岭

3.1 旋转屏幕到底走了哪些回调？android:configChanges又是怎么回事

问完常规场景，面试官大概率会把问题升级到异常场景。旋转屏幕就是一个经典陷阱题。大部分候选人知道旋转屏幕会重建Activity，但具体走了哪些回调、数据怎么保留，往往讲不清楚。

默认情况下，旋转屏幕会触发完整的销毁重建流程：Activity先执行onPause、onStop、onDestroy，然后重新创建，执行onCreate、onStart、onResume。旋转前后的两个Activity不是同一个对象，你原本在onCreate里加载的数据如果没做保存，就会全部丢失。

那么怎么保存数据？系统会通过onSaveInstanceState回调，把界面状态数据保存到一个Bundle里。这个回调在onStop之前调用，具体时机在onPause之后、onStop之前（不同系统版本略有差异），你需要在这个方法里把临时数据写入Bundle。Activity重建时，这个Bundle会作为参数传到新Activity的onCreate方法里，同时也会传给onRestoreInstanceState，你可以在这两个方法的任意一个中恢复数据。

这里有几个关键细节：

• onSaveInstanceState只在Activity被异常销毁时才会调用，按返回键正常退出时不会调用。
• 调用时机上，操作系统的处理顺序是：onPause → onSaveInstanceState → onStop。
• 恢复数据时，onCreate和onRestoreInstanceState的调用时机不同。onCreate在setContentView之前调用，onRestoreInstanceState在onStart之后调用。如果恢复数据依赖View已经被创建，应该选择onRestoreInstanceState。
• 对于Fragment，需要调用Fragment的onSaveInstanceState，并给Fragment设置setRetainInstance(false)（现在已废弃，建议用ViewModel），否则Fragment内部状态也会丢失。

另一种避免重建的方案是android:configChanges属性。如果你在AndroidManifest.xml里给Activity配置了android:configChanges="orientation|screenSize"，那么屏幕旋转时Activity不会走销毁重建流程，而是回调onConfigurationChanged方法。这个方法比较适合视频播放器这类不希望在旋转时打断播放进度的场景。但要注意，这个方案只对配置变更类的事件生效，如果是进程被系统杀死，该方案完全无效。

3.2 onSaveInstanceState的数据恢复：哪些数据该存、哪些不该存

讲到这里顺便补充一个实战经验：onSaveInstanceState并不是万能的，它适合保存轻量级UI状态数据，比如输入框内容、滚动位置、开关状态，这类数据放在Bundle里序列化成本低、恢复快。不适合放大量业务数据，更不适合放大对象或Bitmap，因为Bundle的容量有限，写入和读取都会产生额外开销。

如果你的页面数据量大、数据结构复杂，更推荐用ViewModel来承载。ViewModel的生命周期独立于Activity的销毁重建过程，屏幕旋转时ViewModel不会销毁，数据能自动存活。这也是官方现在强烈推荐的做法——把界面状态分散在onSaveInstanceState和ViewModel两层，前者管临时UI状态，后者管业务数据。

关于系统内存回收，还有一个面试高频点：Android系统在内存不足时会按照一定优先级回收进程，优先级最低的是空进程，其次是后台Activity（对应Stopped状态的Activity），再往上是服务进程、可见进程，最顶层是前台进程。当后台Activity被系统回收后，用户再按返回键回到该Activity时，系统会尝试恢复之前保存的onSaveInstanceState状态，如果数据没保存好，页面的体验就是“闪了一下又回到初始界面”。

3.3 后台进程被系统回收（DontKeepActivities）下的状态流转

开发者选项里有一个“不保留活动”选项，开启后后台Activity会被立刻销毁。很多候选人没试过这个开关，导致实际开发中遇到Activity被系统回收的问题时一脸茫然。

开启“不保留活动”后，从A跳B，A的onSaveInstanceState、onStop、onDestroy会全部触发。此时A不是简单的停止，而是真正被销毁了。当用户从B返回A时，系统会基于之前保存的onSaveInstanceState状态重建A，但对象的创建过程和你手动启动一个Activity不完全一样——重建后的A进程如果已经被杀死，系统会先重启应用进程，再走到Activity的onCreate。

面试中谈到这个场景时，可以顺手延伸一句：为什么Activity被系统回收后还能恢复到之前的界面状态，靠的就是onSaveInstanceState和AMS里保存的任务栈信息。AMS记录了每个任务栈里Activity的内部状态，当需要恢复时，ActivityThread会拿着这些信息去重新创建Activity。这一句话就能让面试官觉得你对系统回收机制有完整的认知。

4. 与启动模式、透明主题纠缠时的生命周期变体

4.1 四种启动模式如何改写你背熟的时序

面试进行到这一步，面试官通常会引入启动模式来考察你对生命周期变体的理解。Activity有四种启动模式：standard、singleTop、singleTask、singleInstance。不同模式下，启动同一个Activity时它的生命周期表现完全不同。

standard模式：每次启动都会创建新实例。从A启动A，两个实例会加载两份，生命周期正常走一遍。

singleTop模式：如果启动的Activity已经位于任务栈栈顶，则不会创建新实例，而是回调onNewIntent，同时onPause、onResume会重新走一遍，onCreate、onStart不会被调用。这个模式适合处理通知栏点击跳转之类的场景，避免重复推送界面。

singleTask模式：如果启动的Activity在任务栈中已经存在，系统会直接把该Activity上面的所有Activity全部出栈，让目标Activity回到栈顶，然后回调onNewIntent。这里会发生一组特殊的生命周期：栈顶之上的Activity依次走onPause、onStop、onDestroy，目标Activity走onNewIntent → onRestart → onStart → onResume。所以这种情况下，目标Activity会经历一次重新可见的过程，你需要确保onNewIntent里的新数据处理不会被旧数据覆盖。

singleInstance模式：这是一种比singleTask更极端的模式，Activity会单独占有一个任务栈。它的生命周期变化和singleTask类似，但涉及任务栈切换，从该Activity回到其他应用时会有不同的转场表现。面试中只要提到“该Activity是栈中唯一实例，系统不会在其上叠加其他Activity”就可以，过度深入反而容易被追问到细节。

关于onNewIntent，还有个高频追问：为什么有了onNewIntent之后，Activity还要走onResume？因为singleTop/singleTask模式复用已有实例时，系统需要让该Activity重新回到前台，而回到前台的过程必然要经过可见和获焦两个阶段。onNewIntent是告诉“你有新数据来了”，onResume是告诉“你现在可以交互了”，两者职责不同，不能混为一谈。

4.2 透明Activity、Dialog、半屏Activity的特殊状态

除了启动模式，页面形态也会影响生命周期。很多人一提到“可见但不可交互”就觉得一定是Dialog导致的，其实透明Activity也属于这个范畴。

当你设置一个Activity的背景为透明主题（比如Theme.Translucent.NoTitleBar），并把它放在另一个Activity之上时，在它启动的瞬间，底层Activity只会进入onPause状态，而不会进入onStop状态，因为底层Activity仍然部分可见。这种情况下，底层Activity无法交互，但仍然在绘制，系统会持续维持它的可见状态。这带来一个实际问题：如果在底层Activity的onPause里做了重量级操作（比如停止视频播放、释放相机），透明Activity弹出时用户会看到底层画面卡住或变黑，体验很差。

处理方式很简单：尽量不在onPause里做跟可见性强相关的操作，这类操作应该放到onStop里去执行。对于透明Activity场景，你需要接受底层Activity停在onPause的事实，在onResume里做恢复操作时也要考虑“可能被透明Activity覆盖导致onPause/onResume频繁触发”。

Dialog窗口也有类似的坑。Dialog本质上是一个独立的Window，它显示的时候不会导致Activity进入onPause（Dialog不会让Activity失去焦点），但DialogFragment则不同，DialogFragment底层是一个Dialog窗口，底层Activity会进入onPause状态。所以面试中如果问到Dialog和DialogFragment的区别，从生命周期这个角度切入是最稳妥的答案。

4.3 Fragment与Activity的生命周期联动

Activity和Fragment之间的生命周期联动是很多面试官喜欢的进阶题。Fragment的生命周期依附于宿主Activity，但又有自己的回调方法，比如onAttach、onCreateView、onViewCreated、onDestroyView等。

常见问题是：“Activity执行onCreate时，Fragment走到了什么状态？”答案依赖Fragment的添加时机。如果Fragment是在Activity的onCreate里通过FragmentTransaction提交的，那么此时Fragment会依次执行onAttach、onCreate、onCreateView、onViewCreated、onActivityCreated（已废弃）、onStart。也就是说，Activity的onCreate调用结束后，Fragment已经走完了自己创建相关的流程，但onStart、onResume还要等宿主Activity继续执行。

如果面试官问：“Activity和Fragment生命周期方法之间的调用顺序是什么？”可以参考这个简化表格：

特别要注意onDestroyView和onDestroy的区别。Fragment的onDestroyView在视图被销毁时调用，此时Fragment对象仍然存在；onDestroy在Fragment本身被销毁时调用。如果Fragment只是从容器中移除但没被销毁，onDestroy不会被调用。这个知识点常被用来考察候选人是否理解Fragment视图和实例的生命周期差异。

另外，FragmentTransaction的add、replace、remove也会改变Fragment的生命周期。replace会先销毁旧Fragment（走onPause → onStop → onDestroyView → onDestroy），再创建新Fragment（走onAttach → onCreate → onCreateView…）。如果只是hide和show，Fragment不会执行onDestroyView，只是视图被隐藏了，生命周期停留在onCreateView之后的状态。这个差异在实际项目里直接影响数据加载和UI更新的时机。

5. 我总结的答题框架：从背方法名到讲原理

5.1 一个通用的三层回答结构

面试中遇到生命周期相关问题，我不建议直接从方法名开始背，而是采用“状态-场景-机制”三层结构来回答。这样既能把知识串联成体系，又能展示你的思维层次。

第一层「状态」：先说Activity的四态转换，说明哪些状态之间可以平滑切换，哪些状态会被系统回收。这一段主要证明你理解了生命周期存在的意义。

第二层「场景」：选择面试官问到的具体场景，按调用顺序列出回调序列。这一段要精确到方法的先后，特别是容易混淆的onPause/onStop、onSaveInstanceState/onRestoreInstanceState。

第三层「机制」：把场景背后的系统原理讲清楚。比如为什么旋转屏幕要重建Activity，为什么onSaveInstanceState要在onStop之前调用，为什么tintActivity下的Activity不会走onStop，这些机制层面的解释才是面试官真正想听到的区分度。

5.2 高频追问与参考回答示例

为了让你更直观地感受这个框架的应用，我把几道高频题拆成参考回答的骨架，你可以按这个风格自己组织语言：

问：“A页面启动B页面，两个页面的生命周期顺序是什么？”

参考框架：先按场景列出顺序（A.onPause → B.onCreate → B.onStart → B.onResume → A.onStop），再解释机制（旧页面必须先让出焦点，新页面才能创建；A的onStop在B完全启动之后才触发，是为了保证转场动画期间A仍然可以绘制）。

问：“旋转屏幕时Activity会经历哪些生命周期？数据怎么保留？”

参考框架：先说明默认行为（销毁重建：onPause → onStop → onDestroy → onCreate → onStart → onResume），再讲数据保留手段（onSaveInstanceState、ViewModel）、android:configChanges的局限（只对配置变更有效，进程被杀无效），最后补充恢复数据的选择（onCreate vs onRestoreInstanceState的区别）。

问：“后台Activity被系统回收后，用户回到这个页面会发生什么？”

参考框架：先说明进程优先级和回收条件，再讲系统如何恢复Activity（通过AMS保存的任务栈和状态Bundle重建），最后强调onSaveInstanceState的必要性以及ViewModel在这种场景下的局限（进程被杀后ViewModel也会丢失，需要用SavedStateHandle）。

问：“singleTask模式下启动一个已有实例的Activity，生命周期怎么变化？”

参考框架：先说明系统会清空该Activity之上的所有界面，然后这个Activity走onNewIntent → onRestart → onStart → onResume。再补充为什么会有onRestart（因为实例还在但曾经离开过前台），以及onNewIntent和onResume的职责区别。

这几个示例都是按“现象→顺序→机制→应对方案”的逻辑组织的，面试中哪怕问题千变万化，只要锁定这个框架，基本都能把答案组织得完整且有深度。

我个人在准备面试和实际带队面试新人的过程中，最大的体会是：生命周期这个专题，背住方法名只能过第一轮，真正拉开差距的是对异常场景和系统机制的理解。你不需要把每个API的源码细节都背下来，但至少要在脑子里形成“四态模型 + 常规时序 + 异常重建 + 模式变体”的知识地图。把这几个图层串起来，再刁钻的追问都能应对。希望这份拆解对你有帮助，面试顺利。