हम लमोडा एप्लिकेशन की स्थिरता कैसे बनाए रखते हैं

सभी को नमस्कार!

मेरा नाम विटाली बेंडिक है। मैं लमोडा में एंड्रॉइड एप्लिकेशन डेवलपमेंट के लिए टीम लीडर हूं। 2018 में, मैंने एक रिपोर्ट के साथ मोसड्रॉइड एल्युमिनियम पर बात की , जिसकी प्रतिलिपि मैं साझा करना चाहता हूं।



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

रिपोर्ट में मैं बताऊंगा:

1. हम आवेदन स्थिरता से क्या मतलब है;
2. हमारे मोबाइल एप्लिकेशन की वास्तुकला के बारे में;
3. प्रक्रियाओं, प्रथाओं और उपकरणों के बारे में जो हम उपयोग करते हैं।

तो, हमारे लिए एक स्थिर अनुप्रयोग क्या है? यह एक ऐसा एप्लिकेशन है जो दुर्घटना नहीं करता है, लटका नहीं है और अनुमानित रूप से काम करता है। जब मैं कहता हूं कि यह नहीं गिरता है, तो मेरा मतलब है कि यह कम से कम 95% -99% उपयोगकर्ताओं में नहीं आता है।

आर्किटेक्चर

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

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




उत्पाद पृष्ठ। विजेट तत्व उदाहरण

मॉडल के साथ प्रस्तुतकर्ता की बातचीत के लिए, यहां सब कुछ मानक है: प्रस्तुतकर्ता इंटरेक्टर के माध्यम से बाकी एप्लिकेशन के साथ बातचीत करता है, चाहे वह रिपॉजिटरी हो या प्रबंधक।



ऐसा होता है कि कई प्रस्तुतकर्ताओं को एक दूसरे के साथ संवाद करने, डेटा का आदान-प्रदान करने की आवश्यकता होती है। इसके लिए, हमारे पास एक समन्वयक है, जिसे कई प्रस्तुतकर्ताओं के बीच एक साझा सहभागिता के रूप में माना जा सकता है।

अनेकता

- हम कोटलिन में सभी नए कोड लिखते हैं, और हम एमवीपी को एमवीपी कार्यान्वयन के रूप में उपयोग करते हैं।
- DI के रूप में हम Dagger2 का उपयोग करते हैं ।
- नेटवर्क के साथ काम करने के लिए - रेट्रोफिट ।
- चित्रों के साथ काम करने के लिए - ग्लाइड ।
- हम नई रेलिक में क्रैश जोड़ते हैं।
- हम भी Lottie का उपयोग करते हैं।
- फिलहाल, हम सक्रिय रूप से कोटलिन कोरआउट्स का उपयोग कर रहे हैं।

विकास की प्रक्रिया

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

परीक्षक ने सफलतापूर्वक परीक्षण पूरा करने के बाद, और हमने उस संस्करण पर निर्णय लिया जो इस सुविधा में जाएगा, यह मास्टर में विलीन हो जाता है।

जब रिलीज का समय आता है (हम हर 2 सप्ताह में जारी किया जाएगा), आरसी-शाखा, जहां धूम्रपान परीक्षण किया जाता है, आवंटित किया जाता है, परीक्षण के मामले चलाए जाते हैं। उसके बाद, सुविधा उत्पादन शाखा में विलीन हो जाती है और Google Play बीटा पर प्रकाशित होती है।



CI / CD के लिए, चूंकि हम एटलसियन स्टैक का उपयोग करते हैं, इसलिए बांस एक बिल्ड सर्वर के रूप में कार्य करता है।

जब एक डेवलपर पुल-अनुरोध बनाता है, तो बांस पर निर्माण कार्य शुरू होता है। वह रिपॉजिटरी से कोड खींचती है, फास्टलेन पर स्क्रिप्ट चलाता है, जो एप्लिकेशन एकत्र करता है, परीक्षण चलाता है और स्लैक को यह रिपोर्ट करता है।

यदि परीक्षक ने सुविधा का परीक्षण करने के लिए असेंबली शुरू की है, तो हॉकी हॉकी में भी लोड किया गया है।

Google Play बीटा पर रिलीज़ प्रकाशित करने के लिए, वितरण प्रबंधक ने बांस पर संबंधित कार्य लॉन्च किया, जो समान प्रवाह चलाता है, लेकिन Google Play बीटा में संस्करण भी अपलोड करता है।

एप्लाइड प्रैक्टिस

रिलीज से पहले का निर्माण

प्रारंभ में, हमारे पास दो प्रकार की विधानसभा थीं, जैसे कई:

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

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

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

विशिष्टता पहले

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



प्रारंभ में, हमारे पास एक एपीआई था जिसके ग्राहक केवल मोबाइल एप्लिकेशन नहीं थे। एपीआई तरीके एक-दूसरे के अनुरूप नहीं थे, जिससे अक्सर बदलाव मुश्किल हो जाता था।

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



या, जब ब्रांडों की अनुपस्थिति में, या तो अशक्त वापस आ गया था, या सामान्य रूप से 4 अशक्त वर्णों में
(JSON नहीं)। इस मामले में, आवेदन कठिन था।



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



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

फ़ीचर-टॉगल

कंपनी का अपना विकास ए / बी टूल है, जो आपको प्रयोगों और फ़ीचर-टॉगल दोनों को लागू करने की अनुमति देता है। फ़ीचर-टॉगल हम उपयोगकर्ता के लिए गैर-महत्वपूर्ण कार्यक्षमता को बंद करते हैं, जो यदि आवश्यक हो, तो अक्षम किया जा सकता है। उदाहरण के लिए, अगर इसमें कुछ गलत हुआ है, या अगर हमें बैकेंड पर लोड को कम करने की आवश्यकता है (एक विकल्प के रूप में, "ब्लैक फ्राइडे पर)"।

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

वास्तविक उपयोगकर्ता निगरानी

वास्तविक उपयोगकर्ता निगरानी आपको उपयोगकर्ता के दृष्टिकोण से आवेदन के प्रदर्शन को मापने की अनुमति देती है। उदाहरण के लिए, एक ग्राहक एक कैटलॉग में एक आइटम पर क्लिक करता है। अपनी कार्रवाई का परिणाम देखने से पहले उसे कितनी देर तक इंतजार करना होगा, यानी वह तस्वीरों के साथ एक उत्पाद कार्ड देखता है?

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

1. मेमोरी की खपत;
2. सीपीयू की खपत;
3. मुख्य धारा पर क्या हुआ;
4. नेटवर्क से क्या लोड किया गया था;
5. अन्य धागों में क्या हुआ।

यह हमें समस्या उत्पन्न करने का अवसर देता है यदि वे उत्पन्न होते हैं, क्योंकि यह स्पष्ट हो जाता है कि वास्तव में अधिकांश समय लगा था और हम इसे अनुकूलित कर सकते हैं ताकि एप्लिकेशन उपयोगकर्ता के लिए अधिक उत्तरदायी हो।

तकनीकी ऋण की वापसी

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

संस्करण की रिहाई के बाद, हम इसे प्रतिशत से रोल आउट करते हैं, महत्वपूर्ण संकेतकों की निगरानी करते हैं और अगर वे होते हैं तो घटनाओं का जवाब देते हैं। चरणबद्ध रोलिंग के लिए हम Google Play कंसोल का उपयोग करते हैं। रोलिंग निम्नानुसार किया जाता है: 5% से लुढ़का, हम संकेतक की निगरानी करते हैं; यदि सब कुछ क्रम में है, तो रोल करें। यदि कुछ हुआ है, तो हॉटफ़िक्स बनाएं और उसे पहले से ही रोल आउट कर दें। अगला, हम 10%, 20% और 50% की रोलिंग करते हैं।

हम किन महत्वपूर्ण स्थानों की निगरानी कर रहे हैं?

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

उपकरण

• ए / बी उपकरण
• NewRelic RPM
• NewRelic अंतर्दृष्टि।

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

यह हमें अवसर देता है:

• जब हम अपने कार्यालय के अंदर कुछ सुविधा का परीक्षण करना चाहते हैं तो कार्यालय पर प्रयोगों को रोल आउट करें।
• एक प्रयोग को रोल करें, साथ ही एक विशिष्ट उपयोगकर्ता के लिए फ़ीचर-टॉगल।

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

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

1. स्मृति की खपत के बारे में;
2. सीपीयू खपत के बारे में;
3. JSON से संबंधित संचालन के बारे में;
4. SQlite से संबंधित संचालन के बारे में।

इसके अलावा, हम क्रैश रिपोर्ट इकट्ठा करने, उपयोगकर्ता के अपवादों को संभालने के लिए और उपयोगकर्ता के इंटरैक्शन के लिए न्यूट्रेलिक का उपयोग करते हैं - यह वास्तव में एक ही वास्तविक उपयोगकर्ता मॉनिटरिंग है । हमने इसे NewRelic उपयोगकर्ता इंटरैक्शन के तंत्र के माध्यम से कार्यान्वित किया है।

लेकिन स्थिरता के बारे में क्या?

हमारे पास क्रैश दर के रूप में इस तरह के एक संकेतक है। पहले, हमने हॉटफ़िक्स को रोल आउट किया था जब इसका संकेतक 0.3% से 0.5% तक था। यदि इसका मान 0.5% से अधिक हो जाता है, तो यह बिल्कुल महत्वपूर्ण है। अब हम क्रैश रोल आउट करते हैं, जब क्रैश दर 0.1% से 0.3% तक होती है। एक महत्वपूर्ण मान 0.3% से अधिक है। और, अगर पहले हमारे आवेदन की औसत क्रैश दर 0.1% थी, तो अब यह 0.05% है।



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