Swift with Hundreds of Engineers——Motivation, Architecture, Learnings
Tuomas Artman, Staff Engineer, Uber
主要講述了Uber從OC遷移到Swift的動機腥寇、目標以及坑的解決方案成翩。
動機主要是看到了Swift的發(fā)展?jié)摿Γ乙呀洺醪椒€(wěn)定赦役。
目標
- 確保核心業(yè)務流程的可靠
- 支撐UberApp未來的發(fā)展--分離麻敌、解耦
- 為工程師、設計師提供詳細計劃扩劝，確保各司其職庸论，各有所務
- 流程自動分析、記錄棒呛、調試、跟蹤
- 第三方插件風險檢測
- 性能調優(yōu)域携，完美支持低版本API簇秒、低配設備
存在問題
- App體量過大，上萬個文件秀鞭，百萬行代碼
經驗總結
Swift的優(yōu)缺點
優(yōu)點：
- Swift的語法嚴謹趋观，在編譯時已經避免了很多不必要的bug扛禽。使得Swift版Uber的崩潰率僅為安卓的1/3；
- 集成靜態(tài)檢查測試皱坛，規(guī)范工程師代碼编曼；
- 語法更貼近JAVA/JS，安卓工程師較OC更為歡迎剩辟。
缺點：
- 難以測試掐场，objc下可以使用OCMock來mock對象。但是贩猎，由于swift的runtime比較弱熊户，所以，swift上一般要手動寫mock吭服；
- 編譯巨慢嚷堡；
- 包體積較大；(原因：結構體艇棕、可選值蝌戒、泛型、Swift的Runtime庫)
- 啟動速度沼琉。（原因：動態(tài)庫鏈接瓶颠、測試的配置文件，重新排序符號表）
解決方案：
- ~
- 棄用Xcode,使用alternatives刺桃，使用更多frameworks粹淋，-warn-long-function-bodies檢測編譯耗時過久的方法并嘗試改善，將多個文件合并為一個將極大提高你的編譯效率瑟慈，Xcode配置桃移，使用Buck。
最后的友情提示：
當你的開發(fā)團隊越來越大時葛碧，你務必：
- 注意編譯時間
- 檢測二進制文件大小
- 嘗試解決如何單元測試
- 開始使用Buck
Concurrency on iOS
Sam Davies,RayWenderlich CTO
印象：很酷借杰，有hip-pop范??
線程優(yōu)先級翻轉、線程死鎖的概念进泼。
提供了Promise方案解決異步流程處理及回調地獄問題蔗衡。
