移動端架構的幾點思考

最近不少文章都在談移動端的架構，在早些年的時候，移動端是沒有所謂的架構可言的，很大的緣由是由於移動端開發剛剛興起，剛剛興起意味着「代碼存量少」，意味着軟件複雜度相對於傳統的服務端開發更低。可是最近愈來愈多的人談到軟件架構很大一部分緣由是移動端通過十年的積累，誕生了愈來愈多的大型App，業務發展愈來愈快，例如微信、支付寶、天貓之類的App。

正因有愈來愈多的大型App，業務愈來愈複雜。快速發版，快速運營需求愈來愈強烈，對移動端要求更加偏向於前端化，所以各類快速開發框架層出不窮，RN、Weex、Flutter。同時爲什麼更好的組織移動端的代碼，將傳統的軟件架構移到了移動端開發上面，從最開始的mvc到mvp、mvvm,以及綜合各類概念的clean架構。

業務即架構

不少人在開發伊始就開始想着後期要怎麼擴展，設計無比複雜的架構，最終致使開發起來很是痛苦，爲了實現一個功能，寫各類各樣冗餘的類，作各類各樣重複的事情，致使效率低下，「過分設計」是架構設計可能犯下的第一個錯誤。

如何作恰當的架構設計？本身實踐經驗來看，第一步先不用去考慮你須要什麼架構，而是應該思考你這個項目的核心業務是什麼，再考慮爲了實現這個核心業務，最大最重要的技術點是什麼？

德魯克管理一書中有一句話：圍繞着價值最大的點去設計流程。

一樣道理，圍繞着最核心的業務、最核心的技術點去設計架構纔是最重要的。

對於一個以H5爲主的App，你最重要的架構設計是設計好H5和原生的交互方式，如何快速的加載出H5頁面。

對於一個以主要以圖片加載爲主的App, 最重要的核心技術點就是大量圖片的加載，好的圖片加載框架，項目已經成功了一半。

對於一個本地數據庫爲主的App，如何設計好本地數據庫的讀取和存儲，如何選擇一個適合的輪子去處理好數據庫存在的問題，纔是最根本的架構設計。

我見過一些項目，最表層項目結構設計的很好MVP+RxJava，可是最重要，最核心的數據庫模塊仍是古老、低效的設計，致使的結果就是，涉及到核心的數據庫操做就麻煩、複雜、低效。甚至出現整個項目組只有一兩我的能看明白最核心的代碼，這樣下來不管是最外層的架構設計多麼NB，整個項目是低效的。沒有從最開始的時候設計好核心東西的架構設計，沒有在開發過程花力氣去優化最核心的模塊。

最簡單的就是最好的

我一直認爲，最簡單的東西每每最有力量。好比

首付5成，貸款加息50%

越多的解釋，就顯得心虛，解釋就是掩飾。架構設計也是如此，越是簡單的架構設計，越容易學會，合做的同事越容易接受，就像代碼設計，自解釋的代碼比寫滿了註釋的代碼設計的要更好。

clean架構爲何不容易流行，由於太複雜了，它把Java Web開發那一套搬到了移動端，若是應用到項目中，可能除了架構設計者，沒人可以徹底明白整個架構設計。

相反，爲何MVC 和MVP容易推廣，由於簡單,可複製性強，無需思考，學習容易。谷歌官方開源了一套MVP架構設計思路，很是值得借鑑，除了寫重複性代碼多一些之外（重複性代碼能夠經過模板自動生成），代碼易用性、維護性都是設計的典範。

代碼邏輯守恆

架構設計中有不少的設計模式、固定範式大部分都是圍繞着分層進行設計的

軟件開發中沒有什麼問題不能經過加一層來解決的

分層思想其實契合人類對事物的認知模式，各司其職，分工不一樣，從傳統農業社會的架構-士、農、工、商，每一個層級負責對應層級的事情，每一個層級有既有隔離又有溝通。

移動端開發也是同樣，從大層級劃分，能夠劃分爲業務層、持久層、UI層，從細分角度來看，又能夠分層各類組件類，好比網絡、圖片、緩存、日誌等等模塊，而經過對這些組件的的組合造成更大的模塊。各個模塊之間既有數據的傳遞和流動，又會對各個層級之間數據的傳遞作限制。最明顯的例子MVP框架，P層做爲溝通的橋樑，負責M和V層數據的交互，可是又限制V和M層直接進行數據的交互，這樣很大程度減小了數據流向複雜的問題。

總之，我認爲架構設計是對代碼邏輯二次劃分，代碼邏輯永遠是守恆的，差異在於你是如何管理這些邏輯的。

MVP管理邏輯的辦法很簡單，就是將全部邏輯放到了P層中，保持M層和V層的純粹性，可是毋庸置疑P層是會隨着業務邏輯的增長，複雜度會產生巨大的增加，所以這個時候就須要對P層在作邏輯的轉移。所以在對P層邏輯轉移過程當中，就產生了各類各樣的helper類，結合各類各樣的網絡處理框架、RxJava響應式編程框架等等，這些東西都是爲了邏輯轉移而作的工做。

這篇文章不談具體的移動端架構設計，更多的是從架構自己聊一下關於架構設計的一些思想，以及在實踐過程當中的一些想法，一家之言，歡迎探討。