传输性能:
socket作为一款通用接口，其传输效率低，开销大，主要用在跨网络的进程间通信和本机上进程间的低速通信。
消息队列和管道采用存储-转发方式，即数据先从发送方缓存区拷贝到内核开辟的缓存区中，然后再从内核缓存区拷贝到接收方缓存区，至少有两次拷贝过程。
共享内存虽然无需拷贝，但控制复杂，难以使用。
表 1 各种IPC方式数据拷贝次数
| IPC |
数据拷贝次数 |
| 共享内存 |
0 |
| Binder |
1 |
| Socket/管道/消息队列 |
2 |
安全性考虑:
Android作为一个开放式，拥有众多开发者的平台，应用程序的来源广泛，确保智能终端的安全是非常重要的。终端用户不希望从网上下载的程序在不知情的情况下偷窥隐私数据，连接无线网络，长期操作底层设备导致电池很快耗尽等等。
传统IPC没有任何安全措施，完全依赖上层协议来确保。
首先传统IPC的接收方无法获得对方进程可靠的UID/PID（用户ID/进程ID），从而无法鉴别对方身份。Android为每个安装好的应用程序分配了自己的UID，故进程的UID是鉴别进程身份的重要标志。使用传统IPC只能由用户在数据包里填入UID/PID，但这样不可靠，容易被恶意程序利用。可靠的身份标记只有由IPC机制本身在内核中添加。
其次传统IPC访问接入点是开放的，无法建立私有通道。比如命名管道的名称、system V的键值、socket的ip地址或文件名都是开放的，只要知道这些接入点的程序都可以和对端建立连接，不管怎样都无法阻止恶意程序通过猜测接收方地址获得连接。
基于以上原因，Android需要建立一套新的IPC机制来满足系统对通信方式，传输性能和安全性的要求，这就是Binder。
Binder基于 Client-Server通信模式，传输过程只需一次拷贝，为发送发添加UID/PID身份，既支持实名Binder也支持匿名Binder，安全性高。
传输数据量：
socket TCP的传输方式假如发送的数据过大，linux kernel 下面的TCP/IP stack 会重新分成小包发送的,对于应用程序来说，不需要关心数据大小。
在UDP的方式下面，会由于发送的数据大小超过了内核缓冲区的最大限制,这个限制好象是65535（默认情况下是64K），导致UDP通信收不到包，阻塞在recvfrom()。
1.UDP方式传输一段完整数据的大小时受内核缓冲区限制的，比如在默认情况下缓冲区大小是64K，所以对于该情况下的socket接收或者发送方，最大可以一次性发送一个64K的数据。而对于socket底层的具体实现是将64K的数据拆分成N个小数据包，内部提供机制保证数据的可靠性，例如每个包的大小为1K，则分成64个包，从服务器端发送到客户端，客户端在本地缓冲区重新组成完整的数据提交给用户。底层的实现方式应该各不相同，但是对于上层结果都是一样的。如果超过了缓冲区大小则无法完成组包出现丢包等等现象。同理，对于200K则可以发送接收200K大小的数据。
binder的数据是有大小限制的，在传输的时候，会先把数据从binder client拷贝到内核，然后从内核拷贝到binder server,数据的大小貌似是：4M
转载自：http://blog.csdn.net/graitude/article/details/55522626