Android后台定期调用API的可靠实现方案咨询

针对你的需求，优先选择方案2（后台启动Foreground Service，前台复用原有逻辑），原因及具体实现建议如下：

方案对比分析 #

• 方案1（WorkManager+轮询）的局限性：
  WorkManager的核心定位是处理可延迟、非实时的任务，官方规定PeriodicWorkRequest的最小执行间隔为15分钟；即便通过循环提交OneTimeWorkRequest模拟高频轮询，在系统Doze模式、低内存场景下，WorkManager的执行会被系统延迟甚至抑制，完全无法保证每15秒一次的API调用频率，满足不了你的实时检测需求。

• 方案2（Foreground Service）的优势：
  前台服务拥有系统高优先级，通过持续显示通知栏提示（Android强制要求），可避免被系统内存清理机制杀死，能稳定保证后台15秒轮询的执行频率，完全匹配你的需求。前台时切换回原有逻辑，还能减少不必要的系统资源占用。

具体实现建议 #

1. 前后台状态监听 #

使用ProcessLifecycleOwner监听应用前后台状态，替代Activity的onPause/onStop（避免多Activity场景下的逻辑混乱）：

ProcessLifecycleOwner.get().lifecycle.addObserver(object : DefaultLifecycleObserver {
    override fun onStart(owner: LifecycleOwner) {
        // 应用回到前台：停止前台服务，启动原有TimerTask/Coroutine轮询
        stopForegroundService()
        startForegroundPolling()
    }

    override fun onStop(owner: LifecycleOwner) {
        // 应用退到后台：停止原有轮询，启动前台服务
        stopForegroundPolling()
        startBackgroundForegroundService()
    }
})

2. 前台服务实现 #

在前台服务中使用Coroutine或ScheduledExecutorService替代TimerTask（TimerTask存在线程泄漏风险，Android官方不推荐）：

class PollingForegroundService : Service() {
    private val job = Job()
    private val scope = CoroutineScope(Dispatchers.IO + job)

    override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int {
        // 创建前台通知（必须）
        val notification = NotificationCompat.Builder(this, "POLLING_CHANNEL")
            .setContentTitle("后台检测中")
            .setContentText("正在监控数据变化")
            .setSmallIcon(R.drawable.ic_notification)
            .setPriority(NotificationCompat.PRIORITY_LOW) // 低优先级减少打扰
            .build()

        startForeground(1, notification)

        // 每15秒执行一次API调用
        scope.launch {
            while (isActive) {
                runCatching {
                    // 调用getStatus、readyToGetDataCall接口
                    val status = getStatus()
                    val data = readyToGetDataCall()
                    // 检测数据变化，播放提示音
                    if (dataChanged(status, data)) {
                        playNotificationSound()
                    }
                }.onFailure {
                    // 处理网络异常，避免轮询中断
                    it.printStackTrace()
                }
                delay(15_000)
            }
        }

        return START_STICKY
    }

    override fun onDestroy() {
        super.onDestroy()
        job.cancel()
    }

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

3. 权限配置 #

在AndroidManifest.xml中声明必要权限与服务：

<uses-permission android:name="android.permission.FOREGROUND_SERVICE" />
<uses-permission android:name="android.permission.POST_NOTIFICATIONS" /> <!-- Android 13+ 通知权限 -->
<service android:name=".PollingForegroundService" />

4. 优化细节 #

• 通知栏可允许用户手动关闭，但需提示用户：关闭通知后后台检测可能失效。
• 轮询逻辑中加入指数退避重试，避免单次网络失败导致检测中断。
• 若设备处于低电量模式，可根据业务需求适当降低轮询频率，减少耗电。

总结 #

方案2能稳定满足后台持续15秒轮询的需求，是当前FCM不可用情况下的最优解。

内容的提问来源于stack exchange，提问作者Takeshi567