一、从插件中startService的流程
这个过程虽然比Activity启动简单很多，但是需要深入理解android源码。点此链接可查看高清svg图：
过程分拆：
1、Hook工作
在插件内调用startService，会进入hooked StartService方法，该方法会调用VActivityManager的public ComponentName startService(IInterface caller, Intent service, String resolvedType, int userId)方法，当然，其实最终是调用了:x进程的VActivityManagerService的对应方法。
2、VActivityManagerService内部处理之一
startService方法会调用内部的startServiceCommon方法，startServiceCommon方法会先判断是否需要启动新进程（支持Service在远程进程），如果需要则启动，并且会返回ProcessRecord（包含了Service所在进程的ApplicationThread）；然后，调用findRecordLocked方法判断是否存在此Service的记录ServiceRecord，如果ServiceRecord是null或者ServiceRecord中的prcoess（ProcessRecord）为null，说明没有启动过该Service，从而needCreateService被置为true，接下来调用远程ApplicationThread的scheduleCreateService方法，并记录下此Service已启动，注意：后续stopService会用到对应的ServiceRecord。
3、Service所在进程处理之一（全是android源码）
ApplicationThread的scheduleCreateService方法会向ActivityThread发送CREATE_SERVICE消息，ActivityThread接收此消息后调用handleCreateService方法，内部会加载Service，调用Service的onCreate方法等，然后，调用ActivityManagerNative.getDefault()的serviceDoneExecuting方法告知远程创建完成。
4、hook serviceDoneExecuting
不过，serviceDoneExecuting也被hook了，它会调用VActivityManager的public void serviceDoneExecuting(IBinder token, int type, int startId, in tres)的方法，当然，其实最终是调用了:x进程的VActivityManagerService的对应方法。
5、VActivityManagerService内部处理之二
VActivityManagerService继续调用requestServiceBindingsLocked方法判断之前是否有被pending的bind请求（即非BIND_AUTO_CREATE的bindService）。如果有，调用远程ApplicationThread的scheduleBindService方法执行绑定操作（稍后会详细介绍bindService和unBindService）。
6、VActivityManagerService内部处理之三
VActivityManagerService继续调用远程ApplicationThread的scheduleServiceArgs方法。
7、Service所在进程处理之二（全是android源码）
ApplicationThread的scheduleServiceArgs方法会向ActivityThread发送SERVICE_ARGS消息，ActivityThread接收此消息后调用handleServiceArgs方法，内部会调用Service的onStartCommand方法等，最后，调用ActivityManagerNative.getDefault()的serviceDoneExecuting方法告知远程start完成。
8、hook serviceDoneExecuting
同4。
二、从插件中stopService的流程
点此链接可查看高清svg图：
过程分拆：
1、Hook工作
在插件内调用stopService，会进入hooked StopService方法，该方法会调用VActivityManager的public int stopService(IInterface caller, Intent service, String resolvedType)方法，当然，其实最终是调用了:x进程的VActivityManagerService的对应方法。
2、VActivityManagerService内部处理之一
stopService方法会调用内部的findRecordLocked方法判断是否启动过此Service，如果已经启动，则查看
是否有BIND_AUTO_CREATE模式的bindService，如果有，则结束此次调用；
如果没有，则再次判断是否有非BIND_AUTO_CREATE模式的bindService，如果有，则调用远程ApplicationThread的scheduleUnbindService方法结束绑定，最终，调用scheduleStopService方法，传递的参数则是ServiceRecord（Binder对象）。
3、Service所在进程处理之一（全是android源码）
ApplicationThread的scheduleStopService方法会向ActivityThread发送STOP_SERVICE消息，ActivityThread接收此消息后调用handleStopService方法，内部会调用对应Service（注意：Service和token一一对应）的onDestroy方法等，最后，调用ActivityManagerNative.getDefault()的serviceDoneExecuting方法告知远程销毁完成。
4、hook serviceDoneExecuting
serviceDoneExecuting也被hook了，它会调用VActivityManager的public void serviceDoneExecuting(IBinder token, int type, int startId, int res)的方法，当然，其实最终是调用了:x进程的VActivityManagerService的对应方法。此方法的作用是移除对应的ServiceRecord。
三、从插件中的Service调用stopSelf的过程
stopSelf有两个重载方法：
其中mToken是VActivityManagerService记录Service启动所用的ServiceRecord，stopSelf方法最终会调用stopServiceToken方法（被Hook了）：
点此链接可查看高清svg图：
过程分拆：
1、Hook工作
进入hooked StopServiceToken方法后，该方法会调用VActivityManager的public boolean isVAServiceToken(IBinder token)方法，当然，其实最终是调用了:x进程的VActivityManagerService的对应方法。
2、VActivityManagerService内部处理之一
isVAServiceToken方法判断传递进来的token是不是ServiceRecord，如果是，返回true。
3、请求stopServiceToken
StopServiceToken继续调用VActivityManager的public boolean stopServiceToken(ComponentName className, IBinder token,int startId)方法，当然，其实最终是调用了:x进程的VActivityManagerService的对应方法。
4、VActivityManagerService内部处理之二
stopServiceToken方法判断传递进来的startId是否为ServiceRecrod记录的最后一个startId，或者startId==-1，如果是，则接下来处理操作同《从插件中stopService的流程》第2步之后的所有操作。
