移動互聯網發展10餘年來，移動應用也誰之發生了翻天覆地的變化。從最初的幾M小應用到現在動則幾十上百M；從最初的一個人幾個小功能，到現在的幾十上百號人，比PC網頁還要齊全還要強大的功能。在此過程中，原有的單Project，MVC架構，一個月一發版，已經遠遠不能滿足當前移動應用的開發。於是乎，一個新的名詞便誕生了--移動架構師。
總有開發者朋友問我，得具備什麼樣的水平，多長的工作經驗，做過多大的項目才能成爲一個架構師啊。的確，這個問題很難回答。架構，在很大程度上並不具有具體的角色定位，架構師亦然。能夠獨立做出一個APP，可以稱爲這個APP的架構師。能夠把控一個超級APP的所有技術解決方案，可以稱爲這個超級APP的架構師。
總有開發者朋友問我，什麼樣的架構纔是好架構。在很長一段時間，C/S架構獨領風騷，隨後B/S架構橫空出世，一時風頭無兩，但是隨着移動互聯網的出現和發展，C/S架構又成爲移動應用的主流，再次煥發初生命地光彩，重拾其榮耀，但與此同時B/S卻也依然堅挺。這就是架構，只有適合，沒有好壞。
同樣，我們今天所談論的這套宏偉的iOS架構，是絕對不適合只有幾個頁面的小APP的。至於如何抉擇，3人以上的開發團隊可以組建化，百萬級別日活可以熱切換，百萬級別用戶量可以熱更新，需求頻繁、功能分佈零散，高耦合可以用MVVM。
數據持久化方案，網絡方案，MODEL方案，這些也是架構，怎麼今天不談呢？因爲這是技術，而我們今天所談論的是思想。
APP組件化，我總結了兩種方案。總線+分線、分線+分線。第一種，總線+分線方案，對應IOS APP，即多個子模塊加一個主模塊，主模塊負責所有子模塊間的組合和通信，必不可少；第二鍾，分線+分線，即任意兩個子模塊都可以組合構成一個獨立的APP。對於這兩種方案，第一種便於理解和實現，第二種靈活性更高，優勢虐勢都很明顯，至於取捨，選則自己擅長的便是。
APP組件化的具體實現，我推薦使用CocoaPods私有Pod來實現各個組件，理由有下，技術成熟、資料衆多，使用者衆。具體實現方式亦有兩種。第一種，將各個組件做爲LocalPod，方便調適，維護。第二種，像第三方Pod一樣作爲外部組件引入，優勢是便於把控。同時，這兩種方式也可以結合使用，與業務毫無關聯的基礎組件，可以作爲第三方Pod引入，由團隊專人維護，而將業務模塊作爲LocalPod引入，可以方便調適、維護。至於具體實現，請參看文章末尾的Git項目。
APP熱切換，即在用戶使用APP的過程中，出現某一個或者多個功能無法使用時，直接將該功能切換爲React-Native的實現，或者H5的實現。前提是你有React-Native或者H5的備份可供下發，並且APP提供了所有正常功能的訪問權限和方法。實現難度不高，但是成本巨大，除非著名大廠高日活APP，否則沒有太大的實現必要。唯一一點實現難度，主要體現在各端數據格式的統一。打個比方，如果你的一個頁面出現了Bug，並且該頁面爲了用戶體驗是使用原生編寫，而該頁面的必要初始化參數通過上一頁面帶入，此時你臨時將頁面切換成RN或者H5的實現，則你所傳遞的參數必定要被其數據結構所認可。所以，如果要實現APP的熱切換，最好是各個功能、頁面都只使用一個identity字段作爲初始化的請求參數。至於具體實現，請參看文章末尾的Git項目。
APP熱更新，即無需發版，可做緊急Bug修復，和功能更新，在去年早些時候還有JSPatch等直接替換OC方法的方案來修復Bug，但是很不幸，現在已經被蘋果所禁用。目前主流的方案是使用RN構築View和實現業務邏輯，然後做有限的功能更新、和Bug修復，即通過RN對你APP所有原生功能做重新的排列組合，而修復一些不是由你的原生基礎庫所導致的Bug。目前主要有兩種實現方案，一種是原生提供所有的基礎功能和庫，由RN實現頁面和業務邏輯，需要從零開始開發；另一種是把RN作爲一個組件，植入到現有原生APP中，併爲RN提供主要原生頁面和功能的訪問支持，部分業務場景使用RN編寫，這樣實現有點類似於原生+H5，優點是性能高於H5，缺點是成本比H5更大。
MVVM架構，即Model-View-ViewModel的分層架構方案，但凡對架構稍有了解的都不會覺得陌生。但在iOS項目的具體實現中ViewController絕對是必不可少的，所以我們在iOS項目中也不妨將它理解爲Model-View-ViewModel-ViewController。Model、View這兩層一個是實體模型，一個是顯示和操作實體模型，在實際情況中Model中的數據和View中的數據往往存在差異，比如Model中有一個100，在View中卻要顯示爲100元，在View中有一個選項菜單，選擇的是具體菜單名，在Model中卻要保存爲菜單名+菜單ID，在Model中有一個詳細信息的數組，在View中卻要根據該信息的長度來控制列表上不同Cell的高度。在MVC架構中這些操作往往通過Controller來完成，但隨着業務的增加Controller卻又會變得無比的龐大，並且功能模塊難以複用。如果將這些操作交給View讓其自己去實現的話又會影響到View的可複用性。所以，爲了解決這樣的問題，ViewModel便應運而生了，ViewModel主要負責將業務和View關聯起來，其本質是對數據流的操作，其關注點亦是數據流。即數據發生改變，ViewModel刷新視圖，數據不同VIewModel提供不同的顯示方案，用戶操作視圖，VIewModel更新數據；同一個視圖，不同的ViewModel綁定不同的數據便做到了視圖的複用；不同的ViewController使用同一個ViewModel便做到了功能的複用和解耦；你也可以將ViewModel理解爲對業務的封裝；所以ViewModel應當具有如下功能，數據的取得、數據的處理、視圖的更新、數據的更新。即，ViewModel應當同時持有View和Model，或者ViewModel應當同時綁定View和Model。第三方開源模塊Rective Cocoa，提供非常簡便的綁定能力，個人推薦使用。至於具體實現，請參看文章末尾的Git項目。
所謂架構，本質上是爲了實現業務而對技術和人員的最有效排列組合。架構思想，則是從哲學的角度對經驗的總結和歸納。如果你把代碼看成有血有肉有思想的生命，那麼，架構思想，即創造代碼的哲學。你的代碼，即你的思想。