成爲架構師幾乎是所有開發人員的終極夢想，或者說是崇拜對象，但是成爲架構師並不容易，至少，就我們Android開發人員來說，Android 架構是我們必須弄明白的。
今天就分享一波大佬關於“架構”的解讀，帶大家徹底理解一下 Android 架構，希望對大家的學習工作有所啓發和幫助~
原文地址：https://juejin.cn/post/6960953981543645214
前言
匯聚了業界知名架構文章。從建築學的知識中得到一些對架構的思考，並以架構設計原則和目的對Jetpack MVVM 重新構造！github 後續本項目將持續更新，並完善 wanAndorid 的所有功能。還會用 23 種設計模式在項目中實踐，徹底理解設計模式在業務場景中的使用，歡迎關注
- Github：github.com/blindmonk/W…
一、什麼是架構
1.1 架構介紹
架構究竟是什麼？如何更好的理解架構。我們知道中國文字博大精深可以說從文字的組成就能理解其含義。架構也不例外 “架構” 是由 “架” 、“構” 組成。
架：建造、搭設、支撐。 簡稱：整體結構
構：屋宇、供人居住的木、磚瓦構築物。 簡稱：組件
整體結構和組件的組合就形成了架構。以 Android 架構爲例子一個 APP 通常是有 class（類）組成，而這些 class 之間如何如何組合、相互之間如何發生作用，則是影響這個 APP 本身的關鍵點。細分的話可以分爲類、接口（連接器）、任務流。所謂類就是組成架構的核心 “磚瓦”，而接口則是這些類之間通訊的路徑、通訊的機制、通訊的期望結果。任務流則是描述系統如何使用類和接口完成某一項需求比如：一次網絡請求。 上面介紹架構中提到了房屋、木頭、磚瓦可見架構和建築有着彼此的聯繫。
1.2 建築學
上世紀 60 年代已經設計軟件架構這個概念了，到了 90 年代軟件架構這個概念纔開始流行起來。而計算機的歷史開始於上世紀五十年代相比建築歷史就非常短暫了，建築工程從石器時代就開始了。人類在幾千年的建築設計實踐中積累了大量的經驗和教訓，建築設計基本上包含兩點，一是建築風格，二是建築模式。獨特的建築風格和恰當選擇的建築模式，可以使它成爲一個獨一無二的建築。
下圖的照片顯示了古代瑪雅建築：Chichen-Itza，九個巨大的石級堆壘而上，九十一級臺階（象徵着四季的天數）奪路而出，塔頂的神殿聳入雲天。所有的數字都如日曆般嚴謹，風格雄渾。難以想象這是石器時代的建築物。
英國首相丘吉爾說，我們構造建築物，建築也構造我們，英國下議院的會議廳較狹窄，無法使所有的下議院議員面向同一個方向入座，而必須分成兩側入座。丘吉爾認爲，議員們入座的時候自然會選擇與自己政見相同的人同時入座，而這就是英國政黨制的起源。
二、架構設計目的
幾乎所有的軟件設計理念都可以在浩瀚的建築學歷史中找到。許多人認爲 “形式必須服從功能”（你認同這種觀點嗎？歡迎在評論區留下你的看法）。而好的設計既有形式又有功能。比如我們的北京大興國際機場大興機場以航站樓爲核心向四周延展從空中俯瞰就像是一隻展翅欲飛的鳳凰，以航站樓核心區爲中心，分別向東北、東南、中南、西南、西北五個方向伸出了五條指廊，通往北京大興國際機場的飛行區。這種從中心向四面八方延伸的設計，使航站樓中心點到最遠端登機口的距離只有 600 米左右，旅客步行前往最多隻需 8 分鐘。
建築的設計又有一定的目的性，而軟件架構設計也同理。軟件架構目的性大致可分爲可擴展性、可定製化、可伸縮、可維護性：
1. 可擴展性： APP 必須能夠在用戶的 UV/PV 數量快速增加的情況下，保持軟件合理的性能。只有這樣在快速的從 0 到 1 的需求迭代中才能後顧無憂。
2. 可定製化： 在同一個軟件系統中可能面向的用戶羣體是不同的、多樣的，需要滿足根據用戶羣的不同和市場需求的不同進行定製化。比如一個 APP 中某些功能只針對特定用戶開放。
3. 可伸縮性： 在新技術出現的時候，一個軟件系統應當允許接入新技術，從而對現有系統進行功能和性能的擴展。
4. 可維護性： 軟件系統的維護包括兩方面，一是修復現有的 bug，二是將新的迭代需求開發到現有系統中去。一個易於維護的系統可以有效地降低人力和物力。
三、實踐一個 APP：玩 Android
針對上面對架構的介紹，相信已經從陌生走向熟悉了。但是最重要的還是實踐，偉大的毛主席曾經說過 你要想知道梨子的滋味，就要親口嘗一下。因此借用了 wanAndoird 開放 API 簡單實現一個 APP 並概括上述架構的關鍵點，主要的功能點如下：
首頁是熱搜文章的分類列表
項目頁面主要包括完整項目
文章、項目點擊可以查看詳情
不知道還有沒有印象上文提到了架構 “形式必須服從功能” 當然這不是權威的定義，可以作爲參考。我們先不管是形式服從功能還是功能服從形式，可以結構化思維理解下這句話，架構大致可分爲：形式、功能所以我們依次按照此兩點進行搭建 wanAndroid 項目。
3.1 架構 - 形式
從形式本身而言包括兩部分。一是事物外在的形狀，二是內在的結構、組合方式。實際上，這兩者爲同一。內容如何內在組合，對外就自然有某種表現的形狀。
我們打開項目的第一眼接觸到和看到的就是我們項目的目錄結構，更清晰更簡潔的目錄結構可以使我們更快的上手項目。這裏主要分爲兩部分核心模塊、業務功能模塊：
核心模塊主要有以下職責：
- Dagger 依賴注入處理。
- 擴展功能：各種 utils。
- 基礎層的抽象：BaseActivity、BaseViewModel 等
- 第三庫處理、網絡異常處理等
業務功能模塊主要有以下好處：
- 高內聚性
- 清晰的功能結構
- 模塊化
- 功能隔離並封裝
在主 APP 下進行了 core、features 的劃分，業務模塊並沒有按照模塊化的形式進行多 moudle 拆分而是聚合在 features 下，以包的形式進行了聚合，這樣做的好處如下：
- 更快的編譯速度
- 減少 maven 庫的依賴衝突
- 通用功能的重用性
- 包的內聚力
可以看到我們並沒有採用按照業務 module 進行模塊化劃分，因爲我之前接觸過一個項目拆分了 40 多個 module 可想而知項目一旦龐大起來壞處也就是暴露出來：
- 編譯一次項目高達 7/8 分鐘，編譯速度優化可以看我之前的文章（編譯速度優化）
- 項目中的 moudle 依賴縱橫交錯
當然我並不反對多 module 模塊化的存在，因爲任何模式都有利有弊，這取決於當前的項目的業務來抉擇使用那種形式。此外項目中全部採用 kotlin 編寫：
-
build.gradle.kts.kts 也是官方推崇的可以使 gradle 更加簡化 -
buildSrc來處理 gradle 依賴
3.2 架構 - 功能
在玩 Android 中的業務點功能點主要有文章、項目獲取，而這些功能點大部分都離不開網絡請求和回調處理。這裏不再描述 MVC、MVP、MVVM 的區別和如何選擇，但是我可以說明一點是任何架構模式都沒有最好、最優，只有最適合當前業務的纔是好架構。現在 google 官方推崇的架構主要是 MVVM 所有我們主要說下 MVVM。更詳細的可以查看官網文檔 應用架構指南：
MVVM 架構模式滿足上文我們描述符合的架構設計的目的，同時也準守了官方給定的架構原則，架構原則大致有兩點如下。可能光看這兩個定義可能不太容易理解。所有我們用結構化思維的方式理解下，關注點分離就是將複雜問題做合理的分解，再研究分解的側面，最後合成整體的解決方案。因此我們在 Activity 或 Fragment 不應該做業務邏輯而是把功能點拆分成需要最小的最優解，最後合併成整體方案。比如 mvvm 我們衍生出 ViewModel、LiveData、Model 等。
- 關注點分離 Activity 或 Fragment 中的代碼應是處理界面和操作系統交互的邏輯應使這些類儘可能保持精簡，這樣可以避免許多與生命週期相關的問題。
- 通過模型驅動界面 模型是負責處理應用數據的組件。它們獨立於應用中的 View 對象和應用組件，因此不受應用的生命週期以及相關的關注點的影響
MVVM 中每個組件僅依賴於其下一級的組件如：activity-->viewMoudle-->Repository。這時候你可能有疑惑，如果是單向依賴那網絡請求的回調怎麼處理？這裏引出一個概念 “響應式編程” 結合 liveData 做處理其內部是觀察者模式，並且關聯視圖的聲明週期如：Activity、Fragment 或 Service。使用 LiveData 的好處如下：
- 不會發生內存泄漏 觀察者會綁定到 Lifecycle 對象，並在其關聯的生命週期遭到銷燬後進行自我清理。
- 不會因 Activity 停止而導致崩潰 如果觀察者的生命週期處於非活躍狀態（如返回棧中的 Activity），則它不會接收任何 LiveData 事件。
- 不再需要手動處理生命週期 界面組件只是觀察相關數據，不會停止或恢復觀察。LiveData 將自動管理所有這些操作，因爲它在觀察時可以感知相關的生命週期狀態變化。
3.3 UseCase
UseCase 是 Clean 架構中的一個概念，其中主要用於 UI 和數據層的連接同時也會進行 IO 的切換，這裏可以看到本項目拋棄了 Rxjava 因爲他完全可以用 Kotlin 來替代。
abstract class UseCase<out Type, in Params> where Type : Any {
abstract suspend fun run(params: Params): Either<Failure, Type>{
operator fun invoke(params: Params, onResult: (Either<Failure, Type>) -> Unit = {}) {
val job = GlobalScope.async(Dispatchers.IO) { run(params) }
GlobalScope.launch(Dispatchers.Main) { onResult(job.await()) }
}
class None
}
3.4 一個完整網絡請求流程
- View：一個網絡請求的發送並訂閱，處理 UI 數據。
- ViewModel：爲 View(Activity/Fragment) 提供數據，並處理業務邏輯。
- LiveData：具有生命週期可觀察的數據存儲器類，LiveData 存儲在 ViewModel 中
- UseCases：用於連接 ViewModel 和 Model，並更新 LiveData。
- Model：可以從網絡、數據庫或其他 API 獲取數據
四、總結
我們可以體會到從架構理論定義到實踐的過程相信你有了自己的理解和見解，但這只是一種實現方式，如果在滿足架構設計目的和架構原則的情況下你有更好的實踐方式或者有任何和架構項目的疑問點都可迎在評論區或者 Github 中留言討論。這裏我也有個疑問點就你認同形式必需服從功能？歡迎留下你的見解。
後續本項目將持續更新，並完善 wanAndorid 的所有功能。還會用 23 種設計模式在項目中實踐，徹底理解設計模式在業務場景中的使用，歡迎持續關注。當其他的平臺如後端、前端架構的搭建都是殊途同歸的。但是我還是有幾點建議：
- 業務決定架構
- 不要過度設計
- 面向接口編程
- 形式需服從功能
參考文獻： 應用架構指南、CleanArchitecture、 LiveData 概覽
五、推薦學習
B站視頻系列：