535
iOS11开发新特性
索引
- iOS11开发新特性之网络部分
- iOS11开发新特性之Xcode9 新特性
- iOS11开发新特性之实用小tips
- iOS11开发新特性之停止支持32位APP
- iOS11开发新特性之 WebKit 支持 WebRTC 协议
iOS11开发新特性之网络部分
前言
网络优化技术进阶 为了给用户提供更好的用户体验，在网络优化和新技术使用方面，苹果一直都保持着很积极的态度，近两年也多次通过加强审核的方式大力推广 IPv6 和 https；每年的 WWDC 都有若干网络优化的 session，介绍和讨论新的网络技术和使用情况；
今年的 Advances in Networking 进一步分享了 ECN/IPV6/MPTCP 等几项技术带来的收益，以及苹果网络相关 API 的一些新特性；
主要内容：
- ECN 显式拥塞通知
- IPv6支持
- Networking stack changes 传输层 TCP/IPv6从内核剥离
- New NetworkExtension facilities 网络扩展：NEHotspotConfiguration、NEDNSProxyProvider
- Multipath protocols for Multipath Devices 多路径协议
- URLSession enhancements URLSession 增强
- waitsForConnectivity
- earliestBeginDate
- ProgressReporting
- Brotli compression
- Public Suffix List
- URLSessionStreamTask
- Best Practice 最佳实践
-
正在进行的开发-TLS 1.3 QUIC Bonjour
ECN
首先所有的网络协议都是为了最大化的使用网络资源，一直到网络出现拥塞; 出现拥塞时会导致丢包，而 TCP 默认的处理是对丢包进行重传；这种方法代价非常大，发送方持续重试可能导致耗电，设备的网络资源也会被无端占用，而网络也可能更加拥塞，需要很长时间才能恢复； 有效的优化拥塞和避免拥塞将减少重传，减少延迟，并极大提升用户体验；
重发为何会带来非常大的性能损耗：原因是因为 TCP 的慢启动与初始拥塞窗口（initial congestion window, initcwnd）。
好的传输协议必须最大限度地利用带宽，而 TCP 有启动速度限制，也就是初始拥塞窗口（initial congestion window, initcwnd），随着时间与稳定性的增加，才能最大限度地使用带宽。一旦发生拥塞重连，将带来非常大的性能损耗。重连时将采用初始拥塞窗口，这个值是连接中最慢的，窗口的限制也会拖慢整个传输过程：在拥塞窗口设置的较小时，对于 TLS 连接，TLS 握手消息消耗了宝贵的初始连接字节（当拥塞窗口较小时），如果拥塞窗口足够大，那么慢启动不会有额外的延迟。但是如果较长的握手消息超过了拥塞窗口的大小，发送方将必须把它拆分成两块，先发送一块儿，等待确认（一个往返），增加拥塞窗口，然后再发送剩下的部分。这也加剧了
扩展说明：
TCP 内置的拥塞控制（congestion control）机制，在一个新的连接开始时，你不知道对端有多快。如果有足够的带宽，你可以用最快的速度传送数据，但如果你正在处理一个缓慢的移动网络连接呢？如果发送的数据太多，你会压垮连接，导致连接中断。出于这个原因，每一个 TCP 连接都有一个拥塞窗口（congestion window）的速度极限。这个窗口的初始值非常小，在可靠性能保证的情况下随时间增长，这种机制被称为慢启动（slow start）。
这带来了反直觉的现象：所有的 TCP 连接，启动速度很慢，随着时间的推移速度增加，直到它们充分发挥其潜力。这对于 HTTP 连接而言，往往是坏消息；它们几乎总是在不理想的条件下工作。重发同理。
综上拥塞是 TCP 的性能瓶颈，TCP 设计之初检测拥塞的方式，只能在发生了丢包时才会发现发生了拥塞。仅从丢包来识别拥塞，代价过高。
优化的思路有两种：
- 优化拥塞时的效率
- 避免拥塞
前者有 quick 之类的协议替换 TCP 协议，Apple 也在积极开发中，iOS11暂时未支持。后者则是基于 TCP 做一些扩展、完善，ECN 就是一种，ECN 已经在 iOS 中全面支持。
什么是 ECN ？
全称：**Advantages of Explicit Congestion Notification**（显式拥塞通知），当网络拥塞发生时，因为发送方无法及时知晓网络情况，在发现丢包时会不断的重发，导致网络情况更加糟糕，而 ECN 的出现就解决了这个问题，ECN 是 TCP IP 协议的扩展，其实现是在 ip header 中加入 1 bit 的拥塞状态值，由接收方回传给发送方；发送方收到这个消息时既停止发送数据包，直到拥塞解除；
ECN 需要客户端、服务端和网络三方面的支持，但是得益于 ECN 隶属 Linux 内核，所以只需要运营商升级 Linux 即可支持，APPLE 给出了 Server 对 ECN 支持率：
数据：
| 时间 | 2013 | 2017 |
|---|---|---|
| Server 对 ECN 支持率 | 35% | 74% |
客户端方面，iOS 10.3 开始，50% 的通过 Wifi 和少量通过移动网络进行的 TCP 连结已经打开了 ECN，没有收到相关问题的报告； 通过也收集到了一些国家出现网络拥塞的情况：
| 地区 | 网络拥塞情况 |
|---|---|
| 美国 | 0.2% |
| 中国 | 1% |
| 法国 | 5%、 |
| 阿根廷 | 30% |
综上，客户端从 iOS 11 开始，所有 TCP 请求都会支持 ECN（全部Wifi 和部分白名单移动运营商）；服务端有 74% 的网站支持了 ECN，也会有越来越多的网络服务商开始支持 ECN 来进一步提升用户体验；（服务商只需要在你的网络接入点支持 ECN 即可）；
显式标记连接拥塞，更加高效。
- 减少重发次数
- 降低延迟
- 提升用户体验
在使用 ECN 的同时，需要结合使用 SQM (Smart Queue Management) 算法 来进行数据缓存，他会保证是真正的拥塞出现前告知发送者当前的网络这块，最大程度上的避免拥塞出现；
ECN 的实现细节
ECN 是 TCP IP 协议的扩展，其实现是在 ip header 中加入 1 bit 的拥塞状态值，由接收方回传给发送方；发送方收到这个消息时既停止发送数据包，直到拥塞解除；
ECN flag 的位置，在 IPv4 中对应于 ToS ，IPv6对应于 Traffic Class。
更详细的位置：
参考链接:
15 年的 session 中 有一个实验对比图：没有 ECN 时 在传输初段出现了明显的网络拥塞，而且持续了很久才恢复正常；而在使用了 ECN + CoDel 算法优化后，没有出现明显的数据终端和因拥塞导致的丢包和重传；
Reference:
your app and next generation networks wwdc/2015/719
IPv6
IPv6 相比 IPv4， IPv6 有更大的地址空间，更小的路由表，更高安全性等优势。
World IPv6 Launch 始于 2016 年 6 月 6 日，包括中国在内的若干国家开始启用 IPv6（事实上中国进展缓慢）。支持 IPv6 的设备从 5 年前的不到 1% 提升到今天的接近 20%。欧美大多数的移动运营商也已同时支持 IPv6 和 IPv4。经过策略改进，HTTPS 请求在 IPv6 下提升了 15%-30%。
15 年的 session 里已经提到了 NAT64，如果服务端只支持 IPv4, 在 IPv6 环境下，可以通过 NAT64 DNS64 技术去正常访问。
16 年 6 月起，苹果也开始要求所有 App 提交时必须经过 NAT64 测试，支持 IPv6 网络；现在因为 IPv6 被拒的 App 已经很少了。
Networking stack changes 网络协议分层
Networking stack changes 传统的网络分层模型中，接口层和传输层 TCP/IP 都在内核态；剩下的协议处理在用户态；数据在这两者间传输时需要做一些上下文切换。
意义在于，
- 方便调整协议
-
效率更高
理想状态下：如果APP开发者想更新调整通信协议内容，比如参数、配置等内容，不用用户再升级系统，而是直接升级 APP 即可实现。比如提升入口初始带宽，目前在 iOS 中能够体现的部分是对于NSURLSession 可以调整 MutliPath TCP 的相应策略。
数据在这两者间传输时避免了一些上下文切换，效率更高。
可以预见，将来在 NSURLSession 中将开放更多的用于调整 TCP 传输的接口，让我们继续期待后续更新吧。
MutliPath TCP
Multipath protocols for Multipath Devices（适合多链路设备的多链路 TC P协议）
增加了对使用多个接口（如Wi-Fi和Cellular）的支持，通过扩展 URLSessionConfiguration 以支持 IETF、RFC 6824中定义的多路径TCP传输单个数据流。有关更多信息，请参阅URLSessionConfiguration.MultipathServiceType。
| 阶段 | iOS10.3 | iOS 11 |
|---|---|---|
| 客户端 | 50% | 100% |
不要使用 BSD 的 Socket，不要嵌入其他网络类库，优先使用 APPLE 的网络类库，底层网络通信在 CPU、内存、电量使用已经做了很多优化，在数据传输效率、动态链接通道切换都有优化，使用其他网络库，无法享受优化成果。
NEDNSProxyProvider
向网络扩展框架添加了新的 DNS 代理应用程序扩展类型。
Receives the system’s DNS query messages Handles them as it wishes
Can send to recursive resolver of its choice Can send using protocol of its choice
支持：
- DNS over TLS
- DNS over HTTP
仅仅适用于 VPN 类 APP
DNS Proxy provider: also for non-managed devices?
Reference:
- Video Reference: 707_advances_in_networking_part_1 18':20''
- Video Reference:Advances in Networking, Part 2 42'15''
- PDF Reference: 707_advances_in_networking_part_1
WKWebView Cookie 管理
基本在这里面展示了他的特性
参考：《iOS 防 DNS 污染方案调研（四）--- Cookie 业务场景》
URLSession Adaptable Connectivity API
重大更新！现在可以通过 urlSession(_:taskIsWaitingForConnectivity:) 让请求等待网络正常后再自动尝试。
URLSessionTask Scheduling API
通过 URLSessionTask Scheduling API 可以在 App 没有运行的时候下载内容，而手机也会结合实际电量，使用状态去决定是否执行。
iOS11开发新特性之Xcode9 新特性
功能更全的 Git 支持
在Xcode 9 中，引入了 GitHub 新源代码管理导航器 可以展示 branch 分支和 tag 标签。
双击对应 commit
可以直接查看本次提交：
本次覆盖，基本涵盖 GitHub 官方客户端功能。
创建新的颜色 asset catalog
创建新的颜色 asset catalog
通常我们会New image set， 现在 可以New color set . 然后填充 rgb alpha 值
在 xcassets 里添加颜色，
在代码或者 IB 中直接引用该颜色：
功能类似开发工具【Zeplin For Mac：生成自定义颜色代码，支持Objective-C和Swift】开发中，每个App都有自己的特有的颜色。比如马尔代夫蓝、屎黄色。。我们通常使用分类为颜色起名，比如[UIColor cyl_sunYellowColor]。Zeplin能选取Sketch文件中的颜色并导出分类，代码可自定义前缀： Zeplin For Mac
对于有设置主题色的 APP 非常有用。
设置
Xcode 9 有个选项可以关闭 Command + Click 的弹层，选择之后就可以跟之前版本一样直接进行跳转
选择 jump to definition：
无线调试
对 Folder 管理也有加强（现在你删掉一个 Folder，文件系统里的那个也会被真的删掉）。
Xcode 终于解决了 Group/Folder 混乱的问题，从此 Group 默认就是 Folder。
增加了主线程 API 检查，Test 可以在模拟器并行进行，无线调试
iOS11开发新特性之实用小tips
DeviceCheck
DeviceCheck 允许你通过你的服务器与 Apple 服务器通讯，并为单个设备设置两个 bit 的数据。
在设备上用 DeviceCheck API 生成一个 2字节的 token (00, 01,10,11)，然后将这个 token 发给自己的服务器，再由自己的服务器与 Apple 的 API 进行通讯，来更新或者查询该设备的值。这两字节 的数据用来追踪用户。比如。借助两个自己的数据，你可以得知用户究竟使用了该 App 多久。
该 API 可以成为：反欺诈领域：
- 试用7天
- Uber、滴滴司机被封号后，防止重新注册账号接单
- 该用户是否已经领取过首次注册红包
-
APP防多开
因为传输的是 flag 级别的数据，并不会定位到该设备的使用者，所以相对安全。
但是对于购买了二手手机的使用场景，可能会出现一些边界情况，这个在业务中也需要考虑进去。
Reference:
## APP 删除后 keychain 不会被清理
| 版本 | 事件 | 说明 |
|---|---|---|
| iOS 10.3 beta 1-5版本 | 保存在keychain中的App相关的数据，会随着应用的删除而被清除，重新安装App后将无法再从keychain中获取应用相关的数据。而10.3之前删除App并不会清理keychain中的对应数据。如果希望App在重新安装后，仍然可以获取到之前的一些数据，则依赖于keychain的方案将变得不可靠。不过，如果数据是在多个App间共享，则只有当所有相关的App都被删除后，才会删除keychain中的这些共享数据。 |
 iOS 10.3 Beta 2 autodeletes keychain items after application uninstall?
|
| 10.3 beta 6 版本、10.3正式版、iOS11 | 恢复到之前的状态，从新安装可以访问到以前保存的数据了。 | iOS 10.3 beta 3 doesn't persist data of KeychainItem |
iOS11开发新特性之停止支持32位APP
iOS11 放弃支持 iPhone5、iPhone5c、iPad4 ，标志着在硬件层面，32位设备退出了历史舞台，iOS 系统不再兼容32位设备。
同时 iOS11 也将不再支持 32位 APP 运行, 32位 APP 在 APPStore 无法被搜到，已经下载的 APP 无法在
“已购”项目中安装。
iOS 11 只兼容 64-bit 设备，也就是搭载 A7 以上处理器的设备. 下面是 iOS 11 兼容设备的全部设备：
下面是 APPLE 淘汰32位 APP ，全面推进 64位 APP 的事件流：
| 时间 | 事件 | 备注 |
|---|---|---|
| 2013.09 | Apple 开始全面推进 64-bit apps | 发布 iPhone 5s |
| 2015.12 | Apple 发出最后通牒：所有送审应用、包括更新必须使用 iOS8+ SDK进行 build ，支持 64-bit | Apple 通知如下: As we announced in October, beginning February 1, 2015 new iOS apps submitted to the App Store must include 64-bit support and be built with the iOS 8 SDK. Beginning June 1, 2015 app updates will also need to follow the same requirements. |
| 2016.10 | iOS 10.1 系统下 Apple 开始弹窗警告32位应用可能会导致设备运行缓慢 |  |
| 2017.06 | iOS 10.3 beta 第一版在打开32位设备时弹窗：打开32位应用iOS版本不支持，应用需要升级。越来越多的 APP 发布新版时没有保留对iphone5c及ipad4等32位设备的支持，比如视频制作应用 Clips。 |  |
| 2017.9.20 | 同时 iOS11 也将不再支持 32位 APP 运行, 32位 APP 在 App Store 无法被搜到，已经下载的 APP 无法在“已购”项目中安装。 |
 App Store中所有的32位应用将无法正常运行。 |
Reference:
- 32-bit apps will not launch on iOS 11, Mac App Store transition to 64-bit from 2018
- 32-Bit Apps No Longer Supported in iOS 11
- 《64-bit Tips》
iOS11开发新特性之 WebKit 支持 WebRTC 协议
iOS 11 的 WebKit 中支持了 WebRTC 相关的接口：
不过 WKWebView 还没有支持 getUserMedia 无法获得 MediaStream ，无法传输音视频流，所以 APP 嵌套的 WebView 还无法使用 WebRTC，必须得用 Safrai APP 才可以。APPLE 回复说是会支持，估计得等几个版本了，可以持续关注后续 WKWebView 更新。
一旦 WKWebView 支持 MediaStream (getUserMedia)，之后朋友圈里面的 Web 会有更多可能性，比如直接音视频的合成，还有实时视频通信、WebAR 的东西进行传播。借助小程序的入口，想象空间还是比较多的。
Reference:
- 《WebRTC入门教程》
- 《WebRTC在iOS端的实现》
- 《苹果终于入伙 WebRTC，新一代移动 Web 应用爆发路上还有哪些坑？》
- Hold On with the Apple WebRTC in iOS Party
- Safari Technology Preview
- What's New in Safari
iOS官方灰度方案：Phased Release for Automatic Updates
iTunes Connect v2 宣布支持：Phased Release 功能，全称 Phased Release for Automatic Updates (阶段性自动更新发布)，
在提交审核通过后，上架当天为第一天，之后灰度比例依次递增：
| 天数 | 百分比 |
|---|---|
| 第一天 | 1% |
| 第二天 | 2% |
| 第三天 | 5% |
| 第四天 | 10% |
| 第五天 | 20% |
| 第六天 | 50% |
| 第七天 | 100% |
其中：
灰度占比 = （推送量） /（打开了自动更新应用的用户）
注意分母并非：总安装量。
这个方案类似于 iOS 系统的每个版本的发布更新，iOS 系统每次更新也并不是全部地区更新，有时也是增量更新。
值得注意的是，虽然 Phased Release 可以起到“灰度”作用，但实际提交的却是一个”正式版本“，只是提交审核的时候选择 Release update over 7-day period using Phased Release，所以如果这个版本出了严重问题，还是需要升级版本号重新提交。
有坑的地方在于下面的这些原因会导致 1%、2% 的灰度比例很难控制：
- 如果用户手动打开了 App Store 检查更新，是能检查到灰度版本的，
-
通过搜索应用名称，也就是能下载到最新的版本的，
如果这个灰度有严重 bug，APPLE 提供了暂停灰度发布的功能来控制影响，但是这个暂停最多30天，超过时间苹果会自动转为全量，并且用户手动检查更新、手动下载还是能下载到有问题的版本。
该机制的缺点与建议：
- 无法控制灰度用户上限：与 TestFlight 相比，缺点较为明显，鉴于官方灰度占比的计算方法，实际操作过程中，是很难把握真实的升级数量，无法升级用户的上限。如果对灰度上限有要求，建议一旦开启该机制，时刻关注版本占比，及时暂停 Phased Release，仅靠手动更新的量进行灰度，或者采用 TestFlight 。
-
无法撤销灰度版本：Phased Release 虽然一定程度上降低了发布风险，但作用并不满足预期，更不能降低版本发布的质量标准，一旦 APP 出现较大 bug，无法撤销灰度版本，只能发布更新，依然要考虑审核周期，以及用户升级周期。
下面是对该功能官方FQA 的翻译：
- 什么是阶段性自动更新发布？
在iTunes Connect，你可以开启Phased Release for Automatic Updates，那就意味着，你发布了一个阶段性更新的iOS应用。在阶段性更新发布版本中，7天之内，你的应用会以百分比的形式来增量更新。在阶段性发布的版本期间内，你的应用会每天都显示在iTunes Connect上，并且部分用户会完成更新。当然，所有的已安装过你的应用的用户也可以选择App Store手动更新，新用户会一直都能看到你最近发布的“可供销售”的版本。 如果你发现在阶段性更新过程中，你的应用有某些缺陷，你可以在任何时间内暂停阶段性更新，这个时间持续30天，不管暂停有多少次。
- 如何阶段性发布我的应用？
阶段性发布一个更新版本：
在iTunes Connect首页，点击我的应用，然后选择一个应用；
在左边的列表，点击你想要提交的版本的应用；
在Phaed Release for Automatic Updates区域，选择 Release update over a 7-day period.
点击右上角保存。
- 在阶段性发布中，成百分比例的用户是如何每天完成自动更新？
自动更新打开时是任意选择的，这基于用户的Apple ID，而不是用户的设备。如果一个用户有多个设备，每个设备都开启了自动更新，那么当一个应用在阶段性发布更新时， 他们会在同一时间段内收到自动更新的提示。
- 在阶段性发布中，我能每天为用户设置自动更新的百分比值吗？ 不能，因为在阶段性发布中，百分比的用户每天完成自动更新的图表如下显示，当然也会显示在iTunes Connect上
| 天数 | 百分比 |
|---|---|
| 第一天 | 1% |
| 第二天 | 2% |
| 第三天 | 5% |
| 第四天 | 10% |
| 第五天 | 20% |
| 第六天 | 50% |
| 第七天 | 100% |
我能针对阶段性发布的应用进行特定的统计数据吗？
不能，因为不可能针对指定统计数据的用户进行，如年龄，性别，地区，设备信息，系统系统，设备类型的查看。用户的更新是随机选择的。-
在应用阶段性发布中，用户完成了自动更新会被通知到吗？
不会被通知到
我可以取消我的应用版本的阶段性更新吗？
如果你想停止发布阶段性的应用，并且 发布给所有已打开自动更新的用户，你可以这么做，在右上角选择你的应用对应的版本，然后点击选择 Release to All Users。
如果在版本更新中，你发现了应用有bug，你可以在任何时候暂停阶段性发布，一共可以持续30天，30天内不管你暂停了多少次；然后提交一个新的版本。
对于已经是 Ready for Sale (可供销售) 的版本来说，不可能撤回版本更新，或者防止用户手动更新。当我的应用还在阶段性发布暂停中，并且已经超过了30天的期限，会发生什么？
当你的应用更新暂停超过30天后，应用发布会在当天从暂停中恢复，并且不能再暂停你的应用发布了。
最后更新：2017-09-30 17:03:00