最近很多文章都在談移動端的架構，在早些年的時候，移動端是沒有所謂的架構可言的，很大的原因是因為移動端開發剛剛興起，剛剛興起意味著“程式碼存量少”，意味著軟體複雜度相對於傳統的服務端開發更低。但是最近越來越多的人談到軟體架構很大一部分原因是移動端經過十年的積累，誕生了越來越多的大型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響應式程式設計框架等等，這些東西都是為了邏輯轉移而做的工作。
這篇文章不談具體的移動端架構設計，更多的是從架構本身聊一下關於架構設計的一些思想，以及在實踐過程中的一些想法，一家之言，歡迎探討。