本文详细分析了Android Binder机制中getService()的过程，包括BpServiceManager::getService()的调用、client端的处理以及service接口的调用流程。此外，还探讨了TF_ONE_WAY异步调用的区别，如client直接返回、不同工作队列的处理，并介绍了DeathRecipient回调的工作原理。最后，总结了Binder在内核中的关键对象。
3.4 getService()分析
clinet中获取service接口的调用如下：
sp<ISampleService> sampleSrv;
if(getService(String16("SampleService"), &sampleSrv) != NO_ERROR){
ALOGE("get SampleService fail");
return 0;
}
template<typename INTERFACE>
status_t getService(const String16& name, sp<INTERFACE>* outService)
{
const sp<IServiceManager> sm = defaultServiceManager();
if (sm != NULL) {
*outService = interface_cast<INTERFACE>(sm->getService(name));
if ((*outService) != NULL) return NO_ERROR;
}
return NAME_NOT_FOUND;
}1，sm->getService(name)获取到一个sp<IBinder>对象。
2，从获取的BpBinder指针中构造出BpSampleService对象。
第二步是很清楚的，就是调用了BpSampleService::interface_cast<ISampleService>(sp<IBinder>)。我们主要需要研究一下第一步的细节。
3.4.1 BpServiceManager::getService()
BpServiceManager::getService()是调用了checkService()函数
virtual sp<IBinder> getService(const String16& name) const
{
unsigned n;
for (n = 0; n < 5; n++){
sp<IBinder> svc = checkService(name);
if (svc != NULL) return svc;
ALOGI("Waiting for service %s...\n", String8(name).string());
sleep(1);
}
return NULL;
}virtual sp<IBinder> checkService( const String16& name) const
{
Parcel data, reply;
data.writeInterfaceToken(IServiceManager::getInterfaceDescriptor());
data.writeString16(name);
remote()->transact(CHECK_SERVICE_TRANSACTION, data, &reply);
return reply.readStrongBinder();
}这边的transact因为没有写入object，流程和PING_TRANSACTION的基本一样了。我们直接到ServiceManager端看看具体的处理。
3.4.2 ServiceManager处理CHECK_SERVICE_TRANSACTION
command和ADD_SERVICE一样在svcmgr_handler()中处理
case SVC_MGR_GET_SERVICE:
case SVC_MGR_CHECK_SERVICE:
//获取service name。
s = bio_get_string16(msg, &len);
//查找对应的service。
ptr = do_find_service(bs, s, len, txn->sender_euid);
if (!ptr)
break;
bio_put_ref(reply, ptr);
return 0;void *do_find_service(struct binder_state *bs, uint16_t *s, unsigned len, unsigned uid)
{
//根据service name找到对应的svcinfo结点。
struct svcinfo *si;
si = find_svc(s, len);
// ALOGI("check_service('%s') ptr = %p\n", str8(s), si ? si->ptr : 0);
if (si && si->ptr) {
if (!si->allow_isolated) {
// If this service doesn't allow access from isolated processes,
// then check the uid to see if it is isolated.
unsigned appid = uid % AID_USER;
if (appid >= AID_ISOLATED_START && appid <= AID_ISOLATED_END) {
return 0;
}
}
//返回结点中的ptr，这个ptr是binder中对应的binder_ref.desc。
return si->ptr;
} else {
return 0;
}
}void bio_put_ref(struct binder_io *bio, void *ptr)
{
//构造了一个binder_object，也就是一个flat_binder_object。
struct binder_object *obj;
if (ptr)
obj = bio_alloc_obj(bio);
else
obj = bio_alloc(bio, sizeof(*obj));
if (!obj)
return;
obj->flags = 0x7f | FLAT_BINDER_FLAG_ACCEPTS_FDS;
obj->type = BINDER_TYPE_HANDLE;
obj->pointer = ptr;
obj->cookie = 0;
}带着这些信息，我们进入到binder中，首先在binder_thread_write()中处理BC_FREE_BUFFER，这边的处理和之前的PING_TRANSACTION基本一致，没有object，释放掉binder_buffer就可以了。
然后处理BC_REPLY，主要在binder_transaction()函数中，这里和addService处理差异在于reply信息是一个object，而不是一个数据，我们看下组织binder_transaction的部分：
//remote binder object, means BpBinder。
case BINDER_TYPE_HANDLE:
case BINDER_TYPE_WEAK_HANDLE: {
struct binder_ref *ref = binder_get_ref(proc, fp->handle);
if (ref == NULL) {
binder_user_error("%d:%d got transaction with invalid handle, %ld\n",
proc->pid,
thread->pid, fp->handle);
return_error = BR_FAILED_REPLY;
goto err_binder_get_ref_failed;
}
if (security_binder_transfer_binder(proc->tsk, target_proc->tsk)) {
return_error = BR_FAILED_REPLY;
goto err_binder_get_ref_failed;
}
//如果传给service所在的进程，转换为BINDER_TYPE_BINDER类型的object。
if (ref->node->proc == target_proc) {
if (fp->type == BINDER_TYPE_HANDLE)
fp->type = BINDER_TYPE_BINDER;
else
fp->type = BINDER_TYPE_WEAK_BINDER;
fp->binder = ref->node->ptr;
fp->cookie = ref->node->cookie;
binder_inc_node(ref->node, fp->type == BINDER_TYPE_BINDER, 0, NULL);
trace_binder_transaction_ref_to_node(t, ref);
binder_debug(BINDER_DEBUG_TRANSACTION,
" ref %d desc %d -> node %d u%p\n",
ref->debug_id, ref->desc, ref->node->debug_id,
ref->node->ptr);
} else {//传入到其他client进程，为目标进程建立新的binder_ref，并传回这个新的binder_ref的信息。
struct binder_ref *new_ref;
new_ref = binder_get_ref_for_node(target_proc, ref->node);//第一次会建立一个新的binder_ref。
if (new_ref == NULL) {
return_error = BR_FAILED_REPLY;
goto err_binder_get_ref_for_node_failed;
}
fp->handle = new_ref->desc;//用目标进程desc替换。
binder_inc_ref(new_ref, fp->type == BINDER_TYPE_HANDLE, NULL);
trace_binder_transaction_ref_to_ref(t, ref,
new_ref);
binder_debug(BINDER_DEBUG_TRANSACTION,
" ref %d desc %d -> ref %d desc %d (node %d)\n",
ref->debug_id, ref->desc, new_ref->debug_id,
new_ref->desc, ref->node->debug_id);
}
} break;3.4.3 client端处理返回信息
client在IPCThreadState::waitForResponse()处理BR_REPLY，数据传递给Parcel reply中，最终调用得到了sp<IBinder>对象。
reply.readStrongBinder();sp<IBinder> Parcel::readStrongBinder() const
{
sp<IBinder> val;
unflatten_binder(ProcessState::self(), *this, &val);
return val;
}status_t unflatten_binder(const sp<ProcessState>& proc,
const Parcel& in, sp<IBinder>* out)
{
const flat_binder_object* flat = in.readObject(false);
if (flat) {
switch (flat->type) {
case BINDER_TYPE_BINDER:
*out = static_cast<IBinder*>(flat->cookie);
return finish_unflatten_binder(NULL, *flat, in);
case BINDER_TYPE_HANDLE:
//查找对应的BpBinder对象。
*out = proc->getStrongProxyForHandle(flat->handle);
return finish_unflatten_binder(
static_cast<BpBinder*>(out->get()), *flat, in);
}
}
return BAD_TYPE;
}getStrongproxyForHandle()中创建BpBinder的动作，我们就不在看了，我们看一下如果不是首次调用的情况下的处理：
} else {
// This little bit of nastyness is to allow us to add a primary
// reference to the remote proxy when this team doesn't have one
// but another team is sending the handle to us.
//force_set()函数和直接赋值的差异在于它会强制调用RefBase.onFirstRef()，对这里来说
//也就是会出发BpBinder.onFirstRef()。
result.force_set(b);
e->refs->decWeak(this);
}但是这里有个问题：
force_set对于binder_ref又增加了一次reference，但是因为他们用的都是同意BpBinder，最终只会调用一次onLastStrongRef()去decrease strong reference，这样会导致ref的增减不同步，可能是会有问题的。（加了debug信息确认，的确是会出现这样的问题的。）
至此，getService()部分分析完毕，我们看到了service的传递主要是依赖binder对于binder_ref的管理，binder_ref.desc决定了在user层的handle，user层又使用handle去建立了一个BpBinder，所有的service访问结构都是使用这个BpBinder构造出BpXXX对象来操作service接口。
3.5 sayHello()调用分析
这部分我们分析下client端调用SampleService的sayHello()接口的流程，看看client端是如何把信息投递到service进程中去的。
3.5.1 sayHello() client调用
virtual int sayHello(const String8& clientName){
Parcel data,reply;
data.writeInterfaceToken(ISampleService::getInterfaceDescriptor());
data.writeString8(clientName);
remote()->transact(BnSampleService::SAY_HELLO, data, &reply);
int ret = reply.readInt32();
ALOGD("sayHello return %d",ret);
return ret;
} if (tr->target.handle) {//handle不为0的情况，这个是一般service的处理。
struct binder_ref *ref;
ref = binder_get_ref(proc, tr->target.handle);
if (ref == NULL) {
binder_user_error("%d:%d got transaction to invalid handle\n",
proc->pid, thread->pid);
return_error = BR_FAILED_REPLY;
goto err_invalid_target_handle;
}
target_node = ref->node;
} else {//handle为0，即ServiceManager的case，直接获取binder_context_mgr_node。
target_node = binder_context_mgr_node;
if (target_node == NULL) {
return_error = BR_DEAD_REPLY;
goto err_no_context_mgr_node;
}
}对于一般service，handle是当前进程中的binder_ref的desc，根据handle我们可以找到对应的binder_ref，而binder_ref.node保存了它所对应的binder_node。
得到了target node之后，可以找到对应的target proc，这样我们就可以把work加入到到对应的进程的todo list中去了。
3.5.2 sayHello() Service端调用
Service端是在IPCThreadState::joinThreadPool()中响应处理的，通过talkWithDriver()和binder打交道，在binder_thread_read()中获取到client传来的信息，流程没有什么特别的，我们注意一下传回来的数据的组织：
if (t->buffer->target_node) {//transaction cmd时候。
//对于binder_context_mgr_node，ptr和cookie都为0。
//对于一般service来说，binder_node中的ptr是service的weakrefs指针,cookie是service的对象指针。（见Parcel中的flatten_binder()）
struct binder_node *target_node = t->buffer->target_node;
tr.target.ptr = target_node->ptr;
tr.cookie = target_node->cookie;
t->saved_priority = task_nice(current);
if (t->priority < target_node->min_priority &&
!(t->flags & TF_ONE_WAY))
binder_set_nice(t->priority);
else if (!(t->flags & TF_ONE_WAY) ||
t->saved_priority > target_node->min_priority)
binder_set_nice(target_node->min_priority);
cmd = BR_TRANSACTION;
} else {//reply cmd时候，reply时候target_node为null。
tr.target.ptr = NULL;
tr.cookie = NULL;
cmd = BR_REPLY;
}回到在executeCommand()中处理command：
case BR_TRANSACTION:
{
binder_transaction_data tr;
result = mIn.read(&tr, sizeof(tr));
ALOG_ASSERT(result == NO_ERROR,
"Not enough command data for brTRANSACTION");
if (result != NO_ERROR) break;
Parcel buffer;
//将data保存到Parcel中。
buffer.ipcSetDataReference(
reinterpret_cast<const uint8_t*>(tr.data.ptr.buffer),
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;
mCallingUid = tr.sender_euid;
//调整Priority。
int curPrio = getpriority(PRIO_PROCESS, mMyThreadId);
if (gDisableBackgroundScheduling) {
if (curPrio > ANDROID_PRIORITY_NORMAL) {
// We have inherited a reduced priority from the caller, but do not
// want to run in that state in this process. The driver set our
// priority already (though not our scheduling class), so bounce
// it back to the default before invoking the transaction.
setpriority(PRIO_PROCESS, mMyThreadId, ANDROID_PRIORITY_NORMAL);
}
} else {
if (curPrio >= ANDROID_PRIORITY_BACKGROUND) {
// We want to use the inherited priority from the caller.
// Ensure this thread is in the background scheduling class,
// since the driver won't modify scheduling classes for us.
// The scheduling group is reset to default by the caller
// once this method returns after the transaction is complete.
set_sched_policy(mMyThreadId, SP_BACKGROUND);
}
}
//ALOGI(">>>> TRANSACT from pid %d uid %d\n", mCallingPid, mCallingUid);
Parcel reply;
IF_LOG_TRANSACTIONS() {
TextOutput::Bundle _b(alog);
alog << "BR_TRANSACTION thr " << (void*)pthread_self()
<< " / obj " << tr.target.ptr << " / code "
<< TypeCode(tr.code) << ": " << indent << buffer
<< dedent << endl
<< "Data addr = "
<< reinterpret_cast<const uint8_t*>(tr.data.ptr.buffer)
<< ", offsets addr="
<< reinterpret_cast<const size_t*>(tr.data.ptr.offsets) << endl;
}
if (tr.target.ptr) {//ptr存在的情况下，
sp<BBinder> b((BBinder*)tr.cookie);//cookie是指向service对象指针，是继承BBinder的，转换为BBinder调用。
const status_t error = b->transact(tr.code, buffer, &reply, tr.flags);
if (error < NO_ERROR) reply.setError(error);
} else {//thre_context_object没有看到被set的地方，目前没有使用到。
const status_t error = the_context_object->transact(tr.code, buffer, &reply, tr.flags);
if (error < NO_ERROR) reply.setError(error);
}
//ALOGI("<<<< TRANSACT from pid %d restore pid %d uid %d\n",
// mCallingPid, origPid, origUid);
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);//不需要返回值的情况。
}
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;status_t BBinder::transact(
uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags)
{
data.setDataPosition(0);
status_t err = NO_ERROR;
switch (code) {
case PING_TRANSACTION:
reply->writeInt32(pingBinder());
break;
default:
err = onTransact(code, data, reply, flags);
break;
}
if (reply != NULL) {
reply->setDataPosition(0);
}
return err;
}调用后，回到executeCommand()中看看sendReply()里面怎么返回的：
status_t IPCThreadState::sendReply(const Parcel& reply, uint32_t flags)
{
status_t err;
status_t statusBuffer;
err = writeTransactionData(BC_REPLY, flags, -1, 0, reply, &statusBuffer);
if (err < NO_ERROR) return err;
return waitForResponse(NULL, NULL);
}注意binder返回的数据，在executeComand()中被付给了Parcel buffer这个局部对象，在buffer析构的时候，回去free掉内存，不需要我们再去释放了。
3.5.3 sayHello() client端处理reply
reply的处理这里就不说了，和前面所讲到的处理是i一样的，没有任何差别。
3.6 TF_ONE_WAY调用的差别
在前面的分析中，我们已经碰到了很多次TF_ONE_WAY这个flag，在binder中也看不到有些和正常调用不一样的处理，这边我们来写一个TF_ONE_WAY调用的接口来分下TF_ONE_WAY调用的流程上的差异。
首先在SampleService里面加了一个新的接口：
int SampleService::sayHelloAsync(const String8& clientName){
ALOGD("Async Hello to %s",clientName.string());
return 0;
}virtual int sayHelloAsync(const String8& clientName){
Parcel data,reply;
data.writeInterfaceToken(ISampleService::getInterfaceDescriptor());
data.writeString8(clientName);
remote()->transact(BnSampleService::SAY_HELLO, data, &reply,TF_ONE_WAY);
int ret = reply.readInt32();
if(NOT_ENOUGH_DATA == ret)
ALOGD("for async mode ,there is no reply ~~");
else
ALOGD("sayHelloAsync return %d",ret);
return 0;
}3.6.1 client调用过程
在IPCThreadState::transact()中的流程有差异，调用waitForResponse()的reply为NULL：
err = waitForResponse(NULL, NULL);binder_transaction()中差异：
if (!reply && !(tr->flags & TF_ONE_WAY))
t->from = thread;//同步transaction的时候，记录from。
else
t->from = NULL;//异步transaction或者reply时候，不需要记录from了。
t->buffer = binder_alloc_buf(target_proc, tr->data_size,
tr->offsets_size, !reply && (t->flags & TF_ONE_WAY));if (is_async &&
proc->free_async_space < size + sizeof(struct binder_buffer)) {
binder_debug(BINDER_DEBUG_BUFFER_ALLOC,
"%d: binder_alloc_buf size %zd failed, no async space left\n",
proc->pid, size);
return NULL;
} buffer->async_transaction = is_async;
if (is_async) {
//update free_async_space
proc->free_async_space -= size + sizeof(struct binder_buffer);
binder_debug(BINDER_DEBUG_BUFFER_ALLOC_ASYNC,
"%d: binder_alloc_buf size %zd async free %zd\n",
proc->pid, size, proc->free_async_space);
}从这里我们可以看出来free_async_space是对于async调用的一个限制，使用的空间不能超过mmap size的一半。
if (reply) {
BUG_ON(t->buffer->async_transaction != 0);
//清除掉binder_tranasaction发起thread的transaction_stack。
binder_pop_transaction(target_thread, in_reply_to);
} else if (!(t->flags & TF_ONE_WAY)) {//同步transaction
BUG_ON(t->buffer->async_transaction != 0);
t->need_reply = 1;
//transaction_stack指向当前thread的最后一个binder_transaction，通过from_parent进行链接。
t->from_parent = thread->transaction_stack;
thread->transaction_stack = t;
} else {//异步transaction
BUG_ON(target_node == NULL);
BUG_ON(t->buffer->async_transaction != 1);
if (target_node->has_async_transaction) {
target_list = &target_node->async_todo;
target_wait = NULL;
} else
target_node->has_async_transaction = 1;
}
之后进入binder_thread_read()，client端在这里是read了BR_TRANSACTION_COMPLETE command后，返回user层，在IPCThreadState::waitForResponse()中进行BR_TRANSACTION_COMPLETE的处理：
case BR_TRANSACTION_COMPLETE:
if (!reply && !acquireResult) goto finish;
break;到这里，client调用已经完全结束了，我们可以清楚看到了异步调用下，我们只是发出command后就退出了，并不会等待service返回BR_REPLY的信息。
3.6.2 service的响应
SampleService还是从binder_thread_read()中读取command：
if (t->buffer->target_node) {//transaction cmd时候。
//对于binder_context_mgr_node，ptr和cookie都为0。
//对于一般service来说，binder_node中的ptr是service的weakrefs指针,cookie是service的对象指针。（见Parcel中的flatten_binder()）
struct binder_node *target_node = t->buffer->target_node;
tr.target.ptr = target_node->ptr;
tr.cookie = target_node->cookie;
t->saved_priority = task_nice(current);
//同步模式下设置priority
if (t->priority < target_node->min_priority &&
!(t->flags & TF_ONE_WAY))
binder_set_nice(t->priority);
else if (!(t->flags & TF_ONE_WAY) ||
t->saved_priority > target_node->min_priority)
binder_set_nice(target_node->min_priority);
cmd = BR_TRANSACTION;
} else {//reply cmd时候，reply时候target_node为null。
tr.target.ptr = NULL;
tr.cookie = NULL;
cmd = BR_REPLY;
}
//记录sender_pid。
//异步模式，或者reply情况下，t->from == 0.
if (t->from) {
struct task_struct *sender = t->from->proc->tsk;
tr.sender_pid = task_tgid_nr_ns(sender,
task_active_pid_ns(current));
} else {
tr.sender_pid = 0;
}
if (cmd == BR_TRANSACTION && !(t->flags & TF_ONE_WAY)) {
//同步模式下更新stack信息，binder_transaction t会在reply时候在binder_transaction()中pop掉。
t->to_parent = thread->transaction_stack;
t->to_thread = thread;
thread->transaction_stack = t;//把最近读到的binder_transaction设置为transaction_stack
} else {//异步模式，或者reply时，binder_transaction已经不需要了
//（reply时候才需要通过binder_transaction找到reply的target thread），在这里直接释放掉。
t->buffer->transaction = NULL;
kfree(t);
binder_stats_deleted(BINDER_STAT_TRANSACTION);
}从binder_thread_read()中返回后，回到user层处理读取到的BR_TRANSACTION：
//client的pid和uid。在异步模式下的时候为0。
mCallingPid = tr.sender_pid;
mCallingUid = tr.sender_euid;另外差异就在于reply的发送，同步模式会发送BC_REPLY给binder，但是对于异步模式来说我们什么都不需要做了。
除去reply之外，我们还要看下freebuffer的处理，Parcel data析构会去调用IPCThreadState::freeBuffer()去发送BC_FREE_BUFFER给binder，我们到binder_thread_write()中看看：
//异步操作的时候，work会被加入到async_todo的list中，在free时候，把下一个work挪到thread的todo中去。
if (buffer->async_transaction && buffer->target_node) {
BUG_ON(!buffer->target_node->has_async_transaction);
if (list_empty(&buffer->target_node->async_todo))
buffer->target_node->has_async_transaction = 0;
else
list_move_tail(buffer->target_node->async_todo.next, &thread->todo);
} if (target_node->has_async_transaction) {
target_list = &target_node->async_todo;
target_wait = NULL;
} else
target_node->has_async_transaction = 1;这样的操作逻辑，让异步操作是在一个thread中去完成，因为异步操作的client不会等待，不需要尽快的返回，可以空出更多的thread给同步操作使用。
接着我们看看释放binder_buffer的函数binder_free_buf()：
if (buffer->async_transaction) {
proc->free_async_space += size + sizeof(struct binder_buffer);
binder_debug(BINDER_DEBUG_BUFFER_ALLOC_ASYNC,
"%d: binder_free_buf size %zd async free %zd\n",
proc->pid, size, proc->free_async_space);
}free_async_space的最大值是mmap size的一半，也就是说binder要求至少保留一半的内存给同步操作去使用。
3.6.3 小结
异步操作的流程我们已经看完了，差异主要是：
1，client发出异步操作后，直接返回，不等待service reply。
2，client发给service的work，在service在处理其他异步操作时候，会被加入到binder_node.async_todo中去，而不是thread/proc的todo中。
4，client发给service的binder_transaction结构，在service read的时候，会直接释放。
5，client传给service的sender_pid为0。
6，service不会发送BC_REPLY给binder。
7，处理BC_FREE_BUFFER时会检测async_todo是否还有work，如果有，会挪到thread.todo中去执行。
3.7 DeathRecipient调用的分析
在第二章编写SampleService的时候，我们在client调用中调用了linkToDeath()去注册service的died的notification，但是实际跑起来之后，这个callback没有被调用到。
我们这里分析下代码，这个回调是怎么工作的，为什么我们的注册没有工作起来。
client中注册的动作如下：
DeathCallBack* deathCb = new DeathCallBack();
sampleSrv->asBinder()->linkToDeath(deathCb);status_t BpBinder::linkToDeath(
const sp<DeathRecipient>& recipient, void* cookie, uint32_t flags)
{
Obituary ob;
ob.recipient = recipient;
ob.cookie = cookie;
ob.flags = flags;
LOG_ALWAYS_FATAL_IF(recipient == NULL,
"linkToDeath(): recipient must be non-NULL");
{
AutoMutex _l(mLock);
if (!mObitsSent) {//判断BpBinder是否已经die。
if (!mObituaries) {//构造一个vector来保存注册的DeathRecipient,并发送BC_REQUEST_DEATH_NOTIFICATION给binder。
mObituaries = new Vector<Obituary>;
if (!mObituaries) {
return NO_MEMORY;
}
ALOGV("Requesting death notification: %p handle %d\n", this, mHandle);
getWeakRefs()->incWeak(this);
IPCThreadState* self = IPCThreadState::self();
self->requestDeathNotification(mHandle, this);
self->flushCommands();
}
ssize_t res = mObituaries->add(ob);//把注册的DeathRecipient加入到mObituaries。
return res >= (ssize_t)NO_ERROR ? (status_t)NO_ERROR : res;
}
}
return DEAD_OBJECT;
}mObituaries创建时候，通过函数requestDeathNotificaiton()，写了一个command BC_REQUEST_DEATH_NOTIFICATION,
status_t IPCThreadState::requestDeathNotification(int32_t handle, BpBinder* proxy)
{
mOut.writeInt32(BC_REQUEST_DEATH_NOTIFICATION);
mOut.writeInt32((int32_t)handle);
mOut.writeInt32((int32_t)proxy);
return NO_ERROR;
}void IPCThreadState::flushCommands()
{
if (mProcess->mDriverFD <= 0)
return;
talkWithDriver(false);//false表明不会读取command,只是去写command。
}之后在binder中处理BC_REQUEST_DEATH_NOTIFICATION，之前我们在分析addService()的时候，已经看到了这个command的处理，主要行为就是为当前的binder_ref创建了了一个binder_ref_death对象。
但是我们的问题还没有解决，当service挂掉的时候，是如何被通知到的呢？考service异常退出的时候是不会来得及去和binder做交互的，那么一定是系统帮忙做了什么。
再想到当进程异常退出的时候，系统会帮助我们做file的flush,release的动作来回收资源，binder对于系统来说一样也是个file，所以也会做一样的处理，所以我们关注一下binder_flush()和binder_release()：
static int binder_flush(struct file *filp, fl_owner_t id)
{
struct binder_proc *proc = filp->private_data;
if(proc->bLogDbg)
printk("Process %d called flush \n",proc->pid);
binder_defer_work(proc, BINDER_DEFERRED_FLUSH);
return 0;
}static void
binder_defer_work(struct binder_proc *proc, enum binder_deferred_state defer)
{
mutex_lock(&binder_deferred_lock);
proc->deferred_work |= defer;//记录defer work的flag。
if (hlist_unhashed(&proc->deferred_work_node)) {
hlist_add_head(&proc->deferred_work_node,
&binder_deferred_list);
//将binder_deferred_work放到binder_deferred_workqueue中去。
queue_work(binder_deferred_workqueue, &binder_deferred_work);
}
mutex_unlock(&binder_deferred_lock);
}binder_deferred_workqueue是binder在binder_init()中建立的一个workqueue，任务放到bufferqueue中会被逐个执行。
binder_deferred_work是下面的代码声明
static DECLARE_WORK(binder_deferred_work, binder_deferred_func);static void binder_deferred_func(struct work_struct *work)
{
struct binder_proc *proc;
struct files_struct *files;
int defer;
do {
binder_lock(__func__);
mutex_lock(&binder_deferred_lock);
if (!hlist_empty(&binder_deferred_list)) {
proc = hlist_entry(binder_deferred_list.first,
struct binder_proc, deferred_work_node);
hlist_del_init(&proc->deferred_work_node);
defer = proc->deferred_work;
proc->deferred_work = 0;//获取defer的值
} else {
proc = NULL;
defer = 0;
}
mutex_unlock(&binder_deferred_lock);
files = NULL;
if (defer & BINDER_DEFERRED_PUT_FILES) {
files = proc->files;
if (files)
proc->files = NULL;
}
//处理binder_flush()传来的state BINDER_DEFERRED_FLUSH
if (defer & BINDER_DEFERRED_FLUSH)
binder_deferred_flush(proc);
//处理binder_release()传来的state BINDER_DEFERRED_RELEASE
if (defer & BINDER_DEFERRED_RELEASE)
binder_deferred_release(proc); /* frees proc */
binder_unlock(__func__);
if (files)
put_files_struct(files);
} while (proc);
}static void binder_deferred_flush(struct binder_proc *proc)
{
struct rb_node *n;
int wake_count = 0;
//让进程所有等待的thread都立刻返回出去。
for (n = rb_first(&proc->threads); n != NULL; n = rb_next(n)) {
struct binder_thread *thread = rb_entry(n, struct binder_thread, rb_node);
thread->looper |= BINDER_LOOPER_STATE_NEED_RETURN;
if (thread->looper & BINDER_LOOPER_STATE_WAITING) {
wake_up_interruptible(&thread->wait);
wake_count++;
}
}
wake_up_interruptible_all(&proc->wait);
binder_debug(BINDER_DEBUG_OPEN_CLOSE,
"binder_flush: %d woke %d threads\n", proc->pid,
wake_count);
}
继续看下binder_release()，
static int binder_release(struct inode *nodp, struct file *filp)
{
struct binder_proc *proc = filp->private_data;
debugfs_remove(proc->debugfs_entry);
binder_defer_work(proc, BINDER_DEFERRED_RELEASE);
return 0;
} //处理binder_release()传来的state BINDER_DEFERRED_RELEASE
if (defer & BINDER_DEFERRED_RELEASE)
binder_deferred_release(proc); /* frees proc */static void binder_deferred_release(struct binder_proc *proc)
{
//对当前进程相关的资源做处理。
struct binder_transaction *t;
struct rb_node *n;
int threads, nodes, incoming_refs, outgoing_refs, buffers,
active_transactions, page_count;
BUG_ON(proc->vma);
BUG_ON(proc->files);
hlist_del(&proc->proc_node);
if (binder_context_mgr_node && binder_context_mgr_node->proc == proc) {
binder_debug(BINDER_DEBUG_DEAD_BINDER,
"%s: %d context_mgr_node gone\n",
__func__, proc->pid);
binder_context_mgr_node = NULL;
}
threads = 0;
active_transactions = 0;
//清除所有的binder_thread对象。
while ((n = rb_first(&proc->threads))) {
struct binder_thread *thread;
thread = rb_entry(n, struct binder_thread, rb_node);
threads++;
active_transactions += binder_free_thread(proc, thread);
}
nodes = 0;
incoming_refs = 0;
//release所有的binder_node对象的资源，当进程中有多个serivce的时候，会有多个binder_node。
//注意这里只是对binder_node做release动作，并不是delete掉binder_node的对象，这个对象因为client还在引用，所以暂时不会被删除。
while ((n = rb_first(&proc->nodes))) {
struct binder_node *node;
node = rb_entry(n, struct binder_node, rb_node);
nodes++;
rb_erase(&node->rb_node, &proc->nodes);
incoming_refs = binder_node_release(node, incoming_refs);
}
outgoing_refs = 0;
//清除当前进程的reference。
while ((n = rb_first(&proc->refs_by_desc))) {
struct binder_ref *ref;
ref = rb_entry(n, struct binder_ref, rb_node_desc);
outgoing_refs++;
binder_delete_ref(ref);
}
//清除两个list。
binder_release_work(&proc->todo);
binder_release_work(&proc->delivered_death);
buffers = 0;
//释放掉已经申请的binder_buffer。
while ((n = rb_first(&proc->allocated_buffers))) {
struct binder_buffer *buffer;
buffer = rb_entry(n, struct binder_buffer, rb_node);
t = buffer->transaction;
if (t) {
t->buffer = NULL;
buffer->transaction = NULL;
pr_err("release proc %d, transaction %d, not freed\n",
proc->pid, t->debug_id);
/*BUG();*/
}
binder_free_buf(proc, buffer);
buffers++;
}
binder_stats_deleted(BINDER_STAT_PROC);
//释放mmap的物理page。
page_count = 0;
if (proc->pages) {
int i;
for (i = 0; i < proc->buffer_size / PAGE_SIZE; i++) {
void *page_addr;
if (!proc->pages[i])
continue;
page_addr = proc->buffer + i * PAGE_SIZE;
binder_debug(BINDER_DEBUG_BUFFER_ALLOC,
"%s: %d: page %d at %p not freed\n",
__func__, proc->pid, i, page_addr);
unmap_kernel_range((unsigned long)page_addr, PAGE_SIZE);
__free_page(proc->pages[i]);
page_count++;
}
kfree(proc->pages);
vfree(proc->buffer);
}
put_task_struct(proc->tsk);
binder_debug(BINDER_DEBUG_OPEN_CLOSE,
"%s: %d threads %d, nodes %d (ref %d), refs %d, active transactions %d, buffers %d, pages %d\n",
__func__, proc->pid, threads, nodes, incoming_refs,
outgoing_refs, active_transactions, buffers, page_count);
kfree(proc);
}static int binder_node_release(struct binder_node *node, int refs)
{
struct binder_ref *ref;
int death = 0;
list_del_init(&node->work.entry);
binder_release_work(&node->async_todo);
if (hlist_empty(&node->refs)) {
kfree(node);
binder_stats_deleted(BINDER_STAT_NODE);
return refs;
}
node->proc = NULL;//将proc置空，binder_proc在release之后不会存在了，但是binder_node不会被delete。
node->local_strong_refs = 0;
node->local_weak_refs = 0;
hlist_add_head(&node->dead_node, &binder_dead_nodes);//加入到binder_dead_nodes中去。
//遍历node对应的所有的binder_ref对象。
hlist_for_each_entry(ref, &node->refs, node_entry) {
refs++;
if (!ref->death)
continue;
death++;
if (list_empty(&ref->death->work.entry)) {//在client的proc.todo中加入BINDER_WORK_DEAD_BINDER work.
ref->death->work.type = BINDER_WORK_DEAD_BINDER;
list_add_tail(&ref->death->work.entry,
&ref->proc->todo);
wake_up_interruptible(&ref->proc->wait);
} else
BUG();
}
binder_debug(BINDER_DEBUG_DEAD_BINDER,
"node %d now dead, refs %d, death %d\n",
node->debug_id, refs, death);
return refs;
}binder_ref.death正是我们在BC_REQUEST_DEATH_NOTIFICATION中为binder_ref创建的。
这里我们已经看出问题了，client在没有和binder交互的情况下，是不可能处理到BINDER_WORK_DEAD_BINDER这个work的。所以我们在client这段也需要调用一下IPCThreadState::joinThreadPool()。
我们假设已经建立了一个thread的情况继续往下分析。
回到SampleService的client端来，当SampleService挂掉之后，client的todo中有了一个BINDER_WORK_DEAD_BINDER的work。
case BINDER_WORK_DEAD_BINDER:
case BINDER_WORK_DEAD_BINDER_AND_CLEAR:
case BINDER_WORK_CLEAR_DEATH_NOTIFICATION: {
struct binder_ref_death *death;
uint32_t cmd;
//获取binder_ref_death对象。
death = container_of(w, struct binder_ref_death, work);
if (w->type == BINDER_WORK_CLEAR_DEATH_NOTIFICATION)
cmd = BR_CLEAR_DEATH_NOTIFICATION_DONE;
else
cmd = BR_DEAD_BINDER;
//写回cmd。
if (put_user(cmd, (uint32_t __user *)ptr))
return -EFAULT;
ptr += sizeof(uint32_t);
if (put_user(death->cookie, (void * __user *)ptr))
return -EFAULT;
ptr += sizeof(void *);
binder_stat_br(proc, thread, cmd);
binder_debug(BINDER_DEBUG_DEATH_NOTIFICATION,
"%d:%d %s %p\n",
proc->pid, thread->pid,
cmd == BR_DEAD_BINDER ?
"BR_DEAD_BINDER" :
"BR_CLEAR_DEATH_NOTIFICATION_DONE",
death->cookie);
if (w->type == BINDER_WORK_CLEAR_DEATH_NOTIFICATION) {
list_del(&w->entry);
kfree(death);
binder_stats_deleted(BINDER_STAT_DEATH);
} else//加入到delivered_death list
list_move(&w->entry, &proc->delivered_death);
if (cmd == BR_DEAD_BINDER)
goto done; /* DEAD_BINDER notifications can cause transactions */
} break;回到user层后，处理BR_DEAD_BINDER,
case BR_DEAD_BINDER:
{
BpBinder *proxy = (BpBinder*)mIn.readInt32();
proxy->sendObituary();//调用注册的death callback.
mOut.writeInt32(BC_DEAD_BINDER_DONE);//写回BC_DEAD_BINDER_DONE，告诉binder已经处理完毕。
mOut.writeInt32((int32_t)proxy);
} break;void BpBinder::sendObituary()
{
ALOGV("Sending obituary for proxy %p handle %d, mObitsSent=%s\n",
this, mHandle, mObitsSent ? "true" : "false");
mAlive = 0;
if (mObitsSent) return;
mLock.lock();
Vector<Obituary>* obits = mObituaries;
if(obits != NULL) {
ALOGV("Clearing sent death notification: %p handle %d\n", this, mHandle);
IPCThreadState* self = IPCThreadState::self();
self->clearDeathNotification(mHandle, this);//写BC_CLEAR_DEATH_NOTIFICATION command给binder。
self->flushCommands();
mObituaries = NULL;
}
mObitsSent = 1;
mLock.unlock();
ALOGV("Reporting death of proxy %p for %d recipients\n",
this, obits ? obits->size() : 0);
if (obits != NULL) {
const size_t N = obits->size();
for (size_t i=0; i<N; i++) {//调用注册在vector中的DeathRecipient。
reportOneDeath(obits->itemAt(i));
}
delete obits;
}
}void BpBinder::reportOneDeath(const Obituary& obit)
{
sp<DeathRecipient> recipient = obit.recipient.promote();
ALOGV("Reporting death to recipient: %p\n", recipient.get());
if (recipient == NULL) return;
recipient->binderDied(this);
}处理完BR_DEAD_BINDER之后，client又向binder中写了两个command，BC_CLEAR_DEATH_NOTIFICATION 和 BC_DEAD_BINDER_DONE，再进入binder中看这两个command的处理。
BC_CLEAR_DEATH_NOTIFICATION在binder_thread_write()中是和BC_REQUEST_DEATH_NOTIFICATION在一个case中处理的，他们的处理是相反的， BC_REQUEST_DEATH_NOTIFICATION为当前的binder_ref建立了一个新的binder_ref_death对象，而BC_CLEAR_DEATH_NOTIFICATION是清除了当前的binder_ref.death指针：
} else {
if (ref->death == NULL) {
binder_user_error("%d:%d BC_CLEAR_DEATH_NOTIFICATION death notification not active\n",
proc->pid, thread->pid);
break;
}
death = ref->death;
if (death->cookie != cookie) {
binder_user_error("%d:%d BC_CLEAR_DEATH_NOTIFICATION death notification cookie mismatch %p != %p\n",
proc->pid, thread->pid,
death->cookie, cookie);
break;
}
ref->death = NULL;//清除binder_ref中的death指针。
if (list_empty(&death->work.entry)) {//death work没有被加入到某个list中，也就是service died还没有被触发。
death->work.type = BINDER_WORK_CLEAR_DEATH_NOTIFICATION;
if (thread->looper & (BINDER_LOOPER_STATE_REGISTERED | BINDER_LOOPER_STATE_ENTERED)) {
list_add_tail(&death->work.entry, &thread->todo);
} else {
list_add_tail(&death->work.entry, &proc->todo);
wake_up_interruptible(&proc->wait);
}
} else {//death work已经被加入到list中，也就是 service died已经触发了，修改work type。
BUG_ON(death->work.type != BINDER_WORK_DEAD_BINDER);
death->work.type = BINDER_WORK_DEAD_BINDER_AND_CLEAR;
}
}之后，binder继续处理BC_DEAD_BINDER_DONE这个command,
case BC_DEAD_BINDER_DONE: {
struct binder_work *w;
void __user *cookie;
struct binder_ref_death *death = NULL;
if (get_user(cookie, (void __user * __user *)ptr))
return -EFAULT;
ptr += sizeof(void *);
list_for_each_entry(w, &proc->delivered_death, entry) {//根据cookie（user层的BpBinder指针）查找到对应的binder_ref_death。
struct binder_ref_death *tmp_death = container_of(w, struct binder_ref_death, work);
if (tmp_death->cookie == cookie) {
death = tmp_death;
break;
}
}
binder_debug(BINDER_DEBUG_DEAD_BINDER,
"%d:%d BC_DEAD_BINDER_DONE %p found %p\n",
proc->pid, thread->pid, cookie, death);
if (death == NULL) {
binder_user_error("%d:%d BC_DEAD_BINDER_DONE %p not found\n",
proc->pid, thread->pid, cookie);
break;
}
list_del_init(&death->work.entry);//从deliver_death list中删除当前的work。
if (death->work.type == BINDER_WORK_DEAD_BINDER_AND_CLEAR) {
death->work.type = BINDER_WORK_CLEAR_DEATH_NOTIFICATION;//发送BINDER_WORK_CLEAR_DEATH_NOTIFICATION work去清除death。
if (thread->looper & (BINDER_LOOPER_STATE_REGISTERED | BINDER_LOOPER_STATE_ENTERED)) {
list_add_tail(&death->work.entry, &thread->todo);
} else {
list_add_tail(&death->work.entry, &proc->todo);
wake_up_interruptible(&proc->wait);
}
}
} break;这边从delivered_death list中删除了death的work，又发了一个新的work BINDER_WORK_CLEAR_DEATH_NOTIFICATION给当前的进程。
从binder_thread_write()中退出后binder在binder_thread_read()中会接受到BINDER_WORK_CLEAR_DEATH_NOTIFICATION进行处理，这个command和前面的BINDER_WORK_DEAD_BINDER是一个case中处理，主要行为，
if (w->type == BINDER_WORK_CLEAR_DEATH_NOTIFICATION)
cmd = BR_CLEAR_DEATH_NOTIFICATION_DONE;
else
cmd = BR_DEAD_BINDER; if (w->type == BINDER_WORK_CLEAR_DEATH_NOTIFICATION) {
list_del(&w->entry);
kfree(death);
binder_stats_deleted(BINDER_STAT_DEATH);
}BR_CLEAR_DEATH_NOTIFICATION_DONE在user层处理：
case BR_CLEAR_DEATH_NOTIFICATION_DONE:
{
BpBinder *proxy = (BpBinder*)mIn.readInt32();
proxy->getWeakRefs()->decWeak(proxy);
} break;getWeakRefs()->incWeak(this);到这，整个DeathRecipient的流程就结束了，我们从中也看到了death的回调整个流程是需要client不停的和binder去交互的，所以我们在client中要也要加上IPCThreadState::joinThreadPool()才行。对client的main函数做如下修改后，我们的deathcallback就可以被调用到了。
#if 0
do{
sleep(2);
if(deathCalled){
ALOGE("death callback called\n");
break;
}
}while(1);
#else
IPCThreadState::self()->joinThreadPool(true);
#endif
四，binder总结
基本上所有的点在上面已经都分析到了。这里list下kernel中的关键对象：
binder_proc：和user层ProcessState对应。
binder_thread：和user层IPCThreadState对应。
binder_node：service在binder中的代表。
binder_ref：client在binder中的代表。
binder_work：传递信息的表达。
binder_proc/binder_thread.todo：维护binder_work，用来传递信息的重要对象。
End!
-------------------------------------------
by sky
扫一扫
1346
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
