V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
KratosOmega
V2EX  ›  Android

Android flavor 与 sourceSets 的争议

  •  
  •   KratosOmega · 12 天前 · 1087 次点击

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

    13 条回复    2025-02-11 17:26:57 +08:00
    messnoTrace
        1
    messnoTrace  
       12 天前
    这玩意看起来像早期用来处理多渠道,多套不同代码的操作啊,或者叫兄弟包,马甲包
    KratosOmega
        2
    KratosOmega  
    OP
       12 天前
    @messnoTrace #1 是啊,但是 path1 和 path2 按理说只放简单的代码。如果项目越复杂,还放 path1/path2 里,就会变成我说的情况了。
    location123
        3
    location123  
       12 天前
    我们现在是这样 积重难返 出了 bug 负担不起 我们有七八个不同的硬件型号 common 做通用 其他做硬件的适配
    open9527
        4
    open9527  
       12 天前
    这个应该就是时间长了 大家都为了方便复制粘贴的代码 正常应该用接口去做
    KratosOmega
        5
    KratosOmega  
    OP
       12 天前
    @open9527 #4 是的,就是这种 flavor 多 sourceSet 的模式,就难以对代码进行管控了。
    Vclow
        6
    Vclow  
       12 天前
    明显是积重难返了,都没勇气去改变,这时候需要个勇士。
    KratosOmega
        7
    KratosOmega  
    OP
       12 天前
    @Vclow #6 好像要把我推出去做那个勇士了,囧
    t4here
        8
    t4here  
       11 天前
    都放到 common 里,马甲包怎么避免代码重复...按道理,前人之所以整个 path1/java,path2/java,就是想相同逻辑代码,不同实现来保证差异吧?只是后来工程越来越赶,就基本不差异代码了
    magicls
        9
    magicls  
       11 天前
    先拿对比工具对比一下几个 flavor 下的 common ,看有没有办法抽成真 common 吧。
    XXWHCA
        10
    XXWHCA  
       11 天前
    就是偷懒,能跑就行,最初可能只是一些配置项的差异,随着迭代 path1 path2 的代码互相复制
    AoEiuV020JP
        11
    AoEiuV020JP  
       11 天前
    我尽量只在 flavor 放 config ,然后 main 里面判断处理,

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

    而反过来如果是某个依赖不能出现在某个 flavor ,那么其他 flavor 就会有这个依赖相关的重复代码,理论上可以搞个 common 解决但我也是靠复制的,
    InkStone
        12
    InkStone  
       11 天前
    buildVariant 维护时间长了确实很容易出现这种问题。

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

    不过 sourceSet 高度重合这个是应该的,如果 sourceSet 只有很小部分重合,那就不该用 variant 了,而应该直接开个新的包。
    KratosOmega
        13
    KratosOmega  
    OP
       11 天前
    @InkStone #12 非常同意
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   917 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 19ms · UTC 20:51 · PVG 04:51 · LAX 12:51 · JFK 15:51
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.