Android11部分设备切前台时ConnectivityManager.activeNetwork偶发为空如何解决

• 厂商定制ROM的服务同步延迟：Android 11对后台应用的网络权限做了收紧，三星One UI等定制ROM在此基础上做了额外的进程资源优化，应用从后台切回前台时，系统ConnectivityService和应用进程的网络状态同步存在100-300ms的延迟，此时主动查询activeNetwork会返回空值，属于厂商层面的实现缺陷。
• 生命周期时序差：onStart是应用从不可见转为可见的过渡阶段，此时应用还未完全获得前台服务的访问权限，部分厂商的网络状态刷新逻辑晚于onStart回调执行，主动查询拿到的是切后台前的缓存状态或者未初始化的空值。
• 临时权限回收：Android 11引入的应用缓存机制会在应用退后台时临时收回网络状态查询的部分权限，切回前台时权限恢复存在毫秒级的时间差，时间窗口内查询就会触发空值问题。

最优方案：使用NetworkCallback替代主动查询 #

主动查询网络状态本身就存在时序差问题，改用系统回调的方式能完全规避该问题，适配所有Android版本：

// 全局声明网络回调
private val networkCallback = object : ConnectivityManager.NetworkCallback() {
    override fun onAvailable(network: Network) {
        super.onAvailable(network)
        // 确认网络可用后执行API请求，注意切回主线程更新UI
        runOnUiThread {
            // 执行业务逻辑
        }
    }

    override fun onLost(network: Network) {
        super.onLost(network)
        // 网络断开时执行提示逻辑
        runOnUiThread {
            showNoNetworkDialog()
        }
    }
}

// onStart中注册回调
override fun onStart() {
    super.onStart()
    val cm = getSystemService(Context.CONNECTIVITY_SERVICE) as ConnectivityManager
    val networkRequest = NetworkRequest.Builder()
        .addTransportType(NetworkCapabilities.TRANSPORT_CELLULAR)
        .addTransportType(NetworkCapabilities.TRANSPORT_WIFI)
        .addTransportType(NetworkCapabilities.TRANSPORT_BLUETOOTH)
        .build()
    cm.registerNetworkCallback(networkRequest, networkCallback)
}

// onStop中注销回调，避免内存泄漏
override fun onStop() {
    super.onStop()
    val cm = getSystemService(Context.CONNECTIVITY_SERVICE) as ConnectivityManager
    cm.unregisterNetworkCallback(networkCallback)
}

临时修复方案：短延迟重试 #

如果不想改动原有逻辑，可以在原有isConnected方法返回false时，增加1-2次延迟重试，每次间隔150ms，大部分场景下都能覆盖厂商的同步延迟窗口。

// 调用处示例
lifecycleScope.launch {
    var isNetworkAvailable = isConnected()
    if (!isNetworkAvailable) {
        // 重试2次，每次间隔150ms
        repeat(2) {
            delay(150)
            isNetworkAvailable = isConnected()
            if (isNetworkAvailable) return@repeat
        }
    }
    if (isNetworkAvailable) {
        // 调用API
    } else {
        // 弹无网络弹窗
    }
}

100-200ms的短延迟方案是可行的，可作为快速上线的临时修复手段，但不推荐长期使用：部分极端场景下厂商的同步延迟可能超过200ms，仍然会触发误判，而且固定延迟会无意义增加所有用户的接口请求等待时间，体验不如回调方案。

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