謎：Android Studioのプロジェクト構造とビルドシステム
これがGradleビルドシステムのせいかどうかはわかりませんが（賭けます）、これまでに理解したことをお話しします。
アップデート4： 2014年9月11日を追加しましたカンニングペーパーのためにBuildTypes、FlavorsとVariants（私は最終的に、この書き込みが自信：D）の
アップデート3： 2014年9月11日には、正確には比較のワークスペースとプロジェクトを更新
アップデート2： 2014年4月17日ASプロジェクト構造Update 1に詳細を追加
： 2013/07/29 IntelliJプロジェクト構造を追加しました
IntelliJのプロジェクト構造（最後に表示）は、androidプラグインを備えたIntelliJ用です。ただし、Android Studioには、次のように分割されたプロジェクト構造があります。
構造：プロジェクトとモジュール
モジュール内のAndroid Studioは似ているプロジェクトでのEclipse
プロジェクト内のAndroid Studioは、のようなものである、ワークスペース内のEclipse（正確には、相互に依存するプロジェクトを持つワークスペース）
ドキュメントから（Android StudioはIntellij IDEAに基づいています）：
IntelliJ IDEAで行うことは何でも、プロジェクトのコンテキストで行います。プロジェクトは、完全なソフトウェアソリューションを表す組織単位です。
完成した製品は、一連の個別の独立したモジュールに分解される可能性がありますが、それらをまとめてより大きな全体に結びつけるのはプロジェクト定義です。
Androidの場合、アプリごとに1つのプロジェクト、ライブラリごと、およびテストアプリごとに1つのモジュールを意味します。
同じプロジェクト内で複数のアプリをビルドしようとすると、複数の問題があります。それは可能ですが、試してみると（私のように）、ほとんどすべてがプロジェクトごとに1つのアプリで動作するように設計されていることがわかります。
たとえば、「プロジェクトを再構築」するオプションがあります。これは、複数のアプリでは意味がなく、他の多くのプロジェクト設定は役に立たず、複数のリポジトリがある場合、組み込みのVCSシステムは適切ではありません。
構造：フォルダー構造
トップレベルのフォルダー
1.主なプロジェクト
これはプロジェクト全体のコンテキストになります（Eclipse Land：ワークスペースと同様ですが、プロジェクトに関連するものに限定されます）。例：指定しHelloWorldProjectたアプリケーションの名前がHelloWorld
2. .idea
これは、プロジェクト固有のメタデータがAndroid Studio（AS）によって格納される場所です。（Eclipse Land： project.propertiesファイル）
3.プロジェクトモジュール
これが実際のプロジェクトです。例：指定したHelloWorldアプリケーション名がHelloWorldの場合
4.グラドル
これは、gradleビルドシステムのjarラッパーです。つまり、このjarは、ASがWindows（私の場合はOS）にインストールされているgradleと通信する方法です。
5.外部ライブラリ
これは実際にはフォルダーではなく、参照ライブラリ（Eclipse Land： Referenced Libraries）が表示される場所です。ここにターゲットプラットフォームなどが表示されます。
[ 補足： Eclipse Landの多くの人が、参照されたライブラリを削除し、参照エラーを修正するためにプロジェクトプロパティを修正していたのを覚えていますか？]
プロジェクトフォルダーの詳細
これは、上記のリストの＃3です。次のサブディレクトリがあります
1.ビルド
これは、makeプロセスのすべての完全な出力、つまり、classes.dex、コンパイルされたクラスとリソースなどを持っています。
Android Studio GUIでは、いくつかのフォルダーのみが表示されます。重要な部分は、ということであるあなたのR.javaがここに発見されたの下でbuild/source/<flavor>/r/<build type(optional)>/<package>/R.java
2. libs
これは、Eclipseの土地にも表示される標準のlibsフォルダーです。
3. src
ここでは、Eclipse Landのフォルダーとフォルダーに対応するjavaおよびresフォルダーのみが表示されます。これは、IMHOで大いに歓迎される簡略化です。srcres
モジュールに関する注意：
モジュールはEclipse Landに似ていますプロジェクトにます。ここでの考え方は、1つのアプリケーションプロジェクト（上記のリストのモジュール＃3）と、アプリケーションプロジェクトが依存する複数のライブラリプロジェクト（グローバルプロジェクトフォルダーの下の個別のモジュール（上記のリストの＃1）として）があるということです。これらのライブラリプロジェクトを他のアプリケーションでどのように再利用できるかについては、まだわかりません。
[ 補足：全体の再編成には、srcフォルダーの簡素化などのいくつかの利点がありますが、非常に複雑です。合併症は主に起因している非常に非常にこの新しいプロジェクトのレイアウト上の薄いマニュアルを参照してください。]
新しいビルドシステム
新しいビルドシステムのユーザーガイド
フレーバーやビルドタイプなどの説明-ハラハラとは何ですか？
フレーバーとビルドタイプのチートシート
BuildType： debugおよびreleaseはbuildTypes、デフォルトですべてのプロジェクトで使用できます。これらは、同じコードをビルド/コンパイルしてさまざまなAPKを生成するためのものです。たとえば、releaseAPKで（難読化のために）proguardを実行し、（デバッグキーに対して）キーで署名し、最適化を実行（多分proguardまたは他のツールを介して）、わずかに異なるpackageNames（com.company.productfor releaseとcom.company.product.debugforで使用debug）を使用します。またBuildConfig.DEBUG、releaseビルド時にログフラグへのロギングをオフにする（アプリが遅くなるため）ために、デバッグフラグ（）も使用します。これにより、debug開発中のビルドが高速になりますが、releasePlayストアに配置するための最適化されたビルドも可能になります。
製品のフレーバー：デフォルトのフレーバーはありません（正確には、デフォルトのフレーバーは空白/名前なしです）。彼らは異なるコードを持っている無料版または有料版であるFlavors可能性があります。それらは同じコードを共有しますが、いくつかのソースコードファイルまたはリソースの異なるバージョン（またはバージョンなし）を共有します。Main
BuildVariant： A buildVariantは、生成されたAPKが実際に対応するものです。それらはそのように（順番に）Product Flavor+ Build Type=のBuild Variantように命名されます。
例1：あなたが持っている場合freeと、paid2つの種類など。入手できるビルドバリアントは次のとおりです。
無料-無料デバッグ
-
有料リリース-
有料デバッグ-リリース
つまり、4つの可能なAPK構成です。いくつかの構成は特定のプロジェクトでは意味をなさない場合がありますが、それらは利用可能です。
例2：（新しいプロジェクトの場合/フレーバーなし）buildVariantsデフォルトのフレーバーは名前なし/空白であるため、2 個またはAPKを使用できます：
デバッグ
リリース
.idea（1）フォルダーには、主に内部IntelliJ IDEA情報を含む多数のサブフォルダーが含まれています。
src（2）フォルダーには、アプリケーションの機能を実装するMyActivity.java （3）ファイルのソースコードが含まれています。ファイルはcom.exampleパッケージに属しています。
res（4）フォルダーには、さまざまなビジュアルリソースが含まれています。
layout / main.xmlファイル（5）は、さまざまなタイプのリソースで構成されるアプリケーションの外観を定義します。
値フォルダー（6）は、さまざまなタイプのリソースを記述する.xmlファイルを格納するためのものです。現在、フォルダーにはStringリソース定義を含むstrings.xmlファイルが含まれています。「色の追加」セクションからわかるように、レイアウトフォルダーには、たとえば、色の記述子を含めることもできます。
ドローアブルフォルダー（7）には画像が含まれています。
gen（8）フォルダーには、ビジュアルリソースとJavaソースコードをリンクするR.java（9）ファイルが含まれています。以下のセクションからわかるように、IntelliJ IDEAは静的リソースとR.java間の緊密な統合をサポートしています。リソースが追加または削除されるとすぐに、R.javaの対応するクラスおよびクラスフィールドが自動的に生成または削除されます。R.javaファイルもcom.exampleパッケージに属しています。
