老司機 iOS 週報 #63 | 2019-04-15
老司機 iOS 週報，只為你呈現有價值的資訊。
你也可以為這個專案出一份力，如果發現有價值的資訊、文章、工具等可以到 Issues 裡提給我們，我們會盡快處理。記得寫上推薦的理由哦。有建議和意見也歡迎到 Issues 提出。
新聞
2019 年上海第一次 T 沙龍將於 4 月 20 日下午 1 點 30 分在上海虹口區天水路 172 號金融街海倫中心 B 座準時舉辦，此次活動邀請到了來自餓了麼、iTutorGroup、極光、以及看雪論壇的業界資深從業者為大家分享他們在移動端技術深度和廣度上的實踐和思考。希望這次活動能對網際網路寒冬下迷茫的移動開發者有一些啟發，併成功破局！猛戳上方連結免費報名。
@四娘：伴隨著 Swift 5 的釋出，SwiftNIO 也正式釋出了 2.0 版本，這個版本主要有兩個大更新：
- 內建了 BoringSSL 作為 Vendor，不再依賴系統的 OpenSSL
- 使用純 Swift 實現了 HTTP2 協議，不再依賴於 nghttp2
@享耳先森 ：Amazon 之前開源的 Swift Web Framework 釋出 1.0 了，圍繞著 AWS 的服務做了很多深度整合。1.0 使用 Swift 4.2, SwiftNIO 1.x 開發，即將釋出 Swift 5 及 SwiftNIO 2 的版本，包含 SmokeHTTP , SmokeAWS , SmokeDynamoDB , SmokeAWSCredentials 幾個子模組。
新手推薦
@looping ：本文就針對大家在使用 Storyboard 後出現的一些問題或質疑，提出了自己的看法，並列舉了相關實踐和建議，從而說明 Storyboard 和 Xib 雖然存在一些缺點，但也是值得學習研究的：
- 通過定製規範，合理的任務分工，以及有節制的使用工具來避免多人協作的坑 —— 對 Storyboard 的濫用（作者在文章中也給出了他們團隊使用 Storyboard 的規範）；
- 通過良好的模組設計，熟練使用 Storyboard 分離程式碼的幾個方案來避免由於 Storyboard 造成 ViewController 程式碼臃腫的問題；
- 需要修改類名或者變數名，應該善用 Xcode 的重構功能，來避免由於手動修改程式碼出現遺漏，導致應用崩潰等現象排查定位困難的問題；
- 經過測試，Storyboard 和 Xib 的執行效率並沒有想象中的那麼低，在重複建立例項時效率反而會比純程式碼要高；
- 使用 Storyboard 和 Xib 進行佈局，缺少約束或者約束衝突就會直接提示錯誤，適配不同裝置也可以直接在 Interface Builder 上切換測試，效率和準確性比手寫適配程式碼要高很多。
文章
@折騰範兒_味精：為了讓 app 裡面的 H5 頁面實現秒開的效果，很多專案都採用了載入本地 H5 離線包的方式。如何實現這樣的秒考就得分別從兩個方面著手實現。
- 離線包的分發與下載
- WebView 的本地載入
需要補充一點的是，本文在 WebView 本地載入上都是以攔截的思路進行本地載入，UIWebView 自然可以順暢使用 NSURLProtocol 但是在 WKWebView 裡就面臨很大的阻礙，而作者給出的代替方案還是 WKURLSchemeHandler 攔截，但面臨的代價也是本來前端無感的攔截方案現在被迫前端也得受影響，打包的時候對資源協議頭進行適配，這一點和很多公司的離線包方案略有差異。
在 WKWebView 裡，即便是使用 WKURLSchemeHandler，資源攔截的方式也面臨著與安卓差異化嚴重，對前端侵入性嚴重等問題，很多公司的離線包方案選擇了另外的一條路，App 起本地伺服器 run 前端離線包頁面，做到讓 WebView 無感知當前是一個“離線”頁面，這樣做能夠最大程度的讓前端對於離線包“無感”，也能忽略掉攔截 API 的平臺差異導致的框架實現差異。
關於起本地伺服器的這套方案，可以參考 基於 LocalWebServer 實現 WKWebView 離線資源載入 一文。它介紹了基於資源攔截技術而實現的 H5 秒開方案，並且在文章點評中提到了還有另外一種 Local Web Server 的方案來實現離線本地 H5 頁面秒開。對這個方案有興趣的朋友可以詳細的看一下本片文章給大家介紹的幾套 Local Web Server 的開源方案並且文章還配有 Demo 程式碼可以參考。本文還向大家詳細介紹了一下證書籤名等部署本地服務會面臨的問題。
@蓮叔：在以往講述 iOS 架構/設計模式的文章中，往往 focus 在某個功能模組如何設計，如：MVC，MVP，VIPER，MVVM 等，講述整個工程的設計模式和組織方法的討論並不多見。本文從整個工程的架構著手，提出了一種工程的分層的架構方式，並且通過針對不同的層選擇動、靜態度來承載，實現了易於拓展、可組合、低耦合的工程架構，同時能兼顧編譯時間和啟動時間。針對各種不同粒度的需求變更，feature 級或者流程級都能夠很好地相容，文章還給出了對初學者很友好的 example app 來描述其思想，避免了讀者在工程配置上可能花費的探索時間（畢竟要配置一堆動靜態庫的依賴關係還是有點蛋疼的)。值得閱讀。
@kyo ：在移動網際網路時代，對於各家公司而言，什麼東西最重要呢？我想大多數的答案應該是流量。本文當然不是討論如何獲取更多的流量等問題，畢竟那更多是產品運營的事情，而為流量做保駕護航的，就是網路。所以，如何優化網路，也是各廠紛紛探索的方向。對於流量越大的 App 而言，網路優化所帶來的收益也越大。本文由百度 App 研發團隊所寫的[百度 App 網路深度優化系列]的第一篇，DNS 的優化，從百度這個億級日活的 App 自身的實踐中總結出來的，非常值得好好看下。
@looping ：多人協作引起的程式碼合併衝突是我們使用 Storyboard 進行開發時常會遇到的比較頭疼的問題了。避免這類協作問題的常用解決方案就是制定規範，規定一個介面用一個 Storyboard，並由單人維護。這樣雖然解決了協作問題，但假如在寫例項化程式碼時不進行優化，還是會存在一些不太友好的冗餘程式碼，甚至硬編碼。例如， let controller = UIStoryboard(name: "MyViewController", bundle: Bundle(for: MyViewController.self)).instantiateInitialViewController() as? MyViewController 。
本文作者就分享了一種優化思路，他通過設計一個 UIViewController 的協議（protocol）IBConstructible —— 帶有 nibName 和 bundle 這兩個屬性，利用 Swift 允許通過擴充套件（Extension）為協議提供預設實現的特性，使得最終例項化程式碼變得非常簡潔， let controller = MyViewController.fromNib 。
如果有在使用 Storyboard 進行開發的團隊，但還沒有對相關程式碼進行優化的話，可以參考本文提供的方案來處理，讓程式碼變得更加簡潔。如果已經優化過的，不妨也分享下自己的思路。同時本文的優化技巧也是可以用在很多程式碼重構的場景上的。
@kyo ：雖然移動裝置的效能越來越好，但為了追求更好的體驗，卡頓依然是我們日常開發中不可忽視的問題。目前，各個公司都會採用各種三方庫或者自己寫的庫來監控卡頓，但無論什麼庫，監控卡頓必然繞不開 Runloop。本文作者簡單介紹了監控卡頓的原理，然後利用 Runloop 的特性製作了一個可以監控卡頓的 Demo。
@極速男孩 : Codable 是在 Swift 4 以後引入的一種序列化和反序列化的協議。本文主要介紹了兩種對於在 Codable 協議中，處理不確定型別的兩種方式：
Any
本文在這裡主要推薦使用 Any 關鍵字， Any 和用美劇的方法相比在保持類似的開發體驗的同時，可以靈活的去修改。
由 yuhanle 推薦
@J_Knight_ ：作者以使用 HTTPS 的緣由為切入點，從對稱加密和非對稱加密的對比，數字證書，數字簽名，以及 HTTPS 通訊的建立流程這幾個方面介紹了 HTTPS。
@zvving：45 期我們曾介紹過 Unit tests 中輕量級 stubbing 實現 ，其中測試用例執行前註冊 stub body 的過程略顯繁瑣。 如今作者更近一步，設計一套名為 arguments spy 的可插拔機制，嘗試解決 Unit Tests 中動態修改 stub body 實現的困擾。對函數語言程式設計感興趣的同學不要錯過。
工具
optionals
@張嘉夫：一個展示 Swift 可選型（optional）各種用法的網站。
onesignal
@邦Ben：國外的一個集合型的服務（移動推送，Web 推送，內購，郵件），老套路，基礎服務免費，高階服務氪金。因此，如果有海外業務的同學和開發個人 APP 的同學不妨看看。
程式碼
@zvving：演算法已經成為各大公司面試必考專案。刷 LeetCode，無論是準備面試還是鍛鍊自己的演算法和程式設計能力都很有幫助。網上 Swift 解法實現不多，這個版本相對完善，在程式碼規範、分類、時間（空間）複雜度梳理等方面可圈可點，值得參考。
LeetCode 已入駐國內，中文名『力扣』，可以一試。
相關閱讀：
Codextended
@張嘉夫：讓 Swift 的 Codable API 更容易使用的一套 extensions，賦予其型別推斷（type inference) 能力。Codextended 既不是 wrapper 也不是全新的框架，而是用一種極其輕量的方式來增強 Codable 。 Codable 很強大也很方便，但如果你需要一定程度的自定義的話（例如轉換部分 decoded data，或為某些鍵提供預設值）， Codable 的標準 API 就會變得 相當 囉嗦。它沒有充分利用 Swift 強大的型別推斷能力，導致產生了很多不必要的重複程式碼。Codextended 就旨在解決這個問題。
Brooklyn
@享耳先森 ：受蘋果 2018.10.30 釋出會啟發，設計並開源的一個屏保程式，非常漂亮，可在終端執行 brew cask install brooklyn 安裝。
SecureDefaults
@小非86：SecureDefaults 是對 UserDefaults 的輕量封裝，使用 Swift 編寫，並額外支援 AES-256 加密（金鑰 256 位）。如果你想改善 App 持久化資料的安全性，又執意要使用 UserDefaults 的介面，SecureDefaults 提供了 Keychain 之外的另一種靈活選擇 。
書
:star2: :racehorse: Swift 5.0 中文版官方文件
@老峰 ：上個月Swift 5.0 正式釋出了，這是 Swift 發展史一次重要的迭代。SwiftGG 翻譯組最近也更新了 Swift 5.0 中文版官方文件 ，內容覆蓋了 Swift 的基礎語法結構以及各種高階特性，感興趣的讀者快來學習吧。
音視訊
@Parsifal：知識小集 x iOS 週報 x SwiftGG 已經成為 iOS 圈子內為大家所熟知的三大社群組織。這一期 GGTalk 邀請到了我們三大組織的創始人 - 小集南峰子，SwiftGG 的樑傑，以及我們週報團隊的一代目卓同學，一起談談我們這三大組織的故事。
週報團隊從 18 年 1 月份第 1 期到現在第 63 期，已經一年多了，期間除了春節等特殊節假日，沒有斷過更新。但週報其實在這一年多的時間裡，也有遇到過不少小問題。我從去年 10 月份左右從老卓手上接過週報的運營工作，至今正好是半年。基於老卓打下的基礎，還有周報 30 位編輯的一起努力，我們依舊在每期穩定地輸出高質量內容，並嘗試了掘金沸點、話題討論和GitHub Release 等全新的方式，公眾號在@Damonwong、@邦Ben 和 @紅紙 地運營下，也逐漸走上正軌。至此我也能說上一句不負所托。
雖然正如樑傑所說的 “組織總有盡頭”，但我還是希望週報在未來的日子裡還會有三代目、四代目……感謝我們三大組織的所有參與者，以及我們所有的讀者和聽眾。
內推
老司機週報團隊聯合知識小集和 SwiftGG 翻譯組收錄了一份靠譜的內推職位。
如果你想 找工作 ，點這裡： www.yuque.com/iosalliance…
如果你想 招人 ，點這裡： www.yuque.com/iosalliance…
當然，也歡迎你關注我們每一期的週報，我們會在每期週報底部及時更新編輯內推崗位。
關注我們
我們開通了公眾號，每期釋出時公眾號（OldDriverWeekly）會推送訊息，歡迎關注。
同時也支援了 RSS 訂閱： github.com/SwiftOldDri… 。