Android 定时任务：AlarmManager、WorkManager 实现定时采集、定时重启服务

Android 定时任务AlarmManager、WorkManager 实现定时采集、定时重启服务在工控领域定时二字就是生产力——定时采数据、定时喂狗、定时重启活脱脱一个按时作息的工厂老黄牛。今天咱就来聊聊 Android 上那些定时任务的祖宗八代。一、Android 定时任务方案演进Android 定时任务的演进史堪比一部旧工具翻车实录方案适用场景局限性java.util.Timer简单定时前台任务进程被杀就歇菜不适合后台长任务Handler.postDelayed()UI线程延时任务依赖消息队列进程死亡即失效AlarmManager精确定时唤醒系统级API 版本碎片化Doze 模式影响JobScheduler(API 21)省电、条件组合任务仅 5.0不兼容低版本WorkManager(Jetpack)延迟可靠任务兼容全版本不适合精确到秒的定时1.1 Timer——被抛弃的老前辈TimertimernewTimer();timer.scheduleAtFixedRate(newTimerTask(){Overridepublicvoidrun(){// 采集数据}},0,5000);// 每5秒Timer 的问题进程一死Timer 清零。工控设备跑了三天被系统回收采集线程直接嗝屁跟没写一样。而且 Timer 不支持 CPU 休眠唤醒Doze 模式一来直接罢工。二、AlarmManager 详解AlarmManager 是 Android 系统级的闹钟服务即使 App 进程被杀系统也会在指定时间启动你的组件。2.1 核心时钟类型AlarmManageram(AlarmManager)getSystemService(ALARM_SERVICE);// 1. RTC_WAKEUP — 基于系统时间能唤醒CPUPendingIntentpiPendingIntent.getBroadcast(...);am.setExact(AlarmManager.RTC_WAKEUP,triggerAtMillis,pi);// 2. RTC — 基于系统时间不唤醒CPUam.setExact(AlarmManager.RTC,triggerAtMillis,pi);// 3. ELAPSED_REALTIME_WAKEUP — 基于开机时间能唤醒am.setExact(AlarmManager.ELAPSED_REALTIME_WAKEUP,elapsedMillis,pi);简单说带 WAKEUP 的能叫醒设备不带的不行。工控场景用 RTC_WAKEUP 最多——凌晨三点重启服务设备休眠也得爬起来干活。2.2 注意 API 版本差异API 19-22setRepeating()不再精确系统会批量对齐闹钟省电API 23Doze 模式限制setExactAndAllowWhileIdle()才能突破低电耗API 31setExact()需要SCHEDULE_EXACT_ALARM权限uses-permissionandroid:nameandroid.permission.SCHEDULE_EXACT_ALARM/2.3 工控实战定时重启采集服务publicclassRebootReceiverextendsBroadcastReceiver{OverridepublicvoidonReceive(Contextcontext,Intentintent){IntentserviceIntentnewIntent(context,CollectService.class);context.stopService(serviceIntent);// 延迟 2 秒重启确保旧服务完全释放newHandler().postDelayed(()-{context.startService(serviceIntent);},2000);}}// 设置每天凌晨 3 点重启publicvoidscheduleReboot(Contextcontext){CalendarcalendarCalendar.getInstance();calendar.set(Calendar.HOUR_OF_DAY,3);calendar.set(Calendar.MINUTE,0);calendar.set(Calendar.SECOND,0);AlarmManageram(AlarmManager)context.getSystemService(Context.ALARM_SERVICE);IntentintentnewIntent(context,RebootReceiver.class);PendingIntentpiPendingIntent.getBroadcast(context,0,intent,PendingIntent.FLAG_UPDATE_CURRENT|PendingIntent.FLAG_IMMUTABLE);am.setExactAndAllowWhileIdle(AlarmManager.RTC_WAKEUP,calendar.getTimeInMillis(),pi);}三、WorkManager——Jetpack 的可靠任务管家WorkManager 是 Google 钦点的后台任务方案内部根据 API 版本自动选择底层实现底层还是 AlarmManager 或 JobScheduler。核心优势任务持久化存数据库重启不丢约束条件网络、电量、空闲状态组合链式任务A 完成 → B 开始3.1 依赖引入implementationandroidx.work:work-runtime:2.9.03.2 工控实战定时数据采集// 定义采集任务publicclassCollectWorkerextendsWorker{publicCollectWorker(NonNullContextcontext,NonNullWorkerParametersparams){super(context,params);}NonNullOverridepublicResultdoWork(){// 读取串口数据byte[]dataSerialPortHelper.read(/dev/ttyS1);// 处理并上报DataManager.processAndReport(data);returnResult.success();}}// 启动周期采集 — 每 15 分钟执行一次PeriodicWorkRequestcollectRequestnewPeriodicWorkRequest.Builder(CollectWorker.class,15,TimeUnit.MINUTES)// 最小间隔 15 分钟.setConstraints(newConstraints.Builder().setRequiredNetworkType(NetworkType.CONNECTED)// 有网才跑.build()).addTag(collect_task).build();WorkManager.getInstance(context).enqueueUniquePeriodicWork(periodic_collect,ExistingPeriodicWorkPolicy.KEEP,// 已存在则复用collectRequest);注意WorkManager 最小周期间隔是 15 分钟。如果需要秒级采集比如每 5 秒读串口应该用Handler.postDelayed()在 Service 内部循环别指望 WorkManager。四、方案选择指南需求推荐方案秒级定时采集Service Handler 循环分钟级周期任务WorkManager凌晨定时重启AlarmManager精确唤醒联网才执行的任务WorkManager 约束条件跨进程保活任务AlarmManager 前台 Service五、工控最佳实践采集服务用前台 Service绑 Notification降低被杀概率AlarmManager BroadcastReceiver 做唤醒入口内部启动 Service 干活WorkManager 处理分钟级上报、日志清理等非实时任务Timer 只用于测试 Demo生产环境碰都别碰重启服务前先 stopService否则可能造成串口资源未释放工控定时任务的本质让设备像瑞士钟表一样可靠运转。选对工具按时吃饭机器才不闹脾气。