Android Studio por dentro

Android Studio parece un editor y no lo es. Es un cliente gráfico de tu sistema de construcción: no sabe qué clases existen, ni qué dependencias tienes, ni siquiera cuántos módulos hay, hasta que Gradle se lo cuenta. Entender esa relación —quién es la fuente de verdad y quién el espectador— explica de golpe el noventa por ciento de las rarezas del IDE: por qué el autocompletado desaparece, por qué una clase generada aparece en rojo, y por qué la solución nunca es reiniciar sino sincronizar.

Un IntelliJ con un modelo de proyecto prestado

Android Studio es IntelliJ IDEA Community más un conjunto de plugins de Google. Todo lo que hace el editor —resaltado, navegación, refactorización, análisis estático— proviene de un modelo de proyecto que el IDE no inventa: lo pide a Gradle ejecutando la fase de configuración del build. Eso es exactamente lo que ocurre durante un Gradle sync.

flowchart LR
A[Editas settings o build.gradle.kts] --> B[Gradle sync]
B --> C[Fase de configuracion del build]
C --> D[Modelo de proyecto del IDE]
D --> E[Indexado y resolucion de simbolos]
E --> F[Autocompletado y navegacion y refactor]
B --> G[Fallo de sync y el IDE usa un modelo viejo]
style D fill:#89b4fa,color:#11111b
style G fill:#f38ba8,color:#11111b

El corolario práctico es fuerte: cuando el IDE “no ve” algo que existe, casi nunca es un fallo del editor. Es un modelo desactualizado. Los ficheros que gobiernan ese modelo viven en la raíz y conviene conocerlos uno a uno.

Las dos vistas y dónde vive cada cosa

El desplegable superior del panel de proyecto ofrece varias vistas del mismo disco. La vista Android es una ficción útil: agrupa, esconde y reordena para que veas la aplicación. La vista Project muestra el árbol tal cual está en el sistema de ficheros. Trabaja en Android y cambia a Project en cuanto tengas una duda real.

app/
  build.gradle.kts
  src/
    main/                      # el conjunto de fuentes por defecto
      AndroidManifest.xml      # componentes, permisos, metadatos
      java/com/ejemplo/app/    # codigo Kotlin, aunque la carpeta se llame java
      res/                     # recursos compilados: layouts, valores, dibujables
      assets/                  # ficheros crudos, servidos tal cual
    debug/                     # solo en la variante de depuracion
    release/
    test/                      # pruebas locales en la JVM
    androidTest/               # pruebas instrumentadas, en dispositivo
  build/
    generated/                 # BuildConfig, R, codigo de KSP: leer, nunca editar
    outputs/                   # apk, aab y mapping de R8

Todo lo que cuelga de build es derivado y desechable: ahí viven la clase R con los identificadores de recursos, BuildConfig con las constantes de la variante y el código que generan los procesadores de anotaciones. Se lee para entender qué produjo el build, jamás se edita, y no se versiona.

La idea que hay que interiorizar es la de conjunto de fuentes. Gradle fusiona main con el conjunto de la variante activa, y lo mismo hace con los recursos y con el manifiesto. Por eso puedes tener una clave de API distinta en debug, o un icono diferente, sin una sola condición en el código. El selector Build Variants, en la barra lateral izquierda, decide cuál de esas fusiones está viendo el IDE en este momento: si editas un fichero de debug con la variante release activa, el editor lo tratará como código muerto.

Las ventanas que de verdad usas

La ventana de Logcat merece una nota aparte porque su lenguaje de consultas sustituye a la vieja combinación de menús desplegables, y componerlo bien es la diferencia entre leer diez líneas y leer diez mil.

package:mine level:warn                      # solo mi aplicacion, avisos y errores
package:com.ejemplo.app tag:Red -message:ping
level:error & age:5m                         # errores de los ultimos cinco minutos

A esas cuatro añade dos que se ignoran sin motivo. Build Analyzer aparece tras cada compilación y te dice qué tarea consumió el tiempo, qué plugin rompió la caché y qué dependencia fuerza una reconfiguración completa; es la herramienta que convierte “el build va lento” en una lista de causas. Y Running Devices incrusta el emulador dentro del IDE, lo que elimina el vaivén de ventanas que fragmenta la atención. El resto de paneles que vienen abiertos por defecto se pueden cerrar sin remordimiento: la barra de herramientas ideal es la que no tiene nada que no uses.

Configurarlo para que no te estorbe

Un Android Studio recién instalado está afinado para un ordenador imaginario. Dos ficheros arreglan casi todo. El primero, gradle.properties del proyecto, se comparte con el equipo:

org.gradle.jvmargs=-Xmx4g -XX:+UseParallelGC -Dfile.encoding=UTF-8
org.gradle.parallel=true
org.gradle.caching=true
org.gradle.configuration-cache=true
android.useAndroidX=true
kotlin.incremental=true

El segundo es la memoria del propio IDE, que se edita desde Help y la opción de personalizar las opciones de la máquina virtual. Un valor de -Xmx4096m es razonable en un equipo con dieciséis gigabytes; subirlo más allá de lo que la máquina puede sostener empeora las cosas, porque el recolector de basura empieza a competir con el demonio de Gradle.

Los atajos son la otra mitad del rendimiento personal, y basta con cinco para no volver a tocar el ratón durante la mayor parte del día.

Tres ajustes más marcan una diferencia desproporcionada. Desactiva los plugins que no usas —hay decenas activos por defecto, para lenguajes y sistemas de control de versiones que no tocas—: cada uno registra inspecciones que se ejecutan mientras escribes. Aprende cuatro atajos y olvida el ratón: la búsqueda global de acciones, la búsqueda universal con doble pulsación de mayúsculas, la lista de ficheros recientes y, sobre todo, la acción contextual de corrección rápida, que resuelve importaciones, crea funciones inexistentes y propone la refactorización obvia. Y define plantillas propias para el código que repites, porque escribir a mano lo que ya sabes que vas a escribir es la forma más silenciosa de perder una hora al día.