binder学习指南
http://weishu.me/2016/01/12/binder-index-for-newer/
carson_ho 的讲解
https://blog.csdn.net/carson_ho/article/details/73560642
mmp()
//www.greatytc.com/p/719fc4758813
android 多进程，用来学习 AIDL
https://segmentfault.com/a/1190000022243232
1.什么是Binder
Binder是一种进程间通信(IPC)的机制。
在Android系统的Binder机制中，由4个组件组成，分别是Client、Server、Service Manager和Binder驱动，其中Client、Server和Service Manager运行在用户空间，Binder驱动程序运行在内核空间。
Bind驱动有三个核心方法: binder_open, binder_mmap, binder_ioctl
binder_open 主要负责在内核空间中注册进程信息 binder_proc, 后续操作以此为依据
binder_mmap 主要负责进行内存映射, 起始为一页物理内存4kB,最大为 4M, 并将虚拟地址保存在 binder_proc->buffer中, 再计算出应用程序的虚拟内存, 后续数据读取涉及到缺页中断
binder_ioctl 主要负责读写等文件操作
其中，核心组件便是Binder驱动。Service Manager提供了辅助管理的功能，Client和Server正是在Binder驱动和Service Manager提供的基础设施上，进行Client-Server之间的通信。Service Manager和Binder驱动已经在Android平台中实现好，开发者只要按照规范实现自己的Client和Server组件就可以了。
2.跨进程通信的方式
经典的IPC方式有:
- 共享内存
- 管道
- unix domain socket
Socket: socket分为ServerSocket（tcp）、DatagramSocket（udp）、LocalServerSocket（unix ipc）
而android特有的方式有:
- ContentProvider 支持跨进程数据共享
- Binder机制 使用Binder还可以具体为AIDL和Messenger.
为什么使用binder机制，而不使用操作系统已有的IPC机制？
- 从性能的角度。Binder数据拷贝只需要一次，而管道、消息队列、Socket都需要2次，但共享内存方式一次内存拷贝都不需要；从性能角度看，Binder性能仅次于共享内存。
- 从稳定性的角度。Binder是基于C/S架构的。客户端和服务端相互独立，稳定性好。
- 从安全的角度。传统Linux IPC的接收方无法获得对方进程可靠的UID/PID，从而无法鉴别对方身份，而Binder有一套上层的安全机制，可以确保app在没有权限的情况下无法执行服务。
- 最重要的是，公司战略层面, Linux内核是开源的系统, 所有进行系统调用的系统都必须开发源码. Google巧妙地将GPL协议控制在内核空间，将用户空间的协议采用Apache-2.0协议（允许基于Android的开发商不向社区反馈源码）
实际上android中的IPC并不单一, Zygote进程的IPC采用的是Socket机制，Kill Process采用的signal（信号）机制等等。而Binder更多则用在system_server进程与上层App层的IPC交互。
-
Binder的一次拷贝是哪次
binder的一次拷贝发生在客户端向服务进程发消息时，从用户空间拷贝消息到内核空间. 对应服务端进程的 proc->buffer中, 这个buffer 和服务端的数据都是虚拟内存, 由 mmp() 返回, 映射了同一个物理地址
4.介绍下AIDL
AIDL是一个生成代码编译机制，方便开发者编写通过Binder进程间通讯的代码。通过aidl文件定义好接口后，编译工具会生成一个interface的java类，这个interface包含一个叫Stub的静态内部抽象类，Stub又包含一个叫Proxy的私有内部静态类。
简单地说，AIDL跨进程通信就是Server和Client约定好方法号和参数，通过binder驱动将方法号和参数从一端传递到另一端的过程。
Service和Activity跨进程通信使用 binder，Activity和Activity 跨进程通信可以使用startActivity和onActivityResult。
使用方式：
在Server进程实例化一个Stub， 在onBind回调中返回。在Client进程中bindService，通过ServiceConnection拿到一个IBinder，通过Stub.asInterface(binder)实例化一个interface的代理Proxy，Client就获得了一个interface的实例。Client通过调用proxy的方法，向binder.transact方法传入方法序号，data parcel，reply parcel和是否oneway的flag，Binder驱动将这些参数传递至Server的Stub实例，在Stub的onTransact中解组parcel，通过方法序号来执行对应的方法。
更复杂一些的，通过AIDL还可以让Client向Server注册回调。首先用aidl定义一个单独的回调接口，使用AIDL生成的接口都继承了IBinder接口，都可以被写入parcel。Client实例化这个回调接口的Stub，在ServiceConnection获得注册接口的proxy后，将回调传给注册接口，把回调binder写入注册接口的data parcel中，通过Binder驱动传递至Server，Server再拿到这个Client的binder后, 将它保存至一个RemoteCallbackList，在合适的时机调用这个回调，再进行一次从Server到Client的进程间通信。
