🔣 🚴 ✍🏾 कुछ सरल चरणों में प्रतिक्रिया मूल निवासी के आकार में 60% की कमी 💬 🚹 👨‍👨‍👧

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

यह ध्यान दिया जाना चाहिए कि हमारे उपयोगकर्ताओं के थोक बजट उपकरणों पर एप्लिकेशन इंस्टॉल करते हैं। हम फेसबुक डिवाइस-ईयर-क्लास लाइब्रेरी के डेटा का उपयोग करके ऐसे निष्कर्ष निकाल सकते हैं।। इस पुस्तकालय ने डिवाइस के मॉडल के बारे में जानकारी प्राप्त की है, रिपोर्ट में बताया गया है कि किस वर्ष इस डिवाइस को एक अपकमिंग फ्लैगशिप फोन माना जाएगा। उदाहरण के लिए, हमारे उपयोगकर्ताओं के बीच सबसे लोकप्रिय फोन सैमसंग गैलेक्सी ए 10 है। यह फोन, हालांकि यह 2019 में जारी किया गया था, इसे केवल 2013 में प्रमुख माना जा सकता है। उपयोगकर्ता उपकरणों पर डेटा का विश्लेषण करते हुए, हम कह सकते हैं कि इनमें से 85% उपकरणों को केवल 2015 या उससे पहले के उच्च-अंत वाले उपकरणों के रूप में पहचाना जा सकता है। इस वजह से, हमें अपने मोबाइल एप्लिकेशन को अनुकूलित करने के लिए विशेष आवश्यकताएं हैं। अनुकूलन का लक्ष्य इतना है कि कमजोर डिवाइस वाले उपयोगकर्ता भी आराम से हमारे एप्लिकेशन का उपयोग कर सकते हैं।

उन उपकरणों का प्रतिशत, जिन्हें किसी विशेष वर्ष में प्रमुख के रूप में पहचाना जा सकता है

इस संबंध में, हमने एप्लिकेशन के आकार पर पूरा ध्यान दिया। अपने Android संस्करण के मामले में, यह 26.8 एमबी था। हालाँकि यह इतना बड़ा आकार नहीं है, लेकिन यह निश्चित रूप से हमारे उपयोगकर्ताओं के अनुप्रयोगों के औसत आकार से अधिक है। Google Play कंसोल के अनुसार, यह आंकड़ा 16.3 एमबी है। आवेदन का आकार सीमित टैरिफ योजनाओं वाले उपयोगकर्ताओं के लिए, या कम मेमोरी वाले उपकरणों के लिए एक निर्णायक कारक हो सकता है, जो उपयोगकर्ताओं को उन अनुप्रयोगों का सावधानीपूर्वक चयन करने के लिए मजबूर करता है जो उन्होंने स्थापित किए होंगे। नतीजतन, कुछ एप्लिकेशन को अनइंस्टॉल करना पड़ता है। यह विशेष रूप से म्युचुअल एप्लिकेशन के मामले में महत्वपूर्ण है, क्योंकि उधारकर्ता इस एप्लिकेशन के माध्यम से मासिक किस्तों का भुगतान करते हैं। जब उधारकर्ता हमारे आवेदन को अनइंस्टॉल करता है, तो वह समय पर भुगतान करने की संभावना बहुत कम हो जाती है।और यह सीधे हमारे मंच का उपयोग करने वाले निवेशकों की कमाई को प्रभावित करता है।

म्यूचुअल एप्लिकेशन का आकार हमारे उपयोगकर्ताओं के

एप्लिकेशन के औसत आकार से बहुत बड़ा होता है । एप्लिकेशन का आकार न केवल अनइंस्टॉल के स्तर को प्रभावित करता है। आकार भी एप्लिकेशन सेटिंग्स की रूपांतरण दर को प्रभावित करता है। यहाँ Google Play टीम द्वारा लिखित इस पर एक अच्छा लेख है। यह आलेख अनुप्रयोग आकार के महत्व पर चर्चा करता है। विशेष रूप से, यह कहता है कि एपीके फ़ाइल के आकार के प्रत्येक अतिरिक्त 6 एमबी से प्रतिष्ठानों की रूपांतरण दर 1% कम हो जाती है।

वे इस तथ्य के बारे में भी बात करते हैं कि विकासशील देशों में जहां बजट उपकरण आदर्श हैं, यह प्रभाव और भी मजबूत है। अर्थात्, उभरते बाजारों में एपीके फ़ाइल के आकार को 10 एमबी तक कम करने से प्रतिष्ठानों की रूपांतरण दर में लगभग 2.5% की वृद्धि होती है।

विभिन्न देशों में एपीके फ़ाइल के आकार को कम करने के लिए हर 10 एमबी के लिए इंस्टॉलेशन की रूपांतरण दर बढ़ाना (Google आंतरिक डेटा के अनुसार)

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

Android ऐप बंडल

सिफारिशों को पढ़ते हुए, हमने सीखा कि एप्लिकेशन के आकार को कम करने का सबसे आसान तरीका एक नया एप्लिकेशन वितरण पद्धति का उपयोग करना है जिसे एंड्रॉइड ऐप बंडल (एएबी) कहा जाता है । इस क्षण तक, हमने एप्लिकेशन को अच्छे पुराने एंड्रॉइड पैकेज (एपीके) फ़ाइल को इकट्ठा करते हुए वितरित किया , जिसे अधिकांश एंड्रॉइड डिवाइसों पर चलाया जा सकता है, और इसे Google Play कंसोल पर अपलोड किया जा सकता है। लेकिन AAB बंडल में केवल संकलित कोड और संसाधन होते हैं। परिणामस्वरूप, जब इसे डाउनलोड किया जाता है, तो Google विभिन्न प्रकार के उपकरणों के लिए अनुकूलित एपीके फ़ाइलों को बनाने, उनकी विशिष्टताओं और सीपीयू वास्तुकला को ध्यान में रखते हुए जिम्मेदार होता है।

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

दस्तावेज़ीकरण पढ़ने के बाद, हमने सिर्फ रिएक्टिव नेटिव ग्रेड बिल्ड स्क्रिप्ट को बदल दिया ताकि यह चालू के बजाय assembleReleaseचल सके bundleRelease। AAB फाइल बनाने के लिए बस इतना ही चाहिए। प्ले स्टोर में सीधे सामग्री अपलोड करने के बारे में फास्टलेनsupply कॉन्फ़िगरेशन के लिए किए गए कुछ और संशोधनों के बाद , हमने एएबी पर स्विच किया, और Google Play कंसोल में हमारे एप्लिकेशन का एक नया संस्करण दिखाई दिया।

अकेले इस परिवर्तन के कारण उपयोगकर्ता उपकरणों में स्थानांतरित की जाने वाली एपीके फाइलों के आकार में कमी आई है। कमी 9.1 से 12.4 एमबी तक रही। जैसा कि यह निकला, एंड्रॉइड ऐप बंडल का उपयोग एक प्रभावी तकनीक है जो वास्तव में, आपको एप्लिकेशन के आकार को कम करने की अनुमति देता है।

पुरानी एपीके-फाइल और नई एएबी-बंडल, जिसका उपयोग इस तथ्य की ओर जाता है कि विभिन्न उपकरणों पर एप्लिकेशन का आकार 14.4 से 17.7 एमबी

सच हो सकता है, आपको यहां सावधान रहना चाहिए। यदि आप हर्मीस के साथ रिएक्ट नेटिव का उपयोग करते हैं, तो आपको अपनी निर्भरता को अपडेट करने की आवश्यकता हो सकती हैsoloader(विवरण यहां देखें)। अन्यथा, उपयोगकर्ता को एक आवेदन देने का जोखिम होता है जिसमें एक महत्वपूर्ण त्रुटि होगी। हम भाग्यशाली थे, हम परियोजना की अल्फा रिलीज के परीक्षण के दौरान इस समस्या की पहचान करने में सक्षम थे। लेकिन त्रुटि आसानी से उत्पादन में फिसल सकती है, क्योंकि यह स्थानीय परीक्षण के दौरान या एपीके फ़ाइल बनाते समय प्रकट नहीं होती है।

Android आकार विश्लेषक का उपयोग करके अनुप्रयोग संसाधनों का अनुकूलन

उन अनुप्रयोगों के अनुकूलन के लिए अगला सुझाव जो हमें प्रलेखन में मिला, वह था एंड्रॉइड साइज़ एनालाइज़र का उपयोग । यह एक कमांड लाइन टूल है जो एंड्रॉइड एप्लिकेशन का विश्लेषण करता है और उनके आकार को कम करने के तरीकों की तलाश करता है। हमने निम्न फॉर्म की कमांड का उपयोग करके यह टूल लॉन्च किया है:

size-analyzer check-bundle [BUNDLE].aab

नतीजतन, हमें महान एप्लिकेशन संसाधनों और छवियों की एक सूची मिली जिसे हम अनुकूलित कर सकते हैं। हमें प्रोगार्ड की स्थापना की भी सिफारिश की गई थी।

आकार-विश्लेषक की रिपोर्ट

▍ProGuard

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

▍ बड़े एप्लिकेशन संसाधनों

इसे size-analyzerफिर से चलाना , कुंजी के साथ -d, हमें उनके आकार द्वारा क्रमबद्ध, आवेदन संसाधनों की एक सूची मिली। चूंकि यह टूल इस बारे में कुछ भी नहीं जानता है कि उपयोगकर्ता एप्लिकेशन के साथ कैसे काम करते हैं, इसने हमें स्वतंत्र रूप से यह निर्णय लेने का अवसर दिया कि किन संसाधनों को हटाया जाना चाहिए और जिन्हें गतिशील रूप से एप्लिकेशन में लोड किया जाना चाहिए।

आकार के आधार पर छांटे गए बड़े एप्लिकेशन संसाधनों की

सूची इस सूची में पहला और सबसे बड़ा संसाधन रिएक्टिव नेटिव जावास्क्रिप्ट बंडल था। अब हम इस बंडल को विभाजित नहीं कर सकते हैं और इसे गतिशील रूप से लोड कर सकते हैं। लेकिन बाद में हम इसके बारे में सोचेंगे। इसके अलावा नीचे दी गई सूची में बड़ी फ़ॉन्ट फ़ाइलें (TTF) और छवि फ़ाइलें (JPG और PNG) हैं।

आवश्यक चित्र

हमारा ध्यान तुरंत स्टोरीबुक में इस्तेमाल की गई विशाल JPG छवियों की ओर आकृष्ट किया गया । हम इस प्रणाली का उपयोग घटकों के विकास और परीक्षण के लिए करते हैं। यह 2 एमबी कचरा है जो परियोजना के उत्पादन संस्करण में गिर गया। शर्मनाक गलती! जब ऐसा कुछ होता है, तो हमें ऐसा लगता है कि हमने कुछ गंभीर मूर्खता की है। लेकिन सॉफ्टवेयर विकास की जटिल दुनिया में, हर कोई गलती करता है। मेरा मानना है कि यदि आप सार्वजनिक रूप से अपनी गलतियों के बारे में बात करते हैं, तो इससे अन्य डेवलपर्स को इन गलतियों से सीखने में मदद मिलेगी। एक संभावना है कि आप वही गलतियाँ करते हैं यदि आप आवेदन की संसाधन संरचना का विश्लेषण नहीं करते हैं, जिसका आकार धीरे-धीरे बढ़ रहा है।

▍ फ़ॉन्ट्स

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

एक और बात जिस पर हमने गौर किया, वह थी फॉन्ट फाइल्स का आकार। उनमें से प्रत्येक का आकार लगभग 670 Kb था। इसका मतलब है कि असम्पीडित बंडल में चार फोंट एक आश्चर्यजनक 2.7 एमबी पर कब्जा कर लेते हैं। लेकिन, सौभाग्य से, FontForge नामक एक उपकरण है जो आपको फ़ॉन्ट फ़ाइलों को गहराई से विश्लेषण और संशोधित करने की अनुमति देता है। इस उपकरण का उपयोग करके, हम यह पता लगाने में सक्षम थे कि फ़ॉन्ट फ़ाइलों के बड़े आकार का मुख्य कारण सिरिलिक वर्ण और अनावश्यक ग्लाइकल्स हैं। हम सुरक्षित रूप से यह सब हटा सकते हैं, क्योंकि हमारे आवेदन का पाठ भाग पूरी तरह से पुर्तगाली में लिखा गया है। इस बदलाव के लिए धन्यवाद, हम फ़ॉन्ट फ़ाइलों के आकार को 670 Kb से घटाकर 70 Kb करने में सक्षम थे - 90% तक।

हमारे फोंट में कुछ ग्लिफ़ के उदाहरण शामिल हैं।

इस तथ्य के कारण कि हमने अनावश्यक फोंट से छुटकारा पाया और शेष लोगों को अनुकूलित किया, हम आवेदन का आकार 3.8 एमबी कम कर पाए। इससे एपीके फ़ाइल के कुल आकार में 2 एमबी की कमी आई।

अनुकूलन से पहले फोंट और उनके आकार की सूची

अनुकूलन के बाद फोंट और उनके आकार की सूची

Ization छवियों का अनुकूलन

छवियों का विश्लेषण करने के बाद जो अभी भी आवेदन में बने हुए हैं, हमने देखा कि उनमें से कुछ काफी बड़े हैं। हमने TinyPNG ग्राफिक्स ऑप्टिमाइज़ेशन टूल के साथ इनमें से कई छवियों को संसाधित किया और इन छवियों के आकार में महत्वपूर्ण कमी देखी। उसके बाद, हमने एप्लिकेशन में उपयोग की जाने वाली सभी जेपीजी और पीएनजी छवियों को अनुकूलित करने का निर्णय लिया। उनमें से 41 थे।

अनुकूलन से पहले और बाद की छवि इससे

हमें छवियों के आकार को 2.5 एमबी से 756 केबी तक कम करने का मौका मिला, अर्थात 70% तक। हालांकि, इस तथ्य के कारण कि छवियां पहले से अनुकूलित नहीं थीं, उन्हें अंतिम एपीके-फ़ाइल के निर्माण के दौरान संकुचित किया गया था। यह पता चला कि हमारे अनुकूलन से उपयोगकर्ता द्वारा डाउनलोड किए गए एप्लिकेशन के आकार में केवल 500 Kb तक की कमी आई।

उसके बाद, हमने महसूस किया कि हमने पहले से ही त्वरित अनुकूलन की सभी संभावनाओं को समाप्त कर दिया था। संसाधनों के अनुकूलन को जारी रखने के लिए या तो महान प्रयासों या केवल मामूली सुधार की आवश्यकता होगी।

प्रतिक्रियाशील जावास्क्रिप्ट जावास्क्रिप्ट बंडल अनुकूलन

हमने Android प्लेटफ़ॉर्म के लिए विशिष्ट एप्लिकेशन संसाधनों का पता लगाने के बाद, जावास्क्रिप्ट बंडल का विश्लेषण करने का समय दिया है। बंडल अनुकूलन को तीन कारणों से एक अच्छा विचार माना जा सकता है। सबसे पहले, यह समाप्त APK फ़ाइल के आकार को कम करता है। दूसरे, इससे एप्लिकेशन का तेज़ लॉन्च होता है, क्योंकि JS वर्चुअल मशीन को कम कोड प्रोसेस करना पड़ता है। अंत में, और सबसे महत्वपूर्ण बात, यह OTA अपडेट्स को गति देता है जो हम हफ्ते में कई बार CodePush का उपयोग करते हैं ।

▍ बंडल विश्लेषक और कोड अनुकूलन

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

आकार के एक संकेत के साथ आपसी आवेदन के सामने के अंत के कोड आधार के पुस्तकालयों और फ़ोल्डरों का स्नैपशॉट

हमें पता चला कि बंडल का कुल आकार 5.49 एमबी है। इस वॉल्यूम का 57.8% फ़ोल्डर से निर्भरताnode_modules, 27.5% - एप्लिकेशन कोडद्वारा दर्शाया गया है। क्या रहता है, हमारे द्वारा उपयोग किए गए उपकरण की पहचान नहीं की जा सकी। बंडल की विधानसभा प्रक्रिया के दौरान, अप्रयुक्त कोड पहले ही हटा दिया गया था, इसलिए हमने जो देखा वह कोड था जो वास्तव में एप्लिकेशन द्वारा उपयोग किया जाता है। लेकिन, यहां तक कि इस पर विचार करते हुए, बंडल में आप हमेशा कुछ ऐसा पा सकते हैं जिसे बेहतर बनाया जा सकता है।

सबसे बड़ी परियोजना निर्भरता हैmath.js। यह पुस्तकालय, जैसा कि इसके नाम से पता चलता है, कई गणितीय कार्यों को कार्यान्वित करता है। हमें इस लाइब्रेरी के लिए विशेष आवश्यकता नहीं है कि इस तथ्य के कारण कि हम सर्वर पर सभी महत्वपूर्ण गणना करते हैं, जिसके बाद हम बस आवेदन के लिए परिणाम भेजते हैं। जब हमने एप्लिकेशन कोड को देखा, तो यह पता चला कि लाइब्रेरी का उपयोग केवल कुछ सरल कार्यों को करने के लिए किया जाता है। यह सबसे अधिक संभावना है कि एक डेवलपर द्वारा उपयोग किया जाता है जो केवल आदत के आधार पर सर्वर कोड पर काम करता है। हमने जल्दी से पुस्तकालय से उपयुक्त तरीके निकाले और उन्हें पूरी तरह से इस निर्भरता से छुटकारा दिलाते हुए अपने कोड बेस में बनाया। इससे बंडल का आकार 4.64 एमबी तक कम हो सकता है। केवल एक पुस्तकालय के इनकार ने बंडल के आकार को 15.5% कम करने की अनुमति दी!

जैसा कि पहले ही उल्लेख किया गया है, हम घटकों के विकास और परीक्षण के लिए स्टोरीबुक का उपयोग करते हैं। सच है, संबंधित क्षमताओं को केवल स्थानीय और मध्यवर्ती वातावरण में उपलब्ध होना चाहिए। अंतिम उपयोगकर्ताओं को इसकी आवश्यकता नहीं है। इसके लिए धन्यवाद, हमने ENVIRONMENTएप्लिकेशन के संबंधित भाग को शामिल करने के लिए चर का उपयोग किया । हालांकि यह पहुंच को प्रतिबंधित करने के लिए उपयुक्त है, लेकिन बंडलर यह नहीं जान सकता कि इस चर के लिए क्या मूल्य लिखा है। इस सीमा के कारण, सभी स्टोरीबुक कोड उत्पादन बंडल में गिर गया।

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

इंडेक्स फ़ाइल के दो संस्करणों के साथ अपडेट किए गए स्टोरीबुक फ़ोल्डर।

इन दो परिवर्तनों ने बंडल आकार को 5.49 एमबी से घटाकर 4.2 एमबी कर दिया। इसका मतलब यह है कि, अन्य चीजों के अलावा, एप्लिकेशन तेजी से लोड होगा और तेजी से अपडेट होगा।

अंतिम बंडल का आकार 4.2 एमबी था।

इन सभी सुधारों के बाद, हमने फिर से प्ले स्टोर में एप्लिकेशन डाउनलोड किया। अब हमें सूचित किया गया कि समाप्त एपीके-फाइल का आकार 10.5 से 13.7 एमबी के बीच होगा। यह, इस तथ्य को देखते हुए कि आवेदन में मूल रूप से 26.8 एमबी का आकार था, बस प्रोजेक्ट आकार में लगभग 60% की कमी का मतलब है! इसलिए, जैसा कि हमने Google Play टीम के एक लेख में कहा है, हम पूरी तरह से उम्मीद कर सकते हैं कि प्रतिष्ठानों की रूपांतरण दर 3.75% बढ़ जाएगी।

अंतिम एपीए संस्करण के साथ आवेदन के मूल एपीके संस्करण की तुलना, जिसमें ऊपर वर्णित सभी सुधार किए गए हैं

सारांश

हम, व्यवसाय-उन्मुख प्रोग्रामर के रूप में, जानते हैं कि कभी-कभी कंपनियां, किसी परियोजना के तेज विकास के लिए, अपने तकनीकी ऋण को बढ़ाने के लिए अच्छी तरह से आगे बढ़ सकती हैं। यह म्यूचुअल जैसे युवा स्टार्टअप के लिए विशेष रूप से सच है, जो बाजार में अपनी जगह खोजने की कोशिश कर रहे हैं। लेकिन अगर आप इस ऋण का पालन नहीं करते हैं, तो आप कष्टप्रद गलतियाँ कर सकते हैं, जैसे कि एक विशाल पुस्तकालय के उत्पादन और अनुचित उपयोग के लिए 2 एमबी परीक्षण छवियां भेजना। तकनीकी ऋण को नियंत्रण से बाहर निकलने और परेशानी का कारण नहीं बनने देना चाहिए।

इसके अलावा, अक्सर ऐसा होता है कि डेवलपर्स परियोजनाओं को अनुकूलित करने के लिए उपलब्ध अवसरों को आसानी से याद करते हैं। इसलिए, कभी-कभी आपकी परियोजनाओं का गंभीर रूप से विश्लेषण करने की सिफारिश की जाती है। बस यह जांचने के लिए कि क्या आपने आवेदन के आकार, गति, या किसी अन्य पहलू को जल्दी से अनुकूलित करने का कुछ अवसर गंवा दिया है। आवेदन का विश्लेषण करने, कार्य की योजना बनाने और परियोजना में सुधार करने में हमें केवल दो दिन लगे, जिससे हमें आवेदन के आकार को 60% तक कम करने की अनुमति मिली। कुछ और के साथ आना मुश्किल है जो इतने कम समय में समान परिणाम दे सकता है।

आप अपनी प्रतिक्रिया मूल परियोजनाओं को कैसे अनुकूलित करते हैं?

कुछ सरल चरणों में प्रतिक्रिया मूल निवासी के आकार में 60% की कमी