Ailurus

@yuyejiang slideshare 网站可能挂了，可以看这个 [Modularity](https://github.com/MDCC2016/Android-Session-Slides/blob/master/02-From.Containerization.To.Modularity.pdf).

@chuyun923 假如是四个人同时开发一个 APP ，每个人负责一个模块，我们先想一下正常的开发模式，一个人在自己的模块里写了一个 util（只是一个例子，也可能是其他的类），然后提交代码了，另一个人更新下来了代码，接下来写代码刚好用到了这个 util 里的一个方法或者变量，于是直接就拿来用来，久而久之，这两个模块的耦合度会越来越高。未来某一天，那个人把 util 里的那个方法或者变量删了，结果整个团队都编译不过了。 为什么他们能相互引用呢？因为他们都是作为宿主的一个 library 而存在的啊，都是属于宿主的一部分。如果要想他们之间没有耦合，在没有任何黑科技引入的情况下，就只好把每个模块都打成 apk ，两个完全独立的 apk 工程，是无法引用彼此的类的。而且每个模块都是一个可以独立运行的 apk ，这样就可以去单独地去测试维护这个模块。 而最终是要打成一个 apk 的，因此在 release 的时候，其他模块又不能作为 apk 存在，否则正常情况下无法加载到模块里的类。所以 release 的时候，就把这个模块作为一个 library ，而整个工程就是一个普通的 APP...

@flyer88 这是个很好的问题。 实际上在 MDCC 上 oasisfeng 也有讲到这个问题，他给出的方案是不管是传递数据还是提供服务，都可以使用 BroadcastReceiver 和 ContentProvider ，甚至是共享进程，来进行通信。这是一种非常轻量的解决方案，同样是不牵涉任何黑科技，甚至是稍微复杂一点的技术。 不过我其实想到有另外一种方案，如果有一些后端的经验或者对 Atlas 有一些了解的话，很容易可以想到 OSGi 这种方式。每个模块单独提供出服务，供其他模块去使用。这是一种比较复杂的解决方案，在组件化这样一个轻量的解决方案里显得重一些，需要在编译期和运行期分别做处理，使得编译期和运行期所引用的类要都能够被找到。 需要注意的一点，本着最大化解耦的原则，这两种方式，都要求当前模块的负责人在提供对外服务的时候，要对所有的可能会用到的接口进行收敛，不管是使用 BroadcastReceiver 和 ContentProvider ，还是类 OSGi ，都要尽可能少地暴露接口。

要在这里选择安装哪个 module 里打出来的包。 或者也可以点击右侧边栏的 install group 里的任务安装，不过不推荐，会有 bug 。 推荐在终端里用命令去安装。

@fqcheng220 哪个类引用不到？日志贴一下看看。

@fqcheng220 在 extra_config.gradle 的脚本可以导出一个 Library 的 'sharedDependency.jar' ``` gradle provided fileTree(dir: project(':componentizationlibrary').projectDir.absolutePath + '/outputs/jar/', include: 'sharedDependency.jar') ``` 就是为了引用的时候不报你日志里的这个错误。

@fqcheng220 demo 是没问题的，你再检查检查吧。

@baoyachi :)

@csatshell 真要这样用的话，那就没办法了，至少是我没想到有什么办法。也不建议这样用的，最好一个 module 至少保留一个 Activity ，将 Activity 作为 Fragment 的容器，这样也不容易出现 Fragment 嵌套很多层的情况。

@ytqiu 参考 https://github.com/airbnb/DeepLinkDispatch