Estoy tratando de aprender sobre el desarrollo de Android e inicialmente estoy confundido por las diferentes estructuras de proyectos entre Eclipse y Android Studio. Esto dificulta seguir los tutoriales diseñados para Eclipse. ¿Alguien podría decirme por qué existen estas diferencias? ¿Deberían existir?

Por ejemplo, si tuviera que ubicar el archivo R.java en los dos IDE diferentes, las rutas se verían así:

Eclipse: aplicación \ gen \ com.example.app \ R.java

Android Studio: aplicación \ build \ source \ r \ debug \ com.example.app \ R.java

¿Por qué estos caminos son diferentes? ¿Por qué mi R.java está ubicado en una carpeta de depuración en Android Studio? Esto conduce a algunos errores desde el principio, y si alguien tiene alguna idea de estas diferencias, se lo agradecería.

El misterio: la estructura del proyecto y el sistema de compilación de Android Studio

No sé si esto se debe al sistema de compilación Gradle (apuesto a que sí), pero les diré lo que he entendido hasta ahora.

Actualización 4: 2014/09/11 Se agregó una hoja de referencia para BuildTypes, Flavorsy Variants(finalmente me siento seguro de escribir esto: D)
Actualización 3: 2014/09/11 Se actualizaron los espacios de trabajo y proyectos de comparación para que sean precisos
Actualización 2: 2014/04/17 Se agregaron más detalles a la estructura del proyecto AS
Actualización 1: 2013/07/29 Se agregó la estructura del proyecto IntelliJ

La estructura del proyecto de IntelliJ (que se muestra al final) es para IntelliJ con el complemento de Android. Android Studio, sin embargo, tiene una estructura de proyecto dividida así:

Estructura: Proyectos y Módulos

módulo en Android Studio es como un proyecto en Eclipse

proyecto en Android Studio es como un espacio de trabajo en Eclipse (para ser precisos, un espacio de trabajo con proyectos interdependientes)

De la documentación (Android Studio se basa en Intellij IDEA):

Hagas lo que hagas en IntelliJ IDEA, lo haces en el contexto de un proyecto. Un proyecto es una unidad organizativa que representa una solución de software completa.

Su producto terminado puede descomponerse en una serie de módulos discretos y aislados, pero es una definición de proyecto lo que los une y los une en un todo mayor.

Para Android, significa un proyecto por aplicación y un módulo por biblioteca y por aplicación de prueba.

Hay varios problemas si intenta crear varias aplicaciones dentro del mismo proyecto. Es posible, pero si lo intentas (como hice yo), verás que casi todo está diseñado para funcionar con una sola aplicación por proyecto.

Por ejemplo, hay una opción para "reconstruir el proyecto", lo que no tiene sentido con múltiples aplicaciones, muchas otras configuraciones del proyecto serían inútiles y el sistema VCS incorporado no es excelente cuando tiene múltiples repositorios.

Estructura: Estructura de carpetas

Carpetas de nivel superior

1. Proyecto principal

Este sería el contexto completo del proyecto ( Eclipse Land: como su espacio de trabajo pero limitado a lo que es relevante para su proyecto). Ej: HelloWorldProjectsi el nombre de la aplicación que dio fueHelloWorld

2. .idea

Aquí, donde Android Studio (AS) almacena los metadatos específicos del proyecto. ( Eclipse Land: project.properties archivo)

3. Módulo de proyecto

Este es el proyecto real. ej .: HelloWorldsi el nombre de su aplicación que dio fue HelloWorld

4. gradle

Aquí es donde el contenedor de jar del sistema de compilación gradle, es decir, este jar es cómo AS se comunica con gradle instalado en Windows (el sistema operativo en mi caso).

5. Bibliotecas externas

En realidad, esta no es una carpeta, sino un lugar donde se muestran las Bibliotecas referenciadas ( Eclipse Land: Bibliotecas referenciadas). Aquí es donde se muestra la plataforma dirigida, etc.

[ Nota al margen: aquí es donde muchos de nosotros en Eclipse Land solíamos eliminar las bibliotecas a las que se hace referencia y corregir las propiedades del proyecto para corregir errores de referencia, ¿recuerdas?]

Carpeta del proyecto en detalle

Este es el número 3 en la lista anterior. Tiene los siguientes subdirectores

1. construir

Esto tiene toda la salida completa del makeproceso, es decir, classes.dex, clases y recursos compilados, etc.

En la GUI de Android Studio, solo se muestran algunas carpetas. La parte importante es que tu R.java se encuentra aquí debajobuild/source/<flavor>/r/<build type(optional)>/<package>/R.java

2. libs

Se trata de las librerías estándar de carpetas que se ve en la tierra Eclipse demasiado

3. src

Aquí, solo verá la carpeta javay resque corresponde a la srccarpeta y la rescarpeta en Eclipse Land . Esta es una simplificación muy bienvenida en mi humilde opinión.

Nota sobre módulos:

Los módulos son como proyectos de Eclipse Land . Aquí la idea es que tenga un proyecto de aplicación (Módulo # 3 en la lista anterior) y varios proyectos de biblioteca (como Módulos separados bajo la carpeta del proyecto global (# 1 en la lista anterior)) de los cuales depende el proyecto de aplicación. Cómo estos proyectos de biblioteca se pueden reutilizar en otras aplicaciones, todavía no lo he descubierto.

[ Nota al margen: Toda la reorganización tiene algunos beneficios como simplificaciones en la carpeta src, pero muchas complicaciones. Las complicaciones se deben principalmente a una documentación MUY MUY delgada sobre este nuevo diseño de proyecto.]

El nuevo sistema de construcción

Guía del usuario para el nuevo sistema de compilación

Explicación de sabores y buildTypes, etc. - ¿De qué se trata el alboroto?

CheatSheet para sabores y buildTypes

BuildType: debug y releaseestán buildTypesdisponibles de forma predeterminada en todos los proyectos. Son para crear / compilar el MISMO CÓDIGO para generar diferentes APK. Por ejemplo, en los releaseAPK, le gustaría ejecutar proguard (para ofuscación), firmarlo con su clave (en comparación con la clave de depuración), ejecutar optimizaciones (tal vez a través de proguard u otras herramientas), usar un poco diferente packageNames(usamos com.company.productpara releasey com.company.product.debugpara debug), etc. También usamos un indicador de depuración ( BuildConfig.DEBUG) para desactivar el registro en logcat (ya que hace que la aplicación sea lenta) en las releasecompilaciones. Esto permite una debugcompilación más rápida durante el desarrollo, pero también una releasecompilación optimizada para poner en Play Store.

Sabor del producto: No hay sabores predeterminados disponibles (o para ser precisos, el sabor predeterminado es en blanco / sin nombre). Flavorspodría ser una versión gratuita o una versión de pago donde tengan CÓDIGO DIFERENTE . Comparten el mismo MainCódigo pero diferentes versiones (o ninguna versión) de unos pocos archivos de código fuente o recursos.

BuildVariant: A buildVariantes a lo que realmente corresponde un APK generado. Se nombran así (en orden) Product Flavor+ Build Type=Build Variant .
Ejemplo 1: si tiene freey paidcomo dos sabores. Las variantes de compilación que obtendría son:
Gratis - depuración
Gratis - lanzamiento
Pagado - depuración
Pagado - lanzamiento
Así que son 4 configuraciones de APK posibles. Algunas configuraciones pueden no tener sentido en un proyecto en particular, pero están disponibles.

Ejemplo 2: (para proyectos nuevos / sin sabores) Tiene 2 buildVariantso APK disponibles, ya que el sabor predeterminado es sin nombre / en blanco: versión de
depuración

Compare esto con la estructura del proyecto de Intellij si eso ayuda:

La carpeta .idea (1) contiene varias subcarpetas, principalmente con información interna de IntelliJ IDEA.

La carpeta src (2) contiene el código fuente del archivo MyActivity.java (3) que implementa la funcionalidad de su aplicación. El archivo pertenece al paquete com.example.

La carpeta res (4) contiene varios recursos visuales.

El archivo layout / main.xml (5) define la apariencia de la aplicación constituida por recursos de varios tipos.

La carpeta de valores (6) está destinada a almacenar archivos .xml que describen recursos de varios tipos. Actualmente, la carpeta contiene un archivo strings.xml con definiciones de recursos String. Como verá en la sección Agregar un color, la carpeta de diseño también puede contener, por ejemplo, un descriptor de colores.

La carpeta dibujable (7) contiene imágenes.

La carpeta gen (8) contiene el archivo R.java (9) que vincula los recursos visuales y el código fuente de Java. Como verá en las secciones siguientes, IntelliJ IDEA admite una estrecha integración entre los recursos estáticos y R.java. Tan pronto como se agregan o eliminan recursos, las clases y campos de clase correspondientes en R.java se generan o eliminan automáticamente en consecuencia. El archivo R.java también pertenece al paquete com.example.

Android Studio: aplicación \ build \ source \ r \ debug \ com.example.app \ R.java

¿Por qué estos caminos son diferentes? ¿Por qué mi R.java está ubicado en una carpeta de depuración en Android Studio? Esto conduce a algunos errores desde el principio, y si alguien tiene alguna idea de estas diferencias, se lo agradecería.

En pocas palabras, Android Studio está configurado para crear un tipo de compilación de depuración en su sistema.

Eclipse / ADT está diseñado para admitir una sola compilación a la vez (por lo que puedo decir). Uno de los objetivos principales del nuevo sistema de compilación ( de la guía del usuario ):

Make it easy to create several variants of an application, 
either for multi-apk distribution or for different flavors of an application

Entonces, como Eclipse / ADT podría generar un R.javaarchivo, Android Studio admite varios. El generada R.javase encuentra en la debugcarpeta ya que por defecto los nuevos soportes de sistemas de construcción debugy releasetipos de construcción del palo. Si cambió su variante de compilación (botón, esquina inferior izquierda de AS) para liberar AS se generará R.javaen el releasedirectorio.

Puede que esto no signifique nada para proyectos simples, pero el soporte de Build Variants significa una simplificación drástica del proceso de construcción para muchos desarrolladores, incluido el proyecto en el que estoy trabajando.

Nuestro proyecto admite 4 versiones con 2 tipos de compilación (depuración y lanzamiento), para admitir un total de 8 combinaciones de APK diferentes. Y cada una de esas combinaciones tiene configuraciones ligeramente diferentes, por lo que este sistema de construcción realmente funcionó para nosotros. Mi estudio de Android está instalado en una máquina diferente, pero si la memoria funciona correctamente, el R.javaarchivo existe en build/source/<flavor>/r/<build type>/package/R.java. Cuando nuestro servidor CI crea los archivos APK, utiliza cada uno de estos R.javaarchivos para generar paquetes separados.

Google Discontinuar el soporte para las herramientas de desarrollo de Android (ADT) en Eclipse está terminando, según nuestro anuncio. Debe migrar sus proyectos de desarrollo de aplicaciones a Android Studio lo antes posible. Para obtener más información sobre la transición a Android Studio, consulte Migración a Android Studio.

Por lo tanto, la mejor herramienta de desarrollo de Android para Android Studio solo para todo el soporte futuro de Android M ---

Para Android Studio 3.0.1 y seleccionó todas las funciones:

• Android O más reciente
• Android Auto
• Cosas de Android
• Desgaste de Android
• Android TV
• Soporte C ++
• Soporte de Kotlin

La estructura de la versión 3.0.1 no se parece en nada a todas las demás respuestas.

La estructura reciente es como se muestra en 2018, Android Studio 3.0.1 01/2018.

El novato encontró algo parecido a utilizable en la subcarpeta de funciones:

Actualice su Android Studio 3.0.1 01_2018:

Información sobre herramientas: