新进入一个团队,发现该团队针对不同的 flavor ,使用了不同的 sourceSets ,且这些 sourceSets 的代码有大量的重合。如:
productFlavors {
fla1 {
//...
}
fla2 {
//...
}
}
sourceSets {
fla1 {
java.srcDirs += ["src/common/java"]
java.srcDirs += ["src/path1/java"]
}
fla2 {
java.srcDirs += ["src/common/java"]
java.srcDirs += ["src/path2/java"]
}
}
上述例子中,path1 和 path2 的代码中有大量的重合。由于 flavor 之间一些代码编译不到一块,当 fla2 要使用到 fla1 的代码时,又不在 common 文件夹时,会习惯性地复制一份,而不是抽离到 common 。
而且随着项目的复杂度越来越高,即使想抽离到 common 的复杂度也越来越高。
不知道大家的 Android 项目有这么使用 flavor 的吗,我个人感觉这是一个坑。
![]() |
1
messnoTrace 12 天前
这玩意看起来像早期用来处理多渠道,多套不同代码的操作啊,或者叫兄弟包,马甲包
|
2
KratosOmega OP @messnoTrace #1 是啊,但是 path1 和 path2 按理说只放简单的代码。如果项目越复杂,还放 path1/path2 里,就会变成我说的情况了。
|
3
location123 12 天前
我们现在是这样 积重难返 出了 bug 负担不起 我们有七八个不同的硬件型号 common 做通用 其他做硬件的适配
|
4
open9527 12 天前
这个应该就是时间长了 大家都为了方便复制粘贴的代码 正常应该用接口去做
|
5
KratosOmega OP @open9527 #4 是的,就是这种 flavor 多 sourceSet 的模式,就难以对代码进行管控了。
|
6
Vclow 12 天前
明显是积重难返了,都没勇气去改变,这时候需要个勇士。
|
7
KratosOmega OP @Vclow #6 好像要把我推出去做那个勇士了,囧
|
8
t4here 11 天前
都放到 common 里,马甲包怎么避免代码重复...按道理,前人之所以整个 path1/java,path2/java,就是想相同逻辑代码,不同实现来保证差异吧?只是后来工程越来越赶,就基本不差异代码了
|
![]() |
9
magicls 11 天前
先拿对比工具对比一下几个 flavor 下的 common ,看有没有办法抽成真 common 吧。
|
10
XXWHCA 11 天前
就是偷懒,能跑就行,最初可能只是一些配置项的差异,随着迭代 path1 path2 的代码互相复制
|
![]() |
11
AoEiuV020JP 11 天前
我尽量只在 flavor 放 config ,然后 main 里面判断处理,
除了某些是有依赖不能出现在某个 flavor 这种情况才会把功能代码放在 flavor, 而反过来如果是某个依赖不能出现在某个 flavor ,那么其他 flavor 就会有这个依赖相关的重复代码,理论上可以搞个 common 解决但我也是靠复制的, |
![]() |
12
InkStone 11 天前
buildVariant 维护时间长了确实很容易出现这种问题。
理论上来说嘛肯定是不能到处复制粘贴代码,某个变体独有的文件夹中只应该保有最小粒度的实现,common 中对接口做抽象。但现实中维护时很容易就会完全搞混……只能说能 if else 就 if else 吧,别天天惦记 variant 这套了,直接硬编码在里面靠 buildConfig 的参数去控制,比这样简单多了。 不过 sourceSet 高度重合这个是应该的,如果 sourceSet 只有很小部分重合,那就不该用 variant 了,而应该直接开个新的包。 |
13
KratosOmega OP @InkStone #12 非常同意
|