Linux现有的所有进程间IPC方式：

1. 管道

什么是管道？

管道可用于具有亲缘关系进程间的通信，**管道是由内核管理的一个缓存区**，相当于我们放入内存中的一个纸条。

管道的一端连接一个进程的输出。这个进程会向管道中放入信息。

管道的另一端连接一个进程的输入，这个进程取出被放入管道的信息。

缓冲区不需要很大，**它被设计成环形的数据结构**，以便管道可以被循环利用。当管道中没有信息的时候，从管道中读取的进程会等待，直到另外一端的进程放入信息。当管道被放满信息的时候，尝试放入信息的进程会等待，直到另一端的进程取出信息。当两个进程都终结的时候，管道也自动消失。

缺点：在创建时分配一个管道，缓冲区的大小比较有限；并不适合Android大量的进程通信。

消息队列

消息队列提供了一种从一个进程向另一个进程发送一个数据块的方法。

每个数据块都被认为含有一个类型，接收进程可以独立地接收含有不同类型的数据结构。

我们可以通过发送消息来避免命名管道的同步和阻塞问题。但是消息队列与命名管道一样，每个数据块都有一个最大长度限制。

缺点：信息复制两次，额外的CPU消耗；不适合频繁或信息量大的通信。
共享内存

共享内存就是允许两个不相关的进程访问同一个逻辑内存。

共享内存是在两个正在运行的进程之间共享和传递数据的一种非常有效的方式。

不同进程之间共享的内存通常安排为同一段物理内存。进程可以将同一段共享内存连接到它们自己的地址空间中，所有进程都可以访问共享内存中的地址。

无需复制，共享缓冲区直接附加到进程虚拟地址空间，速度快。

缺点：通信需要设计复杂的机制保证各个进程通讯有效性。进程间的同步问题操作系统无法实现，必须各进程利用同步工具解决；安全问题比较突出，如果Android采用无异于将每个App放在一个内存中，这样非常不安全
套接字

作为更通用的接口，传输效率低，主要用于不同机器或跨网络的通信。
信号量

常作为一种锁机制，防止某进程正在访问共享资源时，其他进程也访问该资源。因此，主要作为进程间以及同一进程内不同线程之间的同步手段。
信号

不适用于信息交换，更适用于进程中断控制，比如非法内存访问，杀死某个进程等

Binder机制的优点

从性能的角度数据拷贝次数：

Binder数据拷贝只需要一次，而管道、消息队列、Socket都需要2次，但共享内存方式一次内存拷贝都不需要；从性能角度来看，Binder性能仅次于共享内存。
从稳定性的角度

Binder是基于C/S架构的，架构清晰明朗，Server端与Client端相对独立，稳定性较好；而共享内存实现方式复杂，没有客户与服务端之别，需要充分考虑到访问临界资源的并发同步问题，否则可能会出现死锁等问题；从稳定性角度看，Binder架构优越于共享内存。
从安全的角度

传统的Linux IPC的接收方无法获得对方进程可靠的UID/PID，从而无法鉴别对方身份；而Android作为一个开放的开源体系，拥有非常多的开发平台，App来源甚广，因此手机安全显得额外重要；对于普通用户，绝不希望从App商店下载偷窥隐射数据、后台造成手机耗电等等问题，传统Linux IPC无任何保护措施，完全由上层协议来确保。

Android为每个安装好的应用程序分配了自己的UID，故进程的UID是鉴别进程身份的重要标志，前面提到C/S架构，Android系统中对外只暴漏Client端，Client端将任务发送给Server端，Server端会根据权限控制策略，判断UID/PID是否满足访问权限，目前权限控制很多时候是通过弹出权限询问对话框，让用户选择是否运行。
从语言层面的角度

Linux是基于C语言，而Android是基于java语言的。而对于Binder恰恰也符合面向对象的思想，将进程间通信转化为通过对某个Binder对象的引用调用该对象的方法，而其独特之处在于Binder对象是一个可以跨进程引用的对象，它的实体位于一个进程中，而它的引用却遍布于系统的各个进程之中。可以从一个进程传给其它进程，让大家都能访问同一Server，就像将一个对象或引用赋值给另一个引用一样。Binder模糊了进程边界，淡化了进程间通信过程，整个系统仿佛运行于同一个面向对象的程序之中。
从公司战略的角度