Android Service启动方式

1 启动方式

Service 的启动方式主要有两种，分别是 startService 和 bindService

其中， StartService 使用的是同一个 Service, onCreate() 只执行一次，

onStartCommand() 也会执行多次。使用 bindService 启动时， onCreate() 与 onBind() 都只会调用一次。

使用 startService 启动时是单独开一个服务，与 Activity 没有任何关系，而 bindService 方式启动时，

Service 会和 Activity 进行绑定，当对应的 activity 销毁时，对应的 Service 也会销毁。

2 生命周期

2.1 startService

onCreate() ：如果 service 没被创建过，调用 startService() 后会执行 onCreate() 回调；如果 service

已处于运行中，调用 startService() 不会执行 onCreate() 方法。

onStartCommand() ：多次执行了 Context 的 startService() 方法，那么 Service 的

onStartCommand() 方法也会相应的多次调用。

onBind( ) ： Service 中的 onBind() 方法是抽象方法， Service 类本身就是抽象类，所以 onBind() 方法

是必须重写的，即使我们用不到。

onDestory() ：在销毁 Service 的时候该方法。

3 Service 不被杀死

 

3.1 ， onStartCommand 方式中，返回 START_STICKY 。

调用 Context.startService 方式启动 Service 时，如果 Android 面临内存匮乏，可能会销毁当前运行的

Service ，待内存充足时可以重建 Service 。而 Service 被 Android 系统强制销毁并再次重建的行为依赖于

Service 的 onStartCommand() 方法的返回值，常见的返回值有如下一些。

START_NOT_STICKY ：如果返回 START_NOT_STICKY ，表示当 Service 运行的进程被 Android 系统强制   杀掉之后，不会重新创建该Service 。

START_STICKY ：如果返回 START_STICKY ，表示 Service 运行的进程被 Android 系统强制杀掉之后，

Android 系统会将该 Service 依然设置为 started 状态（即运行状态），但是不再保存 onStartCommand

方法传入的 intent 对象，即获取不到 intent 的相关信息。

START_REDELIVER_INTENT ：如果返回 START_REDELIVER_INTENT ，表示 Service 运行的进程被

Android 系统强制杀掉之后，与返回 START_STICKY 的情况类似， Android 系统会将再次重新创建该

Service ，并执行 onStartCommand 回调方法，但是不同的是， Android 系统会再次将 Service 在被杀掉

之前最后一次传入 onStartCommand 方法中的 Intent 再次保留下来并再次传入到重新创建后的 Service

的 onStartCommand 方法中，这样我们就能读取到 intent 参数。

3.Service使用场景

 Service的优点是系统原生支持，使用方便；创建进程方便；可以提供给系统内其他App使用；优先级高，当App退到后台后不宜被杀死。缺点是由于启动Service涉及到多次IPC，运行效率不高，而且受限于系统接口，使用不够灵活。
线程池的优点是运行效率高，配置和使用灵活。缺点是多进程实现不方便， 由于Android实现了一套进程托管机制，我们不能直接创建一个新的进程，而只能通过四大组件的形式创建新的进程。

 一般普通的异步任务，比如网络请求，数据库或者文件相关操作，我们都会使用线程池的方式来做，因为这样使用的系统开销小，运行效率高，而且随着业务逻辑的复杂度增加，扩展性也更强。然而，对于一些特殊场景，比如进程保活，使用第三方SDK服务比如地图，IM等，就需要使用Service来实现，因为这些服务一般与App主进程隔离开，需要运行在新进程中以防止App主进程发生异常崩溃时，牵连第三方服务也挂掉。