public abstract class

Service

extends ContextWrapper
implements ComponentCallbacks

Class Overview

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. Each service class must have a corresponding <service> declaration in its package's AndroidManifest.xml. Services can be started with Context.startService() and Context.bindService().

Service主要用于两种目的：

1、在后台长时间执行某个任务，不和用户直接交互

2、给其他应用程序提供某种功能服务

Note that services, like other application objects, run in the main thread of their hosting process. This means that, if your service is going to do any CPU intensive (such as MP3 playback) or blocking (such as networking) operations, it should spawn its own thread in which to do that work. More information on this can be found in Application Fundamentals: Processes and Threads. The IntentService class is available as a standard implementation of Service that has its own thread where it schedules its work to be done.

The Service class is an important part of an application's overall lifecycle.

Topics covered here:

What is a Service?
Service Lifecycle
Permissions
Process Lifecycle
Local Service Sample
Remote Messenger Service Sample

What is a Service?

Most confusion about the Service class actually revolves around what it is not:

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不是一个独立的进程，而是工作在应用程序所在的进程之中。Service也不是一个线程。

Thus a Service itself is actually very simple, providing two main features:

A facility for the application to tell the system about something it wants to be doing in the background (even when the user is not directly interacting with the application). This corresponds to calls to Context.startService(), which ask the system to schedule work for the service, to be run until the service or someone else explicitly stop it.
A facility for an application to expose some of its functionality to other applications. This corresponds to calls to Context.bindService(), which allows a long-standing connection to be made to the service in order to interact with it.

When a Service component is actually created, for either of these reasons, all that the system actually does is instantiate the component and call its onCreate() and any other appropriate callbacks on the main thread. It is up to the Service to implement these with the appropriate behavior, such as creating a secondary thread in which it does its work.

Note that because Service itself is so simple, you can make your interaction with it as simple or complicated as you want: from treating it as a local Java object that you make direct method calls on (as illustrated by Local Service Sample), to providing a full remoteable interface using AIDL.

Service Lifecycle

There are two reasons that a service can be run by the system. If someone calls Context.startService() then the system will retrieve the service (creating it and calling its onCreate() method if needed) and then call its onStartCommand(Intent, int, int) method with the arguments supplied by the client. The service will at this point continue running until Context.stopService() or stopSelf() is called. Note that multiple calls to Context.startService() do not nest (though they do result in multiple corresponding calls to onStartCommand()), so no matter how many times it is started a service will be stopped once Context.stopService() or stopSelf() is called; however, services can use their stopSelf(int) method to ensure the service is not stopped until started intents have been processed.

For started services, there are two additional major modes of operation they can decide to run in, depending on the value they return from onStartCommand(): START_STICKY is used for services that are explicitly started and stopped as needed, while START_NOT_STICKY or START_REDELIVER_INTENT are used for services that should only remain running while processing any commands sent to them. See the linked documentation for more detail on the semantics.

Clients can also use Context.bindService() to obtain a persistent connection to a service. This likewise creates the service if it is not already running (calling onCreate() while doing so), but does not call onStartCommand(). The client will receive the IBinder object that the service returns from its onBind(Intent) method, allowing the client to then make calls back to the service. The service will remain running as long as the connection is established (whether or not the client retains a reference on the service's IBinder). Usually the IBinder returned is for a complex interface that has been written in aidl.

A service can be both started and have connections bound to it. In such a case, the system will keep the service running as long as either it is started or there are one or more connections to it with the Context.BIND_AUTO_CREATE flag. Once neither of these situations hold, the service's onDestroy() method is called and the service is effectively terminated. All cleanup (stopping threads, unregistering receivers) should be complete upon returning from onDestroy().

Service对调用的三种方式：

1、当系统中调用Context.startService()时，系统就会搜索是否存在合适的Service响应，如果存在，就调用它的onCreate()函数创建它，然后再调用它的onStartCommand()，Service会一直运行直到出现Context.stopService()或stopSelf()的调用。

2、客户端代码也可以调用Context.bindService()来获得与某项服务的长期绑定，这样也会调用Service的onCreate()方法，但不会调用onStartCommand()方法。客户端代码会得到一个IBinder对象，如果它调用Service的onBind()方法，这允许客户端通过IBinder对象对Service进行回调。Service会一直在后台运行，即使当前没有客户端代码对service的IBinder对象的引用。

3、Service也可以同时被开启并绑定，在这种情况下，Service会在开启状态或存在对Service绑定连接状态下保持运行。但是一旦两种条件都不成立，那么Service的onDestroy()函数就会被调用。所以在onDestroy()函数中需要进行清理工作：如停止相关的线程、注销接收者）

Permissions

Global access to a service can be enforced when it is declared in its manifest's <service> tag. By doing so, other applications will need to declare a corresponding <uses-permission> element in their own manifest to be able to start, stop, or bind to the service.

In addition, a service can protect individual IPC calls into it with permissions, by calling the checkCallingPermission(String) method before executing the implementation of that call.

在Service对应的manifest文件中需要添加<service>标签，但是在使用Service的客户端需要使用<uses-permission>标签。

Process Lifecycle

The Android system will attempt to keep the process hosting a service around as long as the service has been started or has clients bound to it. When running low on memory and needing to kill existing processes, the priority of a process hosting the service will be the higher of the following possibilities:

If the service is currently executing code in its onCreate(), onStartCommand(), or onDestroy() methods, then the hosting process will be a foreground process to ensure this code can execute without being killed.
If the service has been started, then its hosting process is considered to be less important than any processes that are currently visible to the user on-screen, but more important than any process not visible. Because only a few processes are generally visible to the user, this means that the service should not be killed except in extreme low memory conditions.
If there are clients bound to the service, then the service's hosting process is never less important than the most important client. That is, if one of its clients is visible to the user, then the service itself is considered to be visible.
A started service can use the startForeground(int, Notification) API to put the service in a foreground state, where the system considers it to be something the user is actively aware of and thus not a candidate for killing when low on memory. (It is still theoretically possible for the service to be killed under extreme memory pressure from the current foreground application, but in practice this should not be a concern.)

Note this means that most of the time your service is running, it may be killed by the system if it is under heavy memory pressure. If this happens, the system will later try to restart the service. An important consequence of this is that if you implement onStartCommand() to schedule work to be done asynchronously or in another thread, then you may want to use START_FLAG_REDELIVERY to have the system re-deliver an Intent for you so that it does not get lost if your service is killed while processing it.

Other application components running in the same process as the service (such as an Activity) can, of course, increase the importance of the overall process beyond just the importance of the service itself.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

android.app.Service

下面是一些常用的成员方法：

public void onCreate ()

Since: API Level 1

Called by the system when the service is first created. Do not call this method directly

public void onDestroy ()

Since: API Level 1

Called by the system to notify a Service that it is no longer used and is being removed. The service should clean up an resources it holds (threads, registered receivers, etc) at this point. Upon return, there will be no more calls in to this Service object and it is effectively dead. Do not call this method directly.

public int onStartCommand (Intent intent, int flags, int startId)

Since: API Level 5

Called by the system every time a client explicitly starts the service by calling startService(Intent), providing the arguments it supplied and a unique integer token representing the start request. Do not call this method directly.

For backwards compatibility, the default implementation calls onStart(Intent, int) and returns either START_STICKY or START_STICKY_COMPATIBILITY.

Parameters

intent	The Intent supplied to `startService(Intent)`, as given. This may be null if the service is being restarted after its process has gone away, and it had previously returned anything except `START_STICKY_COMPATIBILITY`.
flags	Additional data about this start request. Currently either 0, `START_FLAG_REDELIVERY`, or `START_FLAG_RETRY`.
startId	A unique integer representing this specific request to start. Use with `stopSelfResult(int)`.

public abstract IBinder onBind (Intent intent)

Since: API Level 1

Return the communication channel to the service. May return null if clients can not bind to the service. The returned IBinder is usually for a complex interface that has been described using aidl.

Note that unlike other application components, calls on to the IBinder interface returned here may not happen on the main thread of the process. More information about this can be found in Application Fundamentals: Processes and Threads.

Parameters

intent	The Intent that was used to bind to this service, as given to `Context.bindService`. Note that any extras that were included with the Intent at that point will not be seen here.

Returns

Return an IBinder through which clients can call on to the service.

public final void stopSelf ()

Since: API Level 1

Stop the service, if it was previously started. This is the same as calling stopService(Intent) for this particular service

SDK中的localService还没有研究。。。。。

Android：Service

Service

Class Overview

What is a Service?

Service Lifecycle

Permissions

Process Lifecycle

public void onCreate ()

public void onDestroy ()

public int onStartCommand (Intent intent, int flags, int startId)

Parameters

public abstract IBinder onBind (Intent intent)

Parameters

Returns

public final void stopSelf ()

更多相关文章

随机推荐