Dlaczego typy kompilacji różnią się od smaków produktów?

Przedmowa: nie chodzi o to, jak używać typów kompilacji i smaków produktów w aplikacji na Androida. Rozumiem podstawowe pojęcia. To pytanie dotyczy raczej próby zrozumienia, która konfiguracja powinna być określona w typie kompilacji, którą konfigurację należy określić w smaku produktu i czy jakiekolwiek rozróżnienie jest rzeczywiście konieczne.

W tym tygodniu dowiedziałem się więcej o konfiguracji Gradle dla aplikacji na Androida. Początkowo myślałem, że dobrze radzę sobie z typami kompilacji i smakami produktów, ale im głębiej zagłębiałem się w dokumentację, tym bardziej zdawałem sobie sprawę, że rozróżnienie między nimi nie jest dla mnie jasne.

Ponieważ istnieje dobrze zdefiniowana hierarchia (w tym sensie, że właściwości określone w typach kompilacji mają pierwszeństwo przed właściwościami określonymi w smakach produktów), nie rozumiem, dlaczego w ogóle istnieje potrzeba rozróżnienia między typami kompilacji i smakami produktów. Czy nie byłoby lepiej scalić wszystkie właściwości i metody w obiekt DSL smaku produktu, a następnie po prostu potraktować typ kompilacji jako (domyślny) wymiar smaku?

Kilka konkretnych przykładów, które doprowadziły do ​​mojego zamieszania:

• signingConfigNieruchomość może być ustawiony w obu typach budować i smaków produktów ... ale minifyEnabled(i, przypuszczam, shrinkResources?) Może być skonfigurowane tylko w rodzaju kompilacji.

• applicationIdmożna określić tylko w smakach produktu ... i applicationIdSuffixmożna to określić tylko w typach kompilacji !?

Rzeczywiste pytania :

Biorąc pod uwagę powyższe przykłady: czy istnieje wyraźne rozróżnienie między rolami typów kompilacji a smakami produktów?

Jeśli tak, to jak najlepiej to zrozumieć?

Jeśli nie, czy planowane jest ostateczne scalenie typów kompilacji i smaków produktów w jeden konfigurowalny obiekt DSL?

Rozwijając to, co @CommonsWare powiedział w komentarzach, podstawową ideą jest to, że typy kompilacji są przeznaczone dla różnych kompilacji aplikacji, które nie różnią się funkcjonalnie - jeśli masz wersję debugowania i wydania aplikacji, są to ta sama aplikacja , ale jeden zawiera kod do debugowania, może więcej rejestrowania itp., a drugi jest usprawniony i zoptymalizowany oraz prawdopodobnie zaciemniony przez ProGuard. W przypadku smaków intencją jest to, że aplikacja różni się w jakiś sposób. Najlepszym przykładem może być bezpłatna i płatna wersja Twojej aplikacji, ale programiści mogą również różnicować w zależności od tego, gdzie jest dystrybuowana (co może wpłynąć na użycie interfejsu API rozliczeń w aplikacji).

Są programiści, którzy tworzą wiele, wiele różnych wersji podobnej aplikacji dla różnych klientów - przykładem może być prosta aplikacja, która otwiera stronę internetową w widoku internetowym, z różnymi adresami URL i oznaczeniami marki dla każdej wersji - jest to dobre wykorzystanie smaków.

Powtórzę, jeśli jest to „ta sama aplikacja”, pomodulo niektóre różnice, które nie są ważne dla użytkownika końcowego, a zwłaszcza jeśli wszystkie warianty oprócz jednego są przeznaczone do własnych celów testowych i programistycznych, a tylko jeden wariant zostanie wdrożony w użytkowników końcowych, to dobry kandydat do typów kompilacji. Jeśli jest to „inna” aplikacja, a użytkownikom zostanie wdrożonych wiele wariantów, być może jest to kandydat na smak produktu.

Widzieliście już, że istnieją pewne różnice funkcjonalne między typami kompilacji i smakami, ponieważ niektóre opcje są obsługiwane dla jednego, ale nie dla drugiego. Ale koncepcje są różne, mimo że są podobne i nie ma planu ich łączenia.

buildType skonfiguruj sposób pakowania naszej aplikacji

• shrinkResources
• progaurdFile
• itp.

Flavor konfiguruje różne klasy i zasoby.

• w Flavor1 twoja MainActivity może coś zrobić, aw Flavor2 inna implementacja

• inna nazwa aplikacji

• itp.

Każdy smak produktu może mieć swoje własne walory, między innymi, oparte na tych samych właściwościach z defaultConfig:

• applicationId
• minSdkVersion
• targetSdkVersion
• versionCode
• versionName

Oto jak wyodrębniam różnicę do jej istoty:

• buildTypejest jak z kompilacją.
• flavorto co z kompilacją.

build typesSą używane, aby wskazać debug/releasetryb za pomocą różnych certyfikatów i umożliwienie Proguardlub debuggableflagi.

flavorsSłużą mieć niestandardowe funkcje (na przykład wolnego lub wersja płatna), minimum and target APIpoziomy, urządzeń i API Wymagania lubią layout, drawablewięc można mieć inny kod i zasoby w różny flavors.