2021-02-19 分類: 網(wǎng)站建設(shè)
最近很多文章都在談移動(dòng)端的架構(gòu),在早些年的時(shí)候,移動(dòng)端是沒有所謂的架構(gòu)可言的,很大的原因是因?yàn)橐苿?dòng)端開發(fā)剛剛興起,剛剛興起意味著“代碼存量少”,意味著軟件復(fù)雜度相對(duì)于傳統(tǒng)的服務(wù)端開發(fā)更低。但是最近越來越多的人談到軟件架構(gòu)很大一部分原因是移動(dòng)端經(jīng)過十年的積累,誕生了越來越多的大型App,業(yè)務(wù)發(fā)展越來越快,例如微信、支付寶、天貓之類的App。 正因有越來越多的大型App,業(yè)務(wù)越來越復(fù)雜??焖侔l(fā)版,快速運(yùn)營需求越來越強(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ì)無比復(fù)雜的架構(gòu),最終導(dǎo)致開發(fā)起來非常痛苦,為了實(shí)現(xiàn)一個(gè)功能,寫各種各樣冗余的類,做各種各樣重復(fù)的事情,導(dǎo)致效率低下,“過度設(shè)計(jì)”是架構(gòu)設(shè)計(jì)可能犯下的第一個(gè)錯(cuò)誤。
如何做恰當(dāng)?shù)募軜?gòu)設(shè)計(jì)?自己實(shí)踐經(jīng)驗(yàn)來看,第一步先不用去考慮你需要什么架構(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頁面。 對(duì)于一個(gè)以主要以圖片加載為主的App, 最重要的核心技術(shù)點(diǎn)就是大量圖片的加載,好的圖片加載框架,項(xiàng)目已經(jīng)成功了一半。
對(duì)于一個(gè)本地?cái)?shù)據(jù)庫為主的App,如何設(shè)計(jì)好本地?cái)?shù)據(jù)庫的讀取和存儲(chǔ),如何選擇一個(gè)適合的輪子去處理好數(shù)據(jù)庫存在的問題,才是最根本的架構(gòu)設(shè)計(jì)。
我見過一些項(xiàng)目,最表層項(xiàng)目結(jié)構(gòu)設(shè)計(jì)的很好MVP+RxJava,但是最重要,最核心的數(shù)據(jù)庫模塊還是古老、低效的設(shè)計(jì),導(dǎo)致的結(jié)果就是,涉及到核心的數(shù)據(jù)庫操作就麻煩、復(fù)雜、低效。甚至出現(xiàn)整個(gè)項(xiàng)目組只有一兩個(gè)人能看明白最核心的代碼,這樣下來無論是最外層的架構(gòu)設(shè)計(jì)多么NB,整個(gè)項(xiàng)目是低效的。沒有從最開始的時(shí)候設(shè)計(jì)好核心東西的架構(gòu)設(shè)計(jì),沒有在開發(fā)過程花力氣去優(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),無需思考,學(xué)習(xí)容易。谷歌官方開源了一套MVP架構(gòu)設(shè)計(jì)思路,非常值得借鑒,除了寫重復(fù)性代碼多一些以外(重復(fù)性代碼可以通過模板自動(dòng)生成),代碼易用性、維護(hù)性都是設(shè)計(jì)的典范。
代碼邏輯守恒
架構(gòu)設(shè)計(jì)中有很多的設(shè)計(jì)模式、固定范式大部分都是圍繞著分層進(jìn)行設(shè)計(jì)的 軟件開發(fā)中沒有什么問題不能通過加一層來解決的
分層思想其實(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ì)分角度來看,又可以分層各種組件類,比如網(wǎng)絡(luò)、圖片、緩存、日志等等模塊,而通過對(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ù)雜的問題。 總之,我認(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)移過程中,就產(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í)踐過程中的一些想法,一家之言,歡迎探討。
本文題目:移動(dòng)端架構(gòu)的幾種模式
網(wǎng)頁鏈接:http://m.rwnh.cn/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í)需注明來源: 創(chuàng)新互聯(lián)
猜你還喜歡下面的內(nèi)容