筆記來源infoq：滴滴iOS客戶端的架構演變之路

1，狀態機，把訂單中的階段，例如：計程車的等待搶單、計程車的等待接駕、專車的等待搶單、專車的等待接駕，都當成一種獨立的狀態，每 個狀態機只需要知道可能要導向的狀態機，從而做到了相對獨立，狀態機滿足了計程車、專車雙業務線的需求。
狀態機是什麼？簡單的概括為：用一個列舉型別的變數（它通常是單例全域性變數或本檔案有效的靜態區域性變數） ，根據這個變數當前的狀態進行對應處理。
狀態機不只用在資料再加工，檢視（UIView）載入和變換,頁面跳轉，業務線切換，也用在連續操作或處理控制。
狀態機都可以畫出對應的狀態機切換圖。在狀態機切換圖上，它通常都是從不穩定狀態向穩定狀態定向遷移，狀態機都有方向性。
狀態機在複雜邏輯具有很大的使用空間，看了狀態機遷移圖，讓人一看就知道它的處理邏輯。能形象的表達複雜邏輯。
像【長篇高能】ReactiveCocoa 和 MVVM 入門這篇文章說的能替換狀態機，那是它不知道狀態機的真正使用範圍有多廣，並非它理解的僅僅是資料加工那麼簡單。
2，“程式碼治理”，可以“分而治之”的目標。

在各個業務線各自開發的情況下防止程式碼大面積腐化，方便未來再做更加細緻的架構重構， 採用CocoaPods的方式進行拆分；元件化之後，公共部分拆分為技術元件、公用業務元件，每個業務線是單獨元件，如計程車元件、專車元件、快車元件； 通過把不同功能的元件程式碼拆分到不同的 pod 裡，實現了業務線僅依賴於公共就可以迭代開發，改善了功能開發和協同發版。元件化只是做了治理的第一步，後面的架構優化還任重而道遠。

3，目前滴滴的 iOS 架構採用 MVCS 和 MVVM 的架構方式。MVCS 的 S 是 Store 的意思，包括伺服器訪問介面控制、資料共享、資料快取的能力，每個 Store 處理一類情況，例如：訂單 Store 會包括髮單、取消訂單、結束訂單、評價訂單等，常用地址 Store 會包含編輯常用地址、刪除常用地址、拉取常用地址等。MVCS 這種方式的思考邏輯是希望做到元件無狀態，完全依賴於 Store 所返回的各種狀態資訊，這種思想是非常類似於 React Native + Redux 的思路。

4，滴滴iOS客戶端的元件化是如何劃分的，採用什麼技術實現？

我們在15年後半年實施了元件化，元件包括技術元件和業務元件，技術元件是可以跨 App 使用的，例如：網路元件（長連線和短連線）、介面導航管理元件（統一介面轉場方式，模組間介面轉場，通過openURL方式解耦）；根據業務功能，已經實 現了支付、登入、訊息、定位、廣告SDK、資料統計、分享等元件，每個元件是獨立的CocoaPods。

元件採用私有 CocoaPods 來實現，並採用了 Local Pods 的方式，可以在本地不提交程式碼的情況下，元件與呼叫方實現除錯。元件間的頁面間跳轉支援 openURL 的方式，由 ONERoute 模組進行管理，頁面在 +(void)load 方法中完成註冊，ONERoute 內部儲存一份 URL 與 Class 的對應表，當呼叫 openURL 時，會查詢到對應的類，然後生成對應的例項物件。這種方式可以通過 URL 解耦具體的類名稱，方便從 H5 拉起 Native 頁面，未來還可以實現流程的可配置化。在設定頁面裡，還是直接依賴類的方式，避免過度使用 openURL。為了增加安全性，每個頁面會設定是否允許外部開啟，僅有允許外部開啟的頁面才可以通過系統的 openURL 方式開啟。

筆記來源infoq：滴滴出行技術總監：關於技術選型的那些事兒

技術選型要謹慎。

技術選型關鍵需要思考三個角度：技術、業務和人。

技術

第一，要取其長避其短；第二，要關注技術的發展前景。

技術的“前景”可以從幾個維度來判斷，有沒有長期規劃、有沒有持續投入的人或者社群、問題解決的速度如何、業界使用案例及口碑、原始碼質量。

新技術實踐後的積累，有案例和背後的細節，踩的坑，和避免這些坑。

業務

新技術往往被早期創業團隊或大公司的新興業務使用

人

技術選型也非常依賴於人的能力。選型是一件很難被標準化的過程，選型的決策質量跟人的眼界、經驗、業務敏感度、邏輯性等息息相關。就我自己來說，我在面臨一個選型問題時首先考慮的是去學習，看看公司內外類似的問題如何解決的，避免自己閉門造車，然後思考所有的可能性，列舉最核心需要考慮的因素，心裡列一個方案優劣對比，最後將這些邏輯整理清楚，落地成一個決策。

想做好技術選型還是挺難的，要想做好得有足夠的知識積累和實際踩坑的經歷才行。

如何學習

最後難在資訊究竟如何存入知識索引，知識太零散形成不了體系，建不了索引怎麼辦。最入門的做法是看書，看別人是怎麼將知識變成一個個章節的資訊。要想掌握建立索引背後的方法論，我的經驗是先從兩個相近的技術開始，找到建索引的感覺，然後再鋪開去學習更多知識。有這樣困惑的開發者往往在學習方面有些貪心，覺得自己記性好可以囫圇吞棗式的將知識強行內化，這樣做短期可以，長期還是會遺忘，也形成不了經驗。

其實技術知識之間非常像，有很多共性的點可以挖掘。比如客戶端和前端開發，各個框架在 View 生命週期管理、訊息派發機制等方面非常像，後端開發則更加的套路化，無論用那種語言，最基本的分散式服務原理、快取、佇列、資料庫等基礎元件原理，都萬變不離其宗。

如果我們更巨集觀的看每個領域，甚至於都能發現領域之間的知識體系劃分也很類似。作為表現層的前端和客戶端，知識體系都可以分為語言、API、工程化、框架和設計模式。比如前端的語言包括 HTML、CSS、Java 和一些稍小眾的 Type、Coffee 等，API 就是各種標準、介面的使用、能夠實現的效果、平臺限制等，工程化就是各種打包工具、程式碼轉化工具、輔助開發工具等，框架就是像 Vue、React 等，設計模式就是像 PWA、redux 等。

相應的，剛剛說的這些知識都能找到在 iOS 或 Android 裡幾乎對應的知識，無非換了一些細節，這裡我就不繼續展開了。服務端也是這樣，知識體系最頂層的部分也很少，具體到細節，只是要了解每一個實現背後的優劣。

我在創業階段，每一年寫十萬行程式碼。但我進入滴滴後，寫程式碼的價值可能就不是那麼多了，但我還是喜歡寫程式碼。