App 组件化/模块化之路——构建开发架构思路

跟着营业的成长 App 开起身术也越来越成熟，对开辟者来说 App 代码量也敏捷地增长到一个数量级。对于若何架构 App 已经每个开辟者面对的实际问题。好的架构可以进步开辟者的效力，降低保护成本。

因为营业增长引起项目中代码量激增，以及汗青遗留问题和构造纷乱，作为一个有代码洁癖的法度榜样员，很早就开端思虑若何组织 App 架构的问题了。今朝碰到的重要有以下几点问题：

代码量激增引起构造纷乱
各个模块互相引用且耦合度高
无法自力开辟或者调试组件代码
无法应对组件插拔的需求（例如：产品经理今天把这个功能加上，第二天又去掉落，第三天又加回来T_T）

App 架构图

App架构图

假设将授权登录组件定名为auth。那么其它组件在应用的时刻可能类似以下代码片段

自下而大将 App 分为：

内核层
营业层
应用层

内核层

内核层是包含了为 App 供给公共办事的的一些库。例如：公共资本、收集库、日记对象、数据库、图片加载等核心库。这些是全部 App 基本库。

营业层

我认为这一层是全部 App 架构的关键。因为根据实际营业需求，这一层会分别出很多自力组件（其实就是对应于 Android Studio 的 Module），但这些组件可以自力运行，相当于一个小应用（组件若何自力运行将在应用层中会具体解析）。并且这些组件不再像传统的方法进行互相引用，而是采取了组件路由进行各个组件的通信。

在浏览了大年夜量的文档之后，根据实际项目开辟碰到的问题，我总结了以下架构。因为程度有限，有不合理的迎接拍砖

Dev 在 Android Studio 中是对应一个 Application 。在 gradle 中设备为

比如组件 A 中须要跳转到组件 B 中的一个 Activity 页面，传统的做法是在 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);

当然实现膳绫擎的路由道理也有很多方法，例如可以应用 Android 体系的隐式调用实现跳转通信。

在 Manifest 文件中

<activity android:name=".ModuleBActivity"><intent-filter><dataandroid: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>

App 组件化/模块化开辟架构思路

实际调用

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 编码思维

营业层要实现比较好组件分别，对法度榜样猿如今编码思维要转换一下，要切换到 SDK 思维。

那什么是 SDK 思维呢？

想想项目中引用他人编写的库的接口应用方法，就不难解得了。即站在应用者的角度上思虑：若何应用接口才是最便利的？例如公司现有好几个 App 产品，每个 App 都须要应用同样的授权登录。那么这个授权登录模块就可以自力成一个组件。

AuthApi.authorize(context,userId,password).onAuthorizeFinished(authInfo->doAuthorizeWorks(authInfo)//处理登录后的逻辑，把授权码保存用于请求其他营业接口，例如请求用户信息等);

所以，作者认为接口设计或者供给给该是利他主义的。当然这纯粹是作者的一家之言，迎接持续拍砖。

应用层

顾名思义，这一层是半数个 App 的┞符合，也是 App 的人口。这里有 Main 和 Dev。个中 Main 是对各个营业组件的┞符合，是最终打包的产品的上层应用。而组件人口是自力运行和调试各个组件的子应用。

apply plugin: 'com.android.application'

它是一个可以自力运行的子工程，要调试 Module A 那么在 Dev 中将引用该组件

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

这就是一个大年夜概的思路，可以看出这个框架关键的部分是在于营业层的分别。须要把本来项目中的基本模块采掏出来，放在内核层中。那么下一步就开端构建我们的内核层组件。

【编辑推荐】

1/2 1 2 下一页尾页

　　推荐阅读

　　华为云BU副总裁：我们要做企业数字化转型的推动者

【51CTO.com原创稿件】一说公有云，大年夜家也许立时会想到的是阿里云，或者AWS——或者说，华为云>>>详细阅读

本文标题：App 组件化/模块化之路——构建开发架构思路

地址：http://www.17bianji.com/lsqh/36150.html

1/2 1