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

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

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

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

Некоторые конкретные примеры, которые привели к моей путанице:

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

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

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

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

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

Ответ 1

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

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

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

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

Ответ 2

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

shrinkResources
progaurdFile
и др.

Вкус настроить различные классы и ресурсы.

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

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

applicationId
minSdkVersion
targetSdkVersion
versionCode
versionName

Ответ 3

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

buildType - это способ сборки.
flavor это то, что из сборки.

Ответ 4

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

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