Jetpack Compose宝可梦应用在Android12设备启动后无法加载API数据

问题现象 #

• 小米Mi 8 Lite（Android 10）：应用启动后宝可梦列表正常加载
• 小米Mi 11T Pro（Android 12）：启动后无内容显示，但存在两个触发加载的特殊场景：
  • 打开布局检查器后，数据立即加载完成
  • 点击空白屏幕1-2次后，应用发起请求并正常加载列表

可能的原因及排查方向 #

1. ViewModel初始化与Compose重组时机不匹配 #

检查PokemonListViewModel的init块是否直接触发了数据请求（比如调用loadPokemonList()）。Android 12对ViewModel初始化时机和Compose重组调度的逻辑有差异，可能导致初始请求发起时，Composable还未完成首次重组，状态更新无法触发UI刷新。

建议把初始化请求移到Composable的LaunchedEffect(Unit)中，确保UI完成首次组合后再触发加载：

// 在PokemonListScreen这类展示列表的Composable中添加
LaunchedEffect(Unit) {
    viewModel.loadPokemonList()
}

替代直接在ViewModel的init块中执行请求，能保证UI处于可接收状态时再发起数据请求。

2. Hilt注入的依赖初始化延迟问题 #

检查ViewModel依赖的Repository或数据源是否在Hilt注入时存在异步初始化延迟。Android 12的组件初始化调度逻辑可能导致依赖还未就绪，ViewModel就执行了数据请求，最终因依赖未初始化而无数据返回。

可以在ViewModel中通过@Inject构造函数接收依赖后，确保依赖完全初始化再触发请求；或者给暴露数据的StateFlow添加distinctUntilChanged()操作符，保证状态变化能被Compose正确收集。

3. Compose状态收集逻辑异常 #

确认ViewModel中用于暴露数据的StateFlow/LiveData是否被正确收集：

• 如果使用StateFlow，要确保在Composable中调用collectAsState()，且状态初始值设置合理（比如设为emptyList()而非null）
• 检查是否有filter这类操作符意外过滤了初始数据的发射，导致UI接收不到状态更新

4. Android 12行为变更的影响 #

Android 12对后台启动、UI线程调度有更严格的限制，检查数据请求是否在主线程阻塞，或者是否被StrictMode策略拦截延迟执行。可以临时关闭StrictMode测试：

// 在自定义Application的onCreate方法中添加
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.P) {
    StrictMode.setVmPolicy(StrictMode.VmPolicy.Builder().build())
}

如果关闭后恢复正常，说明是StrictMode拦截了相关操作，需要调整请求的执行方式。

5. 点击触发重组的逻辑分析 #

点击屏幕会触发Compose重组，说明数据状态其实已经存在，但初始时没触发UI更新。大概率是ViewModel的状态更新时机早于Composable的首次组合，导致Compose没观察到状态变化。这种场景下，用LaunchedEffect延迟触发请求就能解决问题。

总结建议 #

优先尝试将ViewModelinit块中的数据请求移到Composable的LaunchedEffect(Unit)中，这是解决跨版本重组时机问题最常见的方案。如果问题依旧，再逐步排查Hilt依赖初始化、状态收集逻辑以及Android 12的行为限制。

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