[[436578]]

前言

一般情況下，我們大部分的操作都是在app打開的時候進行的，但是在某些情況下，即使app關閉了，我們也可能需要執行必要的動作，或者會采取一個動作，而不是讓用戶等待加載，我們可以在后臺執行此操作并通知用戶結果。針對這些日常工作中經常出現但是又非常棘手的情況，學會使用workManager將會大家輕松解決這些問題。

WorkManager 是一個 API，可供大家輕松調度那些即使在退出應用或重啟設備后仍應運行的可靠異步任務。WorkManager API 是一個適合用來替換所有先前的 Android 后臺調度 API(包括 FirebaseJobDispatcher、GcmNetworkManager 和 JobScheduler等)的組件，本人也建議您這樣做。WorkManager 在其現代、一致的 API 中整合了其前身的功能，該 API 支持 14及以上，在開發時考慮到了對電池續航等影響。

何時使用 WorkManager

WorkManager 處理需要在滿足各種約束時運行的后臺工作，而不管應用程序進程是否處于活動狀態。后臺工作可以在應用程序在后臺、應用程序在前臺或應用程序在前臺啟動但轉到后臺時啟動。無論應用程序在做什么，后臺工作都應該繼續執行，或者如果 Android 終止其進程則重新啟動。

關于 WorkManager 的一個常見混淆是它用于需要在“后臺”線程中運行但不需要在進程死亡后繼續存在的任務。不是這種情況。對于此用例，還有其他解決方案，例如 Kotlin 的協程、線程池或 RxJava 等庫。

針對許多不同的情況都需要運行后臺工作，因此運行后臺工作有不同的解決方案。

使用的充分不必要條件?

在 WorkManager 的情況下，最好用于必須完成且可延遲的后臺工作。

首先，問問自己：

• 這個任務需要完成嗎?

如果應用被用戶關閉，是否還需要完成任務?一個例子是帶有遠程同步的筆記應用程序;寫完筆記后，如果希望該應用程序將筆記與后端服務器同步。即使切換到另一個應用程序并且操作系統需要關閉該應用程序以回收一些內存，也會發生這種情況。就算重新啟動設備，它也應該發生。可以通過WorkManager 來確保任務完成。

• 這個任務可以延期嗎?

我們可以在以后運行的任務，或者只運行是有用的權利呢?如果任務可以稍后運行，那么它是可延遲的。看下前面的示例，立即上傳即時筆記很理想，但是由于網絡限制等原因,不可能和編輯同步進行，不過這也不是什么大問題，畢竟主流應用的用戶習慣都是這樣。而正因為WorkManager 尊重操作系統背景限制，并嘗試以省電的方式運行您的工作， 因此這也是選擇WorkManager來做延時任務的最佳選擇之一。

WorkerManager的工作流程

在后臺，WorkManager 根據以下條件使用底層作業來調度服務：

Work Request

我們可以創建兩種類型的工作請求。

OneTimeWorkRequest → 當我們只處理一次

PeriodicWorkRequest → 當我們以一定的時間間隔來做

 Worker

Coroutinework是要暫停一個DoWork的通過在操作過程中進行必要的處理函數重載這個函數成功 失敗條件，我們可以處理。

工作器初始化簡易過程。

我們指定它將使用 OneTimeWorkRequest 觸發一次，并將我們的 Worker 類作為參數。我們> 運行使用 WorkManager 創建的 workRequest。

doWork函數將在Worker 被觸發時運行。

向 Worker 發送數據

在構建WorkRequest之前，我們可以設置很多值，其中之一便是setInputData()參數，足以發送屬于androidx.work的Data。

在 Worker類中，我們可以獲取與inputData一起發送的值及其鍵。

限制條件

我們可以使用setConstraints()設置一些條件，以便在運行worker之前檢查這些條件。

• setRequiresDeviceIdle → 如果我們想讓它在進入 Doze 模式時工作，我們只需要將其設置為 true。默認值為假。
• setRequiresNetworkType → 我們可以設置互聯網連接狀態。
• setRequiresBatteryNotLow → 如果電池電量不低，我們可以設置它的狀態。默認值為假。
• setRequiresCharging → 插入狀態。默認值為假。

Delay

延遲部分對于 OneTimeRequest 會起作用一次，對于臨時workder也會以同樣的方式起作用，但是這種延遲不會在每次觸發時起作用。

Worker State Observe

我們可以通過狀態觀察我們在Worker 中所做的過程，有不止一種方法，我們可以在它們之間進行選擇。

getWorkInfosByTagLiveData —> getWorkInfosForUniqueWorkLiveData —> getWorkInfoByIdLiveData 

本人更偏向使用workRequest的id進行觀察，通過將數據分配給Worker中的成功和失敗狀態，將能夠再次接收該數據并對其進行觀察。

臨時worker

它的工作方式與OneTime類似，除此之外我們需要指定作用時間。

但是!會存在一個問題，如果設備處于休眠模式，進程會被擱置;當設備被喚醒時，進程會按順序再次處理。如果大家希望能準確對進程進行操作，則需要往清單文件中添加一下權限。

uses-permission android:name="android.permission.REQUEST_IGNORE_BATTERY_OPTIMIZATIONS"/> 

官方文檔 : 

https://developer.android.com/topic/libraries/architecture/workmanager https://bugrayetkinn.medium.com/android-workmanager-6bc60dcd17fd https://android-developers.googleblog.com/2018/10/modern-background-execution-in-android.html