WorkManager :工作約束 & 延遲 & 重試

chenfp22 2021-08-15 13:36:59 阅读数:676

本文一共[544]字,预计阅读时长:1分钟~
workmanager 工作

在前面的章節中,我們已經提到了工作約束這個詞,但是相關的內容沒有講解。同時前面也已經使用到了延遲的相關方法。所以本章節中將講解工作約束的相關內容。

WorkManager的工作約束

約束可確保將工作延遲到滿足最佳條件時運行。以下約束適用於 WorkManager。

NETWORKTYPE 約束運行工作所需的網絡類型。例如 WI-FI (UNMETERED)。
BatteryNotLow 如果設置為 true,那麼當設備處於“電量不足模式”時,工作不會運行。
RequiresCharging 如果設置為 true,那麼工作只能在設備充電時運行。
DeviceIdle 如果設置為 true,則要求用戶的設備必須處於空閑狀態,才能運行工作。如果您要運行批量操作,否則可能會降低用戶設備上正在積極運行的其他應用的性能,建議您使用此約束。
StorageNotLow 如果設置為 true,那麼當用戶設備上的存儲空間不足時,工作不會運行。

如需創建一組約束並將其與某項工作相關聯,請使用一個 Contraints.Builder() 創建 Constraints 實例,並將該實例分配給 WorkRequest.Builder()

例如,以下代碼會構建了一個工作請求,該工作請求僅在用戶設備正在充電且連接到 Wi-Fi 網絡時才會運行:

Constraints constraints = new Constraints.Builder()
      .setRequiredNetworkType(NetworkType.UNMETERED)  //設置連接到WiFi
      .setRequiresCharging(true)  //設置正在充電
      .build();
​
WorkRequest myWorkRequest =
      new OneTimeWorkRequest.Builder(MyWork.class)
              .setConstraints(constraints)
              .build();
複制代碼

如果指定了多個約束,工作將僅在滿足所有約束時才會運行。

如果在工作運行時不再滿足某個約束,WorkManager 將停止工作器。系統將在滿足所有約束後重試工作。

WorkRequest的延遲工作

如果工作沒有約束,或者當工作加入隊列時所有約束都得到了滿足,那麼系統可能會選擇立即運行該工作。如果您不希望工作立即運行,可以將工作指定為在經過一段最短初始延遲時間後再啟動。

下面舉例說明了如何將工作設置為在加入隊列後至少經過 10 分鐘後再運行。

WorkRequest myWorkRequest =
     new OneTimeWorkRequest.Builder(MyWork.class)
              .setInitialDelay(10, TimeUnit.MINUTES)
              .build();
複制代碼

該示例說明了如何為 OneTimeWorkRequest 設置初始延遲時間,您也可以為 PeriodicWorkRequest 設置初始延遲時間。在這種情况下,定期工作只有首次運行時會延遲。

WorkManager的重試&退避政策

如果您需要讓 WorkManager 重試工作,可以從工作器返回 Result.retry()。然後,系統將根據退避延遲時間和退避政策重新調度工作。

  • 退避延遲時間指定了首次嘗試後重試工作前的最短等待時間。此值不能超過 MIN_BACKOFF_MILLIS(10秒 )。
  • 退避政策定義了在後續重試過程中,退避延遲時間隨時間以怎樣的方式增長。WorkManager 支持 2 個退避政策,即 LINEAREXPONENTIAL

每個工作請求都有退避政策和退避延遲時間。默認政策是 EXPONENTIAL,延遲時間為 10 秒,但您可以在工作請求配置中替換此設置。

以下是自定義退避延遲時間和政策的示例。

​
WorkRequest myWorkRequest =
      new OneTimeWorkRequest.Builder(MyWork.class)
              .setBackoffCriteria(
                      BackoffPolicy.LINEAR,
                      OneTimeWorkRequest.MIN_BACKOFF_MILLIS,
                      TimeUnit.MILLISECONDS)
              .build();
​
複制代碼

在本示例中,最短退避延遲時間設置為允許的最小值,即 10 秒。由於政策為 LINEAR,每次嘗試重試時,重試間隔都會增加約 10 秒。例如,第一次運行以 Result.retry() 結束並在 10 秒後重試;然後,如果工作在後續嘗試後繼續返回 Result.retry(),那麼接下來會在 20 秒、30 秒、40 秒後重試,以此類推。如果退避政策設置為 EXPONENTIAL,那麼重試時長序列將接近 20、40、80 秒,以此類推。

注意:退避延遲時間不精確,在兩次重試之間可能會有幾秒鐘的差异,但絕不會低於配置中指定的初始退避延遲時間。

參照文獻:

定義工作請求  |  Android 開發者  |  Android Developers (google.cn)

版权声明:本文为[chenfp22]所创,转载请带上原文链接,感谢。 https://gsmany.com/2021/08/20210815133652310s.html