[Android进程间通信-2]ServiceMangager源码分析

ServiceManager.getSystemService

    ServiceManager中主要存放系统服务的IBinder对象和其名字的映射关系，这样每次当我们通过 context.getSystemService 查找到对应服务代理对象后，使用代理对象中的方法时候，都会再从ServiceManager中找到对应的IBinder，然后生成服务的代理类proxy,从而通过AIDL来执行服务的方法。

    上图是ServiceManager里的getService方法的源码流程，简单概括就是，ServiceManger中有个缓存池，缓存的是服务IBinder和名称的映射，如果有缓存，则直接返回，没有就生成ServiceManager的代理对象，通过AIDL到真正的ServiceManager（可以理解为底层对象）中去查找。

OK 两个问题：

1. 这里流程并没看到缓存sCache的更新，那么是什么时候push进去的服务呢？
2. 在真正的ServiceManager 中，逻辑又是如何呢？

APP层Servicemanager中sCache更新

    sCache什么时候设置的呢，总结来讲，就是APP进程起来后，ActivityThread执行attach方法时候，遍历所有系统服务，然后将其对应binder对象放到缓存sCache中。

ServiceManager底层原理

    底层原理这里很简单，IServiceManger的实现是在native层实现的，对应源码是CPP文件，里边会维护系统服务名和binder的映射关系，这个是在系统服务进程启动时候创建的，也就是手机设备开机时候。

    会将系统服务优先注册到映射表中，比如AMS,PMS，WMS等服务。所以我们后续可以直接通过ServiceManager找到其对应的代理类。

OK 后续我们接着研究非系统Service的AIDL通信原理，再之后研究Binder机制。