⌛ पुनर्कथन समय

अपने पिछले ब्लॉग में मैंने इस बारे में बात की थी कि कैसे मैंने केवल 2 सप्ताह में अपने ऐप का आकार 75एमबी से घटाकर 34एमबी कर दिया (देखें!)। लेकिन इतना ही नहीं, मैंने अपने ऐप के समग्र प्रदर्शन में भी 80% तक सुधार किया है?

आइये जानें कैसे!!

? विद्या

एक साधारण दौर की सैर के बाद मुझे हमारे ऐप में कुछ शीर्ष स्तरीय मुद्दों का पता चला, जो खराब उपयोगकर्ता अनुभव और अकेले प्रदर्शन का कारण बने। क्या दिन है!

• मुख्य खलनायक - रीयलटाइम प्रतिक्रिया उत्पन्न करते समय संपूर्ण ऐप यूआई फ़्रीज़ हो गया

• साइड विलेन - धीमी प्रतिक्रिया समय और कोई फ्रेम दर नहीं

• खलनायक का प्रेमी - बहुत सारे एपीआई कॉल

• द अनडेड आर्मी - ख़राब त्रुटि प्रबंधन और क्रैश

• दुख - अधिक सीपीयू उपयोग और सर्वर लागत

• कलंकित - मैं !

इसलिए बेहतर विश्व की आशा के साथ ब्रह्मांड के पुनर्निर्माण की बेजान लड़ाई शुरू होती है।

ताहिती योजना (लेकिन इस बार यह काम करती है)

इसलिए मैंने सबसे पहले आसान समस्याओं से निपटना शुरू किया क्योंकि महान अवसाद से तुरंत लड़ने की तुलना में उसे नजरअंदाज करना आसान है।

1. ⚛️ प्रतिक्रिया का अभिशाप

ReactJs की बुद्धि और अभिशाप बताता है। जैसे-जैसे हम रिएक्ट में बड़े होते हैं, हमें एहसास होता है कि जितनी कम स्थितियाँ होंगी, एप्लिकेशन उतना ही बेहतर होगा। इसलिए कला का यह विशेष टुकड़ा एक ही चैट स्क्रीन में 22 (हाँ भगवान 22 स्टेट्स का उपयोग करता है) का उपयोग कर रहा था जहाँ आप केवल संदेश भेज सकते हैं और संदेश प्राप्त कर सकते हैं।

शीर्ष पर चेरी !
हम सर्वर से चंक-दर-चंक डेटा प्राप्त करने के लिए सर्वर साइड इवेंट कार्यान्वयन का उपयोग कर रहे थे, जो कि शब्द-दर-शब्द था। तो यदि आपके पास कोई प्रश्न है जिसका उत्तर 100 शब्दों में है (यह कम से कम उत्तर है)। इसे वास्तव में 100 इवेंट प्राप्त होंगे।

इसलिए यदि आप गणित जानते हैं, तो 100*22 = 2200 पुन: प्रस्तुत करता है हर बार जब हमें कोई प्रतिक्रिया मिलती है।

क्या मुझे और कुछ समझाना होगा? ( नहीं )

इसलिए मैंने पूरी स्क्रीन को फिर से बनाना शुरू किया और संख्या को घटाकर अब 6 राज्य कर दिया। पहले की तरह बेहतर और सुचारू कार्यक्षमता के साथ।

यह पिछले से 72% अधिक प्रदर्शन करने वाला है !!

2. ❄️ जमा हुआ रेगिस्तान

अब रिएक्ट के राडाहन को देखने के बाद, हम आसानी से यह निष्कर्ष निकाल सकते हैं कि ऐप काफी हद तक फ्रीज होने वाला है?

अब 6 राज्यों के साथ भी, मुख्य मुद्दा वही है 100*6। हम अभी भी लटके हुए हैं लेकिन कम राज्यों के साथ।

मुख्य कारण था, प्रत्येक भाग पर रिएक्ट डोम का अद्यतन होना। इसलिए इससे निपटने के लिए हमने "बैच प्रोसेसिंग और फ़्रेम रेट जेनरेशन का उपयोग किया।

अरे हाँ !

इसलिए मूल रूप से हर बार जब हमें एक टुकड़ा मिलता है तो DOM को अपडेट करने के बजाय, हम टुकड़े के बैच बना रहे थे और इसे एक निश्चित गतिशील फ्रेम दर में अपडेट कर रहे थे। ये फ्रेम दर ओएस से बुलाए गए थे, इसलिए प्रत्येक डिवाइस में सिस्टम क्षमता के अनुसार एक अलग एफपीएस होगा जो ऐप को अधिक मजबूत और संगत प्रदर्शन देगा।

हमने एक बैच में टुकड़ों का एक सीमित सेट कैप्चर किया और फ्रेम जारी होने तक प्रतिक्रिया को रोके रखा और सभी टुकड़ों के संसाधित होने तक इसे दोहराया।

इसलिए DOM को 100 बार अपडेट करने के बजाय हमने DOM को केवल 3-4 बार अपडेट किया।

अब गणित करें और होमवर्क के लिए प्रदर्शन वृद्धि की गणना करें!

3. ? एक अच्छा श्रोता होना !

गर्लफ्रेंड बनाना मेरे लिए काम नहीं आया, लेकिन ऐप को काफी बेहतर बनाने में जरूर कामयाब रहा।

एपीआई डेटा प्राप्त करने का अच्छा और अच्छा तरीका है लेकिन उनका बुद्धिमानी से उपयोग करना आपका अपना कौशल है! अब यह ऐप बैकएंड से उपयोगकर्ता की स्थिति जानने के लिए इस एपीआई का उपयोग कर रहा था। लेकिन सबसे अच्छी बात यह है कि इसे हर 3 सेकंड में इस्तेमाल किया जा रहा था !!

मैं समझ गया, डेवलपर के मन में असुरक्षाएं थीं लेकिन कार्य-जीवन संतुलन लाने से उनका मतलब यह नहीं था।

क) लाना

हर बार जब उपयोगकर्ता ऐप का उपयोग करता है तो उपयोगकर्ता डेटा प्राप्त करने के लिए, ऐप शुरू होने पर कॉल करना होता है या हर बार ऐप को हाल ही में (ऐप स्टेट श्रोता) से कॉल किया जाता है। इसे हर 3 सेकंड में कॉल करने से न केवल मोबाइल संसाधनों का अनंत स्ट्रीम में उपयोग होता है, बल्कि सर्वर ओवरहेड भी होता है।

100 उपयोगकर्ताओं से 100 अनुरोध प्राप्त करने के बजाय, सर्व को 1 उपयोगकर्ता से 100 अनुरोध प्राप्त होंगे। यह मुझे बहुत स्केलेबल और विश्वसनीय नहीं लगता।

साथ ही यह अप्राप्य मेमोरी लीक और उपयोग बनाता है जो लंबे समय तक उपयोग में समस्या पैदा करता है।

बी) डेटा प्रवाह

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

मैंने सुनिश्चित किया कि डेटा कैश हो जाए और प्रवाह में रैखिक रूप से प्रवाहित हो जाए और एपीआई को केवल तभी कॉल किया जाता है जब ताजा उदाहरण के लिए आवश्यक हो।

याद रखने योग्य बिंदु !

इसके परिणामस्वरूप सर्वर का स्वास्थ्य बेहतर हुआ और बहुत अधिक एपीआई अनुरोधों के कारण हमारे बैकएंड के लिए डाउनटाइम कम हुआ। चूंकि कंपनी को बैकएंड चलाने में लागत आती है, इसलिए एपीआई का प्रभावी ढंग से और केवल जरूरत पड़ने पर उपयोग करना महत्वपूर्ण है

न केवल बैकएंड के लिए बल्कि फ्रंटएंड के लिए भी, अतिरिक्त एपीआई कॉल करने से यह अधिक सिस्टम खपत वाला हो जाता है क्योंकि हर बार जब आप कॉल करते हैं तो इसे अधिक HTTP हैंडशेक और प्रोटोकॉल करना पड़ता है।

3. ? यदि हम इसे स्वीकार नहीं करते तो यह कोई त्रुटि नहीं है!

एपीआई को संभालने के लिए महत्वपूर्ण चीजों में से एक है, त्रुटियां। उन्हें लॉग में सांत्वना देना पर्याप्त नहीं है क्योंकि यह उपयोगकर्ता के अनुभव को उनके अच्छे उपयोग से कहीं अधिक खराब बना देता है।

किसी प्रकार की फीडबैक प्रणाली का उपयोग करके किसी भी कार्रवाई से होने वाली त्रुटियों को संभालना महत्वपूर्ण है। यह अलर्ट या पॉपअप या टोस्ट या कुछ भी हो सकता है। लेकिन उपयोगकर्ता को पता होना चाहिए कि ऐसा क्यों और कैसे हुआ ताकि वे इसकी रिपोर्ट कर सकें या कम से कम यह जान सकें कि उन्होंने क्या गलत किया!

4. ? उसकी यादें

गॉटचा होमी! वह वापस नहीं आ रही है लेकिन यादें लीक हो जाएंगी। किसी भी श्रोता या एपीआई कॉल को संलग्न करते समय हम जो मुख्य बात भूल जाते हैं, वह उस गतिविधि को बंद करने के बाद उसका उदाहरण हटाना है।

इस ऐप में टोन था, गतिविधि बंद होने या पृष्ठभूमि में होने के बाद भी एपीआई कॉल की जा रही थी। अनावश्यक CPU उपयोग और संसाधनों की खपत के कारण ऐप अधिक सुस्त और उपयोग में कठिन हो जाता है।

इनकी उचित सफाई ऐप को अधिक तेज़ और कम ओवरहेडिंग बनाती है।

5. प्रदर्शन की घोषणा

अब किसी भी संपत्ति का उपयोग करने का मूल तरीका इसे आयात करना और इसका सही उपयोग करना है?

लेकिन क्या आप जानते हैं कि यह कैसे काम करता है? हर बार जब आप किसी आइटम को डिफ़ॉल्ट रूप से आयात करते हैं तो यह आरंभीकरण के साथ मेमोरी में आवंटित हो जाता है। इसलिए यदि आप किसी छवि या घटक को इस तरह की 5 फ़ाइलों में आयात और घोषित करते हैं

import Profile from '../../profile'

यह एक ही चीज़ के लिए इसके 5 उदाहरण बनाएगा!

इसके बजाय आपको सभी संपत्तियों को एक इंडेक्स फ़ाइल में कॉल करना चाहिए और उससे ऑब्जेक्ट आयात करना चाहिए, इस तरह यह केवल एक बार घोषित किया जाएगा और संदर्भ द्वारा हर जगह उपयोग किया जाएगा।

इसलिए मेमोरी उपयोग को घटाकर 4/5 कर दिया गया है।

✅ निष्कर्ष -

आप एक अच्छे इंसान हैं आर्थर! (क्षमा करें, मैंने अभी-अभी RDR2 पूरा किया है और यह एक बहुत बढ़िया गेम था)।

इन परिवर्तनों के साथ ऐप का प्रदर्शन न केवल बेहतर मोबाइल साइड स्वास्थ्य बल्कि बेहतर सर्वर साइड अनुकूलन के साथ बहुत बढ़ गया।

उपयोग के केवल 1 सप्ताह में स्टोर रेटिंग 3.5 से 4.1 हो गई !!!

याद रखें कि यह सिर्फ एक कोड नहीं है बल्कि एक कहानी है कि उपयोगकर्ता इसके साथ कैसे इंटरैक्ट करते हैं।

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

? यदि आपको ब्लॉग पसंद आता है तो टिप्पणियाँ छोड़ें, या इसे अपने साथियों के साथ साझा करें ताकि वे भी इसका आनंद उठा सकें!