6.1 概述
ServerManager的作用是将字符形式的Binder名字转化成Client中对该Binder的引用,使得Client能够通过Binder名字获得对Server中Binder实体的引用。
ServerManager -> DNS,Binder -> router.
这句话是对Binder机制的浓缩概括。但我们要注意的是Binder通信与C/S架构之间的关系。
Binder是android系统提供的一种IPC机制。那么在有众多的IPC机制下,为何android需要自己设计一套独特的Binder机制呢?可以思考一下对于进程通信而言有什么比较重要的指标吗?为什么 Android 要采用 Binder 作为 IPC 机制
主要是出于以下三个方面的考量:
1.高性能:从数据拷贝次数来看Binder只需要进行一次内存拷贝(拷贝发生在何处?),而管道、消息队列、Socket都需要两次,共享内存不需要拷贝,Binder的性能仅次于共享内存。
2.稳定性:上面说到共享内存的性能优于Binder,那为什么不使用共享内存呢,因为共享内存需要处理并发同步问题,容易出现死锁和资源竞争,稳定性较差。而Binder基于C/S架构,客户端与服务端彼此独立,稳定性较好。
3.安全性:Android为每个应用分配了UID,作为鉴别进程的重要标志,Android内部依赖这个UID进行权限管理,包括6.0以前的固定权限和6.0以后的动态权限,传统IPC只能由用户在数据包里填入UID/PID,这个标记是在用户空间控制,没有放在内核空间,因此有被恶意篡改的可能,因此Binder的安全性更高
6.1.1 常见类型基础
6.1.1.1 sp与wp
Android C++层的内存收回主要是通过三个类来实现,分别是RefBase,sp,wp;
SP和WP是两个智能指针模板类,sp是strong pointer,wp则是weak pointer,亦我们常说的强引用和弱引用;实例化sp和wp这两个模板类的类型必须是派生自RefBase的类。因为这个类拥有对内存回收机制的默认实现,所以android上想要支持内存回收机制的类必须派生自RefBase。
6.1.1.2 interface_cast
这是一个模板函数, 如果interface_cast的参数obj是BnInterface,则返回其自身,如果参数obj是BpInterface,则new一个Bp代理对象并返回。
template<typename INTERFACE>
inline sp<INTERFACE> interface_cast(const sp<IBinder>& obj)
{
return INTERFACE::asInterface(obj);
}
INTERFACE::asInterface(obj),看起来很简单的一句话,似乎是调用了一个静态方法,但这个较为简单的函数后面有着一个重要的功能。
6.1.1.3 ioctl
6.1.1.4 asBinder
如果asBinder的参数iface是BnInterface类型,则返回其自身,如果参数iface是BpInterface类型,则返回其mRemote远程代理对象BpBinder(handle) 。
sp<IBinder> IInterface::asBinder(const IInterface* iface)
{
if (iface == NULL) return NULL;
return const_cast<IInterface*>(iface)->onAsBinder();
}
sp<IBinder> IInterface::asBinder(const sp<IInterface>& iface)
{
if (iface == NULL) return NULL;
return iface->onAsBinder();
}
BnInterface
BnInterface的onAsBinder方法,直接返回自身,因为BnInterface继承自BBinder,而BBinder又继承自IBinder
template<typename INTERFACE>
IBinder* BnInterface<INTERFACE>::onAsBinder()
{
return this;
}
BpInterface
BpInterface的onAsBinder方法,调用remote()方法并返回,
template<typename INTERFACE>
inline IBinder* BpInterface<INTERFACE>::onAsBinder()
{
return remote();
}