Android兼容性优化-8.0之后启动后台服务报错异常

前言
本次主要内容包括：

1、Android8.0之后IntentService启动异常跟踪

2、JobIntentService替代IntentService方案

一、Android8.0之后IntentService启动异常跟踪
项目中在做启动优化时，在Application 通过IntentService启动第三方组件时，bugly时常会上报如下问题：

android.app.RemoteServiceException
Context.startForegroundService() did not then call Service.startForeground()

main(2)

android.app.RemoteServiceException
Context.startForegroundService() did not then call Service.startForeground()

1 android.app.ActivityThread$H.handleMessage(ActivityThread.java:2056)2android.os.Handler.dispatchMessage(Handler.java:106)3android.os.Looper.loop(Looper.java:192)4android.app.ActivityThread.main(ActivityThread.java:6959)5java.lang.reflect.Method.invoke(NativeMethod)6com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:557)
7 com.android.internal.os.ZygoteInit.main(ZygoteInit.java:875)

1、Service和IntentService使用场景以及区别
Service的使用场景：

a、Service是运行在主线程的，如果我们需要执行耗时操作，也是在Service创建Thread执行。

b、如果耗时操作无法在当前Activity生命周期执行完成的任务就需要在Service执行，比如异步下载等。

c、需要长时间在后台运行，跟随APP生命周期的任务需要在Service执行，比如Socket长连接。

d、Service是所有服务的基类，我们通常都是继承该类实现服务，如果使用该类，我们需要对Service的生命周期进行管理，在合适的地方停止Service。

IntentService特点

a、IntentService继承于Service，通过源码可以看到，是在Service的基础上增加了Handler、Looper、HandlerThread的支持；

b、只需要重写onHandleIntent(Intentintent)实现异步任务，这个方法已经是非UI线程，可以执行耗时操作；

c、一旦这个方法执行完毕，就会立刻执行stopSelf()停止服务，无需手动停止服务。

Android 8.0新增了startForegroundService方法，用于启动前台服务，前台服务是指带有通知栏的服务，如果我们使用startForegroundService启动服务，那么必须在5秒内调用startForeground()显示一个通知栏，否则就会报错

2、明明调用startforeground了为什么还会报Context.startForegroundService() did not then call Service.startForeground()
首先看下启动IntentService的调用：

private void startInitService() {
Intent intent = new Intent(this, InitIntentService.class);
intent.setAction(“com.pxwx.student.action”);
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
startForegroundService(intent);
} else {
startService(intent);
}
}

在IntentService中的处理：

在onCreate方法中调用了startForeground方法

public class InitIntentService extends IntentService {

public InitIntentService() {
    super("InitIntentService");
}

@RequiresApi(api = Build.VERSION_CODES.O)
private Notification getNotification() {
    NotificationChannel channel = new NotificationChannel("init", "", NotificationManager.IMPORTANCE_LOW);
    NotificationManager manager = (NotificationManager) getSystemService(Context.NOTIFICATION_SERVICE);
    if (manager != null) {
        manager.createNotificationChannel(channel);
    }
    return new Notification.Builder(this, "init")
            .setContentTitle("")
            .setContentText("")
            .setAutoCancel(true)
            .setSmallIcon(com.pxwx.student.core.R.mipmap.small_icon)
            .build();
}

@Override
public void onCreate() {
    super.onCreate();
    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
        //notification ID must not be 0 
        startForeground(1,getNotification());
    }
}

@Override
protected void onHandleIntent(@Nullable Intent intent) {
    initThirdSDK();
}

onCreate方法中明明调用startforeground了为什么还会报Context.startForegroundService() did not then call Service.startForeground()？

分析：

1、启动IntentService服务在Application中执行了多次，IntentService在第二次启动时还未停止的话不知执行onCreate方法，但会走onStart()方法，所以在onStart()方法中也执行startforeground

@Override
public void onStart(@Nullable Intent intent, int startId) {
super.onStart(intent, startId);
//主要是针对后台保活的服务，如果在服务A运行期间，保活机制又startForegroundService启动了一次服务A，那么这样不会调用服务A的onCreate方法，只会调用onStart方法
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
startForeground(1,getNotification());
}
}

2、但是问题依旧存在，只是减少了该问题的发生，然后我又尝试了讲starttForeground方法放在了onHandleIntent中执行

@Override
protected void onHandleIntent(@Nullable Intent intent) {
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
startForeground(1,getNotification());
}
initThirdSDK();
}

3、但是问题依旧存在，只是又减少了该问题的发生，不能完全杜绝该问题的发生，具体分析下IntentService的特性：

a、IntentService如果第一次启动后，onhandleIntent没处理完，继续startService，不会再重新实例化这个Service了，而是将请求放到请求队列里，等待第一个处理完再处理第二个。这种情况下，只有一个线程在运行

b、、IntentService处理任务时是按请求顺序处理的，也就是一个接一个处理

3、 IntentService源码分析
1、首先看下IntentService的继承关系等声明信息：

public abstract class IntentService extends Service {
…
@WorkerThread
protected abstract void onHandleIntent(@Nullable Intent intent);
}

可以看出IntentService是继承自Service的抽象类，有个抽象方法onHandleIntent需要子类覆写，通过注解我们知道该方法的执行是在子线程中的。

2、其次看下IntentService中声明的字段

//volatile修饰，保证其可见性

//Service中子线程中的Looper对象
private volatile Looper mServiceLooper;
//与子线程中Looper关联的Hander对象
private volatile ServiceHandler mServiceHandler;
//与子线程HandlerThread相关的一个标识
private String mName;
//设置Service的标志位，根据它的值来设置onStartCommand的返回值
private boolean mRedelivery;

/**

• You should not override this method for your IntentService. Instead,
• override {@link #onHandleIntent}, which the system calls when the IntentService
• receives a start request.
• @see android.app.Service#onStartCommand
  */
  @Override
  public int onStartCommand(@Nullable Intent intent, int flags, int startId) {
  onStart(intent, startId);
  return mRedelivery ? START_REDELIVER_INTENT : START_NOT_STICKY;
  }

mRedelivery是来处理onStartCommand返回值的一个标志位参数，着重看下onStartCommand的返回值在Service中定义的几个类型：

public static final int START_CONTINUATION_MASK = 0xf;
public static final int START_STICKY_COMPATIBILITY = 0;
public static final int START_STICKY = 1;
public static final int START_NOT_STICKY = 2;
public static final int START_REDELIVER_INTENT = 3;
1
2
3
4
5
根据这几个类型的注释，可以翻译解释：

START_STICKY_COMPATIBILITY：兼容模式，如果Service在创建后，被系统杀死，此时不能保证onStartCommand方法会被执行（可能会被执行，也可能不会被执行）；

START_STICKY：如果Service进程被kill掉，保留Service的状态为开始状态，但不保留递送的intent对象。随后系统会尝试重新创建Service，由于服务状态为开始状态，所以创建服务后一定会调用onStartCommand(Intent,int,int)方法。如果在此期间没有任何启动命令被传递到Service，那么参数Intent将为null；

START_NOT_STICKY：如果Service在启动后（从onStartCommand返回了）被系统杀掉了，在下一次调用Context.startService()之前，不会再创建Service。期间，也不接受空Intent参数的onStartCommand方法调用，因为空的Intent无法进行Service的创建；

START_REDELIVER_INTENT：在Service启动后，被系统杀掉了，将会重传最近传入的Intent到onStartCommand方法中对Service进行重建；

3、上边关于mRedelivery值控制onStartCommand的返回值的问题：

1、如果为true，则返回START_REDELIVER_INTENT，表示如果Service被系统杀死，可以进行重建并重传最近传入的Intent；

2、如果为false，则返回START_NOT_STICKY，表示如果Service被系统杀死，除非再次调用Context.startService()，不会对Servcie进行重建；

3、在Service被销毁的时候，会停止子线程的消息队列；

4、ntentService中还有一个设置mRedelivery的setter方法

4、总结分析：
从IntentService的源码分析看，导致android.app.RemoteServiceException Context.startForegroundService() did not then call Service.startForeground()：异常发生的原因：

1、onStartCommand返回值的一个标志位参数默认是START_NOT_STICKY

2、如果Service在启动后（从onStartCommand返回了）被系统杀掉了，在下一次调用Context.startService()之前，不会再创建Service。期间，也不接受空Intent参数的onStartCommand方法调用，因为空的Intent无法进行Service的创建；

3、导致Context.startForegroundService() did not then call Service.startForeground()的原因可能是被系统杀掉了，未执行IntentService的onCreate、onStart、onHandleIntent方法中的startForeground方法

二、JobIntentService替代IntentService方案
综合上面的分析，没有能完全解决上面的异常情况，该如何解决呢？

通过IntentService源码中针对IntentService的部分注释如下：

• Note: IntentService is subject to all the

• background execution limits
• imposed with Android 8.0 (API level 26). In most cases, you are better off
• using {@link android.support.v4.app.JobIntentService}, which uses jobs
• instead of services when running on Android 8.0 or higher.

翻译一下：

IntentService受Android 8.0（API级别26）的所有后台执行限制的约束。在大多数情况下，在Android 8.0或更高版本上运行时您最好使用android.support.v4.app.JobIntentService而不是服务。

1、JobIntentService介绍
JobIntentService是Android 8.0 新加入的类，它也是继承自Service，根据官方的解释：

Helper for processing work that has been enqueued for a job/service. When running on Android O or later, the work will be dispatched as a job via JobScheduler.enqueue. When running on older versions of the platform, it will use Context.startService.

大概翻译一下：

JobIntentService用于执行加入到队列中的任务。对Android 8.0及以上的系统，JobIntentService的任务将被分发到JobScheduler.enqueue执行，对于8.0以下的系统，任务仍旧会使用Context.startService执行。

2、JobIntentService使用
1、在Manifest中声名Permission：

1 2、在Manifest中声名Service： 1 3、实现JobIntentService类：

public class InitIntentService extends JobIntentService {

public static final int JOB_ID = 1;

public static void enqueueWork(Context context, Intent work) {
    enqueueWork(context, InitIntentService.class, JOB_ID, work);
}

@Override
protected void onHandleWork(@NonNull Intent intent) {
    // 具体逻辑
}

}

4、调用启动实现JobIntentService

InitIntentService.enqueueWork(context, new Intent());
1
JobIntentService不需要关心JobIntentService的生命周期，不需要startService()方法，也就避免了开头中的crash问题，通过静态方法就可以启动，还是非常不错的。