Android应用基于REST服务定期更新UI的实现难题

哥们，我太懂你这种卡在主线程限制和定时更新UI之间的憋屈了——Android对主线程的管控真的严，稍不留神就踩坑。你说的BroadcastReceiver+AlarmManager思路方向是对的，但大概率是实现细节没踩对，尤其是内部类的坑特别多，我给你拆解下正确的玩法：

首先得拎清两个核心规则：网络请求绝对不能碰主线程，而UI更新必须在主线程完成，这俩的衔接是关键。你之前的尝试没成功，大概率是踩了BroadcastReceiver的线程坑或者内部类的引用坑，下面给你一步步捋：

1. 先把网络请求挪到后台：别在BroadcastReceiver里硬刚 #

很多人容易犯的错：以为BroadcastReceiver是后台组件，其实它的onReceive方法是在主线程执行的！你要是在里面做网络请求，直接就触发NetworkOnMainThreadException。正确的做法是用专门的后台组件处理请求：

推荐用WorkManager（适配Android后台限制） #

WorkManager是Jetpack组件，比AlarmManager更懂Android的后台规则，能自动处理设备重启、Doze模式这些场景，示例代码如下：

class FetchDataWorker(context: Context, params: WorkerParameters) : CoroutineWorker(context, params) {
    override suspend fun doWork(): Result {
        // 这里放心做REST请求，比如用Retrofit/OkHttp
        val apiService = Retrofit.Builder()
            .baseUrl("https://你的API地址.com/")
            .addConverterFactory(GsonConverterFactory.create())
            .build()
            .create(你的API接口类::class.java)
        
        val response = apiService.getLatestData()
        if (response.isSuccessful) {
            // 请求成功后，把数据存到SharedPreferences/Room里
            val sharedPref = applicationContext.getSharedPreferences("AppData", Context.MODE_PRIVATE)
            sharedPref.edit().putString("latest_content", Gson().toJson(response.body())).apply()
            // 发广播通知UI更新
            LocalBroadcastManager.getInstance(applicationContext)
                .sendBroadcast(Intent("DATA_REFRESHED"))
            return Result.success()
        } else {
            // 请求失败可以重试
            return Result.retry()
        }
    }
}

2. 设置定期任务：用WorkManager替代AlarmManager #

AlarmManager在Android 6.0+之后受Doze模式限制很大，WorkManager的定期任务更靠谱，示例代码：

// 在MainActivity或者Application类里初始化任务
val periodicTask = PeriodicWorkRequestBuilder<FetchDataWorker>(15, TimeUnit.MINUTES)
    .build()
WorkManager.getInstance(this).enqueueUniquePeriodicWork(
    "FetchDataJob",
    ExistingPeriodicWorkPolicy.KEEP,
    periodicTask
)

注意：Android 12+规定后台定时任务最短周期是15分钟，要是你需要更频繁的更新，得考虑用前台服务（但要注意别打扰用户）

3. 在MainActivity里接收更新并刷新UI #

如果还是想用BroadcastReceiver，别用非静态内部类（会持有Activity引用导致内存泄漏），要么用静态内部类+弱引用，要么直接在Activity里动态注册：

class MainActivity : AppCompatActivity() {
    private lateinit var dataReceiver: BroadcastReceiver

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        // 初始化广播接收器
        dataReceiver = object : BroadcastReceiver() {
            override fun onReceive(context: Context?, intent: Intent?) {
                if (intent?.action == "DATA_REFRESHED") {
                    // 从存储里取数据，更新UI（这里是主线程，放心操作）
                    val sharedPref = getSharedPreferences("AppData", MODE_PRIVATE)
                    val latestContent = sharedPref.getString("latest_content", "暂无数据")
                    findViewById<TextView>(R.id.tv_content).text = latestContent
                }
            }
        }

        // 注册本地广播
        LocalBroadcastManager.getInstance(this).registerReceiver(
            dataReceiver,
            IntentFilter("DATA_REFRESHED")
        )
    }

    override fun onDestroy() {
        super.onDestroy()
        // 一定要注销广播，避免内存泄漏
        LocalBroadcastManager.getInstance(this).unregisterReceiver(dataReceiver)
    }
}

你之前用内部类可能踩的坑 #

• 非静态内部类的内存泄漏：非静态内部类会持有外部Activity的强引用，Activity销毁后接收器还活着，不仅内存泄漏，还可能导致接收器无法正常触发。
• 在BroadcastReceiver里做耗时操作：onReceive在主线程，网络请求直接抛异常，必须把耗时操作移到后台线程。
• AlarmManager的后台限制：Android 6.0+的Doze模式会延迟AlarmManager的任务，不如WorkManager适配性强。

更优雅的进阶方案：LiveData+ViewModel+WorkManager #

如果想贴合Jetpack架构，推荐用LiveData自动观察数据变化：

1. 把数据存在Room数据库
2. 用ViewModel获取Room的LiveData
3. WorkManager定期请求数据并更新Room
4. Activity观察LiveData，自动刷新UI
   这种方式不用手动处理广播，代码更简洁，也更符合Android的架构规范。

内容的提问来源于stack exchange，提问作者Douglas B. Staple