# 插件守护进程模型

站点：答源（https://www.dandroid.cn/）
原文：https://www.dandroid.cn/archives/20285
Canonical：https://www.dandroid.cn/archives/20285
作者：admin
发布日期：2023-09-13
最后更新：2023-09-13 15:52
分类：教程
内容类型：post
说明：本页是原文的纯文本镜像，供大模型与检索器完整读取；不含导航、广告、付费框。引用请以上方「原文」链接为准。

## 正文

Replugin与VirtualApk很大的一个不同就是: 对于插件的管理，它支持单独开辟一个进程来做管理。本文就来看一下这个进程的工作原理以及作用。

插件管理进程的启动

在Android中四大组件都是可以指定在一个单独进程中运行的。Android官方推荐我们使用Service来开启一个后台进程，但是Replugin的插件管理进程并不是一个Service而是一个ContentProvider。
具体说是使用ContentProvider来开辟一个进程来 :

在前面分析ContentProvider启动过程时了解到如果给一个ContentProvider在manifest文件中指定了进程，那么这个ContentProvider会运行在指定进程中。因此Replugin插件管理进程的实现是:

预定义一个运行在指定进程的ContentProvider。即占坑的ContentProvider。

应用主进程启动的时候，会通过getContentResolver().quey(uri)(这个uri指向占坑的ContentProvider)来唤醒占坑ContentProvider，即唤醒插件管理进程。

来看一下代码:

 Uri uri = ProcessPitProviderPersist.URI; //这个uri指定占坑的ContentProvider
 cursor = context.getContentResolver().query(uri, PROJECTION_MAIN, selection, null, null);

通过这个技巧，插件管理进程就真正在系统中运行起来了。

客户端与插件管理进程的通信

在继续分析之前，我们先约定一下 : 插件管理进程叫做Server。宿主进程叫做Client。（宿主进程即我们应用运行的进程）

那么服务端进程和客户端进程如何通信呢？

可以使用Binder，而在Android中最简单的Binder使用就是Service了。即Service提供给Client一个Binder，Client使用这个Binder来和服务端通信。但是对于Service，我们可以通过bindService(intent, ServiceConnection)，即ServiceConnection的回调来拿到Service的Binder。

那Replugin的客户端进程是如何拿到服务端进程的Binder的呢？

它的实现是: 把Binder放在Cursor中传递给客户端 我们向ContentProvider查询数据时，如果ContentProvider运行在其他进程，那么数据是通过Binder来跨进程传递的。Replugin把Binder当做一个数据。通过系统提供的ContentProvider的跨进程访问机制来传递。

下面我们就来具体看一下实现细节:

Client通过query方法获取插件管理进程的Binder:

cursor = context.getContentResolver().query(uri, PROJECTION_MAIN, "main_binder", null, null);

IBinder binder = BinderCursor.getBinder(cursor); 

我们分两个部分来看这两行代码

对于这个query,返回的cursor是如何保存Binder的呢？

看一下占坑ContentProvider的处理逻辑，query方法最后会调用到下面的方法 :

 .....
 Cursor stubMain(Uri uri, String[] projection, String selection, String[] selectionArgs, String sortOrder) {

 if ("main_binder".equals(selection)) {
 return BinderCursor.queryBinder(PMF.sPluginMgr.getHostBinder());
 }

 if ("main_refer".equals(selection)) {
 ...
 return BinderCursor.queryBinder(sPrefImpl);
 }

 return null;
}

即根据传过来的selection来返回了一个BinderCursor。BinderCursor其实就是一个Cursor:

public class BinderCursor extends MatrixCursor {

 public BinderCursor(String[] columnNames, IBinder binder) {
 super(columnNames);

 if (binder != null) {
 Parcelable value = new BinderParcelable(binder);
 mBinderExtra.putParcelable(BINDER_KEY, value);
 }
 }

 @Override
 public Bundle getExtras() {
 return mBinderExtra;
 }
}

即它复写了Cursor的getExtras方法。返回了mBinderExtra。mBinderExtra里面就保存了一个Binder :

public static final Cursor queryBinder(IBinder binder) {
 return new BinderCursor(PluginInfo.QUERY_COLUMNS, binder);
}

所有query方法就是，返回给客户端一个BinderCursor,它里面包含一个Binder。

Client取出Binder

很简单， 直接从BinderCursor的extra中获取就可以了。

public static final IBinder getBinder(Cursor cursor) {
 Bundle extras = cursor.getExtras();
 extras.setClassLoader(BinderCursor.class.getClassLoader());
 BinderParcelable w = (BinderParcelable) extras.getParcelable(BINDER_KEY);
 return w.mBinder;
}

综上所述，通过把Service的Binder放在ContentProvider的自定义BinderCursor中传递到了客户端。这个做法有什么好处呢？

Client可以通过不同的query来获的不同的服务端进程的Binder。

---
由 答源 DAN 底座 1.4.0 生成 · 2026-11-08T17:26:09+00:00