我正在为其他人编写一个即时应用程序以学习如何编写一个即时应用程序，并希望获得一些关于如何最好地为依赖项构建应用程序的想法。
现在阅读有关项目结构的 Android 开发者文档并参考下图：
我想知道新的gradle 3.0 依赖配置，哪些库应该存在于哪些模块中？
基本特征
我在想基本功能模块中的几乎所有东西都应该使用apigradle 配置，因为基本功能模块本质上会编译成 AAR 库文件。我可能对这个模块有一个问题，如果要使用 ROOM，这将是放置它的模块吗？
特征
现在在功能模块中，我的理解是一切都应该使用implementationgradle 配置，因为这些模块不应该将依赖关系泄漏到任何其他模块，以便真正使它们彼此独立。
只是想对我的理解进行一些确认，以及对项目有帮助的任何想法。如果你想查看我目前得到的代码，这里是 github repo。目前真的很简单，但我正在考虑使用 Retrofit 来搞乱星球大战 API。
感谢您提供的任何帮助，如果您想尝试自己提出拉取请求以获取其他人应该知道的即时应用程序的任何其他概念，请感谢您的帮助并乐意接受任何贡献。
正如keyboardsurfer 所提到的，您的依赖假设是正确的方向。
Base位于根目录，就像所有非基本功能模块共享的库，因此应该设置它的共享依赖项，以便
api依赖它的模块也可以访问它们。（不过，base 不必像库一样工作，它也可以是功能 APK 本身）
Features，作为一个即时应用程序，每个应用程序都作为自己的 APK 延伸到最后，因此没有理由将其依赖项泄漏给任何其他模块，因此应该在implementation此处设置依赖项。
在Google 示例中，cookie-api 和 install-api 是一些示例，它们更清楚地展示了依赖项配置的用法，正如我在上面解释的那样。
您问题中的共享详细信息是正确的。考虑以下一些建议，这些建议增加了 TWL 提到的几点：
例如，假设您有一个依赖于库 X、Y 和 Z 的应用程序。最初，您可以通过将所有依赖项放在基本 gradle.build 文件中来打包基本模块中的所有库。但是，如果只有功能模块中的代码需要库 Z，则将这种依赖关系从基本模块移动到功能模块是有意义的。只要没有其他功能模块依赖于同一个库，这种方法就可以工作。如果多个功能模块使用同一个库，那么将其保留在基本模块中绝对是有意义的。
当您的项目依赖的库依赖于另一个库时，就会发生传递依赖，而另一个库又可能依赖于另一个库。有时，这些传递依赖可能包含意想不到的惊喜，例如您根本不需要的库（即您从未在代码中使用的 JSON 处理库。）
我希望这会为您的查询添加一些信息，
我想知道新的 gradle 3.0 依赖配置，哪些库应该存在于哪些模块中？
其中一些链接也可以参考其他数据：
Android Instant Apps(best-practices) A
IA structure
