一. 概述

        Android中有一个重要的系统进程(system_server)，运行着系统中非常重要服务(AMS, PMS, WMS等)， 针对Activity而言，系统进程需要不断地调度Activity执行，管理Activity的状态; 每一个APK都需要运行在一个应用进程中，有自己独立的内存空间， 针对Activity而言，应用进程需要执行Activity生命周期函数(onCreate, onStart, …onDestroy)的具体逻辑。

        应用进程需要频繁与系统进程通信，譬如Activity生命周期的各个方法都是需要经过系统进程调度的，只是在应用进程进行回调，这就需要从系统到应用的跨进程调用; 应用进程有需要将当前Activity的状态告诉系统进程，以便系统将Activity驱动到下一个状态，这就需要从应用到系统的跨进程调用。

        应用进程与系统进程相互通信的手段，就是利用前面文章介绍的Binder机制, 本文要分析的不是Binder机制的内在原理，而是应用进程与系统进程建立在Binder之上通信的业务逻辑，Android为此设计了两个Binder接口:

IApplicationThread:  作为系统进程请求应用进程的接口
IActivityManager:     作为应用进程请求系统进程的接口。

本文内容基于Android10的源码分析总结.

示例图:

             左侧为系统进程                                                                                                    右侧为应用进程

二 . AMS是什么?

比如在你的应用中(进程A)中启动一个Activity界面,肯定会调用startActivity这个方法, 然后跨进程和AMS通信, 接着AMS会管理这个Activity的生命周期方法,  先来说一说AMS是什么的?

1. 从java角度来看，AMS就是一个java对象

它实现了Ibinder接口，所以它是一个用于进程间通信的接口，这个对象初始化是在systemServer.java 的run()方法里面.

public Lifecycle(Context context) { super(context); mService = new ActivityManagerService(context); 
} 

public class ActivityManagerService extends IActivityManager.Stubimplements Watchdog.Monitor, BatteryStatsImpl.BatteryCallback {

2. AMS是一个服务
 ActivityManagerService从名字就可以看出，它是一个服务，用来管理Activity，而且是一个系统服务，就是包管理服务，电池管理服务，震动管理服务等。

3. AMS是一个Binder

AMS实现了Ibinder接口，所以它是一个Binder，这意味着他不但可以用于进程间通信，还是一个线程，因为一个Binder就是一个线程。
 

如果我们运行一个Hello world的安卓应用程序, 这个进程至少要启动4个线程

1. main线程，只是程序的主线程，也是日常用到的最多的线程，也叫UI线程，因为android的组
件是非线程安全的，所以只允许UI/MAIN线程来操作。

2. GC线程，java有垃圾回收机制，每个java程序都有一个专门负责垃圾回收的线程.

3. Binder1  就是我们的ApplicationThread，这个类实现了Ibinder接口，用于进程之间通信，具体
来说，就是我们程序和AMS通信的工具.

4.  Binder2 就是我们的ViewRoot.W对象，他也是实现了IBinder接口，就是用于我们的应用程序和
wms通信的工具。

 static class W extends IWindow.Stub {private final WeakReference<ViewRootImpl> mViewAncestor;private final IWindowSession mWindowSession;W(ViewRootImpl viewAncestor) {mViewAncestor = new WeakReference<ViewRootImpl>(viewAncestor);mWindowSession = viewAncestor.mWindowSession;}
.....
.....
}

WMS就是WindowManagerServicer ，和AMS差不多的概念，不过他是管理窗口的系统服务。

三.  两个接口

既然 IApplicationThread 和 IActivityManager 是两个接口, 我们来看看哪些类实现它们

3.1 IApplicationThread接口

只要继承了android.os.IInterface 则说明它是一个Binder对象, 是用于进程间通信的接口.

public interface IApplicationThread extends android.os.IInterface{
}

1. 先看IApplicationThread , 在 AS中 ctrl + T 快捷键(Eclipse风格)

 实现这个接口的类为: ApplicationThread   它是 ActivityThread.java的内部类

private class ApplicationThread extends IApplicationThread.Stub {
......
......
}

上图中,例外的 (Defaut in IApplicationThread)   (Proxy in stub in IApplicationThread) (Stub in IApplicationThread) 是 系统编译 IApplicationThread.aidl 文件后自动生成的代码文件,  里面的核心内容就是 1. 静态抽象类 Stub;  2. Stub的静态内部类Proxy ;

在看看 IApplicationThread.aidl 的写法, 接口文件前修饰关键字为oneway

/*** System private API for communicating with the application.  This is given to* the activity manager by an application  when it starts up, for the activity* manager to tell the application about things it needs to do.系统进程与应用进程通信的系统专用API** {@hide}*/
oneway interface IApplicationThread {
.....
}

oneway 表示在远程调用时(是异步调用，即客户端不会被阻塞), 它只是发送事务数据并立即返回. 

oneway修饰了的方法不可以有返回值，也不可以有带out或inout的参数。可以去看看 IApplicationThread.aidl文件中,定义的方法, 都是void类型, 没有返回值.

这也对应 AMS 给应用进程发送消息后, 肯定继续做自己的事情,  不会被阻塞,  因为AMS是四大组件的管理者,同一时刻好多事情等着做了, 要是和普通的[(in  out inout), 他们是同步调用, 调用方执行 mRemote.transact 时, 会挂起, 然后等待服务端reply值] 一样的话,  那么系统AMS这么重要的服务岂不是卡的要死. 系统运行也不流畅.

google设计它的使命是什么呢?

IApplicationThread接口的具体业务实现类是ApplicationThread, 它是ActivityThread的一个内部类，ApplicationThread负责响应系统进程发起的请求，这些请求大部分都是需要调度在应用进程的主线程执行，而ActivityThread是应用进程的主线程，通过Handle往主线程发送消息，ApplicationThread就轻松将具体执行任务的工作转交给了主线程。

3.2 IActivityManager接口

同样使用ctrl + T 查看实现类

  实现这个接口的类为: ActivityManagerService.java ,  AMSEx.java 为 AMS的继承类

public class ActivityManagerService extends IActivityManager.Stubimplements Watchdog.Monitor, BatteryStatsImpl.BatteryCallback {.....}public static abstract class Stub extends android.os.Binder implements android.app.IActivityManager{.....
}

根据上面"AMS是什么"介绍, 其实你也可以把AMS理解成运行在 system_server进程中的一个线程.

当然 WMS  PMS 也可以理解成运行在system_server进程中的线程.

Binder 在进程间通信传递的数据限制大小为 1M - 8K

根据以前的文章(Android 进程间通信机制(二) mmap 原理)查看dev/binder分配内存的命令:

cat  proc/进程号/maps  | grep  dev/binder 

我们可以查看 system_server进程 dev/binder 驱动文件分配的内存空间也是为 1M - 8K

Android 系统底层基于 Linux Kernel, 当 Kernel 启动过程会创建 init 进程, 该进 程是所有用户空间的鼻祖, init 进程会启动 servicemanager(binder 服务管家), Zygote 进程(Java 进程的鼻祖). Zygote 进程会创建 system_server 进程以及各 种 app 进程，下图是这几个系统重量级进程之间的层级关系。

用自己的手机查看进程号: 

[号外]:  servicemanager 进程分配dev/binder的内存空间为 128K , 结论支撑代码为

frameworks/native/cmds/servicemanager/service_manager.c

int main(int argc, char** argv)
{struct binder_state *bs;union selinux_callback cb;char *driver;if (argc > 1) {driver = argv[1];} else {driver = "/dev/binder";}bs = binder_open(driver, 128*1024);

google设计128k的理由,  推测是和servicemanager进程通信的业务包括

请求服务(如 ServiceManager.getService(Context.USAGE_STATS_SERVICE))    和 

添加服务等轻量级的工作

ServiceManager.addService(ProcessStats.SERVICE_NAME, mProcessStats);ServiceManager.addService("meminfo", new MemBinder(this), /* allowIsolated= */ false,DUMP_FLAG_PRIORITY_HIGH);ServiceManager.addService("gfxinfo", new GraphicsBinder(this));ServiceManager.addService("dbinfo", new DbBinder(this));if (MONITOR_CPU_USAGE) {ServiceManager.addService("cpuinfo", new CpuBinder(this),/* allowIsolated= */ false, DUMP_FLAG_PRIORITY_CRITICAL);}ServiceManager.addService("permission", new PermissionController(this));ServiceManager.addService("processinfo", new ProcessInfoService(this));

所以在binder分配的空间上只需要128K就可以满足. 

四.  握手通信全流程

4.1 从应用进程到系统进程

在ActivityThread创建的时候，会将自己的ApplicationThread绑定到AMS中, 源码流程如下:

1. 首先在 ActivityThread.java 的main方法中

 public static void main(String[] args) {ActivityThread thread = new ActivityThread();.....//步骤一thread.attach(false, startSeq);}@UnsupportedAppUsageprivate void attach(boolean system, long startSeq) {final IActivityManager mgr = ActivityManager.getService();//步骤二 通过 IActivityManager接口跨进程通信, 把 mAppThread(ApplicationThread对象)传递到AMS中mgr.attachApplication(mAppThread, startSeq);}

应用进程作为客户端，通过IAcitivtyManager接口发起了跨进程调用， 跨进程传递的参数mAppThread就是IApplicationThread的实例， 执行流程从应用进程进入到系统进程

2 接下来就到AMS中去了,调用 AMS.attachApplication() 方法

@Overridepublic void attachApplication(IApplicationThread thread, long startSeq) {if (thread == null) {throw new SecurityException("Invalid application interface");}synchronized (this) {int callingPid = Binder.getCallingPid();final int callingUid = Binder.getCallingUid();final long origId = Binder.clearCallingIdentity();attachApplicationLocked(thread, callingPid, callingUid, startSeq);Binder.restoreCallingIdentity(origId);}}

AMS作为IActivityManager接口的服务端实现，会响应客户端的请求，最终AMS.attachApplication()函数会被执行， 该函数接收跨进程传递过来的IApplicationThread实例，将其绑定到系统进程。 具体的绑定操作细节此处不表，我们只需要知道AMS中维护了所有进程运行时的信息(ProcessRecord)，一旦发生了应用进程的绑定请求， ProcessRecord.thread就被赋值成应用进程的IApplicationThread实例，这样一来，在AMS中就能通过该实例发起向应用进程的调用。

4.2 从系统进程到应用进程

在AMS.attachApplication()的过程中，会有一些信息要传递给应用进程，以便应用进程的初始化.

public void attachApplication(IApplicationThread thread, long startSeq) {....//1attachApplicationLocked(thread, callingPid, callingUid, startSeq);....
}

此时，AMS会反转角色，即系统进程作为客户端，通过IApplicationThread接口向应用进程发起调用。

@GuardedBy("this")private boolean attachApplicationLocked(@NonNull IApplicationThread thread,int pid, int callingUid, long startSeq) {// 2thread.bindApplication(processName, appInfo, providers, null, profilerInfo,null, null, null, testMode,mBinderTransactionTrackingEnabled, enableTrackAllocation,isRestrictedBackupMode || !normalMode, app.isPersistent(),new Configuration(app.getWindowProcessController().getConfiguration()),app.compat, getCommonServicesLocked(app.isolated),mCoreSettingsObserver.getCoreSettingsLocked(),buildSerial, autofillOptions, contentCaptureOptions);
}

2中的 thread就是 实现了IApplicationThread的接口对象,通过它跨进程通信,就跳转到ActivityThread.bindApplication 方法中去了

 public final void bindApplication(String processName, ApplicationInfo appInfo,List<ProviderInfo> providers, ComponentName instrumentationName,ProfilerInfo profilerInfo, Bundle instrumentationArgs, 
.......
.......data.contentCaptureOptions = contentCaptureOptions;//3sendMessage(H.BIND_APPLICATION, data);}

接下来会到消息处理的地方

  public void handleMessage(Message msg) {if (DEBUG_MESSAGES) Slog.v(TAG, ">>> handling: " + codeToString(msg.what));switch (msg.what) {case BIND_APPLICATION:Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "bindApplication");AppBindData data = (AppBindData)msg.obj;//4handleBindApplication(data);Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);//processLinkTurboMonitor();break;

调用handleBindApplication方法:

 private void handleBindApplication(AppBindData data) {.....try {//5mInstrumentation.callApplicationOnCreate(app);}

最终会走到 Application的 onCreate()方法中去

   //Instrumentation.java中public void callApplicationOnCreate(Application app) {app.onCreate();}//Application.javapublic void onCreate() {}

        ApplicationThread作为IApplicationThread接口的服务端实现，运行在应用进程中， 然后ApplicationThread.bindApplication()会被执行，完成一些简单的数据封装(AppBindData)后，通过Handler抛出BIND_APPLICATION消息。这一抛，就抛到了主线程上，

ActivityThread.handleBindApplication()会被执行，接着就到了各位观众较为熟悉的Application.onCreate()函数。历经应用进程和系统进程之间的一个完整来回，总算是创建了一个应用程序。