前言
--
用本篇文章理論知識和架構(gòu)原則實踐了一個 wanAndroid 項目，其中全部采用 kotlin 編寫并拋棄了 Rxjava型诚，因為 kotlin 可以完全替代他鸳劳，[github](https://github.com/blindmonk/WanArchitecture) 本項目中匯總了業(yè)界知名的架構(gòu)文章和一些項目幫你徹底理解架構(gòu)也搓。后續(xù)本項目將持續(xù)更新，并完善 wanAndorid 的所有功能傍妒。還會用 23 種設(shè)計模式在項目中實踐，徹底理解設(shè)計模式在業(yè)務(wù)場景中的使用既忆，歡迎持續(xù)關(guān)注 **[github](https://github.com/blindmonk/WanArchitecture)**
一、什么是架構(gòu)
-------
### 1.1 架構(gòu)介紹
架構(gòu)究竟是什么患雇？如何更好的理解架構(gòu)。我們知道中國文字博大精深可以說從文字的組成就能理解其含義酪术。架構(gòu)也不例外 “架構(gòu)” 是由 **“架”** 翠储、**“構(gòu)”** 組成。
> 架：建造援所、搭設(shè)、支撐挪略。 簡稱：整體結(jié)構(gòu)?
> 構(gòu)：屋宇废酷、供人居住的木瘟檩、磚瓦構(gòu)筑物澈蟆。 簡稱：組件
整體結(jié)構(gòu)和組件的組合就形成了架構(gòu)。以 Android 架構(gòu)為例子一個 APP 通常是有 class（類）組成睹簇，而這些 class 之間如何如何組合寥闪、相互之間如何發(fā)生作用，則是影響這個 APP 本身的關(guān)鍵點疲憋。細分的話可以分為**類、接口（連接器）埃脏、任務(wù)流**秋忙。所謂類就是組成架構(gòu)的核心 “磚瓦”，而接口則是這些類之間通訊的路徑灰追、通訊的機制狗超、通訊的期望結(jié)果朴下。任務(wù)流則是描述系統(tǒng)如何使用類和接口完成某一項需求**比如：一次網(wǎng)絡(luò)請求。** 上面介紹架構(gòu)中提到了房屋麦撵、木頭溃肪、磚瓦可見架構(gòu)和建筑有著彼此的聯(lián)系。
### 1.2 建筑學(xué)
上世紀 60 年代已經(jīng)設(shè)計軟件架構(gòu)這個概念了惫撰，到了 90 年代軟件架構(gòu)這個概念才開始流行起來。而計算機的歷史開始于上世紀五十年代相比建筑歷史就非常短暫了扼雏，建筑工程從石器時代就開始了夯膀。人類在幾千年的建筑設(shè)計實踐中積累了大量的經(jīng)驗和教訓(xùn)，建筑設(shè)計基本上包含兩點诱建，一是建筑風格，二是建筑模式俺猿。獨特的建筑風格和恰當選擇的建筑模式，可以使它成為一個獨一無二的建筑诵冒。
下圖的照片顯示了古代瑪雅建筑：Chichen-Itza谊惭，九個巨大的石級堆壘而上，九十一級臺階（象征著四季的天數(shù)）奪路而出圈盔，塔頂?shù)纳竦盥柸朐铺臁Ｋ械臄?shù)字都如日歷般嚴謹，風格雄渾癌佩。難以想象這是石器時代的建筑物木缝。
英國首相丘吉爾說围辙，我們構(gòu)造建筑物，建筑也構(gòu)造我們矫俺，英國下議院的會議廳較狹窄掸冤，無法使所有的下議院議員面向同一個方向入座，而必須分成兩側(cè)入座稿湿。丘吉爾認為，議員們?nèi)胱臅r候自然會選擇與自己政見相同的人同時入座包斑，而這就是英國政黨制的起源涕俗。
二、架構(gòu)設(shè)計目的
--------
幾乎所有的軟件設(shè)計理念都可以在浩瀚的建筑學(xué)歷史中找到再姑。許多人認為 **“形式必須服從功能”**（你認同這種觀點嗎询刹？歡迎在評論區(qū)留下你的看法）。而好的設(shè)計既有形式又有功能凹联。比如我們的北京大興國際機場大興機場以航站樓為核心向四周延展從空中俯瞰就像是一只展翅欲飛的鳳凰，以航站樓核心區(qū)為中心蔽挠，分別向東北、東南比原、中南杠巡、西南、西北五個方向伸出了五條指廊蚌铜，通往北京大興國際機場的飛行區(qū)。這種從中心向四面八方延伸的設(shè)計冬殃，使航站樓中心點到最遠端登機口的距離只有 600 米左右，旅客步行前往最多只需 8 分鐘审葬。
建筑的設(shè)計又有一定的目的性，而軟件架構(gòu)設(shè)計也同理痴荐。軟件架構(gòu)目的性大致可分為可擴展性旨枯、可定制化蹬昌、可伸縮攀隔、可維護性：
**1. 可擴展性：** APP 必須能夠在用戶的 UV/PV 數(shù)量快速增加的情況下，保持軟件合理的性能明刷。只有這樣在快速的從 0 到 1 的需求迭代中才能后顧無憂满粗。
**2. 可定制化：** 在同一個軟件系統(tǒng)中可能面向的用戶群體是不同的、多樣的挤聘，需要滿足根據(jù)用戶群的不同和市場需求的不同進行定制化捅彻。比如一個 APP 中某些功能只針對特定用戶開放。
**3. 可伸縮性：** 在新技術(shù)出現(xiàn)的時候步淹，一個軟件系統(tǒng)應(yīng)當允許接入新技術(shù)，從而對現(xiàn)有系統(tǒng)進行功能和性能的擴展缭裆。
**4. 可維護性：** 軟件系統(tǒng)的維護包括兩方面，一是修復(fù)現(xiàn)有的 bug辛燥，二是將新的迭代需求開發(fā)到現(xiàn)有系統(tǒng)中去。一個易于維護的系統(tǒng)可以有效地降低人力和物力畅铭。
三勃蜘、實踐一個 APP：玩 Android
--------------------
針對上面對架構(gòu)的介紹假残，相信已經(jīng)從陌生走向熟悉了。但是最重要的還是實踐辉懒，偉大的毛主席曾經(jīng)說過 **你要想知道梨子的滋味，就要親口嘗一下**眶俩。因此借用了 wanAndoird 開放 API 簡單實現(xiàn)一個 APP 并概括上述架構(gòu)的關(guān)鍵點，主要的功能點如下：
*? 首頁是熱搜文章的分類列表
*? 項目頁面主要包括完整項目
*? 文章纲岭、項目點擊可以查看詳情
不知道還有沒有印象上文提到了架構(gòu) **“形式必須服從功能”** 當然這不是權(quán)威的定義线罕，可以作為參考。我們先不管是形式服從功能還是功能服從形式喇闸，可以結(jié)構(gòu)化思維理解下這句話询件，架構(gòu)大致可分為：**形式、功能**所以我們依次按照此兩點進行搭建 wanAndroid 項目宛琅。
### 3.1 架構(gòu) - 形式
從形式本身而言包括兩部分。一是事物外在的形狀座咆，二是內(nèi)在的結(jié)構(gòu)仓洼、組合方式。實際上色建，這兩者為同一。內(nèi)容如何內(nèi)在組合某残，對外就自然有某種表現(xiàn)的形狀。
我們打開項目的第一眼接觸到和看到的就是我們項目的目錄結(jié)構(gòu)玻墅，更清晰更簡潔的目錄結(jié)構(gòu)可以使我們更快的上手項目。這里主要分為兩部分核心模塊澳厢、業(yè)務(wù)功能模塊：
核心模塊主要有以下職責：
*? **Dagger 依賴注入處理。**
*? **擴展功能：各種 utils线得。**
*? **基礎(chǔ)層的抽象：BaseActivity徐伐、BaseViewModel 等**
*? **第三庫處理、網(wǎng)絡(luò)異常處理等**
業(yè)務(wù)功能模塊主要有以下好處：
*? **高內(nèi)聚性**
*? **清晰的功能結(jié)構(gòu)**
*? **模塊化**
*? **功能隔離并封裝**
在主 APP 下進行了 core办素、features 的劃分，業(yè)務(wù)模塊并沒有按照模塊化的形式進行多 moudle 拆分而是聚合在 features 下谓罗，以包的形式進行了聚合季二，這樣做的好處如下：
*? **更快的編譯速度**
*? **減少 maven 庫的依賴沖突**
*? **通用功能的重用性**
*? **包的內(nèi)聚力**
可以看到我們并沒有采用按照業(yè)務(wù) module 進行模塊化劃分，因為我之前接觸過一個項目拆分了 40 多個 module 可想而知項目一旦龐大起來壞處也就是暴露出來：
*? 編譯一次項目高達 7/8 分鐘刻蚯，編譯速度優(yōu)化可以看我之前的文章[（編譯速度優(yōu)化）](https://juejin.cn/post/6924918885259378702)
*? 項目中的 moudle 依賴縱橫交錯
當然我并不反對多 module 模塊化的存在，因為任何模式都有利有弊桑嘶，這取決于當前的項目的業(yè)務(wù)來抉擇使用那種形式炊汹。此外項目中全部采用 kotlin 編寫：
*? `build.gradle.kts` **.kts** 也是官方推崇的可以使 gradle 更加簡化
*? `buildSrc`來處理 gradle 依賴
### 3.2 架構(gòu) - 功能
在玩 Android 中的業(yè)務(wù)點功能點主要有文章、項目獲取逃顶，而這些功能點大部分都離不開網(wǎng)絡(luò)請求和回調(diào)處理讨便。這里不再描述 MVC、MVP以政、MVVM 的區(qū)別和如何選擇霸褒，但是我可以說明一點是**任何架構(gòu)模式都沒有最好、最優(yōu)盈蛮，只有最適合當前業(yè)務(wù)的才是好架構(gòu)**》狭猓現(xiàn)在 google 官方推崇的架構(gòu)主要是 MVVM 所有我們主要說下 MVVM。更詳細的可以查看官網(wǎng)文檔 [應(yīng)用架構(gòu)指南](https://developer.android.com/jetpack/guide?hl=zh-cn)：
MVVM 架構(gòu)模式滿足上文我們描述符合的架構(gòu)設(shè)計的目的，同時也準守了官方給定的架構(gòu)原則殊轴，架構(gòu)原則大致有兩點如下衰倦。可能光看這兩個定義可能不太容易理解樊零。所有我們用結(jié)構(gòu)化思維的方式理解下，關(guān)注點分離就是將復(fù)雜問題做合理的分解孽文，再研究分解的側(cè)面淹接，最后合成整體的解決方案。因此我們在 Activity 或 Fragment 不應(yīng)該做業(yè)務(wù)邏輯而是把功能點拆分成需要最小的最優(yōu)解叛溢，最后合并成整體方案。比如 mvvm 我們衍生出 ViewModel劲适、LiveData楷掉、Model 等。
1.? **關(guān)注點分離** Activity 或 Fragment 中的代碼應(yīng)是處理界面和操作系統(tǒng)交互的邏輯應(yīng)使這些類盡可能保持精簡霞势，這樣可以避免許多與生命周期相關(guān)的問題烹植。
2.? **通過模型驅(qū)動界面** 模型是負責處理應(yīng)用數(shù)據(jù)的組件。它們獨立于應(yīng)用中的 View 對象和應(yīng)用組件愕贡，因此不受應(yīng)用的生命周期以及相關(guān)的關(guān)注點的影響
MVVM 中每個組件僅依賴于其下一級的組件如：activity-->viewMoudle-->Repository草雕。這時候你可能有疑惑，如果是單向依賴那網(wǎng)絡(luò)請求的回調(diào)怎么處理固以？這里引出一個概念 **“響應(yīng)式編程”** 結(jié)合 liveData 做處理其內(nèi)部是觀察者模式墩虹，并且關(guān)聯(lián)視圖的聲明周期如：Activity、Fragment 或 Service憨琳。使用 LiveData 的好處如下：
1.? **不會發(fā)生內(nèi)存泄漏** 觀察者會綁定到 Lifecycle 對象诫钓，并在其關(guān)聯(lián)的生命周期遭到銷毀后進行自我清理。
2.? **不會因 Activity 停止而導(dǎo)致崩潰** 如果觀察者的生命周期處于非活躍狀態(tài)（如返回棧中的 Activity）篙螟，則它不會接收任何 LiveData 事件菌湃。
3.? **不再需要手動處理生命周期** 界面組件只是觀察相關(guān)數(shù)據(jù)，不會停止或恢復(fù)觀察遍略。LiveData 將自動管理所有這些操作惧所，因為它在觀察時可以感知相關(guān)的生命周期狀態(tài)變化。
### 3.3 UseCase
UseCase 是 Clean 架構(gòu)中的一個概念绪杏，其中主要用于 UI 和數(shù)據(jù)層的連接同時也會進行 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
}
復(fù)制代碼
```
### 3.4 一個完整網(wǎng)絡(luò)請求流程
</br>
*? **View**：一個網(wǎng)絡(luò)請求的發(fā)送并訂閱蕾久，處理 UI 數(shù)據(jù)驰唬。
*? **ViewModel**：為 View(Activity/Fragment) 提供數(shù)據(jù)蜘欲，并處理業(yè)務(wù)邏輯昔逗。
*? **LiveData**：具有生命周期可觀察的數(shù)據(jù)存儲器類，LiveData 存儲在 ViewModel 中
*? **UseCases**：用于連接 ViewModel 和 Model，并更新 LiveData娇钱。
*? **Model**：可以從網(wǎng)絡(luò)、數(shù)據(jù)庫或其他 API 獲取數(shù)據(jù)
四旁钧、總結(jié)
----
我們可以體會到從架構(gòu)理論定義到實踐的過程相信你有了自己的理解和見解骗露，但這只是一種實現(xiàn)方式，如果在滿足架構(gòu)設(shè)計目的和架構(gòu)原則的情況下你有更好的實踐方式或者有任何和架構(gòu)項目的疑問點都可迎在評論區(qū)或者 [Github 中**留言討論**](https://github.com/blindmonk/WanArchitecture)霞篡。這里我也有個疑問點就**你認同形式必需服從功能**世蔗？歡迎留下你的見解。
后續(xù)本項目將持續(xù)更新朗兵，并完善 wanAndorid 的所有功能污淋。還會用 **23 種設(shè)計模式在項目中實踐**，徹底理解設(shè)計模式在業(yè)務(wù)場景中的使用余掖，歡迎持續(xù)關(guān)注寸爆。當其他的平臺如后端、前端架構(gòu)的搭建都是殊途同歸的盐欺。但是我還是有幾點建議：
*? **業(yè)務(wù)決定架構(gòu)**
*? **不要過度設(shè)計**
*? **面向接口編程**
*? **形式需服從功能**
參考文獻： [應(yīng)用架構(gòu)指南](https://developer.android.com/jetpack/guide?hl=zh-cn#common-principles)赁豆、[CleanArchitecture](https://fernandocejas.com/blog/engineering/2014-09-03-architecting-android-the-clean-way/)、 [LiveData 概覽](https://developer.android.com/jetpack/guide?hl=zh-cn#common-principles)冗美、
