最近公司平台要从Android 4.4.4 转战 Android 6.0, 带来的问题是之前我们在系统中添加了一些服务, 于是要将一些系统级的服务迁移过去,以及一些Framework 的自定义包.
碰巧在Gerrit上看到了添加系统服务这一块的patch.正好做个总结.虽然我不是Framework工程师, 但是了解Android系统还是很有好处的.
如何获取系统服务
我们获取系统服务都是在context中,getSystemService获取到的. 那么我们看一下getSystemService发生了哪些些事情.
getSystemService的实现是ContextImpl,我们去看一下ContextImpl的源码就知道了.
Android 4.4.4 (KitKat)
这里是Android4.4.4的源码, 6.0的源码过会儿看.
//这是我们获取服务的路口
@Override
public Object getSystemService(String name) {
//可以看到我们是从一个HashMap中拿的服务.
ServiceFetcher fetcher = SYSTEM_SERVICE_MAP.get(name);
return fetcher == null ? null : fetcher.getService(this);
}
private static final HashMap<String, ServiceFetcher> SYSTEM_SERVICE_MAP =
new HashMap<String, ServiceFetcher>();
//这是注册服务的方法,请注意是静态方法
private static void registerService(String serviceName, ServiceFetcher fetcher) {
if (!(fetcher instanceof StaticServiceFetcher)) {
fetcher.mContextCacheIndex = sNextPerContextServiceCacheIndex++;
}
SYSTEM_SERVICE_MAP.put(serviceName, fetcher);
}
我们还在ContextImpl中看到很多静态代码块.全是在注册服务,并且全是我们常用的系统服务.
static {
registerService(ACCESSIBILITY_SERVICE, new ServiceFetcher() {
public Object getService(ContextImpl ctx) {
return AccessibilityManager.getInstance(ctx);
}});
registerService(CAPTIONING_SERVICE, new ServiceFetcher() {
public Object getService(ContextImpl ctx) {
return new CaptioningManager(ctx);
}});
....
}
这么看来,这不就是我们注册服务的地方么?
So. 我们找到了注册系统服务的地方, 这里我们只需要把我们自己想注册的服务添加进去,完成new ServiceFetcher() 的抽象方法就行啦. 这样我们以后再getSystemService,传入注册时的名称,就可以获取到我们的服务对象了了.当然,这是4.4的方法.
上述是，获取系统服务getSystemService的方法实现，SYSTEM_SERVICE_MAP是一个map，value为ServiceFetcher
我们看看ServiceFetcher类的代码。
static abstract class CachedServiceFetcher<T> implements ServiceFetcher<T> {
private final int mCacheIndex;
public CachedServiceFetcher() {
mCacheIndex = sServiceCacheSize++;
}
@Override
@SuppressWarnings("unchecked")
public final T getService(ContextImpl ctx) {
final Object[] cache = ctx.mServiceCache;
synchronized (cache) {
// Fetch or create the service.
Object service = cache[mCacheIndex];
if (service == null) {
service = createService(ctx);
cache[mCacheIndex] = service;
}
return (T)service;
}
}
public abstract T createService(ContextImpl ctx);
}
在ServiceFetcher里，我们看到了获取服务时的缓存机制。即获取过的服务会被缓存在一个final Object[] cache里面。而Cache是这个Context自己的。
所以我们现在可以得到一个结论：同一个上下文里，第二次获取服务是使用的前一次的缓存，即之后无需担心getSystemService效率问题。
Android 6.0 (Marshmallow)
我们来看一下ContextImpl的代码
@Override
public Object getSystemService(String name) {
return SystemServiceRegistry.getSystemService(this, name);
}
我们发现,与 KitKat 大大不同, Marshmallow这里是从一个叫做SystemServiceRegistry的类去获取的.
好了,那我们去看它的源码,原来还是和以前一样的套路,不过是单独封装了一个类来管理这些注册的服务. 这么设计的确好,代码上的耦合度看上去小多了,且不会使得ContextImpl这个类越来月臃肿.
final class SystemServiceRegistry {
private final static String TAG = "SystemServiceRegistry";
// Service registry information.
// This information is never changed once static initialization has completed.
private static final HashMap<Class<?>, String> SYSTEM_SERVICE_NAMES =
new HashMap<Class<?>, String>();
private static final HashMap<String, ServiceFetcher<?>> SYSTEM_SERVICE_FETCHERS =
new HashMap<String, ServiceFetcher<?>>();
private static int sServiceCacheSize;
// Not instantiable.
private SystemServiceRegistry() { }
static {
registerService(Context.ACCESSIBILITY_SERVICE, AccessibilityManager.class,
new CachedServiceFetcher<AccessibilityManager>() {
@Override
public AccessibilityManager createService(ContextImpl ctx) {
return AccessibilityManager.getInstance(ctx);
}});
registerService(Context.CAPTIONING_SERVICE, CaptioningManager.class,
new CachedServiceFetcher<CaptioningManager>() {
@Override
public CaptioningManager createService(ContextImpl ctx) {
return new CaptioningManager(ctx);
}});
....
So.我们 Marshmallow 的系统服务应该在SystemServiceRegistry类中添加.一样的方式.
之后我们再getSystemService,传入注册时的名称,就可以获取到我们的服务对象了了.
本文作者：Anderson/Jerey_Jobs
博客地址 ： 夏敏的博客/Anderson大码渣/Jerey_Jobs
简书地址 : Anderson大码渣
github地址 : Jerey_Jobs
