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

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

系統(tǒng)：當“架構”做名詞的時候， 可以簡單的把系統(tǒng)同等預架構， 可以說一個 App 的系統(tǒng)架構。

模塊：系統(tǒng)不能描述架構的內(nèi)部細節(jié)， 需要劃分為各個模塊， 例如 xxApp 的架構：

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

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

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

以上從架構的名詞層面對齊了架構組成元素的概念。“架構”作為動詞的時候，我們討論的是架構的一些方法論。

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

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

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

最基本的分層架構通常包含以下三層：

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

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

數(shù)據(jù)訪問層(Data Access Layer)：負責與數(shù)據(jù)源進行交互，包括本地數(shù)據(jù)存儲(如 SQLite、Core Data)和網(wǎng)絡請求，提供數(shù)據(jù)的 CRUD(創(chuàng)建、讀取、更新、刪除)操作。

一定規(guī)模的 App 通常還會繼續(xù)分層，例如可以擴展出基礎層出來。

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

檢驗標準：是否成功做到了分層， 檢驗的標準就是是否真正給 App 帶來了前面提到的分層的好處，例如：要替換其中一層里的核心能力，是否可以低成本就替換， 當某一層修改的時候， 是否可以單獨的對該層進行單元測試。

隨著 App 功能規(guī)模、團隊規(guī)模不斷擴大， 這時候可能需要層業(yè)務模塊角度關注架構設計，目的是降低功能規(guī)模增加而帶來的復雜度爆炸增長，橫向架構強調(diào)的是業(yè)務模塊之間的橫向解耦，從而降低復雜度。

圖中4個模塊都存在著依賴關系， 那么復雜度計算為 24：復雜度=4x3x2x1

如果我們通過某種手段進行解耦（例如通過增加一個 api 服務層隔離）：

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

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

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

檢驗標準：橫向架構是否成功， 檢驗的標準是，如果這個模塊給獨立小組開發(fā)，是否可以獨立開發(fā)、編譯、調(diào)試。

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

詳細可以參考：

《架構設計三原則https://time.geekbang.org/column/article/7071》

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

簡單原則：所有在做架構時，在有復雜方案和簡單方案都可以滿足當前業(yè)務是，盡量選擇簡單方案 。

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

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

應該是先有業(yè)務場景， 然后再有什么樣的架構， 為了到達這個架構的要求， 然后才是各種設計模式和設計原則的靈活選取和應用。

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

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

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

跨平臺和動態(tài)性是做 App 架構繞不開的一個話題。

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

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

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

?

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

還有些選擇是由業(yè)務本身決定的，例如類似應用寶這樣的應用商店應用，根本就不用考慮跨平臺問題， 因為它只能跑在 Android 平臺， 但是它對動態(tài)性要求非常高，作為廠商的競爭對象無法在廠商應用商店上架，所以類似插件化這樣的動態(tài)方案就顯得非常重要。

架構中對于動態(tài)性和跨平臺方案的選取，這同樣是一個取舍問題， 架構干的活，大多數(shù)時候都是在做取舍和平衡。

架構作為名稱描述 App 系統(tǒng)組織元素和組織關系。

架構作為動詞，強調(diào)的是架構的整體方法論， 縱向分層架構，橫向模塊化隔離架構，在此之下靈活使用設計模式和設計原則實現(xiàn)架構目標。

架構要適應業(yè)務自身需求和變化， 做到三原則。