共计 1184 个字符，预计需要花费 3 分钟才能阅读完成。
Android 12 (API 级别为 31) 引入了 前台服务启动限度。除少部分 非凡场景 外，如果您的利用的 targetSdkVersion 是 Android 12 或者更高 API 级别的话，利用在后盾运行时将不能再启动前台服务。这意味着，如果利用以后状态不合乎后盾启动服务的条件，调用 setForeground) 时可能会抛出 异样。
因而，咱们在 WorkManager 2.7 中做出了局部改良，使得利用在恪守后盾限度的同时能够轻松地安顿重要工作。通过 加急工作，利用能够轻松地运行 耗时短且高优先级的工作 ，例如发送一条聊天信息或者往社交网络上传一张图片。举荐应用加急工作来启动须要立刻执行且即便用户将利用放至后盾也能继续执行的工作。
如需设置加急工作，可通过 WorkRequest 的 Builder 对象调用 setExpedited() 办法:
val request = OneTimeWorkRequestBuilder<HighPriorityWorker>()
.setExpedited(OutOfQuotaPolicy.RUN_AS_NON_EXPEDITED_WORK_REQUEST)
.build()
WorkManager.getInstance(context).enqueue(request)通过调用 setExpedited() 通知框架该工作是重要的并且比其余工作具备更高的优先级。请留神，咱们在调用 setExpedited() 办法时传入了 OutOfQuotaPolicy 参数。加急工作受基于 利用待机群组 (App Standby Buckets) 的配额限度，当您的利用尝试在超出配额的状况下执行加急工作时，WorkManager 会依据 OutOfQuotaPolicy 参数做出相应的行为: 齐全放弃加急工作申请 (DROP_WORK_REQUEST)，或者将该加急工作降级至一般工作 (RUN_AS_NON_EXPEDITED_WORK_REQUEST)。加急工作很重要，但并不意味着它能够始终执行，您须要将配额视为执行加急工作的工夫限度。
WorkManager 2.7 是向后兼容的，能够在 Android 12 之前的零碎上运行。当在 Android 11 或之前版本的零碎上调用 setExpedited() 时，WorkManager 将默认应用前台服务代替加急工作。
想理解 WorkManager 中 setExpedited() API 的 实战，请参阅官网 示例 和 文档。
您能够在官网公布阐明中查看 WorkManager 每个版本中变更及优化的具体列表，以及 WorkManager 2.6 和 WorkManager 2.7 的公布阐明。
如果您有与 WorkManager 相干的任何性能需要或问题，欢送在咱们公开的问题追踪器里提交 issue。
欢迎您 点击这里 向咱们提交反馈，或分享您喜爱的内容、发现的问题。您的反馈对咱们十分重要，感谢您的反对！
