【Android FrameWork】第二十四天：Activity生命周期是如何运行的

Activity生命周期

Activity作为Android应用的核心组件，其生命周期的有序流转是应用稳定性和系统资源调度的关键保障。

从应用层视角看，开发者只需重写onCreate、onStart、onResume等回调方法，但这些方法的调用时机、执行顺序乃至跨进程协调，均由Android Framework层的核心服务与机制深度管控。

本文将从Framework层的核心组件、通信机制、流程调度等维度，解析Activity生命周期的管控逻辑。

生命周期管控的核心组件体系

Framework层对Activity生命周期的管控依赖于system_server进程 与应用进程的协同，核心组件可分为三类：

1. System_server进程中的管控中枢

ActivityManagerService（AMS）：整个Android系统的Activity生命周期总控中心，负责接收应用进程的Activity操作请求（如startActivity）、管理Activity的栈结构（Task/Stack）、调度生命周期状态的切换，并通过跨进程通信向应用进程下发指令。
ActivityStack（ActivityStackSupervisor/TaskStack）：AMS的核心辅助组件，负责维护Activity的栈式结构（TaskStack管理Task，Task管理ActivityRecord），处理Activity的入栈、出栈、栈顶切换等逻辑，是AMS决策生命周期状态的重要依据。
ActivityRecord：AMS中对单个Activity的抽象表示，记录了Activity的组件信息（ComponentName）、启动模式（launchMode）、状态（RESUMED/PAUSED/STOPPED等）、所属Task等关键数据，是AMS追踪Activity生命周期的最小单元。

2. 应用进程中的执行载体

ActivityThread：应用进程的主线程管理类，负责应用进程的初始化、主线程消息循环（Looper/Handler）的维护，以及接收AMS的指令并执行Activity的创建、生命周期回调等实际操作，是应用进程中生命周期执行的核心入口。
ApplicationThread ：ActivityThread的内部类，实现了IApplicationThread Binder接口，作为应用进程向system_server进程暴露的"通信端点"，负责接收AMS下发的跨进程指令（如scheduleLaunchActivity、schedulePauseActivity），并将指令转发给ActivityThread的主线程Handler（H）处理。
H（ActivityThread$H）：ActivityThread的主线程Handler，负责处理ApplicationThread转发的AMS指令，将跨进程调用转换为主线程的同步执行，确保生命周期回调在UI线程（主线程）中执行。

3. 生命周期执行的工具类

Instrumentation：应用进程中的"生命周期执行器"，由ActivityThread调用，负责Activity的实例化（通过类加载器创建Activity对象）、Context的初始化（ContextImpl）、以及生命周期方法的直接调用（如callActivityOnCreate、callActivityOnResume），是连接ActivityThread与Activity实例的桥梁。

跨进程通信

Activity生命周期的管控本质是system_server进程（AMS） 与应用进程（ActivityThread） 的跨进程协作，通信依赖Android的Binder机制，核心交互流程为：

应用进程→AMS ：应用进程通过ActivityManagerProxy（IActivityManager）向AMS发起跨进程请求（如startActivity），请求参数包含Activity的组件信息、启动参数等。
AMS→应用进程 ：AMS处理完请求后，通过ApplicationThreadProxy（IApplicationThread）向应用进程的ApplicationThread下发指令（如scheduleLaunchActivity），指令携带ActivityRecord的序列化数据（如Intent、ActivityInfo）。
应用进程内部转发：ApplicationThread接收到指令后，将其封装为Message并发送给ActivityThread的主线程Handler（H），由H在主线程中处理并执行实际的生命周期操作。

这种"应用进程请求-AMS决策-应用进程执行"的跨进程模式，确保了系统对所有应用的Activity生命周期进行统一管控，避免了应用进程的自主无序调度。

Framework管控逻辑

以启动一个新Activity（ActivityA→ActivityB） 为例，解析Framework层对生命周期的具体管控步骤：

1. 应用进程发起启动请求

ActivityA中调用startActivity(intent)，最终通过ActivityManagerProxy向AMS发起startActivity跨进程请求，请求链为：
Activity.startActivity() → Instrumentation.execStartActivity() → ActivityManagerProxy.startActivity() → AMS.startActivity()

2. AMS的栈管理与决策

AMS接收到请求后，执行以下核心逻辑：

权限与合法性校验：检查应用是否有启动ActivityB的权限、ActivityB是否在Manifest中注册等。
ActivityRecord创建：为ActivityB创建ActivityRecord对象，记录其组件信息、启动模式、所属Task等。
栈结构调整：由ActivityStackSupervisor/TaskStack处理ActivityB的入栈逻辑（如根据launchMode决定新建Task或加入现有Task、是否需要将栈中其他Activity压入后台等）。
生命周期状态决策 ：AMS根据栈结构变化，决策需要执行的生命周期切换：
- 若ActivityA需退至后台，需先执行其onPause；
- 若ActivityB为新创建，需执行其onCreate→onStart→onResume；
- 若ActivityB为已存在的栈内Activity（如singleTop模式），则执行其onNewIntent+onResume。

3. AMS向应用进程下发指令

AMS通过ApplicationThreadProxy向应用进程的ApplicationThread下发指令：

先下发schedulePauseActivity指令，要求应用进程执行ActivityA的onPause；
待ActivityA的onPause执行完成后，下发scheduleLaunchActivity（或scheduleResumeActivity）指令，要求应用进程创建并启动ActivityB。

4. 应用进程执行生命周期回调

ApplicationThread接收指令：将AMS的指令封装为Message，发送给ActivityThread的主线程Handler（H）。
H处理Message ：
- 处理PAUSE_ACTIVITY消息：调用ActivityThread.handlePauseActivity()，通过Instrumentation执行ActivityA的onPause，并向AMS反馈执行完成（ActivityManagerProxy.activityPaused()）。
- 处理LAUNCH_ACTIVITY消息：调用ActivityThread.handleLaunchActivity()，执行以下核心操作：
  1. Activity实例化：通过Instrumentation创建ActivityB对象，初始化ContextImpl、Application等。
  2. 执行onCreate ：调用Instrumentation.callActivityOnCreate()，触发ActivityB的onCreate回调（此时可执行布局加载、数据初始化等操作）。
  3. 执行onStart ：在handleLaunchActivity后续流程中，调用ActivityThread.handleStartActivity()，通过Instrumentation执行ActivityB的onStart。
- 处理RESUME_ACTIVITY消息：调用ActivityThread.handleResumeActivity()，通过Instrumentation执行ActivityB的onResume，并将ActivityB设置为应用进程的"当前Activity"（mResumedActivity），同时向AMS反馈执行完成（ActivityManagerProxy.activityResumed()）。

至此，ActivityB完成从创建到前台可见可交互的生命周期流转，而ActivityA则完成onPause并退至后台（若需进一步退至Stopped状态，AMS会后续下发scheduleStopActivity指令，触发其onStop）。

特殊场景的生命周期管控逻辑

Framework层对Activity生命周期的管控不仅覆盖常规启动流程，还需处理配置变化、进程回收、Activity销毁等特殊场景：

1. 配置变化（如屏幕旋转）的管控

当系统配置发生变化（如屏幕旋转、语言切换）且Activity未设置android:configChanges时，AMS的管控逻辑为：

AMS检测到配置变化后，决策销毁并重建Activity，先下发schedulePauseActivity→scheduleStopActivity→scheduleDestroyActivity指令，触发Activity的onPause→onStop→onDestroy。
AMS保存Activity的状态（通过onSaveInstanceState，由Instrumentation调用），并重新发起Activity的启动请求，执行新Activity的onCreate（传入保存的状态Bundle）→onStart→onRestoreInstanceState→onResume，完成重建。

2. Activity退后台与前台恢复的管控

当用户按下Home键或启动其他应用时，AMS的管控逻辑为：

栈顶Activity（ActivityB）需退后台：AMS先下发schedulePauseActivity触发onPause，再下发scheduleStopActivity触发onStop（若长时间后台，AMS可能触发应用进程的低内存回收，此时Activity会被标记为STOPPED状态，进程被杀后再次启动需重建）。
当用户再次打开应用时，AMS从ActivityRecord中读取栈顶Activity信息，下发scheduleStartActivity→scheduleResumeActivity，触发Activity的onRestart→onStart→onResume（若进程未被回收）或重建（若进程已被杀）。

3. Activity销毁（finish）的管控

当Activity调用finish()时，管控逻辑为：

应用进程向AMS发起finishActivity跨进程请求，AMS接收后调整栈结构（将对应的ActivityRecord出栈），并下发schedulePauseActivity→scheduleStopActivity→scheduleDestroyActivity指令。
应用进程执行Activity的onPause→onStop→onDestroy，并释放Activity实例资源，AMS最终清理对应的ActivityRecord，完成生命周期的终结。

生命周期管控的线程模型约束

Framework层对Activity生命周期的执行线程有严格约束，核心规则为：

AMS的决策逻辑 ：运行在system_server进程的主线程（ActivityThread） 中，system_server进程的ActivityThread与应用进程的ActivityThread是不同的实例，但其同样依赖Looper/Handler处理消息。
应用进程的生命周期执行 ：所有Activity的生命周期回调（onCreate/onStart/onResume等）必须在应用进程的主线程（UI线程） 中执行，这一约束由ActivityThread的H Handler保证------ApplicationThread接收的跨进程指令会被转发到主线程的MessageQueue，由Looper在主线程中串行处理。
跨进程指令的异步性 ：AMS下发的指令为异步调用，应用进程执行完成后需向AMS反馈（如activityPaused()/activityResumed()），AMS需等待反馈后再执行后续的生命周期调度（如等待ActivityA的onPause完成后，再执行ActivityB的onResume），确保生命周期的执行顺序严格有序。

总结

Android Framework层对Activity生命周期的管控本质是**"中心化决策+分布式执行"** 的架构设计：

中心化决策：由system_server进程的AMS统一管理全系统的Activity栈结构和生命周期状态，确保系统层面的资源调度（如内存、CPU）与Activity的生命周期协同，避免应用进程的自主调度导致系统混乱。
分布式执行：应用进程负责Activity的实际创建和生命周期回调执行，通过Binder跨进程通信与AMS解耦，既保证了系统的统一管控，又赋予了应用进程一定的独立性（如自定义生命周期逻辑的实现）。