首页 › Android开发论坛 › Android WorkManager的概念和使用详细指南

鍾彬 發表於 2025-9-20 14:58:15

Android WorkManager的概念和使用详细指南

<div id="navCategory"><h5 class="catalogue">目录</h5><ul class="first_class_ul"><li>1. WorkManager基础与核心概念</li><ul class="second_class_ul"><li>1.1 WorkManager概述</li><li>1.2 核心设计目标</li><li>1.3 核心优势</li><li>1.4 典型适用场景</li></ul><li>2. 基础使用​</li><ul class="second_class_ul"><li>2.1 ​添加依赖</li><li>2.2 创建 Worker 类​</li><li>2.3 配置 WorkRequest​</li><li>2.4 提交任务​​</li></ul><li>3. Constraints有哪些方法 ?</li><ul class="second_class_ul"><li>3.1 设备状态约束 (Device State Constraints)</li><ul class="third_class_ul"><li>3.1.1 setRequiresCharging(requiresCharging: Boolean): Builder</li><li>3.1.2 setRequiresDeviceIdle(requiresDeviceIdle: Boolean): Builder</li><li>3.1.3 setRequiresBatteryNotLow(requiresBatteryNotLow: Boolean): Builder</li><li>3.1.4 setRequiresStorageNotLow(requiresStorageNotLow: Boolean): Builder</li></ul><li>3.2 网络约束 (Network Constraints)</li><ul class="third_class_ul"><li>3.2.1 setRequiredNetworkType(networkType: NetworkType): Builder</li><li>3.2.2 setRequiredNetworkRequest(networkRequest: NetworkRequest, networkType: NetworkType): Builder</li></ul><li>3.3 内容URI触发约束 (Content URI Triggers)</li><ul class="third_class_ul"><li>3.3.1 addContentUriTrigger(uri: Uri, triggerForDescendants: Boolean): Builder</li><li>3.3.2 setTriggerContentUpdateDelay(&hellip;) 与 setTriggerContentMaxDelay(&hellip;)</li></ul></ul><li>4. CoroutineWorker和Worker的区别</li><ul class="second_class_ul"><li>4.11基础架构与线程模型</li><ul class="third_class_ul"></ul><li>4.2资源消耗与并发能力</li><ul class="third_class_ul"></ul><li>4.3 CoroutineWorker和Worker的doWork方法中，需要单独启动一个IO线程再执行吗 ?</li><ul class="third_class_ul"><li>4.3.1 ​​Worker（传统 Java 线程模型）​</li><li>4.3.2 ​​CoroutineWorker（协程模型）​</li></ul></ul><li>5. PeriodicWorkRequestBuilder和OneTimeWorkRequestBuilder的区别</li><ul class="second_class_ul"><li>5.1 核心区别：执行模式</li><ul class="third_class_ul"></ul><li>5.2 高级配置差异</li><ul class="third_class_ul"></ul><li>5.3 OneTimeWorkRequestBuilder怎么使用</li><ul class="third_class_ul"><li>5.3.1 setBackoffCriteria中EXPONENTIAL和LINEAR的区别</li><li>5.3.2 setExpedited</li></ul></ul><li>6. WorkManager怎么取消任务</li><ul class="second_class_ul"><li>6.1 通过任务 ID 取消</li><ul class="third_class_ul"></ul><li>6.2 通过标签 (Tag) 取消</li><ul class="third_class_ul"></ul><li>6.3 取消唯一任务 (Unique Work)</li><ul class="third_class_ul"></ul><li>6.4 取消所有任务</li><ul class="third_class_ul"></ul><li>6.5 取消后的任务行为</li><ul class="third_class_ul"><li>6.5.1 通过workManager.getWorkInfosByTag，怎么判断是否有某个Work还未执行 ?</li></ul></ul><li>7. 更多内容</li><ul class="second_class_ul"></ul></ul></div><p class="maodian"></p><h2>1. WorkManager基础与核心概念</h2>
<p class="maodian"></p><h3>1.1 WorkManager概述</h3>
<p>WorkManager是Android Jetpack架构组件库的核心成员，专为管理<strong>可靠的后台任务</strong>而设计。它提供了一套统一的API，用于调度需保障执行的延迟型异步任务（如数据同步、日志上传），确保任务在应用退出甚至设备重启后仍能完成。作为Android平台推荐的后台任务调度框架，WorkManager平衡了系统资源限制与任务执行可靠性，成为替代传统方案（如AlarmManager、JobScheduler）的现代化解决方案。</p>
<p class="maodian"></p><h3>1.2 核心设计目标</h3>
<ul><li><strong>有保证的执行（Guaranteed Execution）</strong>：通过SQLite数据库持久化任务信息，即使应用进程被终止或设备重启，系统也会在满足条件后重新调度任务。</li><li><strong>机会性执行（Opportunistic Execution）</strong>：在设备资源充足时（如充电状态、空闲时段）立即执行任务，优化电池寿命与用户体验。</li><li><strong>跨版本兼容性</strong>：自动适配底层调度机制：<ul><li><strong>API &ge;23</strong>：使用<code>JobScheduler</code></li><li><strong>API 14-22</strong>：降级为<code>AlarmManager</code> + <code>BroadcastReceiver</code></li></ul></li></ul>
<p class="maodian"></p><h3>1.3 核心优势</h3>
<ul><li><strong>简化多线程管理</strong>：自动处理线程调度，开发者只需关注<code>Worker</code>中的业务逻辑。</li><li><strong>灵活的任务链</strong>：支持顺序或并行任务组合，例如&ldquo;下载&rarr;处理&rarr;上传&rdquo;工作流可通过<code>beginWith().then()</code>链式调用实现。</li><li><strong>智能约束系统</strong>：通过<code>Constraints.Builder</code>设置执行条件（如仅WiFi下执行），避免无效唤醒。</li></ul>
<p class="maodian"></p><h3>1.4 典型适用场景</h3>
<ul><li><strong>关键数据操作</strong>：用户数据同步、数据库备份（需保障执行）。</li><li><strong>资源敏感型任务</strong>：大文件上传（需<code>UNMETERED</code>网络约束）、图片处理（需设备空闲）。</li><li><strong>聚合执行场景</strong>：日志批量上报（周期性任务 + 弹性窗口<code>flexInterval</code>）。</li></ul>
<blockquote><p>⚠️ <strong>注意</strong>：WorkManager <strong>不适用</strong>于实时性要求高的任务（如即时通讯），此类场景需改用前台服务或推送机制。其核心价值在于为<strong>可延迟但必须完成</strong>的任务提供标准化、低能耗的调度框架。</p></blockquote>
<p class="maodian"></p><h2>2. 基础使用​</h2>
<p class="maodian"></p><h3>2.1 ​添加依赖</h3>
<p>在 build.gradle中添加依赖</p>
<div class="jb51code"><pre class="brush:java;">dependencies {
    implementation "androidx.work:work-runtime-ktx:2.9.1" // KTX 扩展支持协程
}</pre></div>
<p class="maodian"></p><h3>2.2 创建 Worker 类​</h3>
<p>继承 CoroutineWorker（推荐协程）或 Worker，重写 doWork()执行任务逻辑</p>
<div class="jb51code"><pre class="brush:java;">class UploadWorker(context: Context, params: WorkerParameters) : CoroutineWorker(context, params) {
    override suspend fun doWork(): Result {
      val url = inputData.getString("KEY_URL") ?: return Result.failure()
      try {
            performUpload(url) // 执行耗时操作
            return Result.success(workDataOf("RESULT" to "Success"))
      } catch (e: Exception) {
            return Result.retry() // 失败时重试
      }
    }
}​</pre></div>
<p class="maodian"></p><h3>2.3 配置 WorkRequest​</h3>
<p>​​一次性任务​​（OneTimeWorkRequest）</p>
<div class="jb51code"><pre class="brush:java;">val constraints = Constraints.Builder()
    .setRequiredNetworkType(NetworkType.CONNECTED) // 需联网
    .setRequiresCharging(true) // 需充电
    .build()
val uploadRequest = OneTimeWorkRequestBuilder&lt;UploadWorker&gt;()
    .setInputData(workDataOf("KEY_URL" to "https://example.com"))
    .setConstraints(constraints)
    .setInitialDelay(10, TimeUnit.MINUTES) // 延迟启动
    .build()</pre></div>
<p>周期性任务​​（PeriodicWorkRequest，​​最小间隔 15 分钟​​）</p>
<div class="jb51code"><pre class="brush:java;">val syncRequest = PeriodicWorkRequestBuilder&lt;SyncWorker&gt;(15, TimeUnit.MINUTES).build()</pre></div>
<p class="maodian"></p><h3>2.4 提交任务​​</h3>
<p>通过 WorkManager实例入队任务</p>
<div class="jb51code"><pre class="brush:java;">WorkManager.getInstance(context).enqueue(uploadRequest)</pre></div>
<p class="maodian"></p><h2>3. Constraints有哪些方法 ?</h2>
<p>以下方法都是 <code>Constraints.Builder</code> 类中的核心方法，用于为 WorkManager 的后台任务 (<code>WorkRequest</code>) 设置精确的执行条件</p>
<p>这些方法可以分为几大类：<strong>设备状态约束</strong>、<strong>网络约束</strong>和<strong>内容URI触发约束</strong>。</p>
<p class="maodian"></p><h3>3.1 设备状态约束 (Device State Constraints)</h3>
<p>这类方法确保任务只在设备处于特定状态下才执行，对省电和用户体验至关重要。</p>
<p class="maodian"></p><h4>3.1.1 setRequiresCharging(requiresCharging: Boolean): Builder</h4>
<ul><li><strong>作用</strong>：设置任务是否必须在设备<strong>充电时</strong>才能运行。</li><li><strong>参数</strong>：<code>requiresCharging</code> - 设为 <code>true</code> 表示必须充电。</li><li><strong>默认值</strong>：<code>false</code>（不要求充电）。</li><li><strong>使用场景</strong>：非常适合执行耗电量巨大的任务，例如大规模数据同步、备份或复杂的文件处理，可以避免在用户使用电池时消耗其电量。</li></ul>
<p class="maodian"></p><h4>3.1.2 setRequiresDeviceIdle(requiresDeviceIdle: Boolean): Builder</h4>
<ul><li><strong>作用</strong>：设置任务是否必须在设备<strong>空闲时</strong>才能运行。设备空闲通常指屏幕关闭一段时间且没有用户交互。</li><li><strong>参数</strong>：<code>requiresDeviceIdle</code> - 设为 <code>true</code> 表示必须设备空闲。</li><li><strong>默认值</strong>：<code>false</code>（不要求空闲）。</li><li><strong>API 要求</strong>：需要 Android 6.0 (API 级别 23) 或更高。</li><li><strong>使用场景</strong>：用于执行非常占用 CPU 或网络资源的密集型任务，确保不会在用户 actively 使用设备时造成卡顿或干扰。</li></ul>
<p>系统判定设备空闲需满足以下条件：</p>
<ul><li><strong>​​屏幕关闭</strong>​​：设备未处于亮屏状态。</li><li>​​<strong>无用户交互​​</strong>：用户未操作设备（如触摸、按键）持续 ​​&ge;30分钟​​。</li><li>​​<strong>无活跃进程</strong>​​：无前台应用或高优先级服务占用资源。</li></ul>
<p class="maodian"></p><h4>3.1.3 setRequiresBatteryNotLow(requiresBatteryNotLow: Boolean): Builder</h4>
<ul><li><strong>作用</strong>：设置任务是否必须在设备<strong>电量充足</strong>时才能运行。系统定义的&ldquo;低电量&rdquo;阈值通常约为 15%。</li><li><strong>参数</strong>：<code>requiresBatteryNotLow</code> - 设为 <code>true</code> 表示必须电量充足。</li><li><strong>默认值</strong>：<code>false</code>（不要求电量充足）。</li><li><strong>使用场景</strong>：用于非紧急的后台任务，避免在用户电量紧张时雪上加霜。可以和高优先度的通知任务结合，低电量时暂停普通同步。</li></ul>
<p class="maodian"></p><h4>3.1.4 setRequiresStorageNotLow(requiresStorageNotLow: Boolean): Builder</h4>
<ul><li><strong>作用</strong>：设置任务是否必须在设备<strong>存储空间充足</strong>时才能运行。避免在存储空间即将耗尽时执行可能写入文件的操作。</li><li><strong>参数</strong>：<code>requiresStorageNotLow</code> - 设为 <code>true</code> 表示必须存储空间充足。</li><li><strong>默认值</strong>：<code>false</code>（不要求存储空间充足）。</li><li><strong>使用场景</strong>：任何需要下载文件或缓存数据的任务，如下载更新、保存图片或日志文件等。</li></ul>
<p class="maodian"></p><h3>3.2 网络约束 (Network Constraints)</h3>
<p>这类方法控制任务执行所需的网络环境。</p>
<p class="maodian"></p><h4>3.2.1 setRequiredNetworkType(networkType: NetworkType): Builder</h4>
<ul><li><strong>作用</strong>：设置任务执行所需的<strong>基本网络类型</strong>。这是最常用的网络约束方法。</li><li><strong>参数</strong>：<code>networkType</code> - 枚举值，包括：<ul><li><code>NOT_REQUIRED</code>：不需要网络（默认值）。</li><li><code>CONNECTED</code>：设备有任何网络连接即可（Wi-Fi 或移动数据）。</li><li><code>UNMETERED</code>：需要不计流量的网络（如 Wi-Fi）。</li><li><code>METERED</code>：需要按流量计费的网络（如移动数据）。</li><li><code>NOT_ROAMING</code>：需要非漫游网络。</li></ul></li><li><strong>使用场景</strong>：<ul><li><code>UNMETERED</code>：用于下载大文件、更新应用、上传日志等大量数据传输操作。</li><li><code>CONNECTED</code>：用于轻量级的网络请求，如发送即时消息、获取小型配置更新等。</li><li><code>METERED</code>：用于需要明确使用移动数据的场景。</li></ul></li></ul>
<p class="maodian"></p><h4>3.2.2 setRequiredNetworkRequest(networkRequest: NetworkRequest, networkType: NetworkType): Builder</h4>
<ul><li><strong>作用</strong>：提供一个<strong>更高级、更精细</strong>的网络约束方式（基于 Android 的 <code>NetworkRequest</code> API）。它允许你指定更复杂的网络能力要求，例如带宽、延迟等。在较新的 Android 版本（API 28+）上使用此设置，在旧版本上会自动回退到您指定的 <code>networkType</code>。</li><li><strong>限制</strong>：不支持设置了 <code>NetworkSpecifier</code>（如指定特定 Wi-Fi SSID）或 <code>setIncludeOtherUidNetworks</code> 的请求，传入此类请求会抛出 <code>IllegalArgumentException</code>。</li><li><strong>API 要求</strong>：需要 Android 5.0 (API 级别 21) 或更高，但其高级功能在更高版本上才有效。</li><li><strong>使用场景</strong>：需要非常特定网络条件的专业应用，例如视频会议应用需要高上行带宽的网络，或游戏需要低延迟网络。</li></ul>
<p class="maodian"></p><h3>3.3 内容URI触发约束 (Content URI Triggers)</h3>
<p>这是一组非常强大的约束，允许任务在<strong>你关注的特定数据发生变化时</strong>被触发，类似于数据库的触发器。</p>
<p class="maodian"></p><h4>3.3.1 addContentUriTrigger(uri: Uri, triggerForDescendants: Boolean): Builder</h4>
<ul><li><strong>作用</strong>：添加一个要监听的<strong>内容提供者 (ContentProvider) 的 URI</strong>。当此 URI 代表的数据发生变化（插入、更新、删除）时，会触发任务运行。</li><li><strong>参数</strong>：<ul><li><code>uri</code>：要监听的内容 URI（例如 <code>content://media/external/images/media</code>）。</li><li><code>triggerForDescendants</code>：如果为 <code>true</code>，则监听该 URI <strong>及其所有子路径</strong>的变化；如果为 <code>false</code>，则只监听该精确 URI。</li></ul></li><li><strong>API 要求</strong>：需要 Android 7.0 (API 级别 24) 或更高。</li><li><strong>使用场景</strong>：<ul><li>监听媒体库的变化，当有新图片或视频时执行某些处理。</li><li>监听自定义 ContentProvider 的数据变化，实现数据驱动型的任务调度。</li></ul></li></ul>
<p class="maodian"></p><h4>3.3.2 setTriggerContentUpdateDelay(&hellip;) 与 setTriggerContentMaxDelay(&hellip;)</h4>
<ul><li><strong>作用</strong>：这两个方法用于控制<strong>触发延迟</strong>，以避免在数据频繁变化时任务被过于频繁地触发。
<ul><li><code>setTriggerContentUpdateDelay</code>：设置从<strong>检测到内容变化</strong>到<strong>调度任务</strong>之间的<strong>最小等待时间</strong>。如果在此期间内容再次变化，计时器会重置。</li><li><code>setTriggerContentMaxDelay</code>：设置从<strong>第一次检测到内容变化</strong>到<strong>调度任务</strong>之间的<strong>最大等待时间</strong>。即使内容一直在变化，超过此时间后任务也一定会被调度。</li></ul></li><li><strong>重载方法</strong>：两者都提供了接受 <code>(Long, TimeUnit)</code> 和 <code>(Duration)</code> 参数的方法，后者是更现代的 Java Time API。</li><li><strong>API 要求</strong>：需要 Android 7.0 (API 级别 24) 或更高。</li><li><strong>使用场景</strong>：例如，一个文档管理应用在用户批量删除文件时，文件变化事件会连续触发。设置一个最大延迟（如 1 分钟），可以确保任务最终会执行一次以处理所有更改，而不是为每个文件的删除都执行一次。</li></ul>
<p class="maodian"></p><h2>4. CoroutineWorker和Worker的区别</h2>
<p><code>CoroutineWorker</code> 和 <code>Worker</code> 是两种核心的任务执行基类，它们的设计目标、实现机制和适用场景存在显著差异。</p>
<p class="maodian"></p><h3>4.11基础架构与线程模型</h3>
<ul><li><code>Worker</code><br />基于 Java 的线程池和回调机制。其 <code>doWork()</code> 方法在后台线程中同步执行，需避免阻塞主线程。若任务耗时较长，可能占用线程池资源，影响其他任务调度。</li><li><code>CoroutineWorker</code><br />基于 Kotlin 协程实现。<code>doWork()</code> 是挂起函数（<code>suspend</code>），<strong>在协程作用域内异步执行</strong>。任务可被挂起（如等待 I/O 操作），释放底层线程供其他任务使用，显著提升资源利用率。</li></ul>
<p class="maodian"></p><h3>4.2资源消耗与并发能力</h3>
<ul><li><code>Worker</code><br />每个任务独占一个线程，大量并发任务时需创建多个线程，消耗较多内存（每个线程约 1MB 栈空间）。线程切换开销在高并发场景下可能成为瓶颈。</li><li><code>CoroutineWorker</code><br />协程轻量级（内存占用约数十 KB），单线程可调度数万协程。适合高并发 I/O 操作（如网络请求、数据库读写），避免线程资源浪费。</li></ul>
<p class="maodian"></p><h3>4.3 CoroutineWorker和Worker的doWork方法中，需要单独启动一个IO线程再执行吗 ?</h3>
<p class="maodian"></p><h4>4.3.1 ​​Worker（传统 Java 线程模型）​</h4>
<p>无需额外启动 IO 线程​​：</p>
<p>Worker.doWork()​​默认在 WorkManager 管理的后台线程池中执行​​（非主线程）。该线程池由 Executor实现，默认大小为 2-4 个线程（基于设备 CPU 核心数）</p>
<div class="jb51code"><pre class="brush:java;">class MyWorker(context: Context, params: WorkerParameters) : Worker(context, params) {
    override fun doWork(): Result {
      // 直接执行同步 I/O 操作（已在后台线程）
      val data = downloadFileSync("https://example.com/data")
      return Result.success()
    }
}</pre></div>
<p class="maodian"></p><h4>4.3.2 ​​CoroutineWorker（协程模型）​</h4>
<p>​​无需额外启动线程，但需指定调度器​​：</p>
<p>CoroutineWorker.doWork()是挂起函数，​​默认运行在 Dispatchers.Default​​（计算密集型线程池）。若需 I/O 操作（如网络请求、文件读写），应使用 withContext(Dispatchers.IO)切换到 I/O 调度器。</p>
<div class="jb51code"><pre class="brush:java;">class MyCoroutineWorker(context: Context, params: WorkerParameters) : CoroutineWorker(context, params) {
    override suspend fun doWork(): Result {
      // 切换到 IO 调度器执行阻塞操作
      val data = withContext(Dispatchers.IO) {
            downloadFile("https://example.com/data")
      }
      return Result.success()
    }
}</pre></div>
<blockquote><p>从技术趋势看，<code>CoroutineWorker</code> 代表了 Android 异步任务的未来方向，尤其在资源利用率和代码可维护性上优势明显。</p></blockquote>
<p class="maodian"></p><h2>5. PeriodicWorkRequestBuilder和OneTimeWorkRequestBuilder的区别</h2>
<p><code>PeriodicWorkRequestBuilder</code> 和 <code>OneTimeWorkRequestBuilder</code> 是定义后台任务的两类核心构建器，它们的主要区别在于任务执行模式的设计目标。以下是二者的详细对比及 WorkManager 中的其他构建器类型说明：</p>
<p class="maodian"></p><h3>5.1 核心区别：执行模式</h3>
<table><thead><tr><th><strong>特性</strong></th><th><strong>OneTimeWorkRequestBuilder</strong></th><th><strong>PeriodicWorkRequestBuilder</strong></th></tr></thead><tbody><tr><td><strong>任务类型</strong></td><td>一次性任务（执行后终止）</td><td>周期性任务（按固定间隔重复执行）</td></tr><tr><td><strong>最小执行间隔</strong></td><td>无限制</td><td><strong>&ge;15分钟</strong>（受系统强制限制）</td></tr><tr><td><strong>适用场景</strong></td><td>单次数据上传、即时操作处理</td><td>定期数据同步、日志备份、周期检查</td></tr><tr><td><strong>灵活性</strong></td><td>支持复杂约束链（如任务链 <code>beginWith().then()</code>）</td><td>仅支持独立任务（不可链式调用）</td></tr><tr><td><strong>延迟配置</strong></td><td>支持精确延迟（如 <code>setInitialDelay(10, MINUTES)</code>）</td><td>仅支持重复间隔（<code>repeatInterval</code>）和弹性窗口（<code>flexInterval</code>）</td></tr></tbody></table>
<blockquote><p>⚠️ <strong>周期性任务注意事项</strong>：</p>
<ul><li>若周期任务执行时约束未满足（如无网络），系统会跳过本次执行，<strong>不会自动补偿</strong>，需等待下一周期。</li><li>弹性窗口（<code>flexInterval</code>）允许任务在周期末尾的弹性时段内执行（如最后15分钟），优化资源调度。</li></ul></blockquote>
<p class="maodian"></p><h3>5.2 高级配置差异</h3>
<ul><li><strong>重试策略</strong>
<ul><li><code>OneTimeWorkRequestBuilder</code>：可通过 <code>setBackoffCriteria()</code> 配置指数退避策略（如失败后延迟重试）。</li><li><code>PeriodicWorkRequestBuilder</code>：<strong>不支持重试策略</strong>，失败后需等待下一周期。</li></ul></li><li><strong>加速任务（Expedited Work）</strong><ul><li>仅 <code>OneTimeWorkRequestBuilder</code> 支持 <code>setExpedited()</code>，用于紧急任务（如支付操作），系统会优先分配资源。</li><li>周期性任务无法加速执行。</li></ul></li></ul>
<p class="maodian"></p><h3>5.3 OneTimeWorkRequestBuilder怎么使用</h3>
<div class="jb51code"><pre class="brush:java;">val constraints = Constraints.Builder()
    .build()
val workRequest = OneTimeWorkRequestBuilder&lt;MyWorker&gt;()
    .setConstraints(constraints)
    .setInitialDelay(15, TimeUnit.MINUTES) //任务延迟启动（例如 15 分钟后）
    .setBackoffCriteria( //配置失败后的指数退避重试
          BackoffPolicy.EXPONENTIAL, // 或 LINEAR
          OneTimeWorkRequest.MIN_BACKOFF_MILLIS, // 最小延迟 10 秒
          TimeUnit.MILLISECONDS
        )
        .setExpedited(OutOfQuotaPolicy.RUN_AS_NON_EXPEDITED_WORK_REQUEST) //加急任务
    .build()</pre></div>
<p class="maodian"></p><h4>5.3.1 setBackoffCriteria中EXPONENTIAL和LINEAR的区别</h4>
<p>​​EXPONENTIAL（指数退避）​​ 和 ​​LINEAR（线性退避）​​ 是两种不同的重试延迟策略，用于控制任务失败后重新调度的等待时间增长方式。</p>
<ul><li>LINEAR​ : ​延迟时间按​​固定值线性增加​​：延迟时间 = 初始延迟 &times; 重试次数</li><li>EXPONENTIAL : 延迟时间按​​指数倍数增长 : 延迟时间 = 初始延迟 &times; 2^(重试次数-1)</li></ul>
<p class="maodian"></p><h4>5.3.2 setExpedited</h4>
<ul><li>RUN_AS_NON_EXPEDITED_WORK_REQUEST<ul><li>配额足够时​​：<ul><li>任务作为加急任务​​立即执行​​，享受高优先级调度（低延迟、抗省电限制）。</li></ul></li><li>​​配额不足时​​：<ul><li>任务​​自动降级为普通后台任务​​，按标准 WorkRequest流程执行：</li><li>需等待约束条件满足（如联网、充电）。</li><li>可能延迟执行（无加急优先级）</li></ul></li></ul></li><li>DROP_WORK_REQUEST​​<ul><li>配合足够时 :<ul><li>任务作为加急任务​​立即执行​​，享受高优先级调度（低延迟、抗省电限制）。</li></ul></li><li>配额不足时​​直接丢弃任务​​，不会转为普通任务</li></ul></li></ul>
<blockquote><p>加急任务（RUN_AS_NON_EXPEDITED_WORK_REQUEST）的优先级高于延迟设置​​(setInitialDelay)<br />加急任务会尝试​​立即执行​​，仅受系统配额限制（如设备资源紧张时可能延迟）<br />若当前配额充足（如应用在前台或系统负载低），加急任务会忽略延迟时间直接启动</p></blockquote>
<p class="maodian"></p><h2>6. WorkManager怎么取消任务</h2>
<p>取消任务需根据任务标识类型选择对应方法</p>
<p class="maodian"></p><h3>6.1 通过任务 ID 取消</h3>
<p>每个 <code>WorkRequest</code> 创建时自动生成唯一 ID (<code>UUID</code>)，适用于精确取消单个任务。</p>
<div class="jb51code"><pre class="brush:java;">val workRequest = OneTimeWorkRequestBuilder&lt;MyWorker&gt;().build()
WorkManager.getInstance(context).enqueue(workRequest)
// 取消任务
WorkManager.getInstance(context).cancelWorkById(workRequest.id)</pre></div>
<p><strong>适用场景</strong>：明确知道目标任务的 ID 时使用。</p>
<p class="maodian"></p><h3>6.2 通过标签 (Tag) 取消</h3>
<p>为任务添加标签后，可批量取消同标签的所有任务：</p>
<div class="jb51code"><pre class="brush:java;">val workRequest = OneTimeWorkRequestBuilder&lt;MyWorker&gt;()
    .addTag("data_sync") // 添加标签
    .build()
// 取消所有带此标签的任务
WorkManager.getInstance(context).cancelAllWorkByTag("data_sync")</pre></div>
<p><strong>优势</strong>：适用于逻辑分组任务（如&ldquo;所有数据同步任务&rdquo;）。</p>
<p class="maodian"></p><h3>6.3 取消唯一任务 (Unique Work)</h3>
<p>唯一任务通过名称 (<code>uniqueWorkName</code>) 标识，同一名称仅允许一个实例运行：</p>
<div class="jb51code"><pre class="brush:java;">val workRequest = OneTimeWorkRequestBuilder&lt;MyWorker&gt;().build()
// 提交唯一任务
WorkManager.getInstance(context).enqueueUniqueWork(
    "unique_sync_task",
    ExistingWorkPolicy.REPLACE,
    workRequest
)
// 通过唯一名称取消
WorkManager.getInstance(context).cancelUniqueWork("unique_sync_task")</pre></div>
<p><strong>策略说明</strong>：</p>
<ul><li><code>ExistingWorkPolicy.REPLACE</code>：新任务自动取消旧任务。</li><li>适用于防重复任务（如定时数据同步）。</li></ul>
<p class="maodian"></p><h3>6.4 取消所有任务</h3>
<p>清理整个 WorkManager 队列：</p>
<div class="jb51code"><pre class="brush:java;">WorkManager.getInstance(context).cancelAllWork()</pre></div>
<p><strong>慎用</strong>：会取消所有未完成的任务（包括周期任务）。</p>
<p class="maodian"></p><h3>6.5 取消后的任务行为</h3>
<ul><li><strong>状态变更</strong>：任务状态变为 <code>CANCELLED</code>，但 <code>doWork()</code> 中的代码<strong>不会立即停止</strong>。</li><li><strong>资源释放</strong>：需在 Worker 中主动检查取消信号：<div class="jb51code"><pre class="brush:java;">class MyWorker(context: Context, params: WorkerParameters) : Worker(context, params) {
    override fun doWork(): Result {
      while (!isStopped) { // 循环中检查取消状态
            // 执行逻辑
      }
      return Result.success()
    }
    override fun onStopped() {
      super.onStopped()
      // 释放资源（如关闭数据库连接）
    }
}</pre></div><strong>关键点</strong>：
<ul><li><code>isStopped</code>：检测任务是否被取消。</li><li><code>onStopped()</code>：收到取消信号时回调，用于清理资源。</li></ul></li></ul>
<p class="maodian"></p><h4>6.5.1 通过workManager.getWorkInfosByTag，怎么判断是否有某个Work还未执行 ?</h4>
<div class="jb51code"><pre class="brush:java;">val workManager = WorkManager.getInstance(context)
val tag = "YOUR_TAG" // 替换为实际标签
// 异步监听方式（推荐）
workManager.getWorkInfosByTagLiveData(tag).observe(this) { workInfos -&gt;
    val hasUnfinishedWork = workInfos.any { workInfo -&gt;
      workInfo.state == WorkInfo.State.ENQUEUED ||
      workInfo.state == WorkInfo.State.BLOCKED
    }
    if (hasUnfinishedWork) {
      Log.d("WorkStatus", "存在未执行的任务")
    }
}
// 同步查询方式（需在后台线程执行）
val workInfos = workManager.getWorkInfosByTag(tag).get()
val unfinishedWorkExists = workInfos.any { workInfo -&gt;
    workInfo.state == WorkInfo.State.ENQUEUED ||
    workInfo.state == WorkInfo.State.BLOCKED
}</pre></div>
<p class="maodian"></p><h2>7. 更多内容</h2>
<p>有关Doze低功耗模式下的WorkManager，详见 : Android Doze低电耗休眠模式 与 WorkManager</p>
<p>到此这篇关于Android WorkManager的概念和使用详细指南的文章就介绍到这了,更多相关Android WorkManager使用内容请搜索琼殿技术社区以前的文章或继续浏览下面的相关文章希望大家以后多多支持琼殿技术社区！</p>
                           
                            <div class="art_xg">
                              <b>您可能感兴趣的文章:</b><ul><li>Android使用WorkManager实现缓存清理的方案</li><li>android&nbsp;kotlin集成WorkManager实现定时获取数据的步骤</li><li>Android&nbsp;WorkManager使用以及源码分析</li><li>Android&nbsp;WorkManager实现后台定时任务流程详解</li><li>Android Jetpack库重要组件WorkManager的使用</li><li>Android开发Jetpack组件WorkManager用例详解</li><li>Android使用Kotlin API实践WorkManager</li><li>Android WorkManager浅谈</li></ul>
                            </div>

                        </div>
                        <!--endmain-->

查看完整版本: Android WorkManager的概念和使用详细指南