WorkManager — คืออะไร, API และการกำหนดเวลางาน

WorkManager ทำงานอย่างไร?

สถาปัตยกรรม ของ WorkManager สร้างขึ้นรอบคลาสพื้นฐานสามคลาส: Worker, WorkRequest และ WorkManager Worker มีตรรกะของงาน WorkRequest อธิบายพารามิเตอร์การดำเนินการ และ WorkManager จัดการคิวและการกำหนดเวลา ไลบรารีใช้ฐานข้อมูล Room ภายในเพื่อเก็บสถานะของงานทั้งหมด

Worker และ WorkRequest

Worker คือคลาสนามธรรมที่มีเมธอดเดียว doWork ซึ่งถูกเรียกบนเธรดพื้นหลัง เมธอดส่งคืน ListenableWorker.Result — SUCCESS, FAILURE หรือ RETRY WorkRequest เชื่อม Worker กับพารามิเตอร์: หมดเวลา แท็ก หน่วงเวลาเริ่มต้น และข้อจำกัด

class SyncWorker(
    context: Context,
    params: WorkerParameters
) : Worker(context, params) {

    override fun doWork(): Result {
        return try {
            val api = RetrofitClient.api
            val response = api.syncData()
            Result.success()
        } catch (e: Exception) {
            Result.retry()
        }
    }
}

การกำหนดเวลาผ่าน WorkManager

WorkManager กำหนดเวลางานอย่างสม่ำเสมอโดยไม่ขึ้นกับเวอร์ชัน Android เมื่อเรียก enqueue ไลบรารีจะบันทึกงานใน Room ประเมินเงื่อนไขปัจจุบัน และเลือกเวลาดำเนินการที่เหมาะสมที่สุด เบื้องหลังอาจใช้ JobScheduler, AlarmManager หรือตัวกำหนดเวลาของตัวเอง — นักพัฒนาไม่ต้องกังวลเกี่ยวกับเรื่องนี้

val syncRequest = OneTimeWorkRequestBuilder<SyncWorker>()
    .setInitialDelay(15, TimeUnit.MINUTES)
    .addTag("sync")
    .build()

WorkManager.getInstance(context)
    .enqueue(syncRequest)

ประเภทของ WorkRequest

WorkManager รองรับคำขอการดำเนินการสองประเภท: แบบครั้งเดียวและแบบระยะเวลา การเลือกประเภทขึ้นอยู่กับสถานการณ์: งานควรทำงานครั้งเดียวหรือทำซ้ำตามช่วงเวลาที่กำหนด

OneTimeWorkRequest

OneTimeWorkRequest ออกแบบมาสำหรับงานที่ควรดำเนินการเพียงครั้งเดียว ซึ่งอาจเป็นการส่งล็อก การซิงโครไนซ์ข้อมูลหลังการตรวจสอบสิทธิ์ การดาวน์โหลดการกำหนดค่าเมื่อเริ่มครั้งแรก การหน่วงเวลาตั้งค่าผ่าน setInitialDelay และข้อจำกัดผ่าน setConstraints

PeriodicWorkRequest

PeriodicWorkRequest เหมาะสำหรับงานที่ทำซ้ำโดยมีช่วงเวลาขั้นต่ำ 15 นาที ไลบรารีรับประกันว่าช่วงเวลาระหว่างการทำงานจะไม่น้อยกว่าที่กำหนด แต่อาจนานขึ้นเนื่องจากข้อจำกัดของอุปกรณ์ สำหรับงานที่มีความถี่น้อยกว่า 15 นาที ให้ใช้ Handler หรือ Timer ใน Foreground Service

การตั้งค่าข้อจำกัดและห่วงโซ่งาน

ข้อจำกัด ใน WorkManager ช่วยให้คุณกำหนดเงื่อนไขที่สามารถเริ่มงานได้: การเชื่อมต่อเครือข่าย (NetworkType), ระดับแบตเตอรี่ (batteryNotLow), สถานะพื้นที่จัดเก็บ (StorageNotLow) และโหมดไม่ได้ใช้งาน (DeviceIdle) งานจะไม่เริ่มจนกว่าจะปฏิบัติตามข้อจำกัดทั้งหมด

val constraints = Constraints.Builder()
    .setRequiredNetworkType(NetworkType.CONNECTED)
    .setRequiresCharging(true)
    .setRequiresBatteryNotLow(true)
    .build()

val request = OneTimeWorkRequestBuilder<ImageUploadWorker>()
    .setConstraints(constraints)
    .build()

ห่วงโซ่ ช่วยให้คุณจัดระเบียบการดำเนินงานแบบต่อเนื่องหรือขนาน beginWith เริ่มห่วงโซ่ จากนั้นเพิ่ม Worker ถัดไปที่จะดำเนินการหลังจากเสร็จสิ้นงานก่อนหน้าสำเร็จ สำหรับการดำเนินการแบบขนาน ให้ใช้ workManager.enqueue(listOf(request1, request2))

WorkManager.getInstance(context)
    .beginWith(compressWorker)
    .then(uploadWorker)
    .then(cleanupWorker)
    .enqueue()
    // compress -> upload -> cleanup ตามลำดับ

การย้ายจาก JobScheduler ไปยัง WorkManager

JobScheduler ถูกนำมาใช้ใน Android 5 (API 21) ในฐานะบริการระบบสำหรับกำหนดเวลางานพื้นหลัง WorkManager เข้ามาแทนที่ โดยเสนอ API ข้ามแพลตฟอร์มพร้อมการย้ายข้อมูลอัตโนมัติและความสามารถเพิ่มเติม: ห่วงโซ่ การรับประกันการดำเนินการ แท็ก การสังเกตสถานะผ่าน LiveData

เมื่อย้ายจาก JobScheduler ไปยัง WorkManager คุณต้องแปลง JobService เป็น Worker แทนที่ JobInfo ด้วย WorkRequest และ Context.getSystemService ด้วย API ของ WorkManager WorkManager จัดการปัญหาความเข้ากันได้โดยอัตโนมัติและจัดการ Doze Mode ถูกต้องกว่าการใช้งาน JobScheduler ด้วยตนเอง ขั้นตอนการย้าย: 1) สร้างคลาส Worker, 2) สร้าง WorkRequest ด้วยเงื่อนไขเดียวกัน, 3) ลบ JobService และ JobInfo ออกจากโค้ดและ manifest

UniqueWork สำหรับงานที่ไม่ซ้ำ

WorkManager รองรับแนวคิดของงานที่ไม่ซ้ำผ่าน ExistingWorkPolicy หากมีงานตามชื่อที่กำหนดอยู่แล้ว นโยบายจะกำหนดพฤติกรรม: KEEP (ไม่สร้างใหม่), REPLACE (แทนที่งานที่มีอยู่), APPEND (เพิ่มต่อท้ายห่วงโซ่) และ APPEND_OR_REPLACE UniqueWorkRequest สะดวกสำหรับงานที่ไม่ควรทำซ้ำ: การซิงโครไนซ์ฐานข้อมูล การดาวน์โหลดการกำหนดค่า การส่งชุดข้อมูลวิเคราะห์

WorkManager.getInstance(context)
    .enqueueUniqueWork(
        "sync_data",
        ExistingWorkPolicy.KEEP,
        syncRequest
    )

การจัดการความคืบหน้าและผลลัพธ์ระหว่างกลาง

CoroutineWorker รองรับกลไก setProgress ซึ่งช่วยให้ส่งผ่านผลลัพธ์การดำเนินการระหว่างกลาง ซึ่งมีประโยชน์สำหรับการดำเนินการระยะยาว: การดาวน์โหลดไฟล์ขนาดใหญ่ การประมวลผลภาพเป็นชุด การย้ายฐานข้อมูล UI สามารถสมัครรับการอัปเดตผ่าน getWorkInfosByTagLiveData และแสดงความคืบหน้าแบบเรียลไทม์ เมธอด ForegroundInfo ยังมีให้สำหรับเรียกใช้ Worker เป็น Foreground Service พร้อมการแจ้งเตือนหากงานควรปรากฏแก่ผู้ใช้

class ProgressWorker(
    context: Context,
    params: WorkerParameters
) : CoroutineWorker(context, params) {

    override suspend fun doWork(): Result {
        val total = 100
        for (i in 1..total) {
            setProgress(
                workDataOf("progress" to i)
            )
        }
        return Result.success()
    }
}

InputData และ OutputData สำหรับการถ่ายโอนข้อมูล

WorkManager รองรับการถ่ายโอนข้อมูลระหว่าง Workers ผ่าน InputData และ OutputData InputData ถูกสร้างขึ้นระหว่างการสร้าง WorkRequest ผ่าน Data.Builder และส่งต่อไปยัง Worker ผ่าน inputData หลังจากการดำเนินการ Worker สร้าง OutputData ผ่าน workDataOf หรือ Data.Builder และส่งคืนพร้อมกับ Result.success(outputData) Worker ถัดไปในห่วงโซ่ได้รับ outputData ของงานก่อนหน้าเป็น inputData ของตัวเอง ข้อมูลถูกจัดเก็บในรูปแบบคีย์-ค่าพร้อมรองรับชนิดพื้นฐาน: String, Int, Long, Boolean, Double ขนาดสูงสุดของ Data คือ 10 KB

ในทางปฏิบัติ หลายโครงการใช้ WorkManager เป็นตัวกำหนดเวลางานพื้นหลังเพียงตัวเดียว Google แนะนำให้ย้าย JobService ทั้งหมดที่มีอยู่ไปยัง WorkManager โดยเฉพาะในแอปที่รองรับ Android 4.4 (API 19) และต่ำกว่า ซึ่ง JobScheduler ไม่พร้อมใช้งานและ WorkManager ใช้กลไกสำรองผ่าน AlarmManager และ BroadcastReceiver สำหรับการทดสอบ WorkManager มี TestListenableWorkerBuilder และ TestWorkerBuilder ซึ่งช่วยให้ทดสอบ Workers ใน JUnit tests โดยไม่ต้องมีตัวกำหนดเวลาจริง