本文介绍如何使用 workmanager 实现每 30 分钟定时拉取 openweathermap 天气数据、同步处理 ble 温度数据，并基于双源数据联动触发自定义业务逻辑，兼顾系统兼容性、省电性与可靠性。
本文介绍如何使用 workmanager 实现每 30 分钟定时拉取 openweathermap 天气数据、同步处理 ble 温度数据，并基于双源数据联动触发自定义业务逻辑，兼顾系统兼容性、省电性与可靠性。
在 Android 平台上构建具备“感知—判断—响应”能力的物联网类应用（如融合 BLE 温度传感器与天气 API 的智能环境监控 App），关键在于可靠、省电且可调度的数据获取机制，以及灵活可维护的条件判断逻辑。WorkManager 是 Google 官方推荐的、适用于延迟执行、周期性、需保证完成的后台任务解决方案，完美契合本场景中“每 30 分钟拉取天气数据 + 融合本地 BLE 数据 + 执行条件任务”的核心需求。
✅ 为什么首选 WorkManager？
- 系统兼容性强：自动适配 Android 5.0（API 21）及以上，对 Doze 模式、App Standby、后台执行限制等均有健壮应对。
- 保证执行语义：即使设备重启、进程被杀，已入队的周期任务仍能恢复执行（需设置 setExpedited(false) + setConstraints() 合理约束）。
- 支持链式与并行任务：可分别定义 WeatherFetchWorker 和 BleDataSyncWorker，再通过 WorkContinuation 协同；也可在单个 Worker 内统一协调双源数据。
- 不依赖前台服务或 Foreground Service：避免弹出持续通知、权限申请及用户打扰。
?️ 实现步骤（代码示例）
1. 添加依赖（app/build.gradle）
implementation 'androidx.work:work-runtime-ktx:2.9.0'
2. 创建周期性天气获取 Worker
class WeatherFetchWorker(
context: Context,
params: WorkerParameters
) : CoroutineWorker(context, params) {
override suspend fun doWork(): Result {
return try {
val apiKey = inputData.getString("API_KEY") ?: return Result.failure()
val cityId = inputData.getString("CITY_ID") ?: return Result.failure()
// 调用 Retrofit/Ktor 获取 OpenWeatherMap 数据
val response = withContext(Dispatchers.IO) {
WeatherApiService.getInstance().getCurrentWeather(cityId, apiKey)
}
if (response.isSuccessful && response.body() != null) {
val weatherData = response.body()!!
// 保存至 Room 或 DataStore
applicationContext.dataStore.saveWeather(weatherData)
// 触发后续数据比对逻辑（可选：通过 LiveData/EventBus/Callback 通知 UI 或启动决策 Worker）
Result.success()
} else {
Result.retry() // 网络失败时按退避策略重试
}
} catch (e: Exception) {
Result.failure()
}
}
}3. 配置并启动周期任务（建议在 Application 或首次启动时注册）
fun scheduleWeatherSync(context: Context) {
val constraints = Constraints.Builder()
.setRequiredNetworkType(NetworkType.CONNECTED)
.setRequiresBatteryNotLow(true)
.build()
val workRequest = PeriodicWorkRequestBuilder<WeatherFetchWorker>(30, TimeUnit.MINUTES)
.setConstraints(constraints)
.setInputData(workDataOf(
"API_KEY" to BuildConfig.OPENWEATHER_API_KEY,
"CITY_ID" to "2950159" // Berlin 示例
))
.build()
WorkManager.getInstance(context)
.enqueueUniquePeriodicWork(
"weather_sync",
ExistingPeriodicWorkPolicy.KEEP, // 避免重复注册
workRequest
)
}4. 数据融合与条件执行（推荐方案）
⚠️ 注意：不建议在 Worker 中直接执行耗时 UI 操作或启动 Activity。应将决策逻辑封装为纯函数，结果通过以下方式响应：
- 更新 LiveData / StateFlow，由 UI 层监听并弹窗/通知；
- 发送 Notification（需声明 POST_NOTIFICATIONS 权限）；
- 触发 BroadcastReceiver（用于跨进程轻量通信）；
- 写入数据库后由 WorkManager 启动一个 one-off Worker 专门处理响应动作（如发送 MQTT 指令、切换设备模式）。
例如，在 WeatherFetchWorker 成功后，可追加一个决策 Worker：
// 在 WeatherFetchWorker#doWork 成功后：
val decisionWork = OneTimeWorkRequestBuilder<DecisionWorker>()
.setInputData(workDataOf("TRIGGER_REASON" to "weather_updated"))
.build()
WorkManager.getInstance(context)
.beginWith(decisionWork)
.enqueue()DecisionWorker 内部可同时读取最新天气数据（Room）和最近 BLE 温度（如 DataStore 或 SharedPreferences 缓存），执行规则判断：
if (weather.temp > 30.0 && bleTemp > 35.0) {
sendAlertNotification("高温预警：室内外温度均超阈值！")
activateCoolingSystem() // 自定义业务方法
Result.success()
}❗ 关键注意事项
- BLE 数据同步时机：WorkManager 不适合高频 BLE 通信（如每秒收包）。请使用 BluetoothGattCallback 在前台 Service 或 ViewModel 中实时监听；仅将聚合后的快照数据（如过去 5 分钟平均温度）供周期任务消费。
- 最小周期限制：PeriodicWorkRequest 最小间隔为 15 分钟，30 分钟完全合规；若需更短周期（如 5 分钟），需改用 AlarmManager（Android
- 规则引擎？非必需：对于中低复杂度条件（如 IF temp > X AND weather == "Rain" THEN doY()），直接使用 Kotlin when 表达式或简单规则 DSL（如 Drools Lite）即可；仅当规则数量达百级、需热更新或业务人员配置时，才引入完整规则引擎。
- 错误处理与监控：务必为 WorkRequest 设置 setBackoffCriteria()，并在 Result.retry()/failure() 中记录日志（如 Timber.e()），便于问题追溯。
✅ 总结
WorkManager 是实现“30 分钟天气轮询 + BLE 数据联动响应”这一典型 IoT 场景的最优实践方案。它以声明式 API 降低后台任务开发复杂度，同时保障系统级健壮性。开发者应聚焦于数据建模（统一时间戳、标准化单位）、条件逻辑抽象（高内聚低耦合）、以及响应动作解耦（Worker → UI/Notification/Other Worker），从而构建出可演进、易测试、符合现代 Android 架构规范的智能应用。
