大多数浏览器和
Developer App 均支持流媒体播放。
-
根据网络条件的变化自行调整
Apple 设备可以同时连接到多个网络。了解 App 如何自动选择最佳网络以提供出色的体验。探索不同类型的网络并回顾其特征。探索如何使用 URLSession 和 Network 框架最恰当地描述你的需求,以便系统可以随时为 App 智能地选择最佳接口。
资源
相关视频
WWDC21
-
下载
Eric Kinnear:大家好 我叫 Eric 我来自 互联网技术团队 今天我们将介绍 你的 App 如何根据 网络条件的变化自行调整 我们将通过了解 不同类型的网络及其独特属性 来深入探究这方面的内容 我们将介绍 如何使用 Apple 平台上的 API 向系统描述 你的联网需求 我们将探讨 当无法立即联网时 App 如何确定 何时再次尝试连接 最后 我们将深入了解 如何在各种网络条件下 进行测试 以确保使用 App 的 每个人 都可以获得 最佳体验 我们首先 来谈谈网络 Apple 设备通常 可以通过多种方式 连接到网络 例如蜂窝网络或 Wi-Fi 如果设备只有 蜂窝网络连接 互联网流量 当然可以使用这一接口 设备加入 Wi-Fi 网络后 你往往会认为 互联网流量 会改用 这一接口 不过现在设备 至少有两个不同的接口 可以使用 某些协议和 App 可以使用任一接口 甚至可以同时使用 这两个接口 现有连接可能会收到 有关存在更优路由方案的通知 指出它们 应该考虑使用 新的连接 进行后续通信 例如 App 可以使用 多路径 TCP 和 QUIC 等 多路径技术 来创建连接 以便在连接断开时 在蜂窝网络和 Wi-Fi 之间 无缝迁移 如果在当时的条件下 使用 5G 网络可以带来更好的体验 App 也可以使用 5G 网络 而不是 Wi-Fi 网络具有 不同的属性 因此适用于 不同类型的用途 例如 一些蜂窝网络的 使用成本可能很高 数据套餐按流量计费 而其他网络可能没有限制 同样地 某些 Wi-Fi 网络不应 用于批量数据传输 例如在连接到个人热点时 有人可能已将连接 置于低数据模式 这表明他们希望 限制数据使用 其他网络资源可能 仅在系统能够正常开放 另一接口后才可用 例如开放 VPN iPhone 或 iPad 甚至还可能 为 App 提供了 以太网连接 有许多不同类型的连接 可用于设备 以上只列举了 几个示例 幸运的是 你的 App 无需考虑 各种不同的组合 即可打造最佳体验 Apple 平台 会为 App 连接 智能地选择最佳接口 要充分利用这一功能 只需向系统 描述 App 的 联网需求即可 我们来探讨一下如何实现 要考虑所有这些 网络类型 以做出选择 最佳方法是 分析网络属性 而不是网络类型 这样一来 系统就能 在这些组合中 为 App 连接 选择最合适的接口 有两个 网络属性 可用于声明 联网需求 只需使用这两个属性 你的 App 就能尊重 用户的偏好 了解他们希望 App 如何使用可用的网络 当有人通过启用低数据模式 来要求 App 减少数据使用时 就会出现受限网络 系统会自动为个人热点 启用低数据模式 当使用 Network 框架时 对 URLSessionConfiguration 使用 allowsConstrainedNetworkAccess 并使用 prohibitsConstrainedPaths 来确定是否 应使用受限网络来继续运行 一般来说使用受限网络时 App 应该限定 仅传输较小的有效负载 并且仅执行用于实现 用户显式操作的任务 使用受限网络时 不应执行 批量传输 以及后台预取 此外 网络的使用成本 可能很高 类似的逻辑在这种情况下同样适用 这些网络应该 只用于用户发起的操作 通过 URLSession 和 NetworkFramework 中的类似 API 你可以允许或禁止 使用这些网络 考虑对受限网络 和成本较高的网络 使用类似的逻辑 现在你已经 根据网络属性 描述了你的连接 应该使用的网络类型 接下来你应该 立即尝试连接 在连接之前 你往往会检查 设备使用的是 Wi-Fi 还是 接入了 VPN 但是应避免这样做 网络条件 经常变化 这些变化甚至可能是 由 App 的请求触发的 这意味着 执行预检往往是错误的 可能会导致 App 出现意外不到的行为 事实上 使用 SCNetworkReachability 进行预检的做法在 iOS 17.4 中 已被弃用 取而代之的是尝试连接 如果系统 因当前网络条件 而无法立即满足请求 那么对 URLSessionConfiguration 使用 waitsForConnectivity 或对 NW 连接 使用等待状态 意味着 系统会告知你 任务处于等待状态 当条件发生变化时 系统会自动 重新尝试发起请求 由于系统可以 自动等待建立连接 因此它很容易就能知道 何时再次尝试发起请求 我们来探讨一下 在这种情况下该怎么做 在使用 waitsForConnectivity 的情况下 如果系统无法立即发起网络请求 请求将被置于 等待状态 App 将通过 urlSession 任务委托 收到有关任务正在等待 建立连接的通知 在这种情况下 当连接性发生变化时 你不必再次重新尝试发起请求 系统会自动 这样做 当某项任务 等待建立连接时 请考虑 告知用户原因 以帮助他们了解情况 并采取必要的措施 并为用户提供 继续使用 App 的方式 在本例中 当设备连接到 非受限网络时 App 的数据将自动同步 不过轻点 “Sync Now”(立即同步) 将放开这一限制 在受限网络中执行同步 在通报 网络条件时 应慎用警报 警报传达 重要信息 但由于网络条件 往往不受用户控制 因此警报可能具有 干扰性和迷惑性 应该提供 信息和选项 同时提供明确简便的 处理方法 最后 我们来讨论测试 用户在使用你的 App 时 会遇到各种不同的 网络条件 因此测试多种不同的条件 至关重要 你可以直接在 Xcode 的 “Devices and Simulators” (设备和模拟器) 窗口中 模拟不同的网络条件 例如你可以选择 网络链接条件 和 LTE 描述文件 这样将模拟 一般条件下的典型 LTE 网络 然后 你可以测试 App 中的工作流程 以确保一切操作都 顺畅无阻 要在 iPhone 或 iPad 上测试 App 可以使用 “开发者”设置中的 “网络链接调节器” 在这里 你可以像在 Xcode 中那样 模拟网络条件 你可以使用 “网络覆盖” 来模拟设备网络 属性的变化 你可以随时使用 每个接口的设置 来启用低数据模式 在这里 你可以设置 你认为系统中的 蜂窝网络 和 Wi-Fi 接口 成本高昂 还是成本低廉 你还可以将系统配置为 首选 5G 网络 而不是信号差或不安全 Wi-Fi 这样你就可以找出 在哪些情况下 旧联网代码 可能无法 利用 性能更好的连接 好消息是 只要 App 遵循 我们刚刚介绍的 最佳做法 并向 Network 框架 和 urlSession 描述其需求 系统就会智能地 选择最佳接口 无需执行额外的操作 现在是时候 采用现代联网做法了 这样可以利用 设备的所有网络接口 为此 请通过属性 向系统描述 你的联网需求 例如使用受限网络时 是否适合 发出请求 避免将请求 限定到特定接口 例如 Wi-Fi 或蜂窝网络 在 App 中 取消联网预检 并使用 waitsForConnectivity 而不是手动重试 这样当条件满足 App 的需求时 联网就会 自动恢复 还应该确保 你的 App 使用的是 速度较快的现代协议 例如 HTTP/3 和 QUIC 要进一步了解 请观看“通过 HTTP/3 和 QUIC 加快联网速度” 通过这种方法 你的 App 将根据 网络条件的变化自动自行调整 联网行为 并提供 最佳体验 谢谢观看!
-
-
正在查找特定内容?在上方输入一个主题,就能直接跳转到相应的精彩内容。
提交你查询的内容时出现错误。请检查互联网连接,然后再试一次。