अलाइन किए गए इनपुट इवेंट

डेव तापुस्का
डेव तापुस्का

बहुत ज़्यादा शब्द हैं, पढ़ा नहीं गया

  • Chrome 60, इवेंट की फ़्रीक्वेंसी को कम करके जैंक को कम करता है, जिससे फ़्रेम टाइम को एक जैसा बनाए रखने में मदद मिलती है.
  • Chrome 58 में पेश की गई getCoalescedEvents() पद्धति, आपके पास इवेंट से जुड़ी वही जानकारी है, जो आपके पास थी.

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

हम Chrome 60 में, बेहतर परफ़ॉर्मेंस और बेहतर परफ़ॉर्मेंस के लिए बदलाव कर रहे हैं. इसकी वजह से, ये इवेंट कम फ़्रीक्वेंसी पर होते हैं. साथ ही, उपलब्ध कराई गई जानकारी का लेवल भी बढ़ जाता है. ठीक उसी तरह, जब जेली बीन रिलीज़ हुए और उन्होंने कोरियोग्राफ़र को लाया

हालांकि, कभी-कभी आपको ज़्यादा इवेंट की भी ज़रूरत होती है. इसलिए, Chrome 58 में, हमने getCoalescedEvents() नाम का एक तरीका लागू किया है. इसकी मदद से, आपका ऐप्लिकेशन कम इवेंट मिलने के बावजूद, पॉइंटर का पूरा पाथ फिर से हासिल कर सकता है.

चलिए, पहले इवेंट की फ़्रीक्वेंसी के बारे में बात करते हैं.

इवेंट की फ़्रीक्वेंसी कम की जा रही है

आइए, कुछ बुनियादी बातों को समझते हैं: टच-स्क्रीन 60-120 हर्ट्ज़ पर इनपुट डिलीवर करती है और माउस आम तौर पर 100 हर्ट्ज़ पर इनपुट डिलीवर करते हैं. हालांकि, इनपुट 2,000 हर्ट्ज़ तक हो सकते हैं. हालांकि, मॉनिटर की आम तौर पर रीफ़्रेश दर 60 हर्ट्ज़ है. तो, इसका क्या मतलब है? इसका मतलब है कि हमें डिसप्ले अपडेट की तुलना में ज़्यादा दर पर इनपुट मिलते हैं. आइए, अब एक आसान कैनवस पेंटिंग ऐप्लिकेशन के लिए, DevTools की परफ़ॉर्मेंस टाइमलाइन पर नज़र डालते हैं.

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

परफ़ॉर्मेंस की टाइमलाइन, जिसमें फ़्रेम टाइम अलग-अलग दिख रहा है

तो हम ऐसे अतिरिक्त काम क्यों कर रहे हैं जिससे कोई विज़ुअल अपडेट नहीं होता? आम तौर पर, हम ऐसा कोई काम नहीं करना चाहेंगे जिससे उपयोगकर्ता को कोई फ़ायदा न हो. Chrome 60 में, इनपुट पाइपलाइन से लगातार इवेंट (wheel, mousewheel, touchmove, pointermove, mousemove) डिस्पैच करने में देरी होगी और requestAnimationFrame() कॉलबैक होने से ठीक पहले उन्हें भेजा जाएगा. नीचे दी गई तस्वीर में (सुविधा चालू होने पर) आपको ज़्यादा समान फ़्रेम टाइम और कम समय में प्रोसेस होने वाले इवेंट दिखते हैं.

हम कैनरी और डेव चैनलों पर इस सुविधा को चालू करने के लिए एक प्रयोग चला रहे हैं. इससे हमें पता चला कि हम 35% कम हिट टेस्ट करते हैं, जिसकी वजह से मुख्य थ्रेड को ज़्यादा बार चलाने के लिए तैयार किया जा सकता है.

वेब डेवलपर को यह पता होना चाहिए कि जो भी अलग-अलग इवेंट हैं (जैसे कि keydown, keyup, mouseup, mousedown, touchstart, touchend), उन्हें किसी भी बाकी इवेंट के साथ तुरंत भेज दिया जाएगा, जिससे मिलते-जुलते इवेंट का क्रम बना रहेगा. इस सुविधा के चालू होने पर, बहुत सारा काम सामान्य इवेंट लूप फ़्लो में व्यवस्थित हो जाता है. इससे, इनपुट इंटरवल में लगातार सुधार होता है. इससे scroll और resize इवेंट के साथ लगातार इवेंट इनलाइन होते रहते हैं, जिन्हें Chrome में इवेंट लूप फ़्लो में पहले से ही व्यवस्थित किया जा चुका है.

परफ़ॉर्मेंस की टाइमलाइन, जो फ़्रेम टाइम के हिसाब से एक जैसी है.

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

getCoalescedEvents() तरीका

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

स्टैंडर्ड और एक जैसे इवेंट की तुलना की जा रही है.

किसी एक इवेंट को पाने के बजाय, उन पुराने इवेंट के कलेक्शन को ऐक्सेस करें जिनकी वजह से इवेंट हुआ है. Android, iOS, और Windows सभी के नेटिव SDK टूल में काफ़ी मिलते-जुलते एपीआई हैं. इसलिए, हम वेब पर भी इससे मिलता-जुलता एपीआई उपलब्ध करा रहे हैं.

आम तौर पर, ड्रॉइंग ऐप्लिकेशन ने इवेंट पर ऑफ़सेट देखकर कोई पॉइंट बनाया हो सकता है:

window.addEventListener("pointermove", function(event) {
    drawPoint(event.pageX, event.pageY);
});

इवेंट के कलेक्शन का इस्तेमाल करने के लिए, इस कोड को आसानी से बदला जा सकता है:

window.addEventListener("pointermove", function(event) {
    var events = 'getCoalescedEvents' in event ? event.getCoalescedEvents() : [event];
    for (let e of events) {
    drawPoint(e.pageX, e.pageY);
    }
});

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