Android应用程序建立与AMS服务之间的通信过程
Android四大组件源码实现详解系列博客目录:
Android应用进程创建流程大揭秘
[Android四大组件之bindService源码实现详解
Android四大组件之Activity启动流程源码实现详解概要
Activity启动流程(一)发起端进程请求启动目标Activity
Activity启动流程(二)system_server进程处理启动Activity请求
Activity启动流程(三)-Activity Task调度算法复盘分析
Activity启动流程(四)-Pause前台显示Activity，Resume目标Activity
Activity启动流程(五)请求并创建目标Activity进程
Activity启动流程(六)注册目标Activity进程到system_server进程以及创建目标Activity进程Application
Activity启动流程(七)初始化目标Activity并执行相关生命周期流程
Android应用程序建立与AMS服务之间的通信过程
本篇博客编写思路总结和关键点说明:
为了更加方便的读者阅读博客，通过导读思维图的形式将本博客的关键点列举出来，从而方便读者取舍和阅读！
引言
Android四大组件作为Android整个应用层框架的基石，其在Android中的地位是毋庸置疑的。而AMS(这里将ActivityManagerService简称AMS)做为四大组件启动，管理的核心服务却是运行在system_server进程中的，而我们的四大组件的启动和管理，更有甚者我们四大组件所在应用程序的创建都离不开和AMS服务之间的跨进程交互过程。那么这两个进程之间是怎么进行跨进程通信的呢，我想如果对于Android有一定了解的读者肯定会脱口而出通过Binder通信，是的应用程序和AMS服务之间正是通过Binder进行通信的！而我们今天的博客将会重点分析二者之间是如何建立Binder通信逻辑的，即:
我们知道Binder通信有一个特点就是通常只能Binder客户端请求Binder服务端，而不能反过来(注意这里的措辞是通常)！所以通常Binder客户端和服务端之间想建立相互通信的关系，会借助匿名Binder，而我们这里的AMS和应用程序之间也是如此！
- Android应用程序以及关联的四大组件建立和AMS的Binder通信
- AMS建立和应用程序及四大组件的Binder通信
注意:本篇的介绍是基于Android 7.xx平台为基础的，其中涉及的代码路径如下：
frameworks/base/services/core/java/com/android/server/am/
--- ActivityManagerService
frameworks/base/core/java/android/app/
---Activity.java
---ActivityThread
---ApplicationThreadNative.java
---IApplicationThread.java
---ActivityManagerNative.java
---IActivityManager.java
并且在后续的源码分析过程中为了简述方便，会将做如下简述:
- ApplicationThreadProxy简称为ATP
- ActivityManagerProxy简称为AMP
- ActivityManagerService简称为AMS
- ActivityManagerNative简称AMN
- ApplicationThreadNative简称ATN
在正式开始分析前，我们先奉上Android应用程序和AMS之间跨进程Binde通信交互图，也许下面的图就能给读者灵感，不待我分析就知道了今天的主题Android应用程序建立与AMS服务之间的通信过程了。
一.Android应用程序以及关联的四大组件建立和AMS的Binder通信
在正式开始相关的的分析之前，将要涉及到涉及到Context的继承关系类图，从下面的类图中可以看出，Context是一个接口(提供了很多的接口方法)，ContextImp和ContextWrapper都是其实现类，我们常用的Activity、Service、Application都直接或间接继承自ContextWrapper。
1.1 Android应用层获取Framework层AMS核心服务对外接口类ActivityManager
AMS做为Android Framework层的Binder核心服务，它被注册到了servicemanager服务大管家里面，并且也和其它核心服务一样在Android Framework的框架层提供了对应的SDK接口供应用程序调用AMS服务，而我们这里以在应用程序的Activity或者其子类中获取AMS服务对外提供接口类为例说明:
ActivityManager mActivityManager = (ActivityManager) getSystemService(Context.ACTIVITY_SERVICE);
注意这里我们只是为了演示，其实Context上下文已经为了提供了关于使用AMS服务的相关封装接口，譬如startActivity()等
这里我们通过上面的类图关系知道getSystemService()方法最终会调用到ContextThemeWrapper类的getSystemService中，源码如下：
//[ContextThemeWrapper.java]
@Override
public Object getSystemService(String name) {
if (LAYOUT_INFLATER_SERVICE.equals(name)) {
if (mInflater == null) {
mInflater = LayoutInflater.from(getBaseContext()).cloneInContext(this);
}
return mInflater;
}
return getBaseContext().getSystemService(name);
}
//[ContextWrapper.java]
public Context getBaseContext() {
return mBase;//注意这里的mBase指向了ContextImpl类
}
从上面的代码可以看到getSystemService()方法最终都调用到了ContextImpl类中，而至于mBase为什么指向了ContextImpl实例，这里就不过多篇幅分析了可以参见博客初始化目标Activity并执行相关生命周期流程的2.3章节，这里我们直接来看ContextImpl中getSystemService()的实现，如下:
//[ContextImpl.java]
@Override
public Object getSystemService(String name) {
return SystemServiceRegistry.getSystemService(this, name);
}
这里又来了一个SystemServiceRegistry类，我们接着继续分析看看它的处理逻辑！
//[SystemServiceRegistry.java]
private static final HashMap<Class<?>, String> SYSTEM_SERVICE_NAMES =
new HashMap<Class<?>, String>();
private static final HashMap<String, ServiceFetcher<?>> SYSTEM_SERVICE_FETCHERS =
new HashMap<String, ServiceFetcher<?>>();
public static Object getSystemService(ContextImpl ctx, String name) {
ServiceFetcher<?> fetcher = SYSTEM_SERVICE_FETCHERS.get(name);
return fetcher != null ? fetcher.getService(ctx) : null;
}
好像很简单额，直接从SYSTEM_SERVICE_FETCHERS哈希列表中根据服务名称进行查找，这里我们看下SYSTEM_SERVICE_FETCHERS是啥时候被填充的，我们接着查找：
//[SystemServiceRegistry.java]
private static <T> void registerService(String serviceName, Class<T> serviceClass,
ServiceFetcher<T> serviceFetcher) {
SYSTEM_SERVICE_NAMES.put(serviceClass, serviceName);
SYSTEM_SERVICE_FETCHERS.put(serviceName, serviceFetcher);
}
可以看到在registerService()方法中注册了一系列的服务，我接着继续查找看看那里调用了它！
//[SystemServiceRegistry.java]
static {
// Not instantiable.
private SystemServiceRegistry() { }
...
registerService(xxx);
registerService(Context.ACTIVITY_SERVICE, ActivityManager.class,
new CachedServiceFetcher<ActivityManager>() {
@Override
public ActivityManager createService(ContextImpl ctx) {
return new ActivityManager(ctx.getOuterContext(), ctx.mMainThread.getHandler());
}});
}
这里我们可以看到SystemServiceRegistry类的static静态方法区中注册了一系列的服务，而我们的ActivityManager实例对象也被注册到了里面，支持我们就可以使用AMS相关的服务了。而其它的Android Framework层核心服务也数通过上述方法进行注册，然后对外提供的。
不知道细心的读者注意到了没有这里的SystemServiceRegistry类，只有一个私有构造方法，那么说明他不能被实例化，那它是怎么被实例化的呢，或者说是怎么被加载然后执行static的静态区的注册方法呢，这个就要说我们我们的zygote预加载机制了，在Android Zygote进程启动源码分析指南的的2.3章节我们知道zygote进程会调用preload()方法中会通过反射预加载一些类，而这其中就包括我们的SystemServiceRegistry，而我们的Android应用程序进程是由zygote进程孵化的所以继承了zygote进程资源，所以它预加载的SystemServiceRegistry也被我们继承到了。
而我们知道zygote进程预加载的claess被定义在frameworks/base/preloaded-classes中,我们简单看下就找到了SystemServiceRegistry身影，如下:
1.2 Android应用层通过对外接口类ActivityManager使用AMS服务
通过前面的一顿操作，我们获取到了AMS服务对外的接口类ActivityManager，在正式开始分析Android应用程序是怎么通过它使用AMS服务之间，我们先来看看AMS的整体类图框架图，如下:
好了前面1.1章节我们最后获取到了ActivityManager的实例对象，我们来看看其构造方法，如下:
//[ActivityManager.java]
/*package*/ ActivityManager(Context context, Handler handler) {
mContext = context;//感觉啥也没有做，根本没有和AMS搭上半毛钱关系
mHandler = handler;
}
尼玛，这里的ActivityManager感觉和AMS服务没有搭上半毛钱关系啊，是不是搞错了啊！当然不是了，这里我们随意抽取AcivityManager中的一个方法来看看，如下：
//[ActivityManager.java]
public List<RunningServiceInfo> getRunningServices(int maxNum)
throws SecurityException {
try {
return ActivityManagerNative.getDefault()
.getServices(maxNum, 0);
} catch (RemoteException e) {
throw e.rethrowFromSystemServer();
}
}
这里我们终于看到老熟人AMN了，这里牵涉到一个重要的方法AMN.getDefault()，其实它在我们的博客中 Android Binder框架实现之Java层获取Binder服务源码分析已经有详细的介绍和分析了，但是为了博客的连贯性还是简单过下(主要是为了不太熟悉的小伙伴们)。
//ActivityManagerNative.java
static public IActivityManager getDefault() {
return gDefault.get();
}
这里的gDefault是Singleton对象实例，而Singleton我们可以看到是一个模板类对象，并且提供了一个单例方法，其定义如下：
//Singleton.java
public abstract class Singleton<T> {
private T mInstance;
protected abstract T create();
public final T get() {
synchronized (this) {
if (mInstance == null) {//采用单例模式
mInstance = create();
}
return mInstance;
}
}
}
我们将IActivityManager带入Singleton，得到如下的create方法过程：
//ActivityManagerNative.java
private static final Singleton<IActivityManager> gDefault = new Singleton<IActivityManager>() {
protected IActivityManager create() {
//此处等价于IBinder b = new BinderProxy(new BpBinder(handle));
IBinder b = ServiceManager.getService("activity");
if (false) {
Log.v("ActivityManager", "default service binder = " + b);
}
//此处等价于IActivityManager am = new ActivityManagerProxy(new BinderProxy(new BpBinder(handle)))
IActivityManager am = asInterface(b);
if (false) {
Log.v("ActivityManager", "default service = " + am);
}
return am;
}
};
//注意此处我们的入参是BinderProxy类型，所以会走代理端
static public IActivityManager asInterface(IBinder obj) {
if (obj == null) {
return null;
}
IActivityManager in =
(IActivityManager)obj.queryLocalInterface(descriptor);
if (in != null) {
return in;
}
//即会走到此处
return new ActivityManagerProxy(obj);
}
这里即最终经过层层转换得到了AMS服务的代理端ActivityManagerProxy，进而借助它完成对AMS服务的RPC请求。
1.3 Android应用程序以及关联的四大组件建立和AMS的Binder通信小结
至此Android应用程序以及关联的四大组件建立和AMS的Binder通信就已经建立了，其主要核心流程就是先通过Context上下文环境获取ActivityManager，然后ActivityManager借助AMS的代理端AMP来和AMS服务通信从而达到调用AMS服务的功能。而这里最最重要的就是AMN.getDefault()的调用逻辑了，这里我们对其小结一下：
- AMN.getDefault()最终获取了AMS的远程Binder代理端AMP
- AMS的Binder通信过程中提供了一个IActivityManager服务业务层接口，AMP类与AMS类都实现了IActivityManager接口方法，区别不同给的是AMS端显示了真正的具体服务，而AMP端是封装了相关的通信传输逻辑。AMP作为Binder通信的服务代理端，而AMS作为Binder通信的服务端实体，根据Android Binder框架实现之Java层Binder服务跨进程调用源码分析，AMP.xxx()最终调用AMS.xxx()，整个流程图如下：
至此我们就建立了一条如下的通信道路线完成Android应用程序以及关联的四大组件建立和AMS的Binder通信
这里我们需要注意的是其实对四大组件的常规操作，我们的Context上下文环境已经为我么封装好了相关的调用接口，譬如startActivity()，startService()等！但是其核心还是获取AMS服务的代理端AMP，只是省略了获取ActivityManager的流程罢了！
二.AMS建立和Android应用程序以及关联的四大组件之间的Binder通信
我们知道Android应用程序进程通常是AMS服务请求zygote进程fork出来的，Android应用程序被fork出来以后经过一些列的初始化最终会通过反射调用到ActivityThread.main()方法中(如果对此处逻辑不是很清楚的，详见博客请求并创建目标Activity进程)，而我们AMS建立和Android应用程序以及关联的四大组件之间的Binder通信正是在执行main()方法中进行的。
//[ActivityThread.java]
public static void main(String[] args) {
...
Environment.initForCurrentUser();
...
Process.setArgV0("<pre-initialized>");
//创建主线程looper
Looper.prepareMainLooper();
ActivityThread thread = new ActivityThread();
//attach到系统进程AMS服务，从而使AMS建立和应用程序的通信通道
thread.attach(false);//详见章节2.1
if (sMainThreadHandler == null) {
sMainThreadHandler = thread.getHandler();
}
//主线程进入循环状态
Looper.loop();
throw new RuntimeException("Main thread loop unexpectedly exited");
}
2.1 ApplicationThread简介
在正式开始上述Binder通道建立之前，我们有必要来先了解了解ApplicationThread类实现了IApplicationThread接口，这里我们先来简单看下IApplicationThread的定义，如下:
//[IApplicationThread.aidl]
public interface IApplicationThread extends IInterface {
void schedulePauseActivity(IBinder token, boolean finished, boolean userLeaving,
int configChanges, boolean dontReport) throws RemoteException;
void scheduleStopActivity(IBinder token, boolean showWindow,
int configChanges) throws RemoteException;
}
可以看到IApplicationThread定义的方法很多，绝大不是是和Android四大组件生命周期调度有关的，我们接着来看ApplicationThread类，它是一个匿名Binder类,其类图关系图如下:
如果对Binder特别是匿名/实名Binder还没有了解的读者强烈建议先阅读一下该篇以及一系列的博客Android Binder框架实现之何为匿名/实名Binder。通过前面的博客我们应该知道匿名Binder有两个比较重要的用途:
一个是拿到Binder代理端后可跨Binder调用实体端的方法接口(我们这里主要利用了这个功能 )
另一个作用便是在多个进程中标识同一个对象
这里的IApplicationThread与IActivityManager的Binder通信原理一样，ATP作为Binder通信的客户端，ATN作为Binder通信的服务端，其中ApplicationThread继承ATN类，覆写其中的部分方法。
2.2 注册目标Activity进程到system_server建立AMS和它的Binder通信
通过前面的章节我们了解匿名Binder服务ApplicationThread，而本章节将要分析它是怎么被实名Binder传递到system_server进程中然后建立起AMS和它的通信逻辑的，其核心的架构思想如下图所示:
2.2.1 ActivityThread.attach(…)
其实对于该方法，如果有阅读过Android系统启动之system_server进程创建大揭秘的小伙们应该不会陌生了，在system_server进程启动的流程中也会调用它只是传入的参数为true，而我们此时传入的参数为false而已！用以区别是system_server进程发起的绑定还是普通应用进程发起的绑定。
//[ActivityThread.java]
final ApplicationThread mAppThread = new ApplicationThread();
private void attach(boolean system) {
sCurrentActivityThread = this;
mSystemThread = system;
if (!system) {
...
// 设置进程名。此时，还没有ApplicationInfo，所以用<pre-initialized>来命名应用进程
android.ddm.DdmHandleAppName.setAppName("<pre-initialized>",
UserHandle.myUserId());
...
//获取AMS服务端的远程代理对象AMP
final IActivityManager mgr = ActivityManagerNative.getDefault();
try {
//通过Binder远程调用AMS的attachApplication方法
mgr.attachApplication(mAppThread);//详见章节
} catch (RemoteException ex) {
throw ex.rethrowFromSystemServer();
}
...
} else {//system_server进程会进入此分支
}
DropBox.setReporter(new DropBoxReporter());
//为ViewRootImpl注册Config回调接口
ViewRootImpl.addConfigCallback(new ComponentCallbacks2() {
...
});
}
上述方法执行的逻辑并不是很复杂，其主要就是两点:
- 获取AMS服务的远程代理端AMP
- 接着通过AMP借助Binder调用AMS的方法attachApplication，注意这里传递的mAppThread是一个匿名Binder实例，因此可以作为跨进程传递的参数。这里的mAppThread对象存在于应用进程，但会被传递到系统进程，在系统进程看来，此时的mAppThread就是操作应用进程的一个通信工具。后续，系统进程system_server如果想要向应用进程发起跨进程调用，也都需要通过mAppThread这个对象来完成相关的调度。
并且关于上述的执行逻辑我们在Android四大组件之Activity启动流程源码实现详解(一)中2.4章节已经有过详细的分析了，这里就不详细赘述了。并且如果小伙们对于什么是匿名Binder以及怎么传递的有不了解的小伙们，这篇博客Android Binder框架实现之何为匿名/实名Binder有详细分析就不过多歪歪了！
关于上述整个Binder IPC调用流程，可以使用如下伪代码来简述：
AMP.attachApplication(...)--->
BinderProxy.transact(...) --->
BpBinder.transact(...)--->
binder驱动传输--->
JavaBBinder.onTransact(...)--->
AMN.onTransact(..)--->
AMN.attachApplication(...) --->
AMS.attachApplication(...) --->
2.2.2 AMS.attachApplication(…)系统system_server进程处理attachApplication请求
在这里AMS响应了目标Activity进程的attachApplication绑定请求，注意此时的attachApplication是执行在Binder线程中的。
//[ActivityManagerService.java]
public final void attachApplication(IApplicationThread thread) {
synchronized (this) {
//获取调用进程端pid
int callingPid = Binder.getCallingPid();
final long origId = Binder.clearCallingIdentity();
//attachApplicationLocked进行进一步处理
attachApplicationLocked(thread, callingPid);
Binder.restoreCallingIdentity(origId);
}
}
上述方法比较简单，接着调用attachApplicationLocked进行下一步的处理，注意此时多传入了一个参数pid。并且这里还有一点主要注意的是此时的参数类型IApplicationThread已经变成了匿名Binder的代理端了ATP了。IApplicationThread它串联起了AMS对App进程的生命周期及其其它的控制。
我们接着继续分析，attachApplicationLocked源码数量有点多啊(没有啥的、我们只关心我们所关心的)！
//[ActivityManagerService.java]
private final boolean attachApplicationLocked(IApplicationThread thread,
int pid) {
ProcessRecord app;
long startTime = SystemClock.uptimeMillis();
/*
根据PID映射应用进程的ProcessRecord对象
那么此处的ProcessRecord是什么时候创建并加入到mPidsSelfLocked中的呢，这个在该系列博客的五中有详细描述
*/
if (pid != MY_PID && pid >= 0) {
synchronized (mPidsSelfLocked) {
app = mPidsSelfLocked.get(pid);
}
} else {
app = null;
}
...
//将目标Activity进程的IApplicationThread匿名Binder代理端绑定到ProcessRecord对象
app.makeActive(thread, mProcessStats);
/****************************************************/
//这里为了演示方便，直接给出源码
//[ProcessRecord.java]
public void makeActive(IApplicationThread _thread, ProcessStatsService tracker) {
if (thread == null) {
...
}
thread = _thread;
}
/****************************************************/
//继续进行其它的对ProcessRecord的赋值
app.curAdj = app.setAdj = app.verifiedAdj = ProcessList.INVALID_ADJ;
app.curSchedGroup = app.setSchedGroup = ProcessList.SCHED_GROUP_DEFAULT;
app.forcingToForeground = null;
updateProcessForegroundLocked(app, false, false);
app.hasShownUi = false;
app.debugging = false;
app.cached = false;
app.killedByAm = false;
...
try {
...
//省略debug和性能优化等相关配置的代码，这里就不赘述了
//这里又是老熟人了，一路分析过来见过很多次了，此处发起跨进程调用，将一堆的信息传递给目标Activity应用进程
//立即使用了传递过来的匿名Binder，调用到了ActivityThread中
thread.bindApplication(processName, appInfo, providers, app.instrumentationClass,
profilerInfo, app.instrumentationArguments, app.instrumentationWatcher,
app.instrumentationUiAutomationConnection, testMode,
mBinderTransactionTrackingEnabled, enableTrackAllocation,
isRestrictedBackupMode || !normalMode, app.persistent,
new Configuration(mConfiguration), app.compat,
getCommonServicesLocked(app.isolated),
mCoreSettingsObserver.getCoreSettingsLocked());//详见第二大章节
updateLruProcessLocked(app, false, null);
...
} catch (Exception e) {//异常处理
...
}
return true;
}
我们这里只重点关心IApplicationThread 代理端的处理，在传递到AMS服务以后将其保存到了每个应用进程在AMS服务端的记录ProcessRecord的thread中，从而AMS后续可以继续使用该Binder代理端来对Android应用程序和四大组件进行相关的调度，这不后面立即来了一个thread.bindApplication的调度。当然AMS服务中并不单单只有此处的调用，我们简单搜索一下能发现许多，如下:
frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java:2107: r.app.thread.scheduleEnterAnimationComplete(r.appToken);
frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java:2855: procs.add(app.thread.asBinder());
frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java:4289: app.thread.scheduleTrimMemory(level);
frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java:4723: activityToCallback.app.thread.scheduleLocalVoiceInteractionStarted(activity,
frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java:5372: app.thread.asBinder() == thread.asBinder()) {
frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java:6089: app.thread.scheduleSuicide();
frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java:11625: app.thread.scheduleInstallProvider(pi);
frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java:12579: activity.app.thread.requestAssistContextExtras(activity.appToken, pae,
frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java:15464: r.app.thread.dumpActivity(tp.getWriteFd().getFileDescriptor(),
frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java:17100: capp.thread.unstableProviderDied(conn.provider.provider.asBinder());
frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java:19295: app.thread.scheduleConfigurationChanged(configCopy);
frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java:20416: app.thread.scheduleLowMemory();
frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java:20418: app.thread.processInBackground();
frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java:20785: app.thread.setProcessState(app.repProcState);
frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java:21431: app.thread.scheduleTrimMemory(curLevel);
frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java:21468: app.thread.scheduleTrimMemory(
frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java:21486: app.thread.scheduleTrimMemory(level);
frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java:21497: app.thread.scheduleTrimMemory(fgTrimLevel);
frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java:21523: app.thread.scheduleTrimMemory(
frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java:21657: + (app.thread != null ? app.thread.asBinder() : null)
frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java:21663: app.thread.scheduleExit();
frameworks/base/services/core/java/com/android/server/am/ActivityStackSupervisor.java:1343: app.thread.scheduleLaunchActivity(new Intent(r.intent), r.appToken,
frameworks/base/services/core/java/com/android/server/am/ActivityStackSupervisor.java:3027: top.app.thread.scheduleBackgroundVisibleBehindChanged(top.appToken, visible);
frameworks/base/services/core/java/com/android/server/am/ActivityStackSupervisor.java:3465: r.app.thread.dumpActivity(tp.getWriteFd().getFileDescriptor(),
frameworks/base/services/core/java/com/android/server/am/ActiveServices.java:1457: r.app.thread.scheduleBindService(r, i.intent.getIntent(), rebind,
frameworks/base/services/core/java/com/android/server/am/ActiveServices.java:1877: app.thread.scheduleCreateService(r, r.serviceInfo,
frameworks/base/services/core/java/com/android/server/am/ActiveServices.java:1985: r.app.thread.scheduleServiceArgs(r, si.taskRemoved, si.id, flags, si.intent);
frameworks/base/services/core/java/com/android/server/am/ActiveServices.java:2079: r.app.thread.scheduleUnbindService(r,
frameworks/base/services/core/java/com/android/server/am/ActiveServices.java:2135: r.app.thread.scheduleStopService(r);
frameworks/base/services/core/java/com/android/server/am/ActiveServices.java:2240: s.app.thread.scheduleUnbindService(s, b.intent.intent.getIntent());
frameworks/base/services/core/java/com/android/server/am/ActiveServices.java:3436: r.app.thread.dumpService(tp.getWriteFd().getFileDescriptor(), r, args);
frameworks/base/services/core/java/com/android/server/am/BroadcastQueue.java:269: r.receiver = app.thread.asBinder();
frameworks/base/services/core/java/com/android/server/am/BroadcastQueue.java:286: app.thread.scheduleReceiver(new Intent(r.intent), r.curReceiver,
frameworks/base/services/core/java/com/android/server/am/BroadcastQueue.java:476: app.thread.scheduleRegisteredReceiver(receiver, intent, resultCode,
frameworks/base/services/core/java/com/android/server/am/ActivityRecord.java:464: app.thread.scheduleActivityConfigurationChanged(
frameworks/base/services/core/java/com/android/server/am/ActivityRecord.java:477: app.thread.scheduleMultiWindowModeChanged(appToken, !task.mFullscreen);
frameworks/base/services/core/java/com/android/server/am/ActivityRecord.java:488: app.thread.schedulePictureInPictureModeChanged(
frameworks/base/services/core/java/com/android/server/am/ActivityRecord.java:962: app.thread.scheduleNewIntent(
frameworks/base/services/core/java/com/android/server/am/ActivityRecord.java:1322: app.thread.scheduleSleeping(appToken, _sleeping);
frameworks/base/services/core/java/com/android/server/am/CompatModePackages.java:379: app.thread.updatePackageCompatibilityInfo(packageName, ci);
frameworks/base/services/core/java/com/android/server/am/ActivityStack.java:1160: prev.app.thread.schedulePauseActivity(prev.appToken, prev.finishing,
frameworks/base/services/core/java/com/android/server/am/ActivityStack.java:1935: r.app.thread.scheduleWindowVisibility(r.appToken, false);
frameworks/base/services/core/java/com/android/server/am/ActivityStack.java:1998: r.app.thread.scheduleWindowVisibility(r.appToken, true);
frameworks/base/services/core/java/com/android/server/am/ActivityStack.java:2015: r.app.thread.scheduleOnNewActivityOptions(r.appToken, r.returningOptions);
frameworks/base/services/core/java/com/android/server/am/ActivityStack.java:2065: waitingActivity.app.thread.scheduleTranslucentConversionComplete(
frameworks/base/services/core/java/com/android/server/am/ActivityStack.java:2536: next.app.thread.scheduleSendResult(next.appToken, a);
frameworks/base/services/core/java/com/android/server/am/ActivityStack.java:2553: next.app.thread.scheduleNewIntent(
frameworks/base/services/core/java/com/android/server/am/ActivityStack.java:2570: next.app.thread.scheduleResumeActivity(next.appToken, next.app.repProcState,
frameworks/base/services/core/java/com/android/server/am/ActivityStack.java:3238: r.app.thread.scheduleSendResult(r.appToken, list);
frameworks/base/services/core/java/com/android/server/am/ActivityStack.java:3344: r.app.thread.scheduleStopActivity(r.appToken, r.visible, r.configChangeFlags);
frameworks/base/services/core/java/com/android/server/am/ActivityStack.java:3465: r.app.thread.scheduleLocalVoiceInteractionStarted((IBinder) r.appToken,
frameworks/base/services/core/java/com/android/server/am/ActivityStack.java:4072: r.app.thread.scheduleDestroyActivity(r.appToken, r.finishing,
frameworks/base/services/core/java/com/android/server/am/ActivityStack.java:4166: r.app.thread.scheduleCancelVisibleBehind(r.appToken);
frameworks/base/services/core/java/com/android/server/am/ActivityStack.java:4821: r.app.thread.scheduleRelaunchActivity(r.appToken, results, newIntents, changes,
2.3 AMS建立和Android应用程序以及关联的四大组件之间的Binder通信小结
至此AMS建立和Android应用程序以及关联的四大组件之间的Binder通信就到这里就告一段落了，它最终是借助匿名Binder的代理端ATP完成了这一切！分析完结我们发现无论是AMS和应用程序通信还是应用程序和AMS之间的通信都是通过Binder的逻辑进行的，只不过一个是实名Binder通信一个是匿名Binder通信而已，所以Android源码的源码学习一定是绕不开Binder的，读者一定要有所掌握不然真的很难深入理解Android源码的一些设计理念。
总结
Android应用程序建立与AMS服务之间的通信过程到这里就要完结了，通过前面的介绍我们知道了Android应用程序和AMS之间的交互主要是通过IApplicationThread与IActivityManager这两个接口来完成的，IActivityManager实现了Android应用程序到AMS之间通信，而IApplicationThread实现了AMS到Android应用程序之间的通信。但是我们这里发现了无论是借助于那个接口，最终都脱离不了Binder通信，所以所以Android源码的源码学习一定是绕不开Binder的，读者一定要有所掌握不然真的很难深入理解Android源码的一些设计理念(打个广告，可以看看我的系列博客Android Binder框架学习系列博客)。好了，青山不改绿水长流先到这里了。如果本博客对你有所帮助，麻烦关注或者点个赞，如果觉得很烂也可以踩一脚！谢谢各位了！！
扫一扫
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
