WorkManager 從入門到實踐，有這一篇就夠了

前言

一般情況下，我們大部分的操作都是在 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:/>

官方文檔 :

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

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/4qtyymVfUd-vsK06VIC7cw

猜你喜歡