为什么Android要采用Binder作为IPC机制?

1.首先Binder采用了linux的优秀的内存管理技术，在通过内科空间传递数据时，能保证数据的正确性。

　　2.使用用户空间无法访问的内存空间来交换数据，保证了IPC的安全性 1）从性能的角度
数据拷贝次数：binder数据拷贝只需要一次，而管道、消息队列、socket都需要2次，但共享内存方式一次内存拷贝都不需要；从性能角度看，binder性能仅次于共享内存。

（2）从稳定性的角度
binder是基于c/s架构的，简单解释下c/s架构，是指客户端(client)和服务端(server)组成的架构，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是否满足访问权限，目前权限控制很多时候是通过弹出权限询问对话框，让用户选择是否运行。android 6.0，也称为android m，在6.0之前的系统是在app第一次安装时，会将整个app所涉及的所有权限一次询问，只要留意看会发现很多app根本用不上通信录和短信，但在这一次性权限权限时会包含进去，让用户拒绝不得，因为拒绝后app无法正常使用，而一旦授权后，应用便可以胡作非为。

针对这个问题，google在android m做了调整，不再是安装时一并询问所有权限，而是在app运行过程中，需要哪个权限再弹框询问用户是否给相应的权限，对权限做了更细地控制，让用户有了更多的可控性，但同时也带来了另一个用户诟病的地方，那也就是权限询问的弹框的次数大幅度增多。对于android m平台上，有些app开发者可能会写出让手机异常频繁弹框的app，企图直到用户授权为止，这对用户来说是不能忍的，用户最后吐槽的可不光是app，还有android系统以及手机厂商，有些用户可能就跳果粉了，这还需要广大android开发者以及手机厂商共同努力，共同打造安全与体验俱佳的android手机。