Thực thi nền trong phát triển di động — bản chất, giới hạn và nguyên tắc hoạt động

Thực thi nền trong ứng dụng di động là gì?

Background Execution là khả năng ứng dụng tiếp tục thực thi mã sau khi người dùng đã thu nhỏ hoặc chuyển sang ứng dụng khác. Không có cơ chế đặc biệt, hệ điều hành di động đưa ứng dụng vào trạng thái Suspended (tạm dừng) trong vòng vài giây sau khi vào nền, giải phóng CPU và bộ nhớ cho các ứng dụng đang hoạt động.

Trạng thái ứng dụng trong nền

Ứng dụng di động trải qua một số trạng thái vòng đời: Foreground (hoạt động), Background (trong nền), Suspended (tạm dừng) và Terminated (kết thúc). Background là trạng thái duy nhất mà ứng dụng có thể thực thi mã mà không có giao diện hiển thị. iOS và Android định nghĩa thời lượng và các hoạt động có sẵn trong trạng thái này khác nhau.

Các trường hợp sử dụng chính

Thực thi nền cần thiết cho đồng bộ dữ liệu, tải nội dung, xử lý thông báo Push, định vị nền và phát âm thanh. Đồng bộ là kịch bản phổ biến nhất: ứng dụng gửi dữ liệu đến máy chủ hoặc tải bản cập nhật mà không cần người dùng can thiệp.

• Đồng bộ — tải lên và tải xuống dữ liệu khi trạng thái mạng thay đổi.
• Định vị — theo dõi vị trí trong trình theo dõi thể dục và điều hướng.
• Đa phương tiện — phát âm thanh và video trong nền (nhạc, podcast).
• Thông báo — xử lý thông báo Push và thông báo cục bộ.
• Tải xuống — tải tệp lớn (podcast, video) trong nền.

Tại sao hệ điều hành di động giới hạn thực thi nền

Giới hạn thực thi nền do ba yếu tố: tiêu thụ năng lượng, hiệu suất thiết bị và quyền riêng tư người dùng. CPU và các mô-đun vô tuyến (Wi-Fi, dữ liệu di động) tiêu thụ nhiều năng lượng nhất — mỗi tiến trình nền làm giảm tuổi thọ pin.

Tiêu thụ năng lượng và thời lượng pin

Các nghiên cứu của Google cho thấy ứng dụng thực thi tác vụ nền mỗi 5 phút làm giảm thời lượng pin thiết bị 20–30% mỗi ngày. Ngay cả các hoạt động nền được tối ưu với tần suất một giờ một lần cũng có tác động đáng kể nếu có nhiều hơn hai ứng dụng như vậy.

RAM và hiệu suất

Mỗi ứng dụng nền chiếm RAM. Khi thiếu RAM, hệ thống loại bỏ ứng dụng khỏi bộ nhớ, gây khởi động lại khi người dùng quay lại. iOS sử dụng thuật toán Jetsam — cơ chế kết thúc cưỡng chế tiến trình nền khi vượt quá giới hạn bộ nhớ. Android sử dụng LMK (Low Memory Killer) với nguyên tắc tương tự.

Quyền riêng tư người dùng

Từ Android 10 và iOS 13, hệ thống yêu cầu ứng dụng khai báo mục đích của công việc nền. Android đã đưa ra hạn chế về việc khởi chạy Broadcast Receiver trong nền. iOS yêu cầu chỉ định Background Mode trong Capabilities của dự án. Người dùng có thể tắt thực thi nền cho bất kỳ ứng dụng nào trong cài đặt.

Thực thi nền trên Android: WorkManager và Foreground Service

Android cung cấp một số cơ chế cho thực thi nền, mỗi cơ chế giải quyết một loại tác vụ khác nhau. WorkManager là API được khuyến nghị cho các tác vụ trì hoãn và định kỳ. Foreground Service dành cho thực thi ngay lập tức với thông báo hiển thị. JobScheduler là một thay thế cấp thấp cho WorkManager.

WorkManager — Giải pháp phổ quát

WorkManager là một phần của Android Jetpack, cung cấp thực thi tác vụ nền với đảm bảo hoàn thành ngay cả sau khi khởi động lại thiết bị. API chọn thời điểm thực thi tối ưu dựa trên trạng thái mạng, mức pin và chế độ Doze. WorkManager tương thích với API 14+ và thay thế AlarmManager và JobScheduler đã lỗi thời.

Foreground Service — Cho hoạt động dài

Khi ứng dụng cần thực hiện tác vụ hiển thị cho người dùng (phát nhạc, ghi định vị), Foreground Service được sử dụng. Dịch vụ hiển thị thông báo liên tục trên thanh trạng thái và có ưu tiên cao hơn — hệ thống sẽ không kết thúc nó cho đến khi tác vụ hoàn thành. Từ Android 13, cần quyền POST_NOTIFICATIONS.

Chế độ Doze và tối ưu pin

Từ Android 6.0, thiết bị vào chế độ Doze khi không hoạt động. Trong chế độ này, các hoạt động mạng, đồng bộ và JobScheduler bị hoãn lại. WorkManager tự động thích ứng với Doze — các tác vụ được thực thi trong cửa sổ bảo trì tiếp theo khi thiết bị thức dậy để bảo trì.

Thực thi nền trên iOS: Background Tasks và App Refresh

iOS sử dụng cách tiếp cận nghiêm ngặt hơn cho thực thi nền. Background App Refresh là cơ chế chính cho cập nhật dữ liệu định kỳ. BGTaskScheduler là API để lập lịch tác vụ dựa trên trạng thái hệ thống. Cho hoạt động dài, có sẵn Background Modes: audio, location, voip, fetch và processing.

Background App Refresh

Background App Refresh cho phép ứng dụng thức dậy mỗi 15–30 phút để đồng bộ dữ liệu. Thời gian thức dậy phụ thuộc vào hành vi người dùng — hệ thống phân tích tần suất họ mở ứng dụng. Người dùng có thể tắt tính năng này cho từng ứng dụng trong Cài đặt — Cài đặt chung — Background App Refresh.

BGTaskScheduler — Cách tiếp cận hiện đại

Từ iOS 13, BGTaskScheduler đã thay thế performFetch và beginBackgroundTask lỗi thời. Ứng dụng đăng ký tác vụ với định danh và khoảng thời gian tối thiểu, hệ thống xác định thời điểm thực thi tối ưu. Tác vụ được chia thành hai loại: BGProcessingTask (dài, 10+ phút) và BGAppRefreshTask (ngắn, tối đa 30 giây).

Giới hạn thời gian thực thi

iOS cấp phát thời gian có hạn cho thực thi tác vụ nền — tối đa 30 giây cho BGAppRefreshTask và tối đa 10 phút cho BGProcessingTask. Khi vượt quá giới hạn, hệ thống kết thúc tác vụ cưỡng chế. Nhà phát triển phải gọi trình xử lý hết hạn (expiration handler) để lưu kết quả trung gian.

Ví dụ mã: Android WorkManager

Hãy xem xét triển khai thực tế của thực thi nền trên Android bằng WorkManager. Ví dụ đồng bộ dữ liệu mỗi 8 giờ với nhận thức trạng thái mạng. WorkManager đảm bảo thực thi tác vụ ngay cả sau khi khởi động lại thiết bị.

class SyncWorker(context: Context, params: WorkerParameters) : Worker(context, params) {
    override fun doWork(): Result {
        return try {
            syncDataToServer()
            Log.d("Sync", "Dữ liệu đã được đồng bộ")
            Result.success()
        } catch (e: Exception) {
            Result.retry()
        }
    }
}

// Chạy tác vụ định kỳ mỗi 8 giờ
val constraints = Constraints.Builder()
    .setRequiredNetworkType(NetworkType.CONNECTED)
    .setRequiresCharging(false)
    .build()

val syncRequest = PeriodicWorkRequestBuilder<SyncWorker>(
    8, TimeUnit.HOURS
).setConstraints(constraints).build()

WorkManager.getInstance(context).enqueue(syncRequest)

Foreground Service với thông báo

Cho hoạt động dài hiển thị cho người dùng, hãy sử dụng Foreground Service. Ví dụ tải tệp với tiến trình trong thông báo. Dịch vụ gọi startForeground() với thông báo không thể xóa. Khi tải xong — stopForeground(STOP_FOREGROUND_REMOVE).

class DownloadService : Service() {
    override fun onStartCommand(intent: Intent?, flags: Int, id: Int): Int {
        startForeground(NOTIFICATION_ID, createNotification())
        downloadFile()
        stopForeground(STOP_FOREGROUND_REMOVE)
        stopSelf()
        return START_NOT_STICKY
    }
    private fun createNotification(): Notification {
        return NotificationCompat.Builder(this, CHANNEL_ID)
            .setContentTitle("Tải tệp xuống")
            .setSmallIcon(android.R.drawable.ic_download)
            .build()
    }
}

Ví dụ mã: iOS BGTaskScheduler

Trên iOS, thực thi nền được cấu hình thông qua BGTaskScheduler. Ví dụ đăng ký và thực thi tác vụ cập nhật nội dung. Ứng dụng phải đăng ký định danh tác vụ trong Info.plist và gọi submit khi tác vụ cần được lập lịch.

import BackgroundTasks

func registerBackgroundTask() {
    BGTaskScheduler.shared.register(
        forTaskWithIdentifier: "com.app.refresh",
        using: nil
    ) { task in
        self.handleAppRefresh(task: task as! BGAppRefreshTask)
    }
}

func scheduleAppRefresh() {
    let request = BGAppRefreshTaskRequest(
        identifier: "com.app.refresh"
    )
    request.earliestBeginDate = Date(timeIntervalSinceNow: 15 * 60)
    try? BGTaskScheduler.shared.submit(request)
}

func handleAppRefresh(task: BGAppRefreshTask) {
    scheduleAppRefresh()
    task.expirationHandler = {
        // Lưu dữ liệu trung gian
        cacheCurrentState()
    }
    fetchLatestData {
        task.setTaskCompleted(success: true)
    }
}

Background Processing Task

Cho hoạt động dài (dọn bộ nhớ đệm, xử lý dữ liệu), hãy sử dụng BGProcessingTask. Hệ thống cho phép tối đa 10 phút để thực thi. Chỉ chạy khi thiết bị đang sạc và kết nối Wi-Fi. Yêu cầu định danh riêng trong Info.plist và đăng ký qua register(forTaskWithIdentifier:).

func scheduleProcessing() {
    let request = BGProcessingTaskRequest(
        identifier: "com.app.cleanup"
    )
    request.requiresExternalPower = true
    request.requiresNetworkConnectivity = true
    request.earliestBeginDate = Date(timeIntervalSinceNow: 24 * 60 * 60)
    try? BGTaskScheduler.shared.submit(request)
}

So sánh cách tiếp cận Android và iOS

Android và iOS khác nhau cơ bản trong triết lý thực thi nền. Android cung cấp công cụ linh hoạt với kiểm soát nhiều hơn nhưng yêu cầu nhà phát triển chọn API phù hợp. iOS giới hạn khả năng nhưng đảm bảo hiệu suất ổn định và thời lượng pin cho người dùng.

Khi nào chọn Android WorkManager

WorkManager tối ưu cho các tác vụ phải hoàn thành bất kể trạng thái ứng dụng: đồng bộ dữ liệu, gửi phân tích, xử lý hàng đợi. API đảm bảo thực thi ngay cả khi tắt thiết bị — tác vụ được lập lịch lại sau khi khởi động.

Khi nào chọn iOS BGTaskScheduler

BGTaskScheduler phù hợp cho các tác vụ hệ thống có thể thực hiện bất kỳ lúc nào thuận tiện: tải nội dung mới, cập nhật widget, dọn bộ nhớ đệm. Không phù hợp cho hoạt động khẩn cấp — hệ thống trì hoãn tác vụ nếu thiết bị ở chế độ Doze hoặc pin yếu.