首页 > 代码库 > 彻底理解 Android Binder 通信架构
彻底理解 Android Binder 通信架构
roid 6.0的源码剖析， 本文深度剖析Binder IPC过程, 这绝对是一篇匠心巨作，从Java framework到Native，再到Linux Kernel，带你全程看Binder通信过程.
一. 引言
1.1 Binder架构的思考
Android内核是基于Linux系统, 而Linux现存多种进程间IPC方式:管道, 消息队列, 共享内存, 套接字, 信号量, 信号. 为什么Android非要用Binder来进行进程间通信呢.
从我个人的理解角度, 曾尝试着在知乎回答同样一个问题 为什么Android要采用Binder作为IPC机制？.
这是我第一次认认真真地在知乎上回答问题, 收到很多网友的点赞与回复, 让我很受鼓舞, 也决心分享更多优先地文章回报读者和粉丝, 为Android圈贡献自己的微薄之力.
在说到Binder架构之前, 先简单说说大家熟悉的TCP/IP的五层通信体系结构:
- 应用层: 直接为用户提供服务;
- 传输层: 传输的是报文(TCP数据)或者用户数据报(UDP数据)
- 网络层: 传输的是包(Packet), 例如路由器
- 数据链路层: 传输的是帧(Frame), 例如以太网交换机
- 物理层: 相邻节点间传输bit, 例如集线器,双绞线等
这是经典的五层TPC/IP协议体系, 这样分层设计的思想, 让每一个子问题都设计成一个独立的协议, 这协议的设计/分析/实现/测试都变得更加简单:
- 层与层具有独立性, 例如应用层可以使用传输层提供的功能而无需知晓其实现原理;
- 设计灵活, 层与层之间都定义好接口, 即便层内方法发生变化,只有接口不变, 对这个系统便毫无影响;
- 结构的解耦合, 让每一层可以用更适合的技术方案, 更合适的语言;
- 方便维护, 可分层调试和定位问题;
Binder架构也是采用分层架构设计, 每一层都有其不同的功能:
- Java应用层: 对于上层应用通过调用AMP.startService, 完全可以不用关心底层,经过层层调用,最终必然会调用到AMS.startService.
- Java IPC层: Binder通信是采用C/S架构, Android系统的基础架构便已设计好Binder在Java framework层的Binder客户类BinderProxy和服务类Binder;
- Native IPC层: 对于Native层,如果需要直接使用Binder(比如media相关), 则可以直接使用BpBinder和BBinder(当然这里还有JavaBBinder)即可, 对于上一层Java IPC的通信也是基于这个层面.
- Kernel物理层: 这里是Binder Driver, 前面3层都跑在用户空间,对于用户空间的内存资源是不共享的,每个Android的进程只能运行在自己进程所拥有的虚拟地址空间, 而内核空间却是可共享的. 真正通信的核心环节还是在Binder Driver.
1.2 分析起点
前面通过一个Binder系列-开篇来从源码讲解了Binder的各个层面, 但是Binder牵涉颇为广泛, 几乎是整个Android架构的顶梁柱, 虽说用了十几篇文章来阐述Binder的各个过程.
但依然还是没有将Binder IPC(进程间通信)的过程彻底说透.
Binder系统如此庞大, 那么这里需要寻求一个出发点来穿针引线, 一窥视Binder全貌. 那么本文将从全新的视角,以startService流程分析为例子来说说Binder所其作用.
首先在发起方进程调用AMP.startService，经过binder驱动，最终调用系统进程AMS.startService,如下图:
AMP和AMN都是实现了IActivityManager接口,AMS继承于AMN. 其中AMP作为Binder的客户端,运行在各个app所在进程, AMN(或AMS)运行在系统进程system_server.
1.3 Binder IPC原理
Binder通信采用C/S架构，从组件视角来说，包含Client、Server、ServiceManager以及binder驱动，其中ServiceManager用于管理系统中的各种服务。下面说说startService过程所涉及的Binder对象的架构图：
可以看出无论是注册服务和获取服务的过程都需要ServiceManager，需要注意的是此处的Service Manager是指Native层的ServiceManager（C++），并非指framework层的ServiceManager(Java)。ServiceManager是整个Binder通信机制的大管家，是Android进程间通信机制Binder的守护进程，Client端和Server端通信时都需要先获取Service Manager接口，才能开始通信服务, 当然查找懂啊目标信息可以缓存起来则不需要每次都向ServiceManager请求。
图中Client/Server/ServiceManage之间的相互通信都是基于Binder机制。既然基于Binder机制通信，那么同样也是C/S架构，则图中的3大步骤都有相应的Client端与Server端。
- 注册服务：首先AMS注册到ServiceManager。该过程：AMS所在进程(system_server)是客户端，ServiceManager是服务端。
- 获取服务：Client进程使用AMS前，须先向ServiceManager中获取AMS的代理类AMP。该过程：AMP所在进程(app process)是客户端，ServiceManager是服务端。
- 使用服务： app进程根据得到的代理类AMP,便可以直接与AMS所在进程交互。该过程：AMP所在进程(app process)是客户端，AMS所在进程(system_server)是服务端。
图中的Client,Server,Service Manager之间交互都是虚线表示，是由于它们彼此之间不是直接交互的，而是都通过与Binder Driver进行交互的，从而实现IPC通信方式。其中Binder驱动位于内核空间，Client,Server,Service Manager位于用户空间。Binder驱动和Service Manager可以看做是Android平台的基础架构，而Client和Server是Android的应用层.
这3大过程每一次都是一个完整的Binder IPC过程, 接下来从源码角度, 仅介绍第3过程使用服务, 即展开AMP.startService是如何调用到AMS.startService的过程.
Tips: 如果你只想了解大致过程,并不打算细扣源码, 那么你可以略过通信过程源码分析, 仅看本文第一段落和最后段落也能对Binder所有理解.
二. IPC剖析
2.1 AMP.startService
[-> ActivityManagerNative.java ::ActivityManagerProxy]
public ComponentName startService(IApplicationThread caller, Intent service,
String resolvedType, String callingPackage, int userId) throws RemoteException
{
//获取或创建Parcel对象【见小节2.2】
Parcel data = Parcel.obtain();
Parcel reply = Parcel.obtain();
data.writeInterfaceToken(IActivityManager.descriptor);
data.writeStrongBinder(caller != null ? caller.asBinder() : null);
service.writeToParcel(data, 0);
//写入Parcel数据 【见小节2.3】
data.writeString(resolvedType);
data.writeString(callingPackage);
data.writeInt(userId);
//通过Binder传递数据【见小节2.5】
mRemote.transact(START_SERVICE_TRANSACTION, data, reply, 0);
//读取应答消息的异常情况
reply.readException();
//根据reply数据来创建ComponentName对象
ComponentName res = ComponentName.readFromParcel(reply);
//【见小节2.2.3】
data.recycle();
reply.recycle();
return res;
}主要功能:
- 获取或创建两个Parcel对象,data用于发送数据，reply用于接收应答数据.
- 将startService相关数据都封装到Parcel对象data, 其中descriptor = "android.app.IActivityManager";
- 通过Binder传递数据,并将应答消息写入reply;
- 读取reply应答消息的异常情况和组件对象;
2.2 Parcel.obtain
[-> Parcel.java]
public static Parcel obtain() {
final Parcel[] pool = sOwnedPool;
synchronized (pool) {
Parcel p;
//POOL_SIZE = 6
for (int i=0; i<POOL_SIZE; i++) {
p = pool[i];
if (p != null) {
pool[i] = null;
return p;
}
}
}
//当缓存池没有现成的Parcel对象，则直接创建[见流程2.2.1]
return new Parcel(0);
}sOwnedPool是一个大小为6，存放着parcel对象的缓存池,这样设计的目标是用于节省每次都创建Parcel对象的开销。obtain()方法的作用：
- 先尝试从缓存池
sOwnedPool中查询是否存在缓存Parcel对象，当存在则直接返回该对象; - 如果没有可用的Parcel对象，则直接创建Parcel对象。
2.2.1 new Parcel
[-> Parcel.java]
private Parcel(long nativePtr) {
//初始化本地指针
init(nativePtr);
}
private void init(long nativePtr) {
if (nativePtr != 0) {
mNativePtr = nativePtr;
mOwnsNativeParcelObject = false;
} else {
// 首次创建,进入该分支[见流程2.2.2]
mNativePtr = nativeCreate();
mOwnsNativeParcelObject = true;
}
}nativeCreate这是native方法,经过JNI进入native层, 调用android_os_Parcel_create()方法.
2.2.2 android_os_Parcel_create
[-> android_os_Parcel.cpp]
static jlong android_os_Parcel_create(JNIEnv* env, jclass clazz)
{
Parcel* parcel = new Parcel();
return reinterpret_cast<jlong>(parcel);
}创建C++层的Parcel对象, 该对象指针强制转换为long型, 并保存到Java层的mNativePtr对象. 创建完Parcel对象利用Parcel对象写数据. 接下来以writeString为例.
2.2.3 Parcel.recycle
public final void recycle() {
//释放native parcel对象
freeBuffer();
final Parcel[] pool;
//根据情况来选择加入相应池
if (mOwnsNativeParcelObject) {
pool = sOwnedPool;
} else {
mNativePtr = 0;
pool = sHolderPool;
}
synchronized (pool) {
for (int i=0; i<POOL_SIZE; i++) {
if (pool[i] == null) {
pool[i] = this;
return;
}
}
}
}将不再使用的Parcel对象放入缓存池，可回收重复利用，当缓存池已满则不再加入缓存池。这里有两个Parcel线程池,mOwnsNativeParcelObject变量来决定:
mOwnsNativeParcelObject=true, 即调用不带参数obtain()方法获取的对象, 回收时会放入sOwnedPool对象池;mOwnsNativeParcelObject=false, 即调用带nativePtr参数的obtain(long)方法获取的对象, 回收时会放入sHolderPool对象池;
2.3 writeString
[-> Parcel.java]
public final void writeString(String val) {
//[见流程2.3.1]
nativeWriteString(mNativePtr, val);
}2.3.1 nativeWriteString
[-> android_os_Parcel.cpp]
static void android_os_Parcel_writeString(JNIEnv* env, jclass clazz, jlong nativePtr, jstring val)
{
Parcel* parcel = reinterpret_cast<Parcel*>(nativePtr);
if (parcel != NULL) {
status_t err = NO_MEMORY;
if (val) {
const jchar* str = env->GetStringCritical(val, 0);
if (str) {
//[见流程2.3.2]
err = parcel->writeString16(
reinterpret_cast<const char16_t*>(str),
env->GetStringLength(val));
env->ReleaseStringCritical(val, str);
}
} else {
err = parcel->writeString16(NULL, 0);
}
if (err != NO_ERROR) {
signalExceptionForError(env, clazz, err);
}
}
}2.3.2 writeString16
[-> Parcel.cpp]
status_t Parcel::writeString16(const char16_t* str, size_t len)
{
if (str == NULL) return writeInt32(-1);
status_t err = writeInt32(len);
if (err == NO_ERROR) {
len *= sizeof(char16_t);
uint8_t* data = (uint8_t*)writeInplace(len+sizeof(char16_t));
if (data) {
//数据拷贝到data所指向的位置
memcpy(data, str, len);
*reinterpret_cast<char16_t*>(data+len) = 0;
return NO_ERROR;
}
err = mError;
}
return err;
}Tips: 除了writeString(),在Parcel.java中大量的native方法, 都是调用android_os_Parcel.cpp相对应的方法, 该方法再调用Parcel.cpp中对应的方法.
调用流程: Parcel.java --> android_os_Parcel.cpp --> Parcel.cpp.
/frameworks/base/core/java/android/os/Parcel.java
/frameworks/base/core/jni/android_os_Parcel.cpp
/frameworks/native/libs/binder/Parcel.cpp
简单说,就是
2.4 mRemote究竟为何物
mRemote的出生,要出先说说ActivityManagerProxy对象(简称AMP)创建说起, AMP是通过ActivityManagerNative.getDefault()来获取的.
2.4.1 AMN.getDefault
[-> ActivityManagerNative.java]
static public IActivityManager getDefault() {
// [见流程2.4.2]
return gDefault.get();
}gDefault的数据类型为Singleton<IActivityManager>, 这是一个单例模式, 接下来看看Singleto.get()的过程
2.4.2 gDefault.get
public abstract class Singleton<IActivityManager> {
public final IActivityManager get() {
synchronized (this) {
if (mInstance == null) {
//首次调用create()来获取AMP对象[见流程2.4.3]
mInstance = create();
}
return mInstance;
}
}
}首次调用时需要创建,创建完之后保持到mInstance对象,之后可直接使用.
2.4.3 gDefault.create
private static final Singleton<IActivityManager> gDefault = new Singleton<IActivityManager>() {
protected IActivityManager create() {
//获取名为"activity"的服务
IBinder b = ServiceManager.getService("activity");
//创建AMP对象[见流程2.4.4]
IActivityManager am = asInterface(b);
return am;
}
};文章Binder系列7—framework层分析，可知ServiceManager.getService("activity")返回的是指向目标服务AMS的代理对象BinderProxy对象，由该代理对象可以找到目标服务AMS所在进程
2.4.4 AMN.asInterface
[-> ActivityManagerNative.java]
public abstract class ActivityManagerNative extends Binder implements IActivityManager
{
static public IActivityManager asInterface(IBinder obj) {
if (obj == null) {
return null;
}
//此处obj = BinderProxy, descriptor = "android.app.IActivityManager"; [见流程2.4.5]
IActivityManager in = (IActivityManager)obj.queryLocalInterface(descriptor);
if (in != null) { //此处为null
return in;
}
//[见流程2.4.6]
return new ActivityManagerProxy(obj);
}
...
}此时obj为BinderProxy对象, 记录着远程进程system_server中AMS服务的binder线程的handle.
2.4.5 queryLocalInterface
[Binder.java]
public class Binder implements IBinder {
//对于Binder对象的调用,则返回值不为空
public IInterface queryLocalInterface(String descriptor) {
//mDescriptor的初始化在attachInterface()过程中赋值
if (mDescriptor.equals(descriptor)) {
return mOwner;
}
return null;
}
}
//由上一小节[2.4.4]调用的流程便是此处,返回Null
final class BinderProxy implements IBinder {
//BinderProxy对象的调用, 则返回值为空
public IInterface queryLocalInterface(String descriptor) {
return null;
}
}对于Binder IPC的过程中, 同一个进程的调用则会是asInterface()方法返回的便是本地的Binder对象;对于不同进程的调用则会是远程代理对象BinderProxy.
2.4.6 创建AMP
[-> ActivityManagerNative.java :: AMP]
class ActivityManagerProxy implements IActivityManager
{
public ActivityManagerProxy(IBinder remote)
{
mRemote = remote;
}
}可知mRemote便是指向AMS服务的BinderProxy对象。
2.5 mRemote.transact
[-> Binder.java ::BinderProxy]
final class BinderProxy implements IBinder {
public boolean transact(int code, Parcel data, Parcel reply, int flags) throws RemoteException {
//用于检测Parcel大小是否大于800k
Binder.checkParcel(this, code, data, "Unreasonably large binder buffer");
//【见2.6】
return transactNative(code, data, reply, flags);
}
}mRemote.transact()方法中的code=START_SERVICE_TRANSACTION, data保存了descriptor，caller, intent, resolvedType, callingPackage, userId这6项信息。
transactNative是native方法，经过jni调用android_os_BinderProxy_transact方法。
2.6 android_os_BinderProxy_transact
[-> android_util_Binder.cpp]
static jboolean android_os_BinderProxy_transact(JNIEnv* env, jobject obj,
jint code, jobject dataObj, jobject replyObj, jint flags)
{
...
//将java Parcel转为c++ Parcel
Parcel* data = parcelForJavaObject(env, dataObj);
Parcel* reply = parcelForJavaObject(env, replyObj);
//gBinderProxyOffsets.mObject中保存的是new BpBinder(handle)对象
IBinder* target = (IBinder*) env->GetLongField(obj, gBinderProxyOffsets.mObject);
...
//此处便是BpBinder::transact()【见小节2.7】
status_t err = target->transact(code, *data, reply, flags);
...
//最后根据transact执行具体情况，抛出相应的Exception
signalExceptionForError(env, obj, err, true , data->dataSize());
return JNI_FALSE;
}gBinderProxyOffsets.mObject中保存的是BpBinder对象, 这是开机时Zygote调用AndroidRuntime::startReg方法来完成jni方法的注册.
其中register_android_os_Binder()过程就有一个初始并注册BinderProxy的操作,完成gBinderProxyOffsets的赋值过程. 接下来就进入该方法.
2.7 BpBinder.transact
[-> BpBinder.cpp]
status_t BpBinder::transact(
uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags)
{
if (mAlive) {
// 【见小节2.8】
status_t status = IPCThreadState::self()->transact(
mHandle, code, data, reply, flags);
if (status == DEAD_OBJECT) mAlive = 0;
return status;
}
return DEAD_OBJECT;
}IPCThreadState::self()采用单例模式，保证每个线程只有一个实例对象。
2.8 IPC.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) {
// 传输数据 【见小节2.9】
err = writeTransactionData(BC_TRANSACTION, flags, handle, code, data, NULL);
}
if (err != NO_ERROR) {
if (reply) reply->setError(err);
return (mLastError = err);
}
// 默认情况下,都是采用非oneway的方式, 也就是需要等待服务端的返回结果
if ((flags & TF_ONE_WAY) == 0) {
if (reply) {
//reply对象不为空 【见小节2.10】
err = waitForResponse(reply);
}else {
Parcel fakeReply;
err = waitForResponse(&fakeReply);
}
} else {
err = waitForResponse(NULL, NULL);
}
return err;
}transact主要过程:
- 先执行writeTransactionData()已向Parcel数据类型的
mOut写入数据，此时mIn还没有数据； - 然后执行waitForResponse()方法，循环执行，直到收到应答消息. 调用talkWithDriver()跟驱动交互，收到应答消息，便会写入
mIn, 则根据收到的不同响应吗，执行相应的操作。
此处调用waitForResponse根据是否有设置TF_ONE_WAY的标记:
- 当已设置oneway时, 则调用waitForResponse(NULL, NULL);
- 当未设置oneway时, 则调用waitForResponse(reply) 或 waitForResponse(&fakeReply)
2.9 IPC.writeTransactionData
[-> IPCThreadState.cpp]
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.ptr = 0;
tr.target.handle = handle; // handle指向AMS
tr.code = code; // START_SERVICE_TRANSACTION
tr.flags = binderFlags; // 0
tr.cookie = 0;
tr.sender_pid = 0;
tr.sender_euid = 0;
const status_t err = data.errorCheck();
if (err == NO_ERROR) {
// data为startService相关信息
tr.data_size = data.ipcDataSize(); // mDataSize
tr.data.ptr.buffer = data.ipcData(); // mData指针
tr.offsets_size = data.ipcObjectsCount()*sizeof(binder_size_t); //mObjectsSize
tr.data.ptr.offsets = data.ipcObjects(); //mObjects指针
}
...
mOut.writeInt32(cmd); //cmd = BC_TRANSACTION
mOut.write(&tr, sizeof(tr)); //写入binder_transaction_data数据
return NO_ERROR;
}将数据写入mOut
2.10 IPC.waitForResponse
status_t IPCThreadState::waitForResponse(Parcel *reply, status_t *acquireResult)
{
int32_t cmd;
int32_t err;
while (1) {
if ((err=talkWithDriver()) < NO_ERROR) break; // 【见小节2.11】
err = mIn.errorCheck();
if (err < NO_ERROR) break; //当存在error则退出循环
if (mIn.dataAvail() == 0) continue; //mIn有数据则往下执行
cmd = mIn.readInt32();
switch (cmd) {
case BR_TRANSACTION_COMPLETE: ... goto finish;
case BR_DEAD_REPLY: ... goto finish;
case BR_FAILED_REPLY: ... goto finish;
case BR_REPLY: ... goto finish;
default:
err = executeCommand(cmd); //【见小节2.10.1】
if (err != NO_ERROR) goto finish;
break;
}
}
finish:
if (err != NO_ERROR) {
if (reply) reply->setError(err); //将发送的错误代码返回给最初的调用者
}
return err;
}在这个过程中, 常见的几个BR_命令:
- BR_TRANSACTION_COMPLETE: binder驱动收到BC_TRANSACTION事件后的应答消息; 对于oneway transaction,当收到该消息,则完成了本次Binder通信;
- BR_DEAD_REPLY: 回复失败，往往是线程或节点为空. 则结束本次通信Binder;
- BR_FAILED_REPLY:回复失败，往往是transaction出错导致. 则结束本次通信Binder;
- BR_REPLY: Binder驱动向Client端发送回应消息; 对于非oneway transaction时,当收到该消息,则完整地完成本次Binder通信;
规律: BC_TRANSACTION + BC_REPLY = BR_TRANSACTION_COMPLETE + BR_DEAD_REPLY + BR_FAILED_REPLY
2.10.1 IPC.executeCommand
status_t IPCThreadState::executeCommand(int32_t cmd)
{
BBinder* obj;
RefBase::weakref_type* refs;
status_t result = NO_ERROR;
switch ((uint32_t)cmd) {
case BR_ERROR: ...
case BR_OK: ...
case BR_ACQUIRE: ...
case BR_RELEASE: ...
case BR_INCREFS: ...
case BR_TRANSACTION: ... //Binder驱动向Server端发送消息
case BR_DEAD_BINDER: ...
case BR_CLEAR_DEATH_NOTIFICATION_DONE: ...
case BR_NOOP: ...
case BR_SPAWN_LOOPER: ... //创建新binder线程
default: ...
}
}处于剩余的BR_命令.
2.11 IPC.talkWithDriver
//mOut有数据，mIn还没有数据。doReceive默认值为true
status_t IPCThreadState::talkWithDriver(bool doReceive)
{
binder_write_read bwr;
const bool needRead = mIn.dataPosition() >= mIn.dataSize();
const size_t outAvail = (!doReceive || needRead) ? mOut.dataSize() : 0;
bwr.write_size = outAvail;
bwr.write_buffer = (uintptr_t)mOut.data();
if (doReceive && needRead) {
//接收数据缓冲区信息的填充。当收到驱动的数据，则写入mIn
bwr.read_size = mIn.dataCapacity();
bwr.read_buffer = (uintptr_t)mIn.data();
} 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 {
//ioctl不停的读写操作，经过syscall，进入Binder驱动。调用Binder_ioctl【小节3.1】
if (ioctl(mProcess->mDriverFD, BINDER_WRITE_READ, &bwr) >= 0)
err = NO_ERROR;
else
err = -errno;
...
} while (err == -EINTR);
if (err >= NO_ERROR) {
if (bwr.write_consumed > 0) {
if (bwr.write_consumed < 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