Android Binder机制之一(简介)

shenxiaolinil

已于 2023-02-28 11:42:34 修改

阅读量1.3k

点赞数

分类专栏： Android系统 Binder 文章标签： binder

于 2023-02-10 17:17:25 首次发布

本文链接：https://blog.csdn.net/shenxiaolinil/article/details/128972302

版权

Android系统同时被 2 个专栏收录

13 篇文章

订阅专栏

Binder

1 篇文章

订阅专栏

本文详细介绍了Android的Binder机制，包括其作为主要的进程间通信（IPC）方式，如使用Bundle、Messenger、AIDL等。Binder架构涉及Binder驱动、Binder实体、Binder引用、远程服务和服务管理器等角色。文章还提及从Android8.0开始的Binder拆分，并强调理解Binder对于Android高级开发的重要性。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

3.5 ServiceManager守护进程

四、涉及源码

前言

这是本人第N次看Binder 相关知识了，其实每次看都有新的收获，终于下决心做个专题整理，由于个人系统知识面欠缺，加上Binder本身就错综复杂，如有什么不对或者纰漏，欢迎一起讨论指出。

一、Android 进程间通信方式

1. 使用Bundle，实现序列化Parcel接口，底层基于Binder机制；
2. 使用文件共享，前提是多个进程都具备操作文件的读写权限；
3. 使用Messenger，底层基于Binder机制
4. 使用AIDL，底层基于Binder机制，不同于Messenger，除了数据传输, 还有RPC 能力;
5. 使用ContentProvider，可以通过标准接口来操作跨进程数据，包括增、删、改、查等
6. 使用Socket，Linux中也常用的；

对于大部分开发者来说一个矛盾体，尤其是对于想在Android中想更上一层楼的小伙们来说这个IPC是既爱又恨，爱的是它极大方便了我们的开发，恨的是它为啥那么复杂而又繁琐呢！但是又不得不学好Binder因为它是迈向Android高阶开发的必经之路。

当然AOSP 一直在迭代, 从Android 8.0 开始，Binder机制，被拆分成了Binder(System分区进程间通信)、HwBinder(支持System/Vendor分区进程间通信)、VndBinder(Vendor分区进程间通信)。目前我们还是重点关注Binder部分，其他的后续再补充。

借用gityuan之前总结一句话: "无Binder不Android"。

二、Binder架构图

Binder通信采用传统的C/S架构，清晰明朗，Server端与Client端相对独立，稳定性较好。
Binder架构中设计4类角色：Binder驱动，ServiceManager(后续简称SMgr)，Server和Client。其中Server，Client，SMgr运行于用户空间，驱动运行于内核空间

--架构图引用gityuan

Binder机制的实现具有两层含义：
(1)IPC(Inter-Process Communication)，即实现进程间通信。
(2)RPC(Remote Procedure Call),是一种远程过程调用手段

在上图中Binder框架中也实现了如上两层调用：

1) Client先和Server先建立进程间IPC通信
2) Client在和Server建立IPC通信之后，就能如果实现本地服务一样通过RPC调用使用远端Server

这四个角色的关系和互联网非常类似：Server是服务器，Client是客户终端，SMgr是域名服务器（DNS），驱动是路由器。其中四者之间关系有点类似下面的网络关系图：

在这里插入图片描述参考：一次HTTPS请求的过程

三、Binder涉及角色

3.1 Binder驱动

Binder 驱动就如同路由器(DNS)一样，是整个通信的核心，Binder驱动是Android专用的，但底层的驱动架构与Linux驱动一样。binder 驱动在以misc设备进行注册，作为虚拟字符设备，没有直接操作硬件，只是对设备内存的处理。该驱动负责进程之间 Binder 通信的建立，数据在各进程之间的传递，Binder 引用计数管理，数据包在进程之间的传递和交互等一系列底层支持。

3.2 Binder实体

Binder实体，是各个Server以及ServiceManager在内核中的存在形式。Binder实体实际上是内核中binder_node结构体的对象，它的作用是在内核中保存Server和ServiceManager的信息(例如，Binder实体中保存了Server对象在用户空间的地址)。简言之，Binder实体是Server在Binder驱动中的存在形式，内核通过Binder实体可以找到用户空间的Server对象。
如上图中，Server和ServiceManager在Binder驱动中都对应的存在一个Binder实体。

3.3 Binder引用

说到Binder实体，就不得不说"Binder引用"。所谓Binder引用，实际上是内核中binder_ref结构体的对象，它的作用是在表示"Binder实体"的引用。换句话说，每一个Binder引用都是某一个Binder实体的引用，通过Binder引用可以在内核中找到它对应的Binder实体。
如果将Server看作是Binder实体的话，那么Client就好比Binder引用。Client要和Server通信，它就是通过保存一个Server对象的Binder引用，再通过该Binder引用在内核中找到对应的Binder实体，进而找到Server对象，然后将通信内容发送给Server对象。

Binder实体和Binder引用都是内核(即，Binder驱动)中的数据结构。每一个Server在内核中就表现为一个Binder实体，而每一个Client则表现为一个Binder引用。这样，每个Binder引用都对应一个Binder实体，而每个Binder实体则可以多个Binder引用(多个进程持有)。

3.4 远程服务

Server都是以服务的形式注册到ServiceManager中进行管理的。如果将Server本身看作是"本地服务"的话，那么Client中的"远程服务"就是本地服务的代理。如果你对代理模式比较熟悉的话，就很容易理解了，远程服务就是本地服务的一个代理，通过该远程服务Client就能和Server进行通信。

3.5 ServiceManager守护进程

ServiceManager是用户空间的一个守护进程。当该应用程序启动时，它会和Binder驱动进行通信，告诉Binder驱动它是服务管理者；对Binder驱动而言，它则会新建ServiceManager对应的Binder实体，并将该Binder实体设为全局变量。

四、涉及源码

1)binder驱动                        /kernel/drivers/android/*

2)servicemanager /frameworks/native/cmds/servicemanager/*

3)libbinder   /frameworks/native/libs/binder/*

4)JAVA层                             /frameworks/base/core/java/android/os/*

4.1 Java framework

/framework/base/core/java/android/os/  
    - IInterface.java
    - IBinder.java
    - Parcel.java
    - IServiceManager.java
    - ServiceManager.java
    - ServiceManagerNative.java
    - Binder.java  


/framework/base/core/jni/    
    - android_os_Parcel.cpp
    - AndroidRuntime.cpp
    - android_util_Binder.cpp (核心类)

4.2 Native framework

/framework/native/libs/binder         
    - IServiceManager.cpp
    - BpBinder.cpp
    - Binder.cpp
    - IPCThreadState.cpp (核心类)
    - ProcessState.cpp  (核心类)

/framework/native/include/binder/
    - IServiceManager.h
    - IInterface.h

/framework/native/cmds/servicemanager/
    - service_manager.c
    - binder.c

4.3 Kernel

/kernel/drivers/staging/android/
    - binder.c
    - uapi/binder.h