由于我最近在自己的项目中有这个要求,我可能会给你一些建议.
基本上这是你的选择:
1.具有不同模块的单个项目
如果AppA和AppB以某种方式相关(这是您必须决定的),您可以轻松实现.您的项目中已经有AppA和LibC,因此您只需要在Studio for AppB中创建另一个App模块(文件>新模块>应用程序模块)
您可能会有趣地看到,您的项目目录最初的名称为AppA,而您的AppA模块名为app.这是因为Android Studio默认使用向导中提供的名称命名项目,而第一个模块始终命名为app.
您可以将包含项目从AppA重命名为类似项目(通过右键单击项目>重构>重命名,并将应用程序模块重命名为AppA.
基本结构如下所示:
Studio Project AppA (rename to "project")
|
|\_app (module AppA, rename to "AppA")
| |_ src
|
|\_AppB (module AppB)
| |_ src
|
\_LibC (module LibC, dependency for AppA and AppB)
|_ src
此设置的优点是它包含在一个Android Studio项目中,因此您可以免费获得应用程序模块和库之间的所有Android Studio重构魔法.
想象一下,您在LibC中更改了一个方法,它将反映在AppA和AppB中.
2.不同的项目,图书馆符号链接
基本上,这反映了您为AppA和AppB提供两个不同项目位置的想法 – 没有2个物理LibC位置.只需使用LibC(AppA)并将其符号链接到新位置(AppB).
不是一个漂亮的解决方案,但可能(我只能说Unix系统,但也应该在Win上工作.)
Studio Project AppA (location 1 on disk)
|
|\_app
| |_ src
|
\_LibC (dependency for app)
|_ src
…
Studio Project AppB (location 2 on disk)
|
|\_app
| |_ src
|
\_*LibC (symlinked from AppA project dir)
|_ src
请注意,在这种情况下,项目间重构将失败,例如您打开项目AppA,在LibC中进行重大更改,运行AppA.稍后您打开AppB并将导致编译时失败,因为AppB尚未适应使用LibC的新API.
3.图书馆作为外部依赖人工制品
这可以被认为是迄今为止最“专业”的方式.
创建您的应用程序项目,它们不必像选项1中那样位于同一项目树中,并将它们链接到库LibC(aar或jar)的构建工件.
理想情况下,这个人工制品是版本化的,位于(本地)maven存储库中.
这样,您始终拥有一致的构建(因为您链接到库的特定版本,无论LibC当前处于何种开发状态)
Studio Project AppA (location 1 on disk)
|
\_app
|_ src
|_ build.gradle dependency on libc (jar/aar + version XX)
…
Studio Project AppB (location 2 on disk)
|
|
\_app
|_ src
|_ build.gradle dependency on libc (jar/aar + version YY)
Studio Project LibC (location 3 on disk)
|
\_LibC (library module from AppA project dir)
|_ src (in development)
正如您所说,在您创建库模块之前,Android Studio会以某种方式强制您首先创建应用程序模块.我希望将来会随时改变,但这没什么大不了的.之后只需创建您的库模块,并摆脱应用程序模块.然后,您可以通过gradle构建库并导出要与项目一起使用的artefact(aar或jar).
在LibC的build.gradle中,您可以找到类似的东西将它部署到本地机器的maven存储库:
apply plugin: 'maven'
group = 'your.groupid.artefactid'
version = '0.2.0'
uploadArchives {
repositories {
mavenDeployer {
repository url: 'file://' + new File(System.getProperty('user.home'), '.m2/repository').absolutePath
}
}
}
如果您运行gradle uploadArchives,它会创建您的artefact并将其推送到您的本地maven存储库.
[编辑]
还有另一种可能的解决方案,类似于选项2.通过gradle作为文件参考从多个项目引用库,请参阅
此方法还具有选项2的缺点(没有多API版本控制,重构时没有应用程序间同步)
希望基于个人经验的总结可以帮助您找到方向.
如果应用程序相关,我个人会选择选项1,或选项3(Maven)