Android面试：挂了三次的ServiceManager-工作原理，这次怎么也得整的明明白白！

最新推荐文章于 2024-04-21 23:46:36 发布

2401_84103344

最新推荐文章于 2024-04-21 23:46:36 发布

阅读量813

点赞数 18

分类专栏： 2024年程序员学习文章标签： android 面试职场和发展

本文链接：https://blog.csdn.net/2401_84103344/article/details/137944477

版权

2024年程序员学习专栏收录该内容

183 篇文章 0 订阅

订阅专栏

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

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

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

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

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

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

正文

ServiceManager 是为了完成 Binder Server 的 Name（域名）和 Handle（IP 地址）之间对应关系的查询而存在的，它主要包含的功能：

查询：其他应用可以根据 Server 的 Name 查询到对应的 Service Handle

但 ServiceManager 自身也是一个 Binder Server（服务器），怎么找到它的 "IP 地址"呢？Binder 机制对此做了特别规定：ServiceManager 在 Binder 通信过程中的 Handle 永远是 0。

ServiceManager 启动原理

Android 系统第一个启动的 init 进程解析 init.rc 脚本时构建出系统的初始运行状态，Android 系统服务大多是在这个脚本中描述并被相继启动的，包括 zygote、mediaserver、surfaceflinger 以及 servicemanager 等，其中 servicemanager 描述如下：

#init.rc
service servicemanager /system/bin/servicemanager
class core
user system
group system
critical
onrestart restart healthd
onrestart restart zygote
onrestart restart media
onrestart restart surfaceflinger
onrestart restart drm

可以看到，当 ServiceManager 发生问题重启时，其他 healthd、zygote、media 等服务也会被重启。ServiceManager 服务启动后会执行 service_manager.c 的 main 函数，关键代码如下：

//frameworks/native/cmds/servicemanager/service_manager.c
int main(){
bs = binder_open(128*1024);
if (binder_become_context_manager(bs)) {
…
}
…
binder_loop(bs, svcmgr_handler);
return 0;
}

其中三个函数对应了 ServiceManager 初始化的三个关键工作：

binder_open()：打开 binder 驱动并映射内存块大小为 128KB
binder_become_context_manager()：将自己设置为 Binder “DNS” 管理者
binder_loop()：进入循环，等待 binder 驱动发来消息

下面分别来分析这三个函数，首先来看 binder_open() 是怎么打开 binder 驱动并映射内存的：

struct binder_state *binder_open(size_t mapsize){
struct binder_state *bs;
struct binder_version vers;
bs = malloc(sizeof(*bs));
…
//打开 binder 驱动，最终调用 binder_open() 函数
bs->fd = open(“/dev/binder”, O_RDWR | O_CLOEXEC);
…
//获取 Binder 版本，最终调用 binder_ioctl() 函数
ioctl(bs->fd, BINDER_VERSION, &vers)
…
//将虚拟内存映射到 Binder，最终调用 binder_mmap() 函数
bs->mapped = mmap(NULL, mapsize, PROT_READ, MAP_PRIVATE, bs->fd, 0);
…
return bs;
}

再来看 binder_become_context_manager() 是怎么将自己设置为 Binder “DNS 管理者的”：

int binder_become_context_manager(struct binder_state *bs){
//发送 BINDER_SET_CONTEXT_MGR 命令，最终调用 binder_ioctl() 函数
return ioctl(bs->fd, BINDER_SET_CONTEXT_MGR, 0);
}

最后来看 binder_loop() 是怎么循环等待并处理 binder 驱动发来的消息：

void binder_loop(struct binder_state *bs, binder_handler func){
int res;
//执行 BINDER_WRITE_READ 命令所需的数据格式：
struct binder_write_read bwr;
uint32_t readbuf[32]; //每次读取数据的大小
readbuf[0] = BC_ENTER_LOOPER;
//先将 binder 驱动的进入循环命令发送给 binder 驱动：
binder_write(bs, readbuf, sizeof(uint32_t));
for (;😉 { //进入循环
bwr.read_size = sizeof(readbuf);
//读取到的消息数据存储在 readbuf
bwr.read_buffer = (uintptr_t) readbuf;
//执行 BINDER_WRITE_READ 命令读取消息数据
res = ioctl(bs->fd, BINDER_WRITE_READ, &bwr);
if (res < 0) {
ALOGE(“binder_loop: ioctl failed (%s)\n”, strerror(errno));
break;
}
//处理读取到的消息数据
res = binder_parse(bs, 0, (uintptr_t) readbuf, bwr.read_consumed, func);
…
}
}

BINDER_WRITE_READ 命令既可以用来读取数据也可以写入数据，具体是写入还是读取依赖 binder_write_read 结构体的 write_size 和 read_size 哪个大于 0，上面代码通过 bwr.read_size = sizeof(readbuf) 赋值，所以是读取消息。

binder_parse() 方法内部处理由 binder 驱动主动发出的、一系列 BR_ 开头的命令，包括上面提到过的 BR_TRANSACTION、BR_REPLY 等，简化后的代码如下：

int binder_parse(struct binder_state *bs, struct binder_io *bio,
uintptr_t ptr, size_t size, binder_handler func){
switch(cmd) {
case BR_TRANSACTION: {
…
res = func(bs, txn, &msg, &reply); //处理消息
//返回处理结果
inder_send_reply(bs, &reply, txn->data.ptr.buffer, res);
…
break;
}
case BR_REPLY: {…}
case BR_DEAD_BINDER: {…}
…
}