[[436578]]

前言

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

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

何時使用 WorkManager

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

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

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

使用的充分不必要條件?

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

首先，問問自己：

• 這個任務(wù)需要完成嗎?

如果應(yīng)用被用戶關(guān)閉，是否還需要完成任務(wù)?一個例子是帶有遠程同步的筆記應(yīng)用程序;寫完筆記后，如果希望該應(yīng)用程序?qū)⒐P記與后端服務(wù)器同步。即使切換到另一個應(yīng)用程序并且操作系統(tǒng)需要關(guān)閉該應(yīng)用程序以回收一些內(nèi)存，也會發(fā)生這種情況。就算重新啟動設(shè)備，它也應(yīng)該發(fā)生?？梢酝ㄟ^WorkManager 來確保任務(wù)完成。

• 這個任務(wù)可以延期嗎?

我們可以在以后運行的任務(wù)，或者只運行是有用的權(quán)利呢?如果任務(wù)可以稍后運行，那么它是可延遲的?？聪虑懊娴氖纠⒓瓷蟼骷磿r筆記很理想，但是由于網(wǎng)絡(luò)限制等原因,不可能和編輯同步進行，不過這也不是什么大問題，畢竟主流應(yīng)用的用戶習(xí)慣都是這樣。而正因為WorkManager 尊重操作系統(tǒng)背景限制，并嘗試以省電的方式運行您的工作， 因此這也是選擇WorkManager來做延時任務(wù)的最佳選擇之一。

WorkerManager的工作流程

在后臺，WorkManager 根據(jù)以下條件使用底層作業(yè)來調(diào)度服務(wù)：

Work Request

我們可以創(chuàng)建兩種類型的工作請求。

OneTimeWorkRequest → 當(dāng)我們只處理一次

PeriodicWorkRequest → 當(dāng)我們以一定的時間間隔來做

 Worker

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

工作器初始化簡易過程。

我們指定它將使用 OneTimeWorkRequest 觸發(fā)一次，并將我們的 Worker 類作為參數(shù)。我們> 運行使用 WorkManager 創(chuàng)建的 workRequest。

doWork函數(shù)將在Worker 被觸發(fā)時運行。

向 Worker 發(fā)送數(shù)據(jù)

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

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

限制條件

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

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

Delay

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

Worker State Observe

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

getWorkInfosByTagLiveData —> getWorkInfosForUniqueWorkLiveData —> getWorkInfoByIdLiveData 

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

臨時worker

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

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

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