为今日的互联网环境优化您的 App

女士们 先生们 早上好 你们中有多少人 是第一次来 WWDC

非常棒 每年都能见到一些新面孔 实在是太好了 我是 Stuart Cheshire 我们将会讨论网络

我会先从影响你的 App 性能的 一些话题开始 如今完全不利用网络的 App 已经几乎没有了 而让网络性能 达到最优非常重要 我们会讲到 可以帮助你优化 网络性能的一些技术

也会讲到一些有用的提示和方法 来指导你如何最大程度地利用 Apple 的 API 以及关于 即将到来的新技术的一些信息 然后我的同事 Jiten 将会更详细地 讲解 URLSession

我们先从互联网的 近况说起 今年早些时候 使用互联网的人数 达到了 40 亿 超过了世界人口的一半 我们早已习惯了 互联网使用人数的不断翻倍 而当已经超过一半时 显然互联网使用人数 不可能继续翻倍 所以 互联网使用人数增长的速度在减缓 但并不意味着 互联网的发展会减缓 在机器对机器通讯 物联网以及 智能家庭方面 仍然有很高的增长率 另外 在一些地方 例如印度和中国 仍然有很高的增长率

并且仍然有很多人 从未拥有过一台桌面计算机 甚至未来也不会拥有 自己的桌面计算机 他们主要的计算 和通讯设备 是他们的智能手机 而这些智能手机中 很多都仍在使用 2G 网络 我相信这间屋子里的绝大多数 都足够幸运 居住的地方 工作的地方 以及开发我们的 App 的地方 都有快速的 LTE 网络 而这可能会成为一个短板 因为如果你开发 App 时 考虑的是它在 LTE 下运行良好 它可能在 2G 下表现得非常糟糕 在世界的另一个角落 你的某个竞争对手 开发的 App 在 2G 下运行良好 那么在 LTE 下会表现得更为出色 所以我们有了一个工具 可以让所有人都模拟 那些较慢网络的 一些特性 这就是 Network Link Conditioner 从开发 App 的第一刻起 就应该运行 Network Link Conditioner 不要认为你可以 到最后再来改善性能 因为到时就来不及了 请一定一直记得 使用 Network Link Conditioner 来运行和测试你的 App 这样的话 如果程序中有个错误 带来了糟糕的性能问题 你马上就能发现它 并且立刻修复

使用像 Wireshark 和 tcptrace 的工具 来弄清楚你的 App 的网络性能 这很像是用 Instruments 来查看 内存和 CPU 的占用情况 如果你还没用过 tcptrace 这个工具可以 生成像这样的图表 让你一眼就看清楚 网络上进行中的事 如果你想要了解更多 请查看三年前的视频 IPv6 的使用率持续上升 为什么这很重要 这是因为 IPv6 比 IPv4 的性能 表现更好 所以如果你在意性能 你应该确保 不仅你的 App 还有你的 App 使用的网络服务 支持原生 IPv6 在这方面 有些地方的情况比其他地方好一些 在美国 已经有 87% 的 移动运营商支持 IPv6 其他地方 例如印度 也非常好 那么我们现在来看看印度 这里是今年早些时候 Apple 的网络团队 收集到的一些数据 有关印度蜂窝移动网络下 TCP 网络连接建立时长 以及持续的往返延迟 蓝色的线是 IPv6 举例来说 如果我们 观察 75% 这里 可以看出 IPv6 上 75% 的 TCP 连接 在 150 毫秒内建立完成 而相应的 在 IPv4 上则超过 325 毫秒 比 IPv6 慢了不止一倍 因此如果你想要为你的用户 提供响应速度快的 App 请采用 IPv6

另一项通过 降低丢包率和重发率 来提升性能的技术 是 Explicit Congestion Notification 我们在 macOS 和 iOS 上 默认启用这项技术 已经有些年了 因此想要利用这项技术 你不需要在你的 App 中 进行额外操作 不过要确保你的服务支持 ECN 我们调研了 Alexa 前一百万网站 发现截止上月 前一百万服务中有 77% 已经 支持了 ECN 相比几年前 这是个很大的进步 另一项帮助你提升 连接的性能和 弹性的技术 是多路 TCP 用户常常可能在 办公室的 Wi-Fi 下发起连接 然后走出办公室 就丢失了 Wi-Fi 信号 如果是传统 TCP 连接就断了 必须重新连接 重新开始发起 多路 TCP 以包为单位 做数据包的路由选择 而不是以连接为单位 所以可以即时把连接 转向另一个接口

去年我们讨论了如何 00:06:08.416 --> 00:06:09.876 A:middle 在你的 App 中启用这项技术

当然 请和你的 服务器运营商 确认你的服务器也支持多路

我们最近调查了 全世界与 Apple 合作的 移动运营商 其中 78% 支持多路 TCP 只有 22% 的运营商 仍限制多路连接 TCP Fast Open 是一项 可以让你避免通常情况下 TCP 连接建立时的 往返延迟的技术 TCP Fast Open 可以让你 把初始数据放在 连接建立数据包里

你可以在三年前的 视频中找到更多相关信息 也请和你的 服务器运营商 确认支持 TCP Fast Open 现在我们来说讲一些新消息 你们中很多人应该 听说过一个技术 叫做 QUIC 这是一种新的传输协议 也是近 30 年来 第一个真正意义上的 可能取代 TCP 的候选者 它起源于 Google 的一些工程师 做的一项实验 这项实验很成功 现在已成为 IETF 为了标准化的一项工作

Apple 的工程师 也参与其中 实际上 此时此刻我们的工程师 就在瑞典的 QUIC 会议上

不过这项技术还没有完全准备好 标准尚未完成 但是 Apple 正在为之努力 一旦准备好了 你会看到 Apple 有 API 来支持这项技术 继续有关性能的话题 我们观察到了一些 非常常见的行为 相当多的网站和 互联网服务 使用 生命周期短的 DNS 记录 他们之所以这样做 是因为如果一个数据中心出了故障 他们希望能够更新 DNS 从而迅速地把流量导向 另一个不同的数据中心

这个方法的问题在于 你在为一个 几乎从未发生过的情况牺牲性能 数据中心极少出故障 这意味着 每当一个 DNS 地址记录过期 你的客户端不得不 再用一个往返延迟 去等候来自 DNS 服务器的回应 而这个回应 和它上次获知的一模一样 所以 考虑到这点 我们做了一个 可以实现的优化 如果你传了参与这种新方式的标记 那么当你发起 DNS 请求时 如果我们的缓存中 有一个此前过期的回应 我们会把它立即给你 与此同时 进行原本就会做的 普通的 DNS 请求

如果请求到相同的结果 我们预计大多数时候都是如此 那么一切正常 你就省了一次往返时长 从而更快速地建立连接 如果请求到一个不同的地址 我们就会给你的 客户端发另一个异步的通知 来告诉它 这里有一个新的地址 也需要进行尝试 想要利用这个特性 你需要与 Happy Eyeballs 算法 一起使用 这意味着你需要 同期进行多个连接 你需要尝试 IPv4 IPv6 多个地址 多个接口 这听起来工作量很大 也很难正确完成 确实如此 确实有很多工作要做 中场休息后回来 我们会告诉你一些新的 API 可以让你在无需做 所有麻烦的工作的情况下 利用此特性

现在我们看一些指导信息 我们见到 很多开发者 都把 SCNetworkReachability 用作预检查

他们想要预测将来 他们想知道 下一个要做的网络操作 会成功还是会失败 然后 不幸的是 预测将来总是 一件困难的事情 现在你可能连着网 但是两秒后 用户走出了这栋建筑 就没有 Wi-Fi 信号了 所以并没有一种方式 可以保证下一个操作能成功 我们常常会看到这样的情况 他们检查预检成功 于是他们去做 结果失败了 他们又回来重新检查 这也有很多工作量 很多临界情况 很多麻烦的事情要处理 比如使用代理的网络

我们可以帮你搞定

只需要使用 waitsForConnectivity 选项来 建立连接就行 你可以从去年的视频中 了解更多 意思是说 如果你需要 一个连接 你告诉系统 说你需要一个连接 如果可以 现在就需要 如果不行 就之后 如果设备当前在飞行模式 那么当它关闭飞行模式时 你的连接就会成功 这比你自己 创建一个重试循环 要简单得多

我们发现开发者会遇到 这样一种情况 如果你需要让用户 在一个表格里提供很多信息 而你又有足够的理由相信 接下来用户会提交失败 所以不想浪费用户的时间

如果你在意这种情况 请在中场休息后回来 因为我们有一种更好的 处理这种问题的办法 一直以来 安全问题都很重要

TLS 1.2 已经十年了 互联网现在准备转向 它的继承者 TLS 1.3 它有很多提升安全性的特性 类似 TCP Fast Open 会减少连接建立时间 这项标准已经完成 今年早些时候 互联网工程指导小组 批准发布 最终草案 我们在等待 RFC 编辑者 公布正式文档 到那时 我们会默认打开 TLS 1.3

目前在你的配置文件里 还是默认关闭的

你可以按照这里的说明 在你 iOS 和 macOS App 中启用 TLS 1.3 并且我们希望你现在就启用 因为这样一来 今年晚些时候 当 TLS 1.3 默认打开时 你不会有服务不兼容的问题 所以现在就测试好 确保当今年晚些时候 切换的时候一切正常

有关安全的另一个 新要素是 证书透明度 你可能听说过 有时证书颁发机构 可能是恶意 也可能是无能 会给不符合要求的机构 颁发证书

解决这个问题的方法是 一种叫做 证书透明日志的东西 每个合法的证书颁发机构 每颁发一个证书 现在都需要 公开声明 这些公开声明会记录在公共日志中 供任何人检查 这意味着如果 资质较差的证书颁发机构 颁发了一张假证书 一旦公布 立刻会被发现 如果它们不公布的话 会被客户端发现

这也许是你 很熟悉的一种办法 这里新增的实体是日志 当一个证书颁发机构 给一个服务器颁发证书 它也会在日志上记录 然后日志给服务器 一张签名的宣誓书 证明它的证书已经 被公开记录 然后当客户端连接时 服务器可以把这些信息 提供给客户端 客户端就能够确认 这不仅是签名证书 更是一个被公开记录了的 签名证书

现在假设有一个 资质较差的证书颁发机构 不公开它颁发的异常证书 客户端就会拒绝它 因为它没有宣誓书 能够证明 这张证书存在于公开记录

今年晚些时候起 我们会强制实施这个机制

所有新颁发的 TLS 证书必须包含 确认他们被公开记录的证明 那么如果他们没有被记录 客户端就会拒绝它 你的 App 不需要做任何改动 但是如果你的 服务器有专门的证书 确保你的证书颁发机构 在公开的证书透明日志中 留下了记录 现在 针对硬件开发者 我们有一些新消息

Bonjour Conformance Test 工具 可以让你确认 你的硬件设备 是否正确使用 Bonjour

如果你想要 在你的包装上 使用 Bonjour 商标的名字和标识 你需要运行这个测试 如果你想把 Bonjour for Windows 安装包 与 Windows App 捆绑 也需要运行这个测试 如果你想在包装上使用 隔空打印 隔空播放 CarPlay 车载 HomeKit 标识 通过 Bonjour Conformance Test 是标识授权过程的 一部分 因为 可靠的 Bonjour 是这些产品的 重要组成部分 但更重要的是 运行 Bonjour Conformance Test 的价值 在于它帮你 提升了产品质量 让产品更可靠 从而让你的顾客满意 而不会因为 无法使用你的产品而退货 这正是你的顾客想要的 也是你想要的 更是我们想要的 我们想让顾客开心 与可靠的产品 度过美好的时光 现在我想讲一下对 API 的选择

30 年前我们有了 BSD Sockets 30 年前它是个很棒的 API 但是 30 年前我们口袋里 没有移动计算机 也没有无线网络 没有 IPv6 很多计算机 只有一个网络接口 如果那时候你的电脑上有一个以太网接口 那一定是台很不错的电脑 现在世界上有 40 亿人 拥有多宿主的 IPv6 的 无线的 内置电池的计算设备 具备电池管理功能 可以休眠以节省电量 这个世界变得 复杂了许多

你们中很多人可能 正在使用一些基于 Sockets 的第三方库 而更多人可能在用 URLSession 而你可能会以为 URLSession 也只是在 Sockets 外面包了一层

好吧 并不太一样

URLSession 实际上建立在 Apple 的用户空间 网络代码 Network.framework 上的 从现在开始 在 iOS 12 上 我们会把 URLSession 使用的 API 开放出来 这样你的 App 可以直接用这个 API 建立 TCP 连接 或者做其他合理的事情 如果你在使用 URL 和 HTTP GET URLSession 仍然是 API 中的不二选择 而对于 URLSession 做不了的事情 我们现在开放了 Network.framework 你的 App 可以直接使用 并且如果你是某个 基于 BSD Sockets 的 第三方库的开发者 希望你可以 关注 Network.framework 的 API 把你的库转移到 基于这些优化的高性能 API 上 然后告诉我们效果如何 总结一下 我们在此强烈建议 现在是 2018 年了 应该避免使用 BSD Sockets 不要使用那些仅仅在 BSD Sockets 外面 包了一层的库 而如果你是使用这些 老旧的 API 的库的作者 请考虑一下切换过来 今天下午或者明天 请来实验室和我们交流 告诉我们如果把你的库转移到 新的 API 上 都需要做什么

说到这里 我想请我的同事 Jiten 来到台上与你们分享 更多关于 URLSession 的细节 谢谢 Stuart 大家早上好 我叫 Jiten Mehta 我是 CFNetwork 团队的一名工程师 今天我想和你们聊聊 关于你们 App 的 一些网络最佳实践

网络是每个 App 必不可少的一部分 每年你们都会给 你们的 App 增加一些 非常棒的功能 那么今天我会与你们聊聊 一些简单的 有关网络的细节 让你的 App 更好 我们今天计划 讲四类问题 减少延迟 最大化吞吐量

提升响应度 更好地利用 系统资源

在这之前 我们快速回顾一下 你们一直在用的 API URLSession

URLSession 是一个 Apple 的全平台可用的 高级网络 API

URLSession 对 HTTP/2 和 HTTP/1.1 的支持是一流的

如果你的 App 不使用 HTTP 我们也支持 URLSessionStreamTask 这个 API 让你确保 你可以在与服务器的 TCP 连接中 建立任意的协议

这是 URLSession

我们来说说第一项 减少延迟

假设你和你的朋友 去一个餐馆 服务员走向你们 你说 “请给我一杯水可以吗？” 服务员说 “没问题” 后离开 然后给你拿了一杯水 你的朋友说 “也请给我一杯水 可以吗？” 服务员说 “没问题” 后离开 然后给你的朋友拿了一杯水 如果服务员一次性获知 每个人想要的东西 从而减少来回当趟数 不是会更快吗

减少延迟的方法很简单 当你获取一项资源时 减少往返的次数即可 现在我们看看你的 App 如何做到这点 首先我们看一下 HTTP/1.1 的一些问题

你的 App 需要获取资源 你可以创建一个 URLSession 任务 然后调用 resume URLSession 会为你创建 一个包含 DNS TCP 和 TLS 的新连接

一旦和服务器的连接被建立 你的请求会被发出 然后等待从服务器 返回的回应 这就是网络的闲时 你的 App 没有做任何跟 网络相关的事情 只是在等服务器的回应 一旦得到回应 我们会调用你的完成代码块 或向你的 Delegate 发消息 告知已经完成加载 假设在加载的过程中 你的 App 想要从 同一服务器获取另一项资源 你可以再创建一个 URLSession 任务并调用 resume 然后 URLSession 会创建一个新的 连接以获取这个资源 因为它在连接池中 并没有空闲的连接

如果你的 App 又要 从同一服务器再获取 一项资源 你可以再创建 一个 URLSession 任务并调用 resume 然后为了获取资源 会再创建一个新的连接 在这个例子中 我们为了从同一个服务器获取资源 创建了 3 个不同的连接

你可能注意到了 我们花了很多时间创建新连接 我们再看看如果 你只用一个连接会怎样

这是单一连接的情况 因为没有不断创建新连接 我们省了很多时间 但这里有另一个问题

请求 2 也就是绿色的请求 必须要等待 请求 1 的回应 被完全接收

请求 3 也有同样的问题 也就是橘黄色的请求 必须等请求 2 的回应 被完全接收

这个问题被称为 HTTP 队头阻塞

现在来考虑 HTTP/2

HTTP/2 使用单一连接 并且也解决了 HTTP 队头阻塞的问题 HTTP/2 在一条连接上 多路传输多条数据流 让你可以同时收到多个回应 我们再来仔细分析一下这个例子 看看 HTTP/2 是怎样比 HTTP/1.1 表现得更好的

注意以下这些时间节点 当你的 App 试图 获取资源的时候 当请求被发送出去的时候

如果使用 HTTP/1.1 从你的 App 需要资源起 到请求被发送之间 有明显的延迟

HTTP/2 能显著减少 这个延迟 在每当 App 需要资源时 基本上立刻发送请求 再来看一下这些灰色的方块 如果你还记得 这是你的 App 没有做任何 跟网络相关的事时的空闲时间 只是在等待服务器的回应

HTTP/2 能显著减少 这样的网络闲时 允许你更充分地利用带宽

我们刚才讨论了 HTTP/2 相比 HTTP/1.1 的 许多优点 简单总结一下

HTTP/2 在 HTTP 层面 解决了队头阻塞问题 它同时允许你更充分地 利用带宽

如果你的 App 使用 URLSession 你不需要对客户端 做任何改动 仅需在服务器上启用 HTTP/2 你就能看到这些改善

采用 HTTP/2 同时也能使你 在服务器端有所改善 因为那些运行你的 App 的设备 与服务器连接次数变少了 今年 我们在 URLSession 里有一些 新东西 可以作为 HTTP/2 优势的补充 下面我们介绍针对 URLSession 的 HTTP/2 Connection Coalescing HTTP/2 Connection Coalescing 将会 让连接被更充分利用

因为你的 App 不会再一直 建立新连接 对用户的响应会更加及时

从 WWDC 配置文件开始 HTTP/2 Connection Coalescing 会自动在所有使用 URLSession 的 App 上启用

现在我们来看看 HTTP/2 Connection Coalescing 怎样决定重用连接的 假设你有一个 App 这个 App 想要获得 来自 menu.example.com 的资源

我们建立一个与服务器的连接 然后服务器给我们一个证书

如果你的 App 想要获得另一项 处于 delivery.example.com 上的资源 我们建立另一个连接 服务器再给我们另一个证书

在这种旧的运作模式下 URLSession 会从给定的主机名上 创建两个连接 来获取这些资源 但如果你细想一下 提供给我们的第一个证书 覆盖了 example.com 下的所有子域名 这意味着 delivery.example.com 也被 第一个证书包含在内 同时也注意到 delivery.example.com 和第一个连接 导向的 IP 地址一样 到这里 我们完全可以 假定与我们对话的是同一个端点 那么当我们需要获取 第二个资源时可以重用连接 而不是重新建立 一个新的连接 这么做节省了时间 因为不需要建立一个新的连接 这会让加载速度快很多 这就是 HTTP/2 Connection Coalescing 在 iOS 12 和 macOS Mojave 中的新特性

现在让我们看一下 如何通过减少 URLSession 对象的使用 来减少延迟 在刚才的几页幻灯片中 我们讨论的所有 有关连接的好处 都只在你用同一个 URLSession 对象 创建任务的情况下生效

以下这点也同样重要 每个 URLSession 对象都有 一个连接池 当你创建多个 URLSession 对象 你无法得到任何有关 连接的好处

同时也需要说明的是 创建 URLSession 对象 相对来说性能消耗不低 并且在内存方面的占用 不能忽略不计

和以前一样 我们仍然建议你使用 尽可能少的 URLSession 对象 让我们开始今天的下一个话题 最大化吞吐量 回到我们那个餐馆的例子 服务员问你要什么 然后你说 “来一份烤鸡拌酱汁 酱汁要奶油番茄洋葱肉汁 要用大量黄油做”

那真是相当绕口 如果这样会不会就简单得多 就说“我要一份黄油鸡”

最大化吞吐量的方法 也是一样的 每当你想要获取资源 减少你传输的数据量 我们来看看你的 App 如何做到这点 有几种方法 来减少请求的大小 请注意 HTTP Cookies 不是无代价的 储存和查找他们 都消耗空间和时间

Cookies 附加于所有符合域 和路径的属性的请求上 这会极大增加 你的请求大小

请善用域和路径的属性 来确保服务器需要的 Cookies 附在你的请求上

使用尽可能少的 Cookies 并当你不再需要 它们的时候 及时删除

试着把一些状态保存在服务器上 这样你就能减少 客户端上的 Cookies 同时也请考虑转换到 HTTP/2 从而获得头部压缩的好处 我们再来多聊聊压缩 HTTP 压缩 即储存信息与编码 其实就是压缩那些 穿梭于客户端与服务器之间的数据 这使得我们可以更好地利用带宽

URLSession 支持与推荐的 算法是 Gzip 和 Brotli

Gzip 被广泛支持 而且相对较快

Brotli 的支持出现在 去年发布 iOS 11 和 macOS High Sierra 时

Brotli 为结构化的文本 和 HTML 做了优化 而且它在短数据上 具有最优的压缩率 如果你还没有启用压缩的话 请在你的服务器上启用 让我们继续今天的下一个话题 提升响应度

回到我们餐馆的例子 你来圣何塞参加 WWDC 你决定去见见 一些老朋友 你和你的朋友就坐在 餐馆的餐桌旁 你的饮料上来了 但是你想要更多时间 来和你的朋友们叙叙旧 而不是直接上菜吃饭

你可以简单地跟服务员说 “请你过一会 再上菜可以吗？ 我们不赶时间”

这里有一个同样的理念 可以被应用在响应度上 你根据你正在进行的 其它任务给你的任务标上优先级 我们来看看你的 App 可以如何从中获益 你也许很熟悉 跟派遣队列和 NSOperation 对象有关的 这五个 QoS 类 数据需要依靠 CPU 的调度策略

URLSession 是对 QoS 敏感的 意味着它可以在 你调用 task.resume 的队列中采集 QoS

它发给你的 Delegate 的 所有消息都会遵守这个 QoS 举个例子

如果你的 App 想要获取一些 与时间无关的数据 考虑在一个有后台 QoS 的队列上 继续这个任务 保证这个任务不会 与其他正在做的 更高优先级的工作 争夺 CPU 资源 网络服务类型 是 URLSession 配置对象上的 一个属性 可以让你 将你的网络流量分类 从而帮助系统提升 将要离开设备的数据的优先级

今年 我们有了一个 新的网络服务类型 就是 responsiveData

responsiveData 比默认的类型 优先级稍高 但是应该被合理利用

举个你应该使用 responsiveData 的例子 如果你有个购物的 App 在结算页面 你应该把支付请求 标记为 responsiveData 来保证可以从 服务器得到响应

用网络服务类型属性 标记的流量 在 Cisco Fast Lane 上跳转时 会一直保留这个标记

有关这个 API 的更多信息 请查看 2016 年的 有关部分 去年我们介绍了 URLSession 自适应 连接 API waitsForConnectivity

waitsForConnectivity 会一直等待 而不是在你的任务没有 连接的时候 直接加载失败

过去 你们一直在用 STNeworkReachability 来完成发送请求前的预先检查 但是正如 Stuart 刚指出的 这其实是一场赛跑 因为系统可能告诉你 你连上了一个服务器 但是当你创建并发出请求的时候 你已经失去了机会 你不再与服务器连接着了 我们推荐使用 waitsForConnectivity 它会在连接一旦可用时 把你的请求发出去

你也可以执行 taskIsWaitigForConnectivity Delegate 方法 它会在你的任务无连接时被调用

这会在为用户呈现 另一个流程或者离线的 UI 时 带来更好的用户体验

有关这个 API 的更多信息 请看去年 WWDC 介绍这个 API 的有关会谈 现在我们来看今天的 最后一个话题 更好地利用系统资源

回到我们餐馆的例子 你很喜欢这里的食物 你决定第二天 来这里吃晚饭

餐馆有外送服务 你可以今天下单 他们第二天会 把餐品送到你家 这不仅帮你省掉了 去取食物耗费的时间和精力 还帮助餐馆 根据你的截止时间 更好地确定工作的优先级

让我们来看看你的 App 如何 更好地利用系统资源 从而提升效率

后台会话有上传 和下载的任务

这些任务让 系统智能地决定何时开始 以及何时结束下载 这个决定基于很多因素 例如电量 CPU Wi-Fi 等等

如果你的 App 想要下载 一个大文件 考虑使用后台会话

这些任务在进程外运行 意味着即使你的 App 在暂停状态 下载也会继续

与后台会话有关的 更多信息 参见 2014 年的 WWDC 会议 缓存是减少延迟的好方法 但是需要注意的是 缓存可能会导致磁盘存取问题

在现实世界里 我们看到有些 App 每天往磁盘里写入若干 GB 的数据 会引起严重的 闪存劣化

请不要缓存唯一的信息

举个例子 假设你有个 App 约会的 App 而你负责其中 网络部分的代码 这个 App 加载高分辨率的 用户照片

缓存这些高分辨率图像 可能有些浪费 因为用户会向左滑动 去看下一个 意味着你刚才缓存的图像 可能再也不会被请求到

请考虑做些 客户端侧的修改 比如 采用 willChacheResponse Delegate 方法 来决定哪些资源 应该被缓存

如果你拥有服务器的话 请考虑在请求头中使用缓存控制 来决定哪些资源 可以被缓存 我们迅速地过一遍 今天讨论过的关键点 第一点 当你去餐馆时 一次性把所有要点的菜都点完 我开个玩笑 转移到 HTTP/2 从而利用头部压缩 Connection Coalescing 以及无队头阻塞问题等等好处 用更少的 URLSession 对象 通过重用连接来减少延迟 这也减少了内存占用 所以也更好地利用了系统资源 减小请求的大小 来最大化吞吐量

注意 QoS 提高你的 App 的响应灵敏度 最后 使用后台会话 从而可以更好地 利用系统资源

关于这个会议的更多信息 请访问这个网站

现在我们短暂休息一下 休息过后 我们会向你介绍 Sockets 的现代替代者 Network.framework 我很希望在 今天和明天举办的 网络实验室里见到各位

感谢各位来到这里 希望大家享受 大会的其他部分

[ 掌声 ]