Android flavor 与 sourceSets 的争议

[KratosOmega]

新进入一个团队，发现该团队针对不同的 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 的吗，我个人感觉这是一个坑。

[PlF5rhxZ7ilCSfBI]

这玩意看起来像早期用来处理多渠道，多套不同代码的操作啊，或者叫兄弟包，马甲包

[KratosOmega]

@messnoTrace #1 是啊，但是 path1 和 path2 按理说只放简单的代码。如果项目越复杂，还放 path1/path2 里，就会变成我说的情况了。

[location123]

我们现在是这样 积重难返 出了 bug 负担不起 我们有七八个不同的硬件型号 common 做通用 其他做硬件的适配

[open9527]

这个应该就是时间长了 大家都为了方便复制粘贴的代码 正常应该用接口去做

[KratosOmega]

@open9527 #4 是的，就是这种 flavor 多 sourceSet 的模式，就难以对代码进行管控了。

[Vclow]

明显是积重难返了，都没勇气去改变，这时候需要个勇士。

[KratosOmega]

@Vclow #6 好像要把我推出去做那个勇士了，囧

[t4here]

都放到 common 里,马甲包怎么避免代码重复...按道理,前人之所以整个 path1/java,path2/java,就是想相同逻辑代码,不同实现来保证差异吧?只是后来工程越来越赶,就基本不差异代码了

[magicls]

先拿对比工具对比一下几个 flavor 下的 common ，看有没有办法抽成真 common 吧。

[XXWHCA]

就是偷懒，能跑就行，最初可能只是一些配置项的差异，随着迭代 path1 path2 的代码互相复制

[AoEiuV020JP]

我尽量只在 flavor 放 config ，然后 main 里面判断处理，

除了某些是有依赖不能出现在某个 flavor 这种情况才会把功能代码放在 flavor,

而反过来如果是某个依赖不能出现在某个 flavor ，那么其他 flavor 就会有这个依赖相关的重复代码，理论上可以搞个 common 解决但我也是靠复制的，

[InkStone]

buildVariant 维护时间长了确实很容易出现这种问题。

理论上来说嘛肯定是不能到处复制粘贴代码，某个变体独有的文件夹中只应该保有最小粒度的实现，common 中对接口做抽象。但现实中维护时很容易就会完全搞混……只能说能 if else 就 if else 吧，别天天惦记 variant 这套了，直接硬编码在里面靠 buildConfig 的参数去控制，比这样简单多了。

不过 sourceSet 高度重合这个是应该的，如果 sourceSet 只有很小部分重合，那就不该用 variant 了，而应该直接开个新的包。

[KratosOmega]

@InkStone #12 非常同意