Чому типи складання відрізняються від ароматів продуктів?

Передмова: це не питання про те, як використовувати типи складання та ароматизатори продуктів у додатку для Android. Я розумію основні поняття. Це питання стосується більше спроб зрозуміти, яку конфігурацію слід вказати в типі збірки, яку конфігурацію слід вказати в ароматі продукту та чи потрібне будь-яке розрізнення.

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

Оскільки існує чітко визначена ієрархія (у тому сенсі, що властивості, визначені у типах збірки, мають перевагу над тими, які вказані в ароматах продуктів), я не розумію, чому взагалі потрібно розрізняти типи складання та ароматизатори продукту. Чи не було б краще об'єднати всі властивості та методи в об'єкт DSL аромату продукту, а потім просто розглядати тип збірки як (за замовчуванням) смаковий розмір?

Деякі конкретні приклади, які призвели до моєї плутанини:

• signingConfigВластивість можна встановити в обох типах зборки і смаків продукції ... але minifyEnabled(і, я вважаю, shrinkResources?) Ви можете змінити тільки в типах збірки.

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

Актуальні питання :

З огляду на наведені вище приклади: чи існує чітка відмінність між ролями типів складання та ароматами продуктів?

Якщо так, то який найкращий спосіб зрозуміти це?

Якщо ні, чи планується врешті-решт об’єднати типи збірок та ароматизатори продуктів в єдиний об'єкт DSL, який можна настроювати?

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

Є розробники, які роблять багато, багато різних версій подібного додатка для різних клієнтів - приклад може бути простим додатком, який відкриває веб-сторінку у веб-перегляді, з різними URL-адресами та брендингом для кожної версії - це добре використовувати ароматизатори.

Щоб повторити, якщо це "той самий додаток", модулюйте деякі відмінності, які не важливі для кінцевого користувача, і особливо, якщо всі варіанти, окрім одного, призначені для власного тестування та використання, і лише один варіант буде розгорнуто в кінцеві користувачі, то це хороший кандидат для типів збірки. Якщо це "інша" програма і кілька варіантів будуть розгорнуті для користувачів, то, можливо, це кандидат на аромат продукту.

Ви вже бачили, що існують деякі функціональні відмінності між типами збірки та смаками, оскільки деякі варіанти підтримуються для одного, а не для іншого. Але поняття різні, хоча вони схожі, і немає плану їх об'єднання.

buildType налаштувати, як ми пакуємо наш додаток

• скорочуютьсяресурси
• progaurdFile
• тощо.

Налаштування аромату різних класів та ресурсів.

• у Flavor1 ваша MainActivity може щось зробити, а в Flavor2 інша реалізація

• диференціювати назву програми

• тощо.

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

• applicationId
• minSdkVersion
• targetSdkVersion
• versionCode
• versionName

Ось як я перенаправляю різницю до її суті:

• buildType- як будувати.
• flavorце те, що складено.

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

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