libbinder – Binder的Native实现
出于性能和代码统一性的角度考虑，Binder IPC并不Java和Native环境里各实现一次，而只是分别在不同的执行环境里提供使用的接口。使用Binder的Java代码，通过一些使用Binder的Java类之后，必须会走入到Native环境，将具体的分发的工作交给执行效率更高的Native代码。
最后这些接口都将被统一到一个统一的Binder交互环境，这一环境可以被称为Binder环境，而Binder IPC通信的过程，最终是在libbinder这样一种库文件里实现，最终会通过libbinder.so提供到Android系统里。
libbinder是由C++编写的，这便Binder传输在实现上也具备面向对象的特点，这种能力不仅给Java环境里的概念映射提供了方便，同时，也使在Native环境里也以面向对象的方向来使用Binder进行多种环境的互相通信提供了一种机制。于是，直接使用libbinder提供的编程接口，也可以编写Native环境里的System Service，由C++语言直接给Java语言提供服务端实现，这就得到了NativeService。
对于libbinder的使用，可以还是先从Java环境的Binder类开始分析。
Java环境如何访问到libbinder
在对于Java环境的Remote Service分析时，我们可以看到Binder在Java环境里的表现形式，除去只作为接口类的IInterface、IBinder，实际上在Android系统里，只会使用一个Binder基类来托管一个远程对象。从交互过程来看，使用某个Binder上托管的对象，都可以通过Binder之上搭建的IPC消息“桥”进行互通过，在实现上，一个通过继承的Binder的对象，分别将在发送端产生Proxy部分，而在接收端生成Stub部分。这样的Binder通过IInterface将对象暴露出来之后，发送端就可以使用这一引用找到Proxy，通过Proxy对象的transact()方法发送，而接收端对应的也使用同一IInterface，通过其上onTransact()回调接收。这样便构成了交互的能力。
但从Java环境里，实际上，我们根本不知道是如何处理完成的，我们跟踪所有的Binder相关的Java实现，也不看不出来。比如，我们在客户端经常会使用这样的方法来写Proxy端方法：
public IBinder getService(String name) throws RemoteException {
Parcel data = Parcel.obtain();
Parcel reply = Parcel.obtain();
data.writeInterfaceToken(IServiceManager.descriptor);
data.writeString(name);
mRemote.transact(GET_SERVICE_TRANSACTION, data, reply, 0);
IBinder binder = reply.readStrongBinder();
reply.recycle();
data.recycle();
return binder;
}
这种Proxy端的大部分代码，都可以在Java源代码里跟踪到其具体实现，但mRemote.transact()这行，则没有跟踪代码到具体是如何完成Binder通信的，我们前面只是说这一行便是送数据从BinderIPC通道上发送了出去，但并没有解释如何发送出去的。
这就会涉及到Binder的“跨界”实现，Binder这种特殊跨进程对象，实际上会映射到三层环境里，Kernel层，C/C++层，Java层。
如图：
其中Kernel的Binder驱动是提供跨进程实现的基础，能够支持访问Binder驱动只有C/C++层，Java层则必须要通过JNI访问到C/C++层。Java语言实现里并不会支持任何对于底层操作系统功能，因为这样势必会破坏Java在各平台之上直接运行能力，但Java语言又将访问几乎所有的操作系统功能，这些都得通过JNI整合到Java环境的。在JNI编程这种限制之下，如果Binder对象在Java环境里保持一份、C++环境一份，则将加大开发与维护的开销。于是在Android世界里，JNI层一般都很薄（甚至大部分还很难理解），尽可能将代码集中在C++层实现，这样保持了实现上的简洁，同时还收获了执行上的更高的效率。
我们的Binder.java实现了IBinder接口类，于是它拥有如下的结构：
public class Binder implements IBinder {
public static final native int getCallingPid();
public static final native int getCallingUid();
public static final int getOrigCallingUid();
private static final native int getOrigCallingUidNative();
public static final int getOrigCallingUser();
public static final native long clearCallingIdentity();
public static final native void restoreCallingIdentity(long token);
public static final native void setThreadStrictModePolicy(int policyMask);
public static final native int getThreadStrictModePolicy();
public static final native void flushPendingCommands();
public static final native void joinThreadPool();
public Binder() {
init();
...
}
public void attachInterface(IInterface owner, Stringdescriptor) ;
public String getInterfaceDescriptor();
public boolean pingBinder() ;
public boolean isBinderAlive();
public IInterface queryLocalInterface(Stringdescriptor);
protected boolean onTransact(int code, Parcel data, Parcel reply,
int flags) throws RemoteException;
public void dump(FileDescriptor fd, String[] args);
protected void dump(FileDescriptor fd, PrintWriter fout,String[] args);
public final boolean transact(int code, Parcel data, Parcel reply,
int flags) throws RemoteException;
public void linkToDeath(DeathRecipient recipient, int flags) ;
public boolean unlinkToDeath(DeathRecipient recipient, int flags);
protected void finalize() throws Throwable {
destroy();
}
private native final void init();
private native final void destroy();
private boolean execTransact(int code, int dataObj, int replyObj,
int flags) {
res = onTransact(code, data, reply,flags);
return res;
}
}
作为一个继承至IBinder接口的类，Binder这个类势必要实现所有的接口方法。但比较特殊的是Binder类的构造方法Binder()会调用到一个init()方法，析构方法finalize()会调用到一个destroy()方法，这两个方法并不是由Java实现，而是被标识为native的JNI实现的方法。另外需要注意到的是，Binder类本身实现了transact()与onTransact()收发两端的代码，但只是进程类的直接交互，并不会进程间的Binder交互。
另外，我们在同一Binder.java类里，还可以找到另一个BinderProxy类的定义，在这一类里会使用一个native标识的transact()方法。虽然在源代码里找不到任何使用这一类的地方，但从命名方式上来看，这一类应该会是被创建的默认的Proxy端。BinderProxy.java的定义如下：
final class BinderProxy implements IBinder {
public native boolean pingBinder();
public native boolean isBinderAlive();
public IInterface queryLocalInterface(Stringdescriptor);
public native String getInterfaceDescriptor() throws RemoteException;
public native boolean transact(int code, Parcel data, Parcel reply,
int flags) throws RemoteException;
public native void linkToDeath(DeathRecipient recipient,int flags)
throws RemoteException;
public native boolean unlinkToDeath(DeathRecipient recipient,int flags);
public void dump(FileDescriptor fd, String[] args) throws RemoteException;
public void dumpAsync(FileDescriptor fd, String[] args) throws RemoteException;
BinderProxy() {
mSelf = new WeakReference(this);
}
@Override
protected void finalize() throws Throwable {
destroy();
}
private native final void destroy();
private static final void sendDeathNotice(DeathRecipient recipient) {
recipient.binderDied();
}
final private WeakReference mSelf;
private int mObject;
private int mOrgue;
}
BinderProxy的transact会调用android_util_Binder.cpp
android_os_BinderProxy_transact
static jboolean android_os_BinderProxy_transact(JNIEnv* env, jobject obj,
jint code, jobject dataObj, jobject replyObj, jint flags)
{
...
//java Parcel转为native Parcel
Parcel* data = parcelForJavaObject(env, dataObj);
Parcel* reply = parcelForJavaObject(env, replyObj);
...
//gBinderProxyOffsets.mObject中保存的是new BpBinder(0)对象
IBinder* target = (IBinder*)
env->GetLongField(obj, gBinderProxyOffsets.mObject);
...
//此处便是BpBinder::transact(), 经过native层
status_t err = target->transact(code, *data, reply, flags);
...
return JNI_FALSE;
}
BpBinder::transact
BpBinder.cpp
status_t BpBinder::transact(
uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags)
{
if (mAlive) {
status_t status = IPCThreadState::self()->transact(
mHandle, code, data, reply, flags);
if (status == DEAD_OBJECT) mAlive = 0;
return status;
}
return DEAD_OBJECT;
}
IPCThreadState.transact
IPCThreadState.cpp
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);
}
...
// 默认情况下,都是采用非oneway的方式, 也就是需要等待服务端的返回结果
if ((flags & TF_ONE_WAY) == 0) {
if (reply) {
//等待回应事件
err = waitForResponse(reply);
}else {
Parcel fakeReply;
err = waitForResponse(&fakeReply);
}
} else {
err = waitForResponse(NULL, NULL);
}
return err;
}
IPCThreadState.waitForResponse
status_t IPCThreadState::waitForResponse(Parcel *reply, status_t *acquireResult)
{
int32_t cmd;
int32_t err;
while (1) {
if ((err=talkWithDriver()) < NO_ERROR) break;
...
cmd = mIn.readInt32();
switch (cmd) {
case BR_REPLY:
{
binder_transaction_data tr;
err = mIn.read(&tr, sizeof(tr));
if (reply) {
if ((tr.flags & TF_STATUS_CODE) == 0) {
//当reply对象回收时，则会调用freeBuffer来回收内存
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 {
...
}
}
}
case :...
}
}
...
return err;
}
binder_send_reply
servicemanager/binder.c
void binder_send_reply(struct binder_state *bs, struct binder_io *reply, binder_uintptr_t buffer_to_free, int status) {
struct {
uint32_t cmd_free;
binder_uintptr_t buffer;
uint32_t cmd_reply;
struct binder_transaction_data txn;
} __attribute__((packed)) data;
data.cmd_free = BC_FREE_BUFFER; //free buffer命令
data.buffer = buffer_to_free;
data.cmd_reply = BC_REPLY; // reply命令
data.txn.target.ptr = 0;
data.txn.cookie = 0;
data.txn.code = 0;
if (status) {
...
} else {=
data.txn.flags = 0;
data.txn.data_size = reply->data - reply->data0;
data.txn.offsets_size = ((char*) reply->offs) - ((char*) reply->offs0);
data.txn.data.ptr.buffer = (uintptr_t)reply->data0;
data.txn.data.ptr.offsets = (uintptr_t)reply->offs0;
}
//向Binder驱动通信
binder_write(bs, &data, sizeof(data));
}
binder_write将BC_FREE_BUFFER和BC_REPLY命令协议发送给驱动，进入驱动。binder_ioctl -> binder_ioctl_write_read -> binder_thread_write，由于是BC_REPLY命令协议，则进入binder_transaction， 该方法会向请求服务的线程Todo队列插入事务。
接下来，请求服务的进程在执行talkWithDriver的过程执行到binder_thread_read()，处理Todo队列的事务。
readStrongBinder
Parcel.java
eadStrongBinder的过程基本是writeStrongBinder逆过程。
static jobject android_os_Parcel_readStrongBinder(JNIEnv* env, jclass clazz, jlong nativePtr) {
Parcel* parcel = reinterpret_cast<Parcel*>(nativePtr);
if (parcel != NULL) {
return javaObjectForIBinder(env, parcel->readStrongBinder());
}
return NULL;
}
javaObjectForIBinder 将native层BpBinder对象转换为Java层BinderProxy对象。
readStrongBinder(C++)
Parcel.cpp
sp<IBinder> Parcel::readStrongBinder() const
{
sp<IBinder> val;
unflatten_binder(ProcessState::self(), *this, &val);
return val;
}
unflatten_binder
Parcel.cpp
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 = reinterpret_cast<IBinder*>(flat->cookie);
return finish_unflatten_binder(NULL, *flat, in);
case BINDER_TYPE_HANDLE:
//进入该分支
*out = proc->getStrongProxyForHandle(flat->handle);
//创建BpBinder对象
return finish_unflatten_binder(
static_cast<BpBinder*>(out->get()), *flat, in);
}
}
return BAD_TYPE;
}
getStrongProxyForHandle
ProcessState.cpp
//查找handle对应的资源项
handle_entry* e = lookupHandleLocked(handle);
if (e != NULL) {
IBinder* b = e->binder;
if (b == NULL || !e->refs->attemptIncWeak(this)) {
...
//当handle值所对应的IBinder不存在或弱引用无效时，则创建BpBinder对象
b = new BpBinder(handle);
e->binder = b;
if (b) e->refs = b->getWeakRefs();
result = b;
} else {
result.force_set(b);
e->refs->decWeak(this);
}
}
return result;
}
经过该方法，最终创建了指向Binder服务端的BpBinder代理对象。回到[小节4.8] 经过javaObjectForIBinder将native层BpBinder对象转换为Java层BinderProxy对象。 也就是说通过getService()最终获取了指向目标Binder服务端的代理对象BinderProxy。
对于Framework层实现，其基本功能都是通过frameworks/base/core/jni目录里，可以找到所有JNI实现。对应于Java环境里Binder实现，我们可以找到frameworks/base/core/jni/android_util_Binder.cpp。可以在这一JNI实现里看到，实际上所有基于Binder的交互，会通过javaObjectForIBinder()方法基于IBinder引用来创建或是找到对应的Java对象，通过ibinderForJavaObject()通过Java对象找到IBinder引用：
jobject javaObjectForIBinder(JNIEnv* env, constsp<IBinder>& val)
{
if (val == NULL) return NULL;
if(val->checkSubclass(&gBinderOffsets)) {
jobject object = static_cast<JavaBBinder*>(val.get())->object();
LOGDEATH("objectForBinder%p: it's our own %p!\n", val.get(), object);
return object;
}
AutoMutex _l(mProxyLock);
jobject object = (jobject)val->findObject(&gBinderProxyOffsets); //1
if (object != NULL) {
jobject res = env->CallObjectMethod(object,gWeakReferenceOffsets.mGet); //2
if(res != NULL) {
ALOGV("objectForBinder%p: found existing %p!\n", val.get(), res);
return res;
}
LOGDEATH("Proxyobject %p of IBinder %p no longer in working set!!!", object, val.get());
android_atomic_dec(&gNumProxyRefs);
val->detachObject(&gBinderProxyOffsets);
env->DeleteGlobalRef(object);
}
object = env->NewObject(gBinderProxyOffsets.mClass, gBinderProxyOffsets.mConstructor); //3
if (object != NULL) {
LOGDEATH("objectForBinder%p: created new proxy %p !\n", val.get(), object);
env->SetIntField(object, gBinderProxyOffsets.mObject, (int)val.get());
val->incStrong(object);
jobject refObject = env->NewGlobalRef(
env->GetObjectField(object,gBinderProxyOffsets.mSelf));
val->attachObject(&gBinderProxyOffsets, refObject,
jnienv_to_javavm(env),proxy_cleanup);
sp<DeathRecipientList> drl = new DeathRecipientList;
drl->incStrong((void*)javaObjectForIBinder);
env->SetIntField(object, gBinderProxyOffsets.mOrgue, reinterpret_cast<jint>(drl.get()));
android_atomic_inc(&gNumProxyRefs);
incRefsCreated(env);
}
return object;
}
在javaObjectForIBinder()方法里，
1.先会通过传入的IBinder引用，来查找是否已经存在所需要使用的BinderProxy对象；
2.如果存在，则通过BinderProxy的WeakReference引用，然后返回该引用；
3.如果没有，则在后面会创建这一BinderProxy对象。除去这几行，实际上其他代码都是在进行引用计数的维护。而在3代码的操作里之后，调用incRefsCreated()方法，于是又会索引到另一个BinderInternal对象，使用其ForceGc()方法。
而对于Binder类本身，我们也会看到其init()的native实现，
static void android_os_Binder_init(JNIEnv* env, jobject obj)
{
JavaBBinderHolder* jbh = new JavaBBinderHolder();
if (jbh == NULL) {
jniThrowException(env, "java/lang/OutOfMemoryError",NULL);
return;
}
jbh->incStrong((void*)android_os_Binder_init);
env->SetIntField(obj, gBinderOffsets.mObject, (int)jbh);
}
有了这三部分的代码，我们的Java环境里的Binder，便与Native态的Binder结合到一起了，最终会得到如下所示的即有Java，也有C++代码的复杂关系：
在Java环境里，某个Binder对象的IBinder引用，则可以通过javaObjectForIBinder()创建或是取得某个已有的BinderProxy对象，BinderProxy对象的transact()是以JNI的方式实现的，于是有可能进一步通过它来构建底层的Binder交互。同时，Java环境里的Binder对象，会通过init()方法来为该对象创建JavaBBinderHolder，从而使自己被映射到Native环境里的Binder（在Native环境里叫BBinder），最终将两个环境里的Binder对象被映射到一起。
在这时不光需要完成Binder的实现由Java层转入Native层，更重要是需要一种机制，可以使Native态发生的变动，再回到Java层。Java语言环境本身提供自动垃圾回收机制，我们需要将Binder对象能够自动地被Java的GC所管理，同时，我们大部分使用Binder通信的代码还是Java写的，我们需要能够在合适的状态点回调到Javag玩意。JavaBBinderHolder本身只是JavaBBinder的包装类，在JavaBBinder之上再包装上引用计数（继承Refbase），于是同时使用一个能处理GC的BinderInternal便可以自动处理。另外，值得注意的是Java环境里的Binder类，Binder类提供一个不常见的private的execTransact()方法，这其实就是Binder环境的回调，JNI代码在执行Native环境的onTransact()方法时，会通过回调Java环境里的execTransact()方法，从而回调到Java里实现的onTransact()方法。于是，Java环境里的Binder，实际上只是一层封装，直正的Binder通讯是由底层来完成的，由Android系统里使用C++编写的一个libBinder库来完成，如下所示：
ibbinder的构成
实现了从Java环境到Native实现的Binder环境之间的交互之后，还需要可以在多个范围内完成对象的映射。Binder这个概念在Java环境里大量使用了面向对象的重构技巧，尽可能实现通用操作，而只预留出来需要定制的接口。于是，我们为了支持给Java环境提供的灵活功能，在Native层的Binder，也需要具备面向对象的能力。综合这两种需求，我们得到了frameworks/base/libs/binder目录里，用C++实现的libbinder（在Android 4.1里，为了更好地兼容NDK被移到frameworks/native/libs/binder）。当然，C++跟Java的分析方式则有不同，C++的头文件与实现，跟C一样，是分开的，从头文件更容易分析其构成，与实现对应，一般我们都可以在同级目录里找到头文件，libbinder的头文件位于frameworks/base/include/binder。
出于跟Java层代码进行不同语言空间的映射之用，C++实现的Binder库也会与Java环境里的Binder概念有着互通之处。
IInterface.h，定义IInterface接口类。与Java的IInterface接口类对应，用于通过统一的asBinder()接口方法返回IBinder引用。但与Java环境不同，C++环境里需要提供Binder通信实现，于是IInterface类，在内部被进一步拆分成BpInterface（Proxy端对象）、BnInterface（Stub端对象）两个模板，从而使用不同模板参数，可以使用对同一IInterface接口的访问，得到不同功能实现。
IBinder.h，定义IBinder接口类。与Java环境的IBinder对应，提供Binder引用，并定义Binder对象所应实现的方法。跟Java环境一样，IBinder对象会是分别引用到Proxy对象或是Stub对象，通过localBinder()方法返回Binder Stub端的BBinder对象，或是通过remoteBinder()方法返回Binder Proxy端的BpBinder对象。但与Java环境不同，C++环境里没有标准的自动化内存管理（GabageCollection），于是会内置一个DeathRecipient类，通过Refbase来进行垃圾管理，就像我们前面分析JNI部分，这一管理内容，最终会通过BinderInternal类回调到Java的自动化内存管理。
Binder.h，定义BBinder类与BpRefBase类。BBinder类与Java环境里的Binder类对应，是Binder的Stub实现，通过onTransact()回调方法接收与处理Binder事件。但它更属于Binder通讯的基础类，并不会被直接使用，系统只会通过BBinder类的派生类进行通信，所以它的类名是BBinder，Base Binder的意思。BBinder里维护了Extras对象，可在线程完全情况下访问到BpBinder里实现的objectManager，从而自动管理Proxy对象。BpRefBase类，用于通过IBinder引用来找到合适的BpBinder类，进一步被应用于BpInterface模板类。
BpBinder.h，定义BpBinder类。与Java环境里的Stub.Proxy对象对应，是Binder的Proxy端实现。作为Proxy端，又是Binder最底层的封装，这一类的本质作用只是提供一个transact()方法，从而给上层封装的RPC请求提供最终的Binder通信接口。与此同时，BpBinder创建的对象，必须与BBinder加入绑定，于是也提供objectManager类，用于提供Proxy端的对象管理，但与BBinder使用单一objectManager对象不同，这里存在多重映射的可能性，在Proxy对象里的objectManager会以队列形式被管理。
Parcel.h，定义Parcel类。虽然概念上与Java里实现序列化的Parcel类是对应的，也提供同样的操作方法。但在实现上，Native环境里的Parcel是提供Java环境里的Parcel概念的一种基础，所有的Parcel的read|write_*()系列的方法，底层全是由Native代码来实现具体的读写操作。这也是基于Binder的RPC操作的基础，我们进行进程间的方法调用时，都会基于Parcel来完成参数与返回值的序列化，然后再通过Binder进行传输。最终，所有通过实现Parcelable方法得到的对象，都将在传递时被映射到Binder驱动所需要的一种平滑过的对象结构，被存入一种叫flat_binder_object的变量里，从而可以以线性空间的方式保存并传输。
上面的这些基本类，便构成了Binder通信的基础。通过这些基本类，不但完成了Java环境与Binder的Native在实现上的概念统一，两种环境里的对象都有一一对应的关系。而且这些概念上也通过JNI被关联到一起，Java环境里的Binder最终会通过底层的Binder类来进行操作，而底层Binder对象，则会通过RefBase嵌入到Java环境的垃圾回收池。libBinder便拥有了如下所示的构成：
但此时，我们还是没有解决最核心的问题，这些在Native环境里进行Binder通信封装的类，如何操作Binder驱动来达到通信的目的。在libbinder的实现里，我们都会通过两个专门的类来完成真正的Binder消息的读写操作，ProcessState与IPCThreadState，因为此时已经是全系统唯一的概念了，则不会提供Java代码的映射，只由C++代码来实现。
ProcessState.h，定义ProcessState类。正如这个类的名字所表述的，这个类的作用就是维护与IPC相关的进程状态，对于任一使用Binder的进程而言，进程空间里只会有一个ProcessState对象。Binder通信与其他的IPC机制不同，其他的IPC基本上都是基于文件描述符fd来标识出不同的通信过程，而Binder在整个传输过程里都是以进程为单位来进行传输。Binder通信在传输时虽然也会使用/dev/binder的文件描述符，但只是用于与驱动通信，IPC消息只以进程为单位进行传输，并且也可以通过binder知道进程是否还处于存活状态，从而可以实现整个系统的垃圾回收。
IPCThreadState.h，定义类IPCThreadState。这个类描述以线程为基础的IPC传输状态，Binder通信的读写过程便在这个类里完成。在Binder提供底层的跨进程通信能力之后，基于其上建立通信过程，可以以单线程循环方式完成，也可以使用多线程。如果使用单线程，在处理某个大数据量的消息的收发过程里容易发生阻塞，数据传递的效率降低，同时也会使底层的Binder驱动承载的压力变大。如果使用简单多线程，有线程则创建线程加以接收处理，则又产生线程维护开销，并引发多线程编程失控。在IPCThreadState类的实现里，是以线程池的方式来维护Binder的通信请求，对于/dev/binder设备的读写请求都是通过线程方式并行执行的IPCThreadState的线程对象来完成，但并非总是创建，而只是通过IPCThreadState的self()方法取回一个合适的实例来进行处理。
多了这两个与Binder进行通信的基本类之后，libbinder的构成便进一步被扩大，但此时已经可以完成Binder通信，并提供对上层的封装功能了。于是，从Binder通信的功能上来看，libbinder的构成实际上是如下如示的样子：
在libbinder的构成里，ProcessState，只是一个用于描述进程状态的类，于是并不直接跟Binder通信。但Binder驱动会在ProcessState对象里被打开，对于进程来说，Binder的使用实例是唯一的，被保存到mDriverFD里。同时，由Binder派生出来的远程对象，也会在ProcessState里通过getContextObject()和setContextObject()来维护。最后，对于进程当前的线程池环境，也是通过ProcessState对象来维护。
至于IPCThreadState类，则实现上会复杂一些，所有的Binder命令，最终都会通过一个IPCThreadState来进行处理。一个IPCThreadState对象，就是通过talkWitheDriver()方法来循环地操作ProcessState的mDriverFD，完成Binder驱动的实际读写操作。所有命令的发送操作，都是通过IPCThreadState的transact()方法来完成，而Binder驱动返回过来的消息，会通过executeCommand()回调到具体的onTransact()实现。
综合libbinder的实现，与Java环境的Remote Service，最终得到的Binder通信便是如下的流程：
Remote Service的访问者，也就是应用程序进程，会使用Stub.Proxy对象来调用transact()方法，而Proxy对象本身会在使用里创建一个BinderProxy对象，并调用这一BinderProxy对象的transact()方法。而Java环境里的BinderProxy对象的使用，会在libbinder里创建BpBinder与之对应，BinderProxy的transact()本身是使用JNI实现的，会调用BpBinder的transact()实现。这时，在BpBinder的transact()方法里，Binder命令便会经由IPCThreadState对象的transact()、waiteForResponse()、talkWithDriver()，写入当当前进程维护的mDriverFD，也就是Binder驱动里。
Remote Service则是Binder命令的接收与处理者，会一直在自己的ProcessState对象维护的mDriverFD上监听，Remote Service则都使用joinThreadPool()来创建监听Binder的线程。当Binder命令过来之后，监听的IPCThreadState对象会从talkWithDriver()方法里返回，读回相应的命令，然后调用executeCommand()方便处理这一命令。在executeCommand()方法里，当接收到交互请求（命令是BR_TRANSACTION）时，会调用Binder命令里指定BBinder对象的transact()方法。此时，因为Java环境里Binder对象，在JNI实现里会自动创建JavaBBinder类，于是BBinder对象的transact()方法，会通过JavaBBinder的onTransact()回调到Java环境里Binder对象的execTransact()方法，然后再调用到最终的RemoteService里实现的onTransact()方法。
当然，前面通过aidl编程也可以看出，虽然底层实现上如此复杂，九转十八弯才得到了这样的远程调用，但对于编程使用却异常简单，只是需要简单地使用一个Stub对象即可，所有的底层操作都将系统封装掉了，在aidl编程时甚至都不知道有Proxy对象，全由aidl自动生成。这便是Android的优点之一，无论底层多么复杂，但上层都是很简单的接口。而对于系统设计的一个可借鉴之处是，当我们把这套逻辑封装得非常易于编程时，对于底层的改进也将更加平滑，因为用户并不知道底层发生了怎样的变动，仍使用同样的编程方式进行调用。
这种方式，绕来绕去的，不太容易理解，Java环境与Native环境的互相穿越，也容易迷失方向。这是否有必要呢？如果没有Java，这种复杂逻辑是没有理由的，复杂便会效率低下。而且在整个Binder概念的实现上，大量使用面向对象技巧，即便是在C++实现的部分，也会通过虚拟继承来实现访问上的灵活性，在嵌入式环境里使用虚拟继承来进行动态访问，本身就是低效之源。但是，因为有了Java语言的需求，这样设计就很合理了。通过Binder，不但完成了Binder在Java环境与Native环境的成功映射，在Java环境的Binder概念之下通过机器代码实现了高效安全的Binder通信，更进一步的好处是，Binder被托管到了Java虚拟机的自动化垃圾回收机制里。假设Android并没有选择Java语言，而是选择了另一种支持垃圾回收的编程语言，我们只需要简单地将Java态的绑定，也就是Binder概念相关的Java类、JNI实现实现一次即可。
至此，基本上libbinder的基本功能便已经完备了，可以支持上层的基于Binder传递对象、使用IBinder引用来进行调用远程进程中的方法、以及通过Parcel来传递复杂对象的功能。
除了基本功能之外，libbinder里还会实现一些C++环境里的辅助类：
实现在C++环境里的ServiceManager类，从而在C++环境里可以直接调用getService()方法取得其他System Service
实现IMemory接口方法，从而可以灵活实现多种内存共享方式
libbinder里实现的ServiceManager
ServiceManager本身就是Native Service的一个典型的例子，Java环境里编程会使用ServiceManager，调用到SystemServer里实现的系统功能。而整个Android系统各个组成部分也会不停地进行交互，Native Service之间也会进行相互调用。我们可以看到servicemanager是一个C语言写的独立进程，Stub端的功能便会由这一servicemanager进程来完成，于是从Binder领域来说，所有以面向对象实现的ServiceManager类，只需要提供Proxy功能。
以Native Service方式来提供ServiceManager功能，则是一个跟我们的前面的ITask很类似一种实现。出于代码完整性角度考虑，在IServiceManager里也提供了BnServiceManager的实现，但由于没有将这一Service加入到IPCThreadState里，于是只是空的实现。
在frameworks/native/include/binder/IServiceManager.h定义了以Native方式实现的Service，
namespace android {
class IServiceManager: publicIInterface 1
{
public:
DECLARE_META_INTERFACE(ServiceManager); 2
virtual sp<IBinder> getService( const String16& name) const = 0; 3
virtual sp<IBinder> checkService( const String16& name) const = 0;
virtual status_t addService( const String16&name,
constsp<IBinder>& service,
bool allowIsolated =false) = 0;
virtual Vector<String16> listServices() =0;
enum { 4
GET_SERVICE_TRANSACTION=
IBinder::FIRST_CALL_TRANSACTION,
CHECK_SERVICE_TRANSACTION,
ADD_SERVICE_TRANSACTION,
LIST_SERVICES_TRANSACTION,
};
};
sp<IServiceManager> defaultServiceManager();
template<typename INTERFACE>
status_t getService(const String16& name, sp<INTERFACE>* outService) 5
{
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;
}
boolcheckCallingPermission(const String16& permission); 6
boolcheckCallingPermission(const String16& permission,
int32_t*outPid, int32_t* outUid);
bool checkPermission(const String16&permission, pid_t pid, uid_t uid);
class BnServiceManager: publicBnInterface<IServiceManager> 7
{
public:
virtual status_t onTransact(uint32_t code,
const Parcel&data,
Parcel*reply,
uint32_t flags = 0);
};
}; // namespace android
IServiceManager这一接口类，继承自IInterface
进入IServiceManager的类定义部分，就会通过DECLARE_META_INTERFACE来完成通用部分的定义。
定义所需要的接口方法，所有接口方法必然会是纯虚方法。
定义IServiceManager所支持的Binder命令，跟Java环境里的ServiceManager类一致，支持四种命令，分别对应到第3步里定义的四个接口方法。并且跟其他Native Service一样，Binder命令都是从IBinder::FIRST_CALL_TRANSACTION开始。
这里使用了C++的多态，一般的getService()是直接通过一个Service的名字来取回一个IBinder实现，通过返回的IBinder引用是否为NULL来判断是否成功完成调用。而在这里定义的getService()方法，进一步封装了一次，可以返回一个调用的状态值，并且会直接通过interface_cast()宏来确保Proxy对象被创建。
checkCallingPermission()、checkPermission()相当于IServiceManager里提供的一层Proxy功能，这部分的功能是由IPermissionController.cpp来提供，而这部分功能并不适合暴露出来，于是会透过IServiceManager将权限检测功能提供出来。
出于实现上的统一性考虑，在这里也会提供BnServiceManager的实现。
有了这个IServiceManager接口类的定义，在IServiceManager实现就跟
sp<IServiceManager>defaultServiceManager() 1
{
if(gDefaultServiceManager != NULL) return gDefaultServiceManager;
{
AutoMutex _l(gDefaultServiceManagerLock);
if(gDefaultServiceManager == NULL) {
gDefaultServiceManager = interface_cast<IServiceManager>(
ProcessState::self()->getContextObject(NULL)); 2
}
}
returngDefaultServiceManager;
}
…
class BpServiceManager : public BpInterface<IServiceManager> 3
{
public:
BpServiceManager(const sp<IBinder>& impl)
: BpInterface<IServiceManager>(impl)
{
}
…
virtualsp<IBinder> checkService( const String16& name) const 4
{
Parcel data, reply;
data.writeInterfaceToken(IServiceManager::getInterfaceDescriptor());
data.writeString16(name);
remote()->transact(CHECK_SERVICE_TRANSACTION, data, &reply);
return reply.readStrongBinder();
}
…
IMPLEMENT_META_INTERFACE(ServiceManager, "android.os.IServiceManager"); 5
…
}
defaultServiceManager()，每个进程都需要通过getService()来取回RemoteService，所以必然需要调用到defaultServiceManager()来取回一个IServiceManager的Proxy对象。
在defaultServiceManager()里使用了Singleton模式，对于某个进程只会创建一个唯一的IServiceManager的Proxy实例。值得注意的是getContextObject()会通过一个handle变量来取得一个IBinder引用，然后再通过interface_cast()转换成IServiceManager接口类。getContextObject()方法的参数会是整型的handle，handle的值会随着不同Service的引用，每使用一个，handle的值便会加1，这样每个进程空间会拥有各自不同的handle值，使得基于Binder通信的安全变高，不容易简单地抓取Binder命令来分析程序的行为。这里使用的handle值为0，于是对于每个进程，handle为0的Service都会是IServiceManager。
实现IServiceManager的Proxy类，于是实现上便会继承自BpInterface的模板。
跟Java环境的ServiceManager一致，getService()内部也会是调用checkService()来取得Service的IBinder引用。所有的Proxy端方法，都使用统一的模式，就是将调用的方法转换成Binder命令，然后发送出去。
IMPLEMENT_META_INTERFACE()宏，会实现通用部分的代码，同时也会设定特定的descriptor。
通过这样的方式，最终就得到了简单而且高效的，并且与ServiceManager.java实现并行的ServiceManager的Proxy端。
通过libbinder灵活使用内存
在我们传统的Unix/Linux编程环境里，为了保持进程之间的互相独立性，都是用户进程空间里的内容互相独立，使用不同的内存映射，内核空间便会共享同一份内容，使用同一份内存映射。这样的情况下，如果需要在进程之间传递数据，必然是先通过copy_from_user()系统调用从用户空间先拷贝到内核空间，然后再在另一个进程空间里通过copy_from_user()系统调用从内核空间拷贝回用户空间。这种方式就保证了不同进程可以传递数据，同时进程之间互相不会有干扰，任一进程出错，对另一进程完全没有影响，因为进程空间本身是独立的。在Linux内核之上，任何IPC机制都采用了这种实现，Binder也不例外。比如Remote Service，在任一交互过程里，数据始终会有三份，内核一份、进程空间各一份拷贝：
但这种方式比较低效，多次内存拷贝会造成内存的开销，同时由于copy_from_user()和copy_to_user()系统调用，会造成计算上的开销。假设已经确定内存的传递时一方只读，此时就可以改进内存的使用，在发生内存写请求的进程里，仍然使用copy_from_user()，而读取内存的部分，则不再使用copy_to_user()，而是通过mmap()直接映射一段内存到自己的进程空间内，这样只会发生一次内存拷贝。
最后，还有一种可能性，所有进程都共享同一块内存区域，不管内存里保存的内容发生了任何改变，所有进程都应该见得到。这种使用在Linux编程里也很普遍，但一般只用于驱动访问，很少被用于IPC进程间通信。这种使用情境下，如果所共享的页源自于用户空间，则难以保证在物理分配上的连续性，更重要的是不要求，如果承载内存页的进程挂掉，则所有涉及交互的进程都不得不挂掉，所以内存页要在内核空间里。同时，在内核态则需要有一定的实体存放这样的页面映射引用，IPC机制并不支持这样的页面映射管理。但Binder IPC不受限于此，Binder驱动实际上只是一个基于内存映射的虚拟字符设备，于是可以天然地在传输过程里使用内存页的映射功能。于是，又有了第三种使用内存页的方式，就是灵活地内存映射功能：
如上所示，内存页实际上是在使用时通过内核态来分配的，内存只在内核态有一份拷贝，所有的用户进程都只通过mmap()系统调用来引用这样的页。但是这样的方式会引发内存管理上的混乱，内核空间的页面在分配上的优先级要远大于用户空间，而且必须以连续物理页来分配，也容易造成内存使用上的失控。于是，Android在原有的内存管理机制上拓展出来两种“特殊”内存管理机制，准确地说是共享内存的实现机制，pmem和ashmem，这两种机制可以将内核里内存分配机制暴露到用户态来操作。Pmem是一种预留出来一段物理内存供用户态分配连续物理内存来使用，而ashmem则是Android对原有的Shared Memory（共享内存机制）的一种改进，这两种机制我们后台再详细。虽然这种共享内存方式本身跟Binder机制没有关系的，并非由Binder IPC来实现这样共享功能，但得益于Binder通信与Java垃圾回收的绑定，于是Binder为这种内存共享提供了自动的内存管理功能。
IMemory.h，定义两个基于IBinder的远程类，生成两个远程接口类，IMemory与IMemoryHeap，分别用于使用内存和分配内存。这是Android在系统设计上灵活性的一种体现，我们也知道IBinder是提供远程引用的，对于内存使用两个基于IBinder的接口类，则意味着申请内存与分配内存可分别由单独进程来提供。试想一下，比如一个照相机应用程序，通过IMemory接口向mediaserver进程申请内存，但在mediaserver进程里发出内存申请之后，则会由负责显示的surfaceflinger来负责分配所需要的空间。这样复杂的供给关系，只取决于代码如何实现，也不受限于进程空间，而且不会影响效率，因为无论多少进程交互，在底层实际上还是只有一份拷贝。当然，同时使用IMemory与IMemoryHeap远程接口，并不一定要发生在多进程环境里，当两个接口都在同一进程空间里提供Proxy与Stub时，实际上只是多绕了一层Binder IPC，但还是当前进程空间内，也不影响效率。另外，这两个接口类，出于性能的考虑，会是以Native Service的方式来提供。
MemoryDealer.h，定义一个默认的分配内存的MemoryDealer类。在这一类里内置了一个最简化的列表式内存管理算法，这样需要提供内存分配部分，可以使用这一类来创建内存空间，并通过IMemoryHeap共享出去。
MemoryBase.h，通过MemoryBase类来提供IMemory接口类的Stub端实现。MemoryBase会通过getMemory()的远程方法来返回一个IMemoryHeap实例，同时也会是MemoryDealer的操作对象。命名为Base，就说明这会是该类型的基类定义，如果有其他使用IMemory接口的地方可以继承该类，再派出生新的特性。
MemoryHeapBase.h，通过MemoryHeapBase类来实现IMemoryHeap接口类的Stub端。在这个类里实现可用于远程共享的堆空间分配，如果不用于远程共享，则直接使用malloc()即可，IMemoryHeap接口相当于是远程实现的malloc()，new()等操作方法。在这一方法里会定义一些基本的Heap分配操作，根据不同的应用情境分配不同类型的内存（基于文件的、匿名空间等）。
MemoryHeapPmem.h，实现基于Pmem机制并实现IMemoryHeap接口的MemoryHeapHmem类。如果有特殊内存堆的使用需求，则可以通过MemoryHeadBase类派生出新的MemoryHead类，比如在MemoryHeapPmem。所有的的特殊
最终，针对内存的分配与使用，在底层也会灵活地组织起来，在内存使用“食物链”最上流的使用内存的部分，只需要调用MemoryBase对象的getMemory()接口方法，这一请求会通过IMemory接口转发到能处理该请求的另一进程。而getMemory()又会返回一个IMemoryHeap引用，这样会自动地又将请求分发到可以处理这一IMemoryHeap分配的进程来处理内存分配。于是，在libbinder实现里针对跨进程的内存使用与分配，又可以得到如下的关系图：
有了IMemory这样的接口类之后，在Android系统里就可以更灵活地定义不同的内存使用方法。