基本解耦方案

組件化的第一步就是對要拆出去的組件進行解耦，常見解耦方式有以下幾種：

(1) 公用代碼處理

1. 基礎業(yè)務邏輯分別拆成基礎組件

2. 自身邏輯完整、用于完成某一特定功能、不含業(yè)務邏輯的一組代碼，獨立成 SDK

3. 代碼量很小不足以拆分成單獨拆分的代碼和資源，我們統一放在一個專門建立的 common 組件中，并且嚴格限制 common 組件的增長。隨著組件化的逐漸進行，common 應該逐漸變小而不是增大。

4. 碰巧被共同使用的一些代碼和資源片段，通常它們被復用只是因為被開發(fā)人員搜索到而直接使用了，很多時候某個資源已經被 A 業(yè)務聲明了前綴，但是由于沒有隔離，仍然會不可避免的被他人在 B 業(yè)務中強行復用，這時候如果 A 業(yè)務方要進行一些修改，B 業(yè)務就會受到影響 —— 這種情況我們允許直接復制

(2) 初始化

有些組件有在應用啟動時初始化服務的需求，而且很多服務還是有依賴關系的，最初我們?yōu)槊總€組件都添加了一個 init() 方法，但是并不能解決依賴順序問題，需要每個組件都在 app 工程中按順序添加初始化代碼才能正常運行，這使得不熟悉整套組件業(yè)務的人很難建立起一個可以獨立運行的組件 app。因此我們開發(fā)了一套多線程初始化框架，每個組件只要新建若干個啟動 Task 類，并在 Task 中聲明依賴關系即可：

App 只需知道自己依賴什么組件即可，在編譯 app 時 gradle 插件會自動定位到所有的 Task，并運行時生成依賴圖，按依賴順序啟動 Task：

這樣就解決了組件在主工程中堆積初始化代碼的問題，在簡化了代碼的同時還有加快啟動速度的功效。

(3) 路由

界面間使用 Url 進行跳轉，不但實現了解耦，也統一了各端的頁面打開方式。我們實現了一套靈活小巧的路由框架 ZRouter，它支持多組件、路由攔截、AB Test 、參數正則匹配、降級策略、任意參數傳遞以及自定義跳轉等功能，可以自定義路由的各個階段，完全滿足了我們的業(yè)務需求。

(4) 接口

除了頁面間的跳轉，不同業(yè)務之間不可避免的會有一些調用，為了避免組件的直接通信，通常都是使用接口依賴的方式。我們實現了一個 Interface Provider 來支持接口通信，它可以通過運行時在動態(tài)注冊一個接口，同時也實現了對于 ServiceLoader 的支持。只要一方組件將通信接口暴露出來，使用方就可以直接使用接口進行調用。

動態(tài)注冊接口

Provider.register(AbcInterface.class，new AbcInterfaceImpl())

獲取實例并調用

Provider.get(AbcInterface.class).doSomething()

(5) EventBus

這個自不必說，雖然說濫用是一個問題，但是有些場景下，使用事件還是最為方便簡單的方式

(6) 組件 API 模塊

上面提到的接口和事件以及一些跨組件使用的 Model 放到哪里好呢？如果直接將這些類下沉到一個公共組件中，由于業(yè)務的頻繁更新，這個公共組件可能會更新得十分頻繁，開發(fā)也十分的不方便，所以使用公共組件是行不通的，于是我們采取了另一種方式——組件 API ：為每個有對外暴露需求的組件添加一個 API 模塊，API 模塊中只包含對外暴露的 Model 和組件通信用的 Interface 與 Event。有需要引用這些類的組件只要依賴 API 即可。

[圖片上傳中…(image-a39cd0-1598345691997-6)]

一個典型的組件工程結構是這個樣子：

以上圖為例，它包含三個模塊：

template ：組件代碼，它包含了這個組件所有業(yè)務代碼

template-api：組件的接口模塊，專門用于與其他組件通信，只包含 Model、Interface 和 Event，不存在任何業(yè)務和邏輯代碼

app 模塊：用于獨立運行 app，它直接依賴組件模塊，只要添加一些簡單的配置，即可實現組件獨立運行。

組件半自動拆分

有了解耦的方法，剩下的就是采取行動拆分組件了，拆組件是一個很頭疼的問題，它非?？紤]一個人的細心與耐心，由于無法準確知道有哪些代碼要被拆走，也不能直觀的知曉依賴關系，移動變得非常的困難且容易出錯，一旦不能一次性拆分成功，到處都是編譯錯誤，便只能靠人肉一點一點的挪。

工欲善其事，必先利其器。為了解決這個問題，我們開發(fā)了一個輔助工具 RefactorMan： 它可以遞歸的解析出工程中所有源碼的引用和被引用情況，同時會根據預設規(guī)則自動分析出所有不合理的依賴，在開發(fā)人員根據提示解決了不合理依賴之后，即可將組件一鍵移出，大大減少了拆組件的工作量。我們在組件化初期曾經走過一些彎路，最初拆出的八個組件工程的的部分源碼經歷了幾次的反復移動才得出最優(yōu)解，而有了 RefactorMan，我們可以面對反復的拆分和組合組件有恃無恐。

Bonus ：由于可以分析和移動資源，所以額外獲得了清理無用資源的功能。

聯合編譯完整包

單獨運行組件 app 并不能完整的覆蓋所有的 case，尤其是在給 QA 測試的時候，還是需要編譯完整的主工程包的，所以我們需要一個直接編譯完整包的方案：

最初我們的實現方式只針對組件，比較簡單：

首先在 setting.gradle 中動態(tài)引入組件 module：

def allComponents = [“base”, “account” … “template” …]

allComponents.forEach({ name ->

if (shouldUseSource(name)) {

// 動態(tài)引入外部模塊

include “??{name}”

project(“??{name}”).projectDir = getComponentDir(name);

}

})

然后在 app/build.gradle 中切換依賴，需要將所有被間接依賴的組件全部 exclude 以防止同時依賴了一個組件的 module 和 aar：

allComponents.forEach({ name ->

if (shouldUseSource(name)) {

implementation(project(“??{name}”)) { exclude group: COMPONENT_GROUP }

} else {

implementation(“$COMPONEN{T}_{G}ROUP:${name}??{versions[name]}”) { exclude group: COMPONENT_GROUP }

}

})

由于所有組件的 group 都是一樣的，所以這樣做并沒有什么問題，但是后來一些基礎 SDK 也出現了這種需求，這時候就需要一種通用的源碼依賴方案，因此做了一下修改，直接使用 gradle 提供的依賴替換功能，只需要修改 setting.gradle 即可：

// … 忽略讀取配置代碼 …

configs.forEach { artifact, prj ->

include “??{prj.name}”

project(“??{prj.name}”).projectDir = new File(prj.dir)

}

gradle.allprojects { project ->

if (project == project.rootProject) {

return

}

project.configurations.all {

resolutionStrategy.dependencySubstitution {

configs.forEach { artifact, prj ->

// 在這里進行替換

substitute module(artifact) with project(“??{prj.name}”)

}

}

}

}

而 build.gradle 的依賴寫法與普通的工程完全一樣。

普通狀態(tài)下的的主工程：

源碼引用 template 組件后的主工程：

這樣我們就可以像之前在單工程中一樣寫代碼了。

得益于源碼引用，我們直接在提交組件代碼的時候，CI 會自動聯合主工程編譯出完整包，QA 會根據完整包進行測試，在測試通過后即可自動發(fā)布到公司的倉庫，并通過內部的集成平臺集成到主工程

小 tip ：工程 .idea/vcs.xml 中定義了當前工程關聯的 Git 倉庫，可以在聯合編譯的同時通過修改 vcs.xml 來把組件目錄也關聯到主工程 Git 配置中，在開發(fā)過程中就可以使用 Android Studio 的內置 Git 功能了

包含子業(yè)務線的組件

我們當前的組件，絕大部分是一個組件一個倉庫的，對于一般的組件來說，并沒有什么問題，但是對于有的業(yè)務線，本身規(guī)模比較大，包含了若干個子業(yè)務，比如知乎大學，電子書、live 和私家課等子業(yè)務，這些子業(yè)務本身功能獨立，但是共享整個業(yè)務線的基礎代碼，同時大業(yè)務線也有會一些匯總所有子業(yè)務的頁面，它們的關系是這個樣子：

這幾個業(yè)務如果都要拆分出去獨立成組件，然后抽離公共部分成為也成為一個業(yè)務線基礎組件，這時候會面臨一個很大的問題：由于幾條業(yè)務線都屬于同一個主業(yè)務線，做活動或者上新 Feature 的時候，這幾個組件經常會發(fā)生聯動，需要先更新 base 再更新其他業(yè)務線，提交 mr 也要同時提多個倉庫，出現頻繁的連鎖更新；而如果不拆的話，業(yè)務線代碼本身就已經很龐大，即使是單獨編譯組件 app 也會很慢，并且隨著時間的推移，各個業(yè)務線的代碼邊界會像組件化之前的主工程一樣逐漸劣化，耦合會越來越嚴重。

所以現在需求變成了這個樣子：

1. 對外保持只有一個組件：有聯動需求的時候，組件仍然只發(fā)布一次更新

2. 各個子業(yè)務仍舊保持互相獨立和隔離，可以獨立運行

我們曾經試圖使用 sourceSets 的方式將不同的業(yè)務代碼放到不同的文件夾，但是 sourceSets 的問題在于，它并不能限制各個 sourceSet 之間互相引用，base 模塊甚至可以直接引用最上層的代碼，雖然可以在編譯期進行檢查，但是總有一些后知后覺的意味，并且使用 sourceSets 想讓各個模塊單獨跑起來配置也比較麻煩。而 Android Studio 的 module 天然具有隔離的優(yōu)勢。所以我們的解決方案是在組件工程中使用多 Module 結構：
自我介紹一下，小編13年上海交大畢業(yè)，曾經在小公司待過，也去過華為、OPPO等大廠，18年進入阿里一直到現在。

深知大多數初中級Android工程師，想要提升技能，往往是自己摸索成長或者是報班學習，但對于培訓機構動則近萬的學費，著實壓力不小。自己不成體系的自學效果低效又漫長，而且極易碰到天花板技術停滯不前！

因此收集整理了一份《2024年Android移動開發(fā)全套學習資料》，初衷也很簡單，就是希望能夠幫助到想自學提升又不知道該從何學起的朋友，同時減輕大家的負擔。

既有適合小白學習的零基礎資料，也有適合3年以上經驗的小伙伴深入學習提升的進階課程，基本涵蓋了95%以上Android開發(fā)知識點，真正體系化！

由于文件比較大，這里只是將部分目錄截圖出來，每個節(jié)點里面都包含大廠面經、學習筆記、源碼講義、實戰(zhàn)項目、講解視頻，并且會持續(xù)更新！

如果你覺得這些內容對你有幫助，可以掃碼獲?。。。▊渥ⅲ篈ndroid）

最后

對于程序員來說，要學習的知識內容、技術有太多太多，要想不被環(huán)境淘汰就只有不斷提升自己，從來都是我們去適應環(huán)境，而不是環(huán)境來適應我們！

最后，我再重復一次，如果你想成為一個優(yōu)秀的 Android 開發(fā)人員，請集中精力，對基礎和重要的事情做深度研究。

對于很多初中級Android工程師而言，想要提升技能，往往是自己摸索成長，不成體系的學習效果低效漫長且無助。整理的這些架構技術希望對Android開發(fā)的朋友們有所參考以及少走彎路，本文的重點是你有沒有收獲與成長，其余的都不重要，希望讀者們能謹記這一點。

為了大家能夠順利進階中高級、架構師，我特地為大家準備了一套高手學習的源碼和框架視頻等精品Android架構師教程，保證你學了以后保證薪資上升一個臺階。

以下是今天給大家分享的一些獨家干貨：

《互聯網大廠面試真題解析、進階開發(fā)核心學習筆記、全套講解視頻、實戰(zhàn)項目源碼講義》點擊傳送門即可獲?。?/strong>文章來源地址http://www.zghlxwxcb.cn/news/detail-859803.html