धीमी रेंडरिंग

यूज़र इंटरफ़ेस (यूआई) रेंडरिंग एक ऐसी प्रोसेस है जिसमें आपके ऐप्लिकेशन से फ़्रेम जनरेट किया जाता है और उसे स्क्रीन. यह पक्का करने के लिए कि आपके ऐप्लिकेशन के साथ उपयोगकर्ता का इंटरैक्शन आसान हो, 60 फ़्रेम प्रति सेकंड (फ़्रेम प्रति सेकंड) तक पहुंचने के लिए, आपके ऐप्लिकेशन को 16 मि॰से॰ से कम समय में फ़्रेम रेंडर होने होंगे. यह समझने के लिए कि 60 फ़्रेम प्रति सेकंड (फ़्रेम प्रति सेकंड) का सुझाव क्यों दिया जाता है, Android परफ़ॉर्मेंस पैटर्न देखें: 60fps क्यों? अगर आपको 90 फ़्रेम प्रति सेकंड (फ़्रेम प्रति सेकंड) तक पहुंचने के बाद, यह विंडो घटकर 11 मि॰से॰ तक पहुंच जाती है और 120 एफ़पीएस (फ़्रेम प्रति सेकंड) तक हो जाती है 8 मि॰से॰

अगर आपने इस विंडो को 1 मि॰से॰ से ज़्यादा बढ़ाया है, तो इसका मतलब यह नहीं है कि फ़्रेम दिखाया जा रहा है 1 मि॰से॰ की देरी से, लेकिन Choreographer फ़्रेम को पूरी तरह से छोड़ देता है. अगर आपके ऐप्लिकेशन को धीमी यूज़र इंटरफ़ेस (यूआई) रेंडरिंग की समस्या है, तो सिस्टम को फ़्रेम स्किप करने की ज़रूरत नहीं पड़ती और उपयोगकर्ता को आपके ऐप्लिकेशन में कोई हकीकत महसूस होती है. इसे जैंक कहते हैं. इस पेज पर जैंक की समस्या का पता लगाने और उसे ठीक करने का तरीका बताया गया है.

अगर आप ऐसे गेम डेवलप कर रहे हैं जो View सिस्टम इस्तेमाल करता है, तो आप इसे बायपास कर देते हैं Choreographer. इस मामले में, फ़्रेम पेसिंग लाइब्रेरी से मदद मिलती है OpenGL और Vulkan के गेम की रेंडरिंग आसान होती है और Android पर फ़्रेम पेसिंग सही होनी चाहिए.

ऐप्लिकेशन की क्वालिटी को बेहतर बनाने में मदद करने के लिए, Android अपने-आप जैंक के लिए आपके ऐप्लिकेशन को मॉनिटर करता है साथ ही, 'Android की ज़रूरी जानकारी' के डैशबोर्ड में जानकारी दिखाएगा. जानकारी के लिए डेटा इकट्ठा करने के तरीके के बारे में जानने के लिए, अपने ऐप्लिकेशन की तकनीकी क्वालिटी पर नज़र रखने के लिए, Android पर ज़रूरी जानकारी.

जैंक की पहचान करें

आपके ऐप्लिकेशन में उस कोड को ढूंढना मुश्किल हो सकता है जिसकी वजह से जैंक हो रहा है. इस सेक्शन पर जैंक की पहचान करने के तीन तरीके बताता है:

• विज़ुअल की जांच करना
• सिस्ट्रेस
• पसंद के मुताबिक परफ़ॉर्मेंस मॉनिटर करना

विज़ुअल की जांच की सुविधा की मदद से, कुछ मामलों में आपके ऐप्लिकेशन में इस्तेमाल के सभी उदाहरण देखे जा सकते हैं मिनट है, लेकिन यह Systrace की तरह ज़्यादा जानकारी नहीं देता है. Systrace की मदद से हालांकि, अगर आपके ऐप्लिकेशन में इस्तेमाल के सभी उदाहरणों के लिए Systrace चलाया जाता है, तो इतना ज़्यादा डेटा होगा कि इसका विश्लेषण करना मुश्किल हो सकता है. दोनों विज़ुअल की सेवा लें और Systrace आपके लोकल डिवाइस पर जैंक का पता लगाते हैं. अगर आप यह तय नहीं कर पा रहे हैं कि लोकल डिवाइसों पर जैंक किया जा सकता है. ऐसे में, पसंद के मुताबिक परफ़ॉर्मेंस मॉनिटरिंग बनाई जा सकती है फ़ील्ड में चल रहे डिवाइसों पर आपके ऐप्लिकेशन के खास हिस्सों की जानकारी देता है.

विज़ुअल की जांच करना

विज़ुअल की मदद से, जैंक जनरेट करने वाले कॉन्टेंट का पता लगाया जा सकता है. यहां की यात्रा पर हूं अपने ऐप्लिकेशन की विज़ुअल जांच करें, अपना ऐप्लिकेशन खोलें, और मैन्युअल तरीके से अपने ऐप्लिकेशन के हिस्सों को डाउनलोड करने और अपने यूज़र इंटरफ़ेस (यूआई) में जैंक ढूंढने के लिए.

विज़ुअल की जांच करने से जुड़ी कुछ सलाह यहां दी गई है:

• अपने ऐप्लिकेशन का कोई वर्शन या कम से कम डीबग किया जा सकने वाला वर्शन चलाएं. द एआरटी रनटाइम, डीबग के साथ काम करने के लिए कई ज़रूरी ऑप्टिमाइज़ेशन को बंद कर देता है ताकि आपको ठीक उसी तरह के नतीजे दिख रहे हों जैसा कोई उपयोगकर्ता देख रहा है देखता है.
• प्रोफ़ाइल जीपीयू चालू करें रेंडर हो रहा है. प्रोफ़ाइल जीपीयू रेंडर होने में स्क्रीन पर बार दिखते हैं, जिनसे आपको विज़ुअल दिखता है किसी यूज़र इंटरफ़ेस (यूआई) विंडो के फ़्रेम को रेंडर करने में लगने वाला समय बताने वाला वीडियो 16-मि॰से॰ प्रति फ़्रेम के मानदंड के मुताबिक होगा. हर बार में रंगीन कॉम्पोनेंट होते हैं उसे रेंडरिंग पाइपलाइन में एक स्टेज पर मैप किया जा सकता है, ताकि आप देख सकें कि कौनसा हिस्सा सबसे ज़्यादा समय लग रहा है. उदाहरण के लिए, अगर फ़्रेम बहुत ज़्यादा समय बिता रहा है हैंडलिंग इनपुट के लिए, अपना ऐप्लिकेशन कोड देखें जो उपयोगकर्ता इनपुट को हैंडल करता है.
• उन कॉम्पोनेंट को चलाएं जो जैंक के सामान्य सोर्स हैं, जैसे RecyclerView के तौर पर इस्तेमाल करें.
• ऐप्लिकेशन को किसी कोल्ड विंडो से लॉन्च करें शुरू करें.
• समस्या बढ़ने के लिए, अपने ऐप्लिकेशन को धीमे डिवाइस पर चलाएं.

जब आपको जैंक बनाने के काम का पता चलता है, तो आपको पता चल सकता है कि जिसकी वजह से आपके ऐप्लिकेशन में जैंक गड़बड़ी हो रही है. ज़्यादा जानकारी के लिए, Systrace का इस्तेमाल करें ताकि हमें इस समस्या को ठीक करने में मदद मिले.

सिस्ट्रेस

हालांकि, Systrace ऐसा टूल है जिससे यह पता चलता है कि पूरा डिवाइस क्या कर रहा है, लेकिन यह आपके ऐप्लिकेशन में जैंक की पहचान करने में मदद मिलेगी. Systrace में कम से कम सिस्टम होता है ओवरहेड दिया गया हो, ताकि इंस्ट्रुमेंटेशन के दौरान आपको असली खतरों का अनुभव हो सके.

यह कार्रवाई करते समय, Systrace की मदद से ट्रेस रिकॉर्ड करें आपके डिवाइस पर इस्तेमाल का उदाहरण. Systrace का इस्तेमाल करने से जुड़े निर्देशों के लिए, यहां देखें कमांड लाइन पर सिस्टम ट्रेस कैप्चर करें. Systrace की यह प्रक्रिया अलग-अलग प्रोसेस और थ्रेड. Systrace में अपने ऐप्लिकेशन की प्रोसेस देखें, जो कुछ ऐसी दिखती है पहली इमेज.

पहली इमेज में मौजूद Systrace के उदाहरण में, जैंक की पहचान करने वाला:

1. Systrace तब दिखाता है, जब हर फ़्रेम बनाया गया हो और हर फ़्रेम को कलर कोड दिया गया हो रेंडर होने के समय को हाइलाइट किया जाता है. इससे आपको अलग-अलग जैकी फ़्रेम को ज़्यादा ढूंढने में मदद मिलती है इससे ज़्यादा सटीक नतीजे मिलते हैं. ज़्यादा जानकारी के लिए, यह देखें यूज़र इंटरफ़ेस (यूआई) की जांच करें फ़्रेम और सूचनाएं.
2. Systrace आपके ऐप्लिकेशन में होने वाली समस्याओं का पता लगाता है और दोनों में सूचनाएं दिखाता है अलग-अलग फ़्रेम और सूचनाएं पैनल. बेहतर होगा कि आप चेतावनी में दिए गए निर्देशों का पालन करें.
3. Android फ़्रेमवर्क और लाइब्रेरी के हिस्से, जैसे कि RecyclerView में ट्रेस मार्कर मौजूद हैं. इसलिए, systrace की टाइमलाइन से पता चलता है कि यूज़र इंटरफ़ेस (यूआई) पर उन तरीकों को कब एक्ज़ीक्यूट किया गया थ्रेड और उन्हें एक्ज़ीक्यूट करने में कितना समय लगता है.

Systrace के आउटपुट को देखने के बाद, आपके ऐप्लिकेशन में ऐसे तरीके हो सकते हैं जो आपको लगता है कि जैंक होने की वजह बन रही है. उदाहरण के लिए, अगर समयावधि दिखाती है कि RecyclerView की वजह से फ़्रेम में ज़्यादा समय लग रहा है, इसलिए आप कस्टम ट्रेस जोड़ सकते हैं इवेंट और ज़्यादा जानकारी के लिए, Systrace को फिर से चलाएं. नए Systrace में, टाइमलाइन दिखाती है आपके ऐप्लिकेशन के तरीकों को कॉल किया जाता है और उनके लागू होने में कितना समय लगता है.

अगर Systrace आपको इस बारे में जानकारी नहीं दिखाता कि यूज़र इंटरफ़ेस (यूआई) थ्रेड के काम करने में ज़्यादा समय क्यों लग रहा है समय है, तो Android CPU का उपयोग करें प्रोफ़ाइलर, ताकि सैंपल या इंस्ट्रुमेंटेड मेथड ट्रेस का इस्तेमाल करें. आम तौर पर, तरीका ट्रेस करने की सुविधा जैंक की पहचान करने में ओवरहेड कर देते हैं और वे यह नहीं देख सकते कि थ्रेड कब चल रहे हैं और कब ब्लॉक किए गए हैं. हालांकि, मेथड ट्रेस की मदद से आपके ऐप्लिकेशन में उन तरीकों का पता लगाया जा सकता है जो का सबसे ज़्यादा इस्तेमाल करते हैं. इन तरीकों की पहचान करने के बाद, ट्रेस जोड़ें मार्कर की सुविधा का इस्तेमाल करें और देखने के लिए Systrace को फिर से चलाएं कि क्या इन तरीकों से जैंक हो रहा है.

ज़्यादा जानकारी के लिए, जानें कि सिस्ट्रेस.

परफ़ॉर्मेंस को अपने हिसाब से मॉनिटर करना

अगर लोकल डिवाइस पर जैंक को जनरेट नहीं किया जा सकता, तो अपने हिसाब से परफ़ॉर्मेंस तैयार की जा सकती है आपके ऐप्लिकेशन को मॉनिटर किया जा सके, ताकि उन डिवाइसों पर जैंक के सोर्स का पता लगाया जा सके जिनमें फ़ील्ड में डालें.

ऐसा करने के लिए, इसकी मदद से अपने ऐप्लिकेशन के खास हिस्सों से फ़्रेम रेंडर समय इकट्ठा करें FrameMetricsAggregator Firebase की परफ़ॉर्मेंस का इस्तेमाल करके, डेटा को रिकॉर्ड और उसका विश्लेषण करेगा निगरानी करना.

ज़्यादा जानने के लिए, Android.

रुकी हुई फ़्रेम

रुके हुए फ़्रेम, ऐसे यूज़र इंटरफ़ेस (यूआई) फ़्रेम होते हैं जिन्हें रेंडर होने में 700 मि॰से॰ से ज़्यादा समय लगता है. यह है समस्या हो रही है, क्योंकि ऐसा लगता है कि आपका ऐप्लिकेशन अटक गया है और उपयोगकर्ता के इनपुट का जवाब नहीं दे रहा है फ़्रेम रेंडर होने के दौरान, तकरीबन पूरे सेकंड के लिए. हमारा सुझाव है कि आप ऑप्टिमाइज़ करें आसान यूज़र इंटरफ़ेस (यूआई) के लिए 16 मि॰से॰ के अंदर फ़्रेम रेंडर करना होगा. हालांकि, ऐप्लिकेशन के दौरान या किसी अन्य स्क्रीन पर संक्रमण करते समय, यह सामान्य बात है शुरुआती फ़्रेम ड्रॉ होने में 16 मि॰से॰ से ज़्यादा समय लगेगा, क्योंकि आपके ऐप्लिकेशन को इनऐक्टिव होना चाहिए व्यू, स्क्रीन को लेआउट, और शुरुआत में ड्रॉ करना शुरू किया है. इसी वजह से Android, रुके हुए फ़्रेम को धीमी रेंडरिंग से अलग ट्रैक करता है. नहीं आपके ऐप्लिकेशन में मौजूद फ़्रेम को रेंडर होने में 700 मि॰से॰ से ज़्यादा समय लगेगा.

ऐप्लिकेशन की क्वालिटी को बेहतर बनाने में आपकी मदद करने के लिए, Android रुके हुए फ़्रेम और 'Android की ज़रूरी जानकारी' वाले डैशबोर्ड में जानकारी दिखाती है. डेटा इकट्ठा करने के तरीके के बारे में जानकारी के लिए, अपने ऐप्लिकेशन की तकनीकी निगरानी करना देखें 'Android की ज़रूरी जानकारी' की मदद से, कॉन्टेंट की क्वालिटी को बेहतर बनाएं.

रुके हुए फ़्रेम, रेंडर होने में बहुत ज़्यादा समय लेने वाले होते हैं. इसलिए, समस्या का पता लगाने और उसे ठीक करने की प्रक्रिया एक जैसी है.

जैंक को ट्रैक किया जा रहा है

फ़्रेमटाइमलाइन Perfetto में दी गई जानकारी की मदद से, रुके हुए फ़्रेम के साथ दिखेंगे.

रेंडर होने में ज़्यादा समय लेने वाले फ़्रेम, रुके हुए फ़्रेम, और ANR से जुड़ी गड़बड़ियों के बीच संबंध

धीमे फ़्रेम, रुके हुए फ़्रेम, और ANR सभी जैंक के अलग-अलग तरीके हैं, जो आपके को मिल सकती है. दोनों के अंतर को समझने के लिए, यहां दी गई टेबल देखें.

रेंडर होने में ज़्यादा समय लेने वाले फ़्रेम और रुके हुए फ़्रेम को अलग-अलग ट्रैक करें

ऐप्लिकेशन शुरू होने के दौरान या किसी दूसरी स्क्रीन पर जाते समय, यह सामान्य बात है शुरुआती फ़्रेम बनाने में 16 मि॰से॰ से ज़्यादा समय लगेगा, क्योंकि ऐप्लिकेशन को व्यू बढ़ाएं, स्क्रीन का लेआउट तय करें, और वीडियो पर शुरुआत से कुछ ड्रॉ करें.

जैंक की प्राथमिकता तय करने और उसे ठीक करने के सबसे सही तरीके

जैंक की समस्या को हल करने के लिए, इन सबसे सही तरीकों को ध्यान में रखें ऐप्लिकेशन:

• जैंक के सबसे आसानी से दोबारा जनरेट किए जा सकने वाले इंस्टेंस की पहचान करें और उन्हें ठीक करें.
• ANR की गड़बड़ियों को प्राथमिकता दें. रेंडर होने में ज़्यादा समय लेने वाले या रुके हुए फ़्रेम होने पर, ऐप्लिकेशन दिख सकता है काम नहीं करता है, तो ANR की समस्याओं की वजह से ऐप्लिकेशन काम करना बंद कर देता है.
• धीमी रेंडरिंग को फिर से पैदा करना मुश्किल होता है, लेकिन आप 700 मि॰से॰ की फ़्रीज़ को खत्म करके शुरुआत कर सकते हैं फ़्रेम. ऐसा आम तौर पर तब होता है, जब ऐप्लिकेशन चालू हो रहा हो या स्क्रीन बदल रही हो.

जैंक को ठीक करना

जैंक को ठीक करने के लिए, देखें कि कौनसे फ़्रेम 16 मि॰से॰ में पूरे नहीं हो रहे हैं और देखें कि उनमें क्या है गलत. देखें कि क्या Record View#draw या Layout इस अवधि में असामान्य रूप से ज़्यादा समय ले रहा है कुछ फ़्रेम. इन समस्याओं के लिए जैंक के सामान्य स्रोत देखें और अन्य.

जैंक से बचने के लिए, लंबे समय तक चलने वाले टास्क को यूज़र इंटरफ़ेस (यूआई) थ्रेड के बाहर एसिंक्रोनस तरीके से चलाएं. हमेशा इस बात का ध्यान रखें कि आपका कोड किस थ्रेड पर चल रहा है और सावधानी बरतें. मुख्य थ्रेड में सामान्य टास्क पोस्ट करना.

अगर आपके ऐप्लिकेशन के लिए एक जटिल और अहम मुख्य यूज़र इंटरफ़ेस (यूआई) है, जैसे कि मुख्य यूज़र इंटरफ़ेस (यूआई) स्क्रोल करने वाली सूची—इंस्ट्रुमेंटेशन लिखने के बारे में सोचें टेस्ट जो अपने-आप रेंडर होने में लगने वाले समय का पता लगाता है और रिग्रेशन को रोकने के लिए बार-बार टेस्ट करता रहता है.

जैंक के सामान्य स्रोत

यहां दिए गए सेक्शन में, View का इस्तेमाल करने वाले ऐप्लिकेशन में जैंक के आम सोर्स के बारे में बताया गया है और उन्हें हल करने के सबसे सही तरीके बताए गए हैं. ठीक करने के बारे में जानकारी के लिए Jetpack Compose में परफ़ॉर्मेंस की समस्याओं के बारे में जानने के लिए, Jetpack देखें परफ़ॉर्मेंस लिखें.

स्क्रोल की जा सकने वाली सूचियां

ListView—और खास तौर पर RecyclerView—आम तौर पर, स्क्रोल करने वाली जटिल सूचियों के लिए इस्तेमाल किया जाता है. जैंक करने के लिए ज़्यादा खतरा. दोनों में Systrace के मार्कर इस्तेमाल होते हैं. इसलिए, Systrace का इस्तेमाल किया जा सकता है ताकि यह देखा जा सके कि वे आपके ऐप्लिकेशन में जैंक करने में योगदान दे रहे हैं या नहीं. कमांड-लाइन पास करें तर्क -a <your-package-name> लिखें, ताकि RecyclerView—और सभी में ट्रेस सेक्शन मिल सकें आपके जोड़े गए ट्रेस मार्कर—अलग-अलग तरह से दिखते हैं. अगर उपलब्ध हो, तो Systrace आउटपुट में जनरेट होने वाली सूचनाएं. Systrace के अंदर की जानकारी पर क्लिक करके काम की जानकारी देखने के लिए RecyclerView-ट्रेंड किए गए सेक्शन RecyclerView कर रहा है.

RecyclerView: NotificationDataSetChanged()

अगर आपको अपने RecyclerView के हर आइटम को रीबाउंड होता हुआ दिखता है और इस तरह वह फिर से तैयार किया जाता है और एक फ़्रेम में फिर से ड्रॉ करें—पक्का करें कि आपने कॉल नहीं किया हो notifyDataSetChanged(), setAdapter(Adapter), या swapAdapter(Adapter, boolean) आज़माएं. ये तरीके बताते हैं कि पूरी प्रोसेस में बदलाव कॉन्टेंट की सूची बनाएं और Systrace में RV Full invalidate के तौर पर दिखना चाहिए. इसके बजाय, SortedList या DiffUtil जनरेट करने के लिए कॉन्टेंट में बदलाव करने या जोड़े जाने पर कम से कम अपडेट.

उदाहरण के लिए, ऐसा ऐप्लिकेशन चुनें जिसे खबरों की सूची का नया वर्शन मिलता है की मदद से निकाल दिया जाता है. जब आप यह जानकारी अडैप्टर पर पोस्ट करते हैं, notifyDataSetChanged() को कॉल किया जा सकता है, जैसा कि इस उदाहरण में दिखाया गया है:

fun onNewDataArrived(news: List<News>) {
    myAdapter.news = news
    myAdapter.notifyDataSetChanged()
}

void onNewDataArrived(List<News> news) {
    myAdapter.setNews(news);
    myAdapter.notifyDataSetChanged();
}

इसका एक नकारात्मक पहलू यह है कि क्या एक आइटम में कोई मामूली बदलाव किया गया है, जैसे कि एक आइटम शीर्ष पर जोड़ा गया, RecyclerView को जानकारी नहीं है. इसलिए, इसे कैश मेमोरी में सेव किए गए आइटम की स्थिति को रिकॉर्ड करता है. इसलिए, हर चीज़ को रीबाइंड करने की ज़रूरत होती है.

हमारा सुझाव है कि आप DiffUtil का इस्तेमाल करें. यह कम से कम अपडेट का हिसाब लगाता है और उन्हें डिस्पैच करता है आपके लिए:

fun onNewDataArrived(news: List<News>) {
    val oldNews = myAdapter.items
    val result = DiffUtil.calculateDiff(MyCallback(oldNews, news))
    myAdapter.news = news
    result.dispatchUpdatesTo(myAdapter)
}

void onNewDataArrived(List<News> news) {
    List<News> oldNews = myAdapter.getItems();
    DiffResult result = DiffUtil.calculateDiff(new MyCallback(oldNews, news));
    myAdapter.setNews(news);
    result.dispatchUpdatesTo(myAdapter);
}

DiffUtil को अपनी सूचियों की जांच करने का तरीका बताने के लिए, अपने MyCallback को Callback लागू करना.

RecyclerView: नेस्ट किए गए RecyclerViews

RecyclerView के कई इंस्टेंस नेस्ट करना आम बात है. खास तौर पर, हॉरिज़ॉन्टल स्क्रोलिंग सूचियों की वर्टिकल सूची. इसका एक उदाहरण ग्रिड है ऐप्लिकेशन के लिए, Play Store के मुख्य पेज पर जाएं. यह अच्छे से काम कर सकता है, लेकिन यह गतिविधियों को ट्रैक किया जा सकता है.

अगर पेज पर नीचे की ओर स्क्रोल करने पर, आपको बहुत सारे अंदरूनी आइटम बढ़ते हुए दिखते हैं, देख लें कि शेयर किया जा रहा है या नहीं RecyclerView.RecycledViewPool RecyclerView के इनर (हॉरिज़ॉन्टल) इंस्टेंस के बीच. डिफ़ॉल्ट रूप से, हर एक RecyclerView के पास आइटम का अपना पूल है. हालांकि, एक दर्जन itemViews एक ही समय पर स्क्रीन पर हैं. अगर itemViews के पास ऐसा नहीं होता है, तो यह समस्या हो सकती है अगर सभी लाइनें एक जैसी दिख रही हैं, तो इन्हें अलग-अलग हॉरिज़ॉन्टल सूचियों में शेयर किया जाएगा किस तरह के व्यू हैं.

class OuterAdapter : RecyclerView.Adapter<OuterAdapter.ViewHolder>() {

    ...

    override fun onCreateViewHolder(parent: ViewGroup, viewType: Int): ViewHolder {
        // Inflate inner item, find innerRecyclerView by ID.
        val innerLLM = LinearLayoutManager(parent.context, LinearLayoutManager.HORIZONTAL, false)
        innerRv.apply {
            layoutManager = innerLLM
            recycledViewPool = sharedPool
        }
        return OuterAdapter.ViewHolder(innerRv)
    }
    ...

class OuterAdapter extends RecyclerView.Adapter<OuterAdapter.ViewHolder> {
    RecyclerView.RecycledViewPool sharedPool = new RecyclerView.RecycledViewPool();

    ...

    @Override
    public void onCreateViewHolder(ViewGroup parent, int viewType) {
        // Inflate inner item, find innerRecyclerView by ID.
        LinearLayoutManager innerLLM = new LinearLayoutManager(parent.getContext(),
                LinearLayoutManager.HORIZONTAL);
        innerRv.setLayoutManager(innerLLM);
        innerRv.setRecycledViewPool(sharedPool);
        return new OuterAdapter.ViewHolder(innerRv);

    }
    ...

अगर आपको और ज़्यादा ऑप्टिमाइज़ करना है, तो setInitialPrefetchItemCount(int) पूरी तरह कैसे LinearLayoutManager RecyclerView में से एक है. उदाहरण के लिए, अगर आपके पास हमेशा 3.5 आइटम दिखते हैं एक पंक्ति में, innerLLM.setInitialItemPrefetchCount(4) पर कॉल करें. यह सिग्नल RecyclerView कि जब कोई हॉरिज़ॉन्टल लाइन, स्क्रीन पर आने वाली हो, तो उसे अगर यूज़र इंटरफ़ेस (यूआई) थ्रेड को खाली समय मिलता है, तो अंदर के आइटम प्रीफ़ेच करने की कोशिश करें.

RecyclerView: बहुत ज़्यादा इनफ़्लेशन या Create में बहुत ज़्यादा समय लग रहा है

ज़्यादातर मामलों में, RecyclerView की प्रीफ़ेच सुविधा यूज़र इंटरफ़ेस (यूआई) थ्रेड के कुछ समय से इस्तेमाल में न होने पर, काम को समय से पहले करके महंगाई को ध्यान में रखना. अगर आपको फ़्रेम के दौरान महंगाई दिख रही है और RV लेबल वाले सेक्शन में नहीं है प्रीफ़ेच करें, पक्का करें कि आप काम करने वाले डिवाइस पर टेस्ट कर रहे हैं और हाल ही के सहायता लाइब्रेरी का वर्शन होना चाहिए. प्रीफ़ेच की सुविधा सिर्फ़ Android 5.0 एपीआई लेवल 21 और उसके बाद के वर्शन पर काम करती है.

अगर स्क्रीन पर नए आइटम आने के दौरान आपको बार-बार महंगाई दिखती है, जिसकी वजह से जैंक होने लगता है, तो पुष्टि करें कि आपके पास अपनी ज़रूरत से ज़्यादा व्यू टाइप नहीं हैं. इसमें व्यू टाइप की संख्या जितनी कम होगी RecyclerView की सामग्री के मामले में, पहले से कम मुद्रास्फीति की ज़रूरत है. आइटम टाइप स्क्रीन पर दिखते हैं. अगर हो सके, तो जहां ज़रूरी हो वहां व्यू टाइप मर्ज करें. अगर आपने प्रकार के बीच केवल एक आइकन, रंग या टेक्स्ट बदलता है, तो आप बाइंड टाइम में बदलाव करें और इनफ़्लेशन से बचें. इससे आपके ऐप्लिकेशन की मेमोरी कम होती है ट्रैक करें.

अगर आपके व्यू टाइप अच्छे लग रहे हैं, तो अपनी मुद्रास्फीति की लागत को कम करने की कोशिश करें. गै़र-ज़रूरी कंटेनर और स्ट्रक्चरल व्यू को कम करने से मदद मिल सकती है. इसलिए, itemViews में ConstraintLayout की सदस्यता लें, इससे स्ट्रक्चर किए गए व्यू को कम करने में मदद मिल सकती है.

अगर आपको परफ़ॉर्मेंस को बेहतर बनाने के लिए और ज़्यादा ऑप्टिमाइज़ करना है और आपके आइटम की हैरारकी इन्हें इस्तेमाल करना आसान हो जाता है. इसके लिए, आपको मुश्किल थीम और स्टाइल वाली सुविधाओं की ज़रूरत नहीं होती. इसके लिए, खुद ही कंस्ट्रक्टर हैं. हालांकि, इसमें हारने का फ़ायदा नहीं है आसानी से इस्तेमाल किया जा सकता है.

RecyclerView: बाइंड में बहुत ज़्यादा समय लग रहा है

बाइंड—यानी, onBindViewHolder(VH, int)— सीधा होना चाहिए और इस प्रक्रिया में एक मिलीसेकंड से भी कम समय लगेगा लेकिन सबसे जटिल आइटम को छोड़कर सब कुछ किया जा सकता है. इसे सादा पुराना Java ऑब्जेक्ट (POJO) लेना चाहिए आपके अडैप्टर के इंटरनल आइटम डेटा और कॉल सेटर से मिले व्यू ViewHolder. अगर RV OnBindView में ज़्यादा समय लग रहा है, तो पुष्टि करें कि आपके बाइंड कोड में बहुत कम काम करता है.

अगर अडैप्टर में डेटा रखने के लिए बेसिक POJO ऑब्जेक्ट का इस्तेमाल किया जा रहा है, तो इसका उपयोग करके onBindViewHolder में बाइंडिंग कोड लिखने से पूरी तरह बचें डेटा बाइंडिंग लाइब्रेरी.

RecyclerView या ListView: लेआउट या ड्रॉ में बहुत ज़्यादा समय लगता है

ड्रॉ और लेआउट से जुड़ी समस्याओं के लिए, लेआउट की परफ़ॉर्मेंस देखें और परफ़ॉर्मेंस बेहतर बनाना सेक्शन.

ListView: मुद्रास्फीति

अगर आप सावधान नहीं हैं, तो ListView में गलती से रीसाइकलिंग को बंद किया जा सकता है. अगर आपने जब भी कोई आइटम स्क्रीन पर आता है, तो जांच लें कि आपने लागू करना Adapter.getView() सोच-विचार कर रहा है, फिर से बाइंड कर रहा है, और convertView पैरामीटर को लौटा रहा है. अगर आपके getView() लागू करने की प्रक्रिया हमेशा बढ़ी हुई होती है, आपके ऐप्लिकेशन को ListView में रीसाइकलिंग. आपके getView() का स्ट्रक्चर करीब-करीब हमेशा ऐसा होना चाहिए नीचे दिए गए तरीके से लागू होगा:

fun getView(position: Int, convertView: View?, parent: ViewGroup): View {
    return (convertView ?: layoutInflater.inflate(R.layout.my_layout, parent, false)).apply {
        // Bind content from position to convertView.
    }
}

View getView(int position, View convertView, ViewGroup parent) {

    if (convertView == null) {
        // Only inflate if no convertView passed.
        convertView = layoutInflater.inflate(R.layout.my_layout, parent, false)
    }
    // Bind content from position to convertView.
    return convertView;
}

लेआउट की परफ़ॉर्मेंस

अगर Systrace की टीम से पता चलता है कि Choreographer#doFrame का लेआउट सेगमेंट बहुत ज़्यादा काम कर रहे हैं या बहुत बार काम कर रहे हैं, तो इसका मतलब है कि आप लेआउट पर समस्याओं को ठीक करें. आपके ऐप्लिकेशन के लेआउट की परफ़ॉर्मेंस, इस बात पर निर्भर करती है कि ऐप्लिकेशन का कौनसा हिस्सा के लेआउट पैरामीटर या इनपुट बदल रहे हैं.

लेआउट की परफ़ॉर्मेंस: लागत

अगर सेगमेंट कुछ मिलीसेकंड से ज़्यादा लंबे हैं, तो हो सकता है कि आप इसके लिए, सबसे खराब नेस्टिंग परफ़ॉर्मेंस RelativeLayouts या weighted-LinearLayouts. हर ये लेआउट अपने चिल्ड्रन के कई माप और लेआउट पास ट्रिगर कर सकते हैं, इसलिए इन्हें नेस्ट करने से, O(n^2) गहराई से नेस्ट किए जा सकते हैं.

इन सभी में RelativeLayout या LinearLayout की वज़न सुविधा से बचें क्रम के सबसे कम लीफ़ नोड. ऐसा करने के लिए, ये तरीके अपनाएं:

• स्ट्रक्चर के हिसाब से व्यू को फिर से व्यवस्थित करें.
• पसंद के मुताबिक लेआउट लॉजिक तय करें. यहां जाएं: लेआउट की हैरारकी ऑप्टिमाइज़ करना देखें. आप उसे इस फ़ॉर्मैट में बदल सकते हैं ConstraintLayout, जो और इसमें मिलती-जुलती सुविधाएं भी शामिल हैं.

लेआउट की परफ़ॉर्मेंस: फ़्रीक्वेंसी

लेआउट की उम्मीद तब होती है, जब नया कॉन्टेंट स्क्रीन पर आता है. उदाहरण के लिए, जब RecyclerView में, स्क्रोल करके एक नया आइटम दिखता है. अगर अहम लेआउट दिखाई दे रहा है, तो हो सकता है कि आप लेआउट ऐनिमेट कर रहे हों, जो फ़्रेम गिरने की संभावना होती है.

आम तौर पर, View की ड्रॉइंग प्रॉपर्टी पर ऐनिमेशन चलने चाहिए, जैसे कि फ़ॉलो किया जा रहा है:

• setTranslationX()
• setTranslationY()
• setTranslationZ()
• setRotation()
• setAlpha()

आप इन सभी को लेआउट प्रॉपर्टी के मुकाबले बहुत सस्ते में बदल सकते हैं, जैसे पैडिंग, या मार्जिन. आम तौर पर, ड्रॉइंग बदलना भी सस्ता होता है. किसी व्यू की प्रॉपर्टी को ट्रिगर करने वाले सेटर को कॉल करके invalidate(), इसके बाद draw(Canvas) में दिख रहा है. यह उस व्यू के लिए ड्रॉइंग ऑपरेशन को फिर से रिकॉर्ड करता है अमान्य है और आम तौर पर लेआउट से काफ़ी सस्ता है.

परफ़ॉर्मेंस रेंडर करना

Android का यूज़र इंटरफ़ेस (यूआई), दो चरणों में काम करता है:

• यूज़र इंटरफ़ेस (यूआई) थ्रेड पर View#draw रिकॉर्ड करें, जो हरdraw(Canvas) अमान्य व्यू और कॉल को कस्टम व्यू या अपने कोड में बुला सकते हैं.
• RenderThread पर DrawFrame, जो नेटिव RenderThread पर चलता है लेकिन यह Record View#draw फ़ेज़ से जनरेट किए गए काम पर आधारित होता है.

रेंडरिंग परफ़ॉर्मेंस: यूज़र इंटरफ़ेस (यूआई) थ्रेड

अगर Record View#draw में ज़्यादा समय लग रहा है, तो यह आम बात है कि बिटमैप को यूज़र इंटरफ़ेस (यूआई) थ्रेड पर पेंट किया जा रहा है. बिट मैप पर पेंटिंग करने के लिए सीपीयू रेंडरिंग का इस्तेमाल होता है, इसलिए आम तौर पर, जब भी मुमकिन हो, तब ऐसा करने से बचें. आप Android सीपीयू प्रोफ़ाइलर से पता करें कि यह उस समस्या को हल कर सकें.

बिट मैप में तब पेंटिंग की जाती है, जब कोई ऐप्लिकेशन पहले किसी बिट मैप को सजाना चाहता है उसे दिखाने के लिए—कभी-कभी सजावट, जैसे कि गोल कोने जोड़ना:

val paint = Paint().apply {
    isAntiAlias = true
}
Canvas(roundedOutputBitmap).apply {
    // Draw a round rect to define the shape:
    drawRoundRect(
            0f,
            0f,
            roundedOutputBitmap.width.toFloat(),
            roundedOutputBitmap.height.toFloat(),
            20f,
            20f,
            paint
    )
    paint.xfermode = PorterDuffXfermode(PorterDuff.Mode.MULTIPLY)
    // Multiply content on top to make it rounded.
    drawBitmap(sourceBitmap, 0f, 0f, paint)
    setBitmap(null)
    // Now roundedOutputBitmap has sourceBitmap inside, but as a circle.
}

Canvas bitmapCanvas = new Canvas(roundedOutputBitmap);
Paint paint = new Paint();
paint.setAntiAlias(true);
// Draw a round rect to define the shape:
bitmapCanvas.drawRoundRect(0, 0,
        roundedOutputBitmap.getWidth(), roundedOutputBitmap.getHeight(), 20, 20, paint);
paint.setXfermode(new PorterDuffXfermode(PorterDuff.Mode.MULTIPLY));
// Multiply content on top to make it rounded.
bitmapCanvas.drawBitmap(sourceBitmap, 0, 0, paint);
bitmapCanvas.setBitmap(null);
// Now roundedOutputBitmap has sourceBitmap inside, but as a circle.

अगर यूज़र इंटरफ़ेस (यूआई) थ्रेड पर इसी तरह का काम किया जा रहा है, तो पर सेट होता है. कुछ मामलों में, जैसा कि पहले उदाहरण के लिए, यह काम ड्रॉ के समय भी किया जा सकता है. इसलिए, अगर आपके Drawable या View कोड कुछ ऐसा दिखता है:

fun setBitmap(bitmap: Bitmap) {
    mBitmap = bitmap
    invalidate()
}

override fun onDraw(canvas: Canvas) {
    canvas.drawBitmap(mBitmap, null, paint)
}

void setBitmap(Bitmap bitmap) {
    mBitmap = bitmap;
    invalidate();
}

void onDraw(Canvas canvas) {
    canvas.drawBitmap(mBitmap, null, paint);
}

आप इसे इससे बदल सकते हैं:

fun setBitmap(bitmap: Bitmap) {
    shaderPaint.shader = BitmapShader(bitmap, Shader.TileMode.CLAMP, Shader.TileMode.CLAMP)
    invalidate()
}

override fun onDraw(canvas: Canvas) {
    canvas.drawRoundRect(0f, 0f, width, height, 20f, 20f, shaderPaint)
}

void setBitmap(Bitmap bitmap) {
    shaderPaint.setShader(
            new BitmapShader(bitmap, TileMode.CLAMP, TileMode.CLAMP));
    invalidate();
}

void onDraw(Canvas canvas) {
    canvas.drawRoundRect(0, 0, width, height, 20, 20, shaderPaint);
}

ऐसा बैकग्राउंड सुरक्षा के लिए भी किया जा सकता है, जैसे कि ग्रेडिएंट बनाते समय और इमेज फ़िल्टर की गई इमेज ColorMatrixColorFilter—दो बिटमैप में बदलाव करते हुए अन्य सामान्य ऑपरेशन किए गए.

यदि आप किसी अन्य कारण से बिटमैप पर आ रहे हैं—तो संभावित रूप से उसका उपयोग कैश मेमोरी—अपने View को पास किए गए हार्डवेयर से तेज़ी के Canvas तक पहुंचने की कोशिश करें या Drawable सीधे. अगर ज़रूरी हो, तो कॉल करने पर भी विचार करें setLayerType() के साथ LAYER_TYPE_HARDWARE जटिल रेंडरिंग आउटपुट को कैश मेमोरी में सेव करने के साथ-साथ, जीपीयू रेंडरिंग का फ़ायदा भी मिलता है.

रेंडरिंग परफ़ॉर्मेंस: RenderThread

Canvas की कुछ कार्रवाइयां रिकॉर्ड करने के लिए सस्ती होती हैं, लेकिन इनसे महंगा कंप्यूटेशन ट्रिगर होता है RenderThread पर. आम तौर पर, Systrace की टीम इन बातों को अलर्ट करती है.

बड़े पाथ को ऐनिमेट करना

टास्क कब शुरू होगा Canvas.drawPath() को हार्डवेयर से तेज़ी लाने वाले Canvas पर कॉल किया जाता है View में, Android इन पाथ को सबसे पहले सीपीयू पर अपलोड करता है और इन्हें जीपीयू पर अपलोड करता है. अगर आपके पाथ बड़े हैं, तो एक फ़्रेम से दूसरे फ़्रेम में उनमें बदलाव करने से बचें, ताकि वे इन्हें कैश मेमोरी में सेव किया जा सकता है और बेहतर तरीके से निकाला जा सकता है. drawPoints() drawLines() और drawRect/Circle/Oval/RoundRect() की मदद से, बेहतर तरीके से काम किया जा रहा है और और ड्रॉ कॉल का भी इस्तेमाल करें.

Canvas.clipPath

clipPath(Path) क्लिप बनाने से जुड़ी ऐसी गतिविधि ट्रिगर होती है जो महंगे प्रॉडक्ट पर लागू होती है. इसलिए, आम तौर पर इससे बचना चाहिए. टास्क कब शुरू होगा संभव है, गैर-आयताकारों पर क्लिप करने के बजाय आकृतियां बनाने का विकल्प चुनें. यह बेहतर परफ़ॉर्म करता है और एंटी-एलियासिंग के साथ काम करता है. उदाहरण के लिए, निम्न clipPath कॉल को अलग तरीके से दिखाया जा सकता है:

canvas.apply {
    save()
    clipPath(circlePath)
    drawBitmap(bitmap, 0f, 0f, paint)
    restore()
}

canvas.save();
canvas.clipPath(circlePath);
canvas.drawBitmap(bitmap, 0f, 0f, paint);
canvas.restore();

इसके बजाय, पिछले उदाहरण को इस तरह से बताएं:

paint.shader = BitmapShader(bitmap, Shader.TileMode.CLAMP, Shader.TileMode.CLAMP)
// At draw time:
canvas.drawPath(circlePath, mPaint)

// One time init:
paint.setShader(new BitmapShader(bitmap, TileMode.CLAMP, TileMode.CLAMP));
// At draw time:
canvas.drawPath(circlePath, mPaint);

बिट मैप अपलोड

Android बिटमैप को OpenGL टेक्सचर के रूप में दिखाता है, और पहली बार कोई बिटमैप एक फ़्रेम में दिखता है, तो वह जीपीयू पर अपलोड हो जाता है. Systrace में यह जानकारी इस तरह देखी जा सकती है टेक्सचर अपलोड(आईडी) चौड़ाई x ऊंचाई. इसमें कई मिलीसेकंड लग सकते हैं, क्योंकि दूसरी इमेज में दिखाया गया है, लेकिन जीपीयू के साथ इमेज दिखाना ज़रूरी है.

अगर इसमें ज़्यादा समय लग रहा है, तो सबसे पहले ट्रेस करें. सुनिश्चित करें कि प्रदर्शित किया जा रहा बिटमैप इससे महत्वपूर्ण बड़ा न हो स्क्रीन का वह हिस्सा जिसमें वह दिख रहा है. अगर ऐसा है, तो इससे वीडियो अपलोड होने में लगने वाला समय बर्बाद होता है और मेमोरी. आम तौर पर, बिटमैप लोडिंग लाइब्रेरी, बिट मैप को उचित आकार में रखता है.

Android 7.0 में, बिट मैप लोडिंग कोड—आमतौर पर लाइब्रेरी द्वारा किया जाता है— prepareToDraw() से ज़रूरत पड़ने से पहले ही वीडियो अपलोड कर दें. इस तरह, वीडियो जल्दी अपलोड हो जाता है जब RenderThread कुछ समय से इस्तेमाल में न हो. डीकोड करने या बाइंडिंग के बाद ऐसा किया जा सकता है जब तक आपको बिटमैप पता है, तब तक आप उसे देख सकते हैं. आम तौर पर, आपका बिट मैप लोड हो रहा हो यह सुविधा इस्तेमाल करने पर आपको यह मदद मिल सकती है. हालांकि, अगर लाइब्रेरी को खुद मैनेज किया जा रहा है या आपको यह पक्का करना है कि नए डिवाइसों पर अपलोड न करें, आप खुद prepareToDraw() पर कॉल कर सकते हैं कोड.

थ्रेड शेड्यूल करने में देरी

थ्रेड शेड्यूलर, Android ऑपरेटिंग सिस्टम का वह हिस्सा है जो यह तय करता है कि सिस्टम में कौनसे थ्रेड चलने चाहिए, कब चलने चाहिए, और कितनी देर तक चलने चाहिए.

कभी-कभी, जैंक आपके ऐप्लिकेशन का यूज़र इंटरफ़ेस (यूआई) थ्रेड ब्लॉक होने या काम न करने की वजह से होता है. तीसरी इमेज के उदाहरण के मुताबिक, Systrace की मदद से अलग-अलग रंगों का इस्तेमाल किया जाता है. इससे यह पता चलता है कि थ्रेड कब ट्रिगर हुआ नींद (सलेटी), रनेबल (नीला: यह चल सकता है, लेकिन अभी चलने वाला शेड्यूलर, सक्रिय रूप से चल रहा है (हरे रंग में) या बिना रुकावट वाली नींद में (लाल या नारंगी). यह जैंक समस्याओं को डीबग करने में बेहद मददगार होता है यह गड़बड़ी, थ्रेड शेड्यूल करने में हुई देरी की वजह से हुई है.

अक्सर, बाइंडर कॉल—इंटर-प्रोसेस कम्यूनिकेशन (आईपीसी) तकनीक Android—इस वजह से आपका ऐप्लिकेशन काम नहीं करता. Android के बाद के वर्शन में, यह यूज़र इंटरफ़ेस (यूआई) थ्रेड के रुक जाने की सबसे सामान्य वजहों में से एक है. आम तौर पर, बाइंडर कॉल करने वाले फ़ंक्शन को कॉल करने से बचना है. अगर यह है सेव नहीं किया जा सकता, वैल्यू को कैश मेमोरी में सेव करें या काम को बैकग्राउंड थ्रेड में ले जाएं. कोड बेस के तौर पर साइज़ बड़ा हो जाता है, तो कुछ लो-लेवल का इस्तेमाल करके गलती से बाइंडर कॉल भी जोड़ी जा सकती है का इस्तेमाल करें. हालांकि, ट्रेसिंग की मदद से उन्हें ढूंढा और ठीक किया जा सकता है.

अगर आपके पास बाइंडर ट्रांज़ैक्शन हैं, तो उनके कॉल स्टैक को adb निर्देशों का पालन किया जा रहा है:

$ adb shell am trace-ipc start
… use the app - scroll/animate ...
$ adb shell am trace-ipc stop --dump-file /data/local/tmp/ipc-trace.txt
$ adb pull /data/local/tmp/ipc-trace.txt

कभी-कभी छोटी सी लगने वाली कॉल, जैसे getRefreshRate(), यह कर सकते हैं: बाइंडर ट्रांज़ैक्शन को ट्रिगर करते हैं. इससे कॉल किए जाने पर बड़ी समस्याएं होती हैं अक्सर. समय-समय पर ट्रेस करने से, इन समस्याओं का पता लगाने और उन्हें ठीक करने में मदद मिलती है को दिखाना.

अगर आपको बाइंडर गतिविधि नहीं दिख रही है, लेकिन यूज़र इंटरफ़ेस (यूआई) थ्रेड नहीं चल रहा है, तो पक्का करें कि किसी दूसरे थ्रेड के लॉक या दूसरी कार्रवाई का इंतज़ार नहीं किया जा रहा हो. आम तौर पर, यूज़र इंटरफ़ेस (यूआई) थ्रेड को दूसरे थ्रेड के नतीजों के लिए इंतज़ार नहीं करना पड़ता. दूसरे थ्रेड को इसमें जानकारी पोस्ट करनी होगी.

ऑब्जेक्ट असाइन करना और कचरा इकट्ठा करना

ऑब्जेक्ट असाइन करने और गार्बेज कलेक्शन (जीसी) से जुड़ी समस्याएं बहुत कम हैं क्योंकि ART को Android 5.0 में डिफ़ॉल्ट रनटाइम के रूप में पेश किया गया था, लेकिन यह अब भी इस अतिरिक्त काम की मदद से आपके थ्रेड को अहमियत दी जा सकती है. अपने हिसाब से, ऑडियंस सेगमेंट में यह किसी ऐसी दुर्लभ घटना के जवाब में होता है जो एक सेकंड में कई बार नहीं होती—जैसे एक बटन पर टैप करते हैं—लेकिन याद रखें कि हर बजट के लिए लागत होती है. अगर आपने यह लूप में है, जिसे बार-बार कॉल किया जाता है. इसलिए, बजट को कम करने के लिए मशीन लर्निंग का इस्तेमाल करें.

Systrace आपको दिखाता है कि क्या GC अक्सर चल रहा है और Android मेमोरी प्रोफ़ाइलर से आपको पता चल सकता है कि बजट कहां-कहां असाइन हुए हैं कहां से आ रही हैं. अगर हो सके, तो बजट को तय करने से बचें. खास तौर पर तब, जब ऐसा हो लूप होता है, तो आपको समस्याएं होने की संभावना कम होती है.

Android के नए वर्शन पर, GC आम तौर पर HeapTaskDaemon पर टैप करें. ज़्यादा असाइन होने का मतलब है ज़्यादा सीपीयू पर खर्च किए गए संसाधनों को बेहतर तरीके से कैसे दिखाता है, जैसा कि पांचवीं इमेज में दिखाया गया है.