感謝作者 bang 的授權釋出，版權歸原作者所有，未經允許，請勿轉載。
原文地址：http://blog.cnbang.net/tech/3354/
作者：陳振焯，網名 bang，推特中文圈、伊書、JSPatch 作者。2011年畢業，曾在百度實習做 Web 前端，目前在騰訊做微信讀書 iOS 端。
技術之路，共同進步，歡迎投稿、給文章糾錯，請傳送郵件至 [email protected]，或加微信 tree-rain-chen。

最近有一些開發朋友問我應該怎樣提升自己的能力，回想起來做了這麼久 iOS 開發，我也有過那種“讓我做一個功能實現個需求我會做，但接下來怎樣提高我不知道。”的時期，這裡嘗試列一下 iOS 開發的相關技術，再說說在學習進階上我的一些想法。

iOS 技術棧

這裡按我的理解給 iOS 相關技術分個類，以工程實現的角度，分成了基礎、需求、效率、質量四個類別。基礎指程式開發和 iOS 開發的基礎知識和技能，需求就是產品的需求，有了基礎技能，實現了產品需求後，剩下的事情就都是為了提高專案質量和提升開發效率。

大致的思維導圖（高清點這裡）：

基礎

基礎包括語言、框架、記憶體、網路、儲存、渲染、執行緒。

語言目前 iOS 開發就是 OC 和 Swift，國內仍以 OC 為主，對於 OC 除了語法外，最好了解它的物件模型，動態機制等特性。Swift 方面若要在團隊裡使用，目前還是風險大收益小的，但個人最好保持對它的關注。

框架就是 Foundation / UIKit 以及蘋果系統封裝好的各種框架，Foundation 和 UIKit 每個做 iOS 開發的人都熟知這套，iOS 功能越來越多，蘋果提供的框架也越來越多，像 StoreKit / MessageUI / AVFoundation 等可以在使用到再去了解。

接著是客戶端裡最常見流程裡的四個關鍵部分：從網路拉取資料，儲存到本地檔案系統，再從本地取出來放進記憶體，最後渲染出來。而這裡所有的處理都在作業系統的程序和執行緒中執行。

網路方面若要深入的話內容很多，客戶端一般只需要關心 http / https / dns 這幾個協議，瞭解 https 的原理，處理運營商劫持 dns 劫持等情況，另外需要處理好各種異常情況做好重試機制，iOS 作為移動端網路不穩定，要看情況優化弱網路下的連線，做好離線機制，以及注意避免耗費太多流量。還有客戶端跟後臺的通訊協議，資料結構一般用 json 或 protobuf，由於客戶端本地會儲存一部分內容，很多 APP 都會需要做資料的增量更新。

儲存方面主要是 sqlite，sqlite 作為儲存引擎是大多數 APP 的核心，也是效能優化的關鍵點，最基本的需要知道主鍵索引事務等資料庫基本概念，再深入需要了解具體的儲存機制/索引的實現/sqlite的七層結構等，才能在遇到問題時找到最佳的解決方案。客戶端上 nosql 用得較少，除了 sqlite 一般就剩單檔案儲存，XML存檔案或物件序列化成二進位制儲存，也是常用的儲存方式，近期有 realm 這種新型資料庫，也值得了解一下。

記憶體方面，需要了解 OC 的引用計數、 ARC 機制、自動釋放池等相關點，最好其他語言的垃圾回收機制也有所瞭解，另外需要注意避免記憶體洩露，管理好客戶端的快取，避免快取太多導致OOM，或快取命中率太低效能低下。

渲染方面主要是文字和影象，基礎上文字方面 UIKit 已封裝得很好，CoreText也提供了更自由的排版渲染方式，影象渲染只需要注意解壓時機，再深入需要了解 iOS 具體的渲染機制，像圖層混合，渲染時機，離屏渲染等，才好做更多的優化。

執行緒和程序方面，iOS 開發只在做 Extension 時才需要考慮到程序，一般只需處理好執行緒，需要了解主執行緒子執行緒，多執行緒併發鎖競爭，死鎖，GCD，Runloop 等知識點。

需求

需求方面姑且概括為普通需求、特殊需求和運營需求。

普通需求就是上面提到的網路拉資料->儲存->讀取->展示，大多數 APP 主要都是在實現這類需求，熟悉上述的基礎知識後就能輕易實現。

特殊需求是指一些特定 APP 的需求，像瀏覽器核心，文字排版引擎，音視訊和影象處理引擎，圖示繪製引擎等，要求較高，都需要在相關領域裡較深入的鑽研才能做好。

運營需求是 APP 上線後持續運營過程中的需求，包括功能動態化，可以隨時增刪改線上的功能，一般這塊由內嵌 web 承擔。配置系統也算動態化的一種，可以通過各種開關控制展現的功能。統計系統記錄 APP 各項運營資料，包括使用者增長情況，留存率，功能使用情況等。事件流可以清楚看到使用者在 APP 裡的使用流程。有些 APP 還會開發推薦系統，根據收集來的資料給不同使用者推送不同內容，提高使用者轉化率等。

質量

越大的 APP 會花越多的精力在保證和提高 APP 質量上，包括效能優化，搭建監控體系，提升程式碼質量，保證安全，以及通過測試保證質量。

效能優化範圍很大，在網路/儲存/記憶體/渲染/演算法各方面都有優化的可能，一般效能上的優化可以分成三步走，一是檢測各方面的資料，量化執行效能，二是從中找到效能瓶頸，三是找辦法優化，用第一步的資料驗證優化效果。

監控體系在面向大眾使用者的產品裡無論是前端後端一直都是非常重要的，你需要時刻知道使用者在使用你的產品過程中有沒有發生什麼問題，讓你的 APP 處於可知可控狀態，客戶端最常見的監控點是 crash，這個無需多說，另外一般對於 APP 裡的錯誤碼，包括本地錯誤、網路錯誤等都需要監控起來，這樣在出現異常時才能即時得知進行處理。其他通用的監控包括卡頓監控、資料庫監控、流量消耗監控、記憶體消耗監控、各種耗時監控等等，還有各類業務相關的監控，越大的 APP 監控的專案就越多越細緻，目的都是及時發現問題，以及衡量 APP 的質量。除了監控問題外，這裡還需要做好出錯時的補救措施，可以通過預埋功能開關配置或接入熱修復的庫去做。

安全方面，客戶端上安全的分量相對於服務端是少很多，尤其是在 iOS 系統沙盒機制的保護下，本身已經比較安全，最需要注意的是網路傳輸的安全，避免網路傳輸內容被篡改，或洩露了使用者名稱密碼等敏感資訊。對於程式碼裡有機密資訊的可以考慮混淆程式碼對 APP 進行加固，減少被破解的概率。

程式碼質量主要存在於團隊協作上，一般團隊都會定義程式碼規範，讓大家的程式碼風格趨於一致，有些會開發程式碼規範檢測工具，確保提交的程式碼遵循程式碼規範。另外很多團隊都會實行 code review 機制，互相檢視程式碼，減少髒亂差程式碼出現的概率，具體 review 機制各有不同。

測試是一個專業，國內終端產品因為迭代快，常見的是黑盒測試，雖然不能保證無問題，但成本低效率高，部分穩定的核心功能會做單元測試，也有一些團隊所有業務功能都做自動化測試的。

效率

客戶端的架構可以說都是為了提高開發協作效率，因為功能可以用很多種方法實現，可以不需要什麼架構，無論是大型還是小型 APP 都可以按一套來實現，只不過差的架構在中大型 APP 上程式碼會很混亂，導致在開發/協作/debug上效率會越來越低，好的架構則會提升這裡的效率。大多數架構都是分層抽象和解耦，把功能獨立的元件抽離出來，業務模組化，分層職責清晰，互相不耦合。只要分層抽象和解耦做得足夠好，無論多大的 APP 都是很多小模組的拼接，就可以降低複雜度，提高開發效率。但有時解耦會帶來通訊的麻煩，抽象也有粒度大小的問題，這些都需要根據具體情況權衡。業界有各種各樣的架構模式可供參考，像 MVC / MVVM / MVP / VIPER 等。除了解耦和抽象，還有一些改變編方式的架構，像響應式程式設計，單向資料流等。

持續整合的意思是不斷把每個人做的東西（程式碼/資源等）整合到一起輸出成品，進行自動化構建，其中涉及程式碼管理（git / svn），編譯流程，證書和簽名機制，自動化測試，打包釋出等。其中還會有一些自定義的自動化流程，例如自動生成程式碼，根據 debug / release 包型別自動更改配置等，重複做的事都應該自動化，以提高開發效率。

業界為了提升開發效率，跨平臺開發一直是大家孜孜不倦追求的目標。終端上跨平臺願望是隻開發一次，就能完美執行在 Android 和 iOS 上，業界有很多嘗試，這篇文章總結得比較全，總的來說目前最好的跨平臺方案就是 web (H5)，代價是效能略低。

進階

列完 iOS 開發的相關知識點，接下來說說怎樣學習提高。

如果自學能力強的話，不需要多說，上述每個點網上都有大量資料，像記憶體網路儲存這些計算機基礎知識也有經典的書籍，一個個啃下去就行了，只要理解得足夠深入，就已經可以成為領域裡的專家，並很容易觸類旁通。

但這種學習方法會比較枯燥，也難以實踐，個人還是比較推薦在實踐中學習，具體來說就是在平時開發過程中不斷地發現問題 -> 解決問題。

發現問題

首先你最好處在一個有很多工程上的問題急需解決的環境裡，這樣發現問題就很容易，最好的是處於這幾類專案裡：

1. 處於高速發展期的專案。增長會帶來很多問題，一切又未成熟，解決這些問題是非常自然又有價值的。
2. 龐大的專案，超級APP會帶來很多中小型APP沒有遇到過的問題，又因為體量大，就算只有千分之一的人遇到也會影響幾十萬人，很有解決的價值，會有很多細緻的問題。
3. 像上面提到的有“特殊需求”一類的專案，需要在一個領域裡深入研究，也會自然碰到很多問題。

如果恰巧沒有在這三種類型的專案裡，也沒關係，只要是健康發展的專案，總會存在問題和優化空間，只是要培養髮現問題的意識，很多時候問題就在那裡，但沒人發現它，沒人覺得它可以/應該解決。可以按上述列的點，在相關點上多問自己能不能提高效率和質量，例如能不能提高前後臺聯調效率，重複寫的程式碼能不能自動生成，啟動耗時能不能短一點，線上問題發現和排查的效率能不能提高等等。各種問題會涵蓋上述提到的所有知識點。

如果不幸你的專案沒有健康發展，實在沒碰到什麼問題或者問題不值得解決，或者你還沒畢業，那這裡還有一個萬能問題可供參考：那些知名的開源專案具體是怎樣實現的？剖析開源專案原始碼可以學到很多東西，各種各樣的開源專案也覆蓋了很多知識面，只要深入去研究它們，學習它的架構和編碼，不懂的地方再去補齊知識，也是個很好的學習方式，如果學習後能輸出文章效果會更好，相當於動手實踐了。

解決問題

不同的解決問題的方式差別很大，有一些常見的套路可供參考：

1. 業界是怎樣解決這個問題的？他們的方案有什麼不足？我怎樣可以做得更好？

   業界有各種各樣的開源庫和技術分享，只要問題不是太偏門，大多會有人已經提出解決方案，多對比和研究這些已有的方案，看它們是否能滿足需求，找出它們的優點和不足，看看能不能做得比它們更好或更適合解決碰到的問題。

2. 解決方案能否通用化，封裝成開源庫供其他專案使用？

   開源專案都是這樣來的，如果遇到一個別人沒解決好的問題，別錯過封裝成開源庫造福社會。

3. 有沒有辦法防止以後出現類似的問題？

   有些問題可能會反覆出現，能不能防止，或者能不能在出現問題的時候能及時發現和修復，這可能涉及到開發流程、自動化和監控體系等方面的完善。

4. 總結沉澱

   能不能總結出解決這類問題的方法論（套路）？最好能輸出文章或分享，寫的過程是很好的學習過程，因為要把原本模糊的想法都清晰地表達出來，迫使自己去整理思路。

總結

這裡按我的理解列了 iOS 相關技術點，以及在實踐中提升能力的一點小建議，可能無法各方面都覆蓋到，只是作為一個參考。另外這裡只侷限在 iOS 開發上，實際上作為程式設計師不應該限制自己學習的範圍，有時間多去了解後端/前端/運維也會很有利於自身開發能力的提高。