यह पृष्ठ पुर्तगाली से मशीन-अनुवादित है और इसमें त्रुटियाँ हो सकती हैं। पुर्तगाली संस्करण प्रामाणिक है।
paint thread
यह शायद फ्रेमवर्क का सबसे महत्वपूर्ण नियम है ताकि आपका app दूषित न हो।
CrossFly paint thread पर single-thread है
UI और रेंडरिंग की हर क्रिया एक ही thread पर होती है — paint thread। Main create(), render()
और resize() को हमेशा इसी पर बुलाता है; हर onShow, onPaint, onLayout, स्पर्श callback और कंपोनेंट
परिवर्तन इसी पर चलता है।
यह निर्णय क्यों? सरलता और शुद्धता। UI को छूने वाले एक ही निष्पादन-धागे के साथ, पेंटिंग के मार्ग में न कोई lock है, न विवादित साझा अवस्था। इसकी कीमत एक नियम है जिसका आपको पालन करना है: UI को कभी दूसरी thread से न छुएँ।
प्रामाणिक पैटर्न: भारी काम बाहर, UI onUI से वापस
नेटवर्क, डेटाबेस, फ़ाइल, लंबी गणना → पृष्ठभूमि thread। परिणाम के साथ UI को छूने के लिए,
Component.onUI(...) से paint thread पर वापस लौटें:
new Thread(() -> {
List<Cliente> dados = repositorio.buscarTudo(); // भारी काम, background thread
Component.onUI(() -> { // paint thread पर वापस
lista.setItems(dados); // अब UI को छेड़ना सुरक्षित है
Component.repaint(); // एक नया frame माँगता है
});
}).start();
Main.runOnPaintThread(Runnable) (और उसका रूप runOnPaintThreadAndWait(...)) भी मौजूद है, किसी Component
के संदर्भ से बाहर उसी उद्देश्य के लिए।
नियम तोड़ने का क्लासिक लक्षण: नेटवर्क/timer callback के भीतर से “स्क्रीन अपडेट करने” पर app टिक जाता है या अनियमित व्यवहार करता है। सुधार हमेशा यही है: UI के स्पर्श को
onUI(...)में लपेटें।
माँग पर render
paint thread लगातार पुनः चित्रण नहीं करती। एक नया frame केवल तभी उत्पन्न होता है जब कोई repaint() को
बुलाता है (आंतरिक रूप से Gdx.graphics.requestRendering())। यह बैटरी बचाता है — एक स्थिर स्क्रीन GPU खर्च नहीं
करती।
अधिकांश कंपोनेंट setters पहले से ही आपके लिए repaint() को बुलाते हैं। याद रखने योग्य परिणाम:
- कुछ ऐसा बदला जिसे फ्रेमवर्क नहीं जानता?
repaint()स्वयं बुलाएँ। - एनिमेशन? उसे हर frame पर render का अनुरोध जीवित रखना पड़ता है (यही animators
onUpdateमें करते हैं; देखें मान एनिमेशन)।
यह भी देखें
- संबंधित: रेंडरिंग पाइपलाइन · अवस्था और डेटा प्रवाह
- आगे: Layout और Relative मॉडल