本頁面由 Cloud Translation API 翻譯而成。

Android 應用程式模組化指南

含有多個 Gradle 模組的專案稱為多模組專案。本指南包含開發多模組 Android 應用程式的最佳做法和建議模式。

不斷成長的程式碼集問題

由於程式碼集不斷成長，擴充性、可讀性和整體程式碼品質往往會隨著時間逐漸降低。這是因為程式碼集的大小不斷增加所致，其中並無維護人員採取主動措施，強制執行易於維護的結構。模組化是一種建構程式碼集的方式，能改善可維護性並避免這些問題。

模組化是一種將程式碼集整理成鬆耦合部分且包含部分的做法。每個元件都是一個模組。每個模組都是獨立的，具有明確的用途。將問題分成幾個小而易於解決的子問題，就能降低設計和維護大型系��的複雜度。

模組化的優點有很多，但主要在於改善程式碼集的可維護性和整體品質。下表摘要說明主要優點。

權益	摘要
重複使用性	模組化可讓您共用程式碼，並透過同一個基礎建構多個應用程式。模組可以有效建構區塊。應用程式應是功能的總和，而功能會整理成獨立的模組。特定模組提供的功能不一定在特定應用程式中啟用。舉例來說，`:feature:news` 可屬於完整版變種版本和 Wear 應用程式，但不屬於試用版的變種版本。
嚴格控管瀏覽權限	模組可讓您輕鬆控管對程式碼集其他部分公開的內容。公開介面以外的任何內容均可標示為 `internal` 或 `private`，這樣就能避免在模組外使用。
可自訂提供方式	Play Feature Delivery 功能會使用應用程式套件的進階功能，方便您按條件或以隨選方式提供應用程式的特定功能。

上述優點只能透過模組化程式碼集實現。使用其他技術或許也能享有下列優點，但模組化功能可協助您進一步強制實現這些優點。

權益	摘要
彈性擴充	在緊耦合的程式碼集中，單次變更可能會在看似不相關的程式碼部分中，觸發串聯變更。經過適當模組化的專案會謹守關注點分離原則，進而限制耦合。這個做法可提供貢獻者更高的自主能力。
責任擔當	除了啟用提供自主能力以外，模組也可用於強制賦予責任。模組可設立一位專屬擁有者，負責維護程式碼、修正錯誤、新增測試及審查變更。
封裝	封裝表示程式碼的每個部分應該對其他部分都只具備最少程度的知識。隔離的程式碼更容易閱讀及理解。
可測試性	可測試性所描述的是測試程式碼的方便程度。如果程式碼中的元件可以輕鬆以隔離狀態進行測試，就稱為可測試的程式碼。
建構時間	部分 Gradle 功能 (例如漸進式建構、建構快取或平行建構) 可以利用模組化的特性提升建構效能。

程式碼集的精細程度是指組成程式碼集的模組精細程度。越精細的程式碼集含有越小的模組。設計模組化程式碼集時，應決定精細程度。做法是考慮程式碼集的大小和相對複雜度。過於精細會導致負擔加重，而過於粗略則會降低模組化的優勢。

一些常見問題如下：

過於精細：每個模組都會增加建構複雜度和樣板程式碼，因此帶來一定程度的負擔。複雜的建構設定會導致難以在各模組間保持設定一致。樣板程式碼過多會導致程式碼集繁瑣，且難以維護。如果負擔抵消了擴充性改善的好處，請考慮合併部分模組。
過於粗略：反之，如果模組過大，最終就只是一個單體，失去了失去模組化的好處。舉例來說，在小型專案中，您可以將資料層放入單一模組。但隨著規模成長，可能需要將存放區和資料來源分割為獨立的模組。
太過複雜：將專案模組化不一定是合理做法。主要因素是程式碼集的大小。如果您預計專案數量不會成長到超過特定閾值，那麼擴充性和建構時間增長的情形就不會發生。

如果您需要可重複使用性、嚴格控制瀏覽權限或使用 Play Feature Delivery 帶來的優點，就有必要使用模組化技術。如果不需要以上功能，只是想改善擴充性、擁有權、封裝或建構時間，那麼不妨試一試模組化。