Android为什么使用Binder？用 Linux原有的IPC不行吗？
本人今年参加了很多面试，也有幸拿到了一些大厂的offer，整理了众多面试资料，后续还会分享众多面试资料。
整理成了面试系列，由于时间有限，每天整理一点，后续会陆续分享出来，感兴趣的朋友可关注+收藏
（1）从性能角度考虑
Binder传输只需要一次拷贝；使用管道、消息队列、Socket需要两次，共享内存方式一次内存拷贝都不需要。从性能角度来说，Binder性能仅次于共享内存，可共享内存使用复杂。
（2）从稳定性角度考虑
Binder是基于C/S架构的，Client端有什么需求，直接发送给Server端去完成，架构清晰明朗，Server端与Client端相对独立，稳定性较好；而共享内存实现方式复杂，没有客户与服务端之别， 需要充分考虑到访问临界资源的并发同步问题，否则可能会出现死锁等问题；从这稳定性角度看，Binder架构优越于共享内存。
（3）从安全性角度考虑
传统Linux IPC的接收方无法获得对方进程可靠的UID/PID，从而无法鉴别对方身份，完全由上层协议来确保。
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运行过程中，需要哪个权限再弹框询问用户是否给相应的权限，对权限做了更细地控制，让用户有了更多的可控性
传统IPC只能由用户在数据包里填入UID/PID；另外，可靠的身份标记只有由IPC机制本身在内核中添加。其次传统IPC访问接入点是开放的，无法建立私有通道。从安全角度，Binder的安全性更高。
)
