Android Framework startServices 流程

找到Activity它继承的Context里面就有startService函数
具体实现在ContextImpl，而ContextImpl则是由createBaseContextForActivity这个函数创建的，简单点说就是ActivityThread，startActivity时创建并赋予的

startService往下找就会找到一个Service

接下来就是启动服务 的AIDL流程

找到这个AMS服务,他继承了IActivityManager.Stub,正常情况下Stub是服务端的一个内部内，用来实现aidl的接口调用。也就是说他就是服务功能的具体实现者。

这个ActivieServices持有AMS是一个包装类，注意此处的hostingType

bringUpServiceLocked有两路
1.当目标进程已存在，则直接执行realStartServiceLocked()；
2.当目标进程不存在，则先执行startProcessLocked创建进程

以下介绍流程二

意思是让zygote启动这个进程

很明显用的sock连接完成io交互，总之会给一个result回来，

其实反向分析也可以初见端倪
Log.i(TAG, "Service Created",new Exception());

从日志中发现，我们需要从ZygoteInit.main开始分析。
frameworks/base/core/java/com/android/internal/os/ZygoteInit.java

ZygoteInit会fork新进程并返回pid给客户端 的ZygotePrcess

服务端的for循环监听

prcessOneCmmand处理接收到的数据并执行命令

最终走到ZygoteInit的zygoteInit函数初始化

这里就是到了RuntTimeInit的appinit函数

这个RuntTimeInit主要工作就是findStaticMain 反射main函数

MeathondAndArgsCaller 内容就是反射ActivtyThread.main函数

终于到了这里的ActivityThread.main部分。我们知道到这里app的进程才算正式启动了

这段代码很牛皮
将获取AMS服务实例 并attachApplication,mAppThread作为客户端回调监听，给到RunTimeInit来维护。

最终走到了AMS.attachApplicationLocked

发现ApplicationThread就是ActivityThread内部成员也是aidl的接口功能实现，这里终于到了handler sendMessage流程


他post一下其实就还是在ActivityThread这个类实现，handler作为统一调度工具，避免事件紊乱而这样设计。

AMS包装类调用AtivityThread去post一个creat_Services事件

最后看到Service基本就是已经启动了

回到前面的realStartServiceLocked 我们快速介绍流程一

这里的thread就是ActivityThread的内部Stub IApplicationThread,scheduleCreateService就是调用ActivityThread的post CREATE_SERVICE 事件，在内部内Handler的handleMessage中实现功能

最终成功回到OnCreat事件

也印证了改堆栈