从getSystemService()开始,开撸Binder通讯机制

阅读 343
收藏 26
2017-08-09
原文链接:www.jianshu.com
image
image

Binder系列第一篇:《从getSystemService()开始,开撸Binder通讯机制》http://www.jianshu.com/p/1050ce12bc1e

Binder系列第二篇:《能用【白话文】来分析Binder通讯机制?》http://www.jianshu.com/p/fe816777f2cf

Binder系列第三篇:《Binder机制之一次响应的故事》http://www.jianshu.com/p/4fba927dce05

Binder系列第二篇已经上线!我为什么选择用【白话文】来分析Binder通讯机制?- http://www.jianshu.com/p/fe816777f2cf

始于getSystemService()

类似下面的代码,相信各位已经写了100遍了!

val accessibilityManager: AccessibilityManager =
        getSystemService(Context.ACCESSIBILITY_SERVICE) as AccessibilityManager

很简单,我们通过getSystemService()获取到了系统服务代理AccessibilityManager,我们通过应用内的AccessibilityManager可以系统中真正的AccessibilityManager互动。怎么做到的呢?我们慢慢来看,先从这个服务是怎么获取到的开始吧。

getSystemService()实质

我们平时调用getSystemService()实际获取到的是在SystemServiceRegistry中注册的各种系统服务的代理,它们大多在注册的时候会通过ServiceManager.getService()来取得和对应Service交互的IBinder对象,然后创建Service代理。

所以,ServiceManager.getService()应该才算是真正的起点吧。这个方法CoorChice这篇文章《3分钟看懂Activity启动流程》:http://www.jianshu.com/p/9ecea420eb52 中有提到过,在那里ActivityManagerNative通过ServiceManager.getService("Activtiy")获取到了和ActivityManager交互的IBinder对象,并使用它创建了应用程序的ActivityManagerProxy。就不多说,感兴趣的同学可以先看看那篇文章。

这是一张重要的图

image
image

还是从ServiceManager.getService()开始吧

上面这张图其实已经把整个流程描绘的很清楚了,流程不算长,接下来就根据这张图分析下。

图是从红色箭头开始看的,然后你可以跟着箭头一步一梳理这个流程,箭头上都有数字的!然后就是哪些个圈圈,相同颜色的表示同一个对象。So Sweet!

步骤1 开始创建IServiceManager

首先,既然是ServiceManager.getService()方法,那我们当然要毫不犹的直接看这个方法。

public static IBinder getService(String name) {
    try {
        // 先从缓存取
        IBinder service = sCache.get(name);
        if (service != null) {
            return service;
        } else {
            // 没有就去获取
            return getIServiceManager().getService(name);
        }
    } catch (RemoteException e) {
        Log.e(TAG, "error in getService", e);
    }
    return null;
}

可以看出,ServiceManager中会缓存用过的系统服务的IBinder。只有首次使用才去获取,非常科学。需要注意的是,是通过ServiceManager中的成员IServiceManager去获取的。

接下来,我们需要看看ServiceManager的获取过程。进入getIServiceManager()方法。

private static IServiceManager getIServiceManager() {
    if (sServiceManager != null) {
        //确保sServiceManager在进程中是单例
        return sServiceManager;
    }
    
    // 第一次会去获取sServiceManager
    sServiceManager = ServiceManagerNative.asInterface(BinderInternal.getContextObject());
    return sServiceManager;
}

非常简单的一个方法。从中我们可以看出,IServiceManager在应用程序中是一个单例,它用于应用程序内管理Service,它实际是系统的ServiceManager的代理。

在首次调用这个方法时,自然是要创建IServiceManager。通过ServiceManagerNative.asInterface(BinderInternal.getContextObject())这么简单的一句创建了。假象!这一句隐藏了很多玄机。我们接着探索。

步骤2 获取参数IBinder

按照代码执行顺序来,我们先看ServiceManagerNative.asInterface()方法的参数BinderInternal.getContextObject()干了些什么?

手动档单击进入BinderInternal.java后可以看到,这是个native方法!

image
image
public static final native IBinder getContextObject();

WTF?我好慌,而且很害怕!没JNI层源码怎么办?

《AndroidXRed》http://androidxref.com一个神奇的网站!

这个网站可以查看Android从底层到上层的所有源码,并且支持多种搜索,基本上能实现手动挡单击跳转的伪效果。非常的屌!对于CoorChice这种没什么内存,不敢编译源码的低配电脑而言,简直是福音!

现在可以看源码了,CoorChice这里选择了Lollipop - 5.0.0_r2版本的源码。

image
image

从这里开始,你需要了解一些c/c++和JNI的知识。快复习一下吧!

步骤3 在JNI中看IBinder的获取过程

上面那个方法的JNI是在这个文件中的/frameworks/base/core/jni/android_util_Binder.cpp

//这些方法会通过动态注册的方式注册到BinderInternal.java中
static const JNINativeMethod gBinderInternalMethods[] = {
    //getContextObject()就是JNI函数android_os_BinderInternal_getContextObject()
    { "getContextObject", "()Landroid/os/IBinder;", (void*)android_os_BinderInternal_getContextObject },
    ...
};

如果我们要找getContextObject()这个名字的函数,你会发现找不见,因为这里采用了动态注册的方法来注册相关函数的。所以,我们会在上面的方法数组中发现一个字符串"getContextObject"。嗯,就是它了。它所对应的函数是android_os_BinderInternal_getContextObject()

static jobject android_os_BinderInternal_getContextObject(JNIEnv* env, jobject clazz)
{
    //通过ProcessState单例获取handle句柄为0的IBinder
    sp<IBinder> b = ProcessState::self()->getContextObject(NULL);
    return javaObjectForIBinder(env, b);
}

这个函数很简单,但是暗藏玄机+1!通过ProcessState获取到了一个IBinder,并转换成Java层的IBinder返回给Java层。

接下来看看是怎么通过ProcessState获取到这个IBinder的。

步骤4 获取ProcessState的函数self()

首先,从ProcessState::self()看来,ProcessState应该是个单例。我们到self()里验证下。

sp<ProcessState> ProcessState::self()
{
    Mutex::Autolock _l(gProcessMutex);
    if (gProcess != NULL) {
        // 有就直接返回
        return gProcess;
    }
    //没有就创建一个ProcessState
    gProcess = new ProcessState;
    return gProcess;
}

很简短的单例代码,首次调用直接new。

下面看看ProcessState对象是怎么被构造的。

步骤5 ProcessState的创建

ProcessState::ProcessState()
     //打开“/dev/binder”Binder驱动文件,将设备文件描述符保存在mDriverFD中
    : mDriverFD(open_driver())
    , mVMStart(MAP_FAILED)
    , mManagesContexts(false)
    , mBinderContextCheckFunc(NULL)
    , mBinderContextUserData(NULL)
    , mThreadPoolStarted(false)
    , mThreadPoolSeq(1)
{
    ...
}

主要是初始化成员变量。其中mDriverFD(open_driver())是比较关键的一个环节,需要单独说一说。它通过调用open_driver()函数,打开了dev/binder驱动文件,并将文件描述符赋值给mDriverFD。那么,ProcessState作为持有Binder驱动文件描述符的对象,就拥有了和Binder驱动产生联系的资格。

下面简单看一下open_driver()函数。

步骤6 简要分析open_driver()函数

static int open_driver()
{
    //打开"/dev/binder"Binder驱动文件,并获得其描述符
    int fd = open("/dev/binder", O_RDWR);
    ...
    //获取Binder驱动程序的版本号
    status_t result = ioctl(fd, BINDER_VERSION, &vers);
    ...
    size_t maxThreads = 15;
    //告知驱动程序最多可以多少条线程处理事务
    result = ioctl(fd, BINDER_SET_MAX_THREADS, &maxThreads);
    ...
    return fd;
}

这个函数主要是负责打开/dev/binder文件,并配置一些和Binder驱动交互的参数,最后把获得的Binder驱动文件描述符fd返回。由于ProcessState在应用程序中是单例,所以保证了一个应用程序只打开一次/dev/binder

至于具体是怎么打开/dev/binder文件的,后面在详细说明。这里下跳过看下一步。

步骤7 通过getContextObject()获取的IBinder是什么?

ProcessState获取到后,就要调用它的getContextObject()函数来获取到一个IBinder对象了。

sp<IBinder> ProcessState::getContextObject(const sp<IBinder>& /*caller*/)
{ 
    //获取handle句柄为0的Binder
    return getStrongProxyForHandle(0);
}

这个函数看起来是直接用来获取handle为0的IBinder的。这个为handle为0的IBinder代表着谁呢?对,你可能没猜到!它代表了系统的ServiceManager。也就是通过这个handle为0的IBinder可以和ServiceManager交互。也就是说,这个IBinder是Client用来和系统的ServiceManager交互的。这里也先不提了。

步骤8 ProcessState管理着IBinder

sp<IBinder> ProcessState::getStrongProxyForHandle(int32_t handle)
{
    sp<IBinder> result;
    
    ...
    //尝试获取handle对应的handle_entry对象,没有的话会创建一个
    handle_entry* e = lookupHandleLocked(handle);
    
    if (e != NULL) {
        IBinder* b = e->binder;
        if (b == NULL || !e->refs->attemptIncWeak(this)) {
            // 上面的判断确保了同一个handle不会重复创建新的BpBinder
            ...
            //创建一个BpBinder
           //handle为0时创建的是ServiceManager对应的BpBinder
            b = new BpBinder(handle);
            e->binder = b;
            if (b) e->refs = b->getWeakRefs();
            result = b;  //待会儿返回b
        }
        ...
    }
    
    return result;
}

这段代码流程有点长啊,虽然CoorChice已经去掉了很大一部分了。

image
image

这里会调用lookupHandleLocked()函数来获取一个handle_entry类型的指针。我们还是先看看这个函数吧。

ProcessState::handle_entry* ProcessState::lookupHandleLocked(int32_t handle)
{
    //mHandleToObject是一个Vector,用于存放handle_entry结构体
    //该结构体会保存handle对应的IBinder指针
    const size_t N=mHandleToObject.size();
    if (N <= (size_t)handle) {
        //没有handle对应的handle_entry就新建一个插入mHandleToObject中
        //此时handle_entry还没有数据
        handle_entry e;
        e.binder = NULL;
        e.refs = NULL;
        status_t err = mHandleToObject.insertAt(e, N, handle+1-N);
        if (err < NO_ERROR) return NULL;
    }
     //取出mHandleToObject中handle对应的handle_entry
    return &mHandleToObject.editItemAt(handle);
   
}

很短的函数,并且注释已经足够清晰了吧?不多说了,回到getStrongProxyForHandle()函数中。

在根据传入的handle(我们分析这个流程中handle为0)获取到对应的handle_entry后,会检查其binder成员是否存在,不存在则创建,存在直接返回。

可以看到,返回的IBinder实际是一个BpBinder类型的。这个东西也后面再说,总之它与Client发送数据到Service有关。

到此,ServiceManagerNative.asInterface()函数就成功获取到了一个IBinder对象作为参数。下面看看它用这个参数干了啥?

步骤9、10 创建ServiceManagerProxy

拿到IBinder对象后,我们回到Java中,进入ServiceManagerNative.asInterface()方法。你可以注意看一下上图中的红色圈,看看这个IBinder

static public IServiceManager asInterface(IBinder obj)
{
    ...
    //创建一个ServiceManagerProxy
    return new ServiceManagerProxy(obj);
}

反正最后就是使用刚刚获取到的IBinder创建了一个ServiceManagerProxy代理,用来在应用程序内代表系统的ServiceManager,并通过它和系统的ServiceManager交互。

public ServiceManagerProxy(IBinder remote) {
        mRemote = remote;
}

可以看到,ServiceManagerProxy的构造函数十分简单。注意,ServiceManagerProxy是ServiceManagerNative的一个内部类。

实际上这个模式在CoorChice这篇文章《3分钟看懂Activity启动流程》:http://www.jianshu.com/p/9ecea420eb52中也是出现过的。

好了,既然拿到代理ServiceManagerProxy了,我们该看看getService()方法是如何获取到相应的Service的IBinder的。

步骤11 通过IPC获取对应Service的IBinder

public IBinder getService(String name) throws RemoteException {
    // 准备数据包
    Parcel data = Parcel.obtain(); //用于发送的数据包
    Parcel reply = Parcel.obtain(); //用于响应的数据包
    data.writeInterfaceToken(IServiceManager.descriptor);
    //将需要的Service的名字放到数据包中
    data.writeString(name);
    //通过远程的Binder发送data到Binder驱动,并将响应保存到reply中
    mRemote.transact(GET_SERVICE_TRANSACTION, data, reply, 0);
    //从响应结果中获取可用于和Service交互的Binder
    IBinder binder = reply.readStrongBinder();
    reply.recycle();
    data.recycle();
    return binder;
}

在这个方法中,创建了两个Parcel数据包。data是用来发送数据的,reply是用来接收数据的。

注意mRemote.transact(GET_SERVICE_TRANSACTION, data, reply, 0)这里调用了刚刚从底层返回的IBinder对象的transact()方法,意思是要发送数据了,并且把reply一起传过去准备接收数据。这个过程是阻塞式的。接着,当远程Service(这里指的是系统的ServiceManager)响应后,代码就可以接着走了,而这时reply中已经装了响应结果了。我们调用Parcel的readStrongBinder()方法来取出来自Service响应的IBinder对象。然后我们拿着这个IBinder对象就可以和对应的系统Service通过IPC机制交互了。

总结

  • 抽出空余时间写文章分享需要动力,还请各位看官动动小手点个赞,给我点鼓励😄
  • 我一直在不定期的创作新的干货,想要上车只需进到我的【个人主页】点个关注就好了哦。发车喽~

嗯,这篇文章从getSystemService()方法开始撸了系统Service的获取过程。当然这只是个开始,CoorChice留了很多坑,比如open("/dev/binder", O_RDWR)发生了什么,IBinder.transact()又发生了什么?还有IBinder是个啥?Parcel又是如何发挥作用的?等等一些列的谜团,后面的文章中CoorChice会一一拨开它们的迷雾。这只是个开始。

image
image

大家可以先对着图捋一捋。

功力有限,有错还请指出一起交流交流。

看到这里的童鞋快奖励自己一口辣条吧!

想要看CoorChice的更多文章,请点个关注哦!

评论