Android元件化開發實踐（二）：元件化架構設計

摘要： 先說說我自己的元件化架構設計方案，請看下圖： 元件化架構設計圖 圖中可以看到，從上往下分為4層：APP殼工程、常規業務元件層、基礎業務元件層、基礎功能元件層。 為了便於理解，按照從下往上的順序來講講我的分層思路。 基礎功能元件 ...

先說說我自己的元件化架構設計方案，請看下圖：

圖中可以看到，從上往下分為4層：APP殼工程、常規業務元件層、基礎業務元件層、基礎功能元件層。

為了便於理解，按照從下往上的順序來講講我的分層思路。

• 基礎功能元件
  這個層的元件都是最基礎的功能，通常它不包含任何業務邏輯，也可以說這些元件是一些通用的工具類。例如日誌記錄元件，它只是提供了日誌記錄的能力，你要記錄什麼樣的日誌，它並不關心；例如基礎UI元件，它是一個全域性通用的UI資源庫；例如網路服務元件，它封裝了網路的請求能力。
• 基礎業務元件
  該層元件是對一些系統通用的業務能力進行封裝的元件。例如公共業務元件裡，我封裝了BaseActivity、BaseFragment等；例如分享能力元件，我封裝了微信、QQ、微博等的分享能力，其他業務只要整合該元件就能進行相關分享；例如共享公共資料元件，我封裝了應用可以全域性訪問的資料，如使用者登入資訊等。
• 常規業務元件
  該層的元件就是我們真正的業務元件了。我們通常按照功能模組來劃分業務元件，例如註冊登入、使用者個人中心、APP的首頁模組等。這裡的每個業務元件都是一個小的APP，它必須可以單獨編譯，單獨打包成APK在手機上執行。
• 核心管理元件
  主要包括路由服務元件、元件生命週期管理元件。路由主要是為了解決元件間通訊問題，而元件生命週期管理主要是為了解決元件的初始化等問題。
• APP殼工程
  殼工程依賴了需要整合的業務元件，它可能只有一些配置檔案，沒有任何程式碼邏輯。根據你的需要選擇整合你的業務元件，不同的業務元件就組成了不同的APP。

元件之間必須遵循以下規則：

• 只有上層的元件才能依賴下層元件，不能反向依賴，否則可能會出現迴圈依賴的情況；
• 同一層之間的元件不能相互依賴，這也是為了元件之間的徹底解耦；

現在已經有很多成熟的元件化框架了，比較著名的有阿里的手淘atlas框架 ofollow,noindex">https://github.com/alibaba/atlas ，但是這些框架可能都過於複雜，上手難度高，對很多人來說並不一定好用。總的說來，沒有最好的架構設計，只有合適自己的架構設計，不能為了架構而架構。