深入理解Service生命周期及前台服务

Service是干嘛的？

Service是Android中实现程序后台运行的解决方案，它非常适合于去执行那些不需要和用户交互但又需要长期运行的任务。Service的运行不依赖与任何用户界面，即使应用被切换到后台，又或者用户打开了另一个应用程序，Service依然能够保持正常运行，除非被用户或系统强行kill掉。

在Service的概念中，我们经常容易将其与Thread弄混淆。
首先明确一个概念，Service是Android为了辅助我们完成不需要前台显示与交互的任务时所提供的一种组件，而Thread则是CPU调度的基本单位。
Service默认是运行在主线程中的，即UI线程。由于Android主线程的特殊性，导致我们在开发的过程中只能将耗时操作放至子线程中完成。而Activity主要用于做视图显示与用户交互，其生命周期与其是否位于前台和是否可见一一对应，不适用于对用户交互不敏感的耗时操作，所以我们经常会将Service与Thread结合起来，以实现能在后台中完成耗时操作的效果，如网络请求、读写IO等。
换句话说，如果我们有本事霸占着用户的手机显示界面，同样可以通过在Activity中采用多线程的方式来执行耗时任务（手动狗头）。

Service生命周期

Service生命周期图.png

下面从Service的两种启动方式来讲解Service的生命周期

启动Service

应用组件（如Activity、Service）通过调用startService()方法来启动一个Service，其生命周期回调函数的执行顺序为onCreate --> onStartCommand。
多次调用startService方法来启动同一个Service，Service的onCreate只会在第一次被启动时调用，而onStartCommand在每次启动Service时都会被调用，并且为每次请求生成一个int值startId进行标识。

onStartCommand源码.png

其中，onStartCommand有四种返回值

START_STICKY：如果service在启动后被kill掉，会保留service的状态为开始状态，但不保留递送的intent对象。随后系统会尝试重新创建service，由于服务状态处于开始状态，所以创建service后会调用onStartCommand方法。如在此期间没有任何启动的intent传递过来，那么该回调方法的intent对象就会为null。
START_NOT_STICKY：与START_STICKY相对，service进程被kill掉，系统不会主动重新创建该service。
START_REDELIVER_INTENT：如果service在启动后被kill掉，系统会安排其重启，并将上次传递的intent重新传递到onStartCommand。
START_STICKY_COMPATIBILITY：START_STICKY的兼容版本，但不保证service能重启成功。

与启动相对的，则是停止Service，对应的方法是应用组件的stopService()或者Service自身调用stopSelf()。停止Service会导致Service生命周期中的onDestroy被回调。

stopSelf源码.png

其中，stopSelf方法需要传入一个int值，该int值代表最近一次被执行的请求，即onStartCommand中生成的startId（无参的stopSelf其内部调用的还是stopSelf（int），只不过参数为-1，代表直接结束该Service）。如果最近一次处理的请求是startId，那么就停止Service。这样做能让我们更加安全的停止Service，保证进入onStartCommand中的请求都能得到完整处理。

注意
多次启动只会导致多次调用onStartCommand，而onCreate和onDestroy只会在启动和结束的时候被调用。

绑定Service

应用组件能够通过bindService的方式绑定一个Service，以便创建长期的连接，特别是在Android的IPC机制中。
与其他的生命周期回调函数不同，onBind回调方法必须要进行实现，用以返回实现Ibinder接口的对象。启动服务的应用组件会在bindService中添加一个实现了ServiceConnection接口的对象，用于绑定成功之后的回调传递Binder。

其中bindService中第三个参数为标志位，有如下几种：

BIND_AUTO_CREATE：绑定服务时，如果服务尚未创建就会自动创建。
BIND_DEBUG_UNBIND：通常用于Debug。
BIND_NOT_FOREGROUND：不会将被绑定的服务提升到前台的优先级。
BIND_ABOVE_CLIENT：设置服务的进程优先级高于客户端优先级。
BIND_ALLOW_OOM_MANAGEMENT：当内存不足时，会销毁服务。

应用组件可通过unbindService的方式解绑一个Service。若该Service从未启动过，则从绑定到解除绑定Servcie的生命周期回调为：onCreate --> onBind --> onUnbind --> onDestroy

多个应用组件可以同时绑定一个Service，但是onBind方法只会在第一次绑定时被回调。当所有应用组件都解绑Service后，Service才会调用其生命周期中的onUnbind方法。并且onUnbind同样也只会在第一次完全解绑时被回调。

onRebind源码.png

Service针对绑定操作，其生命周期回调中还有一个特殊方法onRebind。这个方法一般不会被调用，只有当Service保持启动状态的前提下，所有绑定都解除并且onUnbind被覆写改为返回为true时，才会在下次bindService时被调用。以上提到的几点条件缺一不可。

混合操作

有时候我们对Service同时进行启动和绑定操作，那么其生命周期就会变得较为复杂。面对这种问题时需要记住的是，生命周期的回调函数一般都是成对出现的。

onCreate-----onDestroy：对应Service的创建和销毁
onBind-----onUnbind：对应Service被初次绑定与完全解绑
onStartComand：这个是个奇葩，没有对应的生命周期回调，在每次启动Service时都会被调用

若我们既启动了Service也绑定了Service，那么就必须保证在解除所有绑定的同时也调用stopService来停止Service，才可能真正的结束掉该Service。

下面比较常见的Service生命周期函数的回调顺序：

由绑定Service开始：onCreate --> onBind --> onStartCommand（多次） --> onUnbind --> onDestroy
由启动Service开始：onCreate --> onStartCommand（多次） --> onBind --> onStartCommand（多次） --> onUnbind --> onDestroy

若存在onRebind，则情况较为特殊。
上面我们描述了onRebind起作用的前置条件，这里不再赘述。在满足onRebind能起作用的前置条件下，我们有可能会见到如下生命周期回调顺序：
onCreate --> onStartCommand --> onBind --> onUnbind --> onRebind --> onUnbind --> onRebind --> onUnbind --> onDestroy
该回调中，当每次所有绑定都解除后会调用onUnbind方法，然后在下一次绑定时会调用onRebind方法，并且多次绑定只会在第一个绑定时执行onRebind方法。

stackoverflow参考回答.png

具体绑定执行流程图可参考下图

Service绑定流程图

前台服务

由于Service几乎都是在后台运行的，其系统优先级通常较低，所以在系统出现内存不足的情况时，有可能会回收掉正在运行的Service。此外，纵然Service位于后台，但是在某些特定需求下，其还是需要能与用户进行一些轻量级的信息显示与交互操作（如音乐播放的控制、天气状态显示等）。所以，Service还提供一种驻留在前台的方式：基于Notification的前台服务。

前台服务必须为状态栏提供通知，这意味着除非服务停止或者从前台移除，否则无法清除掉该通知。要想让服务运行于前台，则必须调用startForeground()方法。此方法需要两个参数：唯一的用于标识通知的整形数(不能为0)和Notification对象。

startForeground(ONGOING_NOTIFICATION_ID, notification);

要想从前台移除服务，得调用stopForeground()。此方法要传入一个布尔值，指示是否同时移除掉状态栏的通知。这个方法不会停止该服务。

具体的Notification如何创建不在本文的研究范畴。详情参考官方技术文档。

若您觉得本文章对您有用，请您为我点上一颗小心心以表支持。感谢！