日韩欧美国产精品免费一二-日韩欧美国产精品亚洲二区-日韩欧美国产精品专区-日韩欧美国产另-日韩欧美国产免费看-日韩欧美国产免费看清风阁

前面多處提到了“架構(gòu)”這個(gè)詞，架構(gòu)架構(gòu)，到底什么是架構(gòu)？，每個(gè)人都有不同的理解，實(shí)際工作中，對(duì)于同一張架構(gòu)設(shè)計(jì)圖，由于不同的人對(duì)于“架構(gòu)”、“系統(tǒng)”、“模塊”這些相關(guān)概念的理解不一，討論的時(shí)候往往很難形成統(tǒng)一結(jié)論。

首先搞清楚什么是“架構(gòu)”， 網(wǎng)絡(luò)上有不少文章對(duì)此做解釋， 其中李運(yùn)華大佬的《從零開(kāi)始學(xué)架構(gòu)》前兩個(gè)章節(jié)介紹得比較清晰。“架構(gòu)” 一詞可以作為名詞， 也可以作為動(dòng)詞。作為名詞描述的是軟件的結(jié)構(gòu)組織關(guān)系；作為動(dòng)詞，指軟件結(jié)構(gòu)的設(shè)計(jì)和演變過(guò)程。先來(lái)看看做為名稱， 架構(gòu)的組成要素：

系統(tǒng)：當(dāng)“架構(gòu)”做名詞的時(shí)候， 可以簡(jiǎn)單的把系統(tǒng)同等預(yù)架構(gòu)， 可以說(shuō)一個(gè) App 的系統(tǒng)架構(gòu)。

模塊：系統(tǒng)不能描述架構(gòu)的內(nèi)部細(xì)節(jié)， 需要?jiǎng)澐譃楦鱾€(gè)模塊， 例如 xxApp 的架構(gòu)：

組件：可以認(rèn)為是系統(tǒng)的最小組成單元，例如消息模塊， 如果繼續(xù)細(xì)化的話， 可以拆分成消息發(fā)送器、消息接收器等組件。

關(guān)聯(lián)：組件、模塊往往不是獨(dú)立存在的，通常都存在著某種關(guān)聯(lián)， 例如消息模塊和用戶模塊，存在著依賴關(guān)系。

子系統(tǒng)：當(dāng)一個(gè)架構(gòu)規(guī)模和復(fù)雜度都比較大時(shí)，光用模塊和組件可能已經(jīng)描述不清楚了， 可以進(jìn)一步把某些相關(guān)的模塊群化為子系統(tǒng)。例如微信可能的架構(gòu)圖：

以上從架構(gòu)的名詞層面對(duì)齊了架構(gòu)組成元素的概念。“架構(gòu)”作為動(dòng)詞的時(shí)候，我們討論的是架構(gòu)的一些方法論。

縱向架構(gòu)，強(qiáng)調(diào)的是分層，核心就是分層思想，這個(gè)在操作系統(tǒng)架構(gòu)上已經(jīng)是一個(gè)經(jīng)久不衰的設(shè)計(jì)思想了。

這樣分層隔離的好處不言而喻， 如果你做過(guò) Android 模擬器開(kāi)發(fā)， 你就知道這里的 HAL 層是多么重要， 通過(guò)它可以輕易替換 Linux kernel 的實(shí)現(xiàn)， 通過(guò)模擬，讓 Android 可以輕松跑在 Windows 的系統(tǒng)里。

分層架構(gòu)是一種將系統(tǒng)程序按功能和職責(zé)劃分為不同層次的設(shè)計(jì)方法。每一層都有其特定的職責(zé),通過(guò)清晰的接口與其他層進(jìn)行交互。這種架構(gòu)方式有助于提高代碼的組織性、可維護(hù)性和可測(cè)試性， 可以輕松的替換、擴(kuò)展其中一層的核心能力。關(guān)于 App 如何做分層架構(gòu)設(shè)計(jì)， 我在 16 年就寫(xiě)過(guò)一篇文章《Android 應(yīng)用架構(gòu)概述 https://www.jianshu.com/p/e157cc64ea5c》 , 現(xiàn)在回頭看， 分層的本質(zhì)思想依然沒(méi)有變。

最基本的分層架構(gòu)通常包含以下三層：

表現(xiàn)層(Presentation Layer)：負(fù)責(zé)用戶界面的展示和用戶交互，包括 UI 組件、視圖控制器等，主要關(guān)注用戶體驗(yàn)和界面邏輯 。

業(yè)務(wù)邏輯層(Business Logic Layer)：實(shí)現(xiàn)核心的業(yè)務(wù)邏輯和規(guī)則，處理數(shù)據(jù)的加工、轉(zhuǎn)換和驗(yàn)證、協(xié)調(diào)表現(xiàn)層和數(shù)據(jù)訪問(wèn)層之間的交互。 

數(shù)據(jù)訪問(wèn)層(Data Access Layer)：負(fù)責(zé)與數(shù)據(jù)源進(jìn)行交互，包括本地?cái)?shù)據(jù)存儲(chǔ)(如 SQLite、Core Data)和網(wǎng)絡(luò)請(qǐng)求，提供數(shù)據(jù)的 CRUD(創(chuàng)建、讀取、更新、刪除)操作。

一定規(guī)模的 App 通常還會(huì)繼續(xù)分層，例如可以擴(kuò)展出基礎(chǔ)層出來(lái)。

表達(dá)的是分層的思想和方法， 具體分多少層， 取決于 App 規(guī)模和復(fù)雜度。

檢驗(yàn)標(biāo)準(zhǔn)：是否成功做到了分層， 檢驗(yàn)的標(biāo)準(zhǔn)就是是否真正給 App 帶來(lái)了前面提到的分層的好處，例如：要替換其中一層里的核心能力，是否可以低成本就替換， 當(dāng)某一層修改的時(shí)候， 是否可以單獨(dú)的對(duì)該層進(jìn)行單元測(cè)試。

隨著 App 功能規(guī)模、團(tuán)隊(duì)規(guī)模不斷擴(kuò)大， 這時(shí)候可能需要層業(yè)務(wù)模塊角度關(guān)注架構(gòu)設(shè)計(jì)，目的是降低功能規(guī)模增加而帶來(lái)的復(fù)雜度爆炸增長(zhǎng)，橫向架構(gòu)強(qiáng)調(diào)的是業(yè)務(wù)模塊之間的橫向解耦，從而降低復(fù)雜度。

圖中4個(gè)模塊都存在著依賴關(guān)系， 那么復(fù)雜度計(jì)算為 24：復(fù)雜度=4x3x2x1

如果我們通過(guò)某種手段進(jìn)行解耦（例如通過(guò)增加一個(gè) api 服務(wù)層隔離）：

通過(guò)這樣解耦，復(fù)雜度變?yōu)榱?5：四個(gè)模塊加一個(gè)隔離層。

通過(guò)上面的分析，基本可以看到， 模塊化解耦是一個(gè) App 發(fā)展到一定規(guī)模后繞不開(kāi)的話題， 淘寶、微信等這樣的巨型 App 早已在迭代過(guò)程中進(jìn)行了多輪的模塊化重構(gòu)， 參考：《微信 Android 模塊化架構(gòu)重構(gòu)實(shí)踐

https://cloud.tencent.com/developer/article/1005631》

檢驗(yàn)標(biāo)準(zhǔn)：橫向架構(gòu)是否成功， 檢驗(yàn)的標(biāo)準(zhǔn)是，如果這個(gè)模塊給獨(dú)立小組開(kāi)發(fā)，是否可以獨(dú)立開(kāi)發(fā)、編譯、調(diào)試。

我經(jīng)歷過(guò)幾十萬(wàn)、幾百萬(wàn)的中小型 App 搭建， 也參與千萬(wàn)日活的大型 App 應(yīng)用架構(gòu)，后者的架構(gòu)更復(fù)雜，用到的技術(shù)和手段也更豐富，是不是就可以把后者套用上去呢？答案顯然是否定的，不可能說(shuō)微信的架構(gòu)很牛， 那我們就搬過(guò)來(lái)用。架構(gòu)設(shè)計(jì)需要滿足三原則：

詳細(xì)可以參考：

《架構(gòu)設(shè)計(jì)三原則https://time.geekbang.org/column/article/7071》

適合原則：根據(jù)當(dāng)前的業(yè)務(wù)類型、規(guī)模選擇合適的縱向、橫向架構(gòu)設(shè)計(jì)方案

簡(jiǎn)單原則：所有在做架構(gòu)時(shí)，在有復(fù)雜方案和簡(jiǎn)單方案都可以滿足當(dāng)前業(yè)務(wù)是，盡量選擇簡(jiǎn)單方案 。

演化原則：微信、淘寶這樣的巨型 App，也不是一開(kāi)始就設(shè)計(jì)成這樣的架構(gòu)的，很多 App 開(kāi)始的時(shí)候可能都沒(méi)有出現(xiàn)模塊化、插件化這樣的橫向架構(gòu)設(shè)計(jì)，都是隨著功能和用戶規(guī)模不斷擴(kuò)展，架構(gòu)不斷重構(gòu)演化而來(lái)的。首先，設(shè)計(jì)出一個(gè)滿足現(xiàn)有業(yè)務(wù)的架構(gòu)，架構(gòu)要在實(shí)際應(yīng)用中不斷的優(yōu)化，保留其優(yōu)秀的部分，修改有缺陷的設(shè)計(jì)、改正錯(cuò)誤的設(shè)計(jì)、去掉無(wú)用的設(shè)計(jì)，使得架構(gòu)不斷完善。當(dāng)業(yè)務(wù)發(fā)展時(shí)，舊的架構(gòu)可以要重構(gòu)、甚至重寫(xiě)，但是有價(jià)值的經(jīng)驗(yàn)、教訓(xùn)卻會(huì)在新的架構(gòu)中體現(xiàn)。

初入這個(gè)行業(yè)的時(shí)候， 很多設(shè)計(jì)模式是看得云里霧里， 我覺(jué)得是我們搞反了順序，導(dǎo)致我們很難理解為什么用這個(gè)模式、 SOLID 設(shè)計(jì)原則有什么作用。

應(yīng)該是先有業(yè)務(wù)場(chǎng)景， 然后再有什么樣的架構(gòu)， 為了到達(dá)這個(gè)架構(gòu)的要求， 然后才是各種設(shè)計(jì)模式和設(shè)計(jì)原則的靈活選取和應(yīng)用。

例如，我們?yōu)榱俗層脩裟K和消息模塊解耦，假設(shè)用戶模塊依賴消息模塊的未讀消息數(shù)這個(gè)信息。

為了滿足橫向架構(gòu)的要求，解除模塊依賴，架構(gòu)變成：

通過(guò)這樣調(diào)整，我們不知不覺(jué)中使用了 SOLID 中的好幾個(gè)原則，例如依賴倒置原則。

跨平臺(tái)和動(dòng)態(tài)性是做 App 架構(gòu)繞不開(kāi)的一個(gè)話題。

兩類跨平臺(tái)：第一：UI 跨平臺(tái)，代表方案 WebView、Weex、RN、Flutter 等類 web 方案。

第二：C++ 跨平臺(tái)， 通常是在追求性能的某些特定場(chǎng)景， 例如音視頻編解碼處理，某些復(fù)雜的加解密算法等。也有一些團(tuán)隊(duì)由于領(lǐng)導(dǎo)班子技術(shù)棧的優(yōu)勢(shì)， 會(huì)選擇將業(yè)務(wù)甚至 UI 也是用 C++ 跨平臺(tái)，例如騰訊會(huì)議。

動(dòng)態(tài)性：代表方案 WebView，Weex ，小程序等類 web 方案和原生插件化方案。

?

關(guān)于怎么選取，我們要完美的動(dòng)態(tài)性或者跨平臺(tái)性的時(shí)候，可能就是犧牲了某些性能，例如 WebView ，在跨平臺(tái)性和動(dòng)態(tài)性都堪稱完美，但卻是可選方案中性能最差的，再比如：如果我們使用 C++ ，性能上肯定沒(méi)問(wèn)題，但是在開(kāi)發(fā)效率、團(tuán)隊(duì)人員技術(shù)要求上都要面臨巨大挑戰(zhàn)。

還有些選擇是由業(yè)務(wù)本身決定的，例如類似應(yīng)用寶這樣的應(yīng)用商店應(yīng)用，根本就不用考慮跨平臺(tái)問(wèn)題， 因?yàn)樗荒芘茉?Android 平臺(tái)， 但是它對(duì)動(dòng)態(tài)性要求非常高，作為廠商的競(jìng)爭(zhēng)對(duì)象無(wú)法在廠商應(yīng)用商店上架，所以類似插件化這樣的動(dòng)態(tài)方案就顯得非常重要。

架構(gòu)中對(duì)于動(dòng)態(tài)性和跨平臺(tái)方案的選取，這同樣是一個(gè)取舍問(wèn)題， 架構(gòu)干的活，大多數(shù)時(shí)候都是在做取舍和平衡。

架構(gòu)作為名稱描述 App 系統(tǒng)組織元素和組織關(guān)系。

架構(gòu)作為動(dòng)詞，強(qiáng)調(diào)的是架構(gòu)的整體方法論， 縱向分層架構(gòu)，橫向模塊化隔離架構(gòu)，在此之下靈活使用設(shè)計(jì)模式和設(shè)計(jì)原則實(shí)現(xiàn)架構(gòu)目標(biāo)。

架構(gòu)要適應(yīng)業(yè)務(wù)自身需求和變化， 做到三原則。