移动开发中的后台任务：定义、类型及工作原理

什么是后台任务？

后台任务是指应用程序不在前台（活跃屏幕）时执行的任何代码。这可能包括：与服务器定期同步数据、下载大文件、处理推送通知、地理定位跟踪、更新小部件。每个平台对后台工作都有自己的限制：iOS更严格（10–30分钟后台时间），Android更宽松，但从版本9开始收紧了规则。

后台任务的架构建立在三个级别上：（1）即时任务 — 立即执行（Foreground Service）；（2）延迟任务 — 在合适条件下执行（WorkManager、BGTaskScheduler）；（3）定期任务 — 按设定间隔重复执行。选择正确级别决定了任务是否能及时完成，以及是否会导致应用被商店拒绝。

在两个平台上，Google/Apple都强烈建议使用声明式API，而不是在后台直接管理线程。Android上的WorkManager和iOS上的BGTaskScheduler允许系统在应用之间优化分配后台工作，将任务分组以节省能源。在IT Sectr，我们总是从分析更新的频率和紧迫性要求开始设计后台架构。

iOS的后台任务（Background Fetch、BGTaskScheduler）

iOS提供了几种后台工作机制。Background Fetch — 以系统（而非开发人员）决定的间隔定期更新内容。应用获得约30秒的窗口来下载新数据。Background Fetch通过Capabilities → Background Modes → Background Fetch启用，并在AppDelegate中实现：application(_:performFetchWithCompletionHandler:)。

BGTaskScheduler是iOS 13+的现代API，取代了Background Fetch。开发人员使用标识符注册任务，系统在适当条件下运行它。BGAppRefreshTask — 用于简短内容更新；BGProcessingTask — 用于长时间运行的任务（缓存清理、数据库同步）。任务在应用启动时注册，系统根据电池状态、网络和用户活动安排其执行。

Background Modes — 允许在特定场景下进行后台工作的模式列表：Audio（后台播放）、Location（GPS跟踪）、VoIP（通过PushKit通话）、BLE（连接蓝牙设备）、Processing（通过BGTaskScheduler进行长时间任务）。每种模式在App Store审核时都需要说明理由。在没有实际需要的情况下使用模式是应用被拒绝的常见原因。

Significant Location Change — 适用于不需要持续定位但需要了解用户大幅移动（超过500米）的应用。系统在蜂窝基站变化时唤醒应用。这种机制与持续的GPS跟踪相比显著节省电池。

Android的后台任务（WorkManager、JobScheduler、Foreground Service）

Android提供了最丰富的后台任务API集，但从版本8.0（API 26）开始规则变得更加严格。WorkManager是Google为所有类型后台任务推荐的解决方案。WorkManager保证即使在设备重启后也能执行任务（通过BootReceiver），并支持任务链、可观察的LiveData/Flow以及向后兼容至API 14。

WorkManager使用Worker — 带有doWork()方法的基类。Constraints定义执行条件：NetworkType.CONNECTED、BatteryNotLow、StorageNotLow。PeriodicWorkRequest — 用于最小间隔为15分钟的定期任务。WorkManager自动适应Doze Mode和App Standby，将任务分组到维护窗口中。简单Worker示例：

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

    override suspend fun doWork(): Result {
        return try {
            val repository =
                Injection.provideRepository(applicationContext)
            repository.syncData()
            Result.success()
        } catch (e: Exception) {
            Result.retry()
        }
    }
}

// Запланировать задачу
val constraints = Constraints.Builder()
    .setRequiredNetworkType(NetworkType.CONNECTED)
    .build()

val syncRequest = OneTimeWorkRequestBuilder<SyncWorker>()
    .setConstraints(constraints)
    .build()

WorkManager.getInstance(context)
    .enqueue(syncRequest)

JobScheduler — 较旧的API（Android 5+，API 21）。按指定条件（网络、充电、空闲）安排任务。限制：不支持设备重启（需要BootReceiver），且没有可观察状态。JobScheduler适用于遗留项目中的简单任务；新项目应使用WorkManager。

Foreground Service — 用户通过持久通知（ongoing notification）看到的服务。用于：音乐播放、GPS跟踪、下载大文件。Foreground Service具有高优先级 — 系统不会在内存不足时杀死它。从Android 13开始，某些类型需要FOREGROUND_SERVICE_SPECIAL_USE权限。替代方案是使用带有ForegroundServiceOption的WorkManager（长时间任务）。

AlarmManager — 用于必须在精确时间执行的任务（闹钟、提醒）。AlarmManager可以从Doze Mode唤醒设备（setAlarmClock）。由于能耗高，不建议用于常规同步。定期任务请使用WorkManager，仅在精确时间至关重要时才使用AlarmManager。

Doze Mode和App Standby

Doze Mode是Android中影响后台任务执行的省电模式。在Android 6.0（API 23）中引入。当设备未充电、屏幕关闭且设备静止时，Doze Mode会阻止网络请求、推迟JobScheduler和WakeLock。Doze会定期打开维护窗口 — 应用程序可以执行延迟任务的短时间隔。从Android 7.0（API 24）开始，Doze在屏幕关闭时激活，而不仅仅是在完全静止时。

App Standby — 一种将未使用的应用程序置于待机状态的模式。如果应用没有活跃通知且多日未打开，它会被放入Standby Bucket：活跃（active）、working、frequent、rare。应用使用越少，限制越严格：网络请求被推迟、同步被阻止、JobScheduler不运行。

WakeLock — 一种保持设备唤醒的机制（防止其休眠）。用于完成重要操作。WakeLock必须在任务完成后释放（release），否则电池将在几小时内耗尽。WakeLock在Doze Mode中不起作用 — 系统会忽略它。在Android 8+上使用WakeLock需要WAKE_LOCK权限和正确的生命周期管理。

在IT Sectr，我们在设计阶段就考虑Doze Mode和App Standby。WorkManager会自动处理这些模式，但对于Foreground Service，需要计划正确处理过渡到Doze的过程。建议在真实设备上启用省电模式并在长时间空闲后测试后台工作。

实用建议

在设计后台任务时，请遵循以下建议。1. 新Android项目始终使用WorkManager。它解决了兼容性问题、Doze Mode和设备重启问题。2. 在iOS上，对于iOS 13+，优先使用BGTaskScheduler而非Background Fetch。3. 仅在任务确实需要可见通知时才使用Foreground Service。4. 不要滥用WakeLock — 这会耗尽电池并可能导致应用被拒绝。5. 在Doze Mode中测试后台任务：adb shell dumpsys deviceidle force-idle。6. 始终通过日志和分析验证任务完成情况。7. 记住限制：iOS为Background Fetch提供约30秒，为BGProcessingTask提供约几分钟。Android WorkManager不保证精确的执行时间。