元件化架構需要各個元件不僅能夠單獨執行而且也能無縫的整合到主程式中，在這個過程中會遇到以下問題：
todo:
在專案的根目錄下的gradle.properties檔案中宣告乙個變數ismodule(該變數能對整個專案中所有的gradle檔案生效)代表是否是元件開發模式。
gradle.properties在每個元件build.gradle檔案中新增以下**，根據剛才定義的變數動態構建該模組。ismodule=false
if
(ismodule.
toboolean()
)else
可以為元件模式和工程模式分別指定不同的androidmanifest.xml檔案，並同時維護兩份檔案。這兩份xml檔案的區別就是，在元件模式下要去掉launcher activity的宣告，其他均相同。
//每個模組下的build.gradle檔案
sourcesets
else
}}
元件化不可避免的會出現資源名衝突的問題，如a和b元件裡面有相同名稱的等。解決這個問題最簡單的辦法就是在專案中約定資源檔案命名規約，比如強制使每個資源檔案的名稱以元件名開始，這個可以根據實際情況和開發人員制定規則。當然了萬能的gradle構建工具也提供了解決方法，通過在在元件的build.gradle中新增如下的**：
//設定了resourceprefix值後，所有的資源名必須以指定的字串做字首，否則會報錯。
//但是resourceprefix這個值只能限定xml裡面的資源，並不能限定資源，所有資源仍然需要手動去修改資源名。
resourceprefix "modulea_"
利用第三方路由框架實現元件間的跳轉，如arouter或activityrouter等。
common模組始終為com.android.library型別。它的主要用作是統籌管理所有依賴關係，各種android許可權的宣告以及工具庫的實現。所有模組都依賴common模組。它的主要作用如下：
common元件的androidmanifest.xml中宣告android應用的所有許可權uses-permission和uses-feature。所有業務元件無需在自己的androidmanifest.xml中再重複宣告許可權了。
common元件的build.gradle需要統一依賴業務元件中用到的各種第三方依賴庫和jar包，如arouter、okhttp等。
common元件的資源檔案中需要放置專案公用的drawable、layout、sting、dimen、color和style 等等，另外專案中的 activity主題必須定義在common中，方便和baseactivity配合保持整個android應用的介面風格統一。
空殼模組就是乙個空殼工程，沒有任何的業務**，也不能有activity，但它又必須被單獨劃分成乙個元件，而不能融合到其他元件中，是因為它有如下幾點重要功能：
空殼模組的 androidmanifest.xml 是我android應用的根表單，應用的名稱、圖示以及是否支援備份等等屬性都是在這份表單中配置的，其他元件中的表單最終在整合開發模式下都被合併到這份 androidmanifest.xml 中。
這個就是和業務相關的模組，無特殊的說明，如moudlea，moudleb，moudlec。
依賴關係：
殼模組依賴moudlea moudleb moudlec
各個moudle均依賴common
android架構學習之元件化
新公司的專案採用了元件化，此前對元件化有過一些研究，但是相關的經驗並不多，正好新的專案有實際運用，在此記錄下元件化的學習與實踐之路。網上元件化的文章很多，本人學習組建化的過程也借鑑了網上先輩們的文章。但大多數文章都從底層的細枝末節開始講述，由下而上給人一種這門技術 博大精深 望而生畏的感覺。而我寫這...
Android 架構元件LifeCycle
android.arch.lifecycle提供的類和介面可以讓你構建能感知生命週期 lifecycle aware 的類。所謂可以感知生命週期就是能夠根據activity或者fragment的生命週期自行調整類的行為。android系統中定義的大多數元件都是有生命週期的。這些元件的生命週期是由系統...
Android元件化開發實踐（二） 元件化架構設計
先說說我自己的元件化架構設計方案，請看下圖 元件化架構設計圖 為了便於理解，按照從下往上的順序來講講我的分層思路。元件之間必須遵循以下規則 現在已經有很多成熟的元件化框架了，比較著名的有阿里的手淘atlas框架但是這些框架可能都過於複雜，上手難度高，對很多人來說並不一定好用。總的說來，沒有最好的架構...