Android中IPC机制之service(一)

前言

官方的介绍:

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

service与activity一样都存在与当前进程的主线程中，所以，一些阻塞UI的操作，比如耗时操作不能放在service里进行，比如另外开启一个线程来处理诸如网络请求的耗时操作。如果在service里进行一些耗CPU和耗时操作，可能会引发ANR警告，这时应用会弹出是强制关闭还是等待的对话框。所以，对service的理解就是和activity平级的，只不过是看不见的，在后台运行的一个组件，这也是为什么和activity同被说为Android的基本组件。

通过上图可以更好的解释下面的说明。

1). 被启动的服务的生命周期：如果一个Service被某个Activity 调用 Context.startService 方法启动，那么不管是否有Activity使用bindService绑定或unbindService解除绑定到该Service，该Service都在后台运行。如果一个Service被startService 方法多次启动，那么onCreate方法只会调用一次，onStart将会被调用多次（对应调用startService的次数），并且系统只会创建Service的一个实例（因此你应该知道只需要一次stopService调用）。该Service将会一直在后台运行，而不管对应程序的Activity是否在运行，直到被调用stopService，或自身的stopSelf方法。当然如果系统资源不足，android系统也可能结束服务。

2). 被绑定的服务的生命周期：如果一个Service被某个Activity 调用 Context.bindService 方法绑定启动，不管调用 bindService 调用几次，onCreate方法都只会调用一次，同时onStart方法始终不会被调用。当连接建立之后，Service将会一直运行，除非调用Context.unbindService 断开连接或者之前调用bindService 的 Context 不存在了（如Activity被finish的时候），系统将会自动停止Service，对应onDestroy将被调用。

3). 被启动又被绑定的服务的生命周期：如果一个Service又被启动又被绑定，则该Service将会一直在后台运行。并且不管如何调用，onCreate始终只会调用一次，对应startService调用多少次，Service的onStart便会调用多少次。调用unbindService将不会停止Service，而必须调用 stopService 或 Service的 stopSelf 来停止服务。

4). 当服务被停止时清除服务：当一个Service被终止（1、调用stopService；2、调用stopSelf；3、不再有绑定的连接（没有被启动））时，onDestroy方法将会被调用，在这里你应当做一些清除工作，如停止在Service中创建并运行的线程。

特别注意：

1、你应当知道在调用 bindService 绑定到Service的时候，你就应当保证在某处调用 unbindService 解除绑定（尽管 Activity 被 finish 的时候绑定会自　　　　　　动解除，并且Service会自动停止）；

2、你应当注意 使用 startService 启动服务之后，一定要使用 stopService停止服务，不管你是否使用bindService；

3、同时使用 startService 与 bindService 要注意到，Service 的终止，需要unbindService与stopService同时调用，才能终止 Service，不管 startService 与 bindService 的调用顺序，如果先调用 unbindService 此时服务不会自动终止，再调用 stopService 之后服务才会停止，如果先调用 stopService 此时服务也不会终止，而再调用 unbindService 或者 之前调用 bindService 的 Context 不存在了（如Activity 被 finish 的时候）之后服务才会自动停止；

4、当在旋转手机屏幕的时候，当手机屏幕在“横”“竖”变换时，此时如果你的 Activity 如果会自动旋转的话，旋转其实是 Activity 的重新创建，因此旋转之前的使用 bindService 建立的连接便会断开（Context 不存在了），对应服务的生命周期与上述相同。

5、在 sdk 2.0 及其以后的版本中，对应的 onStart 已经被否决变为了 onStartCommand，不过之前的 onStart 任然有效。这意味着，如果你开发的应用程序用的 sdk 为 2.0 及其以后的版本，那么你应当使用 onStartCommand 而不是 onStart。

重点关注下onStartCommand(Intent intent, int flags, int startId)方法。

其中参数flags默认情况下是0，对应的常量名为START_STICKY_COMPATIBILITY。startId是一个唯一的整型，用于表示此次Client执行startService(…)的请求请求标识，在多次startService(…)的情况下，呈现0,1,2….递增。另外，此函数具有一个int型的返回值，具体的可选值及含义如下：

START_NOT_STICKY：当Service因为内存不足而被系统kill后，接下来未来的某个时间内，即使系统内存足够可用，系统也不会尝试重新创建此Service。除非程序中Client明确再次调用startService(…)启动此Service。

START_STICKY：当Service因为内存不足而被系统kill后，接下来未来的某个时间内，当系统内存足够可用的情况下，系统将会尝试重新创建此Service，一旦创建成功后将回调onStartCommand(…)方法，但其中的Intent将是null，pendingintent除外。

START_REDELIVER_INTENT：与START_STICKY唯一不同的是，回调onStartCommand(…)方法时，其中的Intent将是非空，将是最后一次调用startService(…)中的intent。

START_STICKY_COMPATIBILITY：compatibility version of {@link #START_STICKY} that does not guarantee that {@link #onStartCommand} will be called again after being killed。此值一般不会使用，所以注意前面三种情形就好。

以上的描述中，”当Service因为内存不足而被系统kill后“一定要非常注意，因为此函数的返回值设定只是针对此种情况才有意义的，换言之，当认为的kill掉Service进程，此函数返回值无论怎么设定，接下来未来的某个时间内，即使系统内存足够可用，Service也不会重启。

当Service需要运行在单独的进程中，AndroidManifest.xml声明时需要通过android:process指明此进程名称，当此Service需要对其他App开放时，android:exported属性值需要设置为true(当然，在有intent-filter时默认值就是true)。

<service
    android:name=".MyService"
    android:exported="true"
    android:process=":remote" >
    <intent-filter>
        <action android:name="com.example.androidtest.myservice" />
    </intent-filter>
</service>

在 AndroidManifest.xml 里 Service 元素的常见选项

android:name　　————-　　服务类名

android:label　　————–　　服务的名字，如果此项不设置，那么默认显示的服务名则为类名

android:icon　　————–　　服务的图标

android:permission　　——-　　申明此服务的权限，这意味着只有提供了该权限的应用才能控制或连接此服务

android:process　　———-　　表示该服务是否运行在另外一个进程，如果设置了此项，那么将会在包名后面加上这段字符串表示另一进程的名字

android:enabled　　———-　　如果此项设置为 true，那么 Service 将会默认被系统启动，不设置默认此项为 false

android:exported　　———　　表示该服务是否能够被其他应用程序所控制或连接，不设置默认此项为 false

4)Started Service Client与Service通信相关

当Client调用startService(Intent serviceIntent)启动Service时，Client可以将参数通过Intent直接传递给Service。Service执行过程中，如果需要将参数传递给Client，一般可以通过借助于发送广播的方式（此时，Client需要注册此广播）。

3.Bind Service

相对于Started Service，Bind Service具有更多的知识点。Bind Service的主要特性在于Service的生命周期是依附于Client的生命周期的，当Client不存在时，Bound Service将执行onDestroy，同时通过Service中的Binder对象可以较为方便进行Client-Service通信。

需要注意的是:

注：在四大基本组件中，需要注意的的是BroadcastReceiver不能作为Bound Service的Client，因为BroadcastReceiver的生命周期很短，当执行完onReceive(..)回调时，BroadcastReceiver生命周期完结。而Bound Service又与Client本身的生命周期相关，因此，Android中不允许BroadcastReceiver去bindService(..)，当有此类需求时，可以考虑通过startService(..)替代。

Service特性

1.Service本身都是运行在其所在进程的主线程（如果Service与Clinet同属于一个进程，则是运行于UI线程），但Service一般都是需要进行”长期“操作，所以经常写法是在自定义Service中处理”长期“操作时需要新建线程，以免阻塞UI线程或导致ANR；

2.Service一旦创建，需要停止时都需要显示调用相应的方法（Started Service需要调用stopService(..)或Service本身调用stopSelf(..)， Bound Service需要调用unbindService(..)），否则对于Started Service将处于一直运行状态，对于Bound Service，当Client生命周期结束时也将因此问题。也就是说，Service执行完毕后，必须人为的去停止它。

Bind Service一般使用过程如下：

1.自定义Service继承基类Service，并重写onBind(Intent intent)方法，此方法中需要返回具体的Binder对象；

2.Client通过实现ServiceConnection接口来自定义ServiceConnection，并通过bindService (Intent service, ServiceConnection sc, int flags)方法将Service绑定到此Client上；

3.自定义的ServiceConnection中实现onServiceConnected(ComponentName name, IBinder binder)方法，获取Service端Binder实例；

4.通过获取的Binder实例进行Service端其他公共方法的调用，以完成Client-Service通信；

5.当Client在恰当的生命周期（如onDestroy等）时，此时需要解绑之前已经绑定的Service，通过调用函数unbindService(ServiceConnection sc)。

@Override
  public void onServiceDisconnected(ComponentName name) {
        /*This is called when the connection with the service has been unexpectedly disconnected -- that is,
        its process crashed. Because it is running in our same process, we should never see this happen.
           所以说，只有在service因异常而断开连接的时候(例如内存的资源不足时)，这个方法才会用到。*/
            Toast.makeText(MainActivity.this, "远程服务断开了", Toast.LENGTH_SHORT).show();
            remoteService = null;
        }
    };

IntentService

IntentService是系统提供给我们的一个已经继承自Service类的特殊类，IntentService特殊性是相对于Service本身的特性而言的：

1.默认直接实现了onBind(..)方法，直接返回null，并定义了抽象方法onHandlerIntent(..)，用户自定义子类时，需要实现此方法；

2.onHandlerIntent(..)主要就是用来处于相应的”长期“任务的，并且已经自动在新的线程中，用户无语自定义新线程；

3.当”长期“任务执行完毕后（也就是onHandlerIntent(..)执行完毕后），此IntentService将自动结束，无需人为调用方法使其结束；

4.IntentService处于任务时，也是按照队列的方式一个个去处理，而非真正意义上的多线程并发方式。

下面是一个基本的继承自IntentService的自定义Service：

public class MyIntentService extends IntentService {

    public static final String TAG = "MyIntentService";

    public MyIntentService() {
        super(TAG);
    }

    public MyIntentService(String name) {
        super(name);
    }

    @Override
    protected void onHandleIntent(Intent intent) {
        Log.w(TAG, "thread name:" + Thread.currentThread().getName());
    }

}

service与Thread的区别

1). Thread：Thread 是程序执行的最小单元，它是分配CPU的基本单位。可以用 Thread 来执行一些异步的操作。

2). Service：Service 是android的一种机制，当它运行的时候如果是Local Service，那么对应的Service 是运行在主进程的 main 线程上的。如：onCreate，onStart 这些函数在被系统调用的时候都是在主进程的 main 线程上运行的。如果是Remote Service，那么对应的 Service 则是运行在独立进程的 main 线程上。

既然这样，那么我们为什么要用 Service 呢？其实这跟 android 的系统机制有关，我们先拿Thread 来说。Thread 的运行是独立于 Activity 的，也就是说当一个 Activity 被 finish 之后，如果你没有主动停止 Thread 或者 Thread 里的 run 方法没有执行完毕的话，Thread 也会一直执行。因此这里会出现一个问题：当 Activity 被 finish 之后，你不再持有该 Thread 的引用。另一方面，你没有办法在不同的 Activity 中对同一 Thread 进行控制。

举个例子：如果你的 Thread 需要不停地隔一段时间就要连接服务器做某种同步的话，该 Thread 需要在 Activity 没有start的时候也在运行。这个时候当你 start 一个 Activity 就没有办法在该 Activity 里面控制之前创建的 Thread。因此你便需要创建并启动一个 Service ，在 Service 里面创建、运行并控制该 Thread，这样便解决了该问题（因为任何 Activity 都可以控制同一 Service，而系统也只会创建一个对应 Service 的实例）。

因此你可以把 Service 想象成一种消息服务，而你可以在任何有 Context 的地方调用Context.startService、Context.stopService、Context.bindService，Context.unbindService，来控制它，你也可以在 Service 里注册 BroadcastReceiver，在其他地方通过发送 broadcast 来控制它，当然这些都是 Thread 做不到的。

ok,service介绍完毕,下一节介绍使用IPC进程通信.