Android Service学习笔记

Android Service学习笔记

---

参考：
Android Service完全解析，关于服务你所需知道的一切(上)
Android Service完全解析，关于服务你所需知道的一切(下)
关于Android Service真正的完全详解，你需要知道的一切
阅读了这两（三）篇解析之后，将其中涉及到的东西以自己能理解的方式记录下来。

介绍

Service主要用于在后台处理一些耗时的逻辑，或者去执行某些需要长期运行的任务。必要的时候我们甚至可以在程序退出的情况下，让Service在后台继续保持运行状态，如音乐播放器等。
根据服务在主线程或其他线程运行，可以分为本地服务和远程服务；

启动与绑定

根据服务运行的两种形式，可以分为启动方式和绑定方式：

• 启动
  当应用组件（如 Activity）通过调用 startService() 启动服务时，服务即处于“启动”状态。一旦启动，服务即可在后台无限期运行，即使启动服务的组件已被销毁也不受影响，除非手动调用才能停止服务， 已启动的服务通常是执行单一操作，而且不会将结果返回给调用方，和启动源没什么联系。
• 绑定
  当应用组件通过调用bindService() 绑定到服务时，服务即处于“绑定”状态。绑定服务提供了一个客户端-服务器接口（ServiceConnection），通过这个借口中的相关方法可以获取到服务的信息，执行相关方法等，允许组件与服务进行交互、发送请求、获取结果，甚至是利用进程间通信 (IPC) 跨进程执行这些操作。 仅当与另一个应用组件绑定时，绑定服务才会运行。 多个组件可以同时绑定到该服务，但全部取消绑定后，该服务即会被销毁。

虽然服务的状态有启动和绑定两种，但实际上一个服务可以同时是这两种状态，也就是说，它既可以是启动服务（以无限期运行），也可以是绑定服务服务，问题只是在于是否实现了相应的回调方法：onStartCommand()（允许组件启动服务）和 onBind()（允许绑定服务）。有点需要注意的是Android系统仅会为一个Service创建一个实例对象，所以不管是启动服务还是绑定服务，操作的是同一个Service实例，而且由于绑定服务或者启动服务执行顺序问题将会出现以下两种情况：

• 先绑定服务后启动服务
  如果当前Service实例先以绑定状态运行，然后再以启动状态运行，那么绑定服务将会转为启动服务运行，这时如果之前绑定的宿主（Activity）被销毁了，也不会影响服务的运行，服务还是会一直运行下去，指定收到调用停止服务或者内存不足时才会销毁该服务。
• 先启动服务后绑定服务
  如果当前Service实例先以启动状态运行，然后再以绑定状态运行，当前启动服务并不会转为绑定服务，但是还是会与宿主绑定，只是即使宿主解除绑定后，服务依然按启动服务的生命周期在后台运行，直到有Context调用了stopService()或是服务本身调用了stopSelf()方法抑或内存不足时才会销毁服务。

生命周期

使用方法

Service有几种不同的运行方式，可以在主线程或其他线程中运行，可以跨进程交互，但整体来说不外乎在Service中编写相对应的回调方法，然后在Activity中启动或绑定，如果只是启动，则之后Activity只能停止，而不能做出交互，只有绑定方式，才可以在ServiceConnection中获取到Service定义的Binder对象（或者Service自己也是可以的）进行交互。

继承Service编写自己的自定义Service

public class MyService extends Service {  

    public static final String TAG = "MyService";  

    @Override  
    public void onCreate() {  
        super.onCreate();  
        Log.d(TAG, "onCreate() executed");  
    }  

    @Override  
    public int onStartCommand(Intent intent, int flags, int startId) {  
        // 只在启动模式下执行
        Log.d(TAG, "onStartCommand() executed");  
        return super.onStartCommand(intent, flags, startId);  
    }  

    @Override  
    public void onDestroy() {  
        super.onDestroy();  
        Log.d(TAG, "onDestroy() executed");  
    }  

    @Override  
    public IBinder onBind(Intent intent) {  
        // 只在绑定时执行，需要编写Binder对象在这里返回
        return null;  
    }  

}  

启动模式

• 在AndroidManifest.xml中注册（application标签之内）

    <service android:name="com.example.servicetest.MyService" >

• 在需要的时机使用Intent启动或停止Service

    Intent startIntent = new Intent(this, MyService.class);  
    startService(startIntent);  
    Intent stopIntent = new Intent(this, MyService.class);  
    stopService(stopIntent);  

因为编写的Service没有编写onBind()方法，也没有绑定任何东西，启动之后就和启动它的Activity没有什么关系了；
启动过程：onCreate()->onStartCommand()
在启动之后再startService，就只有onStartCommand()
执行了。
在服务的内部可以调用stopSelf()方法停止当前服务。

绑定模式

要和Activity关联起来就需要实现onBind()方法，首先需要编写一个自定义的Binder继承自Binder基类：

class MyBinder extends Binder {  
    public void startDoSth() {  
        Log.d("TAG", "do sth");  
        // do sth  
    }  
}  

这个类将在Service对象创建时实例化并用于和Service绑定，修改之前的Service代码：

private MyBinder mBinder = new MyBinder();
//...
//...
@Override  
public IBinder onBind(Intent intent) {  
    // 此处把mBinder作为一个IBinder返回，在后面被connection获取
    return mBinder;  
}  

同时在Activity中还需要实现一个ServiceConnection来获取Binder并执行里面的方法完成这一过程：

private MyService.MyBinder myBinder;  
private ServiceConnection connection = new ServiceConnection() {  
    @Override  
    public void onServiceDisconnected(ComponentName name) {  
        //Android 系统会在与服务的连接意外中断时（例如当服务崩溃或被终止时）调用该方法。注意:当客户端取消绑定时，系统“绝对不会”调用该方法。
    }  

    @Override  
    public void onServiceConnected(ComponentName name, IBinder service) { 
        // 绑定之后进行的操作，应该是自动获取到IBinder类型的service，实际上就是MyBinder，所以直接强制类型转换
        myBinder = (MyService.MyBinder) service;  
        myBinder.startDoSth();  
        }  
    };  

到这里只是写好了用于绑定的准备工作和绑定完成之后的操作，而真正的绑定过程如下：

Intent bindIntent = new Intent(this, MyService.class);  
bindService(bindIntent, connection, BIND_AUTO_CREATE); 

bindService()方法接收三个参数，第一个参数就是刚刚构建出的Intent对象，第二个参数是前面创建出的ServiceConnection的实例，第三个参数是一个标志位，这里传入BIND_AUTO_CREATE表示在Activity和Service建立关联后自动创建Service，这会使得MyService中的onCreate()方法得到执行，但onStartCommand()方法不会执行。所以绑定之后的流程是onCreate()->startDoSth()。
注意到这里并没有onStartCommand()，而是执行onServiceConnected()中的代码。
停止Service：

unbindService(connection);
// 这里的service只创建了，并没有start，所以直接解绑就可以

注意：
Stop Service只会让Service停止，Unbind Service按钮只会让Service和Activity解除关联，一个Service必须要在既没有和任何Activity关联又处理停止状态的时候才会被销毁。
宿主（Activity）解除绑定后，绑定服务就会被销毁

远程Service（无法绑定）

将一个普通的Service转换成远程Service其实非常简单，只需要在注册Service的时候将它的android:process属性指定成:remote就可以了

<service  
    android:name="com.example.servicetest.MyService"  
    android:process=":remote" >  
</service>  

远程Service不在主线程中运行，耗时操作不会阻塞进程，但是Activity和Service运行在两个不同的进程当中，也就不能再使用传统的建立关联的方式，根本无法绑定了。所以这时只能start而不能使用bind方法来使用Service。

绑定远程Service（改进版/跨进程通信）

使用AIDL

此处使用了AIDL（Android Interface Definition Language），是Android接口定义语言的意思，它可以用于让某个Service与多个应用程序组件之间进行跨进程通信，从而可以实现多个应用程序共享同一个Service的功能。
新建aidl，之后会自动生成这样一个java文件:

package com.example.servicetest;  
interface MyAIDLService {  
    int plus(int a, int b);  
    String toUpperCase(String str);  
}

然后修改MyService中的代码，在里面实现定义好的MyAIDLService接口（没弄明白Stub哪来的，此处理解为一个存根），此处把实例化Binder改成了实例化一个Stub:

MyAIDLService.Stub mBinder = new Stub() {  
    @Override  
    public String toUpperCase(String str) throws RemoteException {  
        if (str != null) {  
            return str.toUpperCase();  
        }  
        return null;  
    }  

    @Override  
    public int plus(int a, int b) throws RemoteException {  
        return a + b;  
    }  
};  

然后在onBind()方法中将MyAIDLService.Stub的实现返回。因为Stub其实就是Binder的子类，所以在onBind()方法中可以直接返回Stub的实现。
修改connection：

@Override  
public void onServiceConnected(ComponentName name, IBinder service) {  
      myAIDLService = MyAIDLService.Stub.asInterface(service);  
      // 调用Service中的方法
      try {  
          int result = myAIDLService.plus(3, 5);  
          String upperStr = myAIDLService.toUpperCase("hello world");  
          Log.d("TAG", "result is " + result);  
          Log.d("TAG", "upperStr is " + upperStr);  
      } catch (RemoteException e) {  
          e.printStackTrace();  
      }  
} 

关于Stub：
j2ee里面的stub是这样说的..为屏蔽客户调用远程主机上的对象，必须提供某种方式来模拟本地对象,这种本地对象称为存根(stub),存根负责接收本地方法调用,并将它们委派给各自的具体实现对象

此时依然是调用bindService()来绑定服务，在一个Activity里调用了同一个应用程序的Service里的方法。

跨进程

在另一个应用程序中去绑定Service的时候并没有MyService这个类，这时就必须使用到隐式Intent了。现在修改AndroidManifest.xml中的代码，给MyService加上一个action

<service  
    android:name="com.example.servicetest.MyService"  
    android:process=":remote" >  
    <intent-filter>  
        <action android:name="com.example.servicetest.MyAIDLService"/>  
    </intent-filter>  
</service>  

在另一个程序中，需要复制一份MyAIDLService.aidl文件，注意要将原有的包路径一起拷贝过来，绑定的代码修改如下：

Intent intent = new Intent("com.example.servicetest.MyAIDLService").setPakage("com.example.servicetest");;  
bindService(intent, connection, BIND_AUTO_CREATE);  

将Intent的action指定成了com.example.servicetest.MyAIDLService。

使用Messenger

• 服务实现一个 Handler，由其接收来自客户端的每个调用的回调

 /**
 * 用于接收从客户端传递过来的数据
 */
class IncomingHandler extends Handler {
    @Override
    public void handleMessage(Message msg) {
        switch (msg.what) {
            case MSG_SAY_HELLO:
                Log.i(TAG, "thanks,Service had receiver message from client!");
                break;
            default:
                super.handleMessage(msg);
        }
    }
}

• Handler 用于创建 Messenger 对象（对 Handler 的引用）

/**
* 创建Messenger并传入Handler实例对象
*/
final Messenger mMessenger = new Messenger(new IncomingHandler());

• Messenger 创建一个 IBinder，服务通过 onBind() 使其返回客户端

/**
 * 当绑定Service时,该方法被调用,将通过mMessenger返回一个实现
 * IBinder接口的实例对象
 */
@Override
public IBinder onBind(Intent intent) {
    Log.i(TAG, "Service is invoke onBind");
    return mMessenger.getBinder();
}

• 客户端使用 IBinder 将 Messenger（引用服务的 Handler）实例化，然后使用Messenger将 Message 对象发送给服务

public void onServiceConnected(ComponentName className, IBinder service) {
    /**
     * 通过服务端传递的IBinder对象,创建相应的Messenger
     * 通过该Messenger对象与服务端进行交互
     */
    mService = new Messenger(service);
    mBound = true;
}

• 服务在其 Handler 中（在 handleMessage() 方法中）接收每个 Message

前台服务

前台服务被认为是用户主动意识到的一种服务，因此在内存不足时，系统也不会考虑将其终止。 前台服务必须为状态栏提供通知，状态栏位于“正在进行”标题下方，这意味着除非服务停止或从前台删除，否则不能清除通知。
Android官方给我们提供了两个方法，分别是startForeground()和stopForeground()，这两个方式解析如下：

• startForeground(int id, Notification notification)
  该方法的作用是把当前服务设置为前台服务，其中id参数代表唯一标识通知的整型数，需要注意的是提供给 startForeground() 的整型 ID 不得为 0，而notification是一个状态栏的通知。
• stopForeground(boolean removeNotification)
  该方法是用来从前台删除服务，此方法传入一个布尔值，指示是否也删除状态栏通知，true为删除。 注意该方法并不会停止服务。 但是，如果在服务正在前台运行时将其停止，则通知也会被删除。

Myservice.java

 /**
 * Notification
 */
public void createNotification(){
    //使用兼容版本
    NotificationCompat.Builder builder=new NotificationCompat.Builder(this);
    //设置状态栏的通知图标
    builder.setSmallIcon(R.mipmap.ic_launcher);
    //设置通知栏横条的图标
    builder.setLargeIcon(BitmapFactory.decodeResource(getResources(),R.drawable.screenflash_logo));
    //禁止用户点击删除按钮删除
    builder.setAutoCancel(false);
    //禁止滑动删除
    builder.setOngoing(true);
    //右上角的时间显示
    builder.setShowWhen(true);
    //设置通知栏的标题内容
    builder.setContentTitle("I am Foreground Service!!!");
    //创建通知
    Notification notification = builder.build();
    //设置为前台服务
    startForeground(NOTIFICATION_DOWNLOAD_PROGRESS_ID,notification);
}

 @Override
public int onStartCommand(Intent intent, int flags, int startId) {
    int i=intent.getExtras().getInt("cmd");
    if(i==0){
        if(!isRemove) {
            createNotification();
        }
        isRemove=true;
    }else {
        //移除前台服务
        if (isRemove) {
            stopForeground(true);
        }
        isRemove=false;
    }

    return super.onStartCommand(intent, flags, startId);
}

@Override
public void onDestroy() {
    //移除前台服务
    if (isRemove) {
        stopForeground(true);
    }
    isRemove=false;
    super.onDestroy();
}

onStartCommand详解

onStartCommand(tent intent, int flags, int startId)

参数

• intent ：启动时，启动组件传递过来的Intent，如Activity可利用Intent封装所需要的参数并传递给Service
• flags：表示启动请求时是否有额外数据，可选值有 0，START_FLAG_REDELIVERY，START_FLAG_RETRY，0代表没有，它们具体含义如下：
  
  • START_FLAG_REDELIVERY
    这个值代表了onStartCommand方法的返回值为
    START_REDELIVER_INTENT，而且在上一次服务被杀死前会去调用stopSelf方法停止服务。其中START_REDELIVER_INTENT意味着当Service因内存不足而被系统kill后，则会重建服务，并通过传递给服务的最后一个 Intent 调用 onStartCommand()，此时Intent时有值的。
  • START_FLAG_RETRY
    该flag代表当onStartCommand调用后一直没有返回值时，会尝试重新去调用onStartCommand()。
• startId ： 指明当前服务的唯一ID，与stopSelfResult(int startId)配合使用，stopSelfResult 可以更安全地根据ID停止服务。

返回值

实际上onStartCommand的返回值int类型才是最最值得注意的，它有三种可选值， START_STICKY，START_NOT_STICKY，START_REDELIVER_INTENT，它们具体含义如下：

• START_STICKY
  当Service因内存不足而被系统kill后，一段时间后内存再次空闲时，系统将会尝试重新创建此Service，一旦创建成功后将回调onStartCommand方法，但其中的Intent将是null，除非有挂起的Intent，如pendingintent，这个状态下比较适用于不执行命令、但无限期运行并等待作业的媒体播放器或类似服务。
• START_NOT_STICKY
  当Service因内存不足而被系统kill后，即使系统内存再次空闲时，系统也不会尝试重新创建此Service。除非程序中再次调用startService启动此Service，这是最安全的选项，可以避免在不必要时以及应用能够轻松重启所有未完成的作业时运行服务。
• START_REDELIVER_INTENT
  当Service因内存不足而被系统kill后，则会重建服务，并通过传递给服务的最后一个 Intent 调用 onStartCommand()，任何挂起 Intent均依次传递。与START_STICKY不同的是，其中的传递的Intent将是非空，是最后一次调用startService中的intent。这个值适用于主动执行应该立即恢复的作业（例如下载文件）的服务。