6 Service
6.1 service介绍
6.1.1. 基本介绍
Service是Android四大组件之中的一个（其余的是activity、BroadcastReceiver、Content Provider）。
Service（服务）是一个没实用户界面的在后台执行执行耗时操作的应用组件。其它应用组件可以启动Service。而且当用户切换到另外的应用场景，Service将持续在后台执行。另外。一个组件可以绑定到一个service并与之交互（IPC机制），比如，一个service可能会处理网络操作，播放音乐。操作文件I/O或者与内容提供者（content provider）交互。全部这些活动都是在后台进行。不同应用程序也可以通过service来实现进程间通信(IPC)。
service不能自己启动执行，它须要通过某一个Activity或者其它Context对象来启动。假设在Service的onCreate或者onStart做一些非常耗时间的事情。最好在 Service里启动一个线程来完毕，由于Service是跑在主线程中，会影响到UI操作或者堵塞主线程中的其它事情。
官方对Service的定义：
API Guides：Services
http://developer.android.com/guide/components/services.html
API Guides：Bound Services http://developer.android.com/guide/components/bound-services.html
6.1.2. service的生命周期
Service的生命周期图：
service的生命周期，从它被创建開始。到它被销毁为止。依据启动方式不同，
能够有两条不同的路径：
通过startService()启动
被开启的service通过其它组件调用 startService()被创建。这样的service能够无限地执行下去。必须调用stopSelf()方法或者其它组件调用stopService()方法来停止它。当service被停止时。系统会销毁它。
通过bindService()启动
被绑定的service是当其它组件（一个客户）调用bindService()来创建的。
客户能够通过一个IBinder接口和service进行通信。客户能够通 unbindService()方法来关闭这样的连接。
一个service能够同一时候和多个客户绑定。当多个客户都解除绑定之后。系统会销毁service。 这两条路径并非全然分开的。即是说，你能够和一个已经调用了 startService()而被开启的service进行绑定。
service总体的生命时间是从onCreate()被调用開始，到onDestroy()方法返回为止。和activity一样，service在onCreate()中进行它的初始化工作。在onDestroy()中释放残留的资源。
service活动的生命时间（active lifetime）是从onStartCommand() 或onBind()被调用開始，
它们各自处理由startService()或 bindService()方法传过来的Intent对象。
假设service是被开启的，那么它的活动生命周期和整个生命周期一同结束。
假设service是被绑定的。它们它的活动生命周期是在onUnbind()方法返回后结束。
6.1.3. service的启动方式
有了 Service 类我们怎样启动他呢，通常有两种方法：
• Context.startService()
• Context.bindService()
Ps:跨进程通信：AIDL。这也能够启动服务。
使用context.startService() 启动Service
其生命周期为context.startService() ->onCreate()- >onStart()->Service running-->(假设调用context.stopService() )->onDestroy() ->Service shut down
假设Service还没有执行，则android先调用onCreate()然后调用onStart()；
假设Service已经执行。则仅仅调用onStart()，所以一个Service的onStart方法可能会反复调用多次。
调用stopService的时候直接onDestroy，
假设是调用者自己直接退出而没有调用stopService的话。Service会一直在后台执行。
该Service的调用者再启动起来后能够通过stopService关闭Service。
所以调用startService的生命周期为：onCreate --> onStart(可多次调用)
--> onDestroy
使用bindService()启动Service：
context.bindService()->onCreate()->onBind()->Service running-->onUnbind() -> onDestroy() ->Service stop
onBind将返回给client一个IBind接口实例，IBind同意client回调服务的方法，比方得到Service执行的状态或其它操作。这个时候把调用者（Context。比如Activity）会和Service绑定在一起。Context退出了，Srevice就会调用onUnbind->onDestroy对应退出。
所以调用bindService的生命周期为：onCreate --> onBind(仅仅一次，不可多次绑定) --> onUnbind --> onDestory。一但销毁activity它就结束，假设按home把它放到后台。那他就不退出。
PS：在Service每一次的开启关闭过程中，仅仅有onStart可被多次调用(通过多次startService调用)，其它onCreate，onBind，onUnbind，onDestory在一个生命周期中仅仅能被调用一次。
6.1.4. 其它方面
提高 Service 优先级
Android 系统对于内存管理有自己的一套方法。为了保障系统有序稳定的执行，
系统内部会自己主动分配，控制程序的内存使用。当系统觉得当前的资源很有限的时候，为了保 证一些优先级高的程序能执行，就会杀掉一些他觉得不重要的程序或者服务来释放内存。
这样就能保证真正对用户实用的程序仍然再执行。
假设你的 Service 碰上了这样的情况，多半会先被杀掉。
但假设你添加 Service 的优先级就能让他多留一会，我们能够用 setForeground(true) 来设置 Service 的优先级。
为什么是 foreground ? 默认启动的 Service 是被标记为 background，当前执行的 Activity 一般被标记为 foreground，也就是说你给 Service 设置了 foreground 那么他就和正在执行的 Activity 类似优先级得到了一定的提高。当让这并不能保证你得 Service 永远不被杀掉。仅仅是提高了他的优先级。
设置 Service 訪问空间
在应用声明service的manifest文件中面，声明service的时候。设置其exported属性,能够控制service被安全訪问。
6.2 代码分析
6.1.1. startService
从前面的介绍我们知道，启动一个service能够使用startService（）来实现，我们现来分析startService的代码实现。
6.1.1.1. 阶段一：应用调用startService（）
启动service比較常见的是通过activity来启动，在activity里面调用startService
是怎样实现的呢？
首先，我们看以下的关系图，
|
Context |
抽象类。定义了一些全局常量和应用环境抽象方法。 |
|
ContextWrapper |
类。继承了Context，实现了父类方法，方法全都以类构建的时候传入的Context实例为基础实现，通过使用子类的实例，子类就能够不用重写很多函数。 |
|
ContextThemeWrapper |
类。继承了ContextWrapper，添加了theme相关的方法。 也是使用传入的Context实例为基础实现。 |
|
Activity |
类。继承了ContextThemeWrapper,作为应用窗体界面的父类，维护相关显示和交互功能。 |
|
Application |
类，继承了ContextWrapper，维护应用信息。 |
|
Service |
抽象类，继承了ContextWrapper， |
|
|
|
|
ContextImpl |
类。继承了Context，实现了父类方法，是Context类的真正实现之处。 它为activity、service、application提供了context实例。 |
能够看到，Activity继承自Context，ContextImpl是Context类的真正实现之处，所以在Activity里面调用startService。实际是在ContextImpl里运行，
public ComponentName startService(Intent service) {
warnIfCallingFromSystemProcess();
return startServiceCommon(service, mUser);
}
startServiceCommon的代码例如以下。
private ComponentName startServiceCommon(Intent service, UserHandle user) {
try {
validateServiceIntent(service);
service.prepareToLeaveProcess();
ComponentName cn = ActivityManagerNative.getDefault().startService(
mMainThread.getApplicationThread(), service,
service.resolveTypeIfNeeded(getContentResolver()), user.getIdentifier());
…
这里通过ActivityManagerNative获取到IActivityManager的实例。实际就是AMS的远程接口。使用Binder方式。调用AMS的startService方法，
public ComponentName startService(IApplicationThread caller, Intent service,
String resolvedType, int userId) throws RemoteException
{
Parcel data = Parcel.obtain();
Parcel reply = Parcel.obtain();
data.writeInterfaceToken(IActivityManager.descriptor);
data.writeStrongBinder(caller != null ? caller.asBinder() : null);
service.writeToParcel(data, 0);
data.writeString(resolvedType);
data.writeInt(userId);
mRemote.transact(START_SERVICE_TRANSACTION, data, reply, 0);
reply.readException();
ComponentName res = ComponentName.readFromParcel(reply);
data.recycle();
reply.recycle();
return res;
}
參数caller是一个ApplicationThread实例。它是在ActivityThread里通过ApplicationThread mAppThread = new ApplicationThread();创建的，ApplicationThread继承自ApplicationThreadNative。间接继承自Binder，在Android应用程序中。每个进程都用一个ActivityThread实例来表示，而在ActivityThread类中，成员变量mAppThread，它是一个ApplicationThread实例。实现了IApplicationThread接口，它的作用是用来辅助ActivityThread类来运行一些操作，这几者之间的相互关系见专门的章节。
參数service是一个Intent实例，它里面指定了要启动的服务的名称，就是我们在创建intent的时候使用的名称。
參数resolvedType是一个字符串。String类型，它表示service这个Intent的MIME类型，它是在解析Intent时用到的。
通过service.resolveTypeIfNeeded（）获取到。
6.1.1.2. 阶段二：AMS运行startService
在AMS里面。startService的实现例如以下，
public ComponentName startService(IApplicationThread caller, Intent service,
String resolvedType, int userId) {
enforceNotIsolatedCaller("startService");
…
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, userId);
Binder.restoreCallingIdentity(origId);
return res;
}
}
通过binder传递，调用到该方法，并解析出相关參数。当中，service是应用发起的intent，mServices是AMS里面定义的一个ActiveServices实例引用，其方法startServiceLocked经过參数推断和转化后，继续调用startServiceInnerLocked。进一步到bringUpServiceLocked，
当中在startService里，enforceNotIsolatedCaller("startService");用来推断应用是否被隔离。假设是。则抛出异常，推断方法是通过UID获取到APPID（APPID=UID%100000）。再推断APPID是否在隔离沙箱定义的UID范围之内（99000-99999），是的话就觉得是被隔离的应用，不同意启动服务。
通常APPID值是在10000到19999之间的。
ActiveServices类是AMS的辅助类，完毕。其成员变量mAm相应的就是一个AMS的实例，ActiveServices的startServiceLocked主要代码例如以下，
ComponentName startServiceLocked(IApplicationThread caller,
Intent service, String resolvedType,
int callingPid, int callingUid, int userId) {
…
//获取进程的执行状态
final ProcessRecord callerApp = mAm.getRecordForAppLocked(caller);
callerFg = callerApp.setSchedGroup != Process.THREAD_GROUP_BG_NONINTERACTIVE;
…
//新建一个ServiceLookupResult容器 。并创建ServiceRecord
ServiceLookupResult res =
retrieveServiceLocked(service, resolvedType,
callingPid, callingUid, userId, true, callerFg);
// record为空会返回
if (res.record == null) {
return new ComponentName("!", res.permission != null
? res.permission : "private to package");
}
ServiceRecord r = res.record;
//填充ServiceRecord的初始状态
r.lastActivity = SystemClock.uptimeMillis();
r.startRequested = true;
r.delayedStop = false;
r.pendingStarts.add(new ServiceRecord.StartItem(r, false, r.makeNextStartId(),
service, neededGrants));
…
if (!callerFg && r.app == null && mAm.mStartedUsers.get(r.userId) != null) {
…
}
//继续进一步调用
return startServiceInnerLocked(smap, service, r, callerFg, addToStarting);
mAm.getRecordForAppLocked通过IApplicationThread获取到其相应的进程信息，当前执行进程的信息都存放在ProcessRecord里面。通过进程信息，推断当前进程是前台进程还是后台进程，设置callerFg标识，供后面启动service处理。
retrieveServiceLocked 会根据userid新建一个ServiceMap，里面存放service的相关信息，再根据service的訪问权限和manifest里设置的exported属性，创建不同的ServiceLookupResult并返回，ServiceLookupResult的ServiceRecord类型成员record是ServiceRecord类型，存放的就是将要启动的service的状态信息，创建这个实例后，后面就開始初始状态。
假设record为null，会返回。
兴许的代码对ServiceRecord进行初始填充。
startServiceInnerLocked处理逻辑比較简单，主要是调用bringUpServiceLocked，再依据callerFg标识。处理服务的后台属性，主要代码例如以下，
ComponentName startServiceInnerLocked(ServiceMap smap, Intent service,
ServiceRecord r, boolean callerFg, boolean addToStarting) {
…
String error = bringUpServiceLocked(r, service.getFlags(), callerFg, false);
…
smap.ensureNotStartingBackground(r);
}
而bringUpServiceLocked的代码例如以下，
private final String bringUpServiceLocked(ServiceRecord r,
int intentFlags, boolean execInFg, boolean whileRestarting) {
…
if (r.app != null && r.app.thread != null) {
sendServiceArgsLocked(r, execInFg, false);
return null;
}
…
// Service is now being launched, its package can't be stopped.
try {
AppGlobals.getPackageManager().setPackageStoppedState(
r.packageName, false, r.userId);
app = mAm.getProcessRecordLocked(procName, r.appInfo.uid, false);
if (app != null && app.thread != null) {
try {
app.addPackage(r.appInfo.packageName, mAm.mProcessStats);
realStartServiceLocked(r, app, execInFg);
return null;
}}
if (app == null) {
if ((app=mAm.startProcessLocked(procName, r.appInfo, true, intentFlags,
"service", r.name, false, isolated, false)) == null) {
…
}}
能够看出，ServiceRecord类型的变量r在创建过程中并没有初始化app成员变量，所以不会运行sendServiceArgsLocked并返回。而是继续向下运行，当设置好包状态后，会通过AMS获取到启动应用的app实例，进而运行realStartServiceLocked，
realStartServiceLocked代码例如以下。
private final void realStartServiceLocked(ServiceRecord r,
ProcessRecord app, boolean execInFg) throws RemoteException {
…
app.services.add(r);
bumpServiceExecutingLocked(r, execInFg, "create");
mAm.updateLruProcessLocked(app, true, false);
…
app.forceProcessStateUpTo(ActivityManager.PROCESS_STATE_SERVICE);
app.thread.scheduleCreateService(r, r.serviceInfo,
mAm.compatibilityInfoForPackageLocked(r.serviceInfo.applicationInfo),
app.repProcState);
r.postNotification();
created = true;
requestServiceBindingsLocked(r, execInFg);
…
sendServiceArgsLocked(r, execInFg, true);
…
}
在realStartServiceLocked里面，有两个关键的流程，
一个是app.thread.scheduleCreateService的运行。它发送一个创建服务的CREATE_SERVICE消息出去，当消息被运行的时候，服务类被创建。service的Oncreate（）方法被运行，后面我们会具体分析。
还有一个是sendServiceArgsLocked。它会调用 scheduleServiceArgs，后者也会发出一个消息。当消息被运行时。service的Onstart（）方法被运行。
6.1.1.3. 第三阶段：Service创建和Oncreate（）运行
scheduleCreateService 的功能是发送一个创建服务的CREATE_SERVICE消息出去，当这个消息被处理时，会进行服务类的创建。
在ActivityThread.java的handleMessage里，会处理CREATE_SERVICE消息。处理的方法为handleCreateService，它会创建一个service实例。在service实例创建的时候，new一个ContextImpl。并调用init进行初始化，
private void handleCreateService(CreateServiceData data) {
java.lang.ClassLoader cl = packageInfo.getClassLoader();
service = (Service) cl.loadClass(data.info.name).newInstance();
…
ContextImpl context = new ContextImpl();
context.init(packageInfo, null, this);
Application app = packageInfo.makeApplication(false, mInstrumentation);
context.setOuterContext(service);
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, 0, 0, 0);
ContextImpl实例的内部的创建步骤例如以下：
ContextImpl有例如以下一些重要的变量。其类型和函数说明例如以下，
LoadedApk mPackageInfo 服务相应的包信息。
ActivityThread mMainThread 启动服务的应用相应的ActivityThread，
Context mOuterContext 服务相应的ContextImpl所关联的Context。就是要创建的服务实例。
UserHandle mUser 应用进程UID相应的UserHandle，
它另一个SYSTEM_SERVICE_MAP的hashMap。通过registerService。用来存放系统服务的接口实例，这个数组的初始化过程在static语句块里面。
private static void registerService(String serviceName, ServiceFetcher fetcher) {
if (!(fetcher instanceof StaticServiceFetcher)) {
fetcher.mContextCacheIndex = sNextPerContextServiceCacheIndex++;
}
SYSTEM_SERVICE_MAP.put(serviceName, fetcher);
}
…
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);
}});
…
registerService(ACTIVITY_SERVICE, new ServiceFetcher() {
public Object createService(ContextImpl ctx) {
return new ActivityManager(ctx.getOuterContext(), ctx.mMainThread.getHandler());
}});
对于ContextImpl实例的创建。除了以下的初始化函数外，依据类的创建过程，也包括上面静态语句块的运行。
ContextImpl() {
mOuterContext = this;
}
ContextImpl.init的目的就是完毕上面提到过的基本的成员变量的初始化。让使用这个类的方法能使用相关类提供的服务。
final void init(LoadedApk packageInfo, IBinder activityToken, ActivityThread mainThread,
Resources container, String basePackageName, UserHandle user) {
mPackageInfo = packageInfo;
…
mResources = mPackageInfo.getResources(mainThread);
mResourcesManager = ResourcesManager.getInstance();
…
mMainThread = mainThread;
mActivityToken = activityToken;
mContentResolver = new ApplicationContentResolver(this, mainThread, user);
mUser = user;
}
mMainThread就是创建服务的应用相应的ActivityThread，
packageInfo 就是要创建的服务类的包信息。
mUser 相应于Process.myUserHandle()。
对于service。还要将mOuterContext设置为service的实例。
context.setOuterContext(service);
final void setOuterContext(Context context) {
mOuterContext = context;
}
创建服务的时候，还须要获取到一个Application实例。对于同一个包，公用一个应用，在第一次启动应用时，须要创建一个应用。应用相同也要新建一个ContextImpl实例。并与之关联起来，
public Application makeApplication(boolean forceDefaultAppClass,
Instrumentation instrumentation) {
if (mApplication != null) {
return mApplication;
}
…
java.lang.ClassLoader cl = getClassLoader();
ContextImpl appContext = new ContextImpl();
appContext.init(this, null, mActivityThread);
app = mActivityThread.mInstrumentation.newApplication(
cl, appClass, appContext);
appContext.setOuterContext(app);
…
mActivityThread.mAllApplications.add(app);
mApplication = app;
if (instrumentation != null) {
try {
instrumentation.callApplicationOnCreate(app);
…
service.attach的目的就是在创建service实例后，把service里一些关键的成员变量初始化。和关联类相互关联起来，如context、mThread、mApplication、mActivityManager，
public final void attach(
Context context,
ActivityThread thread, String className, IBinder token,
Application application, Object activityManager) {
attachBaseContext(context);
mThread = thread; // NOTE: unused - remove?
mClassName = className;
mToken = token;
mApplication = application;
mActivityManager = (IActivityManager)activityManager;
mStartCompatibility = getApplicationInfo().targetSdkVersion
< Build.VERSION_CODES.ECLAIR;
}
之后，便開始运行service的onCreate（）方法了，service类本身是一个抽象类，其onCreate类就须要子类自行实现了。
6.1.1.4. 第四阶段：Onstart（）方法被运行
如前所述，在sendServiceArgsLocked会调用r.app.thread.scheduleServiceArgs（），
后者会发送一个SERVICE_ARGS消息。这个消息会被ActivityThread.java的handleMessage方法处理，详细处理方法则为handleServiceArgs，
private void handleServiceArgs(ServiceArgsData data) {
Service s = mServices.get(data.token);
if (data.args != null) {
data.args.setExtrasClassLoader(s.getClassLoader());
}
int res;
if (!data.taskRemoved) {
res = s.onStartCommand(data.args, data.flags, data.startId);
} else {
s.onTaskRemoved(data.args);
res = Service.START_TASK_REMOVED_COMPLETE;
}
QueuedWork.waitToFinish();
try {
ActivityManagerNative.getDefault().serviceDoneExecuting(
data.token, 1, data.startId, res);
} catch (RemoteException e) {
// nothing to do.
}
ensureJitEnabled();
}
当中onStartCommand会调用onStart（）方法。相同，因为service是抽象类。所以会运行到用户自己定义的类。
至此，service的启动过程分析完毕。上面仅仅是分析了其启动的主流程，而实际上，因为各种不同的状态。其启动过程比这复杂非常多。
6.1.1.5. 总结StartService启动流程
综上所述。Service的启动流程例如以下：