Android源码分析--MediaServer源码分析（二）

在上一篇博客中Android源码分析–MediaServer源码分析（一），我们知道了ProcessState和defaultServiceManager，在分析源码的过程中，我们被Android的Binder通信机制中的各种复杂的类关系搞的眼花缭乱，接下来我们就以MediaPlayerService为例来分析一下Binder的通信机制。首先来回顾一下：

• BpBinder和BBinder都是Android中Binder通信的代表类，其中BpBinder是客户端用来与Server交互的代理类，p代表的就是proxy，而BBinder则是交互的目的端；
• BpBinder和BBinder是相互对应的，Binder系统会通过handle来标识对应的BBinder。

Android的通信机制基本上可以看做是Client、Server和ServiceManager三者之间的交互：

• Server首先要注册一些Service到ServiceManager；
• 如果某个Client要使用Service，则首先到ServiceManager中获得该Service的相关信息；
• Client得到Service信息，然后和该Service所在的Server进程建立通信之后使用Service。

注册MediaPlayerService

我们知道若要使用一个Service的话首先要进行注册，所有首先让我们来看看MediaService是如何注册的，文件位置：frameworks\base\media\libmediaplayerservice\MediaPlayerService.cpp

void MediaPlayerService::instantiate() {
    defaultServiceManager()->addService(
            String16("media.player"), new MediaPlayerService());
}

defaultServiceManager返回的其实是一个BpServiceManager对象，在这里我看到了注册的函数addService：

    virtual status_t addService(const String16& name, const sp<IBinder>& service)
    {
        Parcel data, reply;
    //将Descriptor作为令牌
        data.writeInterfaceToken(IServiceManager::getInterfaceDescriptor());
        data.writeString16(name);
        data.writeStrongBinder(service);
        status_t err = remote()->transact(ADD_SERVICE_TRANSACTION, data, &reply);
        return err == NO_ERROR ? reply.readExceptionCode() : err;
}

Parcel类可以看作一个数据块，在该类的内部主要封装了一些数据操作的方法。在写入数据之后remote()->transact方法，remote()方法返回的值是mRemote，在上一篇中我们知道它是一个BpBinder对象，之后我们的通信工作就交由了BpBinder的transact方法：

status_t BpBinder::transact(
    uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags)
{
    // Binder一旦死去将永远不能复活.
    if (mAlive) {
        status_t status = IPCThreadState::self()->transact(
            mHandle, code, data, reply, flags);
        if (status == DEAD_OBJECT) mAlive = 0;
        return status;
    }

    return DEAD_OBJECT;
}

BpBinder完全将工作交给了IPCThreadState，接下来的任务也全部转移到了IPCThreadState类中。

IPCThreadState类分析

IPCThreadState也是以单例模式设计的。由于每个进程只维护了一个ProcessState实例，同时ProcessState只启动一个 Pool thread，也就是说每一个进程只会启动一个Pool thread，因此每个进程则只需要一个IPCThreadState即可。首先让我们来看看这个self方法，文件位置：frameworks\base\libs\binder\IPCThreadState.cpp

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;
}

TLS是Thread Local Storage的缩写，表示线程本地存储，类似于Java中的ThreadLocal机制)pthread_getspecific和)pthread_setspecific方法分别提供了设置变量和获取变量的方法。

在这里我们看到了get方法，有get方法就一定有对应的set方法，set的设置就在构造函数中：

IPCThreadState::IPCThreadState()
    : mProcess(ProcessState::self()),
      mMyThreadId(androidGetTid()),
      mStrictModePolicy(0),
      mLastTransactionBinderFlags(0)
{
    pthread_setspecific(gTLS, this);
    clearCaller();
    mIn.setDataCapacity(256);
    mOut.setDataCapacity(256);
}

可以看到在构造函数中IPCThreadState将自身和线程本地存储关联起来了，在每一个IPCThreadState中都存在一个mIn和mOut，mIn用来存储接收Binder的数据，mOut用来存储发送到Binder的数据。

接下来看看transact方法：

status_t IPCThreadState::transact(int32_t handle,
                                  uint32_t code, const Parcel& data,
                                  Parcel* reply, uint32_t flags)
{
    status_t err = data.errorCheck();

    flags |= TF_ACCEPT_FDS;
    ......
    if (err == NO_ERROR) {
        ......
        err = writeTransactionData(BC_TRANSACTION, flags, handle, code, data, NULL);
    }     
    ......
        if (reply) {
            err = waitForResponse(reply);
        } else {
            Parcel fakeReply;
            err = waitForResponse(&fakeReply);
        }
        ......
    } else {
        err = waitForResponse(NULL, NULL);
    }

    return err;
}

在这里省略了一些打印输出信息的语句，在这里我们可以清楚的看到通信的流程：先写入数据，然后等待接收数据。

如何进行通信

在前面我们知道了通信的流程，首先写入数据，之后等待回应，那么我们的通信就是这样不断的读写数据吗？接下来我们来一下看一下这两个读写的函数：
1.写入数据：

status_t IPCThreadState::writeTransactionData(int32_t cmd, uint32_t binderFlags,
    int32_t handle, uint32_t code, const Parcel& data, status_t* statusBuffer)
{
    binder_transaction_data tr;

    tr.target.handle = handle;
    tr.code = code;
    tr.flags = binderFlags;
    tr.cookie = 0;
    tr.sender_pid = 0;
    tr.sender_euid = 0;

    const status_t err = data.errorCheck();
    if (err == NO_ERROR) {
        tr.data_size = data.ipcDataSize();
        tr.data.ptr.buffer = data.ipcData();
        tr.offsets_size = data.ipcObjectsCount()*sizeof(size_t);
        tr.data.ptr.offsets = data.ipcObjects();
    } else if (statusBuffer) {
        tr.flags |= TF_STATUS_CODE;
        *statusBuffer = err;
        tr.data_size = sizeof(status_t);
        tr.data.ptr.buffer = statusBuffer;
        tr.offsets_size = 0;
        tr.data.ptr.offsets = NULL;
    } else {
        return (mLastError = err);
    }

    mOut.writeInt32(cmd);
    mOut.write(&tr, sizeof(tr));

    return NO_ERROR;
}

在写入数据之前，我们首先对BpBinder进行了标识，在这里我们看到了之前所说的handle值，这样印证了之前一篇博客中所说的BBinder和BpBinder是由handle值来相互标识的。

2.等待回应：

status_t IPCThreadState::waitForResponse(Parcel *reply, status_t *acquireResult)
{
    int32_t cmd;
    int32_t err;

while (1) {
    //talkWithDriver重要函数之一，负责从Binder中读写数据
        if ((err=talkWithDriver()) < NO_ERROR) break;
        err = mIn.errorCheck();
        if (err < NO_ERROR) break;
        if (mIn.dataAvail() == 0) continue;

        cmd = mIn.readInt32();

        switch (cmd) {
        case BR_TRANSACTION_COMPLETE://发送完一个数据包后，可以收到该消息做为成功发送的反馈。
            if (!reply && !acquireResult) goto finish;
            break;

        case BR_DEAD_REPLY://交互过程中如果发现对方进程或线程已经死亡
            err = DEAD_OBJECT;
            goto finish;

        case BR_FAILED_REPLY://发送失败
            err = FAILED_TRANSACTION;
            goto finish;

        case BR_ACQUIRE_RESULT://获得结果
            {
                const int32_t result = mIn.readInt32();
                if (!acquireResult) continue;
                *acquireResult = result ? NO_ERROR : INVALID_OPERATION;
            }
            goto finish;

        case BR_REPLY://当前接收的数据是回复
            {
                binder_transaction_data tr;
                err = mIn.read(&tr, sizeof(tr));
                ALOG_ASSERT(err == NO_ERROR, "Not enough command data for brREPLY");
                if (err != NO_ERROR) goto finish;

                if (reply) {
                    if ((tr.flags & TF_STATUS_CODE) == 0) {
                        reply->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);
                    } else {
                        err = *static_cast<const status_t*>(tr.data.ptr.buffer);
                        freeBuffer(NULL,
                            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), this);
                    }
                } else {
                    freeBuffer(NULL,
                        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), this);
                    continue;
                }
            }
            goto finish;

        default:
        //第二个重要函数，处理命令
            err = executeCommand(cmd);
            if (err != NO_ERROR) goto finish;
            break;
        }
    }

finish:
    if (err != NO_ERROR) {
        if (acquireResult) *acquireResult = err;
        if (reply) reply->setError(err);
        mLastError = err;
    }

    return err;
}

可以看到我们首先从Binder中读写数据，之后执行命令并返回结果状态码。

两个重要函数

IPCThreadState有两个重要的函数，talkWithDriver函数负责从Binder读写数据，executeCommand函数负责解析并执行mIn中的数据。
1.talkWithDriver：

status_t IPCThreadState::talkWithDriver(bool doReceive)
{
//用来和Binder交换数据的结构
    binder_write_read bwr;

    // 判断数据是否为空
    const bool needRead = mIn.dataPosition() >= mIn.dataSize();

    // 如果caller已经请求读取下一行数据，或缓冲区中有数据没读完的时候我们不会进行任何写操作
    const size_t outAvail = (!doReceive || needRead) ? mOut.dataSize() : 0;
    //填充请求命令
    bwr.write_size = outAvail;
    bwr.write_buffer = (long unsigned int)mOut.data();

    if (doReceive && needRead) {
        bwr.read_size = mIn.dataCapacity();
        bwr.read_buffer = (long unsigned int)mIn.data();//mIn用来存储接收的Binder数据
    } else {
        bwr.read_size = 0;
        bwr.read_buffer = 0;
    }
......
    // 如果不需要任何操作了立即返回.
    if ((bwr.write_size == 0) && (bwr.read_size == 0)) return NO_ERROR;

    bwr.write_consumed = 0;
    bwr.read_consumed = 0;
    status_t err;
    do {
#if defined(HAVE_ANDROID_OS)
//ioctl方式进行通信
        if (ioctl(mProcess->mDriverFD, BINDER_WRITE_READ, &bwr) >= 0)
            err = NO_ERROR;
        else
            err = -errno;
#else
        err = INVALID_OPERATION;
#endif
    } while (err == -EINTR);

    if (err >= NO_ERROR) {
        if (bwr.write_consumed > 0) {
            if (bwr.write_consumed < (ssize_t)mOut.dataSize())
                mOut.remove(0, bwr.write_consumed);
            else
                mOut.setDataSize(0);
        }
        if (bwr.read_consumed > 0) {
            mIn.setDataSize(bwr.read_consumed);
            mIn.setDataPosition(0);
        }
        return NO_ERROR;
    } 
    return err;
}

可以看到我们的Binder通信并不是采用的读写方式，而是ioctl方式，什么是ioctl方式呢？

ioctl是设备驱动程序中对设备的I/O通道进行管理的函数。所谓对I/O通道进行管理，就是对设备的一些特性进行控制，例如串口的传输波特率、马达的 转速等等。它的调用函数如下：int ioctl(int fd, ind cmd, …)；其中fd就是用户程序打开设备时使用open函数返回的文件标示符，cmd就是用户程序对设备的控制命令。

2.executeCommand函数：

status_t IPCThreadState::executeCommand(int32_t cmd)
{
    BBinder* obj;
    RefBase::weakref_type* refs;
    status_t result = NO_ERROR;

    switch (cmd) {
    case BR_ERROR:
        result = mIn.readInt32();
        break;

    case BR_OK:
        break;

    case BR_ACQUIRE:
        refs = (RefBase::weakref_type*)mIn.readInt32();
        obj = (BBinder*)mIn.readInt32();
        obj->incStrong(mProcess.get()); 
        mOut.writeInt32(BC_ACQUIRE_DONE);
        mOut.writeInt32((int32_t)refs);
        mOut.writeInt32((int32_t)obj);
        break;

    case BR_RELEASE:
        refs = (RefBase::weakref_type*)mIn.readInt32();
        obj = (BBinder*)mIn.readInt32();
        mPendingStrongDerefs.push(obj);
        break;

    case BR_INCREFS:
        refs = (RefBase::weakref_type*)mIn.readInt32();
        obj = (BBinder*)mIn.readInt32();
        refs->incWeak(mProcess.get());
        mOut.writeInt32(BC_INCREFS_DONE);
        mOut.writeInt32((int32_t)refs);
        mOut.writeInt32((int32_t)obj);
        break;

    case BR_DECREFS:
        refs = (RefBase::weakref_type*)mIn.readInt32();
        obj = (BBinder*)mIn.readInt32();
        mPendingWeakDerefs.push(refs);
        break;

    case BR_ATTEMPT_ACQUIRE:
        refs = (RefBase::weakref_type*)mIn.readInt32();
        obj = (BBinder*)mIn.readInt32();

        {
            const bool success = refs->attemptIncStrong(mProcess.get());
            mOut.writeInt32(BC_ACQUIRE_RESULT);
            mOut.writeInt32((int32_t)success);
        }
        break;

    case BR_TRANSACTION://当前接收的数据是请求
        {
            binder_transaction_data tr;
            result = mIn.read(&tr, sizeof(tr));
            if (result != NO_ERROR) break;

            Parcel buffer;
            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;

            int curPrio = getpriority(PRIO_PROCESS, mMyThreadId);
            if (gDisableBackgroundScheduling) {
                if (curPrio > ANDROID_PRIORITY_NORMAL) {
                //我们已经从caller实现了一个减小的优先级，但我们不希望它以这
                //种状态运行在进程中。驱动已经设置了优先级，所以在开始事务
            //前首先将他设置为默认                   
                    setpriority(PRIO_PROCESS, mMyThreadId, ANDROID_PRIORITY_NORMAL);
                }
            } else {
                if (curPrio >= ANDROID_PRIORITY_BACKGROUND) {
                    androidSetThreadSchedulingGroup(mMyThreadId,                                                   ANDROID_TGROUP_BG_NONINTERACT);
                }
            }

            Parcel reply;
            if (tr.target.ptr) {
        //在这里我们看到了BBinder，还记得吗，BBinder和BpBinder相对应，
        //是交互的目的端
        sp<BBinder> b((BBinder*)tr.cookie);
        //在transact函数中调用了onTransact方法向reply写入数据
                const status_t error = b->transact(tr.code, buffer, &reply, tr.flags);
                if (error < NO_ERROR) reply.setError(error);
            } else {
                const status_t error = the_context_object->transact(tr.code, buffer, &reply, tr.flags);
                if (error < NO_ERROR) reply.setError(error);
            }

            if ((tr.flags & TF_ONE_WAY) == 0) {
                sendReply(reply, 0);
            } 

            mCallingPid = origPid;
            mCallingUid = origUid;    
        }
        break;

    case BR_DEAD_BINDER:
        {
            BpBinder *proxy = (BpBinder*)mIn.readInt32();
            proxy->sendObituary();
            mOut.writeInt32(BC_DEAD_BINDER_DONE);
            mOut.writeInt32((int32_t)proxy);
        } break;

    case BR_CLEAR_DEATH_NOTIFICATION_DONE:
        {
            BpBinder *proxy = (BpBinder*)mIn.readInt32();
            proxy->getWeakRefs()->decWeak(proxy);
        } break;

    case BR_FINISHED:
        result = TIMED_OUT;
        break;

    case BR_NOOP:
        break;

case BR_SPAWN_LOOPER:
    //用于接收方线程池管理。当驱动发现接收方所有线程都处于忙碌状态且线
    //程池里的线程总数没有超过BINDER_SET_MAX_THREADS设置的最大线程数    
    //时，向接收方发送该命令要求创建更多线程以备接收数据。
        mProcess->spawnPooledThread(false);
        break;

    default:
        printf("*** BAD COMMAND %d received from Binder driver\n", cmd);
        result = UNKNOWN_ERROR;
        break;
    }

    if (result != NO_ERROR) {
        mLastError = result;
    }

    return result;
}

在这里我们主要分析一下接收数据请求的情况：在这里我们看到了BBinder对象，并调用了它的transact函数，其实在内部调用了onTransact函数，而这个函数在BBinder中只是定义了两种code之下的操作，大部分的情况是由它的子类完成。还记得上一篇中那个类的关系图吗：BBinder的直接子类是BnInterface，而这是一个接口类，所以所有的任务都落在了BnInterface的子类BnServiceManager中。

总结

看了这个类IPCThreadState，真的有点头晕眼花，究其原因是：该类将代码一部分给客户端使用，一部分给服务端使用，所以有点杂乱。总结一下今天学到的IPCThreadState的工作：

1. 首先，通过线程本地存储机制IPCThreadState将自身和线程本地存储关联起来；
2. 通过writeTransactionData将发生的数据存储在mOut中；
3. waitForResponse调用了talkWithDriver从Binder设备中读写数据，在这里采用的是ioctl方式；
4. 调用executeCommand函数解析并执行mIn中的数据。