Android 如果我在网络请求中指定它们是否与判断网络功能相关

你说得对，onAvailable元的额外支票是不必要的.对于satisfy传入NetworkRequest的网络，平台只会发送onAvailable(否则，API将毫无意义).

以下是一些关于该主题的官方文件(link):

该应用程序构建一个NetworkRequest，通知ConnectionManager

NetworkRequest request = new NetworkRequest.Builder()
  .addCapability(NetworkCapabilities.NET_CAPABILITY_NOT_METERED)
  .addCapability(NET_CAPABILITY_INTERNET)
  .build();
connectivityManager.registerNetworkCallback(request, myNetworkCallback);

这将确保你的应用程序能够听到所有

Note the below is accurate at the time of writing this answer.

对于回调，在Android的连接堆栈中，它们被称为listen个请求，因此，如果您想了解它们与发送onAvailable的相互作用，那么processNewlySatisfiedListenRequests中应该是here个:

private void processNewlySatisfiedListenRequests(@NonNull final NetworkAgentInfo nai) {
        for (final NetworkRequestInfo nri : mNetworkRequests.values()) {
            if (nri.isMultilayerRequest()) {
                continue;
            }
            final NetworkRequest nr = nri.mRequests.get(0);
            if (!nr.isListen()) continue;
            if (nai.satisfies(nr) && !nai.isSatisfyingRequest(nr.requestId)) {
                nai.addRequest(nr);
                notifyNetworkAvailable(nai, nri);
            }
        }
    }

ConnectivityService控制了所有这些，这很难理解，但如果您遵循此处的代码路径，您将看到它来自方法computeNetworkReassignment here.

上面的重要代码行是:

bestNetwork = mNetworkRanker.getBestNetwork(req, nais, nri.getSatisfier());

深入到该方法中，您将看到它调用NetworkRanker，NetworkRanker针对最初传入的NetworkRequest运行satisfies:

final ArrayList<NetworkAgentInfo> candidates = filter(nais, nai -> nai.satisfies(request));

综上所述，您可以看到，如果您收到NetworkRequest的onAvailable分，那么它将满足最初传入的NetworkCapabilities分，因此无需再次判断以确认.