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
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.
