分析Binder线程池的启动流程

2,170

理论基础

Binder

Binder它是android中的一种进程间通信机制,它主要采用的是CS架构模式。 Binder框架中主要涉及到4个角色Client、Server、Service Manager及Binder驱动,其中Client、Server、Service Manager运行在用户空间,Binder驱动运行在内核空间。

线程池

线程池它是一种用于多线程处理形式,处理过程中将任务添加到队列,然后在创建线程后自动启动这些任务。线程池线程都是后台线程。每个线程都使用默认的堆栈大小,以默认的优先级运行,并处于多线程单元中。

简单的说:线程池就是创建一些线程,它们的集合称为线程池。

Binder线程池启动流程

我们知道一个新的app应用程序进程在创建完成之后,它会通过调用RunTimeInit类的静态成员函数zygoteInitNative来进行启动Binder线程池。

Binder线程池启动过程中,主要调用几个关键函数:ZygoteInitNative--->onZygoteInit--->startThreadPool。

下面的源码分析主要是以android5.0版本为例。

ZygoteInitNative源码分析

由于ZygoteInitNative函数是java实现的代码,实践上最终调用的是由C++实现的JNI方法。 以下代码来源于系统的/frameworks/base/core/jni/androidRuntime.cpp文件中

static void com_android_internal_os_RuntimeInit_nativeZygoteInit(JNIEnv* env, jobject clazz)
{
    //gCurRuntime是个全局的变量,后面跟上的是另外实现的方法。
    gCurRuntime->onZygoteInit();
}

onZygoteInit源码分析

onZygoteInit函数在需要源码的位置:/frameworks/base/cmds/app_process/app_main.cpp文件中。

image.png

该函数是个虚函数,并且是一个无返回值和无参数的函数
    virtual void onZygoteInit()
    {
        // Re-enable tracing now that we're no longer in Zygote.
        atrace_set_tracing_enabled(true);
        //获取进程的状态信息
        sp<ProcessState> proc = ProcessState::self();
        //打印日志信息
        ALOGV("App process: starting thread pool.\n");
        //启动线程池
        proc->startThreadPool();
    }

startThreadPool 源码分析

startThreadPool系统实现在\frameworks\native\libs\binder\ProcessState.cpp文件中。

每一个支持Binder进程间通信机制的进程内都有一个唯一的ProcessState对象,当这个ProcessState对象的成员函数StartThreadPool函数被第一次调用的时候,它就会在当前进程中启动一个线程池,并将mThreadPoolStarted这个成员变量设置为true。

//该函数是个无参数,无返回值的函数
void ProcessState::startThreadPool()
{
    AutoMutex _l(mLock);
    //判断线程池是否启动状态,启动的话就将标志信息设置为true属性。
    if (!mThreadPoolStarted) {
        mThreadPoolStarted = true;
        spawnPooledThread(true);
    }
}

总结

Binder在android底层中是一个非常重要的机制,我们在实际的项目调用过程中,我们在app应用程序中只要实现自己的Binder本地对象的时候,跟其他服务一样,只需要将它进行启动起来,并且进行注册到Server Mananger就可以了。至于内部的实现一般是不需要去关心的。