谈谈你对binder的理解
client和server可以在同一进程，也可以不在同一进程
remote call：远程函数调用，可以带参数（传数据）
binder通信使得进程边界变得模糊，
binder存在的意义是什么？
binder运行在驱动层，它是在内核态，它并没有使用Linux跨进程通信机制socket，管道，共享内存，信号等，它是一个android系统创建的全新的IPC
性能： linux常用的进程通信比如socket，管道等是需要内核作为中转的，需要两次数据copy，一次从应用层copy到内核，一次从内存copy到应用层。然而binder是给一块物理内存同时映射到内核和目标进程的用户空间，将数据从应用层copy到内核空间时，相当于将数据copy到了另一个进程的用户空间了，只用copy一次。
方便易用：逻辑简单直接，不易出现问题。共享内存虽然性能很好，但远不如binder好用
安全：普通的linux跨进程访问是很不安全的，比如socket，它的IP地址端口等都是开放的，别人只要知道了他的IP地址就能链接他。或者说命名管道也是，知道了管道的名字就能读写数据了，这很容易被人恶意利用的。主要是我们拿不到调用方可靠身份信息，身份信息总不能让调用方自己填写，这明显是不可靠的，可靠的方式这个身份信息只能有IPC机制本身在内核态中添加，关于这点binder是做到了。
系统服务的binder通信架构，只有系统服务才能注册到serviceManager, 应用端的服务是不能注册到serviceManager的，通过不了权限验证。
Client：应用进程
Server：系统服务，可能运行在SystemServer进程或单独的进程，Server先与Client/应用启动，Server先与ServiceManager交互的，Server启动时将自己的binder注册到ServiceManager
ServiceManager: 单独的系统进程，Servicemanager启用binder机制后进入loop循环，等待Client和Server的请求
这三种进程启动时都会先启动binder机制，这是binder通信的前提
ServiceManager入口函数
binder_open：打开binder驱动，映射内存
SurfaceFlinger入口函数
SurfaceFlinger本身就是binder对象
ServiceManager端
binder通信分层架构图
应用层，framework层（java + Native），驱动层
从binder对象的角度看可以分成代理端（Client）和实体端（Server)
