私はアンドロイド開発を学ぼうとしていますが、EclipseとAndroid Studioのプロジェクト構造の違いに最初は戸惑っています。このため、Eclipse用にデザインされたチュートリアルに従うのが困難です。なぜこのような違いがあるのか、どなたか教えていただけませんか?また、このような違いは存在すべきなのでしょうか?
例えば、R.javaファイルを2つの異なるIDEで探すとすると、パスは次のようになります。
Eclipse: appgencom.example.app
Android Studio: appbuild
なぜこれらのパスが異なるのですか?なぜR.javaはAndroid Studioのdebugフォルダにあるのでしょうか?これは初期の段階でいくつかのエラーにつながりました。もし誰かがこれらの違いについて何か知っていれば、私はそれを感謝します。
Gradle Build Systemのせいなのかどうかは分かりませんが(というか、そうだろうと思う)、これまで理解できたことをお伝えします'します。
Update 4: 2014/09/11 BuildTypes
, Flavors
, Variants
の Cheat Sheet を追加しました(やっと書く自信がつきました:D)。
Update 3: 2014/09/11 比較ワークスペースとプロジェクトを正確に更新しました。
Update 2: 2014/04/17 ASプロジェクトの構造をより詳細に追加しました。
Update 1: 2013/07/29 IntelliJのプロジェクト構造を追加しました。
IntelliJ'sのプロジェクト構造(末尾に表示)は、IntelliJにandroidプラグインを入れた場合のものです。しかし、Android Studioでは、このようにプロジェクト構造が分割されています。
Android Studioのモジュールは、Eclipseのプロジェクトのようなものです。
Android Studioにおけるプロジェクトは、Eclipseにおけるワークスペースのようなものです(正確には、相互に依存するプロジェクトを持つワークスペースです)。
ドキュメント]1より(Android StudioはIntellij IDEAをベースにしています):
IntelliJ IDEAで行うことはすべて、プロジェクトのコンテキスト内で行うことになります。
プロジェクトのコンテキストで行います。プロジェクトとは、1つのソフトウェアソリューションを表す組織単位です。
プロジェクトは、完全なソフトウェアソリューションを表す組織単位です。
gt; プロジェクトは、完全なソフトウェアソリューションを表す組織単位です。
完成した製品は、一連の独立したモジュールに分解されるかもしれません。
しかし、それらを1つにまとめ、1つに結びつけるのがプロジェクトの定義です。
しかし、それらをまとめて、より大きな全体像に結びつけるのがプロジェクトの定義です。
Androidの場合、1アプリにつき1プロジェクト、1ライブラリにつき1モジュール、1テストアプリにつき1モジュールということになります。
同じプロジェクト内で複数のアプリを作ろうとすると、複数の問題が発生します。可能ですが、(私がやったように)やってみると、ほとんどすべてが1つのプロジェクトにつき1つのアプリで動作するように設計されていることがわかります。
例えば、quot;rebuild the project"というオプションがありますが、これは複数のアプリでは意味がありませんし、他の多くのプロジェクト設定は役に立ちませんし、内蔵のVCSシステムは複数のリポジトリがある場合には素晴らしいものではありません。
Android Studioのプロジェクト構造]2。
これは、プロジェクトコンテキスト (Eclipse Land: ワークスペースのようなものですが、プロジェクトに関連するものに限定されます) 全体となります。例:アプリケーション名が「HelloWorld」であれば、「HelloWorldProject」。
Android Studio (AS)がプロジェクト固有のメタデータを格納する場所です。 (Eclipse Land: project.properties
ファイル)
例:アプリケーション名がHelloWorldの場合、HelloWorld
となります。
gradleのビルドシステムのjarラッパーです。
これは実際にはフォルダではなく、参照するライブラリ(Eclipse Land: Referenced Libraries)が表示される場所です。ここには、Targeted Platformなどが表示されます。 (Side note:) Eclipse Landでは、ここで参照されているライブラリを削除し、参照エラーを修正するためにFix Project Propertiesを行っていた人が多かったことを覚えていますか?
これは上記のリストの3番です。以下のサブディレクトリがあります。
このディレクトリには、classes.dex、コンパイルされたクラスとリソースなど、make
プロセスのすべての完全な出力があります。
Android StudioのGUIでは、いくつかのフォルダーしか表示されません。重要なのは、あなたのR.javaは、 build/source/
これは、eclipse landで見る標準的なlibsフォルダです。
ここでは、Eclipse Land の src
フォルダと res
フォルダに相当する java
と res
フォルダのみが表示されます。これは非常に歓迎される簡素化です。
モジュールは、Eclipse Land のプロジェクトのようなものです。ここでは、1つのアプリケーションプロジェクト(上記リストのモジュール#3)と、アプリケーションプロジェクトが依存する複数のライブラリプロジェクト(グローバルプロジェクトフォルダ(上記リストの#1)下にある別のモジュールとして)があると考えます。これらのライブラリプロジェクトがどのように他のアプリケーションで再利用できるのか、私はまだ知りません。 [余談: この再編成は、srcフォルダの簡素化などの利点もありますが、非常に多くの複雑さがあります。この複雑さは、主にこの新しいプロジェクトレイアウトに関する 非常に 薄いドキュメントのせいです] 。
BuildType: debug
と release
は、すべてのプロジェクトでデフォルトで利用できる buildTypes
です。これらは異なるAPKを生成するために、SAME CODEをビルド/コンパイルするためのものです。例えば、release
のAPKでは、proguardを実行し(難読化のため)、あなたの鍵で署名し(debugの鍵に対して)、最適化を行い(proguardや他のツールで)、少し異なる packageNames
(release
では com.company.product
、debug
では com.company.product.debug
) などとしたいことでしょう。また、デバッグフラグ (BuildConfig.DEBUG
) を使用して、release
ビルドでは logcat へのロギング (アプリが遅くなるため) をオフにします。これにより、開発中のデバッグビルドが高速化されるだけでなく、Playストアにアップロードするリリースビルドも最適化されます。
Product Flavor: デフォルトのフレーバーはありません (正確には、デフォルトのフレーバーは空白/名前なしです)。フレーバーは、無料版と有料版があり、それぞれ異なるコードを持っています。メインコードは同じですが、いくつかのソースコードのファイルやリソースのバージョンが異なります(またはバージョンなし)。
BuildVariant: buildVariant
は、生成されたAPKが実際に対応するものです。順番に) Product Flavor
+ Build Type
= Build Variant
のように命名されます。
例1: 2つのフレーバーとして、free
とpaid
がある場合。この場合、ビルドバリアントは次のようになります。
フリー - デバッグ
フリー - リリース
有料版 - デバッグ
有料版 - リリース
以上、4つのAPKの構成が可能です。いくつかの構成は特定のプロジェクトでは意味をなさないかもしれませんが、それらは 利用可能 です。
例2: (新規プロジェクト/フレーバーなし) デフォルトのフレーバーが名無し/空白なので、2つの buildVariants
または APK が利用可能です。
デバッグ
リリース
Intellijのプロジェクト構造スナップショット]5。 .idea (1)フォルダには、主にIntelliJ IDEAの内部情報が格納されたサブフォルダが多数存在します。 src (2) フォルダーには、アプリケーションの機能を実装する MyActivity.java (3) ファイルのソースコード が含まれています。このファイルは com.example パッケージに属しています。 res (4) フォルダーには、さまざまなビジュアルリソースが含まれています。 layout/main.xmlファイル(5)は、様々な種類のリソースで構成されるアプリケーションの外観を定義します。 valuesフォルダ(6)は、各種リソースを記述した.xmlファイルを格納するためのフォルダです。現在、このフォルダには、Stringリソースを定義したstrings.xmlファイルが格納されています。色の追加」の項で説明したように、layout フォルダには、例えば、色の記述子を格納することもできます。 drawable フォルダ(7)には、画像が格納されています。 Gen (8) フォルダーには、ビジュアルリソースとJavaソースコードをリンクするR.java (9) ** ファイルが含まれています。以下のセクションからわかるように、IntelliJ IDEAは静的リソースとR.javaの間の緊密な統合をサポートしています。リソースの追加や削除が行われると、それに応じてR.javaの対応するクラスやクラスフィールドが自動的に生成・削除されます。R.javaファイルはcom.exampleパッケージにも属しています。
Android Studio: appbuildsource
なぜこのようにパスが違うのですか?なぜR.javaはAndroid Studioのdebugフォルダにあるのでしょうか?このため、序盤でエラーが出てしまいました。もし、この違いについてご存知の方がいらっしゃいましたら、教えていただければ幸いです。
簡単に言うと、Android Studioはシステム上でデバッグ用のBuild Typeをビルドするよう設定されています。
Eclipse/ADTは、一度に1つのビルドをサポートするように設計されています(私が知る限りでは)。新しいビルドシステムの主要な目標の1つです(ユーザーガイドより)。
Make it easy to create several variants of an application,
either for multi-apk distribution or for different flavors of an application
そのため、Eclipse/ADTでは1つの R.java
ファイルを生成できましたが、Android Studioでは複数の R.java
ファイルをサポートします。生成された R.java
は debug
フォルダーに置かれます。これは、新しいビルドシステムがデフォルトで debug
と release
ビルドタイプをサポートするためです。もし、ビルドバリアント(ASの左下にあるボタン)をreleaseに変更した場合、ASは R.java
を release
ディレクトリに生成します。
これは単純なプロジェクトでは意味がないかもしれませんが、 Build Variants のサポートは、私が取り組んでいるプロジェクトを含む多くの開発者にとって、 ビルドプロセスの劇的な簡略化を意味します。
私たちのプロジェクトは、2つのビルドタイプ(デバッグとリリース)を持つ4つのフレーバーをサポートしており、合計8つの異なるAPKの組み合わせをサポートしています。そして、それらの組み合わせはそれぞれ微妙に異なる構成を持っているので、このビルドシステムは私たちにとって本当にうまくいったのです。私のアンドロイドスタジオは別のマシンにインストールされていますが、記憶が正しければ R.java
ファイルは build/source/<flavor>/r/<build type>/package/R.java
に存在しています。CIサーバーがAPKファイルをビルドするとき、これらの R.java
ファイルをそれぞれ使用して個別のパッケージを生成します。
Google、Android Developer Toolsの【サポート終了のお知らせ】1。 (ADT)のEclipseでのサポートが終了することが、アナウンスされました。アプリ開発プロジェクトは アプリ開発プロジェクトは、できるだけ早くAndroid Studioに移行してください。 Android Studioへの移行の詳細については、「Android Studioへの移行 Android Studioへの移行をご覧ください。
*Android M]3に対応したAndroid開発ツールは、Android Studioのみとなります ---。