Android应用程序建立与AMS服务之间的通信过程

     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框架学习系列博客)。好了，青山不改绿水长流先到这里了。如果本博客对你有所帮助，麻烦关注或者点个赞，如果觉得很烂也可以踩一脚！谢谢各位了！！