27、Foreground Service：前台服务、Android 14前台服务类型、WorkManager替代方案

聊到前台服务，我估计不少做过Android开发的兄弟都跟它打过交道。说白了，前台服务就是那个让你在通知栏里能看到一个持续通知的后台任务。比如音乐播放器、运动轨迹记录、导航软件——这些场景下，系统不允许你的进程被轻易杀掉，所以你得亮出一个通知，告诉用户“嘿，我在干活呢”。

但说实话，前台服务在Android 14上又变天了。Google对它的限制越来越严，很多以前能跑的场景现在跑不通了。我去年在做一个运动健康App时，就踩过这个坑——Android 14上，后台启动前台服务直接被系统拦截，日志里报了个ForegroundServiceStartNotAllowedException。嗯，当时排查了半天，才发现是新规。

所以这一章，我会把前台服务的核心概念、Android 14的新类型限制、以及什么时候该用WorkManager替代它，一次性讲清楚。

什么是前台服务？

前台服务（Foreground Service）是Android里一种特殊的Service。它跟普通Service最大的区别在于：必须显示一个持续的通知。这个通知不能划掉，用户必须主动关闭服务才能移除它。

为什么要这么做？因为系统认为，前台服务对用户来说是“可见的”任务，优先级高，不容易被回收。我个人的习惯是，只要任务需要长时间在后台运行，且用户能感知到它的存在，就用前台服务。

前台服务的基本实现

先看一个最简单的例子。假设我们要做一个下载文件的Service，用户能看到下载进度。

// AndroidManifest.xml 中声明
<uses-permission android:name="android.permission.FOREGROUND_SERVICE" />
<uses-permission android:name="android.permission.POST_NOTIFICATIONS" />

<service
    android:name=".DownloadService"
    android:foregroundServiceType="dataSync"
    android:exported="false" />

// DownloadService.kt
class DownloadService : Service() {

    override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int {
        val notification = createNotification()
        startForeground(NOTIFICATION_ID, notification)
        // 开始下载任务
        startDownload()
        return START_STICKY
    }

    private fun createNotification(): Notification {
        val channelId = "download_channel"
        val channel = NotificationChannel(
            channelId,
            "下载服务",
            NotificationManager.IMPORTANCE_LOW
        )
        val manager = getSystemService(NotificationManager::class.java)
        manager.createNotificationChannel(channel)

        return NotificationCompat.Builder(this, channelId)
            .setContentTitle("正在下载")
            .setContentText("下载进度：0%")
            .setSmallIcon(android.R.drawable.stat_sys_download)
            .build()
    }

    override fun onBind(intent: Intent?): IBinder? = null
}

这段代码看起来简单，但有个细节要注意：startForeground() 必须在 onStartCommand 返回之前调用，否则系统会报错。我曾经在项目里因为异步初始化导致调用晚了，直接崩溃——嗯，这个坑我记了很久。

Android 14 前台服务类型

Android 14（API 34）引入了一个重要变化：前台服务必须声明明确的类型。你不能随便定义一个前台服务，系统会根据你声明的类型来检查是否允许启动。

目前支持的 foregroundServiceType 有以下几种：

类型	说明	典型场景
camera	相机相关的前台服务	后台录像、扫码
connectedDevice	连接外部设备	蓝牙、USB、NFC
dataSync	数据同步	文件下载、上传、备份
health	健康相关	心率监测、运动记录
location	位置服务	导航、地理围栏
mediaPlayback	媒体播放	音乐、视频播放
mediaProjection	屏幕投影/录制	屏幕共享、录屏
microphone	麦克风录制	录音、语音识别
phoneCall	电话相关	VoIP通话
remoteMessaging	远程消息	即时通讯
shortService	短时前台服务（Android 14新增）	快速任务，3分钟内完成
specialUse	特殊用途（需声明理由）	系统级或特殊场景

Android 14 后台启动限制

除了类型声明，Android 14还收紧了后台启动前台服务的权限。简单来说：应用在后台时，不能通过 startForegroundService() 启动前台服务。

什么叫“后台”？就是你的App没有可见的Activity，也没有其他前台组件。这时候你调用 startForegroundService()，系统会直接拒绝。

那怎么办？Google给了几个例外情况：

• 用户主动操作（比如点击通知、点击按钮）
• 应用拥有 SYSTEM_ALERT_WINDOW 权限
• 应用是设备管理员
• 应用是输入法、壁纸等系统组件
• 通过 WorkManager 调度（这个后面会讲）

我个人的建议是：不要试图绕过这个限制。Google在Play Store审核时会检查你的App是否违规使用前台服务，一旦发现，轻则警告，重则下架。

什么时候用 WorkManager 替代前台服务？

很多开发者一遇到后台任务就上前台服务，其实没必要。你想想看，如果你的任务不需要用户感知，或者任务可以延迟执行，那用 WorkManager 更合适。

WorkManager 是 Jetpack 架构组件中的一员，专门用来处理可延迟、可靠的后台任务。它最大的优势是：自动适配系统版本。在Android 12以下用JobScheduler，在低版本用AlarmManager + BroadcastReceiver，你完全不用操心兼容性。

我整理了一个对比表格，方便你决策：

场景	推荐方案	原因
音乐播放、导航、录音	前台服务	用户必须感知，且需要高优先级
文件下载（用户等待）	前台服务	用户能看到进度，且需要持续运行
数据同步（后台静默）	WorkManager	不需要用户感知，可延迟执行
日志上传、缓存清理	WorkManager	非关键任务，系统可以推迟
定时任务（如每天同步一次）	WorkManager	支持周期性调度，且省电
即时通讯（保持长连接）	前台服务	需要持续连接，且用户期望实时

WorkManager 替代前台服务的示例

假设我们要做一个后台数据同步的任务，以前可能会用前台Service+通知。现在用WorkManager，代码简洁得多：

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

    override fun doWork(): Result {
        return try {
            // 执行同步逻辑
            syncData()
            Result.success()
        } catch (e: Exception) {
            Result.retry()
        }
    }
}

// 调度任务
val syncRequest = OneTimeWorkRequestBuilder<SyncWorker>()
    .setConstraints(
        Constraints.Builder()
            .setRequiredNetworkType(NetworkType.CONNECTED)
            .setRequiresBatteryNotLow(true)
            .build()
    )
    .setBackoffCriteria(
        BackoffPolicy.LINEAR,
        WorkRequest.MIN_BACKOFF_MILLIS,
        TimeUnit.MILLISECONDS
    )
    .build()

WorkManager.getInstance(context).enqueue(syncRequest)

这段代码的好处是：系统会帮你选择最合适的时机执行，而且即使App被杀死，任务也会在下次启动时恢复。我去年做一个电商App时，把原来的前台Service同步改成了WorkManager，用户反馈App更省电了，而且同步成功率反而提升了——因为WorkManager会处理重试和约束条件。

前台服务与WorkManager的混合使用

有些场景下，两者可以结合。比如：

• 先用WorkManager检查网络条件
• 条件满足时，再启动前台服务执行关键任务
• 任务完成后，停止前台服务

这样做的好处是：避免长时间占用前台服务，只在真正需要的时候才亮出通知。用户对通知栏的骚扰很敏感，我见过一些App一启动就弹个前台通知，用户直接卸载了。

知识体系图

下面这张图梳理了前台服务、Android 14限制、以及WorkManager替代方案之间的关系：

避坑指南

最后，分享几个我踩过的坑：

• 通知渠道问题： Android 8.0以上必须创建NotificationChannel，否则通知不显示。我曾经忘记创建，调试了半天才发现。
• 权限声明： Android 13开始，POST_NOTIFICATIONS 是运行时权限。如果你没有申请，前台服务启动时会静默失败。
• 类型不匹配： Android 14上，如果Service声明了 foregroundServiceType="location"，但实际只做数据同步，系统会报错。一定要如实声明。
• 忘记停止服务： 前台服务如果不主动停止，会一直运行。我见过一个App的音乐播放器在退出后还在跑，用户电池直接崩了。

好了，这一章的内容就到这里。前台服务虽然看起来简单，但每个版本都有新坑。记住核心原则：能用WorkManager就别用前台服务，用了前台服务就一定要合规。