हार्डवेयर से तेज़ी लाने की सुविधा

Android 3.0 (एपीआई लेवल 11) से शुरू होने वाले, Android 2D रेंडरिंग पाइपलाइन, हार्डवेयर के साथ काम करती है एक्सीलरेशन का मतलब है कि जो ड्रॉइंग प्रोसेस की जाती हैं वे View का कैनवस, जीपीयू का इस्तेमाल करता है. ऐसा इसलिए है, क्योंकि इस सुविधा को चालू करने के लिए ज़्यादा संसाधनों की ज़रूरत होती है हार्डवेयर की मदद से तेज़ी लाने पर, आपका ऐप्लिकेशन ज़्यादा रैम का इस्तेमाल करेगा.

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

अगर आपका ऐप्लिकेशन कस्टम ड्रॉइंग करता है, तो असल हार्डवेयर डिवाइसों पर अपने ऐप्लिकेशन की जांच करें हार्डवेयर से तेज़ी लाने की सुविधा चालू करके, किसी भी समस्या का पता लगाया जा सकता है. ड्रॉइंग ऑपरेशन के लिए सहायता सेक्शन, हार्डवेयर से तेज़ी लाने और उन्हें ठीक करने का तरीका.

फ़्रेमवर्क एपीआई के साथ OpenGL भी देखें और रेंडरस्क्रिप्ट का इस्तेमाल करें

हार्डवेयर की मदद से तेज़ी लाने की सुविधा कंट्रोल करना

हार्डवेयर की मदद से तेज़ी लाने को इन लेवल पर कंट्रोल किया जा सकता है:

• आवेदन सबमिट करना
• गतिविधि
• विंडो
• देखें

ऐप्लिकेशन लेवल

अपनी Android मेनिफ़ेस्ट फ़ाइल में, नीचे दी गई विशेषता को हार्डवेयर की मदद से तेज़ी लाने के लिए, <application> टैग ऐप्लिकेशन:

<application android:hardwareAccelerated="true" ...>

गतिविधि का लेवल

अगर आपका ऐप्लिकेशन, दुनिया भर में हार्डवेयर से तेज़ी लाने की सुविधा चालू करने पर, ठीक तरह से काम नहीं करता है, तो साथ ही, वे इसे अलग-अलग गतिविधियों के लिए कंट्रोल कर सकते हैं. इस पर हार्डवेयर एक्सेलरेटर को चालू या बंद करने के लिए गतिविधि के लेवल पर, android:hardwareAccelerated एट्रिब्यूट का इस्तेमाल <activity> एलिमेंट. नीचे दिया गया उदाहरण, हार्डवेयर से तेज़ी लाने की सुविधा को चालू करता है पूरी ऐप्लिकेशन को डाउनलोड करता है, लेकिन उसे एक गतिविधि के लिए बंद कर देता है:

<application android:hardwareAccelerated="true">
    <activity ... />
    <activity android:hardwareAccelerated="false" />
</application>

विंडो लेवल

अगर आपको ज़्यादा बेहतर कंट्रोल की ज़रूरत है, तो दिए गए उदाहरण के लिए, हार्डवेयर से तेज़ी लाने की सुविधा चालू की जा सकती है विंडो:

Kotlin

window.setFlags(
        WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED,
        WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED
)

Java

getWindow().setFlags(
    WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED,
    WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED);

ध्यान दें: फ़िलहाल, यहां पर हार्डवेयर की मदद से तेज़ी लाने की सुविधा बंद नहीं की जा सकती विंडो के लेवल पर.

व्यू लेवल

रनटाइम के दौरान, अलग-अलग व्यू के लिए हार्डवेयर की मदद से तेज़ी लाने की सुविधा को बंद किया जा सकता है. इसके लिए, यह कोड डालें:

Kotlin

myView.setLayerType(View.LAYER_TYPE_SOFTWARE, null)

Java

myView.setLayerType(View.LAYER_TYPE_SOFTWARE, null);

ध्यान दें: फ़िलहाल, आप इस डिवाइस पर हार्डवेयर से तेज़ी लाने की सुविधा चालू नहीं कर सकते: व्यू लेवल पर जाएं. व्यू लेयर में, हार्डवेयर की मदद से तेज़ी लाने की सुविधा को बंद करने के अलावा, अन्य फ़ंक्शन भी होते हैं. लेयर के इस्तेमाल के बारे में ज़्यादा जानने के लिए, लेयर देखें पर जाएं.

देखें कि कोई व्यू हार्डवेयर ऐक्सेलरेटेड है या नहीं

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

यह देखने के दो अलग-अलग तरीके हैं कि ऐप्लिकेशन हार्डवेयर ऐक्सेलरेटेड है या नहीं:

• View.isHardwareAccelerated() का शुल्क देकर, प्रॉडक्ट को लौटाया जा सकता है अगर View हार्डवेयर ऐक्सेलरेटेड हार्डवेयर से जुड़ा है, तो true विंडो.
• Canvas.isHardwareAccelerated() अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है अगर Canvas के हार्डवेयर की मदद से रफ़्तार बढ़ाई गई है, तो true दिखाता है

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

Android ड्रॉइंग मॉडल

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

सॉफ़्टवेयर-आधारित ड्रॉइंग मॉडल

सॉफ़्टवेयर ड्रॉइंग मॉडल में, व्यू नीचे दिए गए दो चरणों के हिसाब से बनाए जाते हैं:

1. हैरारकी को अमान्य करें
2. हैरारकी बनाने का तरीका

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

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

ध्यान दें: जब Android व्यू की प्रॉपर्टी में बदलाव होता है, तो वे अपने-आप invalidate() को कॉल कर देते हैं, जैसे कि बैकग्राउंड रंग या TextView में टेक्स्ट.

हार्डवेयर ऐक्सेलरेटेड ड्रॉइंग मॉडल

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

1. हैरारकी को अमान्य करें
2. डिसप्ले सूचियों को रिकॉर्ड और अपडेट करें
3. डिसप्ले सूचियां बनाएं

इस मॉडल में, गंदे इलाके को इंटरसेक्ट करने वाले व्यू पर भरोसा नहीं किया जा सकता, ताकि इसके draw() तरीके को लागू किया जा सके. यह पक्का करने के लिए कि Android सिस्टम की प्रदर्शन सूची देखना चाहते हैं, तो आपको invalidate() को कॉल करना होगा. भूलना ऐसा करने से व्यू बदलने के बाद भी वह एक जैसा ही दिखता है.

डिसप्ले सूचियों का इस्तेमाल करने से ऐनिमेशन की परफ़ॉर्मेंस भी बेहतर होती है, क्योंकि खास प्रॉपर्टी सेट करके, जैसे ऐल्फ़ा या रोटेशन के लिए टारगेट किए गए व्यू को अमान्य करने की ज़रूरत नहीं होती है (ऐसा हो चुका है स्वचालित रूप से). यह ऑप्टिमाइज़ेशन प्रदर्शन सूचियों वाले दृश्यों पर भी लागू होता है (कोई भी दृश्य जब ऐप्लिकेशन हार्डवेयर से तेज़ी से काम करता है.) उदाहरण के लिए, मान लें कि एक LinearLayout है, जिसमें Button से ऊपर ListView मौजूद है. LinearLayout की डिसप्ले सूची ऐसी दिखती है शामिल करें:

• DrawDisplayList(ListView)
• DrawDisplayList(बटन)

अब मान लें कि आपको ListView की ओपैसिटी बदलनी है. इस तारीख के बाद ListView पर setAlpha(0.5f) शुरू हो रहा है, डिसप्ले सूची में अभी इसमें यह शामिल है:

• सेवलेयरऐल्फ़ा(0.5)
• DrawDisplayList(ListView)
• वापस लाएं
• DrawDisplayList(बटन)

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

ड्रॉइंग से जुड़े कामों में मदद पाना

हार्डवेयर ऐक्सेलरेटेड होने पर, 2D रेंडरिंग पाइपलाइन आम तौर पर सबसे ज़्यादा इस्तेमाल होने वाली चीज़ों के साथ काम करती है Canvas ड्रॉइंग ऑपरेशन और कम इस्तेमाल होने वाली कार्रवाइयां. सभी ऐसी ड्रॉइंग कार्रवाइयां जिनका इस्तेमाल Android के साथ शिप होने वाले ऐप्लिकेशन को रेंडर करने के लिए किया जाता है, डिफ़ॉल्ट विजेट साथ ही, बेहतर विज़ुअल इफ़ेक्ट, जैसे कि रिफ़्लेक्शन और टाइल वाली बनावटें भी हैं. समर्थित हैं.

नीचे दी गई टेबल में, एपीआई लेवल पर अलग-अलग तरह की कार्रवाइयां पूरी करने के लेवल की जानकारी दी गई है:

	पहला काम करने वाला एपीआई लेवल
कैनवस
createBitmapMash() (कलर अरे)	18
ड्रॉपिक्चर()	23
ड्रॉपॉज़ टेक्स्ट()	16
ड्रॉTextOnPath()	16
ड्रॉवर्टिस()	29
setDrawFilter()	16
क्लिपपाथ()	18
क्लिपक्षेत्र()	18
क्लिपRect(Region.Op.XOR)	18
क्लिपआरेक्ट(क्षेत्र.ऑप.अंतर)	18
क्लिपआरेक्ट(Region.Op.Reverse खासियत)	18
रोटेशन/पर्सपेक्टिव के साथClipRect()	18
पेंट
setAntiAlias() (टेक्स्ट के लिए)	18
setAntiAlias() (लाइनों के लिए)	16
setFilterBitmap()	17
सेटलीनियर टेक्स्ट()	✗
setMaskFilter()	✗
setPathimpact() (लाइनों के लिए)	28
setShadowlayer() (टेक्स्ट के अलावा)	28
setStrokeCap() (लाइनों के लिए)	18
setStrokeCap() (पॉइंट के लिए)	19
setSubpixelText()	28
एक्सफ़रमोड
PorterDuff.Mode.DARKEN (फ़्रेमबफ़र)	28
PorterDuff.Mode.LIGHTEN (फ़्रेमबफ़र)	28
PorterDuff.Mode.OVERLAY (फ़्रेमबफ़र)	28
शेडर
ComposeShader में ComposeShader	28
ComposeShader में एक ही तरह के शेडर	28
ComposeShader पर स्थानीय मैट्रिक्स	18

कैनवस स्केलिंग

हार्डवेयर ऐक्सेलरेटेड 2D रेंडरिंग पाइपलाइन को सबसे पहले बिना स्केल किए गए ड्रॉइंग के साथ काम करने के लिए बनाया गया था, और ड्रॉइंग से जुड़ी कुछ कार्रवाइयों की वजह से, क्वालिटी बहुत खराब हो गई. ये ऑपरेशन को 1.0 स्केल पर बनाई गई टेक्सचर के तौर पर लागू किया जाता है, जो जीपीयू से बदलता है. एपीआई में शुरू किया जा रहा है लेवल 28 पर, ड्रॉइंग से जुड़ी सभी कार्रवाइयां बिना किसी समस्या के बढ़ सकती हैं.

नीचे दी गई टेबल से पता चलता है कि बड़े स्केल को सही तरीके से हैंडल करने के लिए, लागू करने की प्रक्रिया को कब बदला गया था:

ड्रॉइंग कार्रवाई को स्केल किया जाना है	पहला काम करने वाला एपीआई लेवल
ड्रॉइंग टेक्स्ट()	18
ड्रॉपॉज़ टेक्स्ट()	28
ड्रॉTextOnPath()	28
सिंपल शेप*	17
कॉम्प्लेक्स शेप*	28
ड्रॉपाथ()	28
शैडो लेयर	28

ध्यान दें: 'आसान' आकृतियां drawRect() हैं, drawCircle(), drawOval(), drawRoundRect(), और drawArc() (useCenter=false) के साथ ऐसे पेंट के साथ जारी किए गए आदेश जिसमें पाथइफ़ेक्ट है और इसमें ऐसे नॉन-डिफ़ॉल्ट जॉइन नहीं हैं जो setStrokeJoin() / के ज़रिए जुड़े हैं setStrokeMiter()). उन ड्रॉ कमांड के अन्य उदाहरण 'कॉम्प्लेक्स' के अंतर्गत आते हैं, इंच ऊपर दिया गया चार्ट.

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

लेयर देखें

Android के सभी वर्शन में, व्यू को ऑफ़-स्क्रीन बफ़र में रेंडर करने की सुविधा दी गई है, या तो व्यू की ड्रॉइंग कैश मेमोरी का इस्तेमाल करके या Canvas.saveLayer() का इस्तेमाल करके. ऑफ़-स्क्रीन बफ़र या लेयर के कई इस्तेमाल होते हैं. इन रणनीतियों का इस्तेमाल करके, ये सारे काम किए जा सकते हैं बेहतर परफ़ॉर्मेंस के लिए इस्तेमाल किया जा सकता है. उदाहरण के लिए, कुछ समय के लिए किसी व्यू को रेंडर करने के लिए, Canvas.saveLayer() का इस्तेमाल करके फ़ेड इफ़ेक्ट लागू किए जा सकते हैं और फिर ओपैसिटी फ़ैक्टर के साथ स्क्रीन पर वापस कंपोज़िट करें.

Android 3.0 (एपीआई लेवल 11) से, लेयर का इस्तेमाल करने के तरीके और समय के बारे में आपको ज़्यादा कंट्रोल मिलता है View.setLayerType() तरीके से. इस API में दो पैरामीटर: जिस लेयर का इस्तेमाल करना है और वैकल्पिक Paint ऑब्जेक्ट है जो बताता है कि लेयर को कैसे कंपोज़ किया जाना चाहिए. कलर फ़िल्टर, खास ब्लेंडिंग मोड या ओपैसिटी (अपारदर्शिता) को लागू करने के लिए, Paint पैरामीटर का इस्तेमाल किया जा सकता है लेयर. व्यू, इन तीन लेयर में से किसी एक टाइप का इस्तेमाल कर सकता है:

• LAYER_TYPE_NONE: व्यू सामान्य रूप से रेंडर किया जाता है और इसका बैक अप नहीं लिया जाता को सही तरीके से सेट नहीं किया जा सकता. यह डिफ़ॉल्ट व्यवहार है.
• LAYER_TYPE_HARDWARE: व्यू को हार्डवेयर में हार्डवेयर टेक्सचर, अगर ऐप्लिकेशन हार्डवेयर ऐक्सेलरेटेड है. अगर ऐप्लिकेशन हार्डवेयर नहीं है ऐक्सेलरेटेड, यह लेयर टाइप LAYER_TYPE_SOFTWARE की तरह ही काम करता है.
• LAYER_TYPE_SOFTWARE: व्यू को सॉफ़्टवेयर की मदद से रेंडर किया जाता है बिट मैप.

जिस तरह की लेयर का इस्तेमाल किया जाता है वह आपके लक्ष्य पर निर्भर करता है:

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

लेयर और ऐनिमेशन देखें

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

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

• alpha: लेयर की ओपैसिटी बदलता है
• x, y, translationX, translationY: लेयर की पोज़िशन बदलें
• scaleX, scaleY: लेयर का साइज़ बदलता है
• rotation, rotationX, rotationY: यह 3D स्पेस में लेयर का ओरिएंटेशन
• pivotX, pivotY: लेयर के ट्रांसफ़ॉर्मेशन का ऑरिजिन बदलता है

इन प्रॉपर्टी का इस्तेमाल, ObjectAnimator वाले व्यू को ऐनिमेट करते समय किया जाता है. अगर आपको इन प्रॉपर्टी का ऐक्सेस चाहिए, तो सेटर या गेटर. उदाहरण के लिए, ऐल्फ़ा प्रॉपर्टी में बदलाव करने के लिए, setAlpha() को कॉल करें. नीचे दिया गया कोड स्निपेट, सबसे सही तरीके से Y-ऐक्सिस के चारों ओर व्यूव्यू को 3D में घुमाने के लिए:

Kotlin

view.setLayerType(View.LAYER_TYPE_HARDWARE, null)
ObjectAnimator.ofFloat(view, "rotationY", 180f).start()

Java

view.setLayerType(View.LAYER_TYPE_HARDWARE, null);
ObjectAnimator.ofFloat(view, "rotationY", 180).start();

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

Kotlin

view.setLayerType(View.LAYER_TYPE_HARDWARE, null)
ObjectAnimator.ofFloat(view, "rotationY", 180f).apply {
    addListener(object : AnimatorListenerAdapter() {
        override fun onAnimationEnd(animation: Animator) {
            view.setLayerType(View.LAYER_TYPE_NONE, null)
        }
    })
    start()
}

Java

view.setLayerType(View.LAYER_TYPE_HARDWARE, null);
ObjectAnimator animator = ObjectAnimator.ofFloat(view, "rotationY", 180);
animator.addListener(new AnimatorListenerAdapter() {
    @Override
    public void onAnimationEnd(Animator animation) {
        view.setLayerType(View.LAYER_TYPE_NONE, null);
    }
});
animator.start();

प्रॉपर्टी ऐनिमेशन के बारे में ज़्यादा जानकारी के लिए, प्रॉपर्टी ऐनिमेशन देखें.

सुझाव और तरकीबें

हार्डवेयर ऐक्सेलरेटेड 2D ग्राफ़िक्स में स्विच करने से प्रदर्शन तुरंत बढ़ सकता है, लेकिन को अब भी नीचे दिए गए निर्देशों का पालन करके, जीपीयू का असरदार तरीके से इस्तेमाल करने के लिए अपने ऐप्लिकेशन को डिज़ाइन करना चाहिए सुझाव:

अपने ऐप्लिकेशन के व्यू की संख्या कम करना

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

ओवरड्रॉ से बचना

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

ड्रॉ करने के तरीकों में, रेंडर होने वाले ऑब्जेक्ट न बनाएं

जब भी रेंडरिंग का कोई तरीका शुरू किया जाए, तो एक नया Paint या नया Path बनाना एक आम गलती है. इससे कचरा फैलता है कलेक्टर का इस्तेमाल करता है और हार्डवेयर में कैश मेमोरी और ऑप्टिमाइज़ेशन को बायपास करता है. पाइपलाइन.

आकारों में बार-बार बदलाव न करें

उदाहरण के लिए, जटिल आकार, पाथ, और सर्कल, टेक्सचर मास्क का इस्तेमाल करके रेंडर किए जाते हैं. कई जब कोई पाथ बनाया या उसमें बदलाव किया जाता है, तो हार्डवेयर पाइपलाइन एक नया मास्क बनाती है. इसे महंगा.

बिटमैप में बार-बार बदलाव न करें

जब भी बिट मैप का कॉन्टेंट बदला जाता है, तो यह जीपीयू टेक्सचर के तौर पर फिर से अपलोड हो जाता है अगली बार जब आप उसे ड्रॉ करेंगे.

ऐल्फ़ा का इस्तेमाल सावधानी से करें

जब setAlpha() का इस्तेमाल करके, किसी व्यू को ट्रांसलूसंट बनाया जाता है, AlphaAnimation या ObjectAnimator, यह को ऑफ़-स्क्रीन बफ़र में रेंडर किया जाता है, जो ज़रूरी फ़िल रेट को दोगुना कर देता है. ऐल्फ़ा वर्शन लागू करते समय बहुत बड़े व्यू के लिए, व्यू के लेयर टाइप को LAYER_TYPE_HARDWARE.