如何从 Android Studio 中的根风格继承两种构建风格？

Question

我曾经有以下项目风格：

1. 苹果
2. 橙色

最初唯一的区别是applicationId/packageName。现在有一个不同的 java 文件。确切地说，是一个自定义的 ArrayAdapter。解决方案是创建src/Apple 和src/Orange，它们都继承自src/main。我从src/main 中删除了java 文件，并将副本放入src/Apple 和src/Orange 并进行了适当的修改。世界上一切都很好。

快进几周，现在 Apple 和 Orange 之间大约有 10 个 java 文件不同。再次......没什么大不了的。易于处理。将src/Apple 和src/Orange 中的java 文件分开。

快进到今天。我需要稍微修改一下，因为我想拥有每个版本的免费和高级版本。免费版和高级版仅在 URL 上有所不同。我打算简单地创建新类型，称为：

1. 苹果免费
2. ApplePremium
3. 无橙
4. OrangePremium

但我有一个难题。从现在开始，src/Apple 和 src/Orange 有 10 个不同的文件已更改...如果我更改 AppleFree 中的任何 java 文件，我必须确保在 ApplePremium 中执行相同操作。我有点处于十字路口，希望我的问题在这一点上是有道理的。我提出了三种可能的解决方案，但我不确定如何实施它们/正确的方法是什么/解决方案不是我想要的。

解决方案 1：

使用 if 语句 if (BuildConfig.FLAVOR==appleFree) {//use free Url} else {// use premium url}

问题： 两个 Url 在技术上都编译到 apk 中。我不想要这个。

解决方案 2：

让 src/AppleFree 和 src/ApplePremium 以某种方式从 src/Apple 父目录继承。

问题：不知道该怎么做。

解决方案 3：

像这样在 build.gradle 中添加免费和高级网址吗？

    productFlavors {
            appleFree {
                applicationId "com.example.apple.free"
                versionName "1.0"
                url "http://freeurl.com"
                versionCode 1
            }
            applePremium {
                applicationId "com.example.apple.premium"
                versionName "1.0"
                url "http://premiumurl.com"
                versionCode 1
            }
            orangeFree {
                applicationId "com.example.orange.free"
                versionName "1.0"
                versionCode 1
                url "http://freeurl.com"


            }
            orangePremium {
                applicationId "com.example.orange.premium"
                url "http://premiumurl.com"
                versionName "1.0"
                versionCode 1

            }
        } 

问题：不确定如何实现。

任何提示都是有帮助的。

编辑：

最终解决方案？

flavorGroups 'fruit', 'paid'

productFlavors {
    apple {
        flavorGroup 'fruit'
    }
    orange {
        flavorGroup 'fruit'
    }
    free {
        flavorGroup 'paid'
    }
    premium {
        flavorGroup 'paid'
    }
    appleFree {
        applicationId "com.example.apple.free"
        versionName "1.0"
        buildConfigField 'String', 'BASE_URL', 'http://freeurl.com'
        versionCode 1
    }
    applePremium {
        applicationId "com.example.apple.premium"
        versionName "1.0"
        buildConfigField 'String', 'BASE_URL', 'http://premiumurl.com'
        versionCode 1
    }
    orangeFree {
        applicationId "com.example.orange.free"
        versionName "1.0"
        versionCode 1
        buildConfigField 'String', 'BASE_URL', 'http://freeurl.com'
    }
    orangePremium {
        applicationId "com.example.orange.premium"
        buildConfigField 'String', 'BASE_URL', 'http://premiumurl.com' 
        versionName "1.0"
        versionCode 1
    }
    }

Answer 1

您的问题有很多可能的解决方案。最原生的 Gradle 解决方案是使用 Flavor Dimensions，如 http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Multi-flavor-variants 中所述

这也与您对解决方案 2 的想法类似。

它会像这样工作：

flavorDimensions 'fruit', 'paid'

productFlavors {
    apple {
        dimension 'fruit'
    }
    orange {
        dimension 'fruit'
    }
    free {
        dimension 'paid'
    }
    premium {
        dimension 'paid'
    }
}

这将为您提供构建变体（和源文件夹），在其中组合每个风味维度的所有可能性，保持与您在 flavorDimensions 语句中指定组的顺序相同（即 appleFree ，而不是freeApple)，因此：

* appleFree
* applePremium
* orangeFree
* orangePremium

在您的 src/ 文件夹中，您可以有以下可能性：

* src/main
* src/apple
* src/orange
* src/free
* src/premium
* src/appleFree
* src/applePremium
* src/orangeFree
* src/orangePremium

---

解决方案 3

您可以使用buildConfigField 来逐个指定BuildConfig 类中的常量：

productFlavors {
    appleFree {
        buildConfigField 'String', 'MY_URL', 'value1'
    }
    applePremium {
        buildConfigField 'String', 'MY_URL', 'value2'
    }
    orangeFree {
        buildConfigField 'String', 'MY_URL', 'value3'
    }
    orangePremium {
        buildConfigField 'String', 'MY_URL', 'value4'
    }

---

解决方案 1

我试图按照解决方案 1 的方式进行一些工作，但它不适用于您的确切用例。如果您在 Java 中有一个 if 条件来测试声明为 static final 的布尔值，那么编译器可以静态确定代码是否可访问，如果不是，它将删除它。因此：

static final boolean DEBUG = false;

...

if (DEBUG) {
    // do something
}

// do something 中的代码根本不会被编译。这是 Java 编译器有意并记录在案的行为，它允许您编写昂贵的调试代码，这些代码不会编译到您的发布二进制文件中。正是出于这个原因，BuildConfig.DEBUG 被声明为 static final。

有一个BuildConfig.FLAVOR，但它被定义为String，你不会得到同样的好处：

static final String FLAVOR = "orange";

...

if (FLAVOR.equals("apple")) {
    // do something
}

编译器不够聪明，无法进行静态分析，看到 // do something 无法访问，不编译它。 请注意，它在运行时可以正常工作，但死代码将包含在您的二进制文件中。

但是，如果它适合您，您可以从上面窃取 buildConfigField 方法，并在某些变体中定义一个额外的布尔变量，以允许有条件地编译代码。这比直接定义字符串更复杂解决方案 3，但如果您发现自己想要区分行为而不费心制作特定于风味的子类，您可以走这条路。