Binder 简述

Binder

• Binder使用Client－Server(c/s架构)通信方式。
• Binder框架定义了四个角色：Server,Client,ServiceManager以及Binder驱动。其中Server,Client,ServiceManager运行于用户空间，驱动运行于内核空间。ServiceManager，负责把Binder Server注册到一个容器中。
• 通过代理对象通信：Binder代理对象 Binder引用对象 Binder实体对象 Binder本地对象
• AIDL（Android Interface Definition Language Android接口定义语言），Android提供的一种Binder实现。

线程池

• 主线程是由 Zygote母体生成的；
• 线程池：首次创建第一个Binder线程A，然后监听BR_SPAWN_LOOPER事件，收到后创建第二个Binder线程B，线程B继续监听BR_SPAWN_LOOPER事件，收到后创建第三个Binder线程C。总共创建3个Bindr线程，这是Binder协议决定。根据系统处理器数目以及应用程序的负载强度，线程池的线程数目可以动态调整，这是Binder优化需要考虑的。

Service Manager

• 是整个Binder通信机制的大管家，是Android进程间通信机制Binder的守护进程，管理Binder机制
• Client端和Server端通信时都需要先获取Service Manager接口，才能开始通信服务。
• 所有系统服务都需要在ServiceManager类中进行注册
• 服务注册、获取和访问过程

通信

• BpBinder发送端，根据handler，在当前binder_proc中，找到相应的binder_ref
• 由binder_ref再找到目标binder_node实体
• 由目标binder_node再找到目标进程binder_proc

销毁

• 在应用进程创建的过程中有一个attachApplicationLocked方法的过程中便会创建死亡通知。
• 当binder服务端挂了之后，便会通过binder的DeathRecipient来通知AMS进行相应的清理收尾工作。当该进程会杀，则会回调到binderDied()方法。
• Crash进程中拥有一个Binder服务端ApplicationThread，而应用进程在创建过程调用attachApplicationLocked()，从而attach到system_server进程，在system_server进程内有一个ApplicationThreadProxy，这是相对应的Binder客户端
• 当Binder服务端ApplicationThread所在进程(即Crash进程)挂掉后，则Binder客户端能收到相应的死亡通知，从而进入binderDied流程。
• 进程异常退出的时候，内核保证会释放未正常关闭的它打开的/dev/binder文件，即调用与/dev/binder文件所关联的release回调函数，进而执行清理工作
• BBinder死亡通知机制
  • Client进程从Binder驱动获得一个BpBinder
  • Client进程向Binder驱动注册一个死亡通知，该死亡通知与上述BpBinder所引用的BBinder相关联
  • Binder驱动监控到BBinder所在进程异常退出的时候，检查该BBinder是否注册有死亡通知
  • Binder驱动向注册的死亡通知所关联的BpBinder所运行在的Client进程发送通知
  • Client进程执行相应的清理工作