一种低侵入性的组件化方案 之 组件化需要考虑的几个问题

github开源地址 github.com/beyondxia/m…

    上一篇文章，我们讨论了目前传统的解耦方案和通信机制。其实解耦只是我们实施组件化的第一步，要做到真正的组件化，还需要针对业务模块做代码的独立分仓，lib话（aar化），模块能够以aar库的形式集成到主APP，进一步提供模块的独立性，甚至可以及其方便的进行组件的安装和卸载。

1. 如何确保模块之间绝对的解耦完成
2. 如何进行代码的分仓，中间可能会涉及到哪些问题
3. 如何极简的做到模块的接入和下线需求。

    我们先从第二个问题开始讨论，就是【如何进行代码的分仓，中间可能会涉及到哪些问题】。

    在我所开发的几个大型项目当中，涉及到组件化的需求，都是在项目有小到大发展到一定程度，业务模块越来越多，开发人员数量达到一定数量时，才开始对项目进行组件化的规划。这就意味着，项目刚开始时，我们所有的模块都是在一个代码仓内进行开发的，开发人员也都是在一起开发，模块界限不是很明确。这种情况下，我们再对模块进行组件化拆分，会涉及哪些问题呢：

1. 比如A模块希望获取B模块的model数据、自定义view、fragment等，但是这些结构的定义是在B中定义的，A中无法找到定义；
2. 再比如几个模块需要共享一些资源 文件（如图片，layout，value等）等，我们不可能把相同的资源每个模块中都保留一份。

    我们知道，模块功能暴露以接口方式暴露，接口是需要放中间服务层的，如下图：

    针对上面的问题，我们也可以和服务接口一样，把相应的共享数据放在服务层。只不过共享的资源文件，我们建议以独立的module库放在服务层，各个业务模块根据需求可以选择是否依赖该module库。

    接下来，我们再来讨论第一个问题【何确保模块之间绝对的解耦完成】这儿又分为两种情况：

1. 如何保证子模块之间没有任何依赖
2. 如何保证主app对子模块是没有依赖的。

    对于第一个问题，只要子模块的依赖依赖列表（gradle- dependencies）中没有对其他模块的依赖，就可以绝对保证本模块和其他模块之间是绝对解耦的。

    第二个问题，如何保证主APP对子模块没有绝对的依赖呢，我们知道，主APP如果希望集成子模块，就必须依赖子模块。我们可以使用新版gradle插件依赖选项runtimeOnly，只在运行时可以使用，编译时依赖直接报错。

通过这种方式，可以保证各个模块和主App之间达到绝对的解耦。

    下面我们接着讨论第三个问题【如何极简的做到模块的接入和下线需求】:

    对一个新的业务模块，我们要能够一个极简的方式接入我们的主APP，这很重要，这决定这业务方的接入成本和接入意愿。这就要求我们的框架（特别是解耦框架）能够在极小的代码改动量的情况下，能够快速接入主APP，这部分内容，我们会在后续的文章中详细说明：一种低侵入性的组件化方案 之 传统组件化方案的问题

    那如果我们希望在某些特定的场景或版本中，下线某些业务模块，那该怎么办呢？这里我们需要考虑两个问题：

1. 代码打包中，可以选择性的打包某些业务模块
2. 下线后，对于正常的模块间的调用，app的稳定性要能得到保证，不能因为调用了一个不存在的模块而导致APP编译不通过或应用运行crash。针对问题1，很好解决，主APP中选择性的依赖某些模块即可。第二个问题，就对我们的框架有一定的要求了，我们的解耦，总线，路由框架要能够有一定的异常处理机制，比如：对于某些可能要下线的模块，其他模块在调用的之后，框架可以抛出一个模块不存在的异常，调用方必须捕获该异常。

服务提供：

public abstract class LoginService extends PAService implements ILogin {
	public static ILogin get() throws NoServiceException {
		return getService(SERVICE_NAME);
	}
}
复制代码

调用方：

String username = null;
try {
    username = LoginService.get().getUserName();
} catch (NoServiceException e) {
    e.printStackTrace();
}
复制代码

上一篇：一种低侵入性的组件化方案 之 APP组件化简介

下一篇：一种低侵入性的组件化方案 之 传统组件化方案的问题