Pular para o conteúdo
CrossFly é 100% open sourceSiga no GitHub
CrossFlyCrossFly
Começar

A arquitetura em camadas

Para entender qualquer parte do CrossFly, ajuda ter o mapa do todo. Na essência, o CrossFly é um ApplicationListener da libGDX — um único ponto que a libGDX chama para criar, redimensionar e renderizar a aplicação. Em volta disso, o framework se organiza em camadas.

usa

app — seu código
(Windows, componentes, lógica)

ui — tudo é Component
(widgets, layouts, estilos)

core / kernel
(bootstrap, input, ciclo de vida, config)

gl — renderizadores por primitiva
(traduz desenho → draw calls)

libGDX + OpenGL

serviços — sqlite, device, map
(módulos independentes da UI)

O que cada camada faz

  • app — o seu código: subclasses de Window (telas), componentes, regras de negócio. É onde você vive.
  • ui — a biblioteca de UI: tudo deriva de Component (widgets, containers, estilos, layouts). Ver Tudo é um Component.
  • core / kernel — liga a aplicação ao mundo: o Main (o ApplicationListener) faz o bootstrap, entrega input, dispara o ciclo de vida e carrega configuração de dispositivo. Ver O ciclo de vida.
  • gl — traduz o desenho de alto nível (Paint) em draw calls OpenGL, com um renderizador por primitiva. Ver O pipeline de renderização.
  • serviços — SQLite, device, map, etc.: módulos independentes da UI, usados pela app sob demanda.

Por que essa separação importa

  • Você programa quase sempre na camada ui (compondo Components). As camadas abaixo são detalhe de implementação — você raramente toca em gl ou fala direto com a libGDX.
  • O framework é single-thread na paint thread (ver A paint thread): o Main chama create()/render()/resize() sempre nessa thread, e toda a UI acontece nela.
  • Os serviços não dependem da UI — dá para usar SQLite ou o device sem montar tela, e a UI não “sabe” desses módulos até você chamá-los.

O fluxo de controle, de alto nível

  1. A libGDX cria o Main e chama create() na paint thread.
  2. O Main faz o bootstrap (plataforma, runtime, config) e instancia a janela principal por reflexão, chamando seu onShow().
  3. A cada frame, a libGDX chama render(); o EventsProcessor pinta a pilha de janelas (a do topo por cima) — mas só quando há um pedido de render (repaint()), não continuamente.
  4. Input e resize chegam pelos callbacks do Main, sempre na paint thread.

Este é o mapa mental, não o catálogo de pacotes. Para a lista de pacotes e classes por camada, veja a referência técnica.

Veja também

Esta página foi útil?