移動端架構(gòu)的幾種模式

最近很多文章都在談移動端的架構(gòu)，在早些年的時候，移動端是沒有所謂的架構(gòu)可言的，很大的原因是因為移動端開發(fā)剛剛興起，剛剛興起意味著“代碼存量少”，意味著軟件復(fù)雜度相對于傳統(tǒng)的服務(wù)端開發(fā)更低。但是最近越來越多的人談到軟件架構(gòu)很大一部分原因是移動端經(jīng)過十年的積累，誕生了越來越多的大型App，業(yè)務(wù)發(fā)展越來越快，例如微信、支付寶、天貓之類的App。 正因有越來越多的大型App，業(yè)務(wù)越來越復(fù)雜?？焖侔l(fā)版，快速運營需求越來越強烈，對移動端要求更加偏向于前端化，因此各種快速開發(fā)框架層出不窮，RN、Weex、Flutter。同時為何更好的組織移動端的代碼，將傳統(tǒng)的軟件架構(gòu)移到了移動端開發(fā)上面，從最開始的mvc到mvp、mvvm,以及綜合各種概念的clean架構(gòu)。

更多內(nèi)容: CO-有面試上CO (baidu搜索)

業(yè)務(wù)即架構(gòu)

很多人在開發(fā)伊始就開始想著后期要怎么擴展，設(shè)計無比復(fù)雜的架構(gòu)，最終導致開發(fā)起來非常痛苦，為了實現(xiàn)一個功能，寫各種各樣冗余的類，做各種各樣重復(fù)的事情，導致效率低下，“過度設(shè)計”是架構(gòu)設(shè)計可能犯下的第一個錯誤。

如何做恰當?shù)募軜?gòu)設(shè)計？自己實踐經(jīng)驗來看，第一步先不用去考慮你需要什么架構(gòu)，而是應(yīng)該思考你這個項目的核心業(yè)務(wù)是什么，再考慮為了實現(xiàn)這個核心業(yè)務(wù)，大最重要的技術(shù)點是什么？ 德魯克管理一書中有一句話：圍繞著價值大的點去設(shè)計流程。

同樣道理，圍繞著最核心的業(yè)務(wù)、最核心的技術(shù)點去設(shè)計架構(gòu)才是最重要的。

對于一個以H5為主的App，你最重要的架構(gòu)設(shè)計是設(shè)計好H5和原生的交互方式，如何快速的加載出H5頁面。 對于一個以主要以圖片加載為主的App, 最重要的核心技術(shù)點就是大量圖片的加載，好的圖片加載框架，項目已經(jīng)成功了一半。

對于一個本地數(shù)據(jù)庫為主的App，如何設(shè)計好本地數(shù)據(jù)庫的讀取和存儲，如何選擇一個適合的輪子去處理好數(shù)據(jù)庫存在的問題，才是最根本的架構(gòu)設(shè)計。

我見過一些項目，最表層項目結(jié)構(gòu)設(shè)計的很好MVP+RxJava，但是最重要，最核心的數(shù)據(jù)庫模塊還是古老、低效的設(shè)計，導致的結(jié)果就是，涉及到核心的數(shù)據(jù)庫操作就麻煩、復(fù)雜、低效。甚至出現(xiàn)整個項目組只有一兩個人能看明白最核心的代碼，這樣下來無論是最外層的架構(gòu)設(shè)計多么NB，整個項目是低效的。沒有從最開始的時候設(shè)計好核心東西的架構(gòu)設(shè)計，沒有在開發(fā)過程花力氣去優(yōu)化最核心的模塊。

最簡單的就是最好的

我一直認為，最簡單的東西往往最有力量。

比如 首付5成，貸款加息50% 越多的解釋，就顯得心虛，解釋就是掩飾。架構(gòu)設(shè)計也是如此，越是簡單的架構(gòu)設(shè)計，越容易學會，合作的同事越容易接受，就像代碼設(shè)計，自解釋的代碼比寫滿了注釋的代碼設(shè)計的要更好。

clean架構(gòu)為什么不容易流行，因為太復(fù)雜了，它把Java Web開發(fā)那一套搬到了移動端，如果應(yīng)用到項目中，可能除了架構(gòu)設(shè)計者，沒人能夠完全明白整個架構(gòu)設(shè)計。

相反，為什么MVC 和MVP容易推廣，因為簡單,可復(fù)制性強，無需思考，學習容易。谷歌官方開源了一套MVP架構(gòu)設(shè)計思路，非常值得借鑒，除了寫重復(fù)性代碼多一些以外（重復(fù)性代碼可以通過模板自動生成），代碼易用性、維護性都是設(shè)計的典范。

代碼邏輯守恒

架構(gòu)設(shè)計中有很多的設(shè)計模式、固定范式大部分都是圍繞著分層進行設(shè)計的 軟件開發(fā)中沒有什么問題不能通過加一層來解決的

分層思想其實契合人類對事物的認知模式，各司其職，分工不同，從傳統(tǒng)農(nóng)業(yè)社會的架構(gòu)-士、農(nóng)、工、商，每個層級負責對應(yīng)層級的事情，每個層級有既有隔離又有溝通。 移動端開發(fā)也是一樣，從大層級劃分，可以劃分為業(yè)務(wù)層、持久層、UI層，從細分角度來看，又可以分層各種組件類，比如網(wǎng)絡(luò)、圖片、緩存、日志等等模塊，而通過對這些組件的的組合形成更大的模塊。各個模塊之間既有數(shù)據(jù)的傳遞和流動，又會對各個層級之間數(shù)據(jù)的傳遞做限制。最明顯的例子MVP框架，P層作為溝通的橋梁，負責M和V層數(shù)據(jù)的交互，但是又限制V和M層直接進行數(shù)據(jù)的交互，這樣很大程度減少了數(shù)據(jù)流向復(fù)雜的問題。 總之，我認為架構(gòu)設(shè)計是對代碼邏輯二次劃分，代碼邏輯永遠是守恒的，差別在于你是如何管理這些邏輯的。

MVP管理邏輯的辦法很簡單，就是將所有邏輯放到了P層中，保持M層和V層的純粹性，但是毋庸置疑P層是會隨著業(yè)務(wù)邏輯的增加，復(fù)雜度會產(chǎn)生巨大的增長，因此這個時候就需要對P層在做邏輯的轉(zhuǎn)移。因此在對P層邏輯轉(zhuǎn)移過程中，就產(chǎn)生了各種各樣的helper類，結(jié)合各種各樣的網(wǎng)絡(luò)處理框架、RxJava響應(yīng)式編程框架等等，這些東西都是為了邏輯轉(zhuǎn)移而做的工作。

這篇文章不談具體的移動端架構(gòu)設(shè)計，更多的是從架構(gòu)本身聊一下關(guān)于架構(gòu)設(shè)計的一些思想，以及在實踐過程中的一些想法，一家之言，歡迎探討。

本文題目：移動端架構(gòu)的幾種模式
網(wǎng)頁鏈接：http://www.bm7419.com/news26/101726.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供ChatGPT、網(wǎng)站設(shè)計公司、企業(yè)建站、用戶體驗、小程序開發(fā)、網(wǎng)站制作

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)