标签归档:binder

从最上层到驱动层看Android Conetext.getSystemService究竟做了什么

曾经好奇为什么同样是binder接口,Conetext.getService为什么可以直接获取,而不需要像bindeService一样异步回调,今天终于从能够从上层源码到binder驱动源码,彻底了解这一过程,同时分析binder接口在调用的时候,底层究竟是如何实现的。

1.从getSystemService 到native的getContextObject

ContextImpl.java

SystemServiceRegistry.java

SYSTEM_SERVICE_FETCHERS是一个hasmap,键值是一个抽象类,ServiceFetcher,它在初始化的时候实现,见如下代码

registerService 的作用就是把CachedServiceFetcher 放到 SYSTEM_SERVICE_FETCHERS 中,这样每次取服务时都可以从这个缓存获取,因此我们第二次getSystemService时性能是非常高的,时间复杂度位O(1),然后所有系统服务端最终都会调用到这一步 查看更多

Binder的一次拷贝是哪次

binder的一次拷贝发生在客户端发消息时,从用户空间拷贝消息到内核空间,原因是内核空间与用户空间存在内存隔离,必须内核和驱动开发专用函数 copy_from_user(…),把内存从用户空间拷贝过来才能继续操作

binder请求过程

简述一下通信过程:

1)进程启动时候,打开binder驱动,使用mmp()函数分配一段物理内存,让内核空间和用户空间都指向这段内存,mmp返回共享空间的地址,由进程持有,对应的内核部分由该进程对应的节点持有,驱动维护着所有节点

2)客户端通过驱动查询服务端的节点,不是直接通过驱动,而是先经过了servicemnager,但 servicemnager 实际上是句柄为0的服务端 查看更多