一種低侵入性的組件化方案 之 組件化須要考慮的幾個問題

github開源地址 github.com/beyondxia/m…

    上一篇文章，咱們討論了目前傳統的解耦方案和通訊機制。其實解耦只是咱們實施組件化的第一步，要作到真正的組件化，還須要針對業務模塊作代碼的獨立分倉，lib話（aar化），模塊可以以aar庫的形式集成到主APP，進一步提供模塊的獨立性，甚至能夠及其方便的進行組件的安裝和卸載。

1. 如何確保模塊之間絕對的解耦完成
2. 如何進行代碼的分倉，中間可能會涉及到哪些問題
3. 如何極簡的作到模塊的接入和下線需求。

    咱們先從第二個問題開始討論，就是【如何進行代碼的分倉，中間可能會涉及到哪些問題】。

    在我所開發的幾個大型項目當中，涉及到組件化的需求，都是在項目有小到大發展到必定程度，業務模塊愈來愈多，開發人員數量達到必定數量時，纔開始對項目進行組件化的規劃。這就意味着，項目剛開始時，咱們全部的模塊都是在一個代碼倉內進行開發的，開發人員也都是在一塊兒開發，模塊界限不是很明確。這種狀況下，咱們再對模塊進行組件化拆分，會涉及哪些問題呢：

1. 好比A模塊但願獲取B模塊的model數據、自定義view、fragment等，可是這些結構的定義是在B中定義的，A中沒法找到定義；
2. 再好比幾個模塊須要共享一些資源 文件（如圖片，layout，value等）等，咱們不可能把相同的資源每一個模塊中都保留一份。

    咱們知道，模塊功能暴露以接口方式暴露，接口是須要放中間服務層的，以下圖：

    針對上面的問題，咱們也能夠和服務接口同樣，把相應的共享數據放在服務層。只不過共享的資源文件，咱們建議以獨立的module庫放在服務層，各個業務模塊根據需求能夠選擇是否依賴該module庫。

    接下來，咱們再來討論第一個問題【何確保模塊之間絕對的解耦完成】這兒又分爲兩種狀況：

1. 如何保證子模塊之間沒有任何依賴
2. 如何保證主app對子模塊是沒有依賴的。

    對於第一個問題，只要子模塊的依賴依賴列表（gradle- dependencies）中沒有對其餘模塊的依賴，就能夠絕對保證本模塊和其餘模塊之間是絕對解耦的。

    第二個問題，如何保證主APP對子模塊沒有絕對的依賴呢，咱們知道，主APP若是但願集成子模塊，就必須依賴子模塊。咱們可使用新版gradle插件依賴選項runtimeOnly，只在運行時可使用，編譯時依賴直接報錯。

經過這種方式，能夠保證各個模塊和主App之間達到絕對的解耦。

    下面咱們接着討論第三個問題【如何極簡的作到模塊的接入和下線需求】:

    對一個新的業務模塊，咱們要可以一個極簡的方式接入咱們的主APP，這很重要，這決定這業務方的接入成本和接入意願。這就要求咱們的框架（特別是解耦框架）可以在極小的代碼改動量的狀況下，可以快速接入主APP，這部份內容，咱們會在後續的文章中詳細說明：一種低侵入性的組件化方案 之 傳統組件化方案的問題

    那若是咱們但願在某些特定的場景或版本中，下線某些業務模塊，那該怎麼辦呢？這裏咱們須要考慮兩個問題：

1. 代碼打包中，能夠選擇性的打包某些業務模塊
2. 下線後，對於正常的模塊間的調用，app的穩定性要能獲得保證，不能由於調用了一個不存在的模塊而致使APP編譯不經過或應用運行crash。針對問題1，很好解決，主APP中選擇性的依賴某些模塊便可。第二個問題，就對咱們的框架有必定的要求了，咱們的解耦，總線，路由框架要可以有必定的異常處理機制，好比：對於某些可能要下線的模塊，其餘模塊在調用的以後，框架能夠拋出一個模塊不存在的異常，調用方必須捕獲該異常。

服務提供：

public abstract class LoginService extends PAService implements ILogin {
	public static ILogin get() throws NoServiceException {
		return getService(SERVICE_NAME);
	}
}
複製代碼

調用方：

String username = null;
try {
    username = LoginService.get().getUserName();
} catch (NoServiceException e) {
    e.printStackTrace();
}
複製代碼

上一篇：一種低侵入性的組件化方案 之 APP組件化簡介

下一篇：一種低侵入性的組件化方案 之 傳統組件化方案的問題