Pourquoi les types de construction sont-ils différents des saveurs des produits?

Préface: il ne s'agit pas de savoir comment utiliser les types de build et les saveurs de produit dans une application Android. Je comprends les concepts de base impliqués. Cette question consiste davantage à essayer de comprendre quelle configuration doit être spécifiée dans un type de construction, quelle configuration doit être spécifiée dans une saveur de produit et si une distinction est réellement nécessaire.

Cette semaine, j'en ai appris davantage sur la configuration gradle pour les applications Android. Au départ, je pensais avoir une bonne maîtrise des types de build par rapport aux saveurs de produits, mais plus j'approfondissais la documentation, plus je réalisais que la distinction entre les deux n'était pas claire du tout.

Puisqu'il existe une hiérarchie bien définie (dans le sens où les propriétés spécifiées dans les types de build ont priorité sur celles spécifiées dans les saveurs de produit), je ne comprends pas pourquoi il est nécessaire de faire la distinction entre les types de build et les saveurs de produit. Ne serait-il pas préférable de fusionner toutes les propriétés et méthodes dans l'objet DSL de saveur du produit, puis de traiter simplement le type de construction comme une dimension de saveur (par défaut)?

Quelques exemples concrets qui ont conduit à ma confusion:

• La signingConfigpropriété peut être définie à la fois dans les types de build et les saveurs de produit ... mais minifyEnabled(et, je suppose shrinkResources,?) Ne peut être configurée que dans les types de build.

• applicationIdne peut être spécifié que dans les versions de produit ... et applicationIdSuffixne peut être spécifié que dans les types de construction !?

La (les) question (s) réelle (s) :

Compte tenu des exemples ci-dessus: y a-t-il une distinction claire entre les rôles des types de construction et des saveurs de produit?

Si oui, quelle est la meilleure façon de le comprendre?

Sinon, est-il prévu de fusionner à terme les types de build et les variantes de produit en un seul objet DSL configurable?

En développant ce que @CommonsWare a dit dans les commentaires, l'idée de base est que les types de build sont pour différentes versions de votre application qui ne sont pas fonctionnellement différentes - si vous avez une version de débogage et de publication de votre application, ce sont la même application , mais l'un contient du code de débogage, peut-être plus de journalisation, etc., et l'autre est simplifié et optimisé et peut-être obscurci via ProGuard. Avec les saveurs, l'intention est que l'application soit sensiblement différente d'une certaine manière. L'exemple le plus clair serait une version gratuite ou payante de votre application, mais les développeurs peuvent également faire la différence en fonction de l'endroit où elle est distribuée (ce qui pourrait affecter l'utilisation de l'API de facturation intégrée à l'application).

Il existe des développeurs qui créent de très nombreuses versions différentes d'une application similaire pour différents clients - un exemple pourrait être une application simple qui ouvre une page Web dans une vue Web, avec des URL et une marque différentes pour chaque version - il s'agit d'un bon usage des saveurs.

Pour réitérer, s'il s'agit de "la même application", modulez certaines différences qui ne sont pas importantes pour l'utilisateur final, et surtout si toutes les variantes sauf une sont destinées à votre propre utilisation de test et de développement et qu'une seule variante sera déployée sur utilisateurs finaux, alors c'est un bon candidat pour les types de build. S'il s'agit d'une application «différente» et que plusieurs variantes seraient déployées auprès des utilisateurs, alors c'est peut-être un candidat pour une saveur de produit.

Vous avez déjà vu qu'il existe des différences de fonctionnalités entre les types de build et les versions, en ce sens que certaines options sont prises en charge pour l'un mais pas pour l'autre. Mais les concepts sont différents même s'ils sont similaires, et il n'est pas prévu de les fusionner.

buildType configurer la façon dont nous emballons notre application

• rétrécirRessources
• progaurdFile
• etc.

Flavor configure différentes classes et ressources.

• dans Flavor1 votre MainActivity peut faire quelque chose, et dans Flavor2 une implémentation différente

• Nom de l'application différent

• etc.

Chaque saveur de produit peut avoir ses propres valeurs des propriétés suivantes, entre autres, qui sont basées sur les mêmes propriétés de defaultConfig:

• applicationId
• minSdkVersion
• targetSdkVersion
• versionCode
• versionName

Voici comment je distille la différence jusqu'à son essence:

• buildTypeest le comment de la construction.
• flavorest le quoi de la construction.

Les build typessont utilisés pour indiquer le debug/releasemode avec différents certificats et activation Proguardou debuggableindicateur.

Ils flavorssont utilisés pour avoir des fonctionnalités personnalisées (par exemple, une version gratuite ou payante), des minimum and target APIniveaux, des exigences en matière d'appareil et d'API comme le layout, drawableafin que vous puissiez avoir différents codes et ressources dans différents flavors.