Warum unterscheiden sich Build-Typen von Produktaromen?

Vorwort: Dies ist keine Frage zur Verwendung von Build-Typen und Produktvarianten in einer Android-App. Ich verstehe die grundlegenden Konzepte. Bei dieser Frage geht es eher darum zu verstehen, welche Konfiguration in einem Build-Typ angegeben werden soll, welche Konfiguration in einer Produktvariante angegeben werden soll und ob tatsächlich eine Unterscheidung erforderlich ist.

Diese Woche habe ich mehr über die Gradle-Konfiguration für Android-Apps gelernt. Anfangs dachte ich, ich hätte einen guten Überblick über Build-Typen und Produktaromen, aber je tiefer ich in die Dokumentation einstieg, desto mehr wurde mir klar, dass mir die Unterscheidung zwischen beiden überhaupt nicht klar war.

Da es eine genau definierte Hierarchie gibt (in dem Sinne, dass die in Build-Typen angegebenen Eigenschaften Vorrang vor den in Produktvarianten angegebenen haben), verstehe ich nicht, warum überhaupt zwischen Build-Typen und Produktvarianten unterschieden werden muss. Wäre es nicht besser, alle Eigenschaften und Methoden in das DSL-Objekt für die Produktvariante einzufügen und dann den Build-Typ als (Standard-) Flavour-Dimension zu behandeln?

Einige konkrete Beispiele, die zu meiner Verwirrung geführt haben:

• Die signingConfigEigenschaft kann sowohl in Build-Typen als auch in Produktvarianten festgelegt werden ... aber minifyEnabled(und ich nehme an , shrinkResources?) Kann nur in Build-Typen konfiguriert werden.

• applicationIdkann nur in Produktvarianten angegeben werden ... und applicationIdSuffixkann nur in Build-Typen angegeben werden!?

Die eigentliche Frage (n) :

In Anbetracht der obigen Beispiele: Gibt es eine klare Unterscheidung zwischen den Rollen von Build-Typen und Produktaromen?

Wenn ja, wie kann man das am besten verstehen?

Wenn nicht, ist geplant, Build-Typen und Produktvarianten schließlich in einem einzigen konfigurierbaren DSL-Objekt zusammenzuführen?

Wenn Sie die Aussagen von @CommonsWare in den Kommentaren erweitern, besteht die Grundidee darin, dass Build-Typen für verschiedene Builds Ihrer Anwendung gelten, die funktional nicht unterschiedlich sind. Wenn Sie eine Debug- und Release-Version Ihrer App haben, handelt es sich um dieselbe App , aber einer enthält Debugging-Code, möglicherweise mehr Protokollierung usw., und der andere ist optimiert und optimiert und möglicherweise über ProGuard verschleiert. Mit Aromen ist die Absicht, dass die App in irgendeiner Weise deutlich anders ist. Das klarste Beispiel wäre eine kostenlose oder eine kostenpflichtige Version Ihrer App. Entwickler können jedoch auch danach unterscheiden, wo sie verteilt wird (was sich auf die Verwendung der In-App-Abrechnungs-API auswirken kann).

Es gibt Entwickler, die viele, viele verschiedene Versionen einer ähnlichen App für verschiedene Kunden erstellen - ein Beispiel könnte eine einfache App sein, die eine Webseite in einer Webansicht mit unterschiedlichen URLs und Branding für jede Version öffnet - dies ist eine gute Verwendung von Aromen.

Um es noch einmal zu wiederholen: Wenn es sich um "dieselbe Anwendung" handelt, modulieren Sie einige Unterschiede, die für den Endbenutzer nicht wichtig sind, und insbesondere, wenn alle Varianten außer einer für Ihren eigenen Test- und Entwicklungszweck bestimmt sind und nur eine Variante bereitgestellt wird Endbenutzer, dann ist es ein guter Kandidat für Build-Typen. Wenn es sich um eine "andere" Anwendung handelt und mehrere Varianten für Benutzer bereitgestellt werden, ist dies möglicherweise ein Kandidat für eine Produktvariante.

Sie haben bereits gesehen, dass es einige Funktionsunterschiede zwischen Build-Typen und Varianten gibt, da einige Optionen für die eine, aber nicht für die andere unterstützt werden. Aber die Konzepte sind unterschiedlich, obwohl sie ähnlich sind, und es gibt keinen Plan, sie zusammenzuführen.

buildType konfiguriert, wie wir unsere App verpacken

• shrinkResources
• progaurdFile
• etc.

Flavour konfiguriert verschiedene Klassen und Ressourcen.

• In Flavor1 kann Ihre MainActivity etwas tun und in Flavor2 eine andere Implementierung

• App-Name unterscheiden

• etc.

Jedes Produktaroma kann seine eigenen Werte haben, unter anderem der folgenden Eigenschaften, die auf denselben Eigenschaften basieren wie defaultConfig:

• applicationId
• minSdkVersion
• targetSdkVersion
• versionCode
• versionName

So destilliere ich den Unterschied auf das Wesentliche:

• buildTypeist das Wie des Builds.
• flavorist das was des Builds.

Die build typeswerden verwendet, um den debug/releaseModus mit verschiedenen Zertifikaten und Aktivierungen Proguardoder debuggableFlags anzuzeigen .

Diese flavorswerden verwendet, um benutzerdefinierte Funktionen (z. B. kostenlose oder kostenpflichtige Version), minimum and target APIEbenen, Geräte- und API-Anforderungen wie die zu haben layout, drawablesodass Sie unterschiedliche Codes und Ressourcen in unterschiedlichen Funktionen haben können flavors.