三、IPC常用方式

那时间总是跑得很潇洒

已于 2024-01-14 09:52:57 修改

阅读量910

点赞数 16

分类专栏： Android 合集文章标签： android

于 2024-01-06 13:37:20 首次发布

本文链接：https://blog.csdn.net/qq_31654025/article/details/135425145

版权

8 篇文章 1 订阅

订阅专栏

IPC常用方式

在平时的开发中，大部分时候都在编写单个App，每个App就是个进程。如果App之间需要通信，即进程间通信(IPC，InterProcess Communication)。实现进程间通信通常有两种方法：共享物理内存、通过内核中转。

共享内存，属于共享物理内存方式，多个进程可以共享同一段物理内存，当某个进程改变内存内容时，其它进程都能够知道。此种方式无需拷贝内容，但是需要信号量进行进程间同步。
在这里插入图片描述

管道、消息队列、套接字（socket）
在这里插入图片描述

先将A发送的内容拷贝到内核，这过程可以理解为存储，再从内核拷贝到B的用户空间，这过程可以理解为转发，因此一次"存储-转发"过程需要两次内容拷贝。

进程A给进程B发送一段信息，流程如下：

从上可知，通过Binder，进程A给进程B发送信息只进行了一次数据拷贝。
在这里插入图片描述

效率：传输效率主要影响因素是内存拷贝的次数，拷贝次数越少，传输速率越高。从Android进程架构角度分析：对于消息队列、Socket和管道来说，数据先从发送方的缓存区拷贝到内核开辟的缓存区中，再从内核缓存区拷贝到接收方的缓存区，一共两次拷贝。对于Binder来说，数据从发送方的缓存区拷贝到内核的缓存区，而接收方的缓存区与内核的缓存区是映射到同一块物理地址的，节省了一次数据拷贝的过程：共享内存不需要拷贝，Binder的性能仅次于共享内存。
稳定性：上面说到共享内存的性能优于Binder，那为什么不采用共享内存呢，因为共享内存需要处理并发同步问题，容易出现死锁和资源竞争，稳定性较差。 Binder基于C/S架构，Server端与Client端相对独立，稳定性较好。
安全性：传统Linux IPC的接收方无法获得对方进程可靠的UID/PID，从而无法鉴别对方身份；而Binder机制为每个进程分配了UID/PID，且在Binder通信时会根据UID/PID进行有效性检测。

如下图，实现一个简单四则运算功能，输入两个数字，绑定服务后，点击对应的运算符按钮，客户端把计算的两个数字和计算方法发送给服务端，服务端将结果计算出来并返回给客户端，最后客户端将结果展现在界面上。
在这里插入图片描述

动画功能演示如下：
在这里插入图片描述

UML类图如下：

在这里插入图片描述

运行流程：

在这里插入图片描述

客户端发起绑定请求（界面点击bind calculator binder service按钮，调用bindService函数）；
服务器接收绑定请求，调用onBind函数，在onBind函数中将CalculatorServiceBinder引用返回；
客户端调用onServiceConnected函数，拿到CalculatorServiceBinder引用（与服务端返回的CalculatorServiceBinder不是同一个）；
点击四个运算符按钮（调用calculatorServiceBinder.transact函数，将请求发送给服务端）；
服务端调用onTransact实现逻辑，并将结果返回；