前言
移动设备的操作系统阵营之一的Android，底层基于Linux内核，中间为Native&Runtime层和Framework层。我们知道Linux本身有着很成熟的IPC（进程间通信）机制，比如管道、消息队列、共享内存、socket、信号和信号量等。然而，Android却使用Binder来作为它的IPC的方案，这是为何呢？接下来，就把我之前学习Binder的心得写下来。
WhatWhyHow
What — Binder是什么
Binder起源于OpenBinder。
官方正式的说，Binder是Android跨进程通信的方式，采用了C/S架构。主要包括4个组件，Client、Server、ServiceManager和Binder驱动。其中Client、Server和ServiceManager运行在用户空间，Binder驱动运行在内核空间。
说完了没说一样是吧。说白了其实Binder对于Android来说就像是电话对于人一样，用于通信的。其中Client、Server、ServiceManager和Binder驱动就是电话内部的几个组成组件。
Client：进程间通信的客户端
Server：进程间通信的服务端
ServiceManager：Binder服务的大管家，它是一个守护进程，Client端和Server端的相互通信都需要借助于它。
下面这张图就是Binder的工作原理：
可以看出无论是服务的注册还是服务的获取，都需要ServiceManager。
Why — 为何使用Binder
刚刚提到说，Android底层基于Linux内核，Linux已经包含了好多成熟的进程间通信的方案，为何要选用Binder呢？
这里从我总结的几点说。
1. 性能：Binder在一次通信中只进行一次内存拷贝。而管道、消息队列、socket等都需要2次内存拷贝，可别小看这一倍带来的差距。对于移动设备来说，性能一直是个大问题。想象一下，如果选用管道作为IPC的方案的话，那么Android绘制屏幕的时候都需要与WindowManager进行IPC通信，如果这里效率不高，势必会造成卡顿甚至于app卡死。
当然了，共享内存的方式压根就不需要内存拷贝，但是共享内存在实际写代码会非常复杂，需要频繁的加锁释放锁，稍有不慎就会造成死锁。
所以从性能的角度来说，Binder的性能仅次于共享内存。
IPC方式
内存拷贝次数
socket/管道/消息队列
2
共享内存
0
Binder
1
2. 安全性：Android作为开源的移动端操作系统，拥有非常多的开发平台，有用于手机设备，有用于智能穿戴设备，也有嵌入式及其机器人平台。同时运行的app来源也很多，很多不正规的第三方app都可以发布、安装到Android上，因此手机安全性显得尤为重要。
通义听悟
阿里云通义听悟是聚焦音视频内容的工作学习AI助手，依托大模型，帮助用户记录、整理和分析音视频内容，体验用大模型做音视频笔记、整理会议记录。
85 查看详情 
而Linux传统的IPC的方案，接收方都无法获取对方进程的身份，无法判断对方是否可靠，Linux传统的IPC方案没有任何保护措施。
在Android系统中，Android为每一个安装的app都分配了一个UID标识，这个UID就作为鉴别对方进程身份的重要标志。而Binder采用的C/S架构，系统只暴露了Client端，不会暴露Server端。实际通信中Server端会判断对方进程的UID是否满足权限（在Android 6.0以上的系统，都是通过弹窗询问）。传统的IPC方案只能在用户空间的数据包里填充UID，只能在用户空间定义协议。Binder可以在Binder驱动程序中进行分配和填充记录UID的操作，也就是说，Binder机制对于通信双方的身份是在内核中进行校验支持的，安全性更高。
3. 灵活性：Binder采用的C/S架构，Client端和Server端实则都借助于ServiceManager，在我看来ServiceManager相当于控制和服务中心，有着统一中心化管理的能力，在ServiceManager注册服务后，就可以统一的发布Service供其他进程使用。所以它更加的灵活。
4. 稳定性：相较于Linux传统IPC方案，共享内存虽然性能更好，但是操作起来复杂，需要控制好锁以及各种同步的场景，稍有不慎就会死锁；而B/S架构的模式，像管道/消息队列还得进行包装。而Binder采用C/S架构，稳定性更好。
通过上述的4点，Binder就很适合作为Android系统的IPC方案了。
How — Binder的架构
这里先放出Binder通信架构图：
一次Binder通信过程会涉及到app层、Framework层、Native层和Kernel层，算是把Android的架构从上到下走了个遍。假设已经创建了自己的Client、Service类，并且在Client端持有Service的引用，并且申请调用Service的A函数，那么在Android系统内部的调用过程是这样的：
从调用过程上看可以发现，当Client端发起请求后，Client端的当前线程会挂起。这里需要注意，如果Server端进程需要执行长时间的操作的话，最好不要在UI线程里做以免发生ANR。
接下来说说Binder的C/S架构。我们知道Android系统在开机启动过程中Zygote创建后会fork出system_server进程，然后由system_server进程会孵化出大量的系统服务，分为引导服务、核心服务和其他服务（这里后续会出一篇文章具体介绍）。那么在Android系统中是怎么管理这些服务的，并且让用户可以跨进程调用这些服务呢？
调用系统服务的过程：Android在开机过程初始化所有的Service后，会将这些Service向ServiceManager注册，Client端想要申请具体的Service将直接向ServiceManager要就行了。具体做法是Client端首先向ServiceManager查询，得到具体的Service的引用，然后通过这个引用向具体的Server端发送请求，Server端执行完成后就返回。
而这里有个问题，Client端持有Service的引用，然后调用具体Server端的某个函数，一次Binder请求就完成了。可是Client端和Server端的这两个进程之间是怎么共享资源的呢？聪明的读者一定都猜到了，没错，就是通过Binder驱动。
当Client向Server发请求时，Client会先从自己的进程空间把请求数据拷贝到内核空间，然后因为Server和内核共享数据，所以这里不需要再进行拷贝，直接通过内存地址偏移量获得请求数据地址，并通知Server端执行onTransact()函数，这个函数属于Binder类，当Server端进程执行完毕后将结果写入自己的共享内存中，Binder驱动再将结果拷贝到Client端的进程空间，并唤醒Client端的线程。
接下来说说Binder驱动。用户态程序通过系统调用陷入内核态，比如打开Binder驱动方法的调用链为：open() –> __open() –> binder_open()。open()为用户态方法，__open()为系统调用，通过系统调用表查找到对应内核Binder驱动的binder_open()方法。
Binder驱动有几个核心的方法：
binder_init：主要工作是注册misc设备。binder_open：打开Binder驱动设备。期间会创建binder_proc对象（管理着IPC所需的各种信息）。binder_mmap：在内核虚拟地址空间申请一块与用户虚拟内存相同大小的内存；然后再申请1个page大小的物理内存，再将同一块物理内存分别映射到内核虚拟地址空间和用户虚拟内存空间，从而实现了用户空间的Buffer和内核空间的Buffer同步操作的功能。刚刚讲C/S架构时提到Server端不需要拷贝，Server和内核空间共享一块空间主要就是通过binder_mmap()来实现的。binder_ioctl：负责在两个进程间收发IPC数据和IPC reply数据。
具体的源码分析这里就不展开了。
Binder机制运用。首先看一下下面2行代码：
代码语言：javascript代码运行次数：0运行复制
TelephonyManager telephonyManager = (TelephonyManager) getSystemService(Context.TELEPHONY_SERVICE); String deviceId = telephonyManager.getDeviceId();getSystemService(Context.TELEPHONY_SERVICE)在Android系统内部会向ServiceManager查询标识为TELEPHONY_SERVICE的Server端对象的引用。即TelephonyManager对象的引用，这个引用的真正实现是TelephonyManager的某个代理。得到这个引用后，调用getDeviceId时，真正的实现是在代理里面，代理把参数、数据等打包到Parcel对象中，然后调用transact函数（该函数继承于Binder），之后就会触发Binder驱动做一些列操作，Client端把数据拷贝到内核空间，然后Server端接收，执行完相应的操作（这里是getDeviceId）后把结果映射到内核空间，然后内核再拷贝到Client端的进程空间中从而完成这次Binder IPC调用。
总结
这篇文章记录了个人学习Android Binder的见解，算是一个概要性的学习记录和总结。因为毕竟写的比较简单，也还没有从Android源码来分析，因为Binder贯穿着整个Android系统。如果想全部写明白要写好几篇文章。后续应该会出专门的几篇文章从源码入手，详细的阐述Android Binder。
作者的话
个人喜欢计算机技术，主要涉及的领域包括：Android系统，Linux内核，嵌入式软/硬件，机器人和智能硬件。同时也对其他的各个技术栈都感兴趣。
同时也很喜欢生活，喜欢享受生活，喜欢用拍照和视频的方式来记录生活。
如果你也是个爱学习爱技术的人，欢迎一起探讨，没准，咱们能成为好朋友。如果觉得本文有哪些不对的地方，欢迎指出，大家一起学习进步。
以上就是Android进程间通信 — Binder学习记录的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/300202.html
微信扫一扫 
支付宝扫一扫 
