Android FrameWork——Binder机制详解(2)-白红宇

Android FrameWork——Binder机制详解(2)

阅读量：6034 次

发布时间：2019-06-20

本文共 7988 字，大约阅读时间需要 26 分钟。

6.前面5个段落我主要说明了BinderProxy是如何把数据发送出去的，Ok, 那么接下来，我们肯定想要知道服务端是怎么接收数据并传递给相应的BBinder进行处理的，有没有注意到前面waitForResponse我标注为蓝色的代码，这给我们一个启示，也许接收返回数据(进程作为客户端)和接收命令(进程作为服务端)处理的是同一个函数，但这是我的一个猜测，而实际上我参阅其它blog和代码后并非这么回事，waitForResponse只在客户端发送完数据等待接收数据才被调用的，那么服务端是怎么接收数据的呢？做过 socket编程的同仁们可能知道，服务端为实现接收数据和链接，一般会启动一个监听线程去监听客户端发过来的数据，同样android进程通信的服务端也是这么做的，在这里我先给你看一个Debug线程图：

这是一个简单的Android应用进程Debug图，有没有看到两个Binder Thread线程，每个应用都包含Binder Thread线程，不信你可以试试，它就是负责监听来自Binder驱动的消息的，那么这两个线程在什么时候被起来的呢，这又是我的一个疑问，我也不清楚不同Activity应用的Binder Thread是在哪里被起来的，我后面有待研究，不过System_process进程我倒是清楚它是如何启动这两个线程的，在 init1->system_init() @System_init.cpp函数最后：

if (proc->supportsProcesses()) {

LOGI("System server: entering thread pool.\n");

ProcessState::self()->startThreadPool();//启动Binder监听线程

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

LOGI("System server: exiting thread pool.\n");

}

IPCThreadState::self()函数前面我们已经讲过了，它是线程绑定对象，ProcessState::self函数我列出如下

sp<ProcessState> ProcessState::self()

{

if (gProcess != NULL) return gProcess;

AutoMutex _l(gProcessMutex);

if (gProcess == NULL) gProcess = new ProcessState;

return gProcess;

}

显然ProcessState是单例的，也即每个进程拥有一个ProcessState对象，而每个线程拥有一个IPCThreadState对象，关于 ProcessState,IPCThreadState,网上有一篇转高焕堂先生的blog,建议你此时插读一下，我不作详细说明：

認識Android的ProcessState類別和物件：

(图2：摘自高焕堂先生课件)

ProcessState负责打开Binder驱动，与Binder驱动进行通信，而IPCStateThread负责每个具体线程IPC数据读写

7.服务端监听线程的构建

服务端具体监听线程是怎样构建的的了，前面我只说了是通过ProcessState::self()->startThreadPool(); IPCThreadState::self()->joinThreadPool();这两个函数创建的，网上很多blog也只是简单说一下，具体是怎样一个过程呢？我这里进行一下说明：

void ProcessState::startThreadPool()

{

AutoMutex _l(mLock);

if (!mThreadPoolStarted) {

mThreadPoolStarted = true;

spawnPooledThread(true);

}

//isMain==true

void ProcessState::spawnPooledThread(bool isMain)

{

if (mThreadPoolStarted) {

int32_t s = android_atomic_add(1, &mThreadPoolSeq);

char buf[32];

sprintf(buf, "Binder Thread #%d", s);

LOGV("Spawning new pooled thread, name=%s\n", buf);

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

t->run(buf);

}

注意线程的创建是在run方法中，run方法并不像java中Thread.run是新线程的工作函数，它仍在当前线程中执行，PoolThread并没有覆盖父类Thread.run方法，因此它执行的是Thread.run方法：

status_t Thread::run(const char* name, int32_t priority, size_t stack)

{

。。。

//这个时候才真正创建一个新的线程，新线程的工作方法是_threadLoop，它仍是父类Thread的一个方法

res = createThreadEtc(_threadLoop,

this, name, priority, stack, &mThread);

。。。

}

//新线程工作方法

int Thread::_threadLoop(void* user)

{

。。。

do {

//调用虚函数threadLoop()，该函数被PoolThread实现

result = self->threadLoop();

}

。。。

} while(strong != 0);

return 0;

}

//PoolThread成员方法

virtual bool threadLoop()

{

IPCThreadState::self()->joinThreadPool(mIsMain);//真正线程工作函数

return false;

}

通过上面的代码我们看出，ProcessState::self()->startThreadPool();创建了一个新的线程，并且新线程的工作函数 IPCThreadState::self()->joinThreadPool(true);紧接着当前线程又调用了 IPCThreadState::self()->joinThreadPool(true);我这里是以system_process进程为例，那说明system_process至少有两个binder线程监听Binder驱动消息，接下来我们仔细看一下 joinThreadPool(true)函数的实现：

//服务端线程工作函数

void IPCThreadState::joinThreadPool(bool isMain)

{

mOut.writeInt32(isMain ? BC_ENTER_LOOPER : BC_REGISTER_LOOPER);//通知驱动开始消息监听？？

androidSetThreadSchedulingGroup(mMyThreadId, ANDROID_TGROUP_DEFAULT);//加入默认线程组？？

status_t result;

do {

int32_t cmd;

。。。

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

result = talkWithDriver();

if (result >= NO_ERROR) {

size_t IN = mIn.dataAvail();

if (IN < sizeof(int32_t)) continue;

cmd = mIn.readInt32();//读取命令

}

result = executeCommand(cmd);//执行命令

}

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

break;

}

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

mOut.writeInt32(BC_EXIT_LOOPER);//通知驱动结束消息监听

talkWithDriver(false);

}

通过while循环调用IPCThreadState.mIn读取cmd并执行，这我有一个疑惑就是多个线程去透过IPCThreadState.mIn读取驱动消息会不会存在问题？这个暂且mark一下，以后再分析

到此，我们总算了解服务端的消息监听机制，证明并不是如段落6我猜测的IPCThreadState.waitForResponse去接收消息的，而是 IPCThreadState::joinThreadPool中直接透过IPCThreadState.mIn读取消息的。

8.消息处理IPCThreadState::executeCommand(int32_t cmd)

走到这一步视乎离目标已经不远了，回到我们原来的问题，别让我们身陷代码堆栈而迷失了方向，我们前面做的这些工作，目的都是为了客户端的BpBinder 对象能够调到服务端的BBinder对象，而在BpBinder中有一个mHandle参数指定了服务端的Binder通信地址，因此消息才得以发送到服务端，现在我们有一个问题要解决就是，服务端可能存在多个BBinder对象，我们接收消息后，如何找到对应的BBinder对象把消息传给它处理了，我们先看消息处理函数

executeCommand：

status_t IPCThreadState::executeCommand(int32_t cmd)

{

BBinder* obj;//BBinder对象地址

RefBase::weakref_type* refs;

status_t result = NO_ERROR;

switch (cmd) {

case BR_ERROR:

...

//这是BC_TRANSACTION消息到服务端对应的cmd(客户端发送的是cmd==BC_TRANSACTION,服务端cmd变成BR_TRANSACTION？待研究)

case BR_TRANSACTION:

{

//构造接收消息结构体，与前面客户端writeTransactionData构造的传输数据包一致的结构体

binder_transaction_data tr;

result = mIn.read(&tr, sizeof(tr));//读取消息到结构体tr

LOG_ASSERT(result == NO_ERROR,

"Not enough command data for brTRANSACTION");

if (result != NO_ERROR) break;

Parcel buffer;

buffer.ipcSetDataReference(

reinterpret_cast<const uint8_t*>(tr.data.ptr.buffer),//tr.data.ptr.buffer是消息体，也就是传输参数Parcel

tr.data_size,

reinterpret_cast<const size_t*>(tr.data.ptr.offsets),

tr.offsets_size/sizeof(size_t), freeBuffer, this);

const pid_t origPid = mCallingPid;

const uid_t origUid = mCallingUid;

mCallingPid = tr.sender_pid;//客户端进程pid,uid(uid代表什么？？)

mCallingUid = tr.sender_euid;

。。。

Parcel reply;

if (tr.target.ptr) {//tr.target.ptr值在客户端writeTransactionData中并未设置，只是设置了tr.target.handle = handle;猜测在Binder驱动，根据handle找到了对应BBinder的地址并填写到这个字段了。

sp<BBinder> b((BBinder*)tr.cookie);

const status_t error = b->transact(tr.code, buffer, &reply, 0);//调用对应的BBinder对象的transact方法

if (error < NO_ERROR) reply.setError(error);

} else {//tr.target.ptr为空，没有指定BBinder对象，调用the_context_object->transact方法,the_context_object具体是什么对象？我不能够搜索到代码

const status_t error = the_context_object->transact(tr.code, buffer, &reply, 0);//猜测the_context_object应该是ApplicationThread对象，代表本应用进程上下文，不知道是否正确

if (error < NO_ERROR) reply.setError(error);

}

if ((tr.flags & TF_ONE_WAY) == 0) {//默认同步方式，需要发送返回数据

LOG_ONEWAY("Sending reply to %d!", mCallingPid);

sendReply(reply, 0);//发送返回数据

} else {

LOG_ONEWAY("NOT sending reply to %d!", mCallingPid);//ONEWAY方式客户端并不等待调用返回，因此不需要发送返回数据

}

mCallingPid = origPid;

mCallingUid = origUid;

IF_LOG_TRANSACTIONS() {

TextOutput::Bundle _b(alog);

alog << "BC_REPLY thr " << (void*)pthread_self() << " / obj "

<< tr.target.ptr << ": " << indent << reply << dedent << endl;

}

break;

case BR_DEAD_BINDER:

...

}

...

return result;

}

尽管还是存在很多疑问，但是大概脉络应该已经清楚了，收到数据包binder_transaction_data tr后根据tr.target.ptr得到BBinder对象指针，然后调用该对象的transact方法。

9.回到java层的Binder对象

在图一中，对c层的IBinder类继承结构已有一个清楚的说明，BBinder有两个子类，一个是JavaBBinder，一个是 BnInterface，若Binder存根对象用C实现的，那它会继承BnInterface，以MediaPlayerService为例，它的继承结构如下：MediaPlayerService-->BnMediaPlayerService-->BnInterface<IMediaPlayerService>-->BBinder-->IBinder

代码调用过程图如下：

(图3)

这个很简单，再看怎么调用到java层的Binder对象,前面在图1中已经描述了，java Binder对象对应到C空间的对象是JavaBBinder对象，所以，在BBinder::tansact方法中，调用到得是 JavaBBinder.onTransact方法，在深入JavaBBinder.onTransact前我们先了解一下JavaBBinder是一个什么对象，它怎么建立与java层Binder对象联系的，下面是JavaBBinder的构造函数：

//env:java虚拟机指针

//object:java层的Binder对象

JavaBBinder(JNIEnv* env, jobject object)

: mVM(jnienv_to_javavm(env)), mObject(env->NewGlobalRef(object))

{

LOGV("Creating JavaBBinder %p\n", this);

android_atomic_inc(&gNumLocalRefs);

incRefsCreated(env);

}

通过JavaBBinder的构造函数，我们可以推测，在构建java层Binder对象时也构造了对应的C层的一个JavaBBinder，JavaBBinder对象有两个成员，

JavaVM* const mVM;

jobject const mObject;