插件化框架解读之四大组件调用原理-Service(三)下篇
阿里P7移动互联网架构师进阶视频(每日更新中)免费学习请点击:https://space.bilibili.com/474380680
本文将继续通过Service调用原理来解读Replugin插件化技术
一、开启插件内Service
第1步
在《Replugin插件化技术解读之框架初始化、插件安装与加载(二)》中我们知道插件在加载的时候会自动生成PluginContext来作为插件内上下文使用,而插件中startService其实调用的就是已经被重写的startService方法了。
PluginContext.java
public ComponentName startService(Intent service) {
if (mContextInjector != null) {
mContextInjector.startServiceBefore(service);
}
。。。
try {
return PluginServiceClient.startService(this, service, true);
} catch (PluginClientHelper.ShouldCallSystem e) {
// 若打开插件出错,则直接走系统逻辑
return super.startService(service);
} finally {
if (mContextInjector != null) {
mContextInjector.startServiceAfter(service);
}
}
}
第2步
PluginServiceClient.startService中会首先获取ComponentName对象,得到插件包名和对应Service Class类型对象,然后获得开启的Service所属的进程号,如UI进程或者常驻进程。接着会通过进程号获得对应的IPluginServiceService pss对象,进行pss.startService操作。
public static ComponentName startService(Context context, Intent intent, boolean throwOnFail) {
// 1. 从 Intent 中获取 ComponentName,包含想要开启的ServiceName以及插件包名
ComponentName cn = getServiceComponentFromIntent(context, intent);
// 2. 获取将要使用服务的进程ID,
int process = getProcessByComponentName(cn);
if (process == PROCESS_UNKNOWN) {
// 有可能是不支持的插件,也有可能本意就是想调用Main工程的服务。则直接调用系统方法来做
if (LOG) {
LogDebug.d(PLUGIN_TAG, "PSS.startService(): Call SystemAPI: in=" + intent);
}
if (throwOnFail) {
throw new PluginClientHelper.ShouldCallSystem();
} else {
return context.startService(intent);
}
}
// 既然确认是插件,则将之前获取的插件信息填入
intent.setComponent(cn);
//3. 获取对应进程ID的IPluginServiceServer对象,IBinder实现提是PluginServiceService.Stub
IPluginServiceServer pss = sServerFetcher.fetchByProcess(process);
if (pss == null) {
if (LOGR) {
LogRelease.e(PLUGIN_TAG, "psc.ss: pss n");
}
return null;
}
// 开启服务
try {
return pss.startService(intent, sClientMessenger);
} catch (Throwable e) {
if (LOGR) {
LogRelease.e(PLUGIN_TAG, "psc.ss: pss e", e);
}
}
return null;
}
第3步
重点看下如果根据不同进程去生成相应的PSS对象,也就是方法sServerFetcher.fetchByProcess方法
public IPluginServiceServer fetchByProcess(int process) {
if (process == PluginServiceClient.PROCESS_UNKNOWN) {
return null;
}
// 取之前的缓存
IPluginServiceServer pss;
synchronized (PSS_LOCKER) {
pss = mServiceManagerByProcessMap.get(process);
if (pss != null) {
if (LOG) {
LogDebug.d(PLUGIN_TAG, "PluginServiceClient.fsmbp(): Exists! p=" + process);
}
return pss;
}
}
// 缓存没有?则去目标进程获取新的
if (LOG) {
LogDebug.d(PLUGIN_TAG, "PluginServiceClient.fsmbp(): Create a new one! p=" + process);
}
try {
if (process == IPluginManager.PROCESS_PERSIST) {
//1. 如果是常驻进程,则直接获取得到Pss对象,PluginServiceServer.mStub
IPluginHost ph = PluginProcessMain.getPluginHost();
pss = ph.fetchServiceServer();
} else {
//2. 如果是非常驻其他进程,则会通过 MP.startPluginProcess方法,利用动态编译自动生成的进程挂在宿主Manifest中的Provider
//去通过PluginProviderStub.proxyStartPluginProcess 利用insert方法去吊起provider对应的进程号,开启进程
//IPluginClient的实现体就是PluginProcessPer中,获得对象同样是PluginServiceServer.mStub
PluginBinderInfo pbi = new PluginBinderInfo(PluginBinderInfo.NONE_REQUEST);
IPluginClient pc = MP.startPluginProcess(null, process, pbi);
pss = pc.fetchServiceServer();
}
// 挂死亡周期,如果出问题了就置空重来,防止外界调用psm出现DeadObject问题
pss.asBinder().linkToDeath(new PSSDeathMonitor(process, pss.asBinder()), 0);
} catch (Throwable e) {
if (LOGR) {
LogRelease.e(PLUGIN_TAG, "psc.fsm: e", e);
}
}
if (pss != null) {
synchronized (PSS_LOCKER) {
mServiceManagerByProcessMap.put(process, pss);
}
}
return pss;
}
- 显然,针对不同进程号,使用了一个ArrayMap来缓存对应pss对象,如果是常驻进程,也就是进程号
process == IPluginManager.PROCESS_PERSIST
会直接获得PluginServiceServer.mStub的IPluginServiceService对象来进行相关Service操作。
- 如果Service所处的是非常驻进程,这里会采用一个比较巧妙的方法去首先拉起该进程,跟踪下面方法:
IPluginClient pc = MP.startPluginProcess(null, process, pbi);
MP.java
public static final IPluginClient startPluginProcess(String plugin, int process, PluginBinderInfo info) throws RemoteException {
return PluginProcessMain.getPluginHost().startPluginProcess(plugin, process, info);
}
显然,会调用常驻进程服务的PmHostSvc.startPluginProcess方法去拉起对应进程,PmHostSvc常驻进程服务再整个Replugin确实起到了对各插件管理的作用,包括拉起插件Service进程。继续往下看,调用了PmBase.startPluginProcessLocked方法:
final IPluginClient startPluginProcessLocked(String plugin, int process, PluginBinderInfo info) {
......
PluginProcessMain.schedulePluginProcessLoop(PluginProcessMain.CHECK_STAGE1_DELAY);
// 尝试从缓存中查找
IPluginClient client = PluginProcessMain.probePluginClient(plugin, process, info);
......
int index = IPluginManager.PROCESS_AUTO;
try {
index = PluginProcessMain.allocProcess(plugin, process);
} catch (Throwable e) {
}
// 启动
boolean rc = PluginProviderStub.proxyStartPluginProcess(mContext, index);
......
// 再次获取
client = PluginProcessMain.probePluginClient(plugin, process, info);
......
return client;
}
PluginProviderStub.proxyStartPluginProcess方法去会吊起对应进程,代码如下:
PluginProviderStub.java
static final boolean proxyStartPluginProcess(Context context, int index) {
//
ContentValues values = new ContentValues();
values.put(KEY_METHOD, METHOD_START_PROCESS);
values.put(KEY_COOKIE, PMF.sPluginMgr.mLocalCookie);
Uri uri = context.getContentResolver().insert(ProcessPitProviderBase.buildUri(index), values);
if (LOG) {
LogDebug.d(PLUGIN_TAG, "proxyStartPluginProcess insert.rc=" + (uri != null ? uri.toString() : "null"));
}
if (uri == null) {
if (LOG) {
LogDebug.d(PLUGIN_TAG, "proxyStartPluginProcess failed");
}
return false;
}
return true;
}
这里是个对数据库Provider的插入操作,那么究竟是对哪个Provider进行了数据库操作呢?
关键在这里:
ProcessPitProviderBase.buildUri(index)
最终生成的Uri是这样的:
content://com.qihoo360.replugin.sample.host.loader.p.mainN99/main
这个玩意对应的啥呢?貌似宿主Manifest中并没有配置这个,如果分析过gradle插件应该可以想到,估计又是动态编译自动生成的,反编译宿主apk可以在Manifest中发现:
<provider
android:name="com.qihoo360.replugin.component.process.ProcessPitProviderP0"
android:exported="false"
android:process=":p0"
android:authorities="com.qihoo360.replugin.sample.host.loader.p.mainN100" />
这样就全部串起来啦,想要开启分配在自定义进程中的Service首先就需要通过启动动态编译自动生成的对应进程Provider来拉起进程。
最终返回的IPluginClient的IBinder实现体其实就是PluginProcessPer,生成的PSS也就是PluginServiceServer.mStub了。跟上述常驻进程生成的PSS方式是一样的。
第4步
PSS中startService最终调用的是PluginServiceServer.this.startServiceLocked(intent,client)方法,其内部首先通过retrieveServiceLocked方法生成ServiceRecord对象,接着利用installServiceIfNeededLocked方法去加载Service对象,利用发射将PluginContext通过attachBaseContextLocked方法赋值到上下文内部,接着执行Service的onCreate方法,然后记录以及被加载,同时startPitService开启一个坑位Service,提高进程优先级防止被杀,后面继续调用onStartCommand方法。
// 加载插件,获取Service对象,并将其缓存起来
private boolean installServiceLocked(ServiceRecord sr) {
// 通过ServiceInfo创建Service对象
Context plgc = Factory.queryPluginContext(sr.plugin);
if (plgc == null) {
if (LogDebug.LOG) {
Log.e(TAG, "installServiceLocked(): Fetch Context Error! pn=" + sr.plugin);
}
return false;
}
ClassLoader cl = plgc.getClassLoader();
if (cl == null) {
if (LOGR) {
LogRelease.e(PLUGIN_TAG, "psm.is: cl n " + sr.className);
}
return false;
}
// 构建Service对象
Service s;
try {
s = (Service) cl.loadClass(sr.serviceInfo.name).newInstance();
} catch (Throwable e) {
if (LOGR) {
LogRelease.e(TAG, "isl: ni f " + sr.plugin, e);
}
return false;
}
// 只复写Context,别的都不做
try {
attachBaseContextLocked(s, plgc);
} catch (Throwable e) {
if (LOGR) {
LogRelease.e(PLUGIN_TAG, "psm.is: abc e", e);
}
return false;
}
s.onCreate();
sr.service = s;
// 开启“坑位”服务,防止进程被杀
startPitService();
return true;
}
二、总结
针对插件中startService的Service对象,其实Replugin框架仅仅将此Service当做一个普通的类进行代码强制执行其对应的生命周期各回调方法,当然Android FWK启动Service证明周期也是类似的方式做的,只是原始启动Service的各生命周期是在进程对应的ActivityThread中,而Replugin则是在PSS内部代码执行。这一点跟启动插件Activity是不太一样的。同时还有一个就是启动自定义进程的Service会利用动态编译自动生成的对应该进程的Provider,首先调用该Provider的insert数据库操作去吊起此进程,然后再获得IPluginClient中的PSS,显然,Replugin框架的使用动态编译的地方无处不在。
原文链接:https://blog.csdn.net/hellogmm/article/details/79188334
阿里P7移动互联网架构师进阶视频(每日更新中)免费学习请点击:https://space.bilibili.com/474380680
插件化框架解读之四大组件调用原理-Service(三)下篇的更多相关文章
- 插件化框架解读之四大组件调用原理-Activity(三)上篇
阿里P7移动互联网架构师进阶视频(每日更新中)免费学习请点击:https://space.bilibili.com/474380680 本文通过Activity调用原理来解读Replugin插件化技术 ...
- 插件化框架解读之android系统服务实现原理(五)
阿里P7移动互联网架构师进阶视频(每日更新中)免费学习请点击:https://space.bilibili.com/474380680 一.系统服务提供方式 1.我们平时最常见的系统服务使用方式 Wi ...
- Android Small插件化框架解读——Activity注册和生命周期
通过对嵌入式企鹅圈原创团队成员degao之前发表的<Android Small插件化框架源码分析>的学习,对Android使用的插件化技术有了初步的了解,但还是有很多需要认真学习的地方,特 ...
- 插件化框架解读之so 文件加载机制(四)
阿里P7移动互联网架构师进阶视频(每日更新中)免费学习请点击:https://space.bilibili.com/474380680 提问 本文的结论是跟着 System.loadlibrary() ...
- 插件化框架解读之Android 资源加载机制详解(二)
阿里P7移动互联网架构师进阶视频(每日更新中)免费学习请点击:https://space.bilibili.com/474380680Android提供了一种非常灵活的资源系统,可以根据不同的条件提供 ...
- 插件化框架解读之Class文件与Dex文件的结构(一)
阿里P7移动互联网架构师进阶视频(每日更新中)免费学习请点击:https://space.bilibili.com/474380680 Class文件 Class文件是Java虚拟机定义并被其所识别的 ...
- [置顶]
滴滴插件化框架VirtualAPK原理解析(一)之插件Activity管理
上周末,滴滴与360都开源了各自的插件化框架,VirtualAPK与RePlugin,作为一个插件化方面的狂热研究者,在周末就迫不及待的下载了Virtualapk框架来进行研究,本篇博客带来的是Vir ...
- Android插件化框架
1. dynamic-load-apk/DL动态加载框架 是基于代理的方式实现插件框架,对 App 的表层做了处理,通过在 Manifest 中注册代理组件,当启动插件组件时,首先启动一个代理组件 ...
- android 插件化框架VitualAPK
推荐阅读: 滴滴Booster移动App质量优化框架-学习之旅 一 Android 模块Api化演练 不一样视角的Glide剖析(一) LeakCanary 与 鹅场Matrix ResourceCa ...
随机推荐
- 用Fusion Log诊断同一版本冲突问题解决
处理方法,修改注册表 Add the following values to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion Add: DWORD Force ...
- Address already in use : connect
Address already in use : connect 错误以及处理 项目中有过手写并发测试,在长时间的并发测试(超过20秒,美妙超过2000)的情况下出现了以上错误 处理方法如下(抄的) ...
- elasticsearch 基础 —— Query String
使用查询解析器来解析其内容的查询.下面是一个例子: GET /_search { "query": { "query_string" : { "def ...
- smbclient - 类似FTP操作方式的访问SMB/CIFS服务器资源的客户端
总览 SYNOPSIS smbclient {servicename} [password] [-b <buffer size>] [-d debuglevel] [-D Director ...
- Linux命令(干货)
@ vim 编辑快捷键 ctrl + n 是自动补齐 ctrl + p 是往上选择 ctrl + f 是下一屏幕 ctrl + b 是上一屏幕 w:是移动一个单词 b:是向前一个单词 d^:当前行中, ...
- 初学Java if选择语句
import java.util.Scanner; public class SubtractionQuiz { public static void main(String[] agrs) { ); ...
- rabbiitmq非阻塞调用
https://blog.csdn.net/panxianzhan/article/details/50755409 https://blog.csdn.net/u013946356/article/ ...
- java ArrayList的几种方法使用
package java06; import java.util.ArrayList; /* ArrayList的常用的几个方法: public boolean add(E e) : 向集合汇总添加元 ...
- MySQL系列之三查询优化
通常来说,查询的生命周期大致可以按照顺序来看从客户端到服务端,然后在服务器上进行解析,生产执行计划, 执行,并返回结果给客户端.其中的执行阶段可以认为是整个生命周期中最重要的阶段,其中包括了大量为了检 ...
- windows平台搭建Mongo数据库复制集(类似集群)(三)
在本篇里面,咱们重点总结一下复制集,以及分析一下它的工作原理 一.常见场景 应用程序和数据库之间的网络连接丢失 计划停机.断电.数据库服务硬盘故障等等 复制可以进行故障转移,复制能让你在副本间均衡读负 ...