我目前正在开发一个应用程序，无论发生什么情况，该应用程序都需要在特定的时间运行特定的作业-设备重新启动，更改本地时间，更新应用程序等等。该时间以秒为单位从服务器获取。因此，当我收到该值时，我将使用与此类似的代码创建一个工作
ComponentName componentName = new ComponentName(context, MyJobService.class);
JobInfo.Builder builder = new JobInfo.Builder(jobId, componentName);
builder.setMinimumLatency(secondsFromApi * 1000);
builder.setOverrideDeadline(secondsFromApi * 1000);
builder.setPersisted(true);
JobScheduler scheduler = context.getSystemService(JobScheduler.class);
scheduler.schedule(builder.build());
一切正常，即使我重新启动设备，作业也会在预期的时间触发。但是，当我在重新启动之前手动更改设备时间时，事情会变得混乱。想象一下这样的情况，我创建了一个可以在120秒内运行的作业，然后转到设备设置，将时间改回几个小时，然后关闭设备。然后，我等待了一段时间（大于120秒），使情况变得更加极端，我打开了设备。不幸的是，这项工作无法进行。如果我不更改时间并重新启动电话，等待5分钟然后重新打开，则该作业将在启动后大约一分钟触发，很可能是在操作系统完成时执行的强制性操作，并继续执行挂起的作业并找到并执行我的
根据上一个示例的逻辑，我的假设是JobScheduler在设备离线时实际上并未倒计时。相反，当我尝试关闭设备时，很可能会计算出要触发的作业还有多少毫秒，它将记录设备重启的时间并存储该值。当我重启设备时，它将获取当前时间并添加剩余的毫秒数并重新安排作业。在这种情况下，如果设备时间与最初计划作业的时间不同，则重新启动后，作业将触发得太晚（如果将时间向后更改）或触发得太早（如果将时间更改为将来时间） ）。
所以，总结一下，我的观点引起了几个问题