Android系统服务是如何获取的
关于获取系统服务的猜想
Android获取系统服务一般都需要用getSystemService指定系统服务名称获取：
val wm = getSystemService(Context.WINDOW_SERVICE) as WindowManager
在实际开发中，当我们需要编写提供某一业务流程处理的Manager，通常会实现为单例。那么上面那行代码背后发生了什么，为什么Android不使用单例模式呢？下面我们观察Android是如何设计获取系统服务的，它如何从应用侧到达系统侧。
可以思考一下，不在每个服务中单独使用单例的原因大概是因为Android提供的系统服务众多，都使用getSystemService方法相当于提供了统一的入口。同时因为方法参数中的服务名称字符串，可以提供一个Map来统一存放各种服务实例，这与单例模式十分接近，相当于统一管理各种单例的变种。那么事实是不是这样呢？（下方源码只保留关键代码，API 30）
获取系统服务源码实现
各种继承或者持有Context的组件的getSystemService方法都会调用ContextImpl的同名方法：
//ContextImpl.java
public Object getSystemService(String name) {
return SystemServiceRegistry.getSystemService(this, name);
}
SystemServiceRegistry一看就是统一注册系统服务的地方：
//SystemServiceRegistry.java
public static Object getSystemService(ContextImpl ctx, String name) {
final ServiceFetcher<?> fetcher = SYSTEM_SERVICE_FETCHERS.get(name);
final Object ret = fetcher.getService(ctx);
return ret;
}
这里我们确实发现了Map，可却不是从String到系统服务的Map，SYSTEM_SERVICE_FETCHERS的类型为Map<String, ServiceFetcher<?>>。
//SystemServiceRegistry.java
static abstract interface ServiceFetcher<T> {
T getService(ContextImpl ctx);
}
这个SystemServiceRegistry中的内部接口ServiceFetcher，看上去像是各种系统服务的工厂接口。我们看它的实现类：
//SystemServiceRegistry.java
static abstract class CachedServiceFetcher<T> implements ServiceFetcher<T> {
private final int mCacheIndex;
CachedServiceFetcher() {
mCacheIndex = sServiceCacheSize++;
}
@Override
public final T getService(ContextImpl ctx) {
final Object[] cache = ctx.mServiceCache;
T ret = null;
T service = (T) cache[mCacheIndex];
if (service != null) {
ret = service;
} else {
service = createService(ctx);
cache[mCacheIndex] = service;
ret = service;
}
return ret;
}
public abstract T createService(ContextImpl ctx) throws ServiceNotFoundException;
}
getService方法精简了大量保证线程安全的同步措施，只保留了最核心的逻辑。可以看到另有一个类型为Object[]的数组ctx.mServiceCache，getService从中用下标mCacheIndex获取系统服务，如果服务为空则使用createService方法创建服务并放在数组中。可以说，这个ctx.mServiceCache数组起到了我们最初设想的从String到系统服务的Map的存放所有系统服务的作用。这个映射变为了：
假象的映射（从String到系统服务） <=> SYSTEM_SERVICE_FETCHERS映射（从String到ServiceFetcher）
+ ctx.mServiceCache数组（ServiceFetcher中的mCacheIndex下标到系统服务）
这个SYSTEM_SERVICE_FETCHERS映射在SystemServiceRegistry的静态初始化快中被统一填充，同时提供了上方没有实现的createService：
//SystemServiceRegistry.java
static {
registerService(Context.WINDOW_SERVICE, WindowManager.class,
new CachedServiceFetcher<WindowManager>() {
@Override
public WindowManager createService(ContextImpl ctx) {
return new WindowManagerImpl(ctx);
}});
}
private static <T> void registerService(@NonNull String serviceName,
@NonNull Class<T> serviceClass, @NonNull ServiceFetcher<T> serviceFetcher) {
SYSTEM_SERVICE_FETCHERS.put(serviceName, serviceFetcher);
}
SystemServiceRegistry类初始化时，ctx.mServiceCache系统服务数组还是空的，当某一系统服务需要时，上方CachedServiceFetcher中getService会调用createService创建服务并存放在特定mCacheIndex下标中。
总结一下就是：在Android获取系统服务的流程中，使用工厂模式创建系统服务，使用Map管理工厂，使用数组管理系统服务实例。每种服务在每个ContextImpl中的数组中最多只有一个，且使用前不会提前创建，这点和单例的懒汉式是一致的。
真正的系统服务提供者
我们知道Android Framework中系统服务是运行在系统进程中，需要通过Binder机制与应用进程通信，如果我们不考虑系统侧实现，上面拿到的类真的应用侧的Binder类么？其实并不全是，依旧查看工厂类中的工厂方法：
- 上面获取到的服务类，有些类的确是系统侧的系统服务对应到应用侧的Binder类，比如AlarmManager：
//SystemServiceRegistry.java
registerService(Context.ALARM_SERVICE, AlarmManager.class,
new CachedServiceFetcher<AlarmManager>() {
@Override
public AlarmManager createService(ContextImpl ctx) throws ServiceNotFoundException {
IBinder b = ServiceManager.getServiceOrThrow(Context.ALARM_SERVICE);
IAlarmManager service = IAlarmManager.Stub.asInterface(b);
return new AlarmManager(service, ctx);
}});
- 有些则是对这些Binder类的直接封装，比如ActivityManager：
//SystemServiceRegistry.java
registerService(Context.ACTIVITY_SERVICE, ActivityManager.class,
new CachedServiceFetcher<ActivityManager>() {
@Override
public ActivityManager createService(ContextImpl ctx) {
return new ActivityManager(ctx.getOuterContext(), ctx.mMainThread.getHandler());
}});
其中大量的方法使用getService与getTaskService进行委托：
//ActivityManager.java
public void killUid(int uid, String reason) {
try {
getService().killUid(UserHandle.getAppId(uid),
UserHandle.getUserId(uid), reason);
} catch (RemoteException e) {
throw e.rethrowFromSystemServer();
}
}
public List<RunningTaskInfo> getRunningTasks(int maxNum)
throws SecurityException {
try {
return getTaskService().getTasks(maxNum);
} catch (RemoteException e) {
throw e.rethrowFromSystemServer();
}
}
public static IActivityManager getService() {
return IActivityManagerSingleton.get();
}
private static IActivityTaskManager getTaskService() {
return ActivityTaskManager.getService();
}
而getService与getTaskService都是单例方法，另外使用ServiceManager获取真正的Binder类。
- 另外还有些系统服务为了便于使用，封装得更加复杂，比如WindowManager：
registerService(Context.WINDOW_SERVICE, WindowManager.class,
new CachedServiceFetcher<WindowManager>() {
@Override
public WindowManager createService(ContextImpl ctx) {
return new WindowManagerImpl(ctx);
}});
这里的各不同Context的WindowManagerImpl会统一调用到WindowManagerGlobal，而WindowManagerGlobal在addView时会创建ViewRootImpl，并将Binder类WindowSession传递给ViewRootImpl，由ViewRootImpl完成与WMS通信的工作。
以上实现了获取系统服务时从应用侧到达系统侧的过程。
以上就是Android系统服务是如何获取的的详细内容，更多关于Android系统服务获取的资料请关注脚本之家其它相关文章！
相关文章
这篇文章主要为大家介绍了Android开发自定义短信验证码实现过程详解，有需要的朋友可以借鉴参考下，希望能够有所帮助，祝大家多多进步，早日升职加薪2023-06-06
Flutter 底部弹窗ModelBottomSheet的使用示例
在实际开发过程中，经常会用到底部弹窗来进行快捷操作，例如选择一个选项，选择下一步操作等等。在 Flutter 中提供了一个 showModelBottomSheet 方法用于弹出底部弹窗，本篇介绍如何使用底部弹窗。2021-06-06
这篇文章主要为大家详细介绍了Android实现图片点击爆炸效果，文中示例代码介绍的非常详细，具有一定的参考价值，感兴趣的小伙伴们可以参考一下2020-08-08
本篇文章主要介绍了Android之沉浸式状态栏的实现方法、状态栏透明，具有一定的参考价值，有兴趣的可以了解一下。2017-02-02
这篇文章主要介绍了安卓11适配攻略抢先看,文中通过示例代码介绍的非常详细，对大家的学习或者工作具有一定的参考学习价值，需要的朋友们下面随着小编来一起学习学习吧2020-10-10
Android View源码解读 DecorView与ViewRootImpl浅谈
这篇文章主要解读了Android View源码，为大家详细介绍DecorView与ViewRootImpl，具有一定的参考价值，感兴趣的小伙伴们可以参考一下2017-02-02
在开发过程中经常需要使用文本，有时候需要对一段文字中的部分文字进行特殊的处理，如改变其中部分文字的大小、颜色、加下划线等。本文将为大家介绍如何实现这些效果，感兴趣的可以学习一下2022-01-01
这篇文章主要介绍了Android 实现截屏功能的实例的相关资料,这里实现截屏的实例在代码中注释非常清楚，希望能帮助到大家，需要的朋友可以参考下2017-08-08
这篇文章主要介绍了android中intent传递list或者对象的方法,分析罗列了常用的几种方法,具有一定参考借鉴价值,需要的朋友可以参考下2015-01-01
本篇文章主要介绍了Android中WebView常见问题及解决方案汇总，把WebView遇到的问题详细的罗列下来，有需要的朋友可以了解一下。2016-11-11
最新评论