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