Descripción general de la compilación de Gradle

Las aplicaciones para Android generalmente se compilan con la compilación de Gradle en un sistema de archivos. Antes de entrar en los detalles para configurar tu compilación, explorarás los conceptos en los que se basa la compilación para ver el sistema como un todo.

¿Qué es una construcción?

Un sistema de compilación transforma tu código fuente en una aplicación ejecutable. Las compilaciones suelen implicar varias herramientas para analizar, compilar, vincular y empaquetar una aplicación o biblioteca. Gradle usa un enfoque basado en tareas para organizar y ejecutar estos comandos.

Las tareas encapsulan los comandos que traducen sus entradas a de salida. Los complementos definen tareas y su configuración. Aplicando un complemento a tu compilación registra sus tareas y las conecta mediante su las entradas y salidas... Por ejemplo, aplicar el complemento de Android para Gradle (AGP) en tu archivo de compilación registrará todas las tareas necesarias para compilar un APK o un Biblioteca de Android El complemento java-library te permite compilar un archivo jar a partir de código fuente de Java. código. Existen complementos similares para Kotlin y otros lenguajes, pero otros complementos están diseñados para extender complementos. Por ejemplo, el complemento protobuf está diseñado para agregar Compatibilidad con protobuf con complementos existentes, como AGP o java-library.

Gradle prefiere la convención a la configuración, por lo que los complementos tendrán una buena valores predeterminados listos para usar, pero puedes seguir configurando la compilación mediante un lenguaje específico de dominio (DSL) declarativo. La DSL está diseñada así que puedes especificar qué compilar, en lugar de cómo. La lógica en de que los complementos administren el "cómo". Esa configuración se especifica en varios archivos de compilación en tu proyecto (y subproyectos).

Las entradas de tareas pueden ser archivos y directorios, al igual que otra información codificada como Tipos de Java (número entero, cadenas o clases personalizadas). Los resultados solo pueden ser directorios o archivos, ya que deben escribirse en un disco. Conecta la salida de una tarea a otra entrada de tarea, las vincula para que una deba ejecutarse antes que la otra.

Si bien Gradle admite la escritura de código arbitrario y declaraciones de tareas en tu compilación esto puede hacer que sea más difícil para las herramientas comprender tu compilación y que debes mantener. Por ejemplo, puedes escribir pruebas para código dentro de complementos pero no en los archivos de compilación. En cambio, debes restringir la lógica de compilación y la asignación declaraciones a complementos (que tú u otra persona definan) y declara cómo deseas usar esa lógica en tus archivos de compilación.

¿Qué sucede cuando se ejecuta una compilación de Gradle?

Las compilaciones de Gradle se ejecutan en tres fases. Cada una de estas fases ejecuta partes diferentes de código que defines en tus archivos de compilación.

• La inicialización determina qué proyectos y subproyectos se incluyen en la compilación y configura rutas de clase que contienen tus archivos de compilación y los o complementos. Esta fase se centra en un archivo de configuración en el que se declaran los proyectos a y las ubicaciones de las que recuperar complementos y bibliotecas.
• La configuración registra las tareas de cada proyecto y ejecuta la compilación para aplicar la especificación de compilación del usuario. Es importante entender que tu código de configuración no tendrá acceso a los datos o archivos producidos durante la ejecución.
• La ejecución realiza la "compilación" real. de tu aplicación. El resultado de la configuración es un grafo acíclico dirigido (DAG) de tareas, que representan todos los pasos de compilación requeridos que solicitó el usuario (el las que se proporcionan en la línea de comandos o como valores predeterminados en los archivos de compilación). Esta gráfico representa la relación entre las tareas, ya sea explícita en la secuencia o en función de sus entradas y salidas. Si una tarea tiene una entrada es el resultado de otra tarea, entonces debe ejecutarse después de la otra tarea. Esta ejecuta tareas desactualizadas en el orden definido en el gráfico; Si una tarea está no cambiaron desde la última ejecución, Gradle la omitirá.

Para obtener más información, consulta el ciclo de vida de la compilación de Gradle.

DSL de configuración

Gradle usa un lenguaje específico del dominio (DSL) para configurar compilaciones. Este enfoque declarativo se enfoca en especificar tus datos en lugar de escribir instrucciones paso a paso (imperativas).

Las DSL intentan facilitar a todos, desde los expertos en dominios, y a los programadores, de un proyecto, definiendo un pequeño lenguaje que representa datos en un de forma más natural. Los complementos de Gradle pueden extender el DSL para configurar los datos que necesitan para sus tareas.

Por ejemplo, la configuración de la parte de Android de tu compilación podría verse así:

Kotlin

android {
    namespace = "com.example.app"
    compileSdk = 34
    // ...

    defaultConfig {
        applicationId = "com.example.app"
        minSdk = 34
        // ...
    }
}

Groovy

android {
    namespace 'com.example.myapplication'
    compileSdk 34
    // ...

    defaultConfig {
        applicationId "com.example.myapplication"
        minSdk 24
        // ...
    }
}

En segundo plano, el código DSL es similar a lo siguiente:

fun Project.android(configure: ApplicationExtension.() -> Unit) {
    ...
}

interface ApplicationExtension {
    var compileSdk: Int
    var namespace: String?

    val defaultConfig: DefaultConfig

    fun defaultConfig(configure: DefaultConfig.() -> Unit) {
        ...
    }
}

Cada bloque del DSL está representado por una función que toma una lambda configurarlo y una propiedad con el mismo nombre para acceder a él. Esto hace que el el código en tus archivos de compilación se parece más a una especificación de datos.

Nota: Si te interesan los detalles que hacen que esto funcione en Kotlin, consulta Compiladores de tipo seguro. Para obtener más detalles sobre las DSL en general, consulta el libro Domain Specific Languages, de Martin Fowler y Rebecca Parsons.

Dependencias externas

El sistema de compilación de Maven introdujo una especificación de dependencia, y un sistema de administración y almacenamiento. Las bibliotecas se almacenan repositories (servidores o directorios), con metadatos que incluyen, su versión y dependencias en otras bibliotecas. Tú especificas en los que buscar, las versiones de las dependencias que quieres usar y el el sistema de compilación los descarga durante la compilación.

Los artefactos Maven se identifican por nombre de grupo (empresa, desarrollador, etc.), artefacto nombre (el de la biblioteca) y la versión de ese artefacto. Normalmente, esto es se representa como group:artifact:version.

Este enfoque mejora considerablemente la administración de la compilación. A menudo, escucharás de recursos llamados “repositorios de Maven”, pero se trata de la forma se empaquetan y publican los artefactos. Estos repositorios y metadatos reutilizados en varios sistemas de compilación, incluido Gradle (y Gradle puede publicar estos repositorios). Los repositorios públicos permiten compartirlas para que todos los usen. y los repositorios de la empresa mantienen las dependencias internas.

También puedes modularizar tu proyecto en subproyectos (también conocidos como "módulos" en Android Studio), que también se pueden usar como dependencias. Cada subproyecto produce resultados (como jars) que se pueden que consumen los subproyectos o el proyecto de nivel superior. Esto puede mejorar el tiempo de compilación mediante el aislamiento de las piezas que deben reconstruirse, así como la responsabilidades en la aplicación.

Analizaremos con más detalle cómo especificar dependencias en Cómo agregar una compilación las dependencias.

Variantes de compilación

Cuando creas una aplicación para Android, es recomendable que compiles varios variantes. Las variantes contienen un código diferente o se compilan con diferentes y se componen de tipos de compilación y variantes de productos.

Los tipos de compilación varían las opciones de compilación declaradas. De forma predeterminada, AGP configura la "versión" y "depurar" tipos de compilación, pero puedes ajustarlos y agregar más (tal vez para etapa de pruebas o pruebas internas).

Una compilación de depuración no minifica ni ofusca tu aplicación, lo que acelera su construir y preservar todos los símbolos tal como están. También se marca la aplicación como “depurable”, firmarla con una clave de depuración genérica y habilitar el acceso a la archivos de la aplicación instalada en el dispositivo. Esto permite explorar guardados en archivos y bases de datos mientras se ejecutaba la aplicación.

Una compilación de lanzamiento optimiza la app, la firma con tu clave de lanzamiento y protege los archivos de la aplicación instalada.

Con las variantes de productos, puedes cambiar la fuente incluida y la dependencia variantes de la aplicación. Por ejemplo, podrías crear "demostración" y "completo" de tipos para tu aplicación, o quizás "gratis" y "pagado" sabores. El código fuente común se escribe en una "principal" source set y anular o agregar la fuente a un conjunto de orígenes con el nombre del sabor.

AGP crea variantes para cada combinación de tipo de compilación y variante de producto. Si si no defines variantes, estas reciben los nombres de los tipos de compilación. Si definen ambos, la variante se llama <flavor><Buildtype>. Por ejemplo, con el método los tipos release y debug, y las variantes demo y full, AGP creará variantes:

• demoRelease
• demoDebug
• fullRelease
• fullDebug

Próximos pasos

Ahora que conoces los conceptos de compilación, consulta la página de compilación de Android básica en tu proyecto.