問題描述

前言:這不是關(guān)于如何在 Android 應(yīng)用中使用構(gòu)建類型和產(chǎn)品風(fēng)格的問題.我了解所涉及的基本概念.這個(gè)問題更多是關(guān)于嘗試了解應(yīng)該在構(gòu)建類型中指定哪些配置，應(yīng)該在產(chǎn)品風(fēng)格中指定哪些配置，以及是否真的需要任何區(qū)別.

本周，我一直在學(xué)習(xí)有關(guān) Android 應(yīng)用的 gradle 配置的更多信息.我最初認(rèn)為我對(duì)構(gòu)建類型和產(chǎn)品風(fēng)格有很好的處理，但我越深入文檔，我就越意識(shí)到兩者之間的區(qū)別對(duì)我來(lái)說根本不清楚.

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.

由于存在明確定義的層次結(jié)構(gòu)(在某種意義上，構(gòu)建類型中指定的屬性優(yōu)先于產(chǎn)品風(fēng)格中指定的屬性)，我不明白為什么需要區(qū)分構(gòu)建類型和產(chǎn)品風(fēng)格全部.將所有屬性和方法合并到產(chǎn)品風(fēng)味 DSL 對(duì)象中，然后將構(gòu)建類型視為(默認(rèn))風(fēng)味維度不是更好嗎?

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?

一些導(dǎo)致我困惑的具體例子:

Some concrete examples that led to my confusion:

• signingConfig 屬性可以在構(gòu)建類型和產(chǎn)品風(fēng)格中設(shè)置...但是 minifyEnabled(并且，我假設(shè)，shr??inkResources?) 只能在構(gòu)建類型中配置.

• 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 只能在產(chǎn)品風(fēng)味中指定...而 applicationIdSuffix 只能在構(gòu)建類型中指定！?

applicationId can only be specified in product flavors... and applicationIdSuffix can only be specified in build types!?

實(shí)際問題:

鑒于上述示例:構(gòu)建類型與產(chǎn)品風(fēng)格的角色之間是否有明顯區(qū)別?

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?

如果沒有，是否計(jì)劃最終將構(gòu)建類型和產(chǎn)品風(fēng)格合并到一個(gè)可配置的 DSL 對(duì)象中?

If not, is the plan to eventually merge build types and product flavors into a single configurable DSL object?

推薦答案

擴(kuò)展 @CommonsWare 在評(píng)論中所說的內(nèi)容，基本思想是構(gòu)建類型適用于功能上沒有不同的應(yīng)用程序的不同構(gòu)建——如果你有你的應(yīng)用程序的調(diào)試和發(fā)布版本，它們是同一個(gè)應(yīng)用程序，但一個(gè)包含調(diào)試代碼，可能更多的日志記錄等，另一個(gè)經(jīng)過簡(jiǎn)化和優(yōu)化，可能通過 ProGuard 混淆.使用風(fēng)味，目的是應(yīng)用程序在某些方面明顯不同.最明顯的例子是您的應(yīng)用的免費(fèi)版本和付費(fèi)版本，但開發(fā)人員也可能會(huì)根據(jù)分發(fā)位置(這可能會(huì)影響應(yīng)用內(nèi)結(jié)算 API 的使用)進(jìn)行區(qū)分.

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).

有些開發(fā)人員為不同的客戶制作了許多不同版本的類似應(yīng)用程序——例如，一個(gè)簡(jiǎn)單的應(yīng)用程序在網(wǎng)絡(luò)視圖中打開網(wǎng)頁(yè)，每個(gè)版本都有不同的 URL 和品牌——這是對(duì)風(fēng)味的一種很好的利用.

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.

重申一下，如果它是相同的應(yīng)用程序"，請(qǐng)取模一些對(duì)最終用戶并不重要的差異，特別是如果除一個(gè)之外的所有變體都用于您自己的測(cè)試和開發(fā)用途并且只有一個(gè)變體將部署到最終用戶，那么它是構(gòu)建類型的良好候選者.如果它是一個(gè)不同的"應(yīng)用程序并且將向用戶部署多個(gè)變體，那么它可能是產(chǎn)品風(fēng)格的候選者.

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.

您已經(jīng)看到構(gòu)建類型和風(fēng)格之間存在一些功能差異，其中一種支持某些選項(xiàng)，而另一種則不支持.但即使它們相似，概念也不同，并且沒有將它們合并在一起的計(jì)劃.

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.

這篇關(guān)于為什么構(gòu)建類型與產(chǎn)品風(fēng)味不同?的文章就介紹到這了，希望我們推薦的答案對(duì)大家有所幫助，也希望大家多多支持html5模板網(wǎng)！