android基础学习之service的启动和关闭细解

什么是Service？

         解惑：

                1、  Service不是分离开的进程，除非其他特殊情况，它不会运行在自己的进程，而是作为启动运行它的进程的一部分。

                2、  Service不是线程，这意味着它将在主线程里劳作。

        启动service有两种方法：

             1、  Context.startService()

                    调用者与服务之间没有关联，即使调用者退出，服务仍可运行

             2、  Context.bindService()

                    调用者与服务绑定在一起，调用者一旦退出，服务也就终止

Service的生命周期

         如果使用startService()启动service，系统将通过传入的Intent在底层搜索相关符合Intent里面信息的service。如果服务没有启动则先运行onCreate，然后运行onStartCommand （可在里面处理启动时传过来的Intent和其他参数），直到明显调用stopService或者stopSelf才将停止Service。无论运行startService多少次，只要调用一次stopService或者stopSelf，Service都会停止。使用stopSelf(int)方法可以保证在处理好intent后再停止。

         控制service运行的主要方式有两种，主要是根据onStartCommand方法返回的数值。方法：

         1、START_STICKY

         2、START_NOT_STICKY or START_REDELIVER_INTENT

         这里主要解释这三个变量的意义：

          1、  START_STICKY

                 在运行onStartCommand后service进程被kill后，那将保留在开始状态，但是不保留那些传入的intent。不久后service就会再次尝试重新创建，因为保留在开始状态，在创建     service后将保证调用onstartCommand。如果没有传递任何开始命令给service，那将获取到null的intent

          2、  START_NOT_STICKY

                 在运行onStartCommand后service进程被kill后，并且没有新的intent传递给它。Service将移出开始状态，并且直到新的明显的方法（startService）调用才重新创建。因为如果没有传递任何未决定的intent那么service是不会启动，也就是期间onstartCommand不会接收到任何null的intent。

           3、  START_REDELIVER_INTENT

                在运行onStartCommand后service进程被kill后，系统将会再次启动service，并传入最后一个intent给onstartCommand。直到调用stopSelf(int)才停止传递intent。如果在被kill后还有未处理好的intent，那被kill后服务还是会自动启动。因此onstartCommand不会接收到任何null的intent。

          客户端也可以使用bindService来保持跟service持久关联。谨记：如果使用这种方法，那么将不会调用onstartCommand（跟startService不一样，下面例子注释也有解析，大家可试试）。客户端将会在onBind回调中接收到IBinder接口返回的对象。通常IBinder作为一个复杂的接口通常是返回aidl数据。

         Service也可以混合start和bind一起使用。

权限

         要运行service，首先必须在AndroidManifest.xml里申明<service>标签。

         Service能够保护个人的IPC调用，所以在执行实现该调用时前先使用checkCallingPermission(String) 方法检查是否有这个权限。

 

进程生命周期

         当service运行在低内存的环境时，将会kill掉一下存在的进程。因此进程的优先级将会很重要：

         1、  如果service当前正在执行onCreate、onStartCommand、onDestroy方法，主进程将会成为前台进程来保证代码可以执行完成避免被kill

         2、  如果service已经启动了，那么主进程将会比其他可见的进程的重要性低，但比其他看不见的进程高。因为只有少部分进程始终是用户可见的，因此除非在极度低内存的时候，不然 service是不会被kill的。

         3、  如果有客户端关联到service，那么service永远比客户端重要。也就是说客户端可见，那么service也可见（我理解这里的可见并不是可以看到，而是重要性，因为可见往往就表示重要性高）。

         4、  Service可以使用startForeground API将service放到前台状态。这样在低内存时被kill的几率更低，但是文档后面又写了，如果在极度极度低内存的压力下，该service理论上还是会被kill掉。但这个情况基本不用考虑。

         当然如果service怎么保持还是被kill了，那你可以通过重写onStartCommand返回变量来设置它的启动方式。比如：START_STICKY、START_REDELIVER_INTENT等等，前面已经讨论了它们的作用，这里就不再累赘了

        另外：

        service 的onCreate和onStartCommand 是运行在主线程的，所以如果里面有处理耗时间的任务。两种处理：

1、  请将它们都挪到新的线程里。 

2、  用系统提供的IntentService，它继承了Service，它处理数据是用自身新开的线程。

原文地址：http://blog.csdn.net/centralperk/article/details/7764379