JobScheduler系统源码分析

• 纯个人笔记，不结合源码，你完全可能看不懂

类

• JobSchedulerService:
  系统服务， 性质同AMS, WMS等。
• JobSchedulerService.mControllers:
  几种状态控制器，监听电池、屏幕、用户变动等消息。最早从广播触发，交由它来处理。
• JobScheduler：
  抽象类，给接口给APP用，直接实现是JobSchedulerImpl。
• JobSchedulerImpl:
  系统远程服务JobSchedulerService的客户端，给APP调用，提交、取消Job都通过它。

流程：

• 初始化
  JobSchedulerService.onBootPhase() ：
  //一开机，就初始化批处理的执行环境
  //每个JobService的执行状态，上下文，沟通，都在这个类JobServiceContext的实例里来处理，JobSchedulerService负责排队机制，然后丢给它们，来具体执行任务。当然，这是开机时，初始化而已，还没任务进来。
  mActiveServices.add( new JobServiceContext(this, mBatteryStats, getContext().getMainLooper()));

• 任务添加与执行：
  JobScheduler.schedule() --> JobSchedulerService.schedule() -->startTrackingJob() 提交任务信息给相交的处理器，

比如，空闲控制器，当系统空闲时，处理任务。
IdleController.IdlenessTracker --> startTracking() ,
注册广播监听，监听ACTION_SCREEN_ON、ACTION_SCREEN_OFF等消息，来获得系统空闲状态。
比如，
广播onReceive中，得到空闲状态 ACTION_TRIGGER_IDLE
--> reportNewIdleState()， 报告空闲状态，开始安排需要在空闲状态处理的任务
--> 监听机制，onControllerStateChanged， 实现者是JobSchedulerService
--> JobSchedulerService.onControllerStateChanged --> MSG_CHECK_JOB， 发消息给自己的线程，去处理，
---> maybeQueueReadyJobsForExecutionLockedH, 任务排队处理， 分类，丢到各类的mPendingJobs里
---> maybeRunPendingJobsH，一个个任务处理，这里涉及新的mPendingJobs与已经提交过的，甚至放在mActiveServices里的任务，进行过滤，匹配的问题。略过。
反正，最终，要执行的任务信息，都丢进 mActiveServices
-->mActiveServices.get(i).executeRunnableJob
--> JobServiceContext.executeRunnableJob()
这是直正执行任务的地方，通过远程bindService的方式，来启动JobService的实例，显然，如果你的应用挂了，service没起来，它会自动创建起来。
这里丢进去的是this, 也就是创建成功，会执行本实例的JobServiceContext.onServiceConnected。
在里面你就可以看到，会发消息去让自己处理，最终远程调用JobService.startJob();等，
最终下调到你的JobService.onStartJob().等。
final Intent intent = new Intent().setComponent(job.getServiceComponent());
boolean binding = mContext.bindServiceAsUser(intent, this,
Context.BIND_AUTO_CREATE | Context.BIND_NOT_FOREGROUND,
new UserHandle(job.getUserId()));