四大组件之Service详解

生命周期

694018-99da2307c5d69134.jpg

从图中可以看出Service的生命周期会根据启动方式的不同有不同的生命周期回调。两种启动方式分别是startService和bindService。

两种启动方式的生命周期

startService的生命周期是：onCreate() -> onStart() -> onDestroy()
bindService的生命周期是：onCreate() -> onBind() -> onUnbind() -> onDestroy()

两种启动方式的区别

用startService方法开启服务，这个Service和Client之间没有联系，Service的运行和Client是相互独立的，想结束这个Service的话，就在Service本身中调用stopSelf()方法结束服务或者Client调用Service的stopService()方法。
用bindService方法开启服务，这个Service和Client是有绑定关系的，可以进行数据交互（使用Binder的代理对象），想要结束这个Service，可以通过调用unbindService()方法，或者调用的Client被销毁，绑定的Service也会随之销毁。

一个Service只有一个实例，onCreate()只有在第一次Service实例被创建的时候才会调用，即在Service没被销毁前无论调用startService或bindService多少次，onCreate()只有在第一次才会执行，所以一般在这里做一些初始化工作，比如创建数据缓存，线程池等；onBind()也只有在第一次被绑定时调用，即多次的bindService，onBind()只在第一次绑定的时候调用。

当startService单独使用时，即使对应的startService时传入的Context被销毁，Service也还是会处于运行状态。
无论多少个Activity绑定了Service，但是onBind()只会执行一次，也就是Service首次被绑定时会执行，onUnbind()也是如此，即最后一个Context失效后，才会执行onUnbind()（Activity主动调用unbindService或者被onDestory）。
而如果由于Activity没有主动调用unbindService与Serivice解绑，这样会造成内存泄漏.
如果是多个Activity都绑定了同一个Service绑定，且没有执行过startService，当其中一个Activity onDestory或者进行unbindService之后，其与Service进行bindService时的Context就会失效，而当最后与Service绑定的Contxet失效后，Service才会执行onUnbind()，之后会自动调用onDestory()进行销毁。
如果是同时有多个Activity对Service进行了startService和bindService，如果没有显示调用过stopService，则当所有与Service绑定的Context失效后，Service不会被销毁，会一直在后台运行，因为有主动调用了startService，此时必须主动调用stopService或者在Service中调用stopSelf才能将其销毁；而如果在一个或者多个Context失效前主动调用了stopService或者在Service中调用stopSelf，则需要等到最后一个Context主动与Service进行unbindService或者失效后，才会能使Service执行onDestory。

默认情况下，服务是运行在主线程的，但这不符合我们使用服务的初衷（除非想提高服务优先级不被杀掉）所以一般要在服务运行耗时操作需要在服务中开启子线程。

本地服务和远程服务

本地服务
本地服务依附在主进程上而不是独立的进程，这样在一定程度上节约了资源，另外本地服务因为是在同一进程因此不需要IPC，也不需要AIDL。相应bindService会方便很多，当主进程被Kill后，服务便会终止。一般使用在音乐播放器播放等不需要常驻的服务。指的是服务和启动服务的activity在同一个进程中。
远程服务
远程服务是独立的进程，对应进程名格式为所在包名加上你指定的android:process字符串。一般定义方式 android:process=":remote" 由于是独立的进程，因此在Activity所在进程被Kill的时候，该服务依然在运行，不受其他进程影响，有利于为多个进程提供服务具有较高的灵活性。由于是独立的进程，会占用一定资源，并且使用AIDL进行IPC比较麻烦。一般用于系统的Service，这种Service是常驻的。指的是服务和启动服务的activity不在同一个进程中。
注意：启动本地服务用的是显式启动；远程服务的启动要用到隐式启动

IntentService

IntentService是Android中提供的后台服务类，继承于Service，我们在外部组件中通过Intent向IntentService发送请求命令，之后IntentService逐个执行命令队列里的命令，接收到首个命令时，IntentService就开始启动并开始一条后台线程执行首个命令，接着队列里的命令将会被顺序执行，最后执行完队列的所有命令后，服务也随即停止并被销毁。

与Service的区别

Service中的程序仍然运行于主线程中，而在IntentService中的程序运行在我们的异步后台线程中。
在Service中当我的后台服务执行完毕之后需要在外部组件中调用stopService方法销毁服务，而IntentService并不需要，它会在工作执行完毕后自动销毁。

如何让服务不被杀死

non-sticky服务和sticky服务：
non-sticky服务会在自己认为任务完成时停止，若一个Service为non-sticky服务则应该在onStartCommand方法中返回START_REDELIVER_INTENT或START_NOT_STICKY标志。sticky服务会持续存在，直到外部组件调用Context.stopService方法。sticky服务返回标志位START_STICKY。默认是non-sticky服务。

为了式服务不被杀死，可以使用sticky，在onStartCommand中直接返回START_STICKY

@Override
    public int onStartCommand(Intent intent, int flags, int startId) {
//        return super.onStartCommand(intent, flags, startId);
        return START_STICKY;
    }

当Service因内存不足而被系统kill后，一段时间后内存再次空闲时，系统将会尝试重新创建此Service，一旦创建成功后将回调onStartCommand方法，但其中的Intent将是null，除非有挂起的Intent，如pendingintent，这个状态下比较适用于不执行命令、但无限期运行并等待作业的媒体播放器或类似服务。

提高Service优先级

在onDestroy方法里重启Service
当service走到onDestroy()时，发送一个自定义广播，当收到广播时，重新启动service；
提升Service进程的优先级
进程优先级由高到低：前台进程一可视进程一服务进程一后台进程一空进程
可以使用startForeground将service放到前台状态，这样低内存时，被杀死的概率会低一些；
系统广播监听Service状态
将APK安装到/system/app，变身为系统级应用

以上机制都不能百分百保证Service不被杀死，除非做到系统白名单，与系统同生共死。

Service启动过程

==启动流程==：

Process A进程采用Binder IPC向system_server进程发起startService请求；
system_server进程接收到请求后，向zygote进程发送创建进程的请求；
zygote进程fork出新的子进程Remote Service进程；
Remote Service进程，通过Binder IPC向sytem_server进程发起attachApplication请求；
system_server进程在收到请求后，进行一系列准备工作后，再通过binder IPC向remote Service进程发送scheduleCreateService请求；
Remote Service进程的binder线程在收到请求后，通过handler向主线程发送CREATE_SERVICE消息；
主线程在收到Message后，通过发射机制创建目标Service，并回调Service.onCreate()方法。

到此，服务便正式启动完成。==当创建的是本地服务或者服务所属进程已创建时，则无需经过上述步骤2、3，直接创建服务即可==。

image.png

在整个startService过程，从进程角度看服务启动过程，涉及4个进程：

Process A进程：是指调用startService命令所在的进程，也就是启动服务的发起端进程，比如点击桌面App图标，此处Process A便是Launcher所在进程。
system_server进程：系统进程，是java framework框架的核心载体，里面运行了大量的系统服务，比如这里提供ApplicationThreadProxy（简称ATP），ActivityManagerService（简称AMS），这个两个服务都运行在system_server进程的不同线程中，由于ATP和AMS都是基于IBinder接口，都是binder线程，binder线程的创建与销毁都是由binder驱动来决定的，每个进程binder线程个数的上限为16。
Zygote进程：是由init进程孵化而来的，用于创建Java层进程的母体，所有的Java层进程都是由Zygote进程孵化而来；
Remote Service进程：远程服务所在进程，是由Zygote进程孵化而来的用于运行Remote服务的进程。主线程主要负责Activity/Service等组件的生命周期以及UI相关操作都运行在这个线程；另外，每个App进程中至少会有两个binder线程 ApplicationThread(简称AT)和ActivityManagerProxy（简称AMP），当然还有其他线程，这里不是重点就不提了。

参考链接：
https://blog.csdn.net/qq_22804827/article/details/78609636

https://blog.csdn.net/weixin_39460667/article/details/82770164

https://www.cnblogs.com/it-tsz/p/11601265.html