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