# परतों में बँटा आर्किटेक्चर > CrossFly का मानसिक नक्शा — app → ui → core → gl → libGDX — और यह विभाजन क्यों मौजूद है। Source: https://crossfly.dev/hi/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, containers, स्टाइल, layouts)। देखें [सब कुछ एक Component है](/docs/concepts/everything-is-a-component)। - **core / kernel** — एप्लिकेशन को दुनिया से जोड़ता है: `Main` (यानी `ApplicationListener`) bootstrap करता है, input पहुँचाता है, जीवनचक्र चालू करता है और डिवाइस की कॉन्फ़िगरेशन लोड करता है। देखें [जीवनचक्र](/docs/concepts/lifecycle)। - **gl** — उच्च-स्तरीय चित्रण (`Paint`) को OpenGL *draw calls* में अनुवादित करता है, प्रत्येक प्रिमिटिव के लिए एक रेंडरर के साथ। देखें [रेंडरिंग पाइपलाइन](/docs/concepts/rendering-pipeline)। - **serviços** — SQLite, device, map आदि: **UI से स्वतंत्र** मॉड्यूल, जिन्हें app माँग पर उपयोग करती है। ## यह विभाजन क्यों मायने रखता है - आप **लगभग हमेशा `ui` परत में प्रोग्रामिंग करते हैं** (`Component`s को जोड़-मिलाकर)। नीचे की परतें कार्यान्वयन का विवरण हैं — आप शायद ही कभी `gl` को छूते हैं या libGDX से सीधे बात करते हैं। - फ्रेमवर्क **paint thread पर single-thread है** (देखें [paint thread](/docs/concepts/the-paint-thread)): `Main` `create()`/`render()`/`resize()` को हमेशा उसी thread पर बुलाता है, और सारी UI उसी पर होती है। - **सेवाएँ UI पर निर्भर नहीं करतीं** — बिना स्क्रीन बनाए SQLite या device का उपयोग किया जा सकता है, और UI इन मॉड्यूल के बारे में तब तक "नहीं जानती" जब तक आप उन्हें नहीं बुलाते। ## नियंत्रण का प्रवाह, उच्च स्तर पर 1. libGDX `Main` बनाता है और paint thread पर `create()` को बुलाता है। 2. `Main` bootstrap करता है (प्लेटफ़ॉर्म, runtime, config) और **रिफ्लेक्शन के ज़रिए मुख्य विंडो को इंस्टैंशिएट करता है**, उसके `onShow()` को बुलाते हुए। 3. हर frame पर, libGDX `render()` को बुलाता है; `EventsProcessor` **विंडो के स्टैक** को पेंट करता है (सबसे ऊपर वाली सबसे ऊपर) — पर **केवल तभी जब कोई render का अनुरोध हो** (`repaint()`), लगातार नहीं। 4. Input और `resize` `Main` के callbacks के ज़रिए आते हैं, हमेशा paint thread पर। > यह मानसिक नक्शा है, पैकेजों की सूची नहीं। परत-दर-परत पैकेज और क्लास की सूची के लिए, तकनीकी संदर्भ देखें। ## यह भी देखें - आगे: [सब कुछ एक Component है](/docs/concepts/everything-is-a-component) · [जीवनचक्र](/docs/concepts/lifecycle)