IPC常见方式

image.png

1. Bundle

• 优点： 简单易用
• 缺点： 只能传输Bundle支持的数据类型
• 使用场景： 四大组件间的进程间通信

2. 文件共享

• 优点 简单易用
• 缺点 不适合高并发场景，无法做到即时通信
• 使用场景： 无并发访问请教，简单交换的数据实时性不高的场景

3. AIDL

• 优点：功能强大，支持一对多并发通信，支持实时通信
• 缺点： 使用复杂些
• 使用场景： 一对多，RPC需求

4. ContentProvider

• 优点： 在数据源访问方面功能强大，支持一对多并发数据共享，可通过Call方法扩展其他操作
• 缺点 受约束的AIDL，主要提供数据源的CRUD操作
• 使用场景： 一对多的进程间数据共享

5. Socket

• 优点功能强大，可以通过网络传输字节流，支持一对多并发实时通信
• 缺点 实现细节稍微有点麻烦，不支持直接RPC
• 使用场景： 数据交换

Binder是什么？

Binder是Android提供的一套进程间相互通信框架
系统服务ActivityManagerService,LocationManagerService，等都是在单独进程中的，使用binder和应用进行通信。

Android系统框架

image.png

Android系统分成三层。最上层是application应用层，第二层是Framework层，第三层是native层。
由下图可知几点：

1. Android中的应用层和系统服务层不在同一个进程，系统服务在单独的进程中。

2. Android中不同应用属于不同的进程中。

Android应用和系统services运行在不同进程中是为了安全，稳定，以及内存管理的原因，但是应用和系统服务需要通信和分享数据。

优点

• 安全性：每个进程都单独运行的，可以保证应用层对系统层的隔离。
• 稳定性：如果某个进程崩溃了不会导致其他进程崩溃。
• 内存分配：如果某个进程以及不需要了可以从内存中移除，并且回收相应的内存。

Binder通信

image.png

一个进程是不能直接直接操作另一个进程的，比如说读取另一个进程的数据，或者往另一个进程的内存空间写数据，进程之间的通信要通过内核进程才可以
client和service并不想知道binder相关协议，所以进一步client通过添加proxy代理，service通过添加stub来进一步处理与binder的交互。

Activity请求Activity ManagerService服务为例：

• ActivityManagerService通过调用serviceManager中的addService方法，然后调用ServiceManagerNative类中的addservice(name)方法。

• ServiceManagerNative会通过Binder发送一条SVG_MGR_ADD_SERVICE的指令，然后通过svcmgr_handler()调用do_add_service（）方法往svc_list中添加相应的service。

• client要请求服务，比如说在activity中调用context.getSystemService()方法，这个时候serviceManager就会使用getService（name），然后就会调用到native层中的ServiceManagerNative类中的getService(name)方法。

• ServiceManagerNative会通过Binder发送一条SVG_MGR_GET_SERVICE的指令，然后通过svcmgr_handler()调用do_find_service（）方法去svc_list中查找到相关的service。

• 查找到相应的服务后就会通过Binder将服务传给ServiceManagerNative，然后传给serviceManager，最后client就可以使用了。

服务是在svclist中保存的，svclist是一个链表，因此客户端调用的服务必须要先注册到svclist中。

Binder结构设计

image.png

• Java层AIDL
• Framework层， Android.os.Binder
• Native 层: libBinder.cpp
• 内核层的通信都是通过ioctl来进行的，client打开一个ioctl,进入到轮询队列，一直阻塞直到时间到或者有消息。

Binder中使用的设计模式

1、代理模式（Proxy Pattern ）
在Android中client不是直接去和binder打交道，client直接和Manager交互，而manager和managerProxy交互，也就是说client是通过managerProxy去和binder进行交互的。同时service也不是直接和binder交互，而是通过stub去和binder交互。

Binder与内存映射mmap

Binder IPC 是基于内存映射（mmap）来实现的，但是 mmap() 通常是用在有物理介质的文件系统上的。
进程中的用户区域是不能直接和物理设备打交道的，如果想要把磁盘上的数据读取到进程的用户区域，需要两次拷贝（磁盘–>内核空间–>用户空间）；通常在这种场景下 mmap() 就能发挥作用，通过在物理介质和用户空间之间建立映射，减少数据的拷贝次数，用内存读写取代I/O读写，提高文件读取效率。

而 Binder 并不存在物理介质，因此 Binder 驱动使用 mmap() 并不是为了在物理介质和用户空间之间建立映射，而是用来在内核空间创建数据接收的缓存空间。

一次完整的 Binder IPC 通信过程通常是这样：

• 首先 Binder 驱动在内核空间创建一个数据接收缓存区；
• 接着在内核空间开辟一块内核缓存区，建立内核缓存区和内核中数据接收缓存区之间的映射关系，以及内核中数据接收缓存区和接收进程用户空间地址的映射关系；
• 发送方进程通过系统调用 copyfromuser() 将数据 copy 到内核中的内核缓存区，由于内核缓存区和接收进程的用户空间存在内存映射，因此也就相当于把数据发送到了接收进程的用户空间，这样便完成了一次进程间的通信。

Binder传输数据的大小限制

Activity之间传输BitMap的时候，如果Bitmap过大，就会引起问题，比如崩溃等，这其实就跟Binder传输数据大小的限制有关系，在上面的一次拷贝中分析过，mmap函数会为Binder数据传递映射一块连续的虚拟地址，这块虚拟内存空间其实是有大小限制的

普通的由Zygote孵化而来的用户进程，所映射的Binder内存大小是不到1M的，准确说是 110241024) - (4096 *2) ：这个限制定义在ProcessState类中，如果传输说句超过这个大小，系统就会报错，因为Binder本身就是为了进程间频繁而灵活的通信所设计的，并不是为了拷贝大数据而使用的：

系统服务与bindService等启动的服务的区别

image.png

服务可分为系统服务与普通服务
服务的启动方式 ：

• 系统服务一般是在系统启动的时候，由SystemServer进程创建并注册到ServiceManager中的，这些服务本身其实实现了Binder接口，作为Binder实体注册到ServiceManager中，被ServiceManager管理，而SystemServer进程里面会启动一些Binder线程，主要用于监听Client的请求，并分发给响应的服务实体类，可以看出，这些系统服务是位于SystemServer进程中

• bindService类型的服务，这类服务一般是通过Activity的startService或者其他context的startService启动的，这里的Service组件只是个封装，主要的是里面Binder服务实体类，这个启动过程不是ServcieManager管理的，而是通过ActivityManagerService进行管理的

服务的注册与管理：

• 系统服务一般都是通过ServiceManager的addService进行注册的，这些服务一般都是需要拥有特定的权限才能注册到ServiceManager
• bindService启动的服务可以算是注册到ActivityManagerService，只不过ActivityManagerService管理服务的方式同ServiceManager不一样，而是采用了Activity的管理模型，详细的可以自行分析

使用方式：

• 使用系统服务一般都是通过ServiceManager的getService得到服务的句柄，这个过程其实就是去ServiceManager中查询注册系统服务。
• 而bindService启动的服务，主要是去ActivityManagerService中去查找相应的Service组件，最终会将Service内部Binder的句柄传给Client。

Binder请求的同步与异步？

• 在单次Binder数据传递的过程中，其实都是同步的。只不过，Client在请求Server端服务的过程中，是需要返回结果的，即使是你看不到返回数据，其实还是会有个成功与失败的处理结果返回给Client，这就是所说的Client端是同步的。
• 服务端是异步的，可以这么理解：在服务端在被唤醒后，就去处理请求，处理结束后，服务端就将结果返回给正在等待的Client线程，将结果写入到Client的内核空间后，服务端就会直接返回了，不会再等待Client端的确认，这就是所说的服务端是异步的，

Android APP有多少Binder线程，是固定的么？

Android APP上层应用的进程一般是开启一个Binder线程，而对于SystemServer或者media服务等使用频率高，服务复杂的进程，一般都是开启两个或者更多。驱动会根据目标进程中是否存在足够多的Binder线程来告诉进程是不是要新建Binder线程。

Binder如何精确制导，找到目标Binder实体，并唤醒进程或者线程？

• 首先Service会通过addService将binder实体注册到ServiceManager中去，Client如果想要使用Servcie，就需要通过getService向ServiceManager请求该服务。
• 在Service通过addService向ServiceManager注册的时候，ServiceManager会将服务相关的信息存储到自己进程的Service列表中去，同时在ServiceManager进程的binder_ref红黑树中为Service添加binder_ref节点，这样ServiceManager就能获取Service的Binder实体信息。
• 当Client通过getService向ServiceManager请求该Service服务的时候，ServiceManager会在注册的Service列表中查找该服务，如果找到就将该服务返回给Client，在这个过程中，ServiceManager会在Client进程的binder_ref红黑树中添加binder_ref节点，可见本进程中的binder_ref红黑树节点都不是本进程自己创建的，要么是Service进程将binder_ref插入到ServiceManager中去，要么是ServiceManager进程将binder_ref插入到Client中去。
• Client就能通过Handle句柄获取binder_ref，进而获取到binder_proc与binder_node信息，之后Client便可有目的的将binder_transaction事务插入到binder_proc的待处理列表，进而访问Service服务。
• ServiceManager是比较特殊的服务，所有应用都能直接使用，因为ServiceManager对于Client端来说Handle句柄是固定的，都是0，所以ServiceManager服务并不需要查询，可以直接使用。

参考链接：
https://blog.csdn.net/happylishang/article/details/62234127
https://www.jianshu.com/p/adaa1a39a274