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

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

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

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

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

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

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

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

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

最簡(jiǎn)單的就是最好的

我一直認(rèn)為，最簡(jiǎn)單的東西往往最有力量。

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

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

相反，為什么MVC 和MVP容易推廣，因?yàn)楹?jiǎn)單,可復(fù)制性強(qiáng)，無(wú)需思考，學(xué)習(xí)容易。谷歌官方開源了一套MVP架構(gòu)設(shè)計(jì)思路，非常值得借鑒，除了寫重復(fù)性代碼多一些以外（重復(fù)性代碼可以通過(guò)模板自動(dòng)生成），代碼易用性、維護(hù)性都是設(shè)計(jì)的典范。

代碼邏輯守恒

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

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

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

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

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

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

廣告

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