android service 详解

参考自CSDN博客：http://blog.csdn.net/wtao158/archive/2010/01/08/5149721.aspx

 个人认为百度文库中的这篇文章写的很好。

http://wenku.baidu.com/link?url=JKWXhFAVT04uhArwQeuGZ2QieG3_sMqg5RpDwC6IFWOmb8NZKvXw3ATIXs7Grh4-ieyMYOiM98VCHXvpOzxbONgtQ8KCNq86YN8lVQQxbZ3

有了 Service 类我们如何启动他呢，有两种方法：

      • Context.startService() 
      • Context.bindService()

     1.  在同一个应用任何地方调用 startService() 方法就能启动 Service 了，然后系统会回调 Service 类的 onCreate() 以及 onStart() 方法。这样启动的 Service 会一直运行在后台，直到 Context.stopService() 或者 selfStop() 方法被调用。另外如果一个 Service 已经被启动，其他代码再试图调用 startService() 方法，是不会执行 onCreate() 的，但会重新执行一次 onStart() 。

      2. 另外一种 bindService() 方法的意思是，把这个 Service 和调用 Service 的客户类绑起来，如果调用这个客户类被销毁，Service 也会被销毁。用这个方法的一个好处是，bindService() 方法执行后 Service 会回调上边提到的 onBind() 方发，你可以从这里返回一个实现了 IBind 接口的类，在客户端操作这个类就能和这个服务通信了，比如得到 Service 运行的状态或其他操作。如果 Service 还没有运行，使用这个方法启动 Service 就会 onCreate() 方法而不会调用 onStart()。

     

      总结：

      1. startService()的目的是回调onStart()方法，onCreate() 方法是在Service不存在的时候调用的，如果Service存在（例如之前调用了bindService，那么Service的onCreate方法已经调用了）那么startService()将跳过onCreate() 方法。

      2.  bindService()目的是回调onBind()方法，它的作用是在Service和调用者之间建立一个桥梁，并不负责更多的工作（例如一个Service需要连接服务器的操作），一般使用bindService来绑定到一个现有的Service（即通过StartService启动的服务）。

      由于Service 的onStart()方法只有在startService()启动Service的情况下才调用，故使用onStart()的时候要注意这点。

 

总结2：

Service（服务）是一个没有用户界面的在后台运行执行耗时操作的应用组件。其他应用组件能够启动Service，并且当用户切换到另外的应用场景，Service将持续在后台运行。另外，一个组件能够绑定到一个service与之交互（IPC机制），例如，一个service可能会处理网络操作，播放音乐，操作文件I/O或者与内容提供者（content provider）交互，所有这些活动都是在后台进行。

Service有两种状态，“启动的”和“绑定”

通过startService()启动的服务处于“启动的”状态，一旦启动，service就在后台运行，即使启动它的应用组件已经被销毁了。通常started状态的service执行单任务并且不反悔任何结果给启动者。比如当下载或上传一个文件，当这项操作完成时，service应该停止它本身。

还有一种“绑定”状态的service，通过调用bindService()来启动，一个绑定的service提供一个允许组件与service交互的接口，可以发送请求、获取返回结果，还可以通过夸进程通信来交互（IPC）。绑定的service只有当应用组件绑定后才能运行，多个组件可以绑定一个service，当调用unbind()方法时，这个service就会被销毁了。

与 Service 通信并且让它持续运行

      如果我们想保持和 Service 的通信，又不想让 Service 随着 Activity 退出而退出呢？你可以先 startService() 然后再 bindService() 。当你不需要绑定的时候就执行 unbindService() 方法，执行这个方法只会触发 Service 的 onUnbind() 而不会把这个 Service 销毁。这样就可以既保持和 Service 的通信，也不会随着 Activity 销毁而销毁了。

 

提高 Service 优先级

      Android 系统对于内存管理有自己的一套方法，为了保障系统有序稳定的运信，系统内部会自动分配，控制程序的内存使用。当系统觉得当前的资源非常有限的时候，为了保 证一些优先级高的程序能运行，就会杀掉一些他认为不重要的程序或者服务来释放内存。这样就能保证真正对用户有用的程序仍然再运行。如果你的 Service 碰上了这种情况，多半会先被杀掉。但如果你增加 Service 的优先级就能让他多留一会，我们可以用 setForeground(true) 来设置 Service 的优先级。

      为什么是 foreground ? 默认启动的 Service 是被标记为 background，当前运行的 Activity 一般被标记为 foreground，也就是说你给 Service 设置了 foreground 那么他就和正在运行的 Activity 类似优先级得到了一定的提高。当让这并不能保证你得 Service 永远不被杀掉，只是提高了他的优先级。

 

摘自网络其他资料：关于Service生命周

Android Service生命周期与Activity生命周期是相似的，但是也存在一些细节上也存在着重要的不同：

onCreate和onStart是不同的

通过从客户端调用Context.startService(Intent)方法我们可以启动一个服务。如果这个服务还没有运行，Android将启动它并且在onCreate方法之后调用它的onStart方法。如果这个服务已经在运行，那么它的onStart方法将被新的Intent再次调用。所以对于单个运行的Service它的onStart方法被反复调用是完全可能的并且是很正常的。

onResume、onPause以及onStop是不需要的

回调一个服务通常是没有用户界面的，所以我们也就不需要onPause、onResume或者onStop方法了。无论何时一个运行中的Service它总是在后台运行。

onBind

如果一个客户端需要持久的连接到一个服务，那么他可以调用Context.bindService方法。如果这个服务没有运行方法将通过调用onCreate方法去创建这个服务但并不调用onStart方法来启动它。相反，onBind方法将被客户端的Intent调用，并且它返回一个IBind对象以便客户端稍后可以调用这个服务。同一服务被客户端同时启动和绑定是很正常的。

onDestroy

与Activity一样，当一个服务被结束是onDestroy方法将会被调用。当没有客户端启动或绑定到一个服务时Android将终结这个服务。与很多Activity时的情况一样，当内存很低的时候Android也可能会终结一个服务。如果这种情况发生，Android也可能在内存够用的时候尝试启动被终止的服务，所以你的服务必须为重启持久保存信息，并且最好在onStart方法内来做。

网摘总结1：

把Service等同于thread或process是一个非常常见的误解。需要强调又强调的第一点是，Android的Service是一个Context，并不必然等于一个额外的thread。如果你有仔细看文档(Service | Android Developers)，里面专门强调

• A Service is not a separate process. The Service object itself does not imply it is running in its own process; unless otherwise specified, it runs in the same process as the application it is part of.

• A Service is not a thread. It is not a means itself to do work off of the main thread (to avoid Application Not Responding errors).

那Service是什么？"A Service is an application component representing either an application's desire to perform a longer-running operation while not interacting with the user or to supply functionality for other applications to use." Service只是从逻辑上表示一个用来执行"longer-running"的"后台"任务或功能的"application component"。

为什么强调说"longer running"的"component"? 非常明显，这里是和Activity这种活跃周期相对短暂的component对比而言。一旦用户切换到其他应用，当前Activity就必须pause, stop甚至被destroy，不能在后台处理其他事务。需要强调的事，严格来说你仍然可以在activity里创建自己的worker thread或async task之类做后台的事情，但这样做没有任何保障——因为一旦你所有的activity都被切换到了后台，系统随时可能kill掉你的process，你的后台任务随时可能悄无声息的死掉。

Activity为什么这样设计？Windows下面的窗口在最小化的时候不是一样可以处理消息或者继续运行吗？这是另外一个话题，不过回答也很简单：这是移动设备，内存/电池都有限。

对你的应用而言，通过在manifest里声明Service，把需要后台相对长期运行的逻辑放在Service里，你便获得了这样的保障：只要系统内存不是极端不够用，你的Service一定不会被kill掉。对系统而言，当看到一个进程里有Service在运行，这个进程就具有较高的优先级，会在内存不足被杀的行列里排得比较靠后。

可是前面不是强调了Service并不等于process或thread吗？为什么上面又在说杀进程什么的？这里再次强调，你可以把Service看成一砣代码，用来在后台做些事情，仅此而已。至于这砣代码在哪里运行，完全是取决于你自己的喜好。你的local service，如果不建立worker thread，仍然是在你的应用进程的主线程即UI线程里运行。如果你不想阻塞UI线程，你就建一个worker thread。但这些细节，Android framework并不怎么care，它只知道你声明了一个service，然后在你的manifest里面找到这个service是声明在哪个process里运行，那么这个process就不容易被kill。

什么时候选择local service（即不指定额外的进程），什么时候选择remote service（额外的进程）？通常我们会把真的需要长期运行的service（例如IM之类）放在单独的进程里，这样UI所在的进程在必要的时候仍然可以被系统kill掉来腾出内存。而local service通常用来处理一些需要短期运行但仍然超出activity活动周期的任务，打个比方，发送短信或彩信。这样的任务执行完以后，service就可以stop自己，仍然不妨碍整个UI进程被回收掉。

原文出处：http://blog.csdn.net/elena_wang/article/details/14127887