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 استفاده کنید.

تنظیم محدودیت‌ها و زنجیره‌های وظایف

محدودیت‌ها (constraints) در WorkManager به شما امکان می‌دهند شرایطی را مشخص کنید که وظیفه می‌تواند آغاز شود: اتصال شبکه (NetworkType)، سطح باتری (batteryNotLow)، وضعیت حافظه (StorageNotLow) و حالت انتظار (DeviceIdle). وظیفه تا برآورده نشدن تمام محدودیت‌ها شروع نخواهد شد.

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

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

زنجیره‌ها (chaining) امکان اجرای پیشرو یا موازی وظایف را فراهم می‌کنند. beginWith زنجیره را شروع می‌کند، then 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 را بهتر از پیاده‌سازی دستی JobScheduler مدیریت می‌کند. مراحل مهاجرت: 1) کلاس Worker ایجاد کنید، 2) WorkRequest را با همان شرایط بسازید، 3) JobService و JobInfo را از کد و مانیفست حذف کنید.

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 انتقال داده بین Worker-ها را از طریق InputData و OutputData پشتیبانی می‌کند. InputData در مرحله ساختن WorkRequest از طریق Data.Builder ایجاد می‌شود و از طریق inputData به Worker ارسال می‌شود. پس از اجرا، 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 را فراهم می‌کند که به شما امکان آزمایش Worker-ها را در آزمایش‌های JUnit بدون زمان‌بند واقعی می‌دهند.