ビルドタイプが製品フレーバーと異なるのはなぜですか？

序文：これは、Androidアプリでビルドタイプと製品フレーバーを使用する方法についての質問ではありません。関連する基本的な概念を理解しています。この質問は、ビルドタイプで指定する必要がある構成、プロダクトフレーバーで指定する必要がある構成、および実際に区別が必要かどうかを理解しようとすることに関する詳細です。

今週は、AndroidアプリのGradle構成について詳しく学びました。私は当初、ビルドタイプと製品フレーバーの両方に優れていると思っていましたが、ドキュメントを深く掘り下げるほど、両者の違いがまったく明確ではないことに気付きました。

明確に定義された階層があるため（ビルドタイプで指定されたプロパティが製品フレーバーで指定されたプロパティよりも優先されるという意味で）、ビルドタイプと製品フレーバーをまったく区別する必要がある理由がわかりません。すべてのプロパティとメソッドを製品フレーバーDSLオブジェクトにマージし、ビルドタイプを（デフォルトの）フレーバーディメンションとして扱う方が良いでしょうか？

私の混乱を招いたいくつかの具体的な例：

• signingConfigプロパティは、ビルドの種類と製品の味の両方に設定することができます...しかし、minifyEnabled（と、私が想定し、shrinkResources？）のみビルドタイプに設定することができます。

• applicationId製品フレーバーでapplicationIdSuffixのみ指定できます... ビルドタイプでのみ指定できます！？

実際の質問：

上記の例を考えると、ビルドタイプと製品フレーバーの役割に明確な違いはありますか？

もしそうなら、それを理解するための最良の方法は何ですか？

そうでない場合、最終的にビルドタイプと製品フレーバーを単一の構成可能なDSLオブジェクトにマージする計画ですか？

コメントで@CommonsWareが言ったことを拡張すると、基本的な考え方は、ビルドタイプは機能的には異なるアプリケーションの異なるビルド用であるということです-アプリのデバッグバージョンとリリースバージョンがある場合、それらは同じアプリですですが、1つにはデバッグコード、さらに多くのログ記録などが含まれており、もう1つは合理化および最適化されており、おそらくProGuardによって難読化されています。フレーバーを使用すると、アプリが何らかの点で著しく異なることが意図されます。最も明確な例は、無料版と有料版のアプリですが、開発者はアプリの配布場所によっても異なる場合があります（アプリ内課金APIの使用に影響する可能性があります）。

さまざまな顧客向けに同じようなアプリの多くのさまざまなバージョンを作成している開発者がいます-たとえば、バージョンごとに異なるURLとブランドを使用して、WebビューでWebページを開くシンプルなアプリなどです-味を上手に使う。

繰り返しますが、それが「同じアプリケーション」である場合、エンドユーザーにとって重要ではないいくつかの違いをモジュロします。特に、1つを除くすべてのバリアントが独自のテストおよび開発用であり、1つのバリアントのみがエンドユーザーにとっては、ビルドタイプの候補として適しています。それが「異なる」アプリケーションであり、複数のバリアントがユーザーにデプロイされる場合は、おそらく製品フレーバーの候補です。

ビルドタイプとフレーバーの間にはいくつかの機能の違いがあることはすでに説明しました。一部のオプションは一方に対してのみサポートされ、もう一方に対してはサポートされません。しかし、概念は似ていても異なり、それらをマージする計画はありません。

buildTypeは、アプリのパッケージ方法を構成します

• shrinkResources
• 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。