Android中集结了大量的系统管家Manager：比如当你要kill一个后台Processes时候，你会用到ActivityManager；再比如你需要用到系统的声音相关的你需要AudioManager等等。而且获取这些管家对你来说很简单，比如获取一个ActivityManager，你只需要调用当前context的方法getSystemService就可以了：
final ActivityManager am = (ActivityManager) context
.getSystemService(Context.ACTIVITY_SERVICE);
大家经常用context的方法getSystemService来获取你想要的Manager，你知道为什么任意context实例都能获取Manager吗？ 今天又时间，就看看其秘密。
首先，我们知道Context是一个描述一个application的全局的资源和信息的。而Context其实是一个abstract的类，所以是不能直接用的，他的实现类其实是ContextImpl，看看androidd对ContextImpl一段原文介绍：
/**
* Common implementation of Context API, which provides the base
* context object for Activity and other application components.
*/从上面的意思我们可以知道：ContextImpl其实就是context的实现，application的组件其实继承于他的！所以要研究context，就是要研究ContextImpl。说道这里好像有点跑题了，嘿嘿，下面继续。
刚才说了，context的方法getSystemService可以获取android系统当前使用的各个Manager,那我们来ContextImpl看看getSystemService在做什么。
@Override
public Object getSystemService(String name) {
ServiceFetcher fetcher = SYSTEM_SERVICE_MAP.get(name);
return fetcher == null ? null : fetcher.getService(this);
}
这里我们分两点来看：
（1）首先来看看SYSTEM_SERVICE_MAP是什么？
private static final HashMap SYSTEM_SERVICE_MAP =
new HashMap();原来是一个HashMap, 并且是一个static的私有变量。这表明，SYSTEM_SERVICE_MAP存储的是一个公共、共用的一定数量的ServiceFetcher。
SYSTEM_SERVICE_MAP存储的这些ServiceFetcher值是什么时候初始化的呢？我们后面再说。
（2）我们来看看ServiceFetcher到底是什么？
/**
* Override this class when the system service constructor needs a
* ContextImpl.Else, use StaticServiceFetcher below.
*/
/*package*/ static class ServiceFetcher {
int mContextCacheIndex = -1;
/**
* Main entrypoint; only override if you don't need caching.
*/
public Object getService(ContextImpl ctx) {
ArrayList cache = ctx.mServiceCache;
Object service;synchronized (cache) {
if (cache.size() == 0) {
// Initialize the cache vector on first access.
// At this point sNextPerContextServiceCacheIndex
// is the number of potential services that are
// cached per-Context.
for (int i = 0; i/**
* Override this to create a new per-Context instance of the
* service.getService() will handle locking and caching.
*/
public Object createService(ContextImpl ctx) {
throw new RuntimeException("Not implemented");
}
}
很简单的一个static class，其中只有两个方法getService和createService：
先来看看createService这个方法：改方法里面没有什么实质的东西，重点我们看看这个方法上面的原文说明：说的很清楚这个方法其实是用来Override的，其目的就是创建一个服务Service.
再来看看getService，从这个方法可以知道：首先是看看ctx.mServiceCache里面是否已经有了这个我们需要的服务Service，如果还没有就调用createService来创建一个。
所以，ServiceFetcher很简单，其实就是对服务Service为方便使用而对其的创建、取用的一个封装类。
所以重点，我们还来到了是如何创建一个服务Service的。
很快，你就会发现在ContextImpl里面有一段static代码，其注册了所有的服务Service：
static {
registerService(ACCESSIBILITY_SERVICE, new ServiceFetcher() {
public Object getService(ContextImpl ctx) {
return AccessibilityManager.getInstance(ctx);
}});
registerService(ACCOUNT_SERVICE, new ServiceFetcher() {
public Object createService(ContextImpl ctx) {
IBinder b = ServiceManager.getService(ACCOUNT_SERVICE);
IAccountManager service = IAccountManager.Stub.asInterface(b);
return new AccountManager(ctx, service);
}});
registerService(ACTIVITY_SERVICE, new ServiceFetcher() {
public Object createService(ContextImpl ctx) {
return new ActivityManager(ctx.getOuterContext(), ctx.mMainThread.getHandler());
}});
...}里面都从新了方法createService来创建新的服务对象。
我们最后看看registerService这个方法做了些什么？
private static void registerService(String serviceName, ServiceFetcher fetcher) {
if (!(fetcher instanceof StaticServiceFetcher)) {
fetcher.mContextCacheIndex = sNextPerContextServiceCacheIndex++;
}
SYSTEM_SERVICE_MAP.put(serviceName, fetcher);
}SYSTEM_SERVICE_MAP.put(serviceName, fetcher);看到了吗！其实就是讲创建好的 ServiceFetcher 存储在SYSTEM_SERVICE_MAP这个HashMap里面了。最后，我们来看都有那些Manager服务：1．
EntropyService
熵服务，周期性的加载和保存随机信息。主要是linux开机后，/dev/random的状态可能是可预知的，这样一些需要随机信息的应用程序就可能会有问题。这个无需提供应用程序接口。
2． PowerManagerService
