Service 解析

1.Service生命周期

service启动方式有两种，分别startService和bindService ，下面分别讲讲生命周期

(1) 当我们首次用startService方式启动service时，系统会创建一个service实例对象，并依次调用onCreate,onStartCommand 方法，然后进入运行状态，如果再使用startService启动服务时，不再创建新的服务对象，系统会自动找到刚才创建的Service实例，调用其onStart方法，如果我们想停止一个service，就需调用stopService方法，然后会执行onDestory ，此service将被关闭。值得注意的是，不管调用了多少次startService 只需调用一次stopService 即可关闭当前service。

(2) 当我们首次用bindService方法绑定service时，系统会创建一个service对象，并依次调用onCreate，onBind方法，然后调用者就可以与服务就行交互了，当再次使用bindService 时，系统不会再创建service实例，系统会自动找到刚才创建的实例，调用其onBind方法，如果想解绑service，就需要调用unBindService ，此时onUnBind 和 onDestory方法就会执行，此后服务就将解绑关闭。

两个模式对比：严格来讲，starService 启动的服务，与调用者无必然联系，即使调用者结束了自己的生命周期，只要没调用StopService，改服务就不会关闭。通常情况下，bindService模式下的服务与调用者是生死与共的，绑定结束后，只要调用者一销毁，服务就立马终止，即使没有调用unBindService。这就是：不求同生，但求同死。

提一下：在android2.0之前StartService启动service时都是重写onStart方法，android2.0时，改为了onStartCommand，为了兼容之前的程序，onStartCommand 里面其实还是调用了onStart方法，但我们最好是重写onStartCommand。

2. 进程生命周期

只要service被启动或客户端已绑定service，Android系统就会尝试维护托管服务进程。当运行在低内存并且需要杀死已存在的进程，如果是下面的情况托管服务进程的优先级就越高：

• 如果service执行的代码在它的 onCreate(), onStartCommand(), 或 onDestroy()方法中，那么托管进程将是一个前台进程确保这些代码可以执行不会被杀死。

• 如果服务已经被启动，然后托管进程被认为比用户当前可见的任何进程的重要性要低，但要比其它不可见的进程重要性要高。 因此通常只有少数进程是用户可见的，这意味着service不应该被杀死除了低内存的情况下。然而，由于用户不能直接意识到后台service，在这种状态下它就被认为是一个有效的被杀死的候选，并且你应该为这做好准备。特别地，长时间运行的service被杀死的可能性越大并且如果它们保留的时间足够长可以放心地被杀死（并且如果合适的话重启）。

• 如果是客户端绑定到service，然后service托管进程没有客户端更重要。那是如果它的客户端中的一个对用户是可见的，那么service本身被认为是可见的。客户端重要性影响service的重要性的方式可以通过BIND_ABOVE_CLIENT, BIND_ALLOW_OOM_MANAGEMENT, BIND_WAIVE_PRIORITY, BIND_IMPORTANT, 和 BIND_ADJUST_WITH_ACTIVITY被调节。

• 一个开启的service可以使用startForeground(int, Notification)把service置为前台的状态，系统认为它对用户是积极的并且当低内存时不会是被杀死的候选。（从理论上来讲，在内存极端压力下service还是有可能会被杀死从前台应用程序，但在实践中这不应该值得关注。）

注意这意味着大多数时间你的service在运行，如果它在严重内存压力下有可能被系统杀死。如果发生这种情况，系统将在稍后尝试重启service。这是一个重要的结果，如果你实现了onStartCommand()去计划异步完成任务或在其它线程，然后你可能想要使用START_FLAG_REDELIVERY去接收系统重新分发的Intent，因此如果你的service在处理过程中被杀死Intent不会被丢失。

其它应用组件（例如Activity）和service运行在同一个进程，当然了，除了service本身的重要性还要增加整体进程的重要性。

(3) IntentService

 先看看Service存在的问题

1.Service不会专门启动一个单独的进程，service与他所在的应用位于同一个进程中

2.Service不是一条新的线程，因此不应该在Service中直接处理耗时的任务。

如果开发者需要在Service中处理耗时任务，建议在Service中另开一条线程。有没有什么简单的过程来处理这一问题？那就是IntentService。

IntentService是继承service类并处理异步请求的一个类，IntentService将会使用队列来管理请求Intent，每当客户端通过Intent请求启动IntentService时，IntentService将会将该Intent加入队列，然后开启一个新的worker线程来处理Intent。（同一时刻值处理一个Intent），另外IntentService的启动方式和Service是一样的。

主要特征：

1.IntentService会创建单独的worker线程来处理所有的Intent请求。

2.IntentService会创建单独的worker线程来处理onHandleIntent方法实现的代码，隐藏开发者无需处理多线程问题。

3.当所有 请求处理完成后，IntentService会自动停止，无线调用stopSelf()方法停止service

4.为Service的onBInd方法提供了默认实现，默认返回null。为Service的onStartCommand()方法提供了默认实现，该实现会将请求Intent添加到队列中。

因此，扩展IntentService实现Service无须重写onBind(),onStartCommand 方法，只要重写onHandleIntent方法即可。