注：原文地址
5月8號, I/O大會上又推出了兩個新的Architeture Component庫: Navigation與 WorkManager. 這裡就先介紹一下 WorkManager。

WorkManager簡介

其實就是”管理一些要在後臺工作的任務, – 即使你的應用沒啟動也能保證任務能被執行”。

1. 為何不用JobScheduler, AlarmManger來做?

其實這個想法很對. WorkManager在底層也是看你是什麼版本來選到底是JobScheduler, AlamarManager來做。
JobScheduler是Android 5.x才有的. 而AlarmManager一直存在. 所以WorkManager在底層, 會根據你的裝置情況, 選用JobScheduler, Firebase的JobDispatcher, 或是AlarmManager。

2.為啥不用AsyncTask, ThreadPool, RxJava?

這一點就要特別說明一下了. 這三個和WorkManager並不是替代的關係. 這三個工具, 能幫助你在應用中開後臺執行緒幹活, 但是應用一被殺或被關閉, 這些工具就幹不了活了。

而WorkManager不是, 它在應用被殺, 甚至裝置重啟後仍能保證你安排給他的任務能得到執行。

其實Google自己也說了:”WorkManager並不是為了那種在應用內的後臺執行緒而設計出來的. 這種需求你應該使用ThreadPool”。

WorkManager例項

1. 匯入WorkManager

在app/build.gradle檔案中加入如下依賴配置：
Kotlin

implementation "android.arch.work:work-runtime-ktx:1.0.0-alpha01"

Java

implementation "android.arch.work:work-runtime:1.0.0-alpha01"

2.一個定期Pull的例項

以我在2012年做過的一個專案為例, 當時我在做一個電商專案. 我們有一個需求是要定時推給使用者一些我們推薦的單品, 但是當時集團還沒有push service元件呢, 所以我們當時為了及時上線, 選用的策略是”pull策略”. 客戶端定時去後臺拉取, 看有沒有新的推薦.
這時我們要分兩步走. 第一步是確定要幹什麼活(去後臺pull推薦資訊)；第二步是讓這個活入佇列。

1，程式碼實現上也分為兩步：Worker是幹活的主體，它只管輪到了它時要做的工作，不管其它的東西。首先，新建個Worker的子類, 重寫它的doWork()方法：

class PullWorker : Worker() {
    override fun doWork(): WorkerResult {
        // 模擬設定頁面中的"是否接受推送"是否被勾選
        val isOkay = this.inputData.getBoolean("key_accept_bg_work", false)
        if(isOkay) {
            Thread.sleep(5000) //模擬長時間工作

            val pulledResult = startPull()
            val output = Data.Builder().putString("key_pulled_result", pulledResult).build()
            outputData = output
            return WorkerResult.SUCCESS
        } else {
            return WorkerResult.FAILURE
        }
    }

    fun startPull() : String{
        return "szw [worker] pull messages from backend"
    }
}

2，把Worker包裝成一個WorkRequest, 併入列。此時，WorkRequest就多了一些新屬性。

• ID(一般是一個UUID, 以保證唯一性),
• 何時執行,
• 有沒有限制(如只有在充電並連網時才執行此任務),
• 執行鏈 (當某任務執行完了, 才能輪到我執行)。

然後使用WorkManager將WorkRequest物件入列。

class PullEngine {
    fun schedulePull(){
        //java就請用PeriodicWorkRequest.Builder類
        val pullRequest = PeriodicWorkRequestBuilder<PullWorker>(24, TimeUnit.HOURS)
                .setInputData(
                    Data.Builder()
                        .putBoolean("key_accept_bg_work", true)
                        .build()
                )
                .build()

        WorkManager.getInstance().enqueue(pullRequest)
    }
}

講解

• 1.幹活的是 Worker 類。我們一般是新建個Worker的子類, 並重寫doWork()方法。但是，doWork() 方法是沒有引數的，我們有時有引數的需求，怎麼辦? 這時就要用上Worker.getInputData()方法了。
• 2.同理, doWork()方法是返回void的。你要是有結果想傳出去, 就可以用Worker.setOutputData()。
• 3.上面的兩個方法所得到/設定的資料型別都是Data. 這個Data很類似我們Android中的Bundle, 也有putInt(key, value), getString(key, defaultValue)這樣的方法。一般Data的生成, 是用Data.Builder類. 如:

val output = Data.Builder().putInt(key, 23).build()

• 4.上面講了WorkRequest其實就是入列的一個實體, 它包裝了Worker在內. 但我們一般不直接使用WorkReqeust類, 多是用它的子類: OneTimeWorkRequest, 或是PeriodWorkReqeust。因為我們的pull需求是每天都要去拉一次, 所以這裡我們沒有用OneTimeWorkRequest, 而是構建了一個24小時就重複幹活的PeriodicWorkReqeust。

進階

WorkManager 提供了一個介面讓我們拿到結果, 這個東東就是 WorkStatus. 你可以由id得到你想要的那個任務的WorkStatus. 這個 WorkStatus 其實就是知道這任務沒有完成, 有什麼返回值.

因為前後臺要解耦合的原因, 所以這個工作其實是由LiveData來完成的. 既然有LiveData, 那我們肯定要有一個 LifecycleOwner 了(一般是我們的 AppcompatActivity).

來看個例子. 以上面的pull例子為例, 若我們拉到了結果, 就顯示一個 notification (這裡為簡便, 是收到結果後就列印一下日誌)。

class PullEngine {
    fun schedulePull(){
        val pullRequest = PeriodicWorkRequestBuilder<PullWorker>(24, TimeUnit.HOURS).build()
        WorkManager.getInstance().enqueue(pullRequest)

        // 下面兩行是新加的, 用來存任務的ID
        val pullRequestID = pullRequest.id
        MockedSp.pullId = pullRequestID.toString() // 模擬存在SharedPreference中
    }
}

class PullActivity : AppCompatActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        // UUID實現了Serializable介面. 也能由toString(), fromString()與String互轉
        val uuid = UUID.fromString(MockedSp.pullId)
        WorkManager.getInstance().getStatusById(uuid)
                .observe(this, Observer<WorkStatus> { status ->
                    if (status != null){
                        val pulledResult = status.outputData.getString("key_pulled_result", "")
                        println("szw Activity getResultFromBackend : $pulledResult")
                    }
                })
    }
}

其中，observe()方法是用來監聽的. 它的引數分別是: observer(LifecycleOwner, Observer<WorkStatus>)

1，入參/返回值

入參: WorkRequest.Builder.setInputData()
Worker類: 可以getIntpuData(), 以及setOutputData()
返回值: 由LiveData監聽, 可以得到WorkStatus. 而WorkStatus就有getOutputDat()方法
需要注意的是，這裡說的inputData、outputDat, 都不是普通的int、string，而是Data類。

2，如果任務執行完了, 應用卻沒被啟動怎麼辦? 會強行啟動應用來顯示UI變化嗎?

好問題. 但嚴格來說, 這個其實不是WorkManager的問題, 而是LiveData的問題.
LiveData自己本身就是和Activity的生命週期繫結的. 你不用說應用被殺了, 就是你退出了這個註冊的Activity, 你都收不到LiveData的通知. 所以說你的應用被殺, 任務又執行完了時, 是沒有UI通知的, 更不會強行啟動你的啟動。

3，任務鏈

WorkManager.getInstance()
    .beginWith(workA)
    .then(workB)
    .then(workC)
    .enqueue()

這樣就會按workA, workB, workC的順序來執行. workA執行完了, 才會接著執行workB。WorkManager甚至還能執行:

A --> B
        --> E
C --> D

這樣的形式,，即A執行完了才執行了B, C執行完才執行D. B,D都執行完了才執行E。

5，插入任務時, 已經有相同的任務時, 怎麼辦?

WorkManager可以用beginUniqueWork()來執行唯一工作佇列(“unique work sequence”). 若有任務有重複時, 怎麼辦?
這個主要是一個ExistingWorkPolicy類。這個類也是WorkManager包中的類，它其實是一個Enum。其值有:

• REPLACE: 用新任務來取代已經存在的任務
• KEEP: 保留已經存在的任務. 忽視新任務
• APPEND: 新任務入列. 新舊任務都存在於佇列中.

總結

總體來說, WorkManager並不是要取代執行緒池/AsyncTask/RxJava. 反而是有點AlarmManager來做定時任務的意思. 即保證你給它的任務能完成, 即使你的應用都沒有被開啟, 或是裝置重啟後也能讓你的任務被執行.
WorkManager在設計上設計得比較好. 沒有把worker, 任務混為一談, 而是把它們解耦成Worker, WorkRequest. 這樣分層就清晰多了, 也好擴充套件. (如以後再有一個什麼WorkRequest的子類出來)
最後, WorkManager的入參出參設計得不錯. WorkReqeust負責放入引數, Worker處理並放置返回值, 最後WorkStaus中取出返回值, 並由LiveData來通知監聽者.