AMS 和 App 进程如何通信

Android 系统中，AMS/ATMS与App 进程的通信是典型的Binder 双向通信。这种设计实现了系统对应用的精细化管控与应用对系统资源的合法请求。

【 App 进程 】                                 【 SystemServer 进程 】+---------------------------+                   +----------------------------------+|   Activity / Service      |                   |                                  ||           |               |                   |    ActivityTaskManagerService    ||   (1) 发起请求             |                   |            (ATMS/AMS)            ||           v               |                   |                |                 || [ IActivityManager.Proxy ]|                   |    [ IActivityManager.Stub ]     |+-----------|---------------+                   +----------------|-----------------+            |                                                    |            |            (2) Binder Driver (内核层)               |            |----------------------------------------------------|            |         (通过 UID/PID 校验，执行内存拷贝)            |            |                                                    |+-----------|---------------+                   +----------------|-----------------+| [ IApplicationThread.Stub]|                   | [ IApplicationThread.Proxy ]     ||           |               |                   |                |                 ||   (4) 异步回调处理         |                   |    (3) 下发指令 (oneway)         ||           v               |                   |                |                 ||   ActivityThread (H)      |                   |      LifecycleManager            |+---------------------------+                   +----------------------------------+

1. 核心交互模型

App → 系统 (SystemServer)：App 进程作为客户端，通过IActivityTaskManager(ATMS) 或IActivityManager(AMS) 接口，请求启动 Activity、发送广播等。

系统 → App：系统进程作为客户端，通过IApplicationThread接口，向 App 发送指令（如生命周期回调、内存回收）。

2. 关键类说明 (Android 10+)

类名	角色	核心职责
ATMS (ActivityTaskManagerService)	核心大脑	Android 10 引入，专门负责 Activity 管理、栈管理及生命周期调度。
AMS (ActivityManagerService)	进程管家	负责应用进程生命周期、Service、Broadcast、ContentProvider 管理。
IActivityTaskManager	AIDL 接口	定义了 App 跨进程调起系统（ATMS）功能的协议。
IApplicationThread	AIDL 接口	定义了系统反向调起 App 进程功能的协议。
ActivityThread	App 运行实体	App 进程的入口（`main` 方法所在地），管理主线程（UI 线程）。
ApplicationThread	App 端 Stub 实现	`ActivityThread` 的内部类，作为 Binder 实体接收来自系统进程的回调。

3. App 调用系统：以 startActivity 为例

核心流程

App 进程通过ServiceManager获取 ATMS 的代理对象（Proxy），发起 Binder 调用。

核心源码片段

第一步：获取系统服务代理 (App 进程)

自 Android 10 起，Activity 启动逻辑移至ActivityTaskManager：

// ActivityTaskManager.javapublic static IActivityTaskManager getService() {    return IActivityTaskManagerSingleton.get();}private static final Singleton<IActivityTaskManager> IActivityTaskManagerSingleton =    new Singleton<IActivityTaskManager>() {        @Override        protected IActivityTaskManager create() {            // 获取 ATMS 的 Binder 句柄并转化为 Proxy 对象            final IBinder b = ServiceManager.getService(Context.ACTIVITY_TASK_SERVICE);            return IActivityTaskManager.Stub.asInterface(b);        }    };

第二步：发起请求 (App 进程)

// 最终调用 Proxy 对象的 startActivity// 此时 Binder 驱动将数据打包，唤醒 SystemServer 进程的 Binder 线程池mService.startActivity(whoThread, whoPkg, intent, ...);

第三步：系统处理请求 (系统进程)

ActivityTaskManagerService继承自Stub类，响应请求：

public class ActivityTaskManagerService extends IActivityTaskManager.Stub {    @Override    public final int startActivity(...) {        // 已进入系统进程的 Binder 线程池，执行后续权限检查及栈管理逻辑        return startActivityAsUser(...);    }}

4. 系统调用 App：以“生命周期回调”为例

系统进程手中持有 App 的IApplicationThread代理，实现“远程遥控”。

第一步：注册 Binder 句柄 (App 启动)

在 App 进程启动时，会通过attachApplication将自己的 Binder 实体（ApplicationThread）传给系统：

// ActivityThread.javaprivate void attach(boolean system, long startSeq) {    final IActivityManager mgr = ActivityManager.getService();    // mAppThread 是 ApplicationThread 实例（Binder 实体）    mgr.attachApplication(mAppThread, startSeq);}

第二步：系统进程保存引用

系统进程将该代理对象存储在ProcessRecord中。当需要回调 App（如onResume）时：

// ActivityStackSupervisor.java (系统进程)void realStartActivityLocked(...) {    // clientTransaction 内部持有了 IApplicationThread 的 Proxy 对象    mService.getLifecycleManager().scheduleTransaction(clientTransaction);}

第三步：App 接收并处理请求 (App 进程)

ApplicationThread接收到 Binder 请求后，通过Handler切换到主线程处理：

private class ApplicationThread extends IApplicationThread.Stub {    @Override    public void scheduleTransaction(ClientTransaction transaction) {        // 发送消息到 H (ActivityThread 内部 Handler)        // 保证生命周期逻辑在 UI 线程执行        scheduleSendMessage(H.EXECUTE_TRANSACTION, transaction);    }}

5. 核心点 (Binder 深度应用)

Q1：身份校验——系统如何知道你是谁？

内核态自动填充：当 App 进程发起 Binder 调用时，Binder 驱动会自动在内核数据结构中填入调用者的PID和UID。

系统进程通过Binder.getCallingPid()和Binder.getCallingUid()获取该信息。

结论：UID 是 App 的身份标识，App 无法在应用层伪造，这是 Android 安全机制的基石。

Q2：死亡通知——App 挂了系统怎么知道？

LinkToDeath 机制：系统进程在接收到 App 的 Binder 对象后，会调用linkToDeath注册一个死亡监听。

当 App 进程异常退出或被杀时，Binder 驱动会监控到该连接断开，并触发系统进程中的binderDied()回调。

作用：AMS 借此及时清理 Activity 栈信息、释放资源，避免出现“僵尸”状态。

Q3：性能优化——为什么回调是 oneway？

在IApplicationThread.aidl中，大部分方法标记为oneway（异步调用）。

非 oneway：同步，调用方阻塞等待返回。

oneway：异步，调用方将指令丢给驱动后立即返回。

设计原因：系统进程不能被 App 阻塞。如果 App 进程的主线程卡顿，由于是oneway回调，系统进程（ATMS/AMS）可以继续处理其他任务，而不会发生系统级掉帧。

Q4：ActivityThread vs ApplicationThread

ActivityThread：App 进程的管家。代表主线程逻辑，处理main函数，循环Looper。

ApplicationThread：App 进程的通信窗口。它是 Binder 实体，负责接收系统指令。

关系：两者是“内部类”关系。ApplicationThread接收到指令后，总是通过Handler将任务转发给ActivityThread的主线程执行。

总结

AMS/ATMS 与 App 的通信是双向代理模型：

利用Binder实现了跨进程的数据传输。

利用UID/PID实现了权限管控。

利用oneway机制平衡了系统稳定性和响应速度。

利用LinkToDeath保证了进程状态的一致性。