# 分层架构 > CrossFly 的思维导图 —— app → ui → core → gl → libGDX —— 以及为什么存在这种分层。 Source: https://crossfly.dev/zh/docs/concepts/architecture — CrossFly documentation. Full docs as one file: https://crossfly.dev/llms-full.txt # 分层架构要理解 CrossFly 的任何部分，先掌握整体地图会很有帮助。本质上，**CrossFly 就是一个 libGDX 的 `ApplicationListener`** —— libGDX 通过这个单一入口来创建、调整大小并渲染应用。围绕这一点，框架被组织成若干层。

## 每一层各做什么 - **app** —— 你的代码：`Window` 的子类（屏幕）、组件、业务规则。这是你日常工作的地方。 - **ui** —— UI 库：**一切都派生自 `Component`**（widgets、容器、样式、布局）。参见 [一切都是 Component](/docs/concepts/everything-is-a-component)。 - **core / kernel** —— 将应用连接到外部世界：`Main`（即 `ApplicationListener`）负责启动引导，分发输入、触发生命周期并加载设备配置。参见 [生命周期](/docs/concepts/lifecycle)。 - **gl** —— 将高层绘制（`Paint`）翻译成 OpenGL 的 *draw calls*，每个图元对应一个渲染器。参见 [渲染管线](/docs/concepts/rendering-pipeline)。 - **serviços** —— SQLite、device、map 等：**独立于 UI** 的模块，由 app 按需使用。 ## 为什么这种分层很重要 - 你**几乎总是在 `ui` 层编程**（通过组合 `Component`）。下层是实现细节 —— 你很少会碰 `gl`，也很少直接与 libGDX 打交道。 - 框架在**paint thread 上是单线程的**（参见 [paint thread](/docs/concepts/the-paint-thread)）： `Main` 始终在该线程上调用 `create()`/`render()`/`resize()`，所有 UI 都发生在其中。 - **服务不依赖 UI** —— 你可以不搭建任何界面就使用 SQLite 或 device，而 UI 在你调用这些模块之前也"不知道"它们的存在。 ## 高层次的控制流 1. libGDX 创建 `Main` 并在 paint thread 上调用 `create()`。 2. `Main` 完成启动引导（平台、运行时、配置），并**通过反射实例化主窗口**，调用其 `onShow()`。 3. 每一帧，libGDX 都会调用 `render()`；`EventsProcessor` 绘制**窗口栈**（栈顶在最上层）—— 但**只有在收到渲染请求时**（`repaint()`）才绘制，而非持续绘制。 4. 输入和 `resize` 通过 `Main` 的回调到达，始终在 paint thread 上。 > 这是思维导图，而非包目录。关于按层划分的包和类列表，请参见 > 技术参考。 ## 参见 - 下一篇：[一切都是 Component](/docs/concepts/everything-is-a-component) · [生命周期](/docs/concepts/lifecycle)