Android Framework AMS（03）AMS关键类解读

该系列文章总纲链接：专题总纲目录 Android Framework 总纲

---

本章关键点总结 & 说明：

说明：本章节主要涉AMS的关键类及其设计理念的解读，主要关注图中下方AMS关键类解读部分即可。这么做的目的是为了后面章节分析AMS时更容易理解其相关概念和相关流程。毕竟AMS涉及的关键类较多，直接看流程会导致很多地方不容易理解。

在Android系统中，AMS（ActivityManagerService）是Android系统中非常核心的服务，主要负责应用程序的管理和调度。以下是一些与AMS框架层代码相关的核心类，以及它们的简要介绍：

1. ActivityManagerService (AMS): 这是Android系统中负责管理应用程序生命周期和进程调度的核心服务。它处理Activity、Service、Broadcast Receiver等组件的启动、切换和销毁，以及进程的管理和调度。

2. ActivityStack: 用于管理任务栈，每个ActivityStack对应一个任务栈，存储应用程序的Activity实例，并维护它们的启动和切换顺序。

3. ProcessRecord: 管理应用程序的进程，每个ProcessRecord对应一个应用程序的进程，存储包名、进程名、进程ID等信息，以及该进程中运行的Activity实例。

4. TaskRecord: 管理应用程序的任务，每个TaskRecord对应一个应用程序的任务，维护Activity的启动顺序和切换顺序。

5. ActivityStackSupervisor: 负责监督Activity栈的管理，包括启动新的Activity、处理Activity的切换和任务栈的调度。

6. ActivityThread: 应用程序的入口点，负责创建应用程序的主线程，管理应用程序的运行时环境，包括上下文的创建和资源的加载。

7. Instrumentation: 用于监控应用程序的生命周期，包括Activity的创建、启动和销毁。

8. ActivityManagerNative 和 ActivityManagerProxy: 这两个类实现了AMS的客户端和服务端的通信，通过Binder机制进行进程间通信。

9. ActivityManager: 应用程序可以通过这个类与AMS进行交互，管理Activity的生命周期。

这些类共同构成了AMS框架的核心，它们协同工作，确保了Android系统中应用程序的正常运行和资源的有效管理。接下来将这些核心类以不同的职责来进行分类，便于后续更容易理解整个AMS的设计。

1 AMS核心类

1.1 AMS核心类的概念解读

• ActivityManagerService (AMS)：AMS是Android系统中负责管理应用程序生命周期和进程调度的核心服务。它处理Activity、Service、Broadcast Receiver等组件的启动、切换和销毁，以及进程的管理和调度。
• ActivityStackSupervisor： 负责监督Activity栈的管理，包括启动新的Activity、处理Activity的切换和任务栈的调度。
• ActivityTaskSupervisor：ActivityStackSupervisor的职责被ActivityTaskSupervisor所接管，负责监督和管理系统中所有的Activity任务。

1.2 AMS核心类的设计理念整体解读

ActivityManagerService (AMS)、ActivityStackSupervisor 和 ActivityTaskSupervisor 这几个类在 Android 系统中共同构成了应用程序管理和调度的核心架构。它们的设计理念可以概括为以下几点：

• 集中管理：AMS 作为核心服务，集中管理应用程序的生命周期和进程调度，确保系统资源的合理分配和应用程序的稳定性。
• 职责分离：AMS 处理广泛的管理任务，而 ActivityStackSupervisor 和 ActivityTaskSupervisor 专注于 Activity 的具体管理和调度，这种分离有助于提高代码的可维护性和扩展性。
• 任务和栈的抽象：通过 ActivityStackSupervisor 和 ActivityTaskSupervisor，系统将 Activity 的组织和管理抽象化为任务和栈的概念，使得 Activity 的启动、切换和销毁更加有序和高效。
• 用户界面的连贯性：这些类的设计确保了用户界面的连贯性和响应性，通过合理的任务栈管理，为用户提供了直观的导航体验。
• 资源优化：AMS 和它的辅助类通过监控和调度应用程序的运行状态，优化系统资源的使用，如内存和 CPU，以提高整体性能。
• 灵活性和扩展性：这种分层的设计允许 Android 系统灵活地添加新的组件和功能，同时保持现有系统的稳定性。
• 安全性：AMS 通过控制应用程序的启动和运行，确保了应用程序之间的隔离和安全性。
• 响应用户操作：ActivityStackSupervisor 和 ActivityTaskSupervisor 快速响应用户操作，如启动新 Activity 或返回到前一个 Activity，保证了用户操作的即时反馈。

整体来看，这些类的设计体现了 Android 系统对于应用程序管理的深度思考，旨在提供一个稳定、高效、安全且用户友好的应用程序执行环境。

1.3 AMS核心类的设计理念详细解读

1.3.1 ActivityManagerService (AMS) 的设计理念

ActivityManagerService (AMS) 是 Android 系统中负责管理应用程序生命周期和进程调度的核心服务。它的设计理念包括：

• 统一管理：AMS 作为系统服务，统一管理所有应用程序的生命周期和进程调度，确保系统资源的合理分配和应用程序的稳定性。
• 模块化设计：AMS 将不同的管理职责划分为多个模块，如 Activity、Service、Broadcast Receiver 等，使得系统更加模块化，便于维护和扩展。
• 资源优化：AMS 通过监控和调度应用程序的运行状态，优化系统资源的使用，如内存和 CPU，以提高整体性能。
• 安全性：AMS 控制应用程序的启动和运行，确保了应用程序之间的隔离和安全性。
• 响应性：AMS 快速响应系统事件和用户操作，如启动新应用或切换应用，保证了系统响应的即时性。

1.3.2 ActivityStackSupervisor 的设计理念

ActivityStackSupervisor 负责监督 Activity 栈的管理，包括启动新的 Activity、处理 Activity 的切换和任务栈的调度。它的设计理念包括：

• 任务抽象：将 Activity 的组织和管理抽象化为任务和栈的概念，使得 Activity 的启动、切换和销毁更加有序和高效。
• 用户界面的连贯性：通过合理的任务栈管理，为用户提供了直观的导航体验。
• 灵活性：支持多任务和多栈的管理，使得系统可以灵活地处理复杂的用户交互。
• 响应用户操作：快速响应用户操作，如启动新 Activity 或返回到前一个 Activity，保证了用户操作的即时反馈。

1.3.3 ActivityTaskSupervisor 的设计理念

ActivityTaskSupervisor 在 Android 5.0 及以后的版本中接管了 ActivityStackSupervisor 的职责，负责监督和管理系统中所有的 Activity 任务。它的设计理念包括：

1. 统一任务管理：统一管理所有 Activity 任务，简化了任务管理和调度的复杂性。

2. 任务和栈的抽象：通过任务和栈的抽象，提供了一种更加清晰和高效的方式来组织和管理 Activity。

3. 用户界面的连贯性：通过合理的任务管理，确保了用户界面的连贯性和响应性。

4. 扩展性：支持新的组件类型和任务管理策略，使得系统可以灵活地扩展新的功能。

5. 性能优化：通过优化任务调度和栈管理，提高了系统的性能和响应速度。

总的来说，这三个类的设计理念体现了 Android 系统对于应用程序管理的深度思考，旨在提供一个稳定、高效、安全且用户友好的应用程序执行环境。

2 AMS任务和栈管理

ActivityStack 类在 AMS 中的作用是管理应用程序的 Activity 栈，维护 Activity 的启动顺序和状态，处理 Activity 的切换和任务栈的调度。TaskRecord 类在 AMS 中的作用是表示一个任务，记录和管理任务中 Activity 的启动顺序和历史记录，支持多任务和多栈的管理。接下来对这2个类分别进行解读。

2.1 ActivityStack 解读

2.1.1 ActivityStack 解读

ActivityStack 是 Android 系统中用于管理任务栈的数据结构。每个 ActivityStack 对应一个任务栈，它管理着多个 TaskRecord，这些任务栈代表了用户与应用交互的界面序列。ActivityStack 维护了任务的顺序，确保了用户可以通过按下返回键来正确地退出当前任务。

2.1.2 ActivityStack 类 设计理念

• 任务管理：ActivityStack 负责管理任务的生命周期和状态，包括任务的创建、切换和销毁。
• 顺序维护：它保持了任务的启动顺序，使得用户界面的导航变得直观。
• 响应用户操作：用户的操作（如按下返回键）会通过 ActivityStack 来响应，从而维护用户预期的体验。

2.2 TaskRecord 类解读

2.2.1 TaskRecord 解读

TaskRecord 代表了一个任务，它是 ActivityStack 的组成部分。每个 TaskRecord 包含了一系列的 ActivityRecord，这些记录代表了任务中的每一个活动。

2.2.2 TaskRecord 类 设计理念

• 任务隔离：每个 TaskRecord 都是独立的，保证了任务之间的隔离性。
• 后进先出（LIFO）：TaskRecord 中的 ActivityRecord 遵循后进先出的原则，这与用户期望的返回操作行为一致。
• 任务可识别：每个 TaskRecord 都有一个唯一的标识符，便于系统识别和管理。

ActivityStack 和 TaskRecord 共同构成了 Android 中任务管理和活动记录的基础设施。ActivityStack 作为任务的集合，管理着用户与应用的交互流程，而 TaskRecord 则记录了单个任务中的活动历史。这种设计使得 Android 能够有效地管理多任务和提供流畅的用户体验。

3 AMS进程和实例管理

ProcessRecord 类 和 ActivityRecord 类 在 Android 系统中扮演着重要的角色，它们是 ActivityManagerService (AMS) 用来管理应用程序和其组件的关键数据结构。接下来对其分别进行解读.

3.1 ProcessRecord 类解读

3.1.1 ProcessRecord 解读

ProcessRecord 是 AMS 中用来描述和管理每一个进程的数据结构。它包含了进程的详细信息，如进程ID（pid）、用户ID（uid）、进程名、进程的优先级、进程状态等。此外，它还关联了该进程中运行的所有组件，包括 Activity、Service、BroadcastReceiver 和 ContentProvider。

3.1.2 ProcessRecord 类 设计理念

• 唯一标识：每个进程都有一个唯一的 ProcessRecord，无论它包含多少组件。
• 生命周期管理：ProcessRecord 存储了进程的生命周期信息，AMS 通过这些信息来管理进程的启动、运行和销毁。
• 资源调度：系统根据 ProcessRecord 中的优先级信息来调度 CPU 和内存资源。
• 安全隔离：每个进程都是一个独立的沙箱，确保应用程序之间的安全隔离。

3.2 ActivityRecord 类解读

3.2.1 ActivityRecord 解读

ActivityRecord 是 AMS 用来跟踪和管理单个 Activity 的数据结构。它记录了 Activity 的详细信息，包括 Activity 的名字、Intent、启动模式、状态、关联的 Task（任务栈）等。

3.2.2 ActivityRecord ​​​​​​​类 设计理念

• 组件管理：每个 Activity 组件在 AMS 中都有一个对应的 ActivityRecord，AMS 通过这些记录来管理 Activity 的生命周期。
• 任务关联：ActivityRecord 与其所在的 Task（通过 TaskRecord 表示）有关联，这有助于管理系统中的任务栈。
• 状态跟踪：ActivityRecord 跟踪 Activity 的状态变化，如初始化、运行中、暂停、停止等。
• 历史记录：系统使用 ActivityRecord 来维护 Activity 的历史记录，这对于用户按下“返回”按钮时恢复之前的 Activity 非常重要。

ProcessRecord 和 ActivityRecord 共同支持 AMS 管理应用程序的进程和组件。ProcessRecord 作为进程的抽象，包含了运行在该进程下的所有组件的记录，而 ActivityRecord 则专注于单个 Activity 的管理。两者的设计都体现了 Android 系统对于组件生命周期和资源管理的细致考虑。

4 AMS应用程序运行时环境相关类解读

4.1 ActivityThread类解读

ActivityThread 是用程序的入口点，负责创建应用程序的主线程，管理应用程序的运行时环境，包括上下文的创建和资源的加载。

ActivityThread 类 是 Android 应用程序中非常核心的一个类，它代表了应用程序的主线线程，也就是 UI 线程。它的主要作用如下：

• 主线程管理：ActivityThread 是 Android 应用的入口点，负责启动应用程序的主线程，即 UI 线程。这个线程负责处理所有 UI 事件和界面更新。
• 生命周期管理：它管理着四大组件（Activity、Service、BroadcastReceiver、ContentProvider）的生命周期回调。当 AMS（ActivityManagerService）需要启动或停止这些组件时，它会通过 IPC（进程间通信）向对应的 ActivityThread 发送消息，由 ActivityThread 在主线程中执行相应的生命周期方法。
• 消息循环：在 ActivityThread 的 main() 方法中，会准备主线程的 Looper，这样主线程就具备了消息循环的能力，可以处理各种系统和应用消息。
• 资源管理：ActivityThread 负责加载和创建应用程序的资源，包括字符串、颜色、布局文件等。
• IPC 通信：它通过内部类 ApplicationThread（实现了 IApplicationThread 接口）与 AMS 进行通信，接收 AMS 的指令来创建或销毁组件。

接下来解读ActivityThread 这个类的设计理念：

4.2 ActivityThread的设计理念

• 单一职责：ActivityThread 专注于管理应用的主线线程和组件生命周期，保持了职责的单一性。
• 解耦合：通过 Binder IPC 机制与 AMS 通信，使得应用进程与系统服务进程之间保持了解耦。
• 封装性：ActivityThread 封装了主线线程的创建和消息循环的逻辑，对外提供统一的接口来管理组件生命周期。
• 扩展性：通过内部类和消息机制，ActivityThread 可以灵活地扩展新的组件类型或者处理新的系统请求。
• 性能优化：主线程负责 UI 渲染和事件处理，避免多线程操作 UI 导致的复杂性和性能开销。

Instrumentation 类 是 Android 应用程序的另一个重要类，它与 ActivityThread 紧密合作，用于监控和控制应用程序的组件行为。接下来主要介绍Instrumentation 类。

5 AMS生命周期监控相关类解读

5.1 Instrumentation 类解读

Instrumentation 类是Android框架中的一个核心类，用于监控和控制应用程序的生命周期和行为。它提供了一组API，允许开发者或者测试框架在应用程序运行时注入代码，监控应用程序的生命周期事件，如Activity的创建、销毁等，以及发送用户输入事件。

接下来解读Instrumentation 的设计理念和主要功能。

5.2 Instrumentation 类的设计理念和主要功能

Instrumentation 类的设计理念基于以下几个核心原则：

• 透明性：Instrumentation 类可以监控应用程序的生命周期事件而不需要修改应用程序的代码，对应用程序来说是透明的。
• 控制性：它允许测试代码控制应用程序的行为，例如强制启动一个Activity或发送模拟的用户输入。
• 解耦：Instrumentation 类将测试代码与应用程序代码分离，使得测试代码可以独立于应用程序存在。
• 灵活性：它提供了丰富的API来满足不同的测试需求，如性能测试、UI测试等。

Instrumentation 的主要功能解读如下：

• 生命周期管理：通过 Instrumentation 类，可以在测试中控制Activity的生命周期，如调用 callActivityOnCreate(), callActivityOnDestroy() 等方法。
• 事件分派：可以分派事件（如按键事件、触摸事件）到应用程序。
• 性能监控：可以监控应用程序的性能，如CPU使用、内存分配等。
• 测试结果报告：可以发送测试状态和结果报告。

5.3 Instrumentation杂项解读

Instrumentation 类常用于自动化测试，特别是UI测试。例如，AndroidJUnitRunner和Espresso测试框架在后台都使用了 Instrumentation 来执行测试用例。

Instrumentation 类通过在应用的生命周期方法之前和之后插入自定义的逻辑来工作。例如，它可以在 onCreate() 方法执行之前和之后添加代码，以监控或修改Activity的行为。

总之，Instrumentation 类是Android测试和监控的基石，它为开发者提供了一种强大的方式来控制和检查应用程序的行为，从而确保应用程序的质量。通过 Instrumentation，开发者可以在不修改应用程序代码的情况下，实现对应用程序的深入测试和分析。

6 AMS进程间通信相关类解读

6.1 AMS进程间通信相关类解读

关于进程间通信的类主要涉及的类包括：ActivityManagerNative、ActivityManagerProxy、ActivityManager。ActivityManagerNative 和 ActivityManagerProxy 是实现进程间通信（IPC）的关键类，它们利用Binder机制来完成客户端与服务端之间的数据交换。而ActivityManager提供了一组静态方法来与ActivityManagerService进行交互。详细解读如下：

• ActivityManagerNative 是一个抽象类，继承自Binder并实现了IActivityManager接口。它作为服务端的本地实现，包含了AMS提供给客户端的所有方法。当客户端通过代理对象调用方法时，实际上是通过Binder机制调用了ActivityManagerNative中相应的onTransact方法来处理请求。
• ActivityManagerProxy 是ActivityManagerNative的内部类，它作为客户端的代理，实现了IActivityManager接口。客户端通过ActivityManagerProxy实例来调用AMS的方法，这些调用会被封装成Binder事务并发送给服务端，即ActivityManagerService的实例。
• ActivityManager提供了一组静态方法来与ActivityManagerService进行交互。它通过ActivityManagerNative的getDefault方法来获取一个代理实例，通过这个代理实例，应用程序可以请求启动Activity、获取运行中的服务列表等操作。

接下来解读进程间通信这几个类的设计理念：

6.2 AMS进程间通信的设计理念

这三个类的设计理念基于代理模式，其中ActivityManagerNative充当了实际服务的提供者，而ActivityManagerProxy则是客户端的代理，ActivityManager则是客户端通常直接交互的接口。这种设计模式允许客户端代码透明地与远程服务进行通信，而无需关心IPC的具体细节。

1. 封装性：客户端通过ActivityManager与AMS进行交互，无需关心IPC的具体实现。
2. 解耦：客户端和服务端的代码解耦，修改服务端实现不影响客户端。
3. 扩展性：新增客户端或服务端功能时，不需要修改对方代码，只需要遵循相同的接口定义。

通过这种方式，Android系统能够灵活地管理应用程序的生命周期和调度，同时保持了代码的清晰和可维护性。

原文地址：https://blog.csdn.net/vviccc/article/details/142732779

免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！