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

173

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

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

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

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

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

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

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

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

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

android android-gradle-plugin

— stkent
источник

55

«какая конфигурация должна быть указана в типе сборки, какая конфигурация должна быть указана во вкусе продукта» - типы сборки моделируют ваш жизненный цикл разработки (отладка, «собачья еда», выпуск и т. д.). Варианты продуктов моделируют вашу стратегию распространения (Google IAP против Amazon IAP против BlackBerry IAP и т. Д.). Это независимые понятия. Что касается остального, я бы предположил, что есть технические причины, связанные с реализацией, которые немного продиктовали, как они настроили DSL, и, следовательно, я был бы удивлен, если есть план слияния.

— CommonsWare

1

@CommonsWare, что имеет большой смысл на высоком уровне. И да, возможно, последовательная обработка типов / ароматов ограничивает, как и когда applicationId, например, можно изменить все .

— stkent

168

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

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

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

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

— Скотт Барта
источник

17

Спасибо, Скотт. Я определенно думаю, что это различие имеет смысл (и названия «тип сборки» и «вкус продукта» подходят для этого использования). Возможно, можно понять applicationIdпроблему следующим образом: поскольку ароматы представляют «совершенно разные» версии вашего приложения, имеет смысл указать «совершенно» разные идентификаторы приложений; в то время как для фиксированного варианта все типы сборки представляют «одно и то же» приложение, и поэтому им разрешено изменять только суффикс идентификатора приложения (сохраняя, таким образом, «группировку» идентификаторов приложения).

— stkent

28

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

shrinkResources
progaurdFile
и т.п.

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

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

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

applicationId
minSdkVersion
targetSdkVersion
versionCode
versionName

— itzhar
источник

9

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

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

— Джулиан А.
источник

0

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

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

— Эхсан Машхади
источник