Binder
binder_init
1、为binder设备分配内存空间
2、注册到binder驱动
3、返回注册的binder
binder_open
1、在进程创建的时候，执行binder_open,会new一个ProcessState::open_driver -> binder_open() 为binder_proc 分配内存空间；
2、将binder信息添加进binder_proc;
3、增加一个filp指针指向binder_proc,方便后面的查找；
4、将binder_proc放入到binder_procs全局列表中去。
binder_mmap
1、通过filp拿到binder_proc去mmap，保证映射的内存大小不超过4M；
2、将alloc中的buffer指针指向 这块虚拟内存，为alloc分配一块物理内存，由于这个buffer指针是binder_proc中的成员，所以也其实是物理内存的指针；
3、如果是异步的内存减半；
4、将用户空间的vma指针关联到alloc。（binder_alloc_set_vma(alloc,vma)）
binder_ioctl
1、通过filp去进行读写操作，copy_from_user 将用户空间数据 ubuf 拷贝到 bwr
2、写入数据大于0，执行写入方法，读取数据大于0，执行读取方法
ServiceManager
1、ServiceManager是由init进程通过解析init.rc文件而创建的，其所对应的可执行程序servicemanager，所对应的源文件是service_manager.c，进程名为servicemanager。
2、它主要做三件事
- 打开binder驱动 ProcessState::initWithDriver
- 成为上下文的管理者，这样所有的进程多可以获取到它 ps->becomeContextManager handle 为0的引用
- 循环等待服务的注册 BinderCallback::setupTo(looper)
3、客户端有ServiceManager的binder_ref也就是0号引用handle，客户端的各种服务如AMS,可以通过这个引用去内核中找对应的服务的binder驱动，然后通过ServiceManager将服务返回给客户端。
Binder通信中各阶层的代理对象
- 应用层: ServiceManagerProxy 通过asInterface去拿到的
- Framework层: BinderProxy
- native层: BpBinder 通过getStrongProxyForHandle(0)->javaObjectForIBinder,实际就是创建了 BpBinder 和 BinderProxy，并将二者关联，然后返回 BinderProxy 对象。
- 内核层代理为：binder_ref 结构体
- 内核层实体为：binder_node 结构体
Binder通信中各阶层的binder实体对象
- 应用层:Binder.java
- native层：BBinder
注册服务
我们以AMS注册为例，在 systemserver 启动时，就会调用 AMS 的 setSystemProcess 方法，AMS就是通过该方法向servicemanager注册的。如果对 systemserver启动还不了解的同学，可以先去学习 systemserver 的启动流程。
// frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java
public void setSystemProcess() {
... ...
// 将 AMS 注册到 servicemanager 中
ServiceManager.addService(Context.ACTIVITY_SERVICE, this, /* allowIsolated= */ true,
... ...
}
// frameworks/base/core/java/android/os/ServiceManager.java
public static void addService(String name, IBinder service, boolean allowIsolated,
int dumpPriority) {
getIServiceManager().addService(name, service, allowIsolated, dumpPriority);
... ...
}
getIServiceManager 我们前一节课已经分析了，可以理解为执行了 new ServiceManagerProxy(参数为BinderProxy对象);
我们在看 addService 方法前，我们先来看下 ServiceManagerProxy 的构造方法做了什么。
// frameworks/base/core/java/android/os/ServiceManagerNative.java
public ServiceManagerProxy(IBinder remote) {
mRemote = remote;
mServiceManager = IServiceManager.Stub.asInterface(remote);
}
可以看到这个地方使用了 AIDL，根据AIDL的理解还是可以知道，实际就是返回了一个Proxy对象，然后 remote = BinderProxy。
接着我们再来看 addService 方法：
// frameworks/base/core/java/android/os/ServiceManagerNative.java
public void addService(String name, IBinder service, boolean allowIsolated, int dumpPriority)
throws RemoteException {
mServiceManager.addService(name, service, allowIsolated, dumpPriority);
}
这个方法就会执行到 AIDL对应的 Proxy.addService 方法，根据我们前面介绍的AIDL，我们可以知道生成的AIDL代码，如下：
这个方法里面就会执行 mRemote.transact，也就是执行 BinderProxy.transact。所以接着我们来分析下 BinderProxy.transact 方法。
public void addService(String name, IBinder service, boolean allowIsolated, int dumpPriority) throws RemoteException {
Parcel data = Parcel.obtain();
Parcel reply = Parcel.obtain();
... ...
// 此处 service == AMS
data.writeStrongBinder(service);
... ...
// 实际就是执行 BinderProxy.transact
mRemote.transact(ADD_SERVICE_TRANSACTION, data, reply, 0);
... ...
}
接下来我们分别分析 data.writeStrongBinder(service); 和 mRemote.transact 这两个方法。
- 1.data.writeStrongBinder
这个方法实际就是调用一个native方法，最终进入jni层，代码如下：
// frameworks/base/core/jni/android_os_Parcel.cpp
static void android_os_Parcel_writeStrongBinder(JNIEnv* env, jclass clazz, jlong nativePtr, jobject object)
{
... ...
// 创建 JavaBBinder 对象，并保存在本地
// 下面分别介绍这个方法和参数
const status_t err = parcel->writeStrongBinder(ibinderForJavaObject(env, object));
... ...
}
- 参数：ibinderForJavaObject
这个方法的作用是创建 JavaBBinder 对象
// frameworks/base/core/jni/android_util_Binder.cpp
sp<IBinder> ibinderForJavaObject(JNIEnv* env, jobject obj)
{
... ...
// 获取 JavaBBinderHolder 对象
JavaBBinderHolder* jbh = (JavaBBinderHolder*)
env->GetLongField(obj, gBinderOffsets.mObject);
// 获取 JavaBBinder 对象
return jbh->get(env, obj);
... ...
}
// frameworks/base/core/jni/android_util_Binder.cpp
sp<JavaBBinder> get(JNIEnv* env, jobject obj)
{
... ...
// 创建 JavaBBinder对象
b = new JavaBBinder(env, obj);
... ...
// 返回 JavaBBinder 对象
return b;
}
- 1-2.方法：parcel->writeStrongBinder
// 参数为 JavaBBinder
status_t Parcel::writeStrongBinder(const sp<IBinder>& val)
{
return flattenBinder(val);
}
// 参数为 JavaBBinder
status_t Parcel::flattenBinder(const sp<IBinder>& binder)
{
... ...
// 通过 JavaBBinder 获取 BBinder
BBinder *local = binder->localBinder();
... ...
}
- 2.BinderProxy.transact
public boolean transact(int code, Parcel data, Parcel reply, int flags) throws RemoteException {
... ...
// 这是一个native方法
return transactNative(code, data, reply, flags);
}
transactNative 是一个 native 方法，会执行 android_util_Binder.cpp 中的 android_os_BinderProxy_transact 方法：
// frameworks/base/core/jni/android_util_Binder.cpp
static jboolean android_os_BinderProxy_transact(JNIEnv* env, jobject obj,
jint code, jobject dataObj, jobject replyObj, jint flags) // throws RemoteException
{
... ...
// 获取 BpBinder 对象
IBinder* target = getBPNativeData(env, obj)->mObject.get();
... ...
// 执行 BpBinder.transact
status_t err = target->transact(code, *data, reply, flags);
... ...
}
2-1.BpBinder.transact
// frameworks/native/libs/binder/BpBinder.cpp
status_t BpBinder::transact(
uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags)
{
status_t status = IPCThreadState::self()->transact(
mHandle, code, data, reply, flags);
}
// frameworks/native/libs/binder/IPCThreadState.cpp
status_t IPCThreadState::transact(int32_t handle,
uint32_t code, const Parcel& data,
Parcel* reply, uint32_t flags)
{
// 写入命令 BC_TRANSACTION
err = writeTransactionData(BC_TRANSACTION, flags, handle, code, data, nullptr);
// 类似于网络请求中的 request，最终会执行 ioctl 方法
err = waitForResponse(reply);
}
ioctl最终会调用到两个方法，一个是 binder_thread_write，一个是 binder_thread_read，如下图：
这两个方法就是根据不同的命令，也叫协议，来进行不同的处理的，一次完整的通信协议如下图：
Binder协议包含在IPC数据中，分为两类:
- BINDER_COMMAND_PROTOCOL：binder请求码，以”BC_“开头，简称BC码，用于从IPC层传递到Binder Driver层；
- BINDER_RETURN_PROTOCOL ：binder响应码，以”BR_“开头，简称BR码，用于从Binder Driver层传递到IPC层；
上面我们已经写入了 BC_TRANSACTION 命令，然后通过 binder_thread_write 方法，就会将这个命令发给 binder驱动处理，binder驱动 会先返回一个 BR_TRANSACTION_COMPLETE 命令，让 AMS客户端 挂起，然后将客户端发过来的数据放到内核和服务端的内存共享区域，这样服务端就也能获取到数据了，然后通过 binder_thread_read 方法，向 servicemanager服务端 发送 BR_TRANSACTION 命令，唤醒 servicemanager服务端，servicemanager服务端就会处理该命令，执行如下代码：
// frameworks/native/libs/binder/IPCThreadState.cpp
status_t IPCThreadState::executeCommand(int32_t cmd)
{
... ...
switch ((uint32_t)cmd) {
... ...
case BR_TRANSACTION:
{
... ...
// the_context_object 就是 ServiceManager
error = the_context_object->transact(tr.code, buffer, &reply, tr.flags);
... ...
}
break;
... ...
}
ServiceManager.transact 方法最终会调用到 ServiceManager 的 addService 方法，如下：
frameworks/native/cmds/servicemanager/ServiceManager.cpp
Status ServiceManager::addService(const std::string& name, const sp<IBinder>& binder, bool allowIsolated, int32_t dumpPriority) {
... ...
// 将服务按名称 保存在 mNameToService 中
mNameToService[name] = Service {
.binder = binder,
.allowIsolated = allowIsolated,
.dumpPriority = dumpPriority,
.debugPid = ctx.debugPid,
};
... ...
}
获取服务
获取服务的流程与添加服务的流程类似，这里就不再赘述了，最终会调用 ServiceManager 的 getService 方法，如下：
// frameworks/native/cmds/servicemanager/ServiceManager.cpp
Status ServiceManager::getService(const std::string& name, sp<IBinder>* outBinder) {
*outBinder = tryGetService(name, true);
... ...
}
sp<IBinder> ServiceManager::tryGetService(const std::string& name, bool startIfNotFound) {
... ...
sp<IBinder> out;
... ...
// 根据名称，找到对应的服务，然后返回
if (auto it = mNameToService.find(name); it != mNameToService.end()) {
service = &(it->second);
... ...
out = service->binder;
}
... ...
return out;
}
总结
- servicemanager 启动时，会将自己设置为大管家，这样所有的客户端都可以通过handle为0，找到servicemanager服务。
- AMS注册服务，首先AMS会获取servicemanager的binder代理对象，然后将自己的binder代理传给servicemanager。
- 用户APP获取AMS服务，首先会获取servicemanager的binder代理对象，然后通过servicemanager拿到AMS的binder代理对象。然后用户APP就可以通过AMS这个代理对象与AMS进行通信了。
