शुरुआत में मेस: एक iOS एप्लिकेशन की लॉन्च गति पर पोस्टमार्टम

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

यह लंबे समय से शुरू होता है

एप्लिकेशन में बहुत सारे कोड हैं, बहुत सारी कक्षाएं हैं और वे किसी तरह जुड़े हुए हैं। इन संबंधों को प्रबंधित करने के लिए, हमने डिप (कोड पीढ़ी के बिना स्विंज या किसी अन्य डीआई फ्रेमवर्क) का उपयोग किया।

यह इस तरह से काम करता है: आवेदन की शुरुआत में, सभी निर्भरताएं "कंटेनर" में crammed होती हैं, और फिर वांछित वर्ग को इसमें से निकाला जाता है, जिसमें सभी निर्भरताएं डाल दी जाती हैं। शुरू करने में समय लगता है, किसी भी स्क्रीन को खोलने में समय लगता है।

लेकिन तस्वीरें खूबसूरत हैं

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

यहाँ हमारे छींटे हैं। सुंदर, लेकिन एक समस्या को छिपाते हुए जिसे हमने हल करने की कोशिश भी नहीं की।



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

इसी तरह से डीप प्रोफाइलर में दिखता है। सूची के अंत में कॉल स्टैक सीमा पहुंच गई है। इसके साथ कुछ उचित करना असंभव है।

मक्खियों को 4S? बाद में ठीक करें

इस समय, बग "4S पर रिलीज बिल्ड शुरू नहीं किया था" बैकलॉग में पड़ा था, हालांकि डिबग लॉन्च किए गए थे। किसी ने समस्याओं के कनेक्शन पर ध्यान नहीं दिया, iOS के न्यूनतम संस्करण को 10 तक बढ़ा दिया और परिवर्तनों को भी स्थगित कर दिया। 4S पर कुछ उपयोगकर्ता हैं, है ना?

हमने डिप को देखा: शुरुआत में नहीं, लेकिन संकलन पर

हालांकि, यह स्पष्ट हो गया कि डुबकी को काटने की जरूरत है। और क्या बदलना है? बहुत समय पर, हम स्विफ्ट लेख में निर्भरता इंजेक्शन के पार आए।

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



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

इस प्रकार अब निर्भरता कोड दिखता है। गंदा लेकिन काम करने वाला। पंजीकरण के साथ 450 स्थान और निष्कर्षण के साथ 1400 स्थान हैं।



कार्यात्मक रूप से, कोड समान है, केवल इसके साथ काम करने का तरीका अलग है। गति का अंतर सभी मॉडलों पर दिखाई देता है। एक्सएस पर - दो बार उपवास के रूप में, और एसई अपने लिए देखें:


इसलिए हमने न केवल शुरुआत को गति दी, बल्कि स्क्रीनों के उद्घाटन को भी शुरू किया। परिवर्तनों से पहले, प्रत्येक स्क्रीन ने केवल निर्भरता पर 0.3-1 सेकंड का समय लिया।

पिज्जा के बिना नया साल

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


परिकल्पना: यह iOS अनुप्रयोगों को छोड़ देता है यदि वे लंबे समय तक चलते हैं। संस्करण की पुष्टि इस तथ्य से की गई थी कि सभी समीक्षाएं पुराने उपकरणों से थीं: 5, 5 एस, 6. ऐसी समीक्षाओं की संख्या में काफी वृद्धि हुई है, क्योंकि पिज्जा एक छुट्टी है, लोग अक्सर इसे नए साल के लिए ऑर्डर करते हैं। टीम चिंतित है, उत्पाद चिंतित है, लेकिन हम नए संस्करण को केवल जनवरी में रोल कर रहे हैं।

हम भाग्यशाली थे कि समाधान लिखा गया था और केवल परीक्षण किया जा सकता था। एक अन्य परिदृश्य में, महीनों को कारणों को खोजने और उन्हें ठीक करने में खर्च किया जा सकता है।

---

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

• प्रतीक्षा कर रहा है। यदि आवेदन लंबे समय तक शुरू होता है, तो वे कितने समय तक पिज्जा लेंगे?
• उपयोग करने का सुख। हर स्क्रीन पर बेवकूफ क्यों?
• और स्थिरता के लिए भी। "आवेदन नहीं चल रहा है !!! डेवलपर्स, क्या आप वहां परीक्षण करते हैं? ”(सी)।

और डुबकी, Swinject और अन्य चौखटे जो वास्तविक समय में कंटेनरों के साथ काम करते हैं यदि आपके पास एक बड़ी परियोजना और बहुत अधिक निर्भरता है।

अगले लेख को याद नहीं करने के लिए, डोडो पिज्जा मोबाइल चैनल की सदस्यता लें ।