本文主要是介绍【Service】ServiceManager.getService流程总结，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
参考《深入理解Android内核设计思想》（第2版），对ServiceManager.getService流程分析过程中的一些总结进行记录备忘：
- ServiceManagerProxy
当某个Binder Server在启动时，会把自己的名称name与对应的Binder句柄值保存在ServiceManager中。调用者通常只知道Binder Server的名称，所以必须先向Service Manager发起查询请求，就是getService(name)。
而Service Manager自身也是一个Server，预先已经设定好了句柄值0，因而任何Binder Client都可以直接通过0这个Binder句柄创建一个BpBinder，再通过Binder驱动去获取Service Manager的服务。具体而言，就是调用BinderInternal.getContextObject（）来获得Service Manager的BpBinder。
Android系统同时支持Java与C/C++层的Binder机制，因而很多对象都必须有“双重身份”，如BpBinder在Java层以IBinder来表示。对于Service Manager而言，IBinder的真正持有者与使用者是ServiceManagerProxy--它是Service Manager在本地的代表。
- ProcessState和IPCThreadState
大多数程序都有IPC的需要，而进程间通信本身又非常繁琐，因而Android系统特别为程序进程使用Binder机制封装了两个实现类，即ProcessState和IPCThreadState。从名称上可以看出，前者是进程相关的，而后者是线程相关的。ProcessState负责打开Binder驱动设备，进行mmap()等准备工作；而如何与Binder驱动进行具体的命令通信则由IPCThreadState来完成。
在getService()这个场景下，调用者是从Java层的IBinder.transact（)开始，层层往下调用到IPCThreadState.transact（），然后通过waitForResponse进入主循环---直至收到Service Manager的回复后才跳出循环，并将结果再次层层回传到应用层。
真正与Binder驱动打交道的地方是talkWithDriver中的ioctl()，整个流程中多次调用了这个函数。
- Binder驱动
在这个场景中，主要涉及了Binder驱动提供的binder_ioctl，binder_thread_write，binder_thread_read，和binder_transaction等几个重要的函数实现。Binder驱动通过巧妙的机制来使数据的传递更加高效，即只需要一次复制就可以吧数据从一个进程复制到另一个进程。Binder中还保存着大量的全局以及进程相关的变量，用于管理每个进程/线程的状态、内存申请和待办事项等一系列复杂的数据信息。正是这些变量的有效协作，才使得整个Binder通信真正“动”了起来。
- ServiceManager的实现
ServiceManager在Android系统启动之后就运行起来了，并通过BINDER_SET_CONTEXT_MGR把自己注册成Binder"大管家”。它在做完一系列初始化后，在最后一次ioctl的read操作中会进入睡眠等待，直到有Binder Client发起服务请求而被Binder驱动唤醒。
Service Manager唤醒后，程序分为两条主线索：其一，Service Manager端将接着执行read操作，把调用者的具体请求读取出来，然后利用binder_parse解析，再根据实际情况填写transaction信息，最后把结果通过BR_REPLY命令（也是ioctl）返回Binder驱动。
其二，发起getService请求的Binder Client在等待Service Manager回复的过程中会进入休眠，直到被Binder驱动再次唤醒--它和Service Manager一样也是在read中睡眠的，因而醒来后继续执行读取操作。这一次得到的就是Service Manager对请求的执行结果。程序先把结果填充到reply这个Parcel中，然后通过层层返回到ServiceManagerProxy，再利用Parcel.readStrongBinder生成一个BpBinder，最终经过类型转换为IBinder对象后传给调用者。
对于调用者来说，得到的IBinder对象要先经过asInterface做一次包装，如ServiceManager的BpBinder就被包装成了IServiceManager（实质就是一个ServiceManagerProxy）。这么做的目的在于可以让应用程序更加方便地使用Service Manager提供的服务(其他Binder Server也类似）。
getService调用流程图：
该图分两部分，上半部分是获取IBinder（BpBinder，BinderProxy）的 过程，此流程是从ServiceManagerProxy开始讲解的。下半部分是getService的执行过程。
这篇关于【Service】ServiceManager.getService流程总结的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
