Почему типы сборки отличаются от вкусов продукта?

Question

Предисловие: это не вопрос о том, как использовать типы сборки и разновидности продукта в приложении для Android. Я понимаю основные концепции. Этот вопрос больше касается попыток понять, какая конфигурация должна быть указана в типе сборки, какая конфигурация должна быть указана во вкусе продукта и действительно ли необходимо какое-либо различие.

На этой неделе я узнал больше о конфигурации gradle для приложений Android. Сначала я думал, что хорошо разбираюсь в типах сборки по сравнению со вкусами продукта, но чем глубже я углублялся в документацию, тем больше понимал, что различие между этими двумя понятиями мне совершенно не понятно.

Поскольку существует четко определенная иерархия (в том смысле, что свойства, указанные в типах сборки, имеют приоритет над свойствами, указанными в вариантах продукта), я не понимаю, почему вообще необходимо различать типы сборки и варианты продукта. Не лучше ли объединить все свойства и методы в DSL-объект "Ароматизатор продукта", а затем просто рассматривать тип сборки как ("по умолчанию") Ароматизатор?

Несколько конкретных примеров, которые привели меня в замешательство:

• signingConfig свойство может быть установлено как в типах сборки, так и во вкусе продукта... но minifyEnabled (и, я полагаю, shrinkResources?) можно настроить только в типах сборки.

• applicationId можно указывать только во вкусе продукта... и applicationIdSuffix можно указывать только в типах сборки!?

Актуальный вопрос (ы):

Учитывая приведенные выше примеры: существует ли четкое различие между ролями типов сборки и разновидностей продукта?

Если да, то как лучше всего это понять?

Если нет, планируется ли в конечном итоге объединить типы сборки и разновидности продукта в один настраиваемый объект DSL?

Answer 1

Расширяя сказанное @CommonsWare в комментариях, основная идея заключается в том, что типы сборок предназначены для разных сборок вашего приложения, которые не отличаются функционально - если у вас есть отладочная и выпускная версии приложения, это одно и то же приложение., но один содержит код отладки, возможно, больше журналирования и т. д., а другой оптимизирован и оптимизирован и, возможно, скрыт с помощью ProGuard. Суть ароматов в том, что приложение заметно отличается в некотором роде. Самым ярким примером будет бесплатная и платная версия вашего приложения, но разработчики также могут различать в зависимости от того, где оно распространяется (что может повлиять на использование API биллинга в приложении).

Есть разработчики, которые делают много-много разных версий одного и того же приложения для разных клиентов - примером может быть простое приложение, которое открывает веб-страницу в веб-представлении, с разными URL-адресами и брендингом для каждой версии - это хорошее использование ароматов.

Повторим, если это "одно и то же приложение", по модулю некоторые различия, которые не важны для конечного пользователя, и особенно если все варианты, кроме одного, предназначены для вашего собственного тестирования и разработки, и только один вариант будет развернут в конечные пользователи, то это хороший кандидат для типов сборки. Если это "другое" приложение и для пользователей будет развернуто несколько вариантов, то, возможно, это кандидат на вкус продукта.

Вы уже видели, что между типами сборки и разновидностями есть некоторые функциональные различия в том, что некоторые опции поддерживаются для одного, но не для другого. Но концепции разные, хотя они похожи, и нет никакого плана объединить их.

Answer 2

buildType настроить, как мы упаковываем наше приложение

• shrinkResources
• progaurdFile
• и т.п.

Аромат настраивает разные классы и ресурсы.

• в Flavor1 ваша MainActivity может что-то делать, а в Flavor2 другая реализация

• другое имя приложения

• и т.п.

Каждый продукт вкуса может иметь свои собственные значения следующих свойств, среди прочих, которые основаны на тех же свойствах из defaultConfig:

• applicationId
• minSdkVersion
• targetSdkVersion
• versionCode
• versionName

Answer 3

Вот как я понимаю разницу в ее сути:

• buildType это как построить.
• flavor это что из сборки.

Answer 4

Давайте проясним это на примере из реальной жизни. Предположим, у вас есть тарелка с приготовленной лапшой. Итак, если вы спросите повара,

Что это за тип сборки?

он ответит так -

• С половиной кипяченой воды
• С меньшим количеством соли
• В скороварке и т. Д.

Это означает s / он описывает , как он / построить лапшу.

Каковы его производственные вкусы? он ответит так -

• Сырный
• Менее соленый
• Менее жирный

Это означает, что он / она описывает то, что на самом деле теперь во вкусе после сборки.

Придем к теории -

Типы сборки: позволяет создавать и изменять конфигурации сборки. По умолчанию каждый модуль имеет типы сборки отладки и выпуска, но при необходимости вы можете определить другие.

Ароматизаторы: позволяет создавать несколько вариантов сборки, где каждый вариант определяет набор параметров конфигурации, таких как параметры модуля. minimum и target SDK version, а version code и version name. Например, вы можете определить один вариант, который имеет минимальный SDK, равный 15 и целевой SDK, равный 21, а другой вариант, который имеет минимальный SDK, равный 19, и целевой SDK, равный 23.

Answer 5

Оба являются неотъемлемой частью вашего приложения, в котором мы должны предоставить различные правила и нормы, используя типы сборки и вкусы продуктов.

Оба они определены в 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 Это зависит от вашей среды, например, сцена, качество или производство

      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"
            
        }
    }

Используя это, вы можете установить свое имя пакета, также вы можете указать среду

Эти типы сборки и вкусы продукта вы можете изменить из вариантов сборки

Answer 6

build types используются для указания debug/release режим с разными сертификатами и включение Proguard или же debuggable флаг.

flavors используются для создания пользовательских функций (например, бесплатной или платной версии), minimum and target API уровни, устройства и требования API, такие как layout, drawable так что вы можете иметь разный код и ресурсы в разных flavors,