前言:这不是关于如何在 Android 应用中使用构建类型和产品风格的问题.我了解所涉及的基本概念.这个问题更多是关于尝试了解应该在构建类型中指定哪些配置,应该在产品风格中指定哪些配置,以及是否真的需要任何区别.
本周,我一直在学习有关 Android 应用的 gradle 配置的更多信息.我最初认为我对构建类型和产品风格有很好的处理,但我越深入文档,我就越意识到两者之间的区别对我来说根本不清楚.
This week, I've been learning more about gradle configuration for Android apps. I initially thought I had a good handle on build types vs product flavors, but the deeper I got into the documentation the more I realized the distinction between the two was not clear to me at all.
由于存在明确定义的层次结构(在某种意义上,构建类型中指定的属性优先于产品风格中指定的属性),我不明白为什么需要区分构建类型和产品风格全部.将所有属性和方法合并到产品风味 DSL 对象中,然后将构建类型视为(默认)风味维度不是更好吗?
Since there is a well-defined hierarchy (in the sense that properties specified in build types take precedence over those specified in product flavors), I don't understand why there is a need to distinguish between build types and product flavors at all. Would it not be better to merge all properties and methods into the product flavor DSL object, and then just treat build type as a (default) flavor dimension?
一些导致我困惑的具体例子:
Some concrete examples that led to my confusion:
signingConfig
属性可以在构建类型和产品风格中设置...但是 minifyEnabled
(并且,我假设,shrinkResources
?) 只能在构建类型中配置.
The signingConfig
property can be set in both build types and product flavors... but minifyEnabled
(and, I assume, shrinkResources
?) can only be configured in build types.
applicationId
只能在产品风味中指定...而 applicationIdSuffix
只能在构建类型中指定!?
applicationId
can only be specified in product flavors... and applicationIdSuffix
can only be specified in build types!?
实际问题:
鉴于上述示例:构建类型与产品风格的角色之间是否有明显区别?
Given the above examples: is there a clear distinction between the roles of build types vs product flavors?
如果是这样,最好的理解方法是什么?
If so, what is the best way to understand it?
如果没有,是否计划最终将构建类型和产品风格合并到一个可配置的 DSL 对象中?
If not, is the plan to eventually merge build types and product flavors into a single configurable DSL object?
扩展 @CommonsWare 在评论中所说的内容,基本思想是构建类型适用于功能上没有不同的应用程序的不同构建——如果你有你的应用程序的调试和发布版本,它们是同一个应用程序,但一个包含调试代码,可能更多的日志记录等,另一个经过简化和优化,可能通过 ProGuard 混淆.使用风味,目的是应用程序在某些方面明显不同.最明显的例子是您的应用的免费版本和付费版本,但开发人员也可能会根据分发位置(这可能会影响应用内结算 API 的使用)进行区分.
Expanding on what @CommonsWare said in the comments, the basic idea is that build types are for different builds of your application that aren't functionally different -- if you have a debug and release version of your app, they're the same app, but one contains debugging code, maybe more logging, etc., and the other is streamlined and optimized and possibly obfuscated via ProGuard. With flavors, the intent is that the app is notably different in some way. The clearest example would be a free vs. a paid version of your app, but developers may also differentiate based on where it's being distributed (which could affect in-app billing API use).
有些开发人员为不同的客户制作了许多不同版本的类似应用程序——例如,一个简单的应用程序在网络视图中打开网页,每个版本都有不同的 URL 和品牌——这是对风味的一种很好的利用.
There are developers that make many, many different versions of a similar app for different customers -- an example might be a simple app that opens up a web page in a web view, with different URLs and branding for each version -- this is a good use of flavors.
重申一下,如果它是相同的应用程序",请取模一些对最终用户并不重要的差异,特别是如果除一个之外的所有变体都用于您自己的测试和开发用途并且只有一个变体将部署到最终用户,那么它是构建类型的良好候选者.如果它是一个不同的"应用程序并且将向用户部署多个变体,那么它可能是产品风格的候选者.
To reiterate, if it's "the same application", modulo some differences that aren't important to the end user, and especially if all of the variants except for one are for your own testing and development use and only one variant will be deployed to end users, then it's a good candidate for build types. If it's "a different" application and multiple variants would be deployed to users, then perhaps it's a candidate for a product flavor.
您已经看到构建类型和风格之间存在一些功能差异,其中一种支持某些选项,而另一种则不支持.但即使它们相似,概念也不同,并且没有将它们合并在一起的计划.
You've already seen that there are some functionality differences between build types and flavors, in that some options are supported for one but not the other. But the concepts are different even though they're similar, and there's no plan to merge them together.
这篇关于为什么构建类型与产品风味不同?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持html5模板网!