App 組件化/模塊化之路——構建開發(fā)架構思路
App 組件化/模塊化開發(fā)架構思路
隨著業(yè)務的發(fā)展 App 開發(fā)技術也越來越成熟，對開發(fā)者來說 App 代碼量也迅速地增長到一個數(shù)量級。對于如何架構 App 已經(jīng)每個開發(fā)者面臨的實際問題。好的架構可以提高開發(fā)者的效率，降低維護成本。
由于業(yè)務增長引起項目中代碼量激增，以及歷史遺留問題和結構混亂，作為一個有代碼潔癖的程序員，很早就開始思考如何組織 App 架構的問題了。目前遇到的主要有以下幾點問題：
- 代碼量激增引起結構混亂
- 各個模塊相互引用且耦合度高
- 無法獨立開發(fā)或者調試組件代碼
- 無法應對組件插拔的需求（例如：產品經(jīng)理今天把這個功能加上，第二天又去掉，第三天又加回來T_T）
App 架構圖
在閱讀了大量的文檔之后，根據(jù)實際項目開發(fā)遇到的問題，我總結了以下架構。由于水平有限，有不合理的歡迎拍磚
自下而上將 App 分為：
- 內核層
- 業(yè)務層
- 應用層
內核層
內核層是包含了為 App 提供公共服務的的一些庫。例如：公共資源、網(wǎng)絡庫、日志工具、數(shù)據(jù)庫、圖片加載等核心庫。這些是整個 App 基礎庫。
業(yè)務層
我認為這一層是整個 App 架構的關鍵。因為根據(jù)實際業(yè)務需求，這一層會分離出許多獨立組件（其實就是對應于 Android Studio 的 Module），但這些組件可以獨立運行，相當于一個小應用（組件如何獨立運行將在應用層中會詳細解析）。并且這些組件不再像傳統(tǒng)的方式進行相互引用，而是采用了組件路由進行各個組件的通信。
比如組件 A 中需要跳轉到組件 B 中的一個 Activity 頁面，傳統(tǒng)的做法是在 ModuleAActivity 中
Intent intent = new Intent(this,ModuleBActivity.class);
intent.putExtra("data", data);
startActivity(intent);
這樣 Module A 與 Module B 耦合度就很強
比較好的做法應該是
Intent intent = Router.route(context,"BPackageName.ModuleBActivity",data); startActivity(intent);
當然實現(xiàn)上面的路由原理也有很多方式，例如可以使用 Android 系統(tǒng)的隱式調用實現(xiàn)跳轉通信。
在 Manifest 文件中
<activity android:name=".ModuleBActivity"> <intent-filter> <data android:host="moduleb" android:path="/entry" android:scheme="router"/> <action android:name="android.intent.action.VIEW"/> <category android:name="android.intent.category.DEFAULT"/> <category android:name="android.intent.category.BROWSABLE"/> </intent-filter> </activity>
實際調用
String url = "router://moduleb/entry";
Intent intent = new Intent(Intent.ACTION_VIEW, Uri.parse(url));
intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
PackageManager packageManager = getPackageManager();
List<ResolveInfo> activities = packageManager.queryIntentActivities(intent, 0);
if (!activities.isEmpty()) {
startActivity(intent);
}
Router 層目前有一個比較好的開源框架可以參考，來自 alibaba 的開源項目：ARouter
SDK 編碼思維
業(yè)務層要實現(xiàn)比較好組件分離，對程序猿現(xiàn)在編碼思維要轉換一下，要切換到 SDK 思維。
那什么是 SDK 思維呢？
想想項目中引用他人編寫的庫的接口使用方式，就不難理解了。即站在使用者的角度上思考：如何使用接口才是最方便的？例如公司現(xiàn)有好幾個 App 產品，每個 App 都需要使用同樣的授權登錄。那么這個授權登錄模塊就可以獨立成一個組件。
假設將授權登錄組件命名為auth。那么其它組件在使用的時候可能類似以下代碼片段
AuthApi.authorize(context,userId,password).onAuthorizeFinished( authInfo->doAuthorizeWorks(authInfo)//處理登錄后的邏輯，把授權碼保存用于請求其他業(yè)務接口，例如請求用戶信息等 );
所以，作者覺得接口設計或者提供應該是利他主義的。當然這純粹是作者的一家之言，歡迎繼續(xù)拍磚。
應用層
顧名思義，這一層是對整個 App 的整合，也是 App 的入口。這里有 Main 和 Dev。其中 Main 是對各個業(yè)務組件的整合，是最終打包的產品的上層應用。而組件入口是獨立運行和調試各個組件的子應用。
Dev 在 Android Studio 中是對應一個 Application 。在 gradle 中配置為
apply plugin: 'com.android.application'
它是一個可以獨立運行的子工程，要調試 Module A 那么在 Dev 中將引用該組件
dependencies {
compile fileTree(dir: 'libs', include: ['*.jar'])
compile project(':moduleA')
...
}
這就是一個大概的思路，可以看出這個框架關鍵的部分是在于業(yè)務層的分離。需要把原來項目中的基礎模塊抽取出來，放在內核層中。那么下一步就開始構建我們的內核層組件。
