WorkManager — nó là gì, API và lập lịch tác vụ

WorkManager hoạt động như thế nào?

Kiến trúc của WorkManager được xây dựng xung quanh ba lớp cơ sở: Worker, WorkRequest và WorkManager. Worker chứa logic tác vụ, WorkRequest mô tả tham số thực thi, và WorkManager quản lý hàng đợi và lập lịch. Thư viện sử dụng cơ sở dữ liệu Room nội bộ để lưu trữ trạng thái của tất cả tác vụ.

Worker và WorkRequest

Worker là lớp trừu tượng với một phương thức duy nhất doWork được gọi trên luồng nền. Phương thức trả về ListenableWorker.Result — SUCCESS, FAILURE hoặc RETRY. WorkRequest liên kết Worker với các tham số: thời gian chờ, thẻ, độ trễ ban đầu và ràng buộc.

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()
        }
    }
}

Lập lịch qua WorkManager

WorkManager lập lịch tác vụ đồng nhất bất kể phiên bản Android. Khi gọi enqueue, thư viện lưu tác vụ vào Room, đánh giá điều kiện hiện tại và chọn thời điểm thực thi tối ưu. Bên trong, nó có thể sử dụng JobScheduler, AlarmManager hoặc bộ lập lịch riêng — nhà phát triển không cần lo lắng về điều đó.

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

WorkManager.getInstance(context)
    .enqueue(syncRequest)

Các loại WorkRequest

WorkManager hỗ trợ hai loại yêu cầu thực thi: một lần và định kỳ. Việc chọn loại phụ thuộc vào kịch bản: tác vụ nên chạy một lần hay lặp lại ở một khoảng thời gian nhất định.

OneTimeWorkRequest

OneTimeWorkRequest được thiết kế cho các tác vụ cần thực thi một lần. Đó có thể là gửi nhật ký, đồng bộ dữ liệu sau khi xác thực, tải cấu hình khi khởi chạy lần đầu. Độ trễ được đặt qua setInitialDelay và ràng buộc qua setConstraints.

PeriodicWorkRequest

PeriodicWorkRequest phù hợp cho các tác vụ lặp lại với khoảng thời gian tối thiểu 15 phút. Thư viện đảm bảo khoảng thời gian giữa các lần chạy không nhỏ hơn chỉ định, nhưng có thể dài hơn do ràng buộc thiết bị. Đối với tác vụ có tần suất dưới 15 phút, hãy sử dụng Handler hoặc Timer trong Foreground Service.

Thiết lập ràng buộc và chuỗi tác vụ

Ràng buộc trong WorkManager cho phép đặt điều kiện để khởi chạy tác vụ: kết nối mạng (NetworkType), mức pin (batteryNotLow), trạng thái bộ nhớ (StorageNotLow) và chế độ không hoạt động (DeviceIdle). Tác vụ sẽ không bắt đầu cho đến khi tất cả ràng buộc được đáp ứng.

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

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

Chuỗi cho phép tổ chức thực thi tác vụ tuần tự hoặc song song. beginWith bắt đầu một chuỗi, then thêm Worker tiếp theo sẽ thực thi sau khi hoàn thành thành công Worker trước đó. Để thực thi song song, sử dụng workManager.enqueue(listOf(request1, request2)).

WorkManager.getInstance(context)
    .beginWith(compressWorker)
    .then(uploadWorker)
    .then(cleanupWorker)
    .enqueue()
    // compress -> upload -> cleanup tuần tự

Di chuyển từ JobScheduler sang WorkManager

JobScheduler được giới thiệu trong Android 5 (API 21) như một dịch vụ hệ thống để lập lịch tác vụ nền. WorkManager ra đời để thay thế, cung cấp API đa nền tảng với di chuyển tự động và các khả năng bổ sung: chuỗi, đảm bảo thực thi, thẻ, theo dõi trạng thái qua LiveData.

Khi di chuyển từ JobScheduler sang WorkManager, bạn cần chuyển đổi JobService thành Worker, thay thế JobInfo bằng WorkRequest và Context.getSystemService bằng API WorkManager. WorkManager tự động xử lý các vấn đề tương thích và xử lý Doze Mode chính xác hơn so với triển khai JobScheduler thủ công. Các bước di chuyển: 1) tạo lớp Worker, 2) xây dựng WorkRequest với cùng điều kiện, 3) xóa JobService và JobInfo khỏi mã và tệp kê khai.

UniqueWork cho tác vụ duy nhất

WorkManager hỗ trợ khái niệm tác vụ duy nhất thông qua ExistingWorkPolicy. Nếu tác vụ với tên chỉ định đã tồn tại, chính sách xác định hành vi: KEEP (không tạo mới), REPLACE (thay thế tác vụ hiện có), APPEND (thêm vào cuối chuỗi) và APPEND_OR_REPLACE. UniqueWorkRequest thuận tiện cho các tác vụ không nên trùng lặp: đồng bộ cơ sở dữ liệu, tải cấu hình, gửi lô phân tích.

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

Xử lý tiến trình và kết quả trung gian

CoroutineWorker hỗ trợ cơ chế setProgress, cho phép truyền kết quả thực thi trung gian. Điều này hữu ích cho các hoạt động dài: tải tệp lớn, xử lý ảnh hàng loạt, di chuyển cơ sở dữ liệu. UI có thể đăng ký cập nhật qua getWorkInfosByTagLiveData và hiển thị tiến trình theo thời gian thực. Phương thức ForegroundInfo cũng có sẵn để chạy Worker dưới dạng Foreground Service với thông báo nếu tác vụ cần hiển thị cho người dùng.

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 và OutputData để truyền dữ liệu

WorkManager hỗ trợ truyền dữ liệu giữa các Worker qua InputData và OutputData. InputData được tạo trong quá trình xây dựng WorkRequest qua Data.Builder và được truyền đến Worker qua inputData. Sau khi thực thi, Worker tạo OutputData qua workDataOf hoặc Data.Builder và trả về cùng với Result.success(outputData). Worker tiếp theo trong chuỗi nhận outputData của Worker trước làm inputData của nó. Dữ liệu được lưu trữ ở định dạng khóa-giá trị với hỗ trợ các kiểu cơ bản: String, Int, Long, Boolean, Double. Kích thước tối đa của Data là 10 KB.

Trong thực tế, nhiều dự án sử dụng WorkManager làm bộ lập lịch tác vụ nền duy nhất. Google khuyến nghị di chuyển tất cả JobService hiện có sang WorkManager, đặc biệt trong các ứng dụng hỗ trợ Android 4.4 (API 19) trở xuống, nơi JobScheduler không khả dụng và WorkManager sử dụng cơ chế dự phòng qua AlarmManager và BroadcastReceiver. Để kiểm thử, WorkManager cung cấp TestListenableWorkerBuilder và TestWorkerBuilder, cho phép kiểm thử Worker trong các bài kiểm thử JUnit mà không cần bộ lập lịch thực.