Android -- IPC通信机制之一Binder简介
随着慢慢进入Android Media模块，遇到了很多新的知识和难点，其中之一就是native代码中使用频繁的Binder通信机制。Binder是Android中使用最频繁的一种IPC通信机制，底层基于内核的binder驱动。谷歌大神在native层封装了一套Binder API，供我们实现自己的Binder服务。
Binder是一种Client/Server架构的通信机制，它往往以系统服务的形式存在于系统中。客户端获取一个服务代理对象，通过该服务代理对象与与远程的Server(通常服务端也会有一个服务端代理对象)进行操作交互，实现IPC通信。既然，Binder通信基于Client/Server架构，且以服务的形式存在，那就必须要考虑服务的管理工作。Android中有一个特殊的程序专门用来管理系统中各种各样的服务，它就是ServiceManager。我们实现了自己的服务后，需要注册到ServiceManager中；当Client要使用某个服务时，则要通过ServiceManager获取到该服务的代理对象。
说了这么多， 我们就以MediaServer这个服务为例，来分析native层Binder的通信机制。MediaServer是Android系统中一个庞大、复杂的模块，它在init.rc进行声明：
service media /system/bin/mediaserver
class main
user media
group audio camera inet net_bt net_bt_admin net_bw_acct drmrpc mediadrm
ioprio rt 4当init进程解析到该服务声明时，会为它创建进程并启动它的主程序，具体定义在main_mediaserver.cpp中：
int main(int argc __unused, char** argv)
{
signal(SIGPIPE, SIG_IGN);
char value[PROPERTY_VALUE_MAX];
bool doLog = (property_get("ro.test_harness", value, "0") > 0) && (atoi(value) == 1);
pid_t childPid;
// FIXME The advantage of making the process containing media.log service the parent process of
// the process that contains all the other real services, is that it allows us to collect more
// detailed information such as signal numbers, stop and continue, resource usage, etc.
// But it is also more complex. Consider replacing this by independent processes, and using
// binder on death notification instead.
if (doLog && (childPid = fork()) != 0) {
// media.log service
//prctl(PR_SET_NAME, (unsigned long) "media.log", 0, 0, 0);
// unfortunately ps ignores PR_SET_NAME for the main thread, so use this ugly hack
strcpy(argv[0], "media.log");
sp<ProcessState> proc(ProcessState::self());
MediaLogService::instantiate();
ProcessState::self()->startThreadPool();
for (;;) {
...
} else {
// all other services
if (doLog) {
prctl(PR_SET_PDEATHSIG, SIGKILL); // if parent media.log dies before me, kill me also
setpgid(0, 0); // but if I die first, don't kill my parent
}
InitializeIcuOrDie();
sp<ProcessState> proc(ProcessState::self());//1、创建ProcessState实例
sp<IServiceManager> sm = defaultServiceManager();//2、获取IServiceManager的实例，与ServiceManagner交互，用于注册或者获取服务
ALOGI("ServiceManager: %p", sm.get());//调试信息
AudioFlinger::instantiate();
MediaPlayerService::instantiate();//3、创建MediaPlayerService实例,通过ServiceManager注册服务
ResourceManagerService::instantiate();
CameraService::instantiate();
AudioPolicyService::instantiate();
SoundTriggerHwService::instantiate();
RadioService::instantiate();
registerExtensions();
//4、创建线程、启动线程池，处理Binder通信请求
ProcessState::self()->startThreadPool();
IPCThreadState::self()->joinThreadPool();
}
}
我们根据代码标记处的四步代码处理，来具体分析其中的Binder通信机制。
一、创建ProcessState对象
sp<ProcessState> proc(ProcessState::self());//1、创建ProcessState实例ProcessState类描述了当前进程的状态信息，每个进程只会有一个ProcessState实例。看它的构造过程：
//self()使用了单例模式,每个进程只有一个ProcessState对象
sp<ProcessState> ProcessState::self()
{
Mutex::Autolock _l(gProcessMutex);
if (gProcess != NULL) {
return gProcess;
}
gProcess = new ProcessState;
return gProcess;
}self()使用单例模式创建ProcessState实例，具体构造过程看其构造函数：
ProcessState::ProcessState()
: mDriverFD(open_driver())//打开/dev/binder这个虚拟设备，它的作用就是用于完成进程间通信
, mVMStart(MAP_FAILED)
, mThreadCountLock(PTHREAD_MUTEX_INITIALIZER)
, mThreadCountDecrement(PTHREAD_COND_INITIALIZER)
, mExecutingThreadsCount(0)
, mMaxThreads(DEFAULT_MAX_BINDER_THREADS)
, mManagesContexts(false)
, mBinderContextCheckFunc(NULL)
, mBinderContextUserData(NULL)
, mThreadPoolStarted(false)
, mThreadPoolSeq(1)
{
if (mDriverFD >= 0) {
// XXX Ideally, there should be a specific define for whether we
// have mmap (or whether we could possibly have the kernel module
// availabla).
#if !defined(HAVE_WIN32_IPC)
// mmap the binder, providing a chunk of virtual address space to receive transactions.
/*
*mmap将一个文件或者其它对象映射进内存
*
*void* mmap(void* start,size_t length,int prot,int flags,int fd,off_t offset);
*
*start：映射区的开始地址，设置为0时表示由系统决定映射区的起始地址。
*
*length：映射区的长度。//长度单位是 以字节为单位，不足一内存页按一内存页处理
*
*prot：期望的内存保护标志，不能与文件的打开模式冲突。是以下的某个值，可以通过or运算合理地组合在一起
* PROT_EXEC //页内容可以被执行
* PROT_READ //页内容可以被读取
* PROT_WRITE //页可以被写入
* PROT_NONE //页不可访问
*
*flags：指定映射对象的类型，映射选项和映射页是否可以共享。它的值可以是一个或者多个以下位的组合体
* MAP_FIXED //使用指定的映射起始地址，如果由start和len参数指定的内存区重叠于现存的映射空间，重叠部分将会被丢弃。
* //如果指定的起始地址不可用，操作将会失败。并且起始地址必须落在页的边界上。
* MAP_SHARED //与其它所有映射这个对象的进程共享映射空间。对共享区的写入，相当于输出到文件。
* //直到msync()或者munmap()被调用，文件实际上不会被更新。
* MAP_PRIVATE //建立一个写入时拷贝的私有映射。内存区域的写入不会影响到原文件。这个标志和以上标志是互斥的，只能使用其中一个。
* MAP_DENYWRITE //这个标志被忽略。
* MAP_EXECUTABLE //同上
* MAP_NORESERVE //不要为这个映射保留交换空间。当交换空间被保留，对映射区修改的可能会得到保证。
* //当交换空间不被保留，同时内存不足，对映射区的修改会引起段违例信号。
* MAP_LOCKED //锁定映射区的页面，从而防止页面被交换出内存。
* MAP_GROWSDOWN //用于堆栈，告诉内核VM系统，映射区可以向下扩展。
* MAP_ANONYMOUS //匿名映射，映射区不与任何文件关联。
* MAP_ANON //MAP_ANONYMOUS的别称，不再被使用。
* MAP_FILE //兼容标志，被忽略。
* MAP_32BIT //将映射区放在进程地址空间的低2GB，MAP_FIXED指定时会被忽略。当前这个标志只在x86-64平台上得到支持。
* MAP_POPULATE //为文件映射通过预读的方式准备好页表。随后对映射区的访问不会被页违例阻塞。
* MAP_NONBLOCK //仅和MAP_POPULATE一起使用时才有意义。不执行预读，只为已存在于内存中的页面建立页表入口。
*
*fd：有效的文件描述词。一般是由open()函数返回，其值也可以设置为-1，此时需要指定flags参数中的MAP_ANON,表明进行的是匿名映射。
*
*off_toffset：被映射对象内容的起点。
*
*成功执行时，mmap()返回被映射区的指针
*
*/
mVMStart = mmap(0, BINDER_VM_SIZE, PROT_READ, MAP_PRIVATE | MAP_NORESERVE, mDriverFD, 0);//mmap后，binder驱动会分配一块内存来接收数据
if (mVMStart == MAP_FAILED) {
// *sigh*
ALOGE("Using /dev/binder failed: unable to mmap transaction memory.\n");
close(mDriverFD);
mDriverFD = -1;
}
#else
mDriverFD = -1;
#endif
}
LOG_ALWAYS_FATAL_IF(mDriverFD < 0, "Binder driver could not be opened. Terminating.");
}其中有一个很重要的初始化操作就是调用open_driver()函数初始化了mDriverFD字段，它保存了/dev/binder设备文件的文件描述符：
static int open_driver()
{
int fd = open("/dev/binder", O_RDWR);//打开这个设备，获取对应的文件描述符，这个fd就是我们与kernel中的binder驱动交互的通道
if (fd >= 0) {
fcntl(fd, F_SETFD, FD_CLOEXEC);//fcntl函数可以设置fd对应的文件的某些属性
int vers = 0;
status_t result = ioctl(fd, BINDER_VERSION, &vers);
if (result == -1) {
ALOGE("Binder ioctl to obtain version failed: %s", strerror(errno));
close(fd);
fd = -1;
}
if (result != 0 || vers != BINDER_CURRENT_PROTOCOL_VERSION) {
ALOGE("Binder driver protocol does not match user space protocol!");
close(fd);
fd = -1;
}
size_t maxThreads = DEFAULT_MAX_BINDER_THREADS;//默认情况,最大支持的Binder线程为15个
result = ioctl(fd, BINDER_SET_MAX_THREADS, &maxThreads);//设置fd所支持的最大线程数
if (result == -1) {
ALOGE("Binder ioctl to set max threads failed: %s", strerror(errno));
}
} else {
ALOGW("Opening '/dev/binder' failed: %s\n", strerror(errno));
}
return fd;
}/dev/binder是一个Binder设备，我们通过对该设备进行读写来与Binder驱动通信。该函数中打开了Binder设备，并对其进行了一些设置操作，如该设备支持的最大线程数等。
再看构造函数中的处理，我们获取到了Binder设备的文件描述符后，需要调用mmap()把该文件映射到内存中，此时Binder驱动就会为该设备分配一块内存空间，用来进行数据交互。这里ProcessState的创建工作就结束了，它最主要的工作就是打开了Binder设备，并把它映射到内存中，以支持IPC通信。
二、获取ServiceManager代理
紧接着，看第二步：
sp<IServiceManager> sm = defaultServiceManager();//2、获取IServiceManager的实例，与ServiceManagner交互，用于注册或者获取服务
直接看defaultServiceManager()函数：
//使用了单例设计模式
sp<IServiceManager> defaultServiceManager()
{
if (gDefaultServiceManager != NULL) return gDefaultServiceManager;
{
AutoMutex _l(gDefaultServiceManagerLock);
while (gDefaultServiceManager == NULL) {
gDefaultServiceManager = interface_cast<IServiceManager>(
ProcessState::self()->getContextObject(NULL));//这里有两个函数调用,interface_cast()以及getContextObject()，参数是NULL
if (gDefaultServiceManager == NULL)
sleep(1);
}
}
return gDefaultServiceManager;
}这里也使用了单例模式，主要是为了获取gDefaultServiceManager实例，它的类型是IServiceManager（IInterface的子类，IInterface中定义了两个重要的目标函数），该类定义了ServiceManager提供的所有业务方法：
//IServiceManager是一个业务逻辑类，它定义了ServiceManager需要提供的服务;从函数声明可知,主要包括获取服务、检查服务、添加服务和枚举服务
//重要地，它内部声明了一个宏定义函数:DECLARE_META_INTERFACE(ServiceManager);
class IServiceManager : public IInterface
{
public:
DECLARE_META_INTERFACE(ServiceManager);
/**
* Retrieve an existing service, blocking for a few seconds
* if it doesn't yet exist.
*/
virtual sp<IBinder> getService( const String16& name) const = 0;
/**
* Retrieve an existing service, non-blocking.
*/
virtual sp<IBinder> checkService( const String16& name) const = 0;
/**
* Register a service.
*/
virtual status_t addService( const String16& name,
const sp<IBinder>& service,
bool allowIsolated = false) = 0;
/**
* Return list of all existing services.
*/
virtual Vector<String16> listServices() = 0;
enum {//这里定义的是四个业务方法的编号，就是onTransact()、transact()函数中的code值
GET_SERVICE_TRANSACTION = IBinder::FIRST_CALL_TRANSACTION,
CHECK_SERVICE_TRANSACTION,
ADD_SERVICE_TRANSACTION,
LIST_SERVICES_TRANSACTION,
};
};为了获取到ServiceManager的代理对象，这里有两个主要的函数调用：interface_cast()以及getContextObject()。我们从内而外分析，先看getContextObject()实现：
//参数传入是NULL
sp<IBinder> ProcessState::getContextObject(const sp<IBinder>& /*caller*/)
{
return getStrongProxyForHandle(0);//参数是0，是一个特殊的句柄;观察函数名大概可以猜出是要根据某一个句柄值，去找到某一个代理对象；从这看，这里的0更像是一个数组索引
}
层次调用getStrongProxyForHandle()函数，由函数名称大概可知它会根据一个Handle值(这里为0)去得到一个代理；看它的具体实现：
//最后返回的是一个指向BpBinder类型的强指针
sp<IBinder> ProcessState::getStrongProxyForHandle(int32_t handle)
{
sp<IBinder> result;
AutoMutex _l(mLock);
handle_entry* e = lookupHandleLocked(handle);//根据参数值，找到它所对应的那个代理对象；这里参数值是0;返回值类型是handle_entry
if (e != NULL) {
// We need to create a new BpBinder if there isn't currently one, OR we
// are unable to acquire a weak reference on this current one. See comment
// in getWeakProxyForHandle() for more info about this.
IBinder* b = e->binder;
if (b == NULL || !e->refs->attemptIncWeak(this)) {
if (handle == 0) {//从源码注释可知，handle为0代表了一个特殊的代理对象:context manager，即ServiceManager的代理对象
// Special case for context manager...
// The context manager is the only object for which we create
// a BpBinder proxy without already holding a reference.
// Perform a dummy transaction to ensure the context manager
// is registered before we create the first local reference
// to it (which will occur when creating the BpBinder).
// If a local reference is created for the BpBinder when the
// context manager is not present, the driver will fail to
// provide a reference to the context manager, but the
// driver API does not return status.
//
// Note that this is not race-free if the context manager
// dies while this code runs.
//
// TODO: add a driver API to wait for context manager, or
// stop special casing handle 0 for context manager and add
// a driver API to get a handle to the context manager with
// proper reference counting.
Parcel data;
status_t status = IPCThreadState::self()->transact(
0, IBinder::PING_TRANSACTION, data, NULL, 0);//保证在我需要创建这样一个context manager实例之前，它已经注册到系统中了；否则，返回NULL
if (status == DEAD_OBJECT)
return NULL;
}
b = new BpBinder(handle); //创建BpBinder对象，用于填充;handle值会保存到mHandle,此处是0
e->binder = b;
if (b) e->refs = b->getWeakRefs();
result = b;
} 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.
result.force_set(b);
e->refs->decWeak(this);
}
}
return result;
}果然，它通过lookupHandleLocked()函数，查找句柄(handle)值为0的那个代理对象：
ProcessState::handle_entry* ProcessState::lookupHandleLocked(int32_t handle)
{
const size_t N=mHandleToObject.size();
if (N <= (size_t)handle) {//如果集合内存储的对象总数小于要被查找的索引值，则会创建一个新的对象
handle_entry e;
e.binder = NULL;//填充对象,IBinder类型
e.refs = NULL;//填充对象,RefBase::weakref_type类型;用于引用计数,控制对象的消亡
status_t err = mHandleToObject.insertAt(e, N, handle+1-N);
if (err < NO_ERROR) return NULL;
}
return &mHandleToObject.editItemAt(handle);
}从我们分析的意图来看，0这个句柄值所对应的代理对象就应该是ServiceManager。该函数的整个处理过程类似数组的查找，最后返回一个ProcessState::handle_entry类型对象，它的类型定义是：
struct handle_entry {
IBinder* binder;
RefBase::weakref_type* refs;
};我们主要关注IBinder成员变量。如果根据句柄值，没有查找到对应的资源项，就会重新构建一个handle_entry对象，它的binder值为null；此时符合这种场景。回到getStrongProxyForHandle()函数，由于我们这里的handle值就是0，且e->binder为null。最后就会根据句柄值创建一个BpBinder实例，并返回函数调用。
至此，我们就遇到了几个重要的Binder类型：BpBinder、BBinder和IBinder，它们是Android中用于Binder通信的代表；即正真与Binder驱动交互，都要通过这三个类来完成。
我们首先看下这几个类的家族图谱：
BpBinder的主要定义如下：
//在Binder通信框架中，是客户端与Server进行交互的代理类;它与一个BBinder对应
class BpBinder : public IBinder
{
public:
BpBinder(int32_t handle);
inline int32_t handle() const { return mHandle; }
virtual const String16& getInterfaceDescriptor() const;
virtual status_t transact( uint32_t code,
const Parcel& data,
Parcel* reply,
uint32_t flags = 0);
...
protected:
virtual ~BpBinder();
virtual void onFirstRef();
virtual void onLastStrongRef(const void* id);
virtual bool onIncStrongAttempted(uint32_t flags, const void* id);
private:
const int32_t mHandle;//保持handle值，此处为0；在与BBinder通信时，可以根据句柄值找到目的对象
...
};BBinder的定义类似：
//与BpBinder对应，是Server的代理类;它与BpBinder进行交互
class BBinder : public IBinder
{
public:
BBinder();
virtual const String16& getInterfaceDescriptor() const;
...
virtual status_t transact( uint32_t code,
const Parcel& data,
Parcel* reply,
uint32_t flags = 0);
...
protected:
virtual ~BBinder();
virtual status_t onTransact( uint32_t code,
const Parcel& data,
Parcel* reply,
uint32_t flags = 0);
...
};BpBinder中的transact()函数是Client端(这里是BpServiceManager)用来向Server代理端发送进程间通信请求的。当Binder驱动接收到Client组件发送过来的进程间通信请求后，就会调用BBinder::transact()处理该请求；BBinder中的onTransact()函数一般都是由一个BBinder的子类(这里是BnServiceManager，Server组件)来实现，它负责分发接收到的来自Client端的进程间通信请求，并交与某个服务类(服务类一般都是Server组件的子类，并实现服务的业务方法；我们注册一个服务时，就是将这个服务类注册进系统中。这里是Service Manager处理。
我们得到了new BpBinder(0)实例对象后，再返回到外层函数调用：
//使用了单例设计模式
sp<IServiceManager> defaultServiceManager()
{
if (gDefaultServiceManager != NULL) return gDefaultServiceManager;
{
AutoMutex _l(gDefaultServiceManagerLock);
while (gDefaultServiceManager == NULL) {
/*
*ProcessState::self()->getContextObject(NULL)函数最终返回一个new BpBinder(0)对象实例
*
*所以就得出:
*
*interface_cast<IServiceManager>(new BpBinder(0));
*
*而BpBinder实例就是一个与Server交互的代理类，我们带着这个代理类实例去调用interface_cast()
*
*/
gDefaultServiceManager = interface_cast<IServiceManager>(
ProcessState::self()->getContextObject(NULL));//这里有两个函数调用,interface_cast()以及getContextObject()，参数是NULL
if (gDefaultServiceManager == NULL)
sleep(1);
}
}
return gDefaultServiceManager;
}interface_cast<IServiceManager>()函数是一个重要的模板函数，它定义IServiceManager.h中：
/*
一个模板函数
当INTERFACE为IServiceManager时，整个函数定义就是:
template<typename IServiceManager>
inline sp<IServiceManager> interface_cast(const sp<IBinder>& obj)
{
return IServiceManager::asInterface(obj);
}
实际调用IServiceManager::asInterface(obj)函数
*/
template<typename INTERFACE>
inline sp<INTERFACE> interface_cast(const sp<IBinder>& obj)
{
return INTERFACE::asInterface(obj);
}由代码可知，它实际调用的是IServiceManager::asInterface(obj)函数，那asInterface()函数到底是怎么声明的呢？在IInterface.h中有一个特殊的宏定义：
#define DECLARE_META_INTERFACE(INTERFACE) \
static const android::String16 descriptor; \
static android::sp<I##INTERFACE> asInterface( \
const android::sp<android::IBinder>& obj); \
virtual const android::String16& getInterfaceDescriptor() const; \
I##INTERFACE(); \
virtual ~I##INTERFACE(); \(C++中'##'是连接符号，可以将两个token连接成一个token)它声明了几个函数，其中就有asInterface()，具体的类型名称都由模板类型决定；同时，这几个函数的定义也是由一个宏来定义的：
#define IMPLEMENT_META_INTERFACE(INTERFACE, NAME) \
const android::String16 I##INTERFACE::descriptor(NAME); \
const android::String16& \
I##INTERFACE::getInterfaceDescriptor() const { \
return I##INTERFACE::descriptor; \
} \
android::sp<I##INTERFACE> I##INTERFACE::asInterface( \
const android::sp<android::IBinder>& obj) \
{ \
android::sp<I##INTERFACE> intr; \
if (obj != NULL) { \
intr = static_cast<I##INTERFACE*>( \
obj->queryLocalInterface( \
I##INTERFACE::descriptor).get()); \
if (intr == NULL) { \
intr = new Bp##INTERFACE(obj); \
} \
} \
return intr; \
} \
I##INTERFACE::I##INTERFACE() { } \
I##INTERFACE::~I##INTERFACE() { } \而IServiceManager是IInterface的子类，自然而然就继承了这些宏定义的方法；同时，IServiceManager也明确了这两个宏定义的类型：
DECLARE_META_INTERFACE(ServiceManager);IMPLEMENT_META_INTERFACE(ServiceManager, "android.os.IServiceManager");//第二个变量会初始化一个descriptor成员变量，它跟进程间通信的合法性检测有关所以，我们就得出了这几个重要的函数声明与定义：
//#define DECLARE_META_INTERFACE(INTERFACE) \
static const android::String16 descriptor; \
static android::sp<IServiceManager> asInterface( \
const android::sp<android::IBinder>& obj); \
virtual const android::String16& getInterfaceDescriptor() const; \
IServiceManager(); \
virtual ~IServiceManager(); //#define IMPLEMENT_META_INTERFACE(INTERFACE, NAME) \
const android::String16 IServiceManager::descriptor(NAME); \
const android::String16& \
IServiceManager::getInterfaceDescriptor() const { \
return IServiceManager::descriptor; \
} \
android::sp<IServiceManager> IServiceManager::asInterface( \
const android::sp<android::IBinder>& obj) \
{ \
android::sp<IServiceManager> intr; \
if (obj != NULL) { \
intr = static_cast<IServiceManager*>( \
obj->queryLocalInterface( \
IServiceManager::descriptor).get()); \
if (intr == NULL) { \
intr = new BpServiceManager(obj); \
} \
} \
return intr; \
} \
IServiceManager::IServiceManager() { } \
IServiceManager::~IServiceManager() { } 我们初始化了descriptor成员，它描述了某个服务的名字；IServiceManager::asInterface()函数的定义也明确了，我们就接着看对它的调用。我们传入的参数是new BpBinder(0)实例对象，第一次调用时，我们会以BpBinder为参数创建一个BpServiceMananger对象。这里又冒出了一个BpXXX类，它又是什么呢？要搞清楚它的作用，我们首先要明确整个IServiceManager类的家族关系：
上图描述了IServiceManager类的整个家族图谱，同时它也是一个标准的使用Binder API搭建的一个使用Binder进行IPC通信的服务模板。此时我们的服务是ServiceManager。
因为Binder是基于客户端/服务端架构的，所以BpInterface、BnInterface分支分别代表了Client组件和Server组件(可以将它们归为Binder API的一部分)；BpServiceManager、BnServiceManager则是ServiceManage实现的Client组件和Server组件。
那我们再来看下BpServiceManager和BnServiceManager组件的实现：
// ----------------------------------------------------------------------
class BpServiceManager : public BpInterface<IServiceManager>
{
public:
BpServiceManager(const sp<IBinder>& impl)
: BpInterface<IServiceManager>(impl)
{
}
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());//首先写入IServiceManager的接口描述符，用于后面的CHECK_INTERFACE()合法性检测
data.writeString16(name);
remote()->transact(CHECK_SERVICE_TRANSACTION, data, &reply);
return reply.readStrongBinder();
}
virtual status_t addService(const String16& name, const sp<IBinder>& service,
bool allowIsolated)
{ //Parcel可以看做是一个数据存储类,都是将数据封装到对象中
Parcel data, reply;
data.writeInterfaceToken(IServiceManager::getInterfaceDescriptor());//首先写入IServiceManager的接口描述符，用于后面的CHECK_INTERFACE()合法性检测
data.writeString16(name);
data.writeStrongBinder(service);//服务实例
data.writeInt32(allowIsolated ? 1 : 0);
status_t err = remote()->transact(ADD_SERVICE_TRANSACTION, data, &reply);//remote()返回的就是new BpBinder(0)
return err == NO_ERROR ? reply.readExceptionCode() : err;
}
virtual Vector<String16> listServices()
{
Vector<String16> res;
int n = 0;
for (;;) {
Parcel data, reply;
data.writeInterfaceToken(IServiceManager::getInterfaceDescriptor());//首先写入IServiceManager的接口描述符，用于后面的CHECK_INTERFACE()合法性检测
data.writeInt32(n++);
status_t err = remote()->transact(LIST_SERVICES_TRANSACTION, data, &reply);
if (err != NO_ERROR)
break;
res.add(reply.readString16());
}
return res;
}
};status_t BnServiceManager::onTransact(
uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags)
{
//printf("ServiceManager received: "); data.print();
switch(code) {
case GET_SERVICE_TRANSACTION: {
CHECK_INTERFACE(IServiceManager, data, reply);//检查该进程间通信的合法性，判断是否是从IServiceManager Client组件发送过来的，主要依据就是
//IMPLEMENT_META_INTERFACE宏实现中初始化的descriptor成员值，如果判断为非法，则不会往下执行
String16 which = data.readString16();
sp<IBinder> b = const_cast<BnServiceManager*>(this)->getService(which);
reply->writeStrongBinder(b);
return NO_ERROR;
} break;
case CHECK_SERVICE_TRANSACTION: {
CHECK_INTERFACE(IServiceManager, data, reply);
String16 which = data.readString16();
sp<IBinder> b = const_cast<BnServiceManager*>(this)->checkService(which);
reply->writeStrongBinder(b);
return NO_ERROR;
} break;
case ADD_SERVICE_TRANSACTION: {
CHECK_INTERFACE(IServiceManager, data, reply);
String16 which = data.readString16();
sp<IBinder> b = data.readStrongBinder();
status_t err = addService(which, b);
reply->writeInt32(err);
return NO_ERROR;
} break;
case LIST_SERVICES_TRANSACTION: {
CHECK_INTERFACE(IServiceManager, data, reply);
Vector<String16> list = listServices();
const size_t N = list.size();
reply->writeInt32(N);
for (size_t i=0; i<N; i++) {
reply->writeString16(list[i]);
}
return NO_ERROR;
} break;
default:
return BBinder::onTransact(code, data, reply, flags);
}
}如果我们要搭建一个名为MyService的自定义服务，整体架构上我们只需在IServiceManager类的位置声明一个类IMyService进行替换，定义自己的业务方法并实现IInterface的宏方法，再实现我们自己的Client组件和Server组件(其中的实现细节都可以参考上面的BpServiceManager和BnServiceManager)，那IMyService服务的整个框架就搭成了。
在创建BpServiceManager时，我们传入了一个BpBinder实例；在Client组件侧，我们进行Binder通信使用的就是这个new BpBinder(0)实例；BpRefBase有一个IBinder类型的指针变量mRemote，BpBinder实例就是保存在这个变量中，用于后面的Binder通信。
分析到这，我们就知道了重要的两点：
- interface_cast<>()函数并不是正真的接口类型转换，而是用BpBinder(mHandle为0)实例创建了一个BpServiceManager对象，以此来创建了Client组件，并为它提供了与Server组件通信的桥梁.
- defaultServiceManager()函数返回的是一个ServiceManager client组件的代理，我们通过这个Client组件实例与Server组件通信，来获得ServiceManager的服务.
三、注册系统服务
MediaPlayerService::instantiate();//3、创建MediaPlayerService实例,通过ServiceManager注册服务在了解了Binder通信的基本原理后，我们在来看一个使用Binder进行服务注册的实例。ServiceManager是所有服务的总管，服务都要通过它注册到系统中。我们看一下MediaPlayerService服务注册的过程，来简单分析一下Binder通信的实际过程。
MediaPlayerService的构造过程如下：
void MediaPlayerService::instantiate() {
defaultServiceManager()->addService(
String16("media.player"), new MediaPlayerService());//调用addService()添加的服务实例对象是BnXXXYYY的子类，它是实现了业务接口的Server组件子类.
}addService()函数传入了一个MediaPlayerService实例对象，它实际是一个BnMediaPlayerService（MediaPlayerService的Server组件）的子类，并实现了IMeidaPlayerService中定义的所有业务方法。当我们调用ServiceManager的getService()获取MediaPlayerService的代理对象时，获取到的实际是一个代表代表该服务Server组件的类型为BpBinder的代理对象，我们还需调用IMediaPlayerService::asInterface()方法将该BpBinder实例转化成BpMediaPlayerService对象，供客户端调用MediaPlayerService提供的服务。
我们只关注服务的注册过程，而不着重考虑MediaPlayerService的创建。该方法中调用了addService()方法进行服务注册，并传入了一个服务名称字符串和服务实例对象；由此我们基本可以猜出，别处如果要获取某个服务，应该就是通过这个名称字符串来查找、获取的。我们已经知道defaultServiceManager()函数返回的是一个BpServiceManager对象，直接看它的addService()方法：
virtual status_t addService(const String16& name, const sp<IBinder>& service,
bool allowIsolated)
{ //Parcel可以看做是一个数据存储类,都是将数据封装到对象中
Parcel data, reply;
data.writeInterfaceToken(IServiceManager::getInterfaceDescriptor());
data.writeString16(name);
data.writeStrongBinder(service);//服务实例
data.writeInt32(allowIsolated ? 1 : 0);
status_t err = remote()->transact(ADD_SERVICE_TRANSACTION, data, &reply);//remote()返回的就是new BpBinder(0)
return err == NO_ERROR ? reply.readExceptionCode() : err;
}transact()函数的第一个参数，我们可以看做是一个操作代码，或者是某个操作函数的标号；Server组件可以根据这个code值，得悉我们需要它做什么处理。
直接看BpBinder中的处理：
status_t BpBinder::transact(
uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags)
{
// Once a binder has died, it will never come back to life.
if (mAlive) {
status_t status = IPCThreadState::self()->transact(
mHandle, code, data, reply, flags);//创建IPCThreadState实例，来进行真正的IPC通信
if (status == DEAD_OBJECT) mAlive = 0;
return status;
}
return DEAD_OBJECT;
}这里出现了一个新类型IPCThreadState，它是真正做事情的一个实体，其与Binder驱动真正交互信息；并且每个线程都会有一个IPCThreadState实例。从Client组件传过来的请求都是靠它处理的。我们看它的self()函数：
//主要就是创建IPCThreadState对象，并使用了同步机制
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;//调用构造函数,创建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;
}分析self()函数主要流程：当第一次调用self()函数时，gHaveTLS为false，因而不会进入第一个if判断中，也不会创建IPCThreadState。但是随后它进入第二个if判断，并启动TLS（Thread Local Storate，类似Java的ThreadLocal），然后返回到restart处新建一个IPCThreadState。当以后再被调用时，gHaveTLS为true：如果本地线程已经创建过IPCThreadState，那么pthread_getspecific就不为空：否则返回一个新建的IPCThreadLocal。
看它的构造函数做了哪些处理：
IPCThreadState::IPCThreadState()
: mProcess(ProcessState::self()),/*保存当前进程的ProcessState对象*/
mMyThreadId(gettid()),
mStrictModePolicy(0),
mLastTransactionBinderFlags(0)
{
pthread_setspecific(gTLS, this);
clearCaller();
mIn.setDataCapacity(256);//设置接手数据的缓冲大小为256
mOut.setDataCapacity(256);//设置发送数据的缓冲大小为256
}由前面的分析可知，每个进程只会有一个ProcessState实例，这里保存了一份在mProcess成员中；mIn、mOut是它的两个内部成员：
//可以把Parcel类看成是一个封装数据的类
Parcel mIn;//存储来自Binder设备的数据
Parcel mOut;//存储发送到Binder设备的数据分别对应着接收缓冲区和发送缓冲区，IPCThreadState构造过程中，给这两个缓冲区设置了缓冲大小。再分析IPCThreadState::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_LOG_TRANSACTIONS() {
TextOutput::Bundle _b(alog);
alog << "BC_TRANSACTION thr " << (void*)pthread_self() << " / hand "
<< handle << " / code " << TypeCode(code) << ": "
<< indent << data << dedent << endl;
}
if (err == NO_ERROR) {
LOG_ONEWAY(">>>> SEND from pid %d uid %d %s", getpid(), getuid(),
(flags & TF_ONE_WAY) == 0 ? "READ REPLY" : "ONE WAY");
err = writeTransactionData(BC_TRANSACTION, flags, handle, code, data, NULL);//整理数据,存入mOut对象中
}
if (err != NO_ERROR) {
if (reply) reply->setError(err);
return (mLastError = err);
}
if ((flags & TF_ONE_WAY) == 0) {//当前业务不是异步的
#if 0
if (code == 4) { // relayout
ALOGI(">>>>>> CALLING transaction 4");
} else {
ALOGI(">>>>>> CALLING transaction %d", code);
}
#endif
if (reply) {
err = waitForResponse(reply);//数据发送出去后，等待Binder驱动回应
} else {
Parcel fakeReply;
err = waitForResponse(&fakeReply);
}
#if 0
if (code == 4) { // relayout
ALOGI("<<<<<< RETURNING transaction 4");
} else {
ALOGI("<<<<<< RETURNING transaction %d", code);
}
#endif
IF_LOG_TRANSACTIONS() {
TextOutput::Bundle _b(alog);
alog << "BR_REPLY thr " << (void*)pthread_self() << " / hand "
<< handle << ": ";
if (reply) alog << indent << *reply << dedent << endl;
else alog << "(none requested)" << endl;
}
} else {//当前业务是异步的
err = waitForResponse(NULL, NULL);
}
return err;
}通过代码分析可知，IPCThreadState内部采用了发送数据、等待回应的处理模式，这应该是我们很熟悉的数据处理模型。对这两步我们分别来看，首先是数据封装：
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;//binder_transaction_data是一个数据对象，它由Binder驱动定义
tr.target.ptr = 0; /* Don't pass uninitialized stack data to a remote process */
tr.target.handle = handle;//BpBinder实例中的句柄值，这里是0
tr.code = code;//传给Serve组件的操作码，表示某种操作
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(binder_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 = reinterpret_cast<uintptr_t>(statusBuffer);
tr.offsets_size = 0;
tr.data.ptr.offsets = 0;
} else {
return (mLastError = err);
}
//将数据写到mOut Parcel对象中
mOut.writeInt32(cmd);
mOut.write(&tr, sizeof(tr));
return NO_ERROR;
}将数据封装到binder_transaction_data结构,并最终存储到mOut中，准备发送到内核中；它由Binder驱动定义。处理消息/等待回应的处理部分是：
status_t IPCThreadState::waitForResponse(Parcel *reply, status_t *acquireResult)
{
uint32_t cmd;
int32_t err;
while (1) {
if ((err=talkWithDriver()) < NO_ERROR) break;//我去，talkWithDriver()，多么实在的名字;其中会整理mOut中存储的数据信息，并最终发送给Binder驱动
err = mIn.errorCheck();//程序执行到此,说明已经收到了Binder驱动的回复,此时一般完成了相关的Binder请求
if (err < NO_ERROR) break;
if (mIn.dataAvail() == 0) continue;
cmd = (uint32_t)mIn.readInt32();
IF_LOG_COMMANDS() {
alog << "Processing waitForResponse Command: "
<< getReturnString(cmd) << endl;
}
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:
{
ALOG_ASSERT(acquireResult != NULL, "Unexpected brACQUIRE_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 binder_size_t*>(tr.data.ptr.offsets),
tr.offsets_size/sizeof(binder_size_t),
freeBuffer, this);
} else {
err = *reinterpret_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 binder_size_t*>(tr.data.ptr.offsets),
tr.offsets_size/sizeof(binder_size_t), this);
}
} else {
freeBuffer(NULL,
reinterpret_cast<const uint8_t*>(tr.data.ptr.buffer),
tr.data_size,
reinterpret_cast<const binder_size_t*>(tr.data.ptr.offsets),
tr.offsets_size/sizeof(binder_size_t), this);
continue;
}
}
goto finish;//跳出while循环,结束当前函数调用
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;
}IPCThreadState中保存了ProcessState实例对象，该对象又保存了Binder驱动设备文件的描述符mDriverFD；talkWithDriver()函数通过IO控制命令，向Binder设备文件发送mOut中的数据、读取驱动的回复指令保存到mIn中，然后执行该命令：
status_t IPCThreadState::talkWithDriver(bool doReceive)
{
if (mProcess->mDriverFD <= 0) {
return -EBADF;
}
binder_write_read bwr;//Binder驱动定义的数据交换结构,可以用来保存需要发送到驱动程序的数据,以及Binder驱动返回的回复数据
// Is the read buffer empty?
const bool needRead = mIn.dataPosition() >= mIn.dataSize();
// We don't want to write anything if we are still reading
// from data left in the input buffer and the caller
// has requested to read the next data.
const size_t outAvail = (!doReceive || needRead) ? mOut.dataSize() : 0;
//在bwr中填充需要write的内容和大小
bwr.write_size = outAvail;
bwr.write_buffer = (uintptr_t)mOut.data();
//在bwr中填写需要read的数据请求
// This is what we'll read.
if (doReceive && needRead) {
bwr.read_size = mIn.dataCapacity();
bwr.read_buffer = (uintptr_t)mIn.data();
} else {
bwr.read_size = 0;
bwr.read_buffer = 0;
}
IF_LOG_COMMANDS() {
TextOutput::Bundle _b(alog);
if (outAvail != 0) {
alog << "Sending commands to driver: " << indent;
const void* cmds = (const void*)bwr.write_buffer;
const void* end = ((const uint8_t*)cmds)+bwr.write_size;
alog << HexDump(cmds, bwr.write_size) << endl;
while (cmds < end) cmds = printCommand(alog, cmds);
alog << dedent;
}
alog << "Size of receive buffer: " << bwr.read_size
<< ", needRead: " << needRead << ", doReceive: " << doReceive << endl;
}
// Return immediately if there is nothing to do.
if ((bwr.write_size == 0) && (bwr.read_size == 0)) return NO_ERROR;//如果既不需要发送数据,又不需要读取数据;直接返回
bwr.write_consumed = 0;//write_consumed表明驱动消耗的数据量
bwr.read_consumed = 0;//read_consumed表明我们读取到的数据量
status_t err;
do {
IF_LOG_COMMANDS() {
alog << "About to read/write, write size = " << mOut.dataSize() << endl;
}
#if defined(__ANDROID__)
if (ioctl(mProcess->mDriverFD, BINDER_WRITE_READ, &bwr) >= 0)
err = NO_ERROR;
else
err = -errno;
#else
err = INVALID_OPERATION;
#endif
if (mProcess->mDriverFD <= 0) {
err = -EBADF;
}
IF_LOG_COMMANDS() {
alog << "Finished read/write, write size = " << mOut.dataSize() << endl;
}
} while (err == -EINTR);
IF_LOG_COMMANDS() {
alog << "Our err: " << (void*)(intptr_t)err << ", write consumed: "
<< bwr.write_consumed << " (of " << mOut.dataSize()
<< "), read consumed: " << bwr.read_consumed << endl;
}
if (err >= NO_ERROR) {//Parcel::mDataSize表明当前Parcel中已有的数据量
if (bwr.write_consumed > 0) {//如果驱动程序只是消耗了部分数据,则从mOut中移除那部分
if (bwr.write_consumed < mOut.dataSize())
mOut.remove(0, bwr.write_consumed);
else
mOut.setDataSize(0);//否则数据全部消耗完,数据设置为0
}
if (bwr.read_consumed > 0) {//从驱动读取到了数据,设置mIn中的数据量大小
mIn.setDataSize(bwr.read_consumed);
mIn.setDataPosition(0);//mDataPos是当前已处理过的数据量,此时为0
}
IF_LOG_COMMANDS() {
TextOutput::Bundle _b(alog);
alog << "Remaining data size: " << mOut.dataSize() << endl;
alog << "Received commands from driver: " << indent;
const void* cmds = mIn.data();
const void* end = mIn.data() + mIn.dataSize();
alog << HexDump(cmds, mIn.dataSize()) << endl;
while (cmds < end) cmds = printReturnCommand(alog, cmds);
alog << dedent;
}
return NO_ERROR;
}
return err;
}BBinder::transact()：
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;
}最后会将回复的指令传给它的子类调用onTransact()去处理，一般是BnYyyXxx或BnYyyXxx的子类型来实现onTransact()函数处理。
由于要分析Binder通信的实际过程需要了解Binder驱动本身的协议和设计过程，所以上述的分析就显得较为单薄了。有兴趣的同学可以深入了解下Binder驱动的设计及实现，我们这里只是简略的过了一下这个过程，没有深入分析；这里主要是侧重于使用Binder IPC通信机制，设计自己的服务。
PS：这里有一篇内核大神写的文章，详细地介绍了Binder驱动的原理及架构，有兴趣的同学可以看看：Android Bander设计与实现 - 设计篇
四、创建线程池
main_mediaserver中，服务注册完毕后， 还调用了两个函数：
ProcessState::self()->startThreadPool();//创建一个子线程，加入到线程池中，监听驱动是否有数据需要处理
IPCThreadState::self()->joinThreadPool();//将当前主线程加入到线程池中，监听驱动是否有数据需要处理来时刻监测来自驱动的请求：
void ProcessState::startThreadPool()
{
AutoMutex _l(mLock);
if (!mThreadPoolStarted) {//头一次调用，mThreadPoolStarted肯定为false
mThreadPoolStarted = true;//这里设置为true，防止重复启动线程池
spawnPooledThread(true);
}
}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());
}
}
class PoolThread : public Thread
{
public:
PoolThread(bool isMain)
: mIsMain(isMain)//isMain为TRUE
{
}
protected:
virtual bool threadLoop()
{
IPCThreadState::self()->joinThreadPool(mIsMain);//将线程加入到线程池中，用于处理驱动的数据请求;joinThreadPool()函数参数默认为TRUE
return false;
}
const bool mIsMain;
};void IPCThreadState::joinThreadPool(bool isMain)//isMain为true，表明这个线程是我们主动创建加入到线程池中的；否则，则表明这个线程是应Binder驱动的请求创建并加入到线程池的
{
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);//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();//内部调用talkWithDriver()监听驱动是否有数据需要处理，调用executeCommand()处理数据
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);//参数为FALSE，表示不再接收数据
}status_t IPCThreadState::getAndExecuteCommand()
{
status_t result;
int32_t cmd;
result = talkWithDriver();//向Binder驱动发送数据/接收reply数据
if (result >= NO_ERROR) {
size_t IN = mIn.dataAvail();//有没有可读数据
if (IN < sizeof(int32_t)) return result;
cmd = mIn.readInt32();//如果有,先读取一个cmd,看下是执行哪些操作
IF_LOG_COMMANDS() {
alog << "Processing top-level Command: "
<< getReturnString(cmd) << endl;
}
pthread_mutex_lock(&mProcess->mThreadCountLock);
mProcess->mExecutingThreadsCount++;
if (mProcess->mExecutingThreadsCount >= mProcess->mMaxThreads &&
mProcess->mStarvationStartTimeMs == 0) {
mProcess->mStarvationStartTimeMs = uptimeMillis();
}
pthread_mutex_unlock(&mProcess->mThreadCountLock);
result = executeCommand(cmd);//执行cmd
pthread_mutex_lock(&mProcess->mThreadCountLock);
mProcess->mExecutingThreadsCount--;
if (mProcess->mExecutingThreadsCount < mProcess->mMaxThreads &&
mProcess->mStarvationStartTimeMs != 0) {
int64_t starvationTimeMs = uptimeMillis() - mProcess->mStarvationStartTimeMs;
if (starvationTimeMs > 100) {
ALOGE("binder thread pool (%zu threads) starved for %" PRId64 " ms",
mProcess->mMaxThreads, starvationTimeMs);
}
mProcess->mStarvationStartTimeMs = 0;
}
pthread_cond_broadcast(&mProcess->mThreadCountDecrement);
pthread_mutex_unlock(&mProcess->mThreadCountLock);
// After executing the command, ensure that the thread is returned to the
// foreground cgroup before rejoining the pool. The driver takes care of
// restoring the priority, but doesn't do anything with cgroups so we
// need to take care of that here in userspace. Note that we do make
// sure to go in the foreground after executing a transaction, but
// there are other callbacks into user code that could have changed
// our group so we want to make absolutely sure it is put back.
set_sched_policy(mMyThreadId, SP_FOREGROUND);
}
return result;
}
ProcessState::self()->startThreadPool()主要就是创建了一个子线程用于接收、处理驱动的数据；最后，也将当前主线程加入到了线程池中，用于处理来自驱动的数据。这也表明Binder设备的通信是支持多线程技术的。
PS：Binder图示源文件下载
7746
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
