Android为什么不用Linux的IPC而实现了自己的Binder机制

• Android apps and system services run in separate processes for security, stability, and memory management reasons, but they need to communicate and share data!
  Security: each process is sandboxed and run under a distinct system identity
  Stability: if a process misbehaves (e.g. crashes), it does not affect any other processes
  Memory management: "unneeded" processes are removed to free resources (mainly memory) for new ones
  In fact, a single Android app can have its components run in separate processes 

Android的应用程序和系统服务各自运行在单独安全,稳定,受内存管理的进程中,但是它们需要通讯,共享数据.

Security:每个进程时一个沙箱,它们运行在不同的系统标示下

Stability:如果一个进程挂掉,它不会影响其他的进程

Memory management:“不需要”的进程通过内存管理将其移除资源,为新进程提供内存等资源

事实上,一个单独的应用程序,它的组件可以运行在单独的进程中

• Android’s libc (a.k.a. bionic) does not support System V IPCs,
  No SysV semaphores, shared memory segments, message queues, etc.
  System V IPC is prone to kernel resource leakage, when a process "forgets" to release shared IPC resources upon termination
  Buggy, malicious code, or a well-behaved app that is low-memory SIGKILL'ed
  

Android不支持System V IPC

它没有信号量,共享内存,消息队列等.实际上Android不支持以下头文件提供的功能:

<sys/sem.h>   /* SysV semaphores*/
<sys/shm.h>   /* SysV shared memory segments */
<sys/msg.h>   /* SysV message queues */
<sys/ipc.h>   /* General IPC definitions */

System V IPC容易引起内核资源泄露,如当一个进程"忘记"释放共享IPC的资源

当一个有bug的或恶意程序退出后或普通程序被强行杀死后，没有办法自动释放Sysv信号量（在内核中分配的）。
然而Android系统经常自动杀死进程，给新的进程腾出空间（Android的重要机制）

• Binder to the rescue!
  Its built-in reference-counting of "object" references plus death-notification mechanism make it suitable for "hostile" environments (where lowmemorykiller roams)
  When a binder service is no longer referenced by any clients, its owner is automatically notified that it can dispose of it
  

Binder内置的"对象"引用计数加上death-notification功能使其适合在"恶略"的环境下(例如Android低内存管理)

当一个binder service不再被客户端使用,它会自动通知系统处理掉它

文章参考自:Why Binder?