App 組件化/模塊化開發(fā)架構思路

隨著業(yè)務的發(fā)展 App 開發(fā)技術也越來越成熟，對開發(fā)者來說 App 代碼量也迅速地增長到一個數(shù)量級。對于如何架構 App 已經(jīng)每個開發(fā)者面臨的實際問題。好的架構可以提高開發(fā)者的效率，降低維護成本。

由于業(yè)務增長引起項目中代碼量激增，以及歷史遺留問題和結構混亂，作為一個有代碼潔癖的程序員，很早就開始思考如何組織 App 架構的問題了。目前遇到的主要有以下幾點問題：

1. 代碼量激增引起結構混亂
2. 各個模塊相互引用且耦合度高
3. 無法獨立開發(fā)或者調(diào)試組件代碼
4. 無法應對組件插拔的需求（例如：產(chǎn)品經(jīng)理今天把這個功能加上，第二天又去掉，第三天又加回來T_T）

App 架構圖

在閱讀了大量的文檔之后，根據(jù)實際項目開發(fā)遇到的問題，我總結了以下架構。由于水平有限，有不合理的歡迎拍磚

自下而上將 App 分為：

• 內(nèi)核層
• 業(yè)務層
• 應用層

內(nèi)核層

內(nèi)核層是包含了為 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)的隱式調(diào)用實現(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>

實際調(diào)用

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 產(chǎn)品，每個 App 都需要使用同樣的授權登錄。那么這個授權登錄模塊就可以獨立成一個組件。

假設將授權登錄組件命名為auth。那么其它組件在使用的時候可能類似以下代碼片段

AuthApi.authorize(context,userId,password).onAuthorizeFinished(
authInfo->doAuthorizeWorks(authInfo)//處理登錄后的邏輯，把授權碼保存用于請求其他業(yè)務接口，例如請求用戶信息等
);

所以，作者覺得接口設計或者提供應該是利他主義的。當然這純粹是作者的一家之言，歡迎繼續(xù)拍磚。

應用層

顧名思義，這一層是對整個 App 的整合，也是 App 的入口。這里有 Main 和 Dev。其中 Main 是對各個業(yè)務組件的整合，是最終打包的產(chǎn)品的上層應用。而組件入口是獨立運行和調(diào)試各個組件的子應用。

Dev 在 Android Studio 中是對應一個 Application 。在 gradle 中配置為

apply plugin: 'com.android.application'

它是一個可以獨立運行的子工程，要調(diào)試 Module A 那么在 Dev 中將引用該組件

dependencies {
compile fileTree(dir: 'libs', include: ['*.jar'])
compile project(':moduleA')
...
}

這就是一個大概的思路，可以看出這個框架關鍵的部分是在于業(yè)務層的分離。需要把原來項目中的基礎模塊抽取出來，放在內(nèi)核層中。那么下一步就開始構建我們的內(nèi)核層組件。