找到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事件
也印证了改堆栈
