JobService源码探究之 onStartJob()里执行耗时逻辑导致Job可能被强制销毁

在上篇 《JobService源码探究之 onStartJob()里如何优雅地处理耗时逻辑?》里我们留下了如下两个疑问。
在本篇里一一解答。

疑问一

为什么onStartJob()直接执行耗时逻辑后，即便自己没有finish该Job，但是Job还是会被自动销毁？

疑问二

为什么onStartJob()里开启新线程执行的耗时逻辑超过10min，但是Job被自动停止和销毁？


这两个疑问的有如下区别：

耗时逻辑所属的线程

疑问一 UI线程
疑问二 后台线程

Job最后的结果

疑问一 被自动销毁
疑问二 被自动停止和销毁

但他们之间也存在共同点，就是都是某种程度上的超时。

疑问一 onStartJob()耗时，导致本函数没有及时执行结束，属于onStartJob()回调超时。
疑问二 onStartJob()并没有耗时，但是Job的后台任务执行时间过长，属于Job执行超时。


我们看看这两种情况下系统输出的Log。

疑问一

JobServiceContext: No response from client for onStartJob ef7724f #u0a174/0 com.example.timeapidemo/.EllisonsJobService

疑问二

JobServiceContext( 1433): Client timed out while executing (no jobFinished received), sending onStop: 5673577 #u0a174/0 com.example.timeapidemo/.EllisonsJobService

按照上述log，我们检索源码得知，这两句话出自如下函数。

frameworks/base/services/core/java/com/android/server/job/JobServiceContext.java

    private void handleOpTimeoutLocked() {
        switch (mVerb) {
            ...
            case VERB_STARTING:
                // Client unresponsive - wedged or failed to respond in time. We don't really
                // know what happened so let's log it and notify the JobScheduler
                // FINISHED/NO-RETRY.
                Slog.w(TAG, "No response from client for onStartJob " +
                        mRunningJob != null ? mRunningJob.toShortString() : "<null>");
                closeAndCleanupJobLocked(false /* needsReschedule */, "timed out while starting");★1
                break;
            ...
            case VERB_EXECUTING:
                // Not an error - client ran out of time.
                Slog.i(TAG, "Client timed out while executing (no jobFinished received), " +
                        "sending onStop: "  +
                        mRunningJob != null ? mRunningJob.toShortString() : "<null>");
                mParams.setStopReason(JobParameters.REASON_TIMEOUT);
                sendStopMessageLocked("timeout while executing");★2
                break;
            ...
        }
    }

★1可以看到当Job处在STARTING状态的时候发生超时的话，系统将直接去执行JobService的结束处理，这里面会去解绑JobService并销毁。


★2可以看到当Job处在EXECUTING状态的时候发生超时的话，系统将直接去执行JobService的停止处理，之后再去执行JobService的结束处理。


检索handleOpTimeoutLocked()的调用，发现是内部类JobServiceHandler调用的。

    private class JobServiceHandler extends Handler {
        ...

        @Override
        public void handleMessage(Message message) {
            switch (message.what) {
                case MSG_TIMEOUT:
                    synchronized (mLock) {
                        if (message.obj == mRunningCallback) {
                            handleOpTimeoutLocked();
                        }...
                    }
                ...
            }
        }
    }

检索MSG_TIMEOUT msg发出的地方，如下：

    private void scheduleOpTimeOutLocked() {
        ...
        final long timeoutMillis;
        switch (mVerb) {
            case VERB_EXECUTING:
                timeoutMillis = EXECUTING_TIMESLICE_MILLIS; // 10mins
                break;

            case VERB_BINDING:
                timeoutMillis = OP_BIND_TIMEOUT_MILLIS; // 18s
                break;

            default:
                timeoutMillis = OP_TIMEOUT_MILLIS; // 8s
                break;
        }

        Message m = mCallbackHandler.obtainMessage(MSG_TIMEOUT, mRunningCallback);
        mCallbackHandler.sendMessageDelayed(m, timeoutMillis);
        mTimeoutElapsed = SystemClock.elapsedRealtime() + timeoutMillis;
    }

检索scheduleOpTimeOutLocked()调用的地方，我们发现如下场合的时候都会调用该方法发送一定时间的延时MSG。


●executeRunnableJob() JobService刚开始绑定的时候，发送18s的延时MSG


●handleServiceBoundLocked() 回调JobService的onStartJob()的时候，发送8s的延时MSG


●handleStartedLocked() JobService的onStartJob()回调成功后，发送10mins的延时MSG


●sendStopMessageLocked() 回调JobService的onStopJob()的时候，发送8s的延时MSG


以上可以看出。

疑问一的原因是

onStartJob()没有及时在8s内完成回调，导致JobScheduler自行销毁了该JobService。
而且这时候JobScheduler在结束该Job的时候设置needsReschedule为false，所以这种情况下被销毁了的Job无法自启动。

疑问二的原因是

onStartJob()回调后没有在10mins内调用JobFinished方法通知JobScheduler，导致JobScheduler强制停止了该JobService。


到这里，上面两个疑问都解答了。


我们不禁得到如下启发：

启发一

如果非得在onStartJob()里执行任务逻辑的话，请不要超过8s。

启发二

如果在onStartJob()里已经开启了线程执行任务逻辑，但是处理时间尽量控制在10mins内。