Android Binder线程

最新推荐文章于 2024-04-09 09:24:36 发布

weixin_34419321

最新推荐文章于 2024-04-09 09:24:36 发布

阅读量1.1k

点赞数

文章标签：移动开发 java c/c++

原文链接：https://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_t cmd) 《= IPCThreadState::getAndExecuteCommand() 《= IPCThreadState::joinThreadPool(bool isMain) 《= 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线程。

Done.

转载于:https://my.oschina.net/wolfcs/blog/209421