我们永远都需要流畅的用户体验，但很遗憾我们手上的硬件资源却总是和这个需求唱反调。这也是 Android 平台不断努力的切入点——从 API 26开始，Android 对后台服务引入了严格的限制。基本上，除非您的应用在前台运行， 否则系统将在几分钟内停止应用的所有后台服务。
由于对后台服务的这些限制，JobScheduler 已经成为执行后台任务的实际解决方案。对于熟悉服务的开发者来说，JobScheduler 使用起来通常很简单，当然也存在少量例外。我们这次就来探讨其中一个例外。
假如您正在搭建一个 Android TV 应用。频道对电视应用非常重要，因此您的应用需要能够执行至少五种与频道有关的后台操作：发布频道，向频道添加节目，将有关频道的日志发送到远程服务器，更新频道的元数据，以及删除频道。在 Android 8.0（Oreo）之前，这五个操作中的每一个都可以在后台服务中实现。然而，从 API 26 开始，您必须明智地决定，哪些应该沿用原有的普通后台 Service，哪些应该使用 JobService。
如果只考虑电视 App 的使用场景，上述五个操作里，其实只有 “频道发布” 可以做成一个原有的普通后台服务。在某些场合下，频道发布涉及三个步骤：首先用户单击按钮开始该过程; 然后，应用启动后台操作来创建和提交出版物; 最后，用户通过用户界面以确认订阅。至此您可以看到，发布频道需要用户交互，因此需要可见的 Activity。所以，ChannelPublisherService 可以是一个 IntentService，负责处理后台逻辑。您不应该在这里使用 JobService，因为 JobService 会引入延迟，而用户交互通常需要您的应用进行即时响应。
对于其他四个操作，您应该使用 JobService; 因为它们都可以在您的应用位于后台时执行。所以您应该分别创建 ChannelProgramsJobService，ChannelLoggerJobService，ChannelMetadataJobService，和 ChannelDeletionJobService。
避免 JobId 冲突
由于以上所有的四个 JobService 都在处理 Channel 对象，您似乎可以方便地使用 channelId 作为 jobId。但是由于 JobService 在 Android Framework 中设计的方式，您不能这样做。以下是 jobId 的官方描述：
应用为这个作业提供的 ID。 随后调用取消，或创建相同 jobId 的作业，将会更新已经存在的同一个 ID 的作业。该 ID 在同一个 uid 的所有客户端（不只是同一个应用包）中必须是唯一的。您需要确保该 ID 在应用更新时始终保持稳定，因此它可能不应该基于资源 ID。
根据以上的描述，即使您使用 4 个不同的 Java 对象（即 -JobService），也仍然不能使用 channelId来作为它们的 jobId。类级别的命名空间不能帮助到您。
这确实是个问题。您需要一个稳定、可扩展的方式来将 channelId 和它的 jobId 关联起来。而最糟的结果莫过于，由于 jobId 冲突，导致不同的频道互相覆盖操作。如果jobId 是 String 类型，而不是 Integer 类型的话，解决起来就很容易：ChannelProgramsJobService 的 jobId = "ChannelPrograms" + channelId, ChannelLoggerJobService 的 jobId = "ChannelLogs" + channelId，等等。但因为 jobId属于 Integer 类型，而不属于 String 类型，所以您就要设计一个智能的系统，用来为您的作业生成可重复使用 jobId。
重点来了 —— 现在我们来聊聊 JobIdManager，看怎样用它来解决这个问题。
JobIdManager 是一个类别，您可以根据自己的应用需求进行调整。对于目前谈到的这个电视应用，基本构想是：使用一个 channelId 处理与 Channel 相关的所有作业 。下面我们先来看看这个样本 JobIdManager 类的代码 ，然后再详细讨论。
public class JobIdManager {
public static final int JOB_TYPE_CHANNEL_PROGRAMS = 1;
public static final int JOB_TYPE_CHANNEL_METADATA = 2;
public static final int JOB_TYPE_CHANNEL_DELETION = 3;
public static final int JOB_TYPE_CHANNEL_LOGGER = 4;
public static final int JOB_TYPE_USER_PREFS = 11;
public static final int JOB_TYPE_USER_BEHAVIOR = 21;
@IntDef(value = { JOB_TYPE_CHANNEL_PROGRAMS,
JOB_TYPE_CHANNEL_METADATA,
JOB_TYPE_CHANNEL_DELETION,
JOB_TYPE_CHANNEL_LOGGER,
JOB_TYPE_USER_PREFS,
JOB_TYPE_USER_BEHAVIOR })
@Retention(RetentionPolicy.SOURCE)
public @interface JobType { }
//16-1 for short. Adjust per your needs private static final int JOB_TYPE_SHIFTS = 15;
public static int getJobId(@JobType int jobType, int objectId) {
if ( 0 < objectId && objectId < (1<< JOB_TYPE_SHIFTS) ) {
return (jobType << JOB_TYPE_SHIFTS) + objectId;
} else {
String err = String.format("objectId %s must be between %s and %s", objectId,0,(1<如您所见，JobIdManager 只需结合一个前缀和 channelId 即可获得 jobId。然而这种简单优雅的解决方案只是冰山一角。我们来考虑一下假设条件和注意事项。
您必须能够强制 channelId 成为一个 Short 类型，所以当您将 channelId 与一个前缀结合后，您仍然会得到一个有效的 Java Integer。当然，严格来说，它不一定是 Short。只要您的前缀和 channelId 组合成一个不溢出的 Integer，它就能有效运作。但边际处理在坚实的软件工程中至关重要。所以，除非您真的走投无路，否则就强制为 Short 类型吧。在实践中，为远程服务器上具有较大 ID 的对象执行此操作的一种方法是，在本地数据库或 content provider 中定义一个密钥，并使用该密钥生成您的jobId。
您的整个应用只应该有一个 JobIdManager 类。该类可以为应用的所有作业生成 jobId：无论这些工作是否与频道、用户或者其他任何事情有关。事实上我们的示例 JobIdManager 类指出了这一点：并不是所有 JOB_TYPE 都与 Channel 操作有关。一个作业类型与用户偏好有关，一个与用户行为有关。JobIdManager 通过为每个作业类型分配一个不同的前缀来覆盖以上种类型。
您的应用中的每个 -JobService，都必须拥有唯一和最终的 JOB_TYPE_ 前缀。再强调一次，必须是彻底的一对一关系。
使用 JobIdManager
以下代码片段摘自 ChannelProgramsJobService，它为我们演示了如何在您的项目中使用 JobIdManager。无论何时需要安排新作业，都会使用 JobIdManager.getJobId(…) 生成 jobId。
import android.app.job.JobInfo;
import android.app.job.JobParameters;
import android.app.job.JobService;
import android.content.ComponentName;
import android.content.Context;
import android.os.PersistableBundle;
public class ChannelProgramsJobService extends JobService {
private static final String CHANNEL_ID = "channelId";
. . public static void schedulePeriodicJob(Context context,
final int channelId,
String channelName,
long intervalMillis,
long flexMillis)
{
JobInfo.Builder builder = scheduleJob(context, channelId);
builder.setPeriodic(intervalMillis, flexMillis);
JobScheduler scheduler =
(JobScheduler) context.getSystemService(Context.JOB_SCHEDULER_SERVICE); if (JobScheduler.RESULT_SUCCESS != scheduler.schedule(builder.build())) {
//todo what? log to server as analytics maybe?
Log.d(TAG, "could not schedule program updates for channel " + channelName);
}
}
private static JobInfo.Builder scheduleJob(Context context,final int channelId){
ComponentName componentName =
new ComponentName(context, ChannelProgramsJobService.class);
final int jobId = JobIdManager
.getJobId(JobIdManager.JOB_TYPE_CHANNEL_PROGRAMS, channelId);
PersistableBundle bundle = new PersistableBundle();
bundle.putInt(CHANNEL_ID, channelId);
JobInfo.Builder builder = new JobInfo.Builder(jobId, componentName);
builder.setPersisted(true);
builder.setExtras(bundle); builder.setRequiredNetworkType(JobInfo.NETWORK_TYPE_ANY); return builder;
}
...
}
相信看到这里，您对如何针对不同的场景来设计后台机制有了比较清晰的认识。但不管怎样，从 Oreo 开始对后台任务做出的种种限制都会对提升用户体验有着现实的意义，这也要求开发者们对自己的应用需要完成以及何时需要完成一些事情有着更精准的规划。如果您有什么问题，或者经验之谈，欢迎在下面和我们分享哦～
- 注：感谢 Christopher Tate 和 Trevor Johnsz 在本文撰写中提供的宝贵反馈意见
