Swift with Hundreds of Engineers——Motivation, Architecture, Learnings
Tuomas Artman, Staff Engineer, Uber
主要講述了Uber從OC遷移到Swift的動(dòng)機(jī)、目標(biāo)以及坑的解決方案。
動(dòng)機(jī)主要是看到了Swift的發(fā)展?jié)摿?，而且已?jīng)初步穩(wěn)定。
目標(biāo)
- 確保核心業(yè)務(wù)流程的可靠
- 支撐UberApp未來(lái)的發(fā)展--分離、解耦
- 為工程師、設(shè)計(jì)師提供詳細(xì)計(jì)劃，確保各司其職，各有所務(wù)
- 流程自動(dòng)分析、記錄、調(diào)試、跟蹤
- 第三方插件風(fēng)險(xiǎn)檢測(cè)
- 性能調(diào)優(yōu)，完美支持低版本API、低配設(shè)備
存在問(wèn)題
- App體量過(guò)大，上萬(wàn)個(gè)文件，百萬(wàn)行代碼
經(jīng)驗(yàn)總結(jié)
Swift的優(yōu)缺點(diǎn)
優(yōu)點(diǎn)：
- Swift的語(yǔ)法嚴(yán)謹(jǐn)，在編譯時(shí)已經(jīng)避免了很多不必要的bug。使得Swift版Uber的崩潰率僅為安卓的1/3；
- 集成靜態(tài)檢查測(cè)試，規(guī)范工程師代碼；
- 語(yǔ)法更貼近JAVA/JS，安卓工程師較OC更為歡迎。
缺點(diǎn)：
- 難以測(cè)試，objc下可以使用OCMock來(lái)mock對(duì)象。但是，由于swift的runtime比較弱，所以，swift上一般要手動(dòng)寫(xiě)mock；
- 編譯巨慢；
- 包體積較大；(原因：結(jié)構(gòu)體、可選值、泛型、Swift的Runtime庫(kù))
- 啟動(dòng)速度。（原因：動(dòng)態(tài)庫(kù)鏈接、測(cè)試的配置文件，重新排序符號(hào)表）
解決方案：
- ~
- 棄用Xcode,使用alternatives，使用更多frameworks，-warn-long-function-bodies檢測(cè)編譯耗時(shí)過(guò)久的方法并嘗試改善，將多個(gè)文件合并為一個(gè)將極大提高你的編譯效率，Xcode配置，使用Buck。
最后的友情提示：
當(dāng)你的開(kāi)發(fā)團(tuán)隊(duì)越來(lái)越大時(shí)，你務(wù)必：
- 注意編譯時(shí)間
- 檢測(cè)二進(jìn)制文件大小
- 嘗試解決如何單元測(cè)試
- 開(kāi)始使用Buck
Concurrency on iOS
Sam Davies,RayWenderlich CTO
印象：很酷，有hip-pop范??
線程優(yōu)先級(jí)翻轉(zhuǎn)、線程死鎖的概念。
提供了Promise方案解決異步流程處理及回調(diào)地獄問(wèn)題。
