Android Studio项目结构（v.s. Eclipse Project Structure） [英] Android Studio Project Structure (v.s. Eclipse Project Structure)
问题描述
我正在尝试学习Android开发，而我最初被Eclipse和Android Studio之间的不同项目结构所困惑。这使得很难遵循为Eclipse设计的教程。有谁能让我知道为什么这些差异存在吗？是否存在？
例如，如果要在两个不同的IDE中找到R.java文件，路径将如下所示：
Eclipse： app \gen\com.example.app\R.java
Android Studio： app\build\source\r/\\debug\com.example.app\R.java
为什么这些路径不同？为什么我的R.java位于Android Studio的调试文件夹中？这会在早期导致一些错误，如果有人对这些差异有任何洞察，我将不胜感激。
这个奥秘：Android Studio的项目结构和构建系统
我不知道这是因为Gradle Build System（我会赌注），但是我会告诉你我迄今为止所了解的。
更新4： 2014/09/11为 BuildTypes ，添加作弊表 和变体（我终于有信心写道：D）
更新3： 2014/09/11更新了比较工作空间和项目以确定
更新2： 2014/04/17向AS项目结构添加更多详细信息
更新1： 2013/07/29添加IntelliJ项目结构
IntelliJ的项目结构（最后显示）适用于IntelliJ与android插入。但是，Android Studio的项目结构如下所示：
结构：项目和模块
< Android Studio 中的p> 项目类似于 Eclipse 中的工作区（确切地说，具有相互依赖项目的工作区）
从
口味和buildTypes等的说明 - 什么是hullabaloo？
口味的CheatSheet和buildTypes
BuildType： debug 和 code>是所有项目默认可用的$ code> buildTypes 。它们用于构建/编译同一代码以生成不同的APK。例如，在发布 APK你会想要运行proguard（用于混淆），用你的密钥（与调试键一样）进行签名，运行优化（可能是通过proguard或其他工具），使用稍微不同的 packageNames （我们使用 com.company.product release 和 com.company.product.debug for debug ）等等。我们还使用调试标志（ BuildConfig.DEBUG ）关闭日志记录到logcat（因为它使应用程序变慢）在发布 builds 。这使得在开发过程中更快的调试构建，而且还可以将优化的版本版本放在播放存储上。
产品味道：没有默认的口味可用（或者确切的说，默认味道是空白/无名）。 Flavors 可以是免费版或付费版，他们拥有不同的代码。他们共享相同的主要代码，但不同的版本（或没有版本）的几个源代码文件或资源。
BuildVariant：一个 buildVariant 是一个生成的APK实际对应的。他们被命名为（按顺序） 产品风味 + 构建类型 = 建立变体 。
示例1：如果您有免费和付款作为两种口味。您将获得的构建变体是：
免费 - 调试
免费 - 发布
付费 - 调试
付费 - 发布
这是4种可能的APK配置。一些配置在某个项目中可能没有意义，但是可用。
示例2：对于新项目/没有味道）您有2个 buildVariants 或APK可用，因为默认风味是无名/空白：
debug
发布
将此与 Intellij的项目进行比较结构如果这有帮助：
.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）文件夹包含连接可视资源的 R.java（9） Java源代码。从下面的部分可以看出，IntelliJ IDEA支持静态资源和R.java之间的紧密集成。一旦添加或删除任何资源，就会自动生成或删除R.java中的相应类和类字段。 R.java文件也属于com.example包。
I'm trying to learn android development and I am initially confused by the different project structures between Eclipse and Android Studio. This makes it difficult to follow tutorials designed for Eclipse. Could anyone let me know why these differences exist? Should they exist?
For instance, if I were to locate the R.java file in the two different IDEs, the paths would look like this:
Eclipse: app\gen\com.example.app\R.java
Android Studio: app\build\source\r\debug\com.example.app\R.java
Why are these paths different? Why is my R.java located in a debug folder in Android Studio? This lead to some errors early on, and if anyone has any insight into these differences I would appreciate them.
The mystery: Android Studio's Project Structure and Build System
I don't know if this is because of the Gradle Build System (I'd wager it is), but I'll tell you what I've understood so far.
Update 4: 2014/09/11 Added Cheat Sheet for BuildTypes, Flavors and Variants(I finally feel confident to write this :D)
Update 3: 2014/09/11 Updated the comparison workspaces and projects to be precise
Update 2: 2014/04/17 Added more detail to AS project structure
Update 1: 2013/07/29 Added IntelliJ Project Structure
The IntelliJ's Project structure (shown at the end) is for IntelliJ with the android plugin. The Android Studio, however, has a project structure divided like so:
Structure: Projects and Modules
module in Android Studio is like a project in Eclipse
project in Android Studio is like a workspace in Eclipse (to be precise, a workspace with interdependent projects)
From the documentation (Android Studio is based on Intellij IDEA) :
Whatever you do in IntelliJ IDEA, you do that in the context of a project. A project is an organizational unit that represents a complete software solution.
Your finished product may be decomposed into a series of discrete, isolated modules, but it's a project definition that brings them together and ties them into a greater whole.
For Android, it means one project per app, and one module per library and per test app.
There are multiple issues if you try to build multiple apps within the same project. It's possible, but if you try (like I did), you will see that almost everything is designed to work with a single app per project.
For example, there is an option to "rebuild the project", which makes no sense with multiple apps, many other project settings would be useless, and the built-in VCS system isn't great when you have multiple repositories.
Structure: Folder Structure
Top Level Folders
1. Main Project
This would be entire project context (Eclipse Land: Like your workspace but limited to what's relevant to your project). Ex: HelloWorldProject if the name of the application you gave was HelloWorld
2. .idea
This where project specific metadata is stored by Android Studio (AS). (Eclipse Land: project.properties file)
3. Project Module
This is the actual project. ex: HelloWorld if your application name you gave was HelloWorld
4. gradle
This is where the gradle build system's jar wrapper i.e. this jar is how AS communicates with gradle installed in Windows (the OS in my case).
5. External Libraries
This is not actually a folder but a place where Referenced Libraries (Eclipse Land: Referenced Libraries) are shown. Here's where the Targeted Platform is shown etc.
[Side note: This where many of us in Eclipse Land used to delete the referenced libraries and Fix Project Properties to fix reference errors, remember?]
Project Folder in Detail
This is number #3 in the above list. Has the following sub dirs
1. build
This has all the complete output of the make process i.e. classes.dex, compiled classes and resources, etc.
In the Android Studio GUI, only a few folders are shown. The important part is that your R.java is found here under build/source/<flavor>/r/<build type(optional)>/<package>/R.java
2. libs
This is the standard libs folder that you see in eclipse land too
3. src
Here, you only see the java and res folder which correspond to the src folder and res folder in Eclipse Land. This is much welcomed simplification IMHO.
Note on Modules:
Modules are like Eclipse Land projects. Here the idea is that you have one application project (Module #3 in the list above) and several library projects(as separate Modules under the global project folder (#1 in the above list)) which the application project depends on. How these library projects can be re-used in other applications, I still haven't found out.
[Side note: The whole re-organization has some benefits like simplifications in src folder, but so many complications. The complications are mainly due VERY VERY thin documentation on this new project layout.]
The New Build System
User Guide for the new Build System
Explanation of flavors and buildTypes, etc - What is the hullabaloo about?
CheatSheet for flavors and buildTypes
BuildType: debug and release are buildTypes available by default on all projects. They are for building/compiling the SAME CODE to generate different APKs. For example on release APKs you would want to run proguard(for obfuscation), sign it with your key (as against the debug key), run optimizations (maybe via proguard or other tools), use slightly different packageNames (we use com.company.product for release and com.company.product.debug for debug), etc. We also use a debug flag (BuildConfig.DEBUG) to turn off logging to logcat (since it makes the app slow) on release builds. This makes for a faster debug build during development but also an optimized release build to put on play store.
Product Flavor: There are no default flavors available (or to be precise, the default flavor is blank/nameless). Flavors could be free version or paid version where they have DIFFERENT CODE. They share the same Main Code but different versions(or no versions) of a few source code files or resources.
BuildVariant: A buildVariant is what a generated APK actually corresponds to. They are named like so (in order) Product Flavor + Build Type = Build Variant.
Example 1: if you have free and paid as two flavors. The build variants you would get are:
Free - debug
Free - release
Paid - debug
Paid - release
So that is 4 possible APK configurations. A few configurations may not make sense in a particular project, but they are available.
Example 2: (for new projects/ no flavors) You have 2 buildVariants or APKs available, since the default flavor is nameless/blank:
debug
release
Compare this with Intellij's Project Structure if that helps:
The .idea (1) folder contains a number of subfolders, mainly with internal IntelliJ IDEA information.
The src (2) folder contains the MyActivity.java (3) file source code that implements the functionality of your application. The file belongs to the com.example package.
The res (4) folder contains various visual resources.
The layout/main.xml file (5) defines the appearance of the application constituted of resources of various types.
The values folder (6) is intended for storing .xml files that describe resources of various types. Presently, the folder contains a strings.xml file with String resources definitions. As you will see from the Adding a Color section, the layout folder can also contain, for example, a descriptor of colors.
The drawable folder (7) contains images.
The gen (8) folder contains the R.java (9) file that links the visual resources and the Java source code. As you will see from the sections below, IntelliJ IDEA supports tight integration between static resources and R.java. As soon as any resources are added or removed, the corresponding classes and class fields in R.java are automatically generated or removed accordingly. The R.java file also belongs to the com.example package.
这篇关于Android Studio项目结构（v.s. Eclipse Project Structure）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
