为什么 Android 要采用 Binder 作为 IPC 机制？
Android 的内核也是基于 Linux 内核，Linux 中已经有很多成熟的 IPC 机制，为何不直接采用 Linux 现有的进程 IPC 方案还要另起炉灶采用 Binder 机制呢？
首先先概括下 Linux 现有的进程间通信的方式：
- 管道：在创建时分配一个page大小的内存，缓存区大小比较有限；
- 消息队列：信息会复制两次，造成额外的CPU消耗；不适合频繁或信息量大的通信；
- 共享内存：无须复制，共享缓冲区直接附加到进程虚拟地址空间，速度快；但进程间的同步问题操作系统无法实现，必须各进程利用同步工具解决；
- 套接字：作为更通用的接口，传输效率低，主要用于不通机器或跨网络的通信；
- 信号量：常作为一种锁机制，防止某进程正在访问共享资源时，其他进程也访问该资源。因此，主要作为进程间以及同一进程内不同线程之间的同步手段。
- 信号: 不适用于信息交换，更适用于进程中断控制，比如非法内存访问，杀死某个进程等；
接下来从性能、稳定性、安全等角度进行分析：
1、从性能的角度 数据拷贝次数：Binder 数据拷贝只需要一次，而管道、消息队列、Socket 都需要 2 次，但共享内存方式一次内存拷贝都不需要；从性能角度看，Binder 性能仅次于共享内存。、
2、从稳定性的角度：Binder是基于C/S架构的，Client端有什么需求，直接发送给Server端去完成，架构清晰明朗，Server端与Client端相对独立，稳定性较好；而共享内存实现方式复杂，没有客户与服务端之别， 需要充分考虑到访问临界资源的并发同步问题，否则可能会出现死锁等问题；从这稳定性角度看，Binder架构优越于共享内存。
仅仅从以上两点，各有优劣，还不足以支撑google去采用binder的IPC机制，那么更重要的原因是：
3、从安全的角度
传统 Linux IPC 的接收方无法获得对方进程可靠的 UID/PID，从而无法鉴别对方身份；而Android作为一个开放的开源体系，拥有非常多的开发平台，App来源甚广，因此手机的安全显得额外重要；对于普通用户，绝不希望从App商店下载偷窥隐射数据、后台造成手机耗电等等问题，传统Linux IPC无任何保护措施，完全由上层协议来确保。
Android为每个安装好的应用程序分配了自己的UID，故进程的UID是鉴别进程身份的重要标志，前面提到C/S架构，Android系统中对外只暴露Client端，Client端将任务发送给Server端，Server端会根据权限控制策略，判断UID/PID是否满足访问权限，目前权限控制很多时候是通过弹出权限询问对话框，让用户选择是否运行。