Service启动过程分析
Service是一种计算型组件，用于在后台执行一系列的计算任务。由于工作在后台，因此用户是无法直接感知到它的存在。Service组件和Activity组件略有不同，Activity组件只有一种运行模式，即Activity处于启动状态，但是Service组件却有两种状态：启动状态和绑定状态。当Service组件处于启动状态时，这个时候Service内部可以做一些后台计算，并且不需要和外界有直接的交互。
Service分为两种工作状态，一种是启动状态，主要用于执行后台计算，另一张是绑定状态，主要用于其他组件和Service的交互，需要注意的是Service的这两种状态是可以共存的，即Service既可以处于启动状态也可以同时处于绑定状态。
Service的启动过程
Service的启动过程从ContextWrapper的startService开始。
@Override
public ComponentName startService(Intent service) {
return mBase.startService(service);
}
这里的mBase的类型是ContextImpl，其实说到这，就得说下Activity被创建时会通过attach方法将一个ContextImpl对象关联起来，这也就是mBase。从ContextWrapper的实现可以看出，其中大部分操作都是通过mBase来实现的，在设计模式中这是一种典型的桥接模式。
@Override
public ComponentName startService(Intent service) {
warnIfCallingFromSystemProcess();
return startServiceCommon(service, mUser);
}
private ComponentName startServiceCommon(Intent service, UserHandle user) {
try {
validateServiceIntent(service);
service.prepareToLeaveProcess(this);
ComponentName cn = ActivityManagerNative.getDefault().startService(
mMainThread.getApplicationThread(), service, service.resolveTypeIfNeeded(
getContentResolver()), getOpPackageName(), user.getIdentifier());
if (cn != null) {
if (cn.getPackageName().equals("!")) {
throw new SecurityException(
"Not allowed to start service " + service
+ " without permission " + cn.getClassName());
} else if (cn.getPackageName().equals("!!")) {
throw new SecurityException(
"Unable to start service " + service
+ ": " + cn.getClassName());
}
}
return cn;
} catch (RemoteException e) {
throw e.rethrowFromSystemServer();
从startServiceCommon方法中可以看出，是ActivityManagerNative.getDefault()这个方法的类启动的，其实ActivityManagerNative.getDefault()就是AMS，是通过AMS来启动服务的行为是一个远程过程调用。
@Override
public ComponentName startService(IApplicationThread caller, Intent service,
String resolvedType, String callingPackage, int userId)
throws TransactionTooLargeException {
enforceNotIsolatedCaller("startService");
// Refuse possible leaked file descriptors
if (service != null && service.hasFileDescriptors() == true) {
throw new IllegalArgumentException("File descriptors passed in Intent");
}
if (callingPackage == null) {
throw new IllegalArgumentException("callingPackage cannot be null");
}
if (DEBUG_SERVICE) Slog.v(TAG_SERVICE,
"startService: " + service + " type=" + resolvedType);
synchronized(this) {
final int callingPid = Binder.getCallingPid();
final int callingUid = Binder.getCallingUid();
final long origId = Binder.clearCallingIdentity();
ComponentName res = mServices.startServiceLocked(caller, service,
resolvedType, callingPid, callingUid, callingPackage, userId);
Binder.restoreCallingIdentity(origId);
return res;
}
}
在上面的代码中，AMS会通过mServices这个对象来完成Service后续的启动过程，mServices对象的类型是ActiveService，ActiveService是一个辅助AMS进行Service管理的类，包括Service的启动、绑定和停止等。
最终是通过app.thread的scheduleCreateService方法来创建Service对象并调用onCreate，接着再通过sendServiceArgsLocked方法来调用Service的其他方法，比如onStartCommand，这两个过程均是进程间通信，到最后是通过ApplicationThread的scheduleCreateService方法来
public final void scheduleCreateService(IBinder token, ServiceInfo info, CompatibilityInfo compatInfo, int processState) {
updateProcessState(processState, false);
CreateServiceData s = new CreateServiceData();
s.token = token;
s.info = info;
s.compatInfo = compatInfo;
sendMessage(H.CREATE_SERVICE, s);
}
是通过发消息给Handler H，H会接收这个CREATE_SERVICE消息并通过handleCreateService方法来完成Service的最终启动。
private void handleCreateService(CreateServiceData data) {
// If we are getting ready to gc after going to the background, well
// we are back active so skip it.
unscheduleGcIdler();
LoadedApk packageInfo = getPackageInfoNoCheck(
data.info.applicationInfo, data.compatInfo);
Service service = null;
try {
java.lang.ClassLoader cl = packageInfo.getClassLoader();
service = (Service) cl.loadClass(data.info.name).newInstance();
} catch (Exception e) {
if (!mInstrumentation.onException(service, e)) {
throw new RuntimeException(
"Unable to instantiate service " + data.info.name
+ ": " + e.toString(), e);
}
}
try {
if (localLOGV) Slog.v(TAG, "Creating service " + data.info.name);
ContextImpl context = ContextImpl.createAppContext(this, packageInfo);
context.setOuterContext(service);
Application app = packageInfo.makeApplication(false, mInstrumentation);
service.attach(context, this, data.info.name, data.token, app,
ActivityManagerNative.getDefault());
service.onCreate();
mServices.put(data.token, service);
try {
ActivityManagerNative.getDefault().serviceDoneExecuting(
data.token, SERVICE_DONE_EXECUTING_ANON, 0, 0);
} catch (RemoteException e) {
throw e.rethrowFromSystemServer();
}
} catch (Exception e) {
if (!mInstrumentation.onException(service, e)) {
throw new RuntimeException(
"Unable to create service " + data.info.name
+ ": " + e.toString(), e);
}
}
}
handleCreateService主要完成了如下几件事：
- 通过类加载器创建Service的实例
- 创建Application对象并调用其onCreate，当然Application的创建过程只会有一次。
- 接着创建ConTextImpl对象并通过Service的attach方法建立二者之间的关系。
- 最后调用onCreate方法，并将Service对象存储到ActivityThreadd的一个列表中。
Service的绑定过程
和Service的启动过程一样，Service绑定过程也是从ContextWrapper开始的。
@Override
public boolean bindService(Intent service, ServiceConnection conn,
int flags) {
return mBase.bindService(service, conn, flags);
}
然后会调用bindServiceCommon方法，这个方法主要完成如下两件事情：
- 首先将客户端的ServiceConnection对象转化为ServiceDispatcher.InnerConnection对象。
- 接着bindServiceCommon会通过AMS来完成Service的具体绑定过程，对应于AMS的bindService方法。
最终也是调用handleBindService来处理。
private void handleBindService(BindServiceData data) {
Service s = mServices.get(data.token);
if (DEBUG_SERVICE)
Slog.v(TAG, "handleBindService s=" + s + " rebind=" + data.rebind);
if (s != null) {
try {
data.intent.setExtrasClassLoader(s.getClassLoader());
data.intent.prepareToEnterProcess();
try {
if (!data.rebind) {
IBinder binder = s.onBind(data.intent);
ActivityManagerNative.getDefault().publishService(
data.token, data.intent, binder);
} else {
s.onRebind(data.intent);
ActivityManagerNative.getDefault().serviceDoneExecuting(
data.token, SERVICE_DONE_EXECUTING_ANON, 0, 0);
}
ensureJitEnabled();
} catch (RemoteException ex) {
throw ex.rethrowFromSystemServer();
}
} catch (Exception e) {
if (!mInstrumentation.onException(s, e)) {
throw new RuntimeException(
"Unable to bind to service " + s
+ " with " + data.intent + ": " + e.toString(), e);
}
}
}
}
最后，以借用一张流程图来说明：
阅读扩展
源于对掌握的Android开发基础点进行整理，罗列下已经总结的文章，从中可以看到技术积累的过程。
1，Android系统简介
2，ProGuard代码混淆
3，讲讲Handler+Looper+MessageQueue关系
4，Android图片加载库理解
5，谈谈Android运行时权限理解
6，EventBus初理解
7，Android 常见工具类
8，对于Fragment的一些理解
9，Android 四大组件之 " Activity "
10，Android 四大组件之" Service "
11，Android 四大组件之“ BroadcastReceiver "
12，Android 四大组件之" ContentProvider "
13，讲讲 Android 事件拦截机制
14，Android 动画的理解
15，Android 生命周期和启动模式
16，Android IPC 机制
17，View 的事件体系
18，View 的工作原理
19，理解 Window 和 WindowManager
20，Activity 启动过程分析
21，Service 启动过程分析
22，Android 性能优化
23，Android 消息机制
24，Android Bitmap相关
25，Android 线程和线程池
26，Android 中的 Drawable 和动画
27，RecylerView 中的装饰者模式
28，Android 触摸事件机制
29，Android 事件机制应用
30，Cordova 框架的一些理解
31，有关 Android 插件化思考
32，开发人员必备技能——单元测试
