指定NetworkRequest网络条件后回调触发还需重复校验网络能力吗

问题场景 #

在Android端开发互联网连接状态监听逻辑时，通常的实现方式是先构建网络请求筛选对象，再通过ConnectivityManager注册网络回调，示例代码如下：

val networkCallback = createNetworkCallback()
val networkRequest = NetworkRequest.Builder()
    .addCapability(NET_CAPABILITY_INTERNET)
    .addTransportType(TRANSPORT_CELLULAR)
    .addTransportType(TRANSPORT_WIFI)
    .addTransportType(TRANSPORT_ETHERNET)
    .build()
connectivityManager.registerNetworkCallback(networkRequest, networkCallback)

上述networkRequest的筛选规则为：仅监听具备NET_CAPABILITY_INTERNET能力，且传输类型为蜂窝移动网络、Wi-Fi、以太网的网络。官方对registerNetworkCallback方法的注释明确说明：

Registers to receive notifications about all networks which satisfy the given NetworkRequest.
（注册以接收所有满足给定NetworkRequest条件的网络的通知）

核心疑问 #

按照官方注释的逻辑，只有完全符合NetworkRequest配置的筛选条件的网络，才会触发对应的回调。比如开关Wi-Fi时，只有当前网络属于指定传输类型、满足对应能力要求，网络回调才会执行。
目前的疑问是：当networkCallback触发时，是否还需要在回调内部再次校验网络的能力与传输类型？比如当前在onAvailable回调中写了如下校验逻辑：

override fun onAvailable(network: Network) {
    val networkCapabilities = cm.getNetworkCapabilities(network)
    val hasInternetCapabilities = networkCapabilities?.let {
        return@let it.hasCapability(NET_CAPABILITY_INTERNET) or
            it.hasTransport(TRANSPORT_WIFI) or
            it.hasTransport(TRANSPORT_CELLULAR) or
            it.hasTransport(TRANSPORT_ETHERNET)
    } ?: false
}

如果网络不满足预先设置的networkRequest筛选条件，onAvailable()就不会触发，那么回调内部的这段校验逻辑就是多余的，需要求证这个判断是否正确。

解答 #

你的理解完全正确，这段回调内的重复校验属于冗余代码，没有保留必要。

• ConnectivityManager的回调分发逻辑会严格匹配传入的NetworkRequest筛选规则，所有不满足你设置的能力、传输类型要求的网络，根本不会进入回调队列，onAvailable等回调方法只会针对符合筛选条件的网络触发。
• 需要注意一个容易混淆的点：NET_CAPABILITY_INTERNET仅代表网络理论上具备连接互联网的能力，不代表网络实际连通可用（比如连接了需要认证的公共Wi-Fi、移动网络欠费停机的场景，系统依然会标记网络具备NET_CAPABILITY_INTERNET能力）。如果你的业务需要判断网络是否真的可以访问业务服务，需要自行做端到端的连通性检测，但这和你当前写的重复校验传输类型、基础能力的逻辑无关。
• 额外提一句：你贴出的回调内校验逻辑本身存在逻辑错误，使用了or做或判断，只要满足「有互联网能力」「是WiFi」「是蜂窝网络」「是以太网」任意一个条件就会判定通过，和你最初在NetworkRequest中设置的「同时具备互联网能力+属于三类指定传输类型」的匹配规则不一致，就算要保留校验也需要修正逻辑，这也进一步说明这段冗余代码没有存在的价值。

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