对于ServiceManager的使用，我们在应用程序编程时也会经常使用到，比如我们需要使用Sensor时，我们一般会做如下的调用：

这样的编程模式，API说明会告诉我们，每次系统里加速度计Sensor发生状态变化时，就会触发onSensorChanged()回调方法被执行来处理Sensor的变动信息。这里就很好地说明了在系统范围内使用Service的另一种模式，就是通过getSystemService()，取回一个System

1. 标准的getService()实现。在正常情况下，getService()只是从Cache中查找是否已经创建好所需要的Service对象，如果有则直接返回这一对象，如果没有，则创建所需要的Service对象，再返回。
2. Service而言，虽然都在系统运行过程中一直存在，但有的会很忙，像Media、Audio、Graphic等，只要有Proxy，便可以响应其调用请求，有一部分则可能长期驻留后台，只是偶尔响应一下请求，比如像我们例子里看到AlarmManager。对于响应度不高的SystemService，一般都会在一个叫servicemanager的守护进程的监管之下，所以我们这里会使用Stub.asInterface()接口方法申请对象，从而保证这一Service不被调用时则可以进入休眠。

在这个整体的执行流程里，比较绕，而且深入代码分析时，我们也会看到在实现时的不一致，风格并非很严谨。但通过中间插入的这层ServiceFetcher，可以让应用程序（或是某种需要使用getSystemService()方法的系统组件）很快找到合适的ServiceProxy端的初始化方法，快速建立起跟RemoteService的通信。

我们可以注意到getService()与bindService()的一个重要区别，bindService()与unbindService()成对，而getService()只是单独出现。于是，bindService()这种调用机制上的Service，总是在Bounded生命周期里才能对外提供服务，可以做到按需启动，不再需要时便会在合适的时间点被关闭。而getService()所操作的Service则没有什么生命周期，永远在系统里运行并提供服务，这里也需要有种实体可以管理这些Service，当这些Service无人使用时，承载该Service的进程便会进入休眠中，这便是ServiceManager的Stub端所完成的功能。

代码如此简洁，于是我们可以跟踪ServiceManagerNative的实现。从ServiceManagerNative类的实现上，我们也可以看到基于Binder收发两端的实现，但实际上接收端没有意义，也不会被执行到。代码如下：

1. 从ServiceManagerNative，可以看到，它也是一个抽象类，继承Binder，实现IServiceManager接口。于是它必然会实现asInterface()、asBinder()等Binder所需要的接口方法。但因为它本质上只是起到Proxy作用，作为一个抽象类，它并不可能被实例化，除非有一个非抽象类继承它并实现它所缺少的方法。这种实现在代码层面上没有意义，我们从后面的分析servicemanager的Native实现时也可以看得出来，于是我们虽然看到了onTransact()实现，但实际上它不起作用。
2. 这是整个ServiceManagerNative类实现的最有意义的一行。虽然这一行与其他基于IBinder实现的远程类没什么不同，但这一行提供了Proxy接口，这个Proxy接口，则是其他System
3. ServiceManagerProxy对象里实现就没什么特殊之处了。跟会通过Binder访问到Remote Service的其他远程方法一样，会将本地需要调用的方法，将方法名与参数打包，将得到的命令通过Binder发送出去，然后再等着远程执行的返回。

Java语言环境本身只是一种虚拟机环境，Java虚拟机在实现上强调的是对底层的封装，并不会提供针对操作系统的某种功能，如果我们想实现对底层的访问，则必须使用JNI来访问。比如访问Binder，如果把这样的机制通过指令或是IO拓展的方式直接嵌入到Java语言里，则会引发Android系统与Java语言的更大分裂。于是Binder本身是通过JNI拓展到Java语言里的，这样同时还达到一个高效的目的，虽然Java语言里可以访问到Binder的相应操作接口，但在底层实际上是通过C++实现的更高效的版本。既然Binder已经是C++实现，再通过JNI引入到Java环境里，我们的ServiceManager的Stub实现就没有必要到Java环境里再重复一次了，可以直接在底层将IServiceManager接口所需要的远程方法实现即可。这种方式更符合Java语法习惯、Native实现可以得到更高效ServiceManager，另外还提供了进一步实现NativeSerivce的可能性。既然底层是C++实现的，于是可以将Service的逻辑用C++写出来，再通过Binder直接暴露到应用程序层即可。

作为IServerManager的Stub端，它所需要完成的功能是提供getService()、addService()等方法，并通过这些远程方法来控制什么状态下进程应该处于活跃状态，而什么时间点促使进进入休眠。到目前为此，它只需要给Java环境里的ServiceManager类提供服务，但稍后面我们就会看到，它也需要提供同样的服务接口给Native环境里的用C++语言编写的ServiceManager类。出于这样需求，于是干脆这一代码就用C语言来实现，以区别于使用服务的Java环境和C++环境里的对象。

ServiceManager会是一个在init.rc里定义的一个系统进程，在系统运行时全局有效。在Android系统里，唯一会与底层Binder驱动直接交互的，便是servicemanager进程（系统里其他部分，都是通过libbinder封装之后使用统一的访问模型来进行）。监听在Binder驱动 之上的servicemanager进程，相当于Android世界里的“大内总管”。一方面，系统内存在的Service，并非全局都知道，只有通过servicemanager才能查询到；另一方面，所谓的System Service也需要有一种类似于RemoteService的收发自如的执行能力，被调用时便投入运行，而没有被调用到时，虽不能被杀死掉，但也不会盲目的“空转”执行。出于这样的需求，便有servicemanager的实现框架。

无论出于什么样的设计需求，servicemanager都需要承当起service的管理功能，从一般的设计上来考察，或许这一实现会很复杂，但事实上并非如此。整个servicemanager的实现非常精练，加上binder通信的处理过程，总共不超过一千行代码，而且是使用C语言写出来的精练代码。Servicemanager的源代码位于frameworks/base/cmds/servicemanager里，通过service_manager.c实现主控部分，通过binder.c来实现与binder的通信处理过程。

既然是C语言代码，我们可以先从main()方法分析起。

从这一个main()函数实现，我们可以看出servicemanager在实现上的简洁性。本质上，只进行了三步操作：

1. binder_open()，在这一函数里打开了binder驱动，然后通过mmap()系统调用直接映射了binder驱动提供的128 * 1024共128K字节空间。这段空间用户态编程时并不会用到，只是一种“偷”内存的技巧，binder驱动将使用这段用户态内存，这样使用binder驱动并不占用任何系统内存，而Binder IPC所需要的内存，都存在于使用它的进程空间里，一旦进程退出，而内存随之被回收。

这种简洁的实现，就使servicemanager这个进程有能力解析binder命令，然后根据不同命令调度不同进程进入执行时的活跃状态，或是在不再被用到时进入到休眠状态。我们把上述三个步骤打开，就可以看到这一执行过程：

打开驱动并映射128K字节空间。在后面对binder驱动的分析我们可以看到，这是android系统里唯一一次使用这样的方式来访问binder，通过这样的方式，则servicemanager可以直接操作binder驱动来分配的一段内存，而其他进程会通过ioctl的系统调用将操作请求，从用户态拷贝到servicemanager的这段内核空间的内存。通过这种方式，减少了一次内存拷贝（servicemanager直接映射使用内核空间的binder区域）。

这就只是通过ioctl来操作一次binder驱动而已。

这一实现复杂一点，就是循环地从binder取回binder消息，然后再通过传入的回调函数循环处理binder消息。

       由于binder_loop()函数实现复杂一些，于是我们更细一点的来进行分析。从实现原理来看，它所需要做的就是循环从binder驱动读回IPC信息，然后再进行处理。于是，综合得到的具体步骤是：

1. struct binder_write_read。在一般编程时我们见不到这样的数据结构，因为一般我们在编程上都是使用libinder封装过的Binder传输。我们可以在后面的关于Binder的描述中看到，所有的Binder通信，都是会用这样的binder_write_read结构体，再通过ioctl()系统调用将这一结构体写入binder，或是读出来。
2. 让Binder进入读循环。BC_ENTER_LOOPER，这一个命令操作到Binder驱动上，将使用Binder在当前进程得到的文件描述符fd进入到循环监听状态，这种操作类似于TCP/IP编程时使用的bind()。需要注意的是，此时我们使用的一个32字节的readbuf，但这readbuf在这里并非用于读，而只是借用过来发命令。
3. 此时真正开始Binder信息的读取。而由于servicemanager本身所实现的RPC很简单，只有两种，于是可以假设，在通信时数据量也会很小，于是这时只是通过binder_write_read结构体将只有32字节的read_buf通知到Binder驱动，当系统里其他任何部分调用到ServiceManager，都将迫使Binder驱动将该访问信息填写到read_buf里。
4. binder_parse()函数则会解析读取到的Binder命令信息。我们可以看到，readbuf, bwr.read_consumed, func，这三个参数将包含binder驱动里读取到的Binder命令、命令的长度，之后会跟所有C式的调用风格一样，通过func回调方法来处理这一个Binder命令。

再看binder_parse()函数，我们可以看到Binder会循环地读取read_buf，根据不同命令作不同处理。在这个方法里，我们看到全是BR_开头的命令，在后面分析Binder运行原理时可以看到，BC是Binder Command的缩写，BC_开头的命令会全都是发出操作，而BR则是Bind Return的缩写，BR_开头的命令只会用于操作结果的返回，也就是说servicemanager进行的是被动地响应。而只有两种情况会引发后续的处理：BR_TRANSACTION，会触发Binder消息的后续处理；而BR_DEAD_BINDER，则会触发Binder相关资源的回收。

如果在binder_parse()函数里得到的Binder消息会是BR_TRANSACTION，我们从后面对Binder驱动的描述可以看出，此时则会是通过proxy对象发过来的命令请求。我们从名字也大概可以看出一些端倪，BR_TRANSACTION，不是Binder发送时的transact发送，这必然会是onTransact()，用来处理Binder命令的接收处理。

Binder传输的是如此严整的数据结构，则在进行处理时提供了多种可能的处理功能，所以从servicemanager层面来看来，也不只是简单地将数据读出来，而会是通过不同的结构来进行消息体的解析。虽然我们在后面的binder机制分析时还将看到binder_tranaction_data结构，我们这里也看一下其含义：

1. target本身是一种union。target在本地则会是指向对象的指针，加上，而在远端则是会是指向远程对象的引用。
2. cookie是辅助target的附加信息，比如与target结合则具备了自动回收等后续处理能力
3. flag则是传输时指定的一些属性值，像线程优先级等
4. sender_pid是发送Binder命令的进程的pid，可用于进程是否存在的检验
5. sender_euid，是发送Binder命令的进程执行时使用的uid，可用于验证进程的访问权限
6. data，指向所需要操作的buffer，或是直接是内置的最多八字节buffer

有了这样数据结构，我们对BR_TRANSACTION的处理就比较容易理解了，在servicemanager里，我们会有数据的收发处理，但对底层来说，都是binder_txn结构的数据格式，而对于上层处理，都是通过binder_io结构来完成。所以，在这时会将收到的buffer，通过bio_init_from_txn()转换成binder_io，同时准备好应答的缓冲区，通过bio_init()来规整这一缓冲区。然后这两个binder_io指向的消息体会通过回调函数func()进行处理，处理完则通过binder_send_reply()将func回调函数处理得到的应答消息写回Binder，从而通知到调用servicemanager的地方。

1. svcmgr_handler()函数，就跟我们Java环境里的onTransact()方法一样，但是因为是C环境，所以都是指针作为参数，写得有点不直观。这样的编程风格，就有点C语言的进行面向对象式的编程技巧，binder_state和binder_txn用于Binder处理里上下文环境判断，而两个分别用于收发的binder_io则是相当于Message封装。
2. 在这里我们可以体会C语言的面向对象式技巧，这里取出要处理的binder_io里的信息，并不是直接使用字符串指针操作，而是通过bio_get_*系列的封装，类似于Java语言里的Getter/Setter。于是，在这里我们进一步对数据包的合法性进行验证。
3. SVC_MGR_GET_SERVICE和SVC_MGR_CHECK_SERVICE。虽然他们是两个不同binder命令，但对于底层来说是一回，通过get_sevice成功，我们可以给check_service一个是否可以正常运行的应答。这一般会被使用service的部分来获得Service的引用，对于内部实现来说，它只是在自己维护的一个svcinfo的单链表里找到合适的service来响应服务请求。
4. SVC_MGR_LIST_SERVICE。这一命令会将自己维护的svcinfo链表遍历一次，然后将所保存的service信息返回给调用端。

通过引入servicemanager这样一种机制，在我们系统设计上就得到方便，我们不再需要系统内部的bindService()，但又提供了类似于bindService()这样按需启动的功能。我们在系统里实现的一个Remote

在某个Service对象完成自己的初始化后，就会调用add_service()，将自己加入到Service列表，然后就会在Binder驱动上休眠。应用程序会调用get_service()，尝试跟某个SystemService建立交互，此时也在Binder驱动上休眠。当servicemanager做完合法性判断之后，则会唤醒收发两端的进程进入到交互过程里。从这个意义上来说，servicemanager虽然代码如此简单，但也起到了“大内总管”的职能，会管理System Service，并在合适点唤醒它们投入执行。

Manager，调用频度不那么高，也会直接通过C这样的Native语言来编写，get_service()/add_service()的调用频度比Binder通信要低多了，那我们Binder通信本身也应该使用native实现了。另外，Java语言本身并不知道Binder的存在，为了支持Binder这种特殊的IPC，我们也应该使用Native编码来导入Binder