Android Binder线程

转：http://my.oschina.net/wolfcs/blog/209421

在android系统中，通过binder进行IPC时，服务端总是会起一些Binder线程来响应客户端的请求。如下面的这个设备上，system_process进程中就可以看到许多名为"Binder_X"的线程：

那这些Binder线程又是如何创建，如何管理的呢？而这些Binder线程本身又有些什么样的特点呢？在android的java app进程被创建起来时，它就会去建立一个线程池，来专门处理那些binder IPC事务。在frameworks/base/cmds/app_process/app_main.cpp中我们可以看到下面的这两个方法：

    virtual void onStarted()

    {

        sp<ProcessState> proc = ProcessState::self();

        ALOGV("App process: starting thread pool.\n");

        proc->startThreadPool();

        AndroidRuntime* ar = AndroidRuntime::getRuntime();

        ar->callMain(mClassName, mClass, mArgC, mArgV);

        IPCThreadState::self()->stopProcess();

    }

    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();

    }

app_main实际上就是android java app的java命令。这里的代码总是一个android java app执行控制的重要的枢纽。大体扫一眼这个部分的code，没错，就是上面的proc->startThreadPool()这个调用创建的Binder线程池。在android binder的设计中，ProcessState被设计来直接与binder驱动进行通信。ProcessState类被按照单例模式来设计，以确保这种类的对象可以保证在进程的全局是唯一的。它的构造函数是private，在代码中只能通过ProcessState::self()来访问ProcessState类的对象。我们顺便来看一下ProcessState::self()的实现(frameworks/native/libs/binder/ProcessState.cpp)：

sp<ProcessState> ProcessState::self()

{

    Mutex::Autolock _l(gProcessMutex);

    if (gProcess != NULL) {

        return gProcess;

    }

    gProcess = new ProcessState;

    return gProcess;

}

蛮典型的一个C++单例模式的一个实现呢。那在ProcessState::startThreadPool()中又是如何创建线程池的呢？(frameworks/native/libs/binder/ProcessState.cpp)

void ProcessState::startThreadPool()

{

    AutoMutex _l(mLock);

    if (!mThreadPoolStarted) {

        mThreadPoolStarted = true;

        spawnPooledThread(true);

    }

}

这里会通过一个标记mThreadPoolStarted来表明binder线程线程池是否已经被启动过。在每次调用这个函数时都会先去检查这个标记，从而确保即使这个函数被多次调用，线程池也只会被启动一次。具体来看启动线程池的过程：设置mThreadPoolStarted为true，然后调用spawnPooledThread(true)来创建线程池中的第一个线程，也就是线程池的main线程。

那binder线程具体又是什么呢？可以看spawnPooledThread()的实现(frameworks/native/libs/binder/ProcessState.cpp)：

String8 ProcessState::makeBinderThreadName() {

    int32_t s = android_atomic_add(1, &mThreadPoolSeq);

    String8 name;

    name.appendFormat("Binder_%X", s);

    return name;

}

void ProcessState::spawnPooledThread(bool isMain)

{

    if (mThreadPoolStarted) {

        String8 name = makeBinderThreadName();

        ALOGV("Spawning new pooled thread, name=%s\n", name.string());

        sp<Thread> t = new PoolThread(isMain);

        t->run(name.string());

    }

}

ProcessState::ProcessState()

    : mDriverFD(open_driver())

    , mVMStart(MAP_FAILED)

    , mManagesContexts(false)

    , mBinderContextCheckFunc(NULL)

    , mBinderContextUserData(NULL)

    , mThreadPoolStarted(false)

    , mThreadPoolSeq(1)

{

可以看到，所谓的binder线程，不过就是PoolThread而已。在进程全局且唯一的ProcessState对象中，有一个已经创建的binder线程的计数器mThreadPoolSeq，每创建一个新的线程，这个计数器就会加1。在ProcessState::makeBinderThreadName()函数中，会根据当前的binder线程计数器的值来构造新创建的binder线程的线程名"Binder_%X"，从而可以根据线程名来识别各个不同的binder线程。

那PoolThread具体又有些什么特点呢？这个还是得看PoolThread的threadLoop()方法实现(frameworks/native/libs/binder/ProcessState.cpp)：

class PoolThread : public Thread

{

public:

    PoolThread(bool isMain)

        : mIsMain(isMain)

    {

    }

    

protected:

    virtual bool threadLoop()

    {

        IPCThreadState::self()->joinThreadPool(mIsMain);

        return false;

    }

    

    const bool mIsMain;

};

这个倒是简单的很，就是调用IPCThreadState::self()->joinThreadPool(mIsMain)而已。

在android binder设计中，IPCThreadState是一个binder线程的一个抽象，用于管理binder线程的具体执行。这个类被设计为，其对象在每个binder线程中唯一。为了控制这个类的对象的创建，其构造函数也被声明为private，并且只能通过IPCThreadState::self()来创建或访问IPCThreadState类的对象(frameworks/native/libs/binder/IPCThreadState.cpp)：

static pthread_mutex_t gTLSMutex = PTHREAD_MUTEX_INITIALIZER;

static bool gHaveTLS = false;

static pthread_key_t gTLS = 0;

static bool gShutdown = false;

static bool gDisableBackgroundScheduling = false;

IPCThreadState* IPCThreadState::self()

{

    if (gHaveTLS) {

restart:

        const pthread_key_t k = gTLS;

        IPCThreadState* st = (IPCThreadState*)pthread_getspecific(k);

        if (st) return st;

        return new IPCThreadState;

    }

    

    if (gShutdown) return NULL;

    

    pthread_mutex_lock(&gTLSMutex);

    if (!gHaveTLS) {

        if (pthread_key_create(&gTLS, threadDestructor) != 0) {

            pthread_mutex_unlock(&gTLSMutex);

            return NULL;

        }

        gHaveTLS = true;

    }

    pthread_mutex_unlock(&gTLSMutex);

    goto restart;

}

IPCThreadState::self()函数在第一次被调到时，会先去创建一个线程局部存储的key，也就是gTLS。随后则会创建IPCThreadState对象，在IPCThreadState的构造函数中，会把this保存到线程局部存储gTLS标识的部分去(frameworks/native/libs/binder/IPCThreadState.cpp):

IPCThreadState::IPCThreadState()

    : mProcess(ProcessState::self()),

      mMyThreadId(androidGetTid()),

      mStrictModePolicy(0),

      mLastTransactionBinderFlags(0)

{

    pthread_setspecific(gTLS, this);

    clearCaller();

    mIn.setDataCapacity(256);

    mOut.setDataCapacity(256);

}

创建好了IPCThreadState对象之后就返回给调用者。因此，这个地方实际上是运用了线程局部存储机制来实现IPCThreadState对象的线程级单例的。

我们再回到IPCThreadState::joinThreadPool()，来接着看Binder线程，主执行流程所做的事情:

void IPCThreadState::joinThreadPool(bool isMain)

{

    LOG_THREADPOOL("**** THREAD %p (PID %d) IS JOINING THE THREAD POOL\n", (void*)pthread_self(), getpid());

    mOut.writeInt32(isMain ? BC_ENTER_LOOPER : BC_REGISTER_LOOPER);

    

    // This thread may have been spawned by a thread that was in the background

    // scheduling group, so first we will make sure it is in the foreground

    // one to avoid performing an initial transaction in the background.

    set_sched_policy(mMyThreadId, SP_FOREGROUND);

        

    status_t result;

    do {

        processPendingDerefs();

        // now get the next command to be processed, waiting if necessary

        result = getAndExecuteCommand();

        if (result < NO_ERROR && result != TIMED_OUT && result != -ECONNREFUSED && result != -EBADF) {

            ALOGE("getAndExecuteCommand(fd=%d) returned unexpected error %d, aborting",

                  mProcess->mDriverFD, result);

            abort();

        }

        

        // Let this thread exit the thread pool if it is no longer

        // needed and it is not the main process thread.

        if(result == TIMED_OUT && !isMain) {

            break;

        }

    } while (result != -ECONNREFUSED && result != -EBADF);

    LOG_THREADPOOL("**** THREAD %p (PID %d) IS LEAVING THE THREAD POOL err=%p\n",

        (void*)pthread_self(), getpid(), (void*)result);

    

    mOut.writeInt32(BC_EXIT_LOOPER);

    talkWithDriver(false);

}

在这个函数中，基本上就是执行一个getAndExecuteCommand()的循环。在getAndExecuteCommand()中则会不停的向binder driver拿命令执行，拿命令执行。

Binder线程池中首个线程的创建执行，大致如上所述，在android java app进程一旦被创建，也就紧跟着会被创建。那意思是说，任何一个android Java app都至少有一个Binder线程，而不管它是否有一个service组件并对其他app提供服务喽？是的，事实就是这个样子的。我们可以去查看任何一个android java app进程中的线程情况，都至少有一个以上的Binder线程，甚至是最简单的HelloWorld app也是这样的。

所谓的binder线程池，不能是只有这么一个线程吧。那Binder线程池中其它的线程又是如何创建的呢？其实是kernel发命令给某个已经在运行的binder线程来产生新的线程，如下：

    case BR_SPAWN_LOOPER:

        mProcess->spawnPooledThread(false);

        break;

大体的backtrace为：

IPCThreadState::executeCommand(int32_tcmd) 《= IPCThreadState::getAndExecuteCommand() 《= IPCThreadState::joinThreadPool(boolisMain) 《= PoolThread::threadLoop()。

binder线程真的就只有这两种创建的方式吗？所谓的binder线程，不过指的就是执行binder IPC事务处理循环的线程吧。而binder IPC事务处理循环不是被封装在了IPCThreadState::joinThreadPool()中了嘛。那是不是任何一个线程只要执行了IPCThreadState::self()->joinThreadPool()，就可以把自己变成一个binder线程了？确实是这样的。在android系统中，也确实有一些native的service，在设置好执行环境之后，甚至会让主线程去执行binder IPC事务处理循环从而把主线程变成binder线程。比如在mediaserver中(frameworks/av/media/mediaserver/main_mediaserver.cpp)，就会在main()函数的最后来执行IPCThreadState::self()->joinThreadPool():

118    } else {

119        // all other services

120        if (doLog) {

121            prctl(PR_SET_PDEATHSIG, SIGKILL);   // if parent media.log dies before me, kill me also

122            setpgid(0, 0);                      // but if I die first, don't kill my parent

123        }

124        sp<ProcessState> proc(ProcessState::self());

125        sp<IServiceManager> sm = defaultServiceManager();

126        ALOGI("ServiceManager: %p", sm.get());

127        AudioFlinger::instantiate();

128        MediaPlayerService::instantiate();

129        CameraService::instantiate();

130        AudioPolicyService::instantiate();

131        registerExtensions();

132        ProcessState::self()->startThreadPool();

133        IPCThreadState::self()->joinThreadPool();

134    }

binder线程还具有一个特点。那就是binder线程线程池中线程的数量是有一个上限的，我们可以看ProcessState.cpp中open_driver()函数的实现：

343static int open_driver()

344{

345    int fd = open("/dev/binder", O_RDWR);

346    if (fd >= 0) {

347        fcntl(fd, F_SETFD, FD_CLOEXEC);

348        int vers;

349        status_t result = ioctl(fd, BINDER_VERSION, &vers);

350        if (result == -1) {

351            ALOGE("Binder ioctl to obtain version failed: %s", strerror(errno));

352            close(fd);

353            fd = -1;

354        }

355        if (result != 0 || vers != BINDER_CURRENT_PROTOCOL_VERSION) {

356            ALOGE("Binder driver protocol does not match user space protocol!");

357            close(fd);

358            fd = -1;

359        }

360        size_t maxThreads = 15;

361        result = ioctl(fd, BINDER_SET_MAX_THREADS, &maxThreads);

362        if (result == -1) {

363            ALOGE("Binder ioctl to set max threads failed: %s", strerror(errno));

364        }

365    } else {

366        ALOGW("Opening '/dev/binder' failed: %s\n", strerror(errno));

367    }

368    return fd;

369}

在这个函数中，会通过ioctl命令，告诉binder驱动，只能创建最多15个的binder线程。