# La arquitectura en capas > El mapa mental de CrossFly — app → ui → core → gl → libGDX — y por qué existe esa separación. Source: https://crossfly.dev/es/docs/concepts/architecture — CrossFly documentation. Full docs as one file: https://crossfly.dev/llms-full.txt # La arquitectura en capas Para entender cualquier parte de CrossFly, ayuda tener el mapa del todo. En esencia, **CrossFly es un `ApplicationListener` de libGDX** — un único punto que libGDX llama para crear, redimensionar y renderizar la aplicación. Alrededor de eso, el framework se organiza en capas.

## Qué hace cada capa - **app** — tu código: subclases de `Window` (pantallas), componentes, reglas de negocio. Es donde vives. - **ui** — la biblioteca de UI: **todo deriva de `Component`** (widgets, containers, estilos, layouts). Ver [Todo es un Component](/docs/concepts/everything-is-a-component). - **core / kernel** — conecta la aplicación al mundo: el `Main` (el `ApplicationListener`) hace el bootstrap, entrega el input, dispara el ciclo de vida y carga la configuración de dispositivo. Ver [El ciclo de vida](/docs/concepts/lifecycle). - **gl** — traduce el dibujo de alto nivel (`Paint`) en *draw calls* OpenGL, con un renderizador por primitiva. Ver [El pipeline de renderizado](/docs/concepts/rendering-pipeline). - **serviços** — SQLite, device, map, etc.: módulos **independientes de la UI**, usados por la app bajo demanda. ## Por qué importa esta separación - Programas **casi siempre en la capa `ui`** (componiendo `Component`s). Las capas inferiores son un detalle de implementación — rara vez tocas `gl` o hablas directamente con libGDX. - El framework es **single-thread en la paint thread** (ver [La paint thread](/docs/concepts/the-paint-thread)): el `Main` llama a `create()`/`render()`/`resize()` siempre en esa thread, y toda la UI ocurre en ella. - Los **servicios no dependen de la UI** — se puede usar SQLite o el device sin montar pantalla, y la UI no "conoce" esos módulos hasta que los llamas. ## El flujo de control, de alto nivel 1. libGDX crea el `Main` y llama a `create()` en la paint thread. 2. El `Main` hace el bootstrap (plataforma, runtime, config) e instancia la **ventana principal por reflexión**, llamando a su `onShow()`. 3. En cada frame, libGDX llama a `render()`; el `EventsProcessor` pinta la **pila de ventanas** (la del tope por encima) — pero **solo cuando hay una solicitud de render** (`repaint()`), no continuamente. 4. El input y el `resize` llegan por los callbacks del `Main`, siempre en la paint thread. > Este es el mapa mental, no el catálogo de paquetes. Para la lista de paquetes y clases por capa, ve la > referencia técnica. ## Ver también - Siguiente: [Todo es un Component](/docs/concepts/everything-is-a-component) · [El ciclo de vida](/docs/concepts/lifecycle)