建議直接跳轉閱讀第二篇組件化文章
組件化案例視頻代碼傳送門:https://www.jikexueyuan.com/zhiye/course/84.html?type=18
Android 組件化案例第二篇:http://blog.csdn.net/asddavid/article/details/54599688
前言
在移動開發橫行，應用日漸飽和，開發週期，迭代週期要求越來越快的時代下，經常看見有羣裏小夥伴抱怨問題：
Gradle編譯一個項目需要10分鐘、20分鐘…..
這什麼JB玩意兒，什麼都忘一個類裏放，怎麼改呀（扣腦殼）….
這裏給出兩個方案：
- 加大電腦內存，提升AndroidStudio的使用內存
- 合理規劃項目結構，組件化、模塊化開發項目
第一個解決方案，貌似不太靠譜，總不能每次都換電腦吧？都已經硬件頂配還怎麼換啊。。。下面我們談談第二點，使用組件化，模塊化解決。
什麼是組件化
大致來說，組件可以分爲兩大類，一類是application組件，一類是libs組件的module.
application組件是一個可運行的app.
libs可以作爲application的依賴，但是自身不可作爲程序運行的存在。
一般開發的缺點，爲什麼組件化
實施者對基礎模塊，基礎組件，中間層，上層業務的規劃不合理
業務，組件，資源放在一起，任何一個改動都會消耗甚大，運行整個application
因爲所有東西都一堆，項目不易維護，耦合度超高
不利於單獨模塊化測試
組件化好處
組件化描述完畢後，看組件化後有什麼好處呢。
每個Module可以單獨調試開發，節省編譯時間
單獨個模塊開發可共享工具類，網絡庫等
對測試來說可以對單個模塊進行快速測試
公司業務繁重可以不斷複用模塊，節省開發時間
對個人來說，可以積累個人的開發工具
組件化弊端
組件與組件之間存在業務聯繫
組件調用application
資源命名重複
- 引用的庫版本不對應，使用衝突
第一點：存在業務聯繫的可以歸納爲同一個組件
第二點：在基礎架構層建BaseApplication,統一使用
第三點：命名按照moduel的開頭命名
第四點： 參考此文
下面看兩張圖：
①：沒有組件化、模塊化的的項目
不用多說，什麼都在application一個組件內部。
②：具有一定架構並組件化、模塊化
這張圖也許有的兄弟看起來很模糊，馬上我們將其拆分從最底部慢慢升上來看。
- SDK層
SDK層主要爲Android的SDK以及我們需要使用的第三方SDK（地圖、定位、直播等）
- 基礎架構層
首先我們得選取一個整體架構模式，比如MVC。 其他模塊全部依賴於Base的基礎框架層完成，NetWork，SQLite、圖片加載庫，支付等組件模塊以便給予業務層使用。
- 業務框架層
此處簡單列舉三個例子，有Login、Shop、Circle三大組件模塊，
此3個業務模塊需要什麼即依賴基礎框架層的Module完成。DEBUG期間可以單獨作爲application使用，當要正式打包時候將作爲libs使用。
- 應用層
應用層即爲application，依賴於業務框架（上訴的Login、Shop、Circle）完成的Native部分，如果有部分業務跨平臺了，如HyBird，React-Native等，混合開發將其和Native部分綜合即可完成一個App.
項目組件化圖例
我們完成基礎框架模塊的newwork等模塊後將其加入basemvp，看看如何在basemvp依賴：
apply plugin: 'com.android.library'
android {
compileSdkVersion rootProject.ext.android.compileSdkVersion
buildToolsVersion rootProject.ext.android.buildToolsVersion
defaultConfig {
minSdkVersion rootProject.ext.android.minSdkVersion
targetSdkVersion rootProject.ext.android.targetSdkVersion
versionCode rootProject.ext.android.versionCode
versionName rootProject.ext.android.versionName
}
buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
}
}
dependencies {
compile fileTree(dir: 'libs', include: ['*.jar'])
compile rootProject.ext.dependencies.appcompatV7
compile rootProject.ext.dependencies.design
compile project(':allure_base_module:imageloader')
compile project(':allure_base_module:network')
compile project(':allure_base_module:utils')
}
均依賴於basemvp的基礎框架。
業務模塊
apply plugin: 'com.android.library'
android {
compileSdkVersion rootProject.ext.android.compileSdkVersion
buildToolsVersion rootProject.ext.android.buildToolsVersion
defaultConfig {
minSdkVersion rootProject.ext.android.minSdkVersion
targetSdkVersion rootProject.ext.android.targetSdkVersion
versionCode rootProject.ext.android.versionCode
versionName rootProject.ext.android.versionName
}
buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
}
}
dependencies {
compile fileTree(dir: 'libs', include: ['*.jar'])
compile rootProject.ext.dependencies.appcompatV7
compile rootProject.ext.dependencies.design
compile project(':allure_base_module:basemvp')
}
依賴於基礎框架模塊完成業務邏輯的書寫。
最終APP
apply plugin: 'com.android.application'
android {
compileSdkVersion rootProject.ext.android.compileSdkVersion
buildToolsVersion rootProject.ext.android.buildToolsVersion
defaultConfig {
minSdkVersion rootProject.ext.android.minSdkVersion
targetSdkVersion rootProject.ext.android.targetSdkVersion
versionCode rootProject.ext.android.versionCode
versionName rootProject.ext.android.versionName
}
buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
}
}
dependencies {
compile fileTree(dir: 'libs', include: ['*.jar'])
compile rootProject.ext.dependencies.appcompatV7
compile rootProject.ext.dependencies.design
compile project(':allure_core_module:login')//登陸
//其他模塊
}僅僅需要依賴 業務模塊即可，至於你有多少業務模塊取決於你的業務。
總結
看完整篇內容，相信大家對組件化有了一定的認識，並知道組件化的好處，爲什使用它。
個人認爲，組件化的開發難度並不大，真正的難度在於理解當前公司的業務需求，並在其基礎上能很好的解耦提高靈活度，所以具體是否組件化還是得看公司的業務發展。
若公司業務發展單一，是否組件化意義並不大，反而會加大自身開發成本，當業務已經成熟在回頭來優化組件化也未嘗不可。
