JobService源码探究之 Job自行Cancel后即使onStopJob返回true也不会被再启动

最新推荐文章于 2023-11-07 00:16:58 发布

TechMerger

最新推荐文章于 2023-11-07 00:16:58 发布

阅读量1.8k

点赞数 1

分类专栏： Android JobService 文章标签： Android JobService JobScheduler Service

本文链接：https://blog.csdn.net/allisonchen/article/details/79262316

版权

Android 同时被 2 个专栏收录

90 篇文章 19 订阅

订阅专栏

JobService

6 篇文章 4 订阅

订阅专栏

上章节遗留的疑问二，本章将继续探究缘由。

疑问二

自行cancel了JobService后，onStopJob()即使返回true也不能被重新启动？

照例直接上源码。
cancel是IJobScheduler的API，我们直接查看该API的实现。

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

public final class JobSchedulerService extends com.android.server.SystemService
        implements StateChangedListener, JobCompletedListener {
    ...
    final class JobSchedulerStub extends IJobScheduler.Stub {
        ...
        @Override
        public void cancel(int jobId) throws RemoteException {
            final int uid = Binder.getCallingUid();
            long ident = Binder.clearCallingIdentity();
            try {
                JobSchedulerService.this.cancelJob(uid, jobId);★1
            }...
        }
    }
    ...
    public void cancelJob(int uid, int jobId) {
        JobStatus toCancel;
        synchronized (mLock) {
            toCancel = mJobs.getJobByUidAndJobId(uid, jobId); // 从JobStore中获取指定UID下的指定ID的JobStatus
            if (toCancel != null) {
                cancelJobImplLocked(toCancel, null, "cancel() called by app");★2
            }
        }
    }
    ...
    private void cancelJobImplLocked(JobStatus cancelled, JobStatus incomingJob, String reason) {

        cancelled.unprepareLocked(ActivityManager.getService());
        stopTrackingJobLocked(cancelled, incomingJob, true /* writeBack */); // 从JobStore中移除该Job的追踪记录
        // Remove from pending queue.
        if (mPendingJobs.remove(cancelled)) {// 从运行中JobStatus列表中移除该Job
            mJobPackageTracker.noteNonpending(cancelled);
        }
        // Cancel if running.
        stopJobOnServiceContextLocked(cancelled, JobParameters.REASON_CANCELED, reason);★3 即将执行Job停止处理
        reportActiveLocked();
    }
    ...
    private boolean stopJobOnServiceContextLocked(JobStatus job, int reason, String debugReason) {
        for (int i=0; i<mActiveServices.size(); i++) {
            JobServiceContext jsc = mActiveServices.get(i);
            final JobStatus executing = jsc.getRunningJobLocked();
            if (executing != null && executing.matches(job.getUid(), job.getJobId())) {
                jsc.cancelExecutingJobLocked(reason, debugReason);★4告诉JobServiceContext去停止该Job
                return true;
            }
        }
        return false;
    }
}

我们继续看看JobServiceContext具体做了什么处理。

public final class JobServiceContext implements ServiceConnection {
    ...
    void cancelExecutingJobLocked(int reason, String debugReason) {
        doCancelLocked(reason, debugReason);★1
    }
    ...
    void doCancelLocked(int arg1, String debugReason) {
        ...
        mParams.setStopReason(arg1);// 设置REASON_CANCELED作为停止Job原因
        if (arg1 == JobParameters.REASON_PREEMPT) {
            mPreferredUid = mRunningJob != null ? mRunningJob.getUid() :
                    NO_PREFERRED_UID;
        }
        handleCancelLocked(debugReason);★2
    }
    ...
    private void handleCancelLocked(String reason) {
        ...
        switch (mVerb) {
            case VERB_BINDING:
            case VERB_STARTING:
                mCancelled = true;
                applyStoppedReasonLocked(reason);★3-1 如果JobService还未执行走这个处理
                break;
            case VERB_EXECUTING:
                sendStopMessageLocked(reason);★3-2 如果JobService已经执行走这个处理
                break;
               ...
        }
    }

    // 假设JobService已经执行，那直接走到这
    private void sendStopMessageLocked(String reason) {
        removeOpTimeOutLocked();
        ...
        try {
            mVerb = VERB_STOPPING;//将Job状态置为VERB_STOPPING
            scheduleOpTimeOutLocked();
            service.stopJob(mParams);★4 IPC调用JobService的onStopJob()
        }...
    }
}

同样的JobServcie处理完onStopJob()后会将返回值通过IJobCallback会发给JobServiceContext。

public abstract class JobServiceEngine {
    static final class JobInterface extends IJobService.Stub {
        ...
        public void stopJob(JobParameters jobParams) throws RemoteException {
            JobServiceEngine service = mService.get();
            if (service != null) {
                Message m = Message.obtain(service.mHandler, MSG_STOP_JOB, jobParams);★1
                m.sendToTarget();
            }
        }
    }
    ...
    class JobHandler extends Handler {
        ...
        @Override
        public void handleMessage(Message msg) {
            final JobParameters params = (JobParameters) msg.obj;
            switch (msg.what) {
                case MSG_STOP_JOB:
                    try {
                        boolean ret = JobServiceEngine.this.onStopJob(params);★2
                        ackStopMessage(params, ret);★3
                    }...
                ...
            }
        }
    }
    ...
    private void ackStopMessage(JobParameters params, boolean reschedule) {
        final IJobCallback callback = params.getCallback();
        final int jobId = params.getJobId();
        if (callback != null) {
            try {
                callback.acknowledgeStopMessage(jobId, reschedule);★4
            }...
        }...
   }
}

我们假设onStopJob()返回的是true，那么★4传给JobServiceContext的reschedule就是true。

再次回到JobServiceContext。

public final class JobServiceContext implements ServiceConnection {
    ...
    final class JobCallback extends IJobCallback.Stub {
        @Override
        public void acknowledgeStopMessage(int jobId, boolean reschedule) {
            doAcknowledgeStopMessage(this, jobId, reschedule);★1
        }
        ...
    }
    ...
    void doAcknowledgeStopMessage(JobCallback cb, int jobId, boolean reschedule) {
        doCallback(cb, reschedule, null);★2
    }
    ...
    void doCallback(JobCallback cb, boolean reschedule, String reason) {
        final long ident = Binder.clearCallingIdentity();
        try {
            synchronized (mLock) {
                if (!verifyCallerLocked(cb)) {
                    return;
                }
                doCallbackLocked(reschedule, reason);★3 此刻的reschedule为true
            }
        }...
    }
    ...
    void doCallbackLocked(boolean reschedule, String reason) {
        ...
        removeOpTimeOutLocked();//在这里移除回调onStopJob时发送的8s延时msg

        if (mVerb == VERB_STARTING) {
            handleStartedLocked(reschedule);
        } else if (mVerb == VERB_EXECUTING ||
                mVerb == VERB_STOPPING) {
            handleFinishedLocked(reschedule, reason);★4 此刻状态为STOPPING,调用finish逻辑
        }...
    }
    ...
    private void handleFinishedLocked(boolean reschedule, String reason) {
        switch (mVerb) {
            case VERB_EXECUTING:
            case VERB_STOPPING:
                closeAndCleanupJobLocked(reschedule, reason);★5 
                break;
            ...
        }
    }
    ...
    private void closeAndCleanupJobLocked(boolean reschedule, String reason) {
        ...
        applyStoppedReasonLocked(reason);
        completedJob = mRunningJob;
        mJobPackageTracker.noteInactive(completedJob);
        ...
        if (mWakeLock != null) {
            mWakeLock.release();//释放WakeLock
        }
        mContext.unbindService(JobServiceContext.this);★6告诉AMS解绑该JobService,最终会调到它的onDestroy()
        mWakeLock = null;
        mRunningJob = null;
        mRunningCallback = null;
        mParams = null;
        mVerb = VERB_FINISHED;// 将Job状态置为VERB_FINISHED
        mCancelled = false;
        service = null;
        mAvailable = true;
        removeOpTimeOutLocked();
        mCompletedListener.onJobCompletedLocked(completedJob, reschedule); ★7 将结束的Job当作参数调用结束后回调处理
    }
    ...
    public void onJobCompletedLocked(JobStatus jobStatus, boolean needsReschedule) {
        ...
        final JobStatus rescheduledJob = needsReschedule
                ? getRescheduleJobForFailureLocked(jobStatus) : null; // 从结束的Job中复制出新的JobStatus
        ...
        // 从JobStore中移除原有Job的追踪记录，因为之前的JobStatus在cancel的时候已经从JobStore中移除了。所以本函数返回false
        // 然后发送MSG_CHECK_JOB_GREEDY的msg
        if (!stopTrackingJobLocked(jobStatus, rescheduledJob, !jobStatus.getJob().isPeriodic())) {
            ...
            mHandler.obtainMessage(MSG_CHECK_JOB_GREEDY).sendToTarget();★8
            return;
        }
        ...
    }

    final private class JobHandler extends Handler {
        ...
        @Override
        public void handleMessage(Message message) {
            synchronized (mLock) {
                ...
                switch (message.what) {
                    ...
                    case MSG_CHECK_JOB_GREEDY:
                        queueReadyJobsForExecutionLocked();★9 将准备好执行的Jobs排入队列
                        break;
                    ...
                }
                maybeRunPendingJobsLocked(); ★10 轮循mPendingJobs准备执行JobService
                ...
            }
        }
    }

    private void queueReadyJobsForExecutionLocked() {
        ...
        // ★9－1 遍历通过JobStore中存储的所有Job，然后回调ReadyQueueFunctor添加Job到ReadyJobQueueFunctor中
        mJobs.forEachJob(mReadyQueueFunctor);
        
        // 将ReadyJobQueueFunctor中保存的jobs列表添加到待执行列表mPendingJobs中
        mReadyQueueFunctor.postProcess();
    }
}

执行cancel处理的时候已经从JobStore里移除了原有的JobStatus对象，
同时在发送MSG_CHECK_JOB_GREEDY前有没有将新的JobStatus对象保存到JobStore中。

所以★9－1在遍历存储的Jobs时候，并不会将新的JobStatus插入到待执行队列里。
进而导致★10的时候不会重新执行该JobService。

那为什么发生条件不满足时候Job被强制停止后能再度启动呢？
查看源码我们知道。

比如设备进入IDLE状态的时候，JobSchedulerService直接通知JobServiceContext去取消没有设置IDLE条件下运行的Job。
而并没有事先去JobStore理移除该Job。

等到JobServiceContext成功停止了该Job后。
JobSchedulerService在执行Job结束的回调(onJobCompletedLocked)时，将会把JobStore里保存的原有JobStatus移除，然后添加为新创建的JobStaus。

这样一来在MSG_CHECK_JOB_GREEDY的msg响应的时候，新的Job就可以得到执行。

到这里，疑问二就解决了。

下次我们探讨下之前遗留的两个思考以及一个总结。