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

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.

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