VirtualApk源码分析- service插件化

简介: android启动Service有两种方式,一种是startService,还有一种是bindService,关于startService的启动流程可以参照https://www.

android启动Service有两种方式,一种是startService,还有一种是bindService,关于startService的启动流程可以参照https://www.jianshu.com/p/fd31917c518a ,bindService的运行流程如下所示:

img_d8f56baea006d592d990585b22bd517f.png
bindService流程

1、Activity.bindService-->ContextImpl.bindService-->ContextImpl.bindServiceCommon

img_094283902995e0e25e62ab539ed1e4c0.png
ContextImpl.bindServiceCommon

ContextImpl.bindServiceCommon首先调用mPackageInfo.getServiceDispatcher获取IServiceConnection对象,IServiceConnection是个Binder类型,具体内容如下:

img_931f2303ae39ebdbec74a42821ccba21.png
mPackageInfo.getServiceDispatcher

mPackageInfo.getServiceDispatcher中先创建了ServiceDispatcher,并传入bindService调用方的ServiceConnection,返回调用ServiceDispatcher.getIServiceConnection:

img_dd3062a26cca50dc2c42425ab7d0260a.png
ServiceDispatcher.getIServiceConnection

其中mIServiceConnection是在ServiceDispatcher中赋值的:

img_fe2462537f45f2384702f3eb3138664d.png
ServiceDispatcher构造函数

mIServiceConnection的实现类是InnerConnection:

img_359c28f628a7ca11664daac148dbd839.png
InnerConnection

InnerConnection是Binder Service端的存根,返回给Binder Client端进行跨进程调用的,在bindService的时候将InnerConnection对象传送给AMS,这样AMS就可以跨进程调用bindService调用方的ServiceConnection。这一点和ApplicationThread以及广播的IIntentReceiver如出一辙。

创建完IServiceConnection后就调用AMS的bindService并传入IServiceConnection对象。

2、AMS.bindService-->ActiveServices.bindServiceLocked-->ActiveServices.requestServiceBindingLocked

在bindServiceLocked函数中,判断是否是AUTO_CREATE,如果是,就调用bringUpServiceLocked启动Service并触发Service.onCreate,然后再requestServiceBindingLocked:

img_351ffca44778795886e368b388435ee2.png
requestServiceBindingLocked

requestServiceBindingLocked会调用ApplicationThread.scheduleBindService

3、ApplicationThread.scheduleBindService-->ActivityThread.handleBindService

img_0bd5517f8752f5d88d0ee0963697def3.png
ActivityThread.handleBindService

ActivityThread.handleBindService首先从mServices中取出要Binde的service(在第二步bindServiceLocked函数中会创建Service对象并保存),取到之后就调用s.onBind方法获取当前Service返回给远程bindService调用方的binder对象,最后调用AMS.plublishService,并将s.onBind传过去,该值最终会传给bindService的ServiceConnection.onServiceConnected中。

4、AMS.publishService-->ActiveServices.publishServiceLocked

img_4da1ea79567a56cf4bec30f2926cb51b.png
ActiveServices.publishServiceLocked

ActiveServices.publishServiceLocked中调用了c.conn.connected,c.conn就是第一步中创建的InnerConnection对象,c.conn.connected会调用ServiceDispatcher.doConnected:

img_b55b48a1e759bebc0d35193dcbaf1b2b.png
ServiceDispatcher.doConnected

ServiceDispatcher.doConnected最终调用了ServiceConnection.onServiceConnectioned,并传入第三步中s.onBind的返回值。

5、bindService的调用以AMS.serviceDoneExecuting收尾。

在理解了startService和bindService的运行流程后,似乎对Service如何插件化还没任何思路。下面说下VirtualApk是如何实现的吧。

VitualApk在实现Service插件化的时候依然是采用的宿主占坑的方案,通过在宿主实现占坑的LocalService和RemoteService,

img_2109d8de87ca0626eaecec16a662648d.png
占坑Service

通过hook掉AMS启动Service相关的方法,如果发现是启动插件的Service,就将目标Service转化为宿主占坑的Service,再由宿主占坑Service实现代理转发,在宿主Service中反射加载插件Service的实例,并调用其对对应的方法,这里以LocalService为例,描述下整个流程:

1、Hook掉AMS的startService bindService等函数

img_b17b470516ff6b5ce9a9f9fb2126c269.png
PulginManager.hookSystemServices

hookSystemService会替换掉当前进程的AMS本地代理,实现了自己的ActivityManagerProxy

img_c71a6ea1923d95eda9768648e80c8f5e.png
ActivityManagerProxy.invoke

ActivityManagerProxy hook调用Service相关的方法,这里以startService为例:

img_ea88feb4670a764be9fb14873a4362e9.png
ActivityManagerProxy .startService

startService中会调用startDelegateServiceForTarget:

img_19c5c0d42d1ace0fb9d68deadb7d3a64.png
startDelegateServiceForTarget

其中wapperTargetIntent将启动插件Service的Intent转为启动宿主占坑Service:

img_3f978d89ead1f9d5d24dc6761455ba80.png
wapperTargetIntent

2、LocalService的处理

第一步将启动插件Service的Intent转为了启动宿主占坑的LocalService,LocalService中会实现代理转发。LocalService.onStartCommand中有如下代码:

img_b95daff7f0dd67ad42fad3e00ef2ddb7.png
LocalService.onStartCommand

LocalService.onStartCommand首先反射创建插件Service对象,返回反射调用了其attach方法,最后调用了Service.onCreate,这样就完成了startService启动插件Service的插件化。

其他Service方法的插件化类似,可自行分析。

目录
相关文章
|
6月前
|
负载均衡 监控 Cloud Native
|
6月前
|
负载均衡 监控 Cloud Native
Service Mesh的实现原理
【5月更文挑战第6天】Service Mesh是一种针对云原生应用的服务治理技术,通过轻量级网络代理(SideCar)实现服务间的通信和可靠性保证,无需代码集成。它解决了跨语言服务调用和云原生服务治理的问题。
|
6月前
|
负载均衡 监控 Cloud Native
Service Mesh 的实现原理
【2月更文挑战第20天】
|
11月前
|
Kubernetes 监控 Cloud Native
k8s 自身原理之 Service
k8s 自身原理之 Service
|
11月前
|
存储 Web App开发 缓存
WorkBox 之底层逻辑Service Worker(二)
WorkBox 之底层逻辑Service Worker(二)
169 0
|
11月前
|
存储 缓存 前端开发
WorkBox 之底层逻辑Service Worker(一)
WorkBox 之底层逻辑Service Worker(一)
104 0
|
存储 XML Java
Flowable:ProcessEngin(引擎)与Service(服务接口)讲解
Flowable:ProcessEngin(引擎)与Service(服务接口)讲解
334 0
|
Kubernetes 监控 Perl
【k8s 系列】k8s 学习二十七 - 6,k8s 自身原理之 Service
好不容易,终于来到 k8s 自身的原理之 关于 Service 的一部分了 前面我们用 2 个简图展示了 pod 之间和 pod 与 node 之间是如何通信息的,且通信的数据包是不会经过 NAT 网络地址转换的
|
域名解析 Kubernetes 负载均衡
k8s service 概念和原理
详细讲解k8s的概念和原理
823 0
k8s service 概念和原理
|
存储 负载均衡 Kubernetes
简单说说K8S的Service底层,总感觉还是说不清楚。
简单说说K8S的Service底层,总感觉还是说不清楚。
195 0