Skip to content

插件守护进程模型.md

Latest commit

 

History

History
127 lines (76 loc) · 4.8 KB

插件守护进程模型.md

File metadata and controls

127 lines (76 loc) · 4.8 KB

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

插件管理进程的启动

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

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

  1. 预定义一个运行在指定进程的ContentProvider。即占坑的ContentProvider。
  2. 应用主进程启动的时候，会通过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);

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

  1. 对于这个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。

  1. 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中传递到了客户端。这个做法有什么好处呢？

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