引言:这不是一个关于如何在Android应用程序中使用构建类型和产品风格的问题。我了解其中的基本概念。这个问题更多的是试图理解应该在构建类型中指定哪个配置,应该在产品类型中指定哪个配置,以及是否确实有必要进行任何区分。

本周,我学习了更多关于Android应用的gradle配置。我最初认为我已经很好地处理了构建类型和产品风格,但随着文档的深入,我意识到两者之间的区别对我来说根本不清楚。

由于存在定义良好的层次结构(在构建类型中指定的属性优先于产品类型中指定的属性),我不理解为什么需要区分构建类型和产品类型。将所有属性和方法合并到产品风格DSL对象中,然后仅仅将构建类型作为(默认的)风格维度不是更好吗?

以下是一些让我困惑的具体例子:

signingConfig属性可以在构建类型和产品风格中设置…但是minifyEnabled(我假设还有shrinkResources?)只能在构建类型中配置。 applicationId只能在产品口味中指定…和applicationIdSuffix只能在构建类型中指定!?

实际问题:

对于上面的例子:构建类型和产品风格之间的角色是否有明确的区别?

如果是,最好的理解方式是什么?

如果不是,是否计划最终将构建类型和产品风格合并到一个可配置的DSL对象中?


当前回答

构建类型用于使用不同的证书指示调试/发布模式,并启用Proguard或debuggable标志。

这些风格用于具有自定义功能(例如免费或付费版本),最低和目标API级别,设备和API需求(如布局),可绘制的,因此您可以在不同风格中拥有不同的代码和资源。

其他回答

两者都是应用程序的重要组成部分,我们必须使用构建类型和产品风格提供不同的规则和管理

两者都在build.gradle(Module)中定义 # Build_Type 主要有哪些调试和发布

buildTypes {
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
        }
        debug {
            buildConfigField "boolean", "FILE_LOGGING", "true"
            signingConfig signingConfigs.debug
            versionNameSuffix ".debug"
        }
    }

在上面的构建类型中,我们可以为调试和发布提供一组不同的规则

# Product_Flavours 这取决于你所处的环境,如阶段,qa或制作

productFlavors {
       staging {
            versionNameSuffix "_STG"
            versionCode 12
            dimension "version"
            buildConfigField "boolean", "shareLog", "true"
            applicationIdSuffix ".staging.abcapp"
            
      }
        QA {
            versionNameSuffix "_awsQA"
            versionCode 01
            dimension "version"
            buildConfigField "boolean", "shareLog", "true"
            applicationIdSuffix ".awsqa.abcapp"
       
        }
        production {
            dimension "version"
            buildConfigField "boolean", "shareLog", "false"
            applicationIdSuffix ".android.abc"
            
        }
    }

使用这个你可以设置你的pkg名称,你也可以指定环境

您可以从构建变体中更改此构建类型和产品风味

构建类型用于使用不同的证书指示调试/发布模式,并启用Proguard或debuggable标志。

这些风格用于具有自定义功能(例如免费或付费版本),最低和目标API级别,设备和API需求(如布局),可绘制的,因此您可以在不同风格中拥有不同的代码和资源。

以下是我如何从本质上提炼出两者的区别:

buildType是构建的方式。 风味是构建的内容。

让我们看一个真实的例子。 假设你有一个煮好的面条盘。如果你问厨师这个问题

它的构建类型是什么?

他/她会这样回答-

用半开的水 少放盐 在高压锅等。

这意味着他/她在描述他/她是如何做面条的。

它的生产风味是什么? 他/她会这样回答-

干酪 不咸的 更少的油

这意味着他/她正在描述构建之后的实际情况。

让我们来看看理论

构建类型:在Android应用程序中,构建类型通常指的是你运行应用程序的环境。每个模块默认情况下都必须调试和发布构建类型,但你可以根据需要定义更多的构建类型。如果你在科技公司工作过,你可能知道通常不止这两家。您可以自定义您的构建类型,以包括其他风格,如QA,发布候选或RC, Pre-Prod,或任何适合您的需求。

风格:除了基于环境的差异之外,应用程序通常也会有所不同。口味支持这种变化。例如,你可以使用口味来处理:

选择付费版本还是免费版本。 为你上传的每个商店(游戏邦注:如亚马逊Appstore、谷歌Play store和三星Galaxy store)提供相应版本。 为不同的产品使用相同的应用程序,并自定义资产以改变应用程序的外观和感觉。

构建变体:变体是构建类型和构建风格的组合。例如,你可以拥有应用的“开发付费”版本,这是应用的“开发”构建类型和“付费”风格的结合。如果你同时拥有这两种风格和类型,你可以在上传到谷歌Play Store或任何其他商店时发布变体。

构建类型配置我们的应用程序的包装:

shrinkResources proguardFile 等。

产品类型配置不同的类和资源:

在Flavor1中,MainActivity可以做一些事情,而在Flavor2中,MainActivity可以有不同的实现 不同的应用名称 等。

每种产品风格都可以有自己的以下属性值,这些属性是基于defaultConfig中的相同属性的:

applicationId minSdkVersion targetSdkVersion versionCode versionName