【Android 源码】Android 系统服务的获取

Android 系统服务的获取

序言

在Android系统中，我们经常会涉及通过Context获取系统级别的服务，如WindowsManagerService、ActivityManagerService、LayoutInflater。
那么这些系统服务是什么时候初始化的呢，又是如何获取的呢？

跟踪源码

我们就以LayoutInflater为例，进行分析。开发过程中，特别是设计自定义View时，我们经常会使用它加载布局，其一般使用方式如下：

 private void initView(Context context) {
     View view = LayoutInflater.from(context).inflate(R.layout.view_wayne, this);
     ... 
     }

跟踪LayoutInflater.from方法

实际是调用context.getSystemService()这个方法来获取LayoutInflater，我们继续跟进，看到了一个抽象方法。

正如我们所知，Context类里并没有具体实现，我们要到ContextImpl类中寻找我们想要的答案。

这里在进行了一些判断之后，转而调用SystemServiceRegistry.getSystemService()方法。

到这里，主体脉络已经捋清楚了，现在来看一下SystemServiceRegistry这个类。该类包含一段静态代码块：

static {
    //内容过长，就不完全展示出来，主要是注册各种系统服务
    ......
    
    //注册 LayoutInflator
    registerService(Context.LAYOUT_INFLATER_SERVICE, LayoutInflater.class,
                new CachedServiceFetcher<LayoutInflater>() {
            @Override
            public LayoutInflater createService(ContextImpl ctx) {
                return new PhoneLayoutInflater(ctx.getOuterContext());
            }});
    ......
}

看一下registerService方法

实际上就是把Name，ServiceFetcher，ClassName保存在三个静态HashMap中，在获取系统服务时先通过Name找到ServiceFetcher，再通过ServiceFetcher获取真正的服务对象。

接下来看一下ServiceFetcher，该类定义如下：

该类只有一个getService方法，该类实现类：CachedServiceFetcher，StaticServiceFetcher。它们都有一个抽象方法createService，区别在于，createService接收的参数：

• CachedServiceFetcher需要ContextImpl
  

• StaticServiceFetcher不需要ContextImpl
  

这些系统服务都只会创建一个对象（单例模式），第一次获取服务时，通过ServiceFetcher的createService创建服务对象，然后将该对象存在静态HashMap中，下次直接从缓存中获取，避免重复创建对象。

总结
以后使用系统服务的时候大家就很清楚这些服务的注册和获取方式了，他们采用容器单例实现方式，通过HashMap来管理一组单例对象，很好的设计思想，值得大家学习。

推荐阅读：Android 系统服务的注册以及 getService() 方法源码解析