前言
用本篇文章理論知識(shí)和架構(gòu)原則實(shí)踐了一個(gè) wanAndroid 項(xiàng)目疾瓮，其中全部采用 kotlin 編寫(xiě)并拋棄了 Rxjava陷谱，因?yàn)?kotlin 可以完全替代他，github 本項(xiàng)目中匯總了業(yè)界知名的架構(gòu)文章和一些項(xiàng)目幫你徹底理解架構(gòu)。后續(xù)本項(xiàng)目將持續(xù)更新肛鹏，并完善 wanAndorid 的所有功能。還會(huì)用 23 種設(shè)計(jì)模式在項(xiàng)目中實(shí)踐恩沛，徹底理解設(shè)計(jì)模式在業(yè)務(wù)場(chǎng)景中的使用在扰，歡迎持續(xù)關(guān)注
- 項(xiàng)目地址：https://github.com/blindmonk/WanArchitecture
一、什么是架構(gòu)
1.1 架構(gòu)介紹
架構(gòu)究竟是什么雷客？如何更好的理解架構(gòu)芒珠。我們知道中國(guó)文字博大精深可以說(shuō)從文字的組成就能理解其含義。架構(gòu)也不例外 “架構(gòu)” 是由 “架” 搅裙、“構(gòu)” 組成妓局。
架：建造、搭設(shè)呈宇、支撐好爬。 簡(jiǎn)稱：整體結(jié)構(gòu)
構(gòu)：屋宇、供人居住的木甥啄、磚瓦構(gòu)筑物存炮。 簡(jiǎn)稱：組件
整體結(jié)構(gòu)和組件的組合就形成了架構(gòu)。以 Android 架構(gòu)為例子一個(gè) APP 通常是有 class（類）組成，而這些 class 之間如何如何組合穆桂、相互之間如何發(fā)生作用宫盔，則是影響這個(gè) APP 本身的關(guān)鍵點(diǎn)。細(xì)分的話可以分為類享完、接口（連接器）灼芭、任務(wù)流。所謂類就是組成架構(gòu)的核心 “磚瓦”般又，而接口則是這些類之間通訊的路徑彼绷、通訊的機(jī)制、通訊的期望結(jié)果茴迁。任務(wù)流則是描述系統(tǒng)如何使用類和接口完成某一項(xiàng)需求比如：一次網(wǎng)絡(luò)請(qǐng)求寄悯。 上面介紹架構(gòu)中提到了房屋、木頭堕义、磚瓦可見(jiàn)架構(gòu)和建筑有著彼此的聯(lián)系猜旬。
1.2 建筑學(xué)
上世紀(jì) 60 年代已經(jīng)設(shè)計(jì)軟件架構(gòu)這個(gè)概念了，到了 90 年代軟件架構(gòu)這個(gè)概念才開(kāi)始流行起來(lái)倦卖。而計(jì)算機(jī)的歷史開(kāi)始于上世紀(jì)五十年代相比建筑歷史就非常短暫了洒擦，建筑工程從石器時(shí)代就開(kāi)始了。人類在幾千年的建筑設(shè)計(jì)實(shí)踐中積累了大量的經(jīng)驗(yàn)和教訓(xùn)怕膛，建筑設(shè)計(jì)基本上包含兩點(diǎn)秘遏，一是建筑風(fēng)格，二是建筑模式嘉竟。獨(dú)特的建筑風(fēng)格和恰當(dāng)選擇的建筑模式邦危，可以使它成為一個(gè)獨(dú)一無(wú)二的建筑。
下圖的照片顯示了古代瑪雅建筑：Chichen-Itza舍扰，九個(gè)巨大的石級(jí)堆壘而上倦蚪，九十一級(jí)臺(tái)階（象征著四季的天數(shù)）奪路而出，塔頂?shù)纳竦盥柸朐铺毂咂弧Ｋ械臄?shù)字都如日歷般嚴(yán)謹(jǐn)陵且，風(fēng)格雄渾。難以想象這是石器時(shí)代的建筑物个束。
英國(guó)首相丘吉爾說(shuō)慕购，我們構(gòu)造建筑物，建筑也構(gòu)造我們茬底，英國(guó)下議院的會(huì)議廳較狹窄沪悲，無(wú)法使所有的下議院議員面向同一個(gè)方向入座，而必須分成兩側(cè)入座阱表。丘吉爾認(rèn)為殿如，議員們?nèi)胱臅r(shí)候自然會(huì)選擇與自己政見(jiàn)相同的人同時(shí)入座贡珊，而這就是英國(guó)政黨制的起源。
二涉馁、架構(gòu)設(shè)計(jì)目的
幾乎所有的軟件設(shè)計(jì)理念都可以在浩瀚的建筑學(xué)歷史中找到门岔。許多人認(rèn)為 “形式必須服從功能”（你認(rèn)同這種觀點(diǎn)嗎？歡迎在評(píng)論區(qū)留下你的看法）烤送。而好的設(shè)計(jì)既有形式又有功能寒随。比如我們的北京大興國(guó)際機(jī)場(chǎng)大興機(jī)場(chǎng)以航站樓為核心向四周延展從空中俯瞰就像是一只展翅欲飛的鳳凰，以航站樓核心區(qū)為中心帮坚，分別向東北妻往、東南、中南叶沛、西南蒲讯、西北五個(gè)方向伸出了五條指廊忘朝，通往北京大興國(guó)際機(jī)場(chǎng)的飛行區(qū)灰署。這種從中心向四面八方延伸的設(shè)計(jì)，使航站樓中心點(diǎn)到最遠(yuǎn)端登機(jī)口的距離只有 600 米左右局嘁，旅客步行前往最多只需 8 分鐘溉箕。
建筑的設(shè)計(jì)又有一定的目的性，而軟件架構(gòu)設(shè)計(jì)也同理悦昵。軟件架構(gòu)目的性大致可分為可擴(kuò)展性肴茄、可定制化、可伸縮但指、可維護(hù)性：
1. 可擴(kuò)展性： APP 必須能夠在用戶的 UV/PV 數(shù)量快速增加的情況下寡痰，保持軟件合理的性能。只有這樣在快速的從 0 到 1 的需求迭代中才能后顧無(wú)憂棋凳。
2. 可定制化： 在同一個(gè)軟件系統(tǒng)中可能面向的用戶群體是不同的拦坠、多樣的，需要滿足根據(jù)用戶群的不同和市場(chǎng)需求的不同進(jìn)行定制化剩岳。比如一個(gè) APP 中某些功能只針對(duì)特定用戶開(kāi)放贞滨。
3. 可伸縮性： 在新技術(shù)出現(xiàn)的時(shí)候，一個(gè)軟件系統(tǒng)應(yīng)當(dāng)允許接入新技術(shù)拍棕，從而對(duì)現(xiàn)有系統(tǒng)進(jìn)行功能和性能的擴(kuò)展晓铆。
4. 可維護(hù)性： 軟件系統(tǒng)的維護(hù)包括兩方面，一是修復(fù)現(xiàn)有的 bug绰播，二是將新的迭代需求開(kāi)發(fā)到現(xiàn)有系統(tǒng)中去骄噪。一個(gè)易于維護(hù)的系統(tǒng)可以有效地降低人力和物力。
三蠢箩、實(shí)踐一個(gè) APP：玩 Android
針對(duì)上面對(duì)架構(gòu)的介紹腰池，相信已經(jīng)從陌生走向熟悉了尾组。但是最重要的還是實(shí)踐，偉大的毛主席曾經(jīng)說(shuō)過(guò) 你要想知道梨子的滋味示弓，就要親口嘗一下讳侨。因此借用了 wanAndoird 開(kāi)放 API 簡(jiǎn)單實(shí)現(xiàn)一個(gè) APP 并概括上述架構(gòu)的關(guān)鍵點(diǎn)，主要的功能點(diǎn)如下：
首頁(yè)是熱搜文章的分類列表
項(xiàng)目頁(yè)面主要包括完整項(xiàng)目
文章奏属、項(xiàng)目點(diǎn)擊可以查看詳情
不知道還有沒(méi)有印象上文提到了架構(gòu) “形式必須服從功能” 當(dāng)然這不是權(quán)威的定義跨跨，可以作為參考。我們先不管是形式服從功能還是功能服從形式囱皿，可以結(jié)構(gòu)化思維理解下這句話勇婴，架構(gòu)大致可分為：形式、功能所以我們依次按照此兩點(diǎn)進(jìn)行搭建 wanAndroid 項(xiàng)目嘱腥。
3.1 架構(gòu) - 形式
從形式本身而言包括兩部分耕渴。一是事物外在的形狀，二是內(nèi)在的結(jié)構(gòu)齿兔、組合方式橱脸。實(shí)際上，這兩者為同一分苇。內(nèi)容如何內(nèi)在組合添诉，對(duì)外就自然有某種表現(xiàn)的形狀。
我們打開(kāi)項(xiàng)目的第一眼接觸到和看到的就是我們項(xiàng)目的目錄結(jié)構(gòu)医寿，更清晰更簡(jiǎn)潔的目錄結(jié)構(gòu)可以使我們更快的上手項(xiàng)目栏赴。這里主要分為兩部分核心模塊、業(yè)務(wù)功能模塊：
核心模塊主要有以下職責(zé)：
- Dagger 依賴注入處理靖秩。
- 擴(kuò)展功能：各種 utils须眷。
- 基礎(chǔ)層的抽象：BaseActivity、BaseViewModel 等
- 第三庫(kù)處理沟突、網(wǎng)絡(luò)異常處理等
業(yè)務(wù)功能模塊主要有以下好處：
- 高內(nèi)聚性
- 清晰的功能結(jié)構(gòu)
- 模塊化
- 功能隔離并封裝
在主 APP 下進(jìn)行了 core花颗、features 的劃分，業(yè)務(wù)模塊并沒(méi)有按照模塊化的形式進(jìn)行多 moudle 拆分而是聚合在 features 下事扭，以包的形式進(jìn)行了聚合捎稚，這樣做的好處如下：
- 更快的編譯速度
- 減少 maven 庫(kù)的依賴沖突
- 通用功能的重用性
- 包的內(nèi)聚力
可以看到我們并沒(méi)有采用按照業(yè)務(wù) module 進(jìn)行模塊化劃分，因?yàn)槲抑敖佑|過(guò)一個(gè)項(xiàng)目拆分了 40 多個(gè) module 可想而知項(xiàng)目一旦龐大起來(lái)壞處也就是暴露出來(lái)：
- 編譯一次項(xiàng)目高達(dá) 7/8 分鐘求橄，編譯速度優(yōu)化可以看我之前的文章（編譯速度優(yōu)化）
- 項(xiàng)目中的 moudle 依賴縱橫交錯(cuò)
當(dāng)然我并不反對(duì)多 module 模塊化的存在今野，因?yàn)槿魏文Ｊ蕉加欣斜祝@取決于當(dāng)前的項(xiàng)目的業(yè)務(wù)來(lái)抉擇使用那種形式罐农。此外項(xiàng)目中全部采用 kotlin 編寫(xiě)：
-
build.gradle.kts.kts 也是官方推崇的可以使 gradle 更加簡(jiǎn)化 -
buildSrc來(lái)處理 gradle 依賴
3.2 架構(gòu) - 功能
在玩 Android 中的業(yè)務(wù)點(diǎn)功能點(diǎn)主要有文章条霜、項(xiàng)目獲取，而這些功能點(diǎn)大部分都離不開(kāi)網(wǎng)絡(luò)請(qǐng)求和回調(diào)處理涵亏。這里不再描述 MVC宰睡、MVP蒲凶、MVVM 的區(qū)別和如何選擇，但是我可以說(shuō)明一點(diǎn)是任何架構(gòu)模式都沒(méi)有最好拆内、最優(yōu)旋圆，只有最適合當(dāng)前業(yè)務(wù)的才是好架構(gòu)。現(xiàn)在 google 官方推崇的架構(gòu)主要是 MVVM 所有我們主要說(shuō)下 MVVM麸恍。更詳細(xì)的可以查看官網(wǎng)文檔 應(yīng)用架構(gòu)指南：
MVVM 架構(gòu)模式滿足上文我們描述符合的架構(gòu)設(shè)計(jì)的目的灵巧，同時(shí)也準(zhǔn)守了官方給定的架構(gòu)原則，架構(gòu)原則大致有兩點(diǎn)如下抹沪】桃蓿可能光看這兩個(gè)定義可能不太容易理解。所有我們用結(jié)構(gòu)化思維的方式理解下融欧，關(guān)注點(diǎn)分離就是將復(fù)雜問(wèn)題做合理的分解敏弃，再研究分解的側(cè)面，最后合成整體的解決方案噪馏。因此我們?cè)?Activity 或 Fragment 不應(yīng)該做業(yè)務(wù)邏輯而是把功能點(diǎn)拆分成需要最小的最優(yōu)解麦到，最后合并成整體方案。比如 mvvm 我們衍生出 ViewModel逝薪、LiveData隅要、Model 等蝴罪。
- 關(guān)注點(diǎn)分離 Activity 或 Fragment 中的代碼應(yīng)是處理界面和操作系統(tǒng)交互的邏輯應(yīng)使這些類盡可能保持精簡(jiǎn)董济，這樣可以避免許多與生命周期相關(guān)的問(wèn)題。
- 通過(guò)模型驅(qū)動(dòng)界面 模型是負(fù)責(zé)處理應(yīng)用數(shù)據(jù)的組件要门。它們獨(dú)立于應(yīng)用中的 View 對(duì)象和應(yīng)用組件虏肾，因此不受應(yīng)用的生命周期以及相關(guān)的關(guān)注點(diǎn)的影響
MVVM 中每個(gè)組件僅依賴于其下一級(jí)的組件如：activity-->viewMoudle-->Repository。這時(shí)候你可能有疑惑欢搜，如果是單向依賴那網(wǎng)絡(luò)請(qǐng)求的回調(diào)怎么處理封豪？這里引出一個(gè)概念 “響應(yīng)式編程” 結(jié)合 liveData 做處理其內(nèi)部是觀察者模式，并且關(guān)聯(lián)視圖的聲明周期如：Activity炒瘟、Fragment 或 Service吹埠。使用 LiveData 的好處如下：
- 不會(huì)發(fā)生內(nèi)存泄漏 觀察者會(huì)綁定到 Lifecycle 對(duì)象，并在其關(guān)聯(lián)的生命周期遭到銷毀后進(jìn)行自我清理疮装。
- 不會(huì)因 Activity 停止而導(dǎo)致崩潰 如果觀察者的生命周期處于非活躍狀態(tài)（如返回棧中的 Activity）缘琅，則它不會(huì)接收任何 LiveData 事件。
- 不再需要手動(dòng)處理生命周期 界面組件只是觀察相關(guān)數(shù)據(jù)廓推，不會(huì)停止或恢復(fù)觀察刷袍。LiveData 將自動(dòng)管理所有這些操作，因?yàn)樗谟^察時(shí)可以感知相關(guān)的生命周期狀態(tài)變化樊展。
3.3 UseCase
UseCase 是 Clean 架構(gòu)中的一個(gè)概念呻纹，其中主要用于 UI 和數(shù)據(jù)層的連接同時(shí)也會(huì)進(jìn)行 IO 的切換堆生，這里可以看到本項(xiàng)目拋棄了 Rxjava 因?yàn)樗耆梢杂?Kotlin 來(lái)替代。
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 一個(gè)完整網(wǎng)絡(luò)請(qǐng)求流程
</br>
- View：一個(gè)網(wǎng)絡(luò)請(qǐng)求的發(fā)送并訂閱雷酪，處理 UI 數(shù)據(jù)淑仆。
- ViewModel：為 View(Activity/Fragment) 提供數(shù)據(jù)，并處理業(yè)務(wù)邏輯哥力。
- LiveData：具有生命周期可觀察的數(shù)據(jù)存儲(chǔ)器類糯景，LiveData 存儲(chǔ)在 ViewModel 中
- UseCases：用于連接 ViewModel 和 Model，并更新 LiveData省骂。
- Model：可以從網(wǎng)絡(luò)蟀淮、數(shù)據(jù)庫(kù)或其他 API 獲取數(shù)據(jù)
四、總結(jié)
我們可以體會(huì)到從架構(gòu)理論定義到實(shí)踐的過(guò)程相信你有了自己的理解和見(jiàn)解钞澳，但這只是一種實(shí)現(xiàn)方式怠惶，如果在滿足架構(gòu)設(shè)計(jì)目的和架構(gòu)原則的情況下你有更好的實(shí)踐方式或者有任何和架構(gòu)項(xiàng)目的疑問(wèn)點(diǎn)都可迎在評(píng)論區(qū)或者 Github 中留言討論。這里我也有個(gè)疑問(wèn)點(diǎn)就你認(rèn)同形式必需服從功能轧粟？歡迎留下你的見(jiàn)解策治。
后續(xù)本項(xiàng)目將持續(xù)更新，并完善 wanAndorid 的所有功能兰吟。還會(huì)用 23 種設(shè)計(jì)模式在項(xiàng)目中實(shí)踐通惫，徹底理解設(shè)計(jì)模式在業(yè)務(wù)場(chǎng)景中的使用，歡迎持續(xù)關(guān)注混蔼。當(dāng)其他的平臺(tái)如后端履腋、前端架構(gòu)的搭建都是殊途同歸的。但是我還是有幾點(diǎn)建議：
- 業(yè)務(wù)決定架構(gòu)
- 不要過(guò)度設(shè)計(jì)
- 面向接口編程
- 形式需服從功能
參考文獻(xiàn)： 應(yīng)用架構(gòu)指南惭嚣、CleanArchitecture遵湖、 LiveData 概覽、
