开发工作时长统计App遇难题：Foreground Service计时异常且易被系统终止

一、解决计时显示误差与TimerTask异常问题 #

核心问题在于依赖本地累加（Thread.sleep/TimerTask）的方式会因系统调度延迟累积误差，正确思路是基于系统时间戳计算时长，而非本地计数：

• 放弃Thread.sleep(1000)或TimerTask累加计时的逻辑，改为存储计时的起始时间戳（如存入SharedPreferences或Room数据库）。
• 每次更新UI时，通过当前系统时间与起始时间戳的差值计算真实时长，示例代码：

// 从持久化存储读取起始时间戳
val startTime = sharedPref.getLong("start_time", 0L)
// 计算已流逝时长（毫秒）
val elapsedMs = System.currentTimeMillis() - startTime
// 转换为时分秒格式
val hours = elapsedMs / 3600000
val minutes = (elapsedMs % 3600000) / 60000
val seconds = (elapsedMs % 60000) / 1000

• 若要实现秒表实时跳动的视觉效果，用Handler.postDelayed或协程delay每500ms刷新一次UI即可，每次刷新都重新计算时间差，避免本地累加的误差。

二、解决Foreground Service被杀死后计时重置问题 #

单纯依赖Service内存状态不可靠，需结合持久化存储+系统级任务调度保障计时连续性：

1. 关键状态持久化
   启动计时时，将以下数据存入SharedPreferences/Room：

   • start_time：计时开始的系统时间戳
   • is_running：标记当前是否处于计时状态
   • 若支持暂停功能，额外存储paused_elapsed：暂停时已流逝的总时长
     每次状态变化（开始/暂停/结束）都更新持久化数据。

2. Service重启恢复逻辑
   当Foreground Service被系统杀死重启时，先读取持久化的is_running状态：

   • 若为true，用当前系统时间减去start_time直接计算已流逝时长，无需从头开始计时
   • 若有暂停记录，叠加paused_elapsed后再计算当前时长

3. 用WorkManager补充保活

   • 注册周期性Work（如每15分钟执行一次），任务内检查is_running状态，若处于计时中，可更新一次持久化的"最后校验时间"，或直接重新计算当前时长并存储（确保状态不丢失）
   • 利用WorkManager的后台执行能力，在App被杀死后仍能维持状态校验，必要时触发Foreground Service重启

4. 优化Foreground Service生存概率

   • 给Service设置高优先级通知，显示当前计时状态（让系统感知到服务的用户可见性，降低被杀死概率）
   • Android 12+需在Manifest中指定android:foregroundServiceType（如dataSync或workManager），符合系统权限要求
   • 监听ACTION_BOOT_COMPLETED广播，手机重启后读取is_running状态，自动重启Foreground Service并恢复计时

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