关键类：Service ， IntentService
范例：ServiceStartArguments ，LocalService
相关文章：Multitasking the Android Way Service API changes starting with Android 2.0
参阅：bound服务
Service 是一个应用程序组件，它能够在后台执行一些耗时较长的操作，并且不提供用户界面。 服务能被其它应用程序的组件启动，即使用户切换到另外的应用时还能保持后台运行。 此外，应用程序组件还能与服务绑定，并与服务进行交互，甚至能进行进程间通信（IPC）。 比如，服务可以处理网络传输、音乐播放、执行文件I/O、或者与content provider进行交互，所有这些都是后台进行的。
服务有以下两种基本类型：
虽然本文对这两种类型的服务是分别进行简要描述的，但是你的服务仍可以同时用两种方式工作——可以是started（一直运行下去），同时也能被绑定。 只会存在一点麻烦，是否两个回调方法都要实现：实现 onStartCommand() 以允许组件启动服务、实现 onBind() 以允许绑定。
无论你的应用程序是started、bound、还是两者都支持，任何应用程序组件都可以使用此服务（即使是从另一个独立的应用程序中）， 同样，任何组件都可以用这种方式使用一个activity——通过一个 Intent 启动。不过，也可以在manifest文件中把服务声明为私有private的，以便阻止其它应用程序的访问。 这将在在manifest中声明服务文中详细论述。
警告： 服务运行于宿主进程的主线程中——不创建自己的线程并且不是运行在单独的进程中（除非你明确指定）。 这意味着，如果你的服务要执行一些很耗CPU的工作或者阻塞的操作（比如播放MP3或网络操作），你应该在服务中创建一个新的线程来执行这些工作。 利用单独的线程，将减少你的activity发生应用程序停止响应（ANR）错误的风险。
使用服务还是使用线程？
服务仅仅是一个组件，即使用户不再与你的应用程序发生交互，它仍然能在后台运行。因此，应该只在需要时才创建一个服务。
如果你需要在主线程之外执行一些工作，但仅当用户与你的应用程序交互时才会用到，那你应该创建一个新的线程而不是创建服务。 比如，如果你需要播放一些音乐，但只是当你的activity在运行时才需要播放，你可以在 onCreate() 中创建一个线程，在 onStart() 中开始运行，然后在 onStop() 中终止运行。还可以考虑使用 AsyncTask 或 HandlerThread来取代传统的 Threadd 类。关于线程的详细信息，请参阅 进程和线程。
请记住，如果你使用了服务，它默认就运行于应用程序的主线程中。因此，如果服务执行密集计算或者阻塞操作，你仍然应该在服务中创建一个新的线程来完成。
为了创建一个服务，你必须新建一个 Service 的子类（或一个已有Service的子类）。在你的实现代码中，请按需重写一些回调方法，用于对服务生命周期中的关键节点进行处理，以及向组件提供绑定机制。 最重要的需要重写的回调方法包括：
如果组件通过调用 startService() （这会导致 onStartCommand() 的调用）启动了服务，那么服务将一直保持运行，直至自行用 stopSelf() 终止或由其它组件调用 stopService() 来终止它。
如果组件调用 bindService() 来创建服务（那 onStartCommand() 就不会被调用），则服务的生存期就与被绑定的组件一致。一旦所有客户端都对服务解除了绑定，系统就会销毁该服务。
仅当内存少得可怜、且必须覆盖拥有用户焦点的activity的系统资源时，Android系统才会强行终止一个服务。 如果服务被拥有用户焦点的activity绑定着，则它一般不会被杀死。 如果服务声明为前台运行（下文讨论），则它几乎永远不会被杀死。 否则，如果服务已被启动并且已运行了很长时间，那么系统将会随时间推移而降低它在后台任务列表中的级别， 此类服务将很有可能会被杀死——如果服务已经启动，那你必须好好设计代码，使其能完美地 应付被系统重启的情况。 如果系统杀死了你的服务，只要资源再度够用，系统就会再次启动服务（当然这还取决于 onStartCommand() 的返回值，下文将会述及）。关于系统可能会在何时销毁服务的详细信息，请参阅 进程和线程 。
在下节中，你将看到如何创建每种类型的服务，以及如何在应用程序组件中使用它们。
与activity（及其它组件）类似，你必须在应用程序的manifest文件中对所有的服务进行声明。
要声明你的服务，把 <service> 元素作为子元素加入到 <application> 元素中去即可。例如：
<manifest ... > ... <application ... > <service android:name=".ExampleService" /> ... </application></manifest>
在 <service> 元素中可以包含很多其它属性，比如定义启动服务所需权限、服务运行的进程之类的属性。 android:name 是唯一必需的属性——它定义了服务的类名。应用程序一经发布，就不得再修改这个类名。因为这么做可能会破坏某些显式引用该服务的intent功能（参阅博客文章 Things That Cannot Change ）。
关于在manifest中声明服务的详情，请参阅 <service> 元素参考文档。
与activity一样，服务可以定义intent过滤器，使得其它组件能用隐式intent来调用服务。 通过声明intent过滤器，任何安装在用户设备上的应用程序组件都有能力来启动你的服务，只要你的服务所声明的intent过滤器与其它应用程序传递给 startService() 的intent相匹配即可。
如果你想让服务只能内部使用（其它应用程序无法调用），那么就不必（也不应该）提供任何intent过滤器。 如果不存在任何intent过滤器，那你就必须用精确指定服务类名的intent来启动服务。 关于 启动一个服务 的详细内容，将在下文讨论。
此外，如果包含了 android:exported 属性并且设置为”false”， 就可以确保该服务是你应用程序的私有服务。即使服务提供了intent过滤器，本属性依然生效。
关于为服务创建intent过滤器的详细信息，请参阅 Intent和Intent过滤器 文档。
针对Android 1.6及以下版本
如果你正在为Android 1.6及以下版本开发应用，那么需要实现 onStart() 方法，而不是 onStartCommand() （在Android 2.0中， onStart() 是过期的方法，而用 onStartCommand() 取而代之）。
关于Android 2.0以前版本的兼容性信息，请参阅 onStartCommand() 文档。
started服务是指其它组件通过调用 startService() 来启动的服务，这会引发对该服务 onStartCommand() 方法的调用。
一旦服务被启动started，它就拥有了自己的生命周期，这是独立于启动它的组件的。并且它能够在后台一直运行下去，即使启动它的组件已被销毁 也是如此。 因此，服务应该能够在完成工作后自行终止，通过调用 stopSelf() 即可，或者由其它组件通过调用 stopService() 也可以。
诸如activity之类的应用程序组件，可以通过调用 startService() 启动服务,并传入一个给出了服务和服务所需数据的 Intent 对象。服务将在 onStartCommand() 方法中接收到该 Intent 对象。
举个例子，假定某activity需要把一些数据保存到在线数据库中。此activity可以启动一个守护服务并通过传入 startService() 一个intent把需要保存的数据发送给该服务。该服务在 onStartCommand() 内接收intent，连接Internet，再进行数据库事务处理。当事务完成后，服务自行终止，并被系统销毁。
警告： 默认情况下，运行服务的进程与应用程序的相同，并且运行在应用程序的主线程中。 因此，如果你的服务要执行计算密集或阻塞的操作，而同时用户又需要与同一个应用程序中的activity进行交互，那么服务将会降低activity的性能。 为了避免对应用程序性能的影响，你应该在服务中启动一个新的线程。
传统做法，你可以扩展两个类来创建started服务：
下一节描述了如何用这两个类来实现服务。
因为大多数started服务都不需要同时处理多个请求（这实际上是一个危险的多线程情况），所以最佳方式也许就是用 IntentService 类来实现你的服务。
IntentService 将执行以下步骤：
以上所有步骤将汇成一个结果：你要做的全部工作就是实现 onHandleIntent() 的代码，来完成客户端提交的任务。（当然你还需要为服务提供一小段构造方法。）
以下是个 IntentService 的实现例程：
public class HelloIntentService extends IntentService { /** * A constructor is required, and must call the super IntentService(String) * constructor with a name for the worker thread. */ public HelloIntentService() { super("HelloIntentService"); } /** * The IntentService calls this method from the default worker thread with * the intent that started the service. When this method returns, IntentService * stops the service, as appropriate. */ @Override protected void onHandleIntent(Intent intent) { // Normally we would do some work here, like download a file. // For our sample, we just sleep for 5 seconds. long endTime = System.currentTimeMillis() + 5*1000; while (System.currentTimeMillis() < endTime) { synchronized (this) { try { wait(endTime - System.currentTimeMillis()); } catch (Exception e) { } } } }}
所有你需要做的就是：一个构造方法和一个 onHandleIntent() 方法的实现。
如果你还决定重写其它的回调方法，比如 onCreate()、 onStartCommand()、 onDestroy()， 请确保调用一下父类的实现代码，以便 IntentService 能正确处理工作线程的生命周期。
比如说， onStartCommand() 必须返回缺省实现代码的结果（缺省代码实现了如何获取传给 onHandleIntent() 的intent）：
@Overridepublic int onStartCommand(Intent intent, int flags, int startId) { Toast.makeText(this, "service starting", Toast.LENGTH_SHORT).show(); return super.onStartCommand(intent,flags,startId);}
除了 onHandleIntent() 以外，唯一不需要调用父类实现代码的方法是 onBind() （不过如果你的服务允许绑定，你还是需要实现它）。
在下一节中，你将看到如何扩展 Service 基类来实现同一服务，代码量会多一些，但可能适合处理多个同时发起的请求。
如上节所述，利用 IntentService 来实现一个started服务非常简单。 不过，假如你的服务需要多线程运行（而不是通过一个工作队列来处理启动请求），那你可以扩展 Service 类来完成每个intent的处理。
作为对照，以下例程实现了 Service 类，它执行的工作与上述使用 IntentService 的例子相同。确切地说，对于每一个启动请求，它都用一个工作线程来完成处理工作，并且每次只处理一个请求。
public class HelloService extends Service { private Looper mServiceLooper; private ServiceHandler mServiceHandler; // 处理从线程接收的消息 private final class ServiceHandler extends Handler { public ServiceHandler(Looperlooper) { super(looper); } @Override public voidhandleMessage(Message msg) { // 通常我们在这里执行一些工作，比如下载文件。 // 作为例子，我们只是睡个5秒钟。 long endTime = System.currentTimeMillis() + 5*1000; while (System.currentTimeMillis() <endTime) { synchronized (this) { try { wait(endTime - System.currentTimeMillis()); } catch (Exception e) { } } } // 根据startId终止服务，这样我们就不会在处理其它工作的过程中再来终止服务 stopSelf(msg.arg1); } } @Override public void onCreate() { // 启动运行服务的线程。 // 请记住我们要创建一个单独的线程，因为服务通常运行于进程的主线程中，可我们不想阻塞主线程。 // 我们还要赋予它后台运行的优先级，以便计算密集的工作不会干扰我们的UI。 HandlerThread thread = new HandlerThread("ServiceStartArguments", Process.THREAD_PRIORITY_BACKGROUND); thread.start(); // 获得HandlerThread的Looper队列并用于Handler mServiceLooper = thread.getLooper(); mServiceHandler = new ServiceHandler(mServiceLooper); } @Override public int onStartCommand(Intent intent, intflags, int startId) { Toast.makeText(this, "service starting", Toast.LENGTH_SHORT).show(); // 对于每一个启动请求，都发送一个消息来启动一个处理 // 同时传入启动ID，以便任务完成后我们知道该终止哪一个请求。 Message msg = mServiceHandler.obtainMessage(); msg.arg1 = startId; mServiceHandler.sendMessage(msg); // 如果我们被杀死了，那从这里返回之后被重启 return START_STICKY; } @Override public IBinderonBind(Intent intent) { // 我们不支持绑定，所以返回null return null; } @Override public void onDestroy() { Toast.makeText(this, "service done", Toast.LENGTH_SHORT).show(); }}
如你所见，它要干的事情比用 IntentService 时多了很多。
不过，因为是自行处理每个 onStartCommand() 调用，你可以同时处理多个请求。 本例中没有这么去实现，但只要你愿意，你就可以为每个请求创建一个新的线程，并立即运行它们（而不是等待前一个请求处理完毕）。
请注意 onStartCommand() 方法必须返回一个整数。这个整数是描述系统在杀死服务之后应该如何继续运行（上一节中缺省的 IntentService 实现代码会替你处理这一点，当然那样你就无法修改这个处理过程）。 onStartCommand() 的返回值必须是以下常量之一：
如果系统在 onStartCommand() 返回后杀死了服务，则不会重建服务了，除非还存在未发送的intent。 当服务不再是必需的，并且应用程序能够简单地重启那些未完成的工作时，这是避免服务运行的最安全的选项。
如果系统在 onStartCommand() 返回后杀死了服务，则将重建服务并调用 onStartCommand() ，但不会再次送入上一个intent， 而是用null intent来调用 onStartCommand() 。除非还有启动服务的intent未发送完，那么这些剩下的intent会继续发送。 这适用于媒体播放器（或类似服务），它们不执行命令，但需要一直运行并随时待命。
如果系统在 onStartCommand() 返回后杀死了服务，则将重建服务并用上一个已送过的intent调用 onStartCommand() 。任何未发送完的intent也都会依次送入。这适用于那些需要立即恢复工作的活跃服务，比如下载文件。
关于这些返回值的详情，请参阅每个常量的参考文档链接 。
从activity或其它应用程序组件中可以启动一个服务，调用 startService() 并传入一个 Intent （指定所需启动的服务）即可。Android系统将调用服务的 onStartCommand() 方法，并传入该 Intent 。（你永远都不应该直接去调用 onStartCommand()）
例如，一个activity可以用一个显式的intent通过 startService() 启动上一节的示例服务（HelloSevice）：
Intentintent = new Intent(this, HelloService.class);startService(intent);
startService() 方法会立即返回，Android系统会去调用服务的 onStartCommand() 方法。如果服务还未运行，系统会首先调用 onCreate() ，然后再去调用 onStartCommand() 。
如果服务不同时支持绑定，那么通过 startService() 传入的intent将是应用程序组件与服务进行交互的唯一途径。 当然，如果你期望服务能返回结果，那启动服务的客户端可以创建一个 PendingIntent 来获得一个广播broadcast（利用 getBroadcast() ），并把它放入启动服务的 Intent 并传到服务中去。然后服务就会用这个broadcast来传递结果。
多个启动服务的请求将会引发服务 onStartCommand() 方法的多次调用。不过，只有一个终止服务的请求（用 stopSelf() 或 stopService() ）会被接受并执行。
一个started服务必须自行管理生命周期。也就是说，系统不会终止或销毁这类服务，除非必须恢复系统内存并且服务返回后一直维持运行。 因此，服务必须通过调用 stopSelf() 自行终止，或者其它组件可通过调用 stopService() 来终止它。
用 stopSelf() 或 stopService() 的终止请求一旦发出，系统就会尽快销毁服务。
不过，如果你的服务要同时处理多个 onStartCommand() 请求，那在处理启动请求的过程中，你就不应该去终止服务，因为你可能接收到了一个新的启动请求（在第一个请求处理完毕后终止服务将停止第二个请求的处理。 为了避免这个问题，你可以用 stopSelf(int) 来确保终止服务的请求总是根据最近一次的启动请求来完成。 也就是说，当你调用 stopSelf(int) 时，你把启动请求ID（发送给 onStartCommand() 的startId）传给了对应的终止请求。这样，如果服务在你可以调用 stopSelf(int) 时接收到了新的启动请求，则ID将会不一样，服务将不会被终止。
警告： 当服务完成工作后，你的应用程序应该及时终止它，这点非常重要。这样可以避免系统资源的浪费，并能节省电池的电力。 必要时，其它组件可以通过调用 stopService() 来终止服务。即使你的服务允许绑定，你也必须保证它在收到对 onStartCommand() 的调用时能够自行终止。
关于服务生命周期的详细信息，请参阅下文的 对服务的生命周期进行管理 章节。
bound服务是指允许被应用程序组件绑定的服务，通过调用 bindService() 可以完成绑定，用于创建一个长期存在的连接（并且一般不再允许组件通过调用 startService() 来start服务。
当应用程序中的activity或其它组件需要与服务进行交互，或者应用程序的某些功能需要暴露给其它应用程序时，你应该创建一个bound服务，并通过进程间通信（IPC）来完成。
要创建一个bound服务，你必须实现 onBind() 回调方法，并返回一个 IBinder 对象，此对象定义了与服务进行通信的接口。 然后，其它应用程序组件可以调用 bindService() 来获得接口并调用服务中的方法。 服务只在为绑定的应用程序组件工作时才会存活，因此，只要没有组件绑定到服务，系统就会自动销毁服务（你不需要像started服务中那样通过 onStartCommand() 来终止一个bound服务）。
要创建一个bound服务，首先必须定义好接口，用于指明客户端如何与服务进行通信。 这个客户端与服务之间的接口必须是一个 IBinder 对象的实现，并且你的服务必须在 onBind() 回调方法中返回这个对象。一旦客户端接收到这个 IBinder ，它就可以通过这个接口来与服务进行交互。
同一个服务可以被多个客户端绑定。当客户端完成交互时，会调用 unbindService() 来解除绑定。一旦不存在客户端与服务绑定时，系统就会销毁该服务。
实现bound服务的方式可以有很多种，实现的过程也比started类型的服务更为复杂，因此bound服务将在单独的bound服务文档中讨论。
一旦开始运行，服务就能够利用 toast通知 或 状态栏通知 把事件通知给用户。
toast通知是一个显示在当前窗口之上的消息框，显示一会儿之后它会自行消失。 而状态栏通知则是在状态栏上显示一个附带消息的图标，用户可以选中它来执行一个action（比如启动一个activity）。
通常，当某些后台工作已经完成时（比如文件下载完毕），状态栏通知是最好的通知手段，用户这时可以在其上执行一些操作。
前台服务是指那些经常会被用户关注的服务，因此内存过低时它不会成为被杀的对象。 前台服务必须提供一个状态栏通知，并会置于“正在进行的”（“Ongoing”）组之下。这意味着只有在服务被终止或从前台移除之后，此通知才能被解除。
例如，用服务来播放音乐的播放器就应该运行在前台，因为用户会清楚地知晓它的运行情况。 状态栏通知可能会标明当前播放的歌曲，并允许用户启动一个activity来与播放器进行交互。
要把你的服务请求为前台运行，可以调用 startForeground() 方法。此方法有两个参数：唯一标识通知的整数值、状态栏通知 Notification 对象。例如：
Notification notification = new Notification(R.drawable.icon, getText(R.string.ticker_text), System.currentTimeMillis());Intent notificationIntent = new Intent(this, ExampleActivity.class);PendingIntent pendingIntent = PendingIntent.getActivity(this, 0, notificationIntent, 0);notification.setLatestEventInfo(this, getText(R.string.notification_title), getText(R.string.notification_message), pendingIntent);startForeground(ONGOING_NOTIFICATION, notification);
要从前台移除服务，请调用 stopForeground() 方法，调用参数是个布尔值，表示是否同时移除状态栏通知。此方法不会终止服务。不过，如果服务在前台运行时被你终止了，那么通知也会同时被移除。
注意： startForeground() 和 stopForeground() 方法是自Android 2.0 (API Level 5)开始引入的。 为了让服务能在更早版本的平台上实现前台运行，你必须使用以前的 setForeground() 方法——关于如何提供向后兼容性的详情，请参阅 startForeground() 。
有关通知的详细信息，请参阅 状态栏通知 。
服务的生命周期与activity的非常类似。不过，更为重要的是你需密切关注服务的创建和销毁环节，因为后台运行的服务是不会引起用户注意的。
服务的生命周期——从创建到销毁——可以有两种路径：
这两种路径并不是完全隔离的。也就是说，你可以绑定到一个已经用 startService() 启动的服务上。例如，一个后台音乐服务可以通过调用 startService() 来启动，传入一个指明所需播放音乐的 Intent。 之后，用户也许需要用播放器进行一些控制，或者需要查看当前歌曲的信息，这时一个activity可以通过调用 bindService() 与此服务绑定。在类似这种情况下， stopService() 或 stopSelf() 不会真的终止服务，除非所有的客户端都解除了绑定。
与activity类似，服务也存在生命周期回调方法，你可以实现这些方法来监控服务的状态变化，并在适当的时机执行一些操作。 以下代码提纲展示了服务的每个生命周期回调方法：
public class ExampleService extends Service { int mStartMode; // indicates how to behave if the service is killed IBinder mBinder; // interface for clients that bind boolean mAllowRebind; // indicates whether onRebind should be used @Override public void onCreate() { // The service is being created } @Override public int onStartCommand(Intent intent, intflags, int startId) { // The service is starting, due to a call to startService() return mStartMode; } @Override public IBinder onBind(Intentintent) { // A client is binding to the service with bindService() return mBinder; } @Override public boolean onUnbind(Intentintent) { // All clients have unbound with unbindService() return mAllowRebind; } @Override public void onRebind(Intentintent) { // A client is binding to the service with bindService(), // after onUnbind() has already been called } @Override public void onDestroy() { // The service is no longer used and is being destroyed }}
图 2.服务的生命周期。 左边的图展示了用 startService() 创建的服务的生命周期，右边的图展示了用 bindService() 创建的服务的生命周期。
注意： 与activity的生命周期回调方法不同，你不是一定要调用父类的回调方法。
通过实现这些方法，你能够监控服务中两个嵌套的生命周期循环
不管是用 startService() 创建的，还是用 bindService() 创建的，所有的服务都会调用 onCreate() 和 onDestroy() 方法。
如果服务是started的，则活跃生存期与完整生存期同时结束（即使 onStartCommand() 返回后，服务仍然处于活跃期。）如果服务是bound的，则活跃生存期在 onUnbind() 返回后结束。
注意： 虽然started的服务是用 stopSelf() 或 stopService() 调用来终止的，但是服务却没有相应的回调方法（不存在onStop()回调方法）。因此，除非服务与客户端绑定了，不然系统就会在服务终止时销毁它—— onDestroy() 是唯一会收到的回调方法。
图 2 标明了服务中典型的回调方法。尽管此图把 startService() 创建的服务和 bindService() 创建的分开描述了，但请记住，无论启动的方式如何，所有的服务实际上都允许被绑定。 因此，用 onStartCommand() 启动的服务（客户端调用 startService() ）仍然可以接收 onBind() 调用（当客户端调用了 bindService() 时）。
联系客服
