ApplicationThread 代理启动

ApplicationThread
ActivityThread
这2个类经常出现在AMS框架里面，但是他们都不是线程
ActivityThread 是主线程的逻辑类，但是本身不是线程。
查看源码。有一个main函数。启动主线程轮询。这样也就是同一个线程，也就是充当主线程的作用了。

ApplicationThread充当的作用是Binder机制，他继承的类就可以看出来。是ActivityThread的一个类。
private class ApplicationThread extends IApplicationThread.Stub

其实分析这种IPC通信，有一个基础还是比较重要的。我们看ApplictaionThread就知道是IApplicationThread 接口通信
也就是一个协议吧，就有Proxy啊。Stub啊
Proxy是代理，而Stub则是直接实现接口的实现者。Stub说明
ApplicationThread实现了接口定义的协议，协议定义生命周期的
schedule方法。

public final void schedulePauseActivity(IBinder token, boolean finished,
boolean userLeaving, int configChanges, boolean dontReport) {
int seq = getLifecycleSeq();
if (DEBUG_ORDER) Slog.d(TAG, "pauseActivity " + ActivityThread.this
+ " operation received seq: " + seq);
sendMessage(
finished ? H.PAUSE_ACTIVITY_FINISHING : H.PAUSE_ACTIVITY,
token,
(userLeaving ? USER_LEAVING : 0) | (dontReport ? DONT_REPORT : 0),
configChanges,
seq);
}

Stub作为服务实现者，这里比较奇怪，为什么App进程做服务端呢。仔细想想，Activity的生命周期回调是谁调用的啊。肯定不是
app本身控制，而远程服务通过监听到一系列的操作发起周期回调，AMS持有App的proxy，这个代理的协议是IApplicationThread，于是AMS监控系统需要onResume,则通过proxy发起IApplicationThread的onResume,也就是通知服务去onResume.所以这里作为Binder理解IPC，服务端就是客户端App而不是AMS，AMS作为请求端，持有App进程的代理。

理解这里，对于Activity的onResume onStop被动的周期回调很有帮助。

如果觉得难以理解，我又想到一种思路了。

作为客户端的Activity生命周期等等需要回调，还是以onResume为例，客户端本身肯定不知道什么时候onResume，这时候肯定是
AMS回调Activity对吧，但是AMS怎么通知呢，肯定是IPC，定义一套接口，然后就是接口的CS端，Stub还有Proxy，proxy这里是AMS，Stub就是ApplicationThread，就是这样，AMS去请求接口，https://github.com/android/platform_frameworks_base/blob/master/core/java/android/app/ActivityThread.java