[[436578]]

前言

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

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

何時(shí)使用 WorkManager

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

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

針對(duì)許多不同的情況都需要運(yùn)行后臺(tái)工作，因此運(yùn)行后臺(tái)工作有不同的解決方案。

使用的充分不必要條件?

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

首先，問問自己：

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

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

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

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

WorkerManager的工作流程

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

Work Request

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

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

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

 Worker

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

工作器初始化簡(jiǎn)易過程。

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

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

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

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

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

限制條件

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

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

Delay

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

Worker State Observe

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

getWorkInfosByTagLiveData —> getWorkInfosForUniqueWorkLiveData —> getWorkInfoByIdLiveData 

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

臨時(shí)worker

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

但是!會(huì)存在一個(gè)問題，如果設(shè)備處于休眠模式，進(jìn)程會(huì)被擱置;當(dāng)設(shè)備被喚醒時(shí)，進(jìn)程會(huì)按順序再次處理。如果大家希望能準(zhǔn)確對(duì)進(jìn)程進(jì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