KratosOmega
V2EX  ›  Android

Android flavor 与 sourceSets 的争议

  •  
  •   KratosOmega · Feb 10, 2025 · 4685 views
    This topic created in 484 days ago, the information mentioned may be changed or developed.

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

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

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

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

    不过 sourceSet 高度重合这个是应该的,如果 sourceSet 只有很小部分重合,那就不该用 variant 了,而应该直接开个新的包。
    KratosOmega
        13
    KratosOmega  
    OP
       Feb 11, 2025
    @InkStone #12 非常同意
    About   ·   Help   ·   Advertise   ·   Blog   ·   API   ·   FAQ   ·   Solana   ·   3128 Online   Highest 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 41ms · UTC 14:42 · PVG 22:42 · LAX 07:42 · JFK 10:42
    ♥ Do have faith in what you're doing.