Android Binder进程间通信机制，百度一面后多久有二面通知如果不通过也有通知吗

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Android开发知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip204888 （备注Android）

正文

这部分源码位置在Linux内核中：

/kernel/drivers/android/binder.c

/kernel/include/uapi/linux/android/binder.h

3.1 Binder驱动设备初始化

---

Binder驱动设备在初始化时主要完成如下几件事情：

1. 通过misc_register()将自己注册为misc device类型的驱动设备；

2. 填写file_operations函数指针结构体以标识用户空间在使用Binder驱动时所支持的文件操作；

3. 指定Binder设备的名称是“binder”，这样用户空间便可以通过对/dev/binder文件进行操作来使用Binder。如下代码所示：

/kernel/drivers/android/binder.c/

static int __init init_binder_device(const char *name)

{

int ret;

struct binder_device *binder_device;

binder_device = kzalloc(sizeof(*binder_device), GFP_KERNEL);

if (!binder_device)

return -ENOMEM;

binder_device->miscdev.fops = &binder_fops;// 1.Binder驱动支持的文件操作

binder_device->miscdev.minor = MISC_DYNAMIC_MINOR;//动态分配次设备号

binder_device->miscdev.name = name;//2.驱动名称设置，一般就是“binder”

binder_device->context.binder_context_mgr_uid = INVALID_UID;

binder_device->context.name = name;

mutex_init(&binder_device->context.context_mgr_node_lock);

ret = misc_register(&binder_device->miscdev);// 3.注册Binder驱动

if (ret < 0) {

kfree(binder_device);

return ret;

}

hlist_add_head(&binder_device->hlist, &binder_devices);

return ret;

}

const struct file_operations binder_fops = {

.owner = THIS_MODULE,

.poll = binder_poll,

.unlocked_ioctl = binder_ioctl,// binder_ioctl

.compat_ioctl = binder_ioctl,

.mmap = binder_mmap,// binder_mmap

.open = binder_open,// binder_open

.flush = binder_flush,

.release = binder_release,

};

由此可见，Binder驱动为上层应用提供了6个接口——其中使用最多的就是binder_ioctl、binder_mmap和binder_open。这是因为：需要使用Binder的进程，几乎总是先通过binder_open打开Binder设备，然后通过binder_mmap进行内存映射，最后再通过binder_ioctl来进行实际的操作。Client对于Server端的请求，以及Server对于Client请求结果的返回，都是通过ioctl完成的。

3.2 打开Binder驱动——binder open

---

上层用户空间的进程在访问Binder驱动时，首先需要通过open(“dev/binder”)打开Binder驱动设备，这个操作最终对应的实现是在binder_open()中。如下所示：

/kernel/drivers/android/binder.c/

static int binder_open(struct inode *nodp, struct file *filp)

{

struct binder_proc *proc;

struct binder_device *binder_dev;

binder_debug(BINDER_DEBUG_OPEN_CLOSE, “%s: %d:%d\n”, func,

current->group_leader->pid, current->pid);

proc = kzalloc(sizeof(*proc), GFP_KERNEL);//1.创建进程对应的binder_proc对象

if (proc == NULL)

return -ENOMEM;

spin_lock_init(&proc->inner_lock);

spin_lock_init(&proc->outer_lock);

get_task_struct(current->group_leader);

proc->tsk = current->group_leader;

INIT_LIST_HEAD(&proc->todo);

proc->default_priority = task_nice(current);

/* binderfs stashes devices in i_private */

if (is_binderfs_device(nodp))

binder_dev = nodp->i_private;

else

binder_dev = container_of(filp->private_data,

struct binder_device, miscdev);

proc->context = &binder_dev->context;

binder_alloc_init(&proc->alloc);

binder_stats_created(BINDER_STAT_PROC);

proc->pid = current->group_leader->pid;

// 2.初始化binder_proc

INIT_LIST_HEAD(&proc->delivered_death);

INIT_LIST_HEAD(&proc->waiting_threads);

filp->private_data = proc;

mutex_lock(&binder_procs_lock);// 获取锁

hlist_add_head(&proc->proc_node, &binder_procs);// 3.添加到全局列表binder_procs中

mutex_unlock(&binder_procs_lock);

if (binder_debugfs_dir_entry_proc) {

char strbuf[11];

snprintf(strbuf, sizeof(strbuf), “%u”, proc->pid);

/*

• proc debug entries are shared between contexts, so

• this will fail if the process tries to open the driver

• again with a different context. The priting code will

• anyway print all contexts that a given PID has, so this

• is not a problem.

*/

proc->debugfs_entry = debugfs_create_file(strbuf, 0444,

binder_debugfs_dir_entry_proc,

(void *)(unsigned long)proc->pid,

&proc_fops);

}

return 0;

}

在Binder驱动中，通过binder_procs集合记录了所有使用Binder的进程。每个初次打开Binder设备的进程都会创建一个binder_proc结构体对象，用来描述使用Binder的进程，然后被添加到这个列表中的。

3.3 内存映射——binder_mmap

---

在打开Binder设备之后，上层进程就要通过mmap进行内存映射。mmap的作用有如下两个：

• 申请一块内存空间，用来接收Binder通信过程中的数据

• 对这块内存进行地址映射，以便将来访问

mmap在内核对应的就是binder_mmap()函数：在这个函数中，会申请一块物理内存，然后将用户空间和内核空间虚拟地址同时对应到这块物理内存上。在这之后，当有Client要发送数据给Server的时候，只需一次copy_from_user动作，将Client发送过来的数据拷贝到Server端的内核空间指定的内存地址即可（从而实现前文说的Binder通信机制只需要一次内存拷贝的效果），由于这个内存地址在服务端已经同时映射到用户空间，因此无需再做一次复制，Server即可直接访问，整个过程如下图所示：

这幅图的说明如下：

1. Server在启动之后，调用对/dev/binder设备调用mmap；

2. 内核中的binder_mmap函数进行对应的处理：申请一块物理内存，然后在用户空间和内核空间同时进行映射；

3. Client通过BINDER_WRITE_READ命令发送请求，这个请求将先到驱动中，同时需要将数据从Client进程的用户空间拷贝到内核空间；

4. 驱动通过BR_TRANSACTION通知Server有人发出请求，Server进行处理。由于这块内存也在用户空间进行了映射，因此Server进程的代码可以直接访问。

3.4 Binder驱动控制协议——binder_ioctl

---

binder_ioctl()实现了上层应用进程与Binder驱动之间的交互命令，可以说承载了Binder驱动的大部分业务，也是我们学习的重中之重。下面表格中列出binder_ioctl支持的命令：

| 命令 | 说明 |

| — | — |

| BINDER_WRITE_READ | 读写操作，可以用此命令向Binder读取或写入数据 |

| BINDER_SET_MAX_THREADS | 设置支持的最大线程数。因为客户端可以并发向服务器端发送请求，如果Binder驱动发现当前线程数已经超过设定值，就会告知Binder Server停止启动新的线程 |

| BINDER_SET_CONTEXT_MGR | Service Manager专用，将自己设置为“Binder大管家”。系统中只能有一个SM存在 |

| BINDER_THREAD_EXIT | 通知Binder线程退出。每个线程退出时都应该告知Binder驱动、才能释放相关资源；否则会造成内存泄漏 |

| BINDER_VERSION | 获取Binder版本号 |

其中BINDER_WRITE_READ这个命令是重点，又分为若干子命令，如下表所示：

| 命令 | 说明 |

| — | — |

| BC_TRANSACTION | Binder事务，即：Client对于Server的请求 |

| BC_REPLY | 事务的应答，即：Server对于Client的回复 |

| BC_ENTER_LOOPER | 通知驱动主线程ready |

| BC_REGISTER_LOOPER | 通知驱动子线程ready |

| BR_REPLY | 通知进程收到Binder请求的回复（Client） |

| BR_TRANSACTION_COMPLETE | 驱动对于接受请求的确认回复 |

| BR_TRANSACTION | 通知进程收到一次Binder请求（Server端） |

| BR_DEAD_BINDER | 发送死亡通知 |

| BR_SPAWN_LOOPER | 通知Binder进程创建一个新的线程 |

其中BC_TRANSACTION和BC_REPLAY是最关键的两个命令，Binder机制中Client与Server交互基本靠它们完成。

单独看上面的协议可能很难理解，这里我们以一次Binder请求过程来详细看一下Binder协议是如何通信的，就比较好理解了。

这幅图的说明如下：

• Binder是C/S架构的，通信过程牵涉到：Client，Server以及Binder驱动三个角色

• Client对于Server的请求以及Server对于Client回复都需要通过Binder驱动来中转数据

• BC_XXX命令是进程发送给驱动的命令

• BR_XXX命令是驱动发送给进程的命令

• 整个通信过程由Binder驱动控制

4 Binder Framework C++层

=====================================================================================

Binder Framework的C++部分：主要功能是实现向下与Binder驱动的对接交互，并封装复杂的内部实现，对外提供使用接口。头文件定义位于：/frameworks/native/include/binder/，实现位于这个路径：/frameworks/native/libs/binder/ 。Binder库最终会编译成一个动态链接库libbinder.so，供其他进程链接使用。为了便于说明，下文中我们将Binder Framework 的C++部分称为libbinder。

4.1 主要类结构

---

先用一张类图描述libbinder中的主要类结构之间的关系：

对照上面这张libbinder的设计类图，我们来理一下各个核心类的功能与职责：

• 基类

1. IBinder：Binder对象的基类，这个类描述了所有在Binder上传递的对象，它既是Binder服务端对象BBinder的父类，也是Binder客户端对象BpBinder的父类；主要定义的方法有：a.transact ———进行一次Binder操作；b.queryLocalInterface——尝试获取本地Binder对象；c.getInterfaceDescriptor ——获取Binder的服务接口唯一的描述；d.isBinderAlive——查询Binder服务是否还活着等；

2. IInterface：Binder服务接口的基类，Binder服务通常需要同时提供客户端接口和服务端接口。每个Binder服务都是为了某个功能而实现的，因此其本身会定义一套接口集来描述自己提供的所有功能。而Binder服务既有自身实现服务的类，也要有给客户端进程调用的类。为了便于开发，这两中类里面的服务接口应当是一致的。因此为了实现方便，本地实现类和远程接口类需要有一个公共的描述服务接口的基类（即上图中的IXXXService）来继承。而这个基类通常是IInterface的子类。

• 客户端类

1. BpBinder ：BpBinder的实例代表了客户端Binder，这个类的对象将被客户端调用。这个类最重要就是提供了transact方法，这个方法会将客户端调用的参数封装好通过IPCThreadState逻辑封装后发送给Binder驱动。

2. BpInterface：客户端接口的基类，远程接口是供客户端调用的接口集。BpInterface是个模板类，它们在继承自INTERFACE的基础上还继承了BpRefBase，通过这个类的remote方法可以获取到指向服务实现方的句柄。

• 服务端类

1. BBinder：BBinder的实例代表了服务端Binder，它描述了服务的提供方，所有Binder服务的实现者都要继承这个类（的子类），在继承类中，最重要的就是实现onTransact方法，因为这个方法是所有请求的入口。因此，这个方法是和BpBinder中的transact方法对应的，这个方法同样也有一个uint32_t code参数（统一在IBinder中定义），在这个方法的实现中，由服务提供者通过code对请求的接口进行区分，然后调用具体实现服务的方法。

2. BnInterface：服务端接口的基类，是需要服务端服务中真正实现的接口集。BnInterface是个模板类，它们在继承自INTERFACE(Binder服务接口的基类，继承自IInterface)的基础上还继承了BBinder，由此可以通过复写onTransact方法来提供实现。

• 与驱动通信的类

1. ProcessState : 代表使用Binder的进程。在讲解Binder驱动的时候我们就提到：任何使用Binder机制的进程都必须要对/dev/binder设备进行open以及mmap之后才能使用，这部分逻辑是所有使用Binder机制进程共同的。对于这种共同逻辑的封装便是Framework层的职责之一。libbinder中，ProcessState类封装了这个逻辑，从而负责进程Binder的初始化。

2. IPCThreadState ：代表了进程中使用Binder的线程，这个类中封装了与Binder驱动通信的具体实现逻辑。

在客户端接口的实现类中，每个接口在组装好参数之后，都会调用remote()->transact来发送请求，而这里其实就是调用的BpBinder的transact方法，这样请求便通过Binder到达了服务实现方的onTransact中。这个过程如下图所示：

4.2 进程的Binder初始化（ProcessState）

---

之前讲解Binder驱动的时候讲过，需要使用Binder的进程，需要先通过binder_open打开Binder设备，然后通过binder_mmap进行内存映射。由于这部分逻辑是所有使用Binder的进程共有的，所以libbinder中使用ProcessState类统一封装了这个逻辑，具体代码如下：

/framework/native/libs/binder/ProcessState.cpp/

#define BINDER_VM_SIZE ((110241024) - (4096 *2)) // 1M - 8k

ProcessState::ProcessState(const char *driver)

mDriverName(String8(driver))

, mDriverFD(open_driver(driver))// 1.调用open_driver打开binder驱动设备

, mVMStart(MAP_FAILED)

, mThreadCountLock(PTHREAD_MUTEX_INITIALIZER)

, mThreadCountDecrement(PTHREAD_COND_INITIALIZER)

, mExecutingThreadsCount(0)

, mMaxThreads(DEFAULT_MAX_BINDER_THREADS)

, mStarvationStartTimeMs(0)

, mBinderContextCheckFunc(nullptr)

, mBinderContextUserData(nullptr)

, mThreadPoolStarted(false)

, mThreadPoolSeq(1)

, mCallRestriction(CallRestriction::NONE)

{

// TODO(b/139016109): enforce in build system

#if defined(ANDROID_APEX)

LOG_ALWAYS_FATAL(“Cannot use libbinder in APEX (only system.img libbinder) since it is not stable.”);

#endif

if (mDriverFD >= 0) {

// 2.mmap执行内存映射动作

// mmap the binder, providing a chunk of virtual address space to receive transactions.

mVMStart = mmap(nullptr, BINDER_VM_SIZE, PROT_READ, MAP_PRIVATE | MAP_NORESERVE, mDriverFD, 0);

if (mVMStart == MAP_FAILED) {

// sigh

ALOGE(“Using %s failed: unable to mmap transaction memory.\n”, mDriverName.c_str());

close(mDriverFD);

mDriverFD = -1;

mDriverName.clear();

}

}

}

这是ProcessState构造函数，Binder的初始化工作都是在这个函数中完成的。在这个函数中，初始化mDriverFD的时候调用了open_driver方法打开binder设备，然后又在函数体中，通过mmap进行内存映射。这里需要注意的是mmap函数的参数中有个BINDER_VM_SIZE，这个就是指定在内核上开辟的内存空间的大小，也是一次Binder通信传递的最大数据量，目前默认定义大小是1016个字节（1M-8K）。这个其实也就解释了我们平常开发过程中遇到的一个问题，就是通过Intent传递过大的对象时会报TransactionTooLargeException异常的原因。open_driver动作具体代码如下：

/framework/native/libs/binder/ProcessState.cpp/

#define DEFAULT_MAX_BINDER_THREADS 15

static int open_driver(const char *driver)

{

int fd = open(driver, O_RDWR | O_CLOEXEC);// 1.通过open系统调用打开了dev/binder设备

if (fd >= 0) {

int vers = 0;

// 2.通过ioctl获取Binder实现的版本号，并检查是否匹配

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(%d) does not match user space protocol(%d)! ioctl() return value: %d”,

vers, BINDER_CURRENT_PROTOCOL_VERSION, result);

close(fd);

fd = -1;

}

size_t maxThreads = DEFAULT_MAX_BINDER_THREADS;

// 3.通过ioctl设置进程支持的最大Binder线程数

result = ioctl(fd, BINDER_SET_MAX_THREADS, &maxThreads);

if (result == -1) {

ALOGE(“Binder ioctl to set max threads failed: %s”, strerror(errno));

}

} else {

ALOGW(“Opening ‘%s’ failed: %s\n”, driver, strerror(errno));

}

return fd;

}

open_driver函数中除了实现通过open系统调用打开了dev/binder设备外。还会通过ioctl调用的BINDER_SET_MAX_THREADS命令设置进程支持的最大Binder线程数，目前定义的一般进程默认最大Binder线程数是15。这个也解释了我们在开发过程中遇到一类性能问题：就是进程的Binder线程耗尽，此时进程中已经开启了15个Binder线程用于处理binder请求且都处于工作或阻塞状态，此时如果有新的binder请求时就无法继续处理了，从而导致阻塞卡主；

4.3 与Binder驱动的通信(IPCThreadState)

---

IPCThreadState是一个单例类，进程中的每个Binder线程存在一个实例，负责了与驱动通信的细节处理。这个类中的关键几个方法说明如下：

以其中最主要的是transact方法为例，该方法会完成一次Binder数据传输动作，代码如下：

/framework/native/libs/binder/IPCThreadState.cpp/

status_t IPCThreadState::transact(int32_t handle,

uint32_t code, const Parcel& data,

Parcel* reply, uint32_t flags)

{

…

// 1.通过writeTransactionData完成数据组装写入

err = writeTransactionData(BC_TRANSACTION, flags, handle, code, data, nullptr);

…

// 2.判断是否为TF_ONE_WAY异步单向请求，如果是线程不需要阻塞等待返回值，直接返回即可

if ((flags & TF_ONE_WAY) == 0) {

…

// 3.通过waitForResponse将数据传输到驱动并等待返回结果

if (reply) {

err = waitForResponse(reply);

} else {

Parcel fakeReply;

err = waitForResponse(&fakeReply);

}

…

} else {

err = waitForResponse(nullptr, nullptr);

}

return err;

}

从代码可以看出，通过Binder驱动完成一次Binder数据传输的主要流程是：

1. 先通过writeTransactionData函数完成传输数据binder_transaction_data的组装填充；

2. 通过waitForResponse函数真正完成传输数据写入驱动并等待返回数据，具体实现会调用talkWithDriver函数，通过ioctl命令BINDER_WRITE_READ与Binder驱动通信，完成数据的传输写入，并读取返回数据。

详细代码如下：

/framework/native/libs/binder/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

binder_transaction_data tr;

tr.target.ptr = 0; /* Don’t pass uninitialized stack data to a remote process */

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(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.writeInt32(cmd);

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

return NO_ERROR;

}

status_t IPCThreadState::waitForResponse(Parcel *reply, status_t *acquireResult)

{

uint32_t cmd;

int32_t err;

while (1) {

// 调用talkWithDriver真正完成传输数据写入驱动并等待返回数据

if ((err=talkWithDriver()) < NO_ERROR) break;

}

}

status_t IPCThreadState::talkWithDriver(bool doReceive)

{

…

do {

IF_LOG_COMMANDS() {

alog << "About to read/write, write size = " << mOut.dataSize() << endl;

}

#if defined(ANDROID)

// 通过ioctl命令BINDER_WRITE_READ与Binder驱动通信

if (ioctl(mProcess->mDriverFD, BINDER_WRITE_READ, &bwr) >= 0)

err = NO_ERROR;

else

err = -errno;

…

} while (err == -EINTR);

…

}

4.4 C++ Binder服务实现举例

---

上面的理论知识可能比较枯燥和抽象，下面以Android系统中的一个系统Binder服务为例，结合上面的理论具体分析一下。 我们以实现系统图像合成显示的核心进程服务SurfaceFlinger为例，来分析C++的Binder服务如何实现。下图是SurfaceFlinger C++ Binder服务实现类图：

ISurfaceComposer定义了SurfaceFlinger对外提供的功能接口，其子类都继承了这些接口。

• BpSurfaceComposer是提供给客户端调用的远程接口，先通过remote方法获取到指向服务实现方的句柄，然后通过transact方法发送具体请求。

• BnSurfaceComposer中只有一个onTransact方法，该方法根据请求的code来对接每个请求，并直接调用SurfaceFlinger中对应的方法。

• SurfaceFlinger是服务接口功能真正的实现。

4.4.1 服务端实现

主要包括BnSurfaceComposer和SurfaceFlinger两个类，SurfaceFlinger是BnSurfaceComposer的子类，因此在BnSurfaceComposer中调用自身的virtual方法其实都是在子类SurfaceFlinger类中实现的。BnSurfaceComposer类要做的就是复写onTransact方法，这个方法的职责是：根据请求的code区分具体调用的是那个接口，然后按顺序从Parcel中读出打包好的参数，接着调用留待子类实现的虚函数。我们看一下BnSurfaceComposer::onTransact中的代码片段：

/framework/native/libs/gui/ISurfaceComposer.cpp/

status_t BnSurfaceComposer::onTransact(

uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags)

{

switch(code) {

…

case CREATE_DISPLAY: {

CHECK_INTERFACE(ISurfaceComposer, data, reply);

String8 displayName = data.readString8();

bool secure = bool(data.readInt32());

sp display(createDisplay(displayName, secure));

reply->writeStrongBinder(display);

return NO_ERROR;

}

…

}

}

这段代码中我们看到了实现中是如何根据code区分接口，并通过Parcel读出调用参数，然后调用具体服务方的。而SurfaceFlinger这个类中的createDisplay方法才是真正实现创建显示设备的逻辑，详细代码如下：

/framework/native/services/surfaceflinger/SurfaceFlinger.cpp/

sp SurfaceFlinger::createDisplay(const String8& displayName, bool secure) {

class DisplayToken : public BBinder {

sp flinger;

virtual ~DisplayToken() {

// no more references, this display must be terminated

Mutex::Autolock _l(flinger->mStateLock);

flinger->mCurrentState.displays.removeItem(this);

flinger->setTransactionFlags(eDisplayTransactionNeeded);

}

public:

explicit DisplayToken(const sp& flinger)

flinger(flinger) {

}

};

sp token = new DisplayToken(this);

Mutex::Autolock _l(mStateLock);

// Display ID is assigned when virtual display is allocated by HWC.

DisplayDeviceState state;

state.isSecure = secure;

state.displayName = displayName;

mCurrentState.displays.add(token, state);

mInterceptor->saveDisplayCreation(state);

return token;

}

4.4.2 注册服务

服务实现完成之后，并不是立即就能让别人使用的。而是需要先通过Binder驱动向ServiceManager中注册服务，表明可以对外提供服务。下面我们看看SurfaceFlinger服务注册发布的具体代码实现：

/frameworks/native/services/surfaceflinger/main_surfaceflinger.cpp/

int main(int, char**) {

…

// When SF is launched in its own process, limit the number of

// binder threads to 4.

ProcessState::self()->setThreadPoolMaxThreadCount(4);

// 1.启动Binder线程池

// start the thread pool

sp ps(ProcessState::self());

ps->startThreadPool();

// instantiate surfaceflinger

sp flinger = surfaceflinger::createSurfaceFlinger();

setpriority(PRIO_PROCESS, 0, PRIORITY_URGENT_DISPLAY);

set_sched_policy(0, SP_FOREGROUND);

// initialize before clients can connect

flinger->init();

// 2.通过IServiceManager::addService在ServiceManager中注册服务，此处服务的名称为“SurfaceFlinger”

// publish surface flinger

sp sm(defaultServiceManager());

sm->addService(String16(SurfaceFlinger::getServiceName()), flinger, false,

IServiceManager::DUMP_FLAG_PRIORITY_CRITICAL | IServiceManager::DUMP_FLAG_PROTO);

// run surface flinger in this thread

flinger->run();

return 0;

}

由此可见，发布Binder服务需要先启动Binder线程池，然后通过IServiceManager::addService在ServiceManager中进行服务的注册。

4.4.3 客户端实现

BpSurfaceComposer需要实现ISurfaceComposer中的所有接口。我们以上文提到的createDisplay接口为例，来看看BpSurfaceComposer::createDisplay方法代码是如何实现的：

/frameworks/native/libs/gui/ISurfaceComposer.cpp/

virtual sp createDisplay(const String8& displayName, bool secure)

{

Parcel data, reply;

// 1.填写服务接口的唯一描述信息descriptor

data.writeInterfaceToken(ISurfaceComposer::getInterfaceDescriptor());

// 2.通过Parcel写入发送参数

data.writeString8(displayName);

data.writeInt32(secure ? 1 : 0);

// 3. 调用remote()->transact将请求发送出去

remote()->transact(BnSurfaceComposer::CREATE_DISPLAY, data, &reply);

return reply.readStrongBinder();

}

这段代码很简单，逻辑就是：通过Parcel写入调用参数进行打包，然后调用remote()->transact将请求发送出去。

4.4.4 获取服务

客户端在使用服务端的服务之前，需要先根据服务的名称向ServiceManager中查询获取到访问服务的句柄，才能通过BpSurfaceComposer::remote()函数拿到远端服务的代理后调用transact方法完成一次Binder数据发送。详细代码如下：

/framworks/native/libs/gui/SurfaceComposerClient.cpp/

void ComposerService::connectLocked() {

// 1. 需要查找的远端Binder服务名称为"SurfaceFlinger"

const String16 name(“SurfaceFlinger”);

// 2 .调用IServiceManager::getService封装接口获取远端服务代理并封装到BpSurfaceComposer中

while (getService(name, &mComposerService) != NO_ERROR) {

usleep(250000);

}

…

}

/frameworks/native/include/binder/IServiceManager.h/

template

status_t getService(const String16& name, sp* outService)

{ // 1. 获取到ServiceManager的代理以访问ServiceManager

const sp sm = defaultServiceManager();

if (sm != nullptr) {

// 2. 通过getService获取具体的服务句柄，并使用interface_cast转换获取到BpSurfaceComposer对象

*outService = interface_cast(sm->getService(name));

if ((*outService) != nullptr) return NO_ERROR;

}

return NAME_NOT_FOUND;

}

/frameworks/native/libs/binder/IServiceManager.cpp/

sp defaultServiceManager()

{

std::call_once(gSmOnce, {

sp sm = nullptr;

while (sm == nullptr) {

//ProcessState::getContextObject(nullptr)获取到ServiceManager的访问句柄

sm = interface_cast(ProcessState::self()->getContextObject(nullptr));

…

}

}

});

return gDefaultServiceManager;

}

/frameworks/native/libs/binder/ProcessState.cpp/

sp ProcessState::getContextObject(const sp& /caller/)

{

// 此处的参数“0”代表查找的是ServiceManager服务，这个是个特殊的地址，用于标识ServiceManager

sp context = getStrongProxyForHandle(0);

…

return context;

}

通过interface_cast这个方法来获取服务的接口对象，由这个方法本身根据是否是在同一个进程，来自动确定返回一个本地Binder还是远程Binder。interface_cast是一个模板方法，其源码如下：

/frameworks/native/libs/binder/include/binder/IInterface.h/

template

inline sp interface_cast(const sp& obj)

{

return INTERFACE::asInterface(obj);

}

对于ISurfaceComposer来说，其实就是ISurfaceComposer::asInterface(obj)，其定义如下：

/frameworks/native/libs/binder/include/binder/IInterface.h/

::android::sp<I##INTERFACE> I##INTERFACE::asInterface( \

const ::android::sp<::android::IBinder>& obj) \

{ \

::android::sp<I##INTERFACE> intr; \

if (obj != nullptr) { \

//1.先使用queryLocalInterface尝试获取本地同一进程中的Binder对象

intr = static_cast<I##INTERFACE*>( \

obj->queryLocalInterface( \

I##INTERFACE::descriptor).get()); \

//2.失败则创建并返回远端Binder对象，封装成BpSurfaceComposer

if (intr == nullptr) { \

intr = new Bp##INTERFACE(obj); \

} \

} \

return intr; \

}

由于都是模板定义，所以在理解的时候，将“##”替换成SurfaceComposer即可。

5 ServiceManager——Binder服务“大管家”

=============================================================================================

ServerManager(简称SM)的功能可以类比互联网中的DNS服务器，“IP地址”为0。每一个Binder服务都需要有一个唯一的名称，由SM来管理这些服务的注册和查找。另外，和DNS服务器本身也是服务器一样，SM也是一个标准的Binder Server，且Binder驱动中，也会通过特定handle = 0这个位置来访问ServiceManager。因此，分析SM我们可以完整的看到一个上层应用如何通过Binder驱动来构建一个Binder Server的过程。下面我们分析SM模块的的具体实现。

5.1 ServiceManager进程的启动

---

SM作为Binder服务的“大管家”，必须要保证在系统所有Binder服务启动之前就已经启动并处于正常工作状态。所以SM是在开机时由init程序解析init.rc加载时直接启动。如下所示：

/framework/native/cmds/servicemanager/servicemanager.rc/

service servicemanager /system/bin/servicemanager// 1.servicemanager是一个独立可执行文件

class core animation

user system

group system readproc

critical

onrestart restart healthd

onrestart restart zygote// 2.servicemanager重启后会导致zygote重启

onrestart restart audioserver

onrestart restart media

onrestart restart surfaceflinger// 3.servicemanager重启后会导致surfaceflinger重启

onrestart restart inputflinger

onrestart restart drm

onrestart restart cameraserver

onrestart restart keystore

onrestart restart gatekeeperd

onrestart restart thermalservice

writepid /dev/cpuset/system-background/tasks

shutdown critical

由上可见，servicemanager是一个独立可执行文件，由C++编写，是一个独立运行的native进程，在系统开机时有init进程直接拉起。源码路径如下：

/framework/native/cmds/servicemanager/*

其main函数主要逻辑如下：

题外话

我们见过很多技术leader在面试的时候，遇到处于迷茫期的大龄程序员，比面试官年龄都大。这些人有一些共同特征：可能工作了7、8年，还是每天重复给业务部门写代码，工作内容的重复性比较高，没有什么技术含量的工作。问到这些人的职业规划时，他们也没有太多想法。

其实30岁到40岁是一个人职业发展的黄金阶段，一定要在业务范围内的扩张，技术广度和深度提升上有自己的计划，才有助于在职业发展上有持续的发展路径，而不至于停滞不前。

不断奔跑，你就知道学习的意义所在！

注意：我们之前因为秋招收集的二十套一二线互联网公司Android面试真题（含BAT、小米、华为、美团、滴滴）和我自己整理Android复习笔记（包含Android基础知识点、Android扩展知识点、Android源码解析、设计模式汇总、Gradle知识点、常见算法题汇总。）

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip204888 （备注Android）

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

em readproc

critical

onrestart restart healthd

onrestart restart zygote// 2.servicemanager重启后会导致zygote重启

onrestart restart audioserver

onrestart restart media

onrestart restart surfaceflinger// 3.servicemanager重启后会导致surfaceflinger重启

onrestart restart inputflinger

onrestart restart drm

onrestart restart cameraserver

onrestart restart keystore

onrestart restart gatekeeperd

onrestart restart thermalservice

writepid /dev/cpuset/system-background/tasks

shutdown critical

由上可见，servicemanager是一个独立可执行文件，由C++编写，是一个独立运行的native进程，在系统开机时有init进程直接拉起。源码路径如下：

/framework/native/cmds/servicemanager/*

其main函数主要逻辑如下：

题外话

我们见过很多技术leader在面试的时候，遇到处于迷茫期的大龄程序员，比面试官年龄都大。这些人有一些共同特征：可能工作了7、8年，还是每天重复给业务部门写代码，工作内容的重复性比较高，没有什么技术含量的工作。问到这些人的职业规划时，他们也没有太多想法。

其实30岁到40岁是一个人职业发展的黄金阶段，一定要在业务范围内的扩张，技术广度和深度提升上有自己的计划，才有助于在职业发展上有持续的发展路径，而不至于停滞不前。

不断奔跑，你就知道学习的意义所在！

注意：我们之前因为秋招收集的二十套一二线互联网公司Android面试真题（含BAT、小米、华为、美团、滴滴）和我自己整理Android复习笔记（包含Android基础知识点、Android扩展知识点、Android源码解析、设计模式汇总、Gradle知识点、常见算法题汇总。）

[外链图片转存中…(img-PCbQOK40-1713642271364)]

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip204888 （备注Android）
[外链图片转存中…(img-x3egJFL3-1713642271364)]

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！