मेमोरी में एंड्रॉइड ऐप। Yandex.Luncher के लिए अनुकूलन रिपोर्ट

हल्के एंड्रॉइड गो सिस्टम ने पूर्व-स्थापित अनुप्रयोगों के लिए आवश्यकताओं में वृद्धि की है - आकार और मेमोरी का उपयोग किया। हमें इन आवश्यकताओं को पूरा करने की चुनौती का सामना करना पड़ा। हमने कई अनुकूलन किए और अपने ग्राफिकल शेल की वास्तुकला को गंभीरता से बदलने का फैसला किया - Yandex.Luncher। मोबाइल एप्लिकेशन डेवलपमेंट टीम के प्रमुख अलेक्जेंडर स्टारचेंको ने यह अनुभव साझा किया।


- मेरा नाम अलेक्जेंडर है, मैं सेंट पीटर्सबर्ग से, उस टीम से हूं जो Yandex.Loncher और Yandex.Phone विकसित करता है। आज मैं आपको बताऊंगा कि हमने लॉन्चर में मेमोरी को कैसे अनुकूलित किया। सबसे पहले, मैं संक्षेप में बताऊंगा कि लॉन्चर क्या है। अगला, हम उन कारणों पर चर्चा करते हैं जिनकी हमें स्मृति को अनुकूलित करने की आवश्यकता है। उसके बाद, हम इस बात पर विचार करेंगे कि मेमोरी को सही तरीके से कैसे मापें और इसमें क्या शामिल है। फिर अभ्यास के लिए आगे बढ़ते हैं। मैं इस बारे में बात करूंगा कि हमने लॉन्चर में मेमोरी को कैसे ऑप्टिमाइज़ किया और हम समस्या के एक रैडिकल समाधान पर कैसे आए। और अंत में मैं इस बारे में बात करूंगा कि हम स्मृति के उपयोग की निगरानी कैसे करते हैं, हम इसे कैसे नियंत्रण में रखते हैं।



"लॉन्चर" या "लॉन्चर" - इतना महत्वपूर्ण नहीं है। हम यैंडेक्स में उन्हें लांचर कहते थे, और रिपोर्ट में मैं "लॉन्चर" शब्द का उपयोग करूंगा।



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

अब किन कारणों से हमें मेमोरी को ऑप्टिमाइज़ करने की आवश्यकता है। मैं हमारे कारण से शुरू करता हूँ। संक्षेप में, यह Android Go है। और अब लंबे समय तक। 2017 के अंत में, Google ने Android Oreo और इसका विशेष संस्करण, Android Oreo Go संस्करण पेश किया। इसमें क्या खास बात है? यह संस्करण कम-अंत के लिए डिज़ाइन किया गया है, जिसमें एक गीगाबाइट रैम तक के सस्ती फोन हैं। वह और क्या खास है? Android के इस संस्करण पर पहले से इंस्टॉल किए गए एप्लिकेशन के लिए, Google अतिरिक्त आवश्यकताओं को आगे रखता है। विशेष रूप से - रैम की खपत के लिए आवश्यकताएं। मोटे तौर पर, लॉन्च के कुछ समय बाद, एप्लिकेशन की मेमोरी हटा दी जाती है, और फोन की स्क्रीन के आकार के आधार पर, लॉन्चर के लिए आकार 30-50 मेगाबाइट से अधिक नहीं होना चाहिए। सबसे छोटे पर 30, बड़े स्क्रीन पर 50।

यह भी ध्यान दिया जाना चाहिए कि Google इस क्षेत्र को विकसित करना जारी रखता है, और पहले से ही एक एंड्रॉइड पाई गो संस्करण है।

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

ठीक है, अब हम जानते हैं कि मेमोरी को क्यों ऑप्टिमाइज़ करना है। आइए देखें कि इसे मापने का क्या मतलब है और इसमें क्या शामिल है।

^{_{स्लाइड से लिंक करें}}

शायद आप में से कई लोगों ने यह तस्वीर देखी होगी। यह एक मेमोरी व्यू से एंड्रॉइड स्टूडियो प्रोफाइल का स्क्रीनशॉट है। इस टूल का वर्णन डेवलपर.android.com पर पर्याप्त विवरण में किया गया है। शायद आप में से कई लोगों ने उनका इस्तेमाल किया है। किसने उपयोग नहीं किया - प्रयास करें।

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

^{_{स्लाइड से लिंक: पहला , दूसरा}}

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

ऐसा करने के लिए, आपको एक छोटी उपयोगिता, एक पेशेवर कनवर्टर का उपयोग करने की आवश्यकता होगी। यह एंड्रॉइड गो एडिशन के साथ आता है और इसके कई फायदे हैं। उदाहरण के लिए, यह जीएस जड़ों तक पथ का निर्माण कर सकता है। यह देखने में हमें बहुत मदद करता है कि कौन सी कक्षाएं लॉन्चर द्वारा लोड की जाती हैं और कब लोड होती हैं। हम Android Studio Profiler का उपयोग करके ऐसा नहीं कर सकते थे।



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

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

और अंत में हमारे पास कुल है, यह सूचीबद्ध सभी वर्गों का योग है। हम इसे कम करना चाहते हैं।



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

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

बहुत बढ़िया। हम जानते हैं कि हमें मेमोरी को ऑप्टिमाइज़ करने की आवश्यकता क्यों है, इसे कैसे ठीक से मापना है, इसमें क्या शामिल है। चलो अभ्यास करने के लिए, और मैं आपको बताता हूं कि हमने लॉन्चर में मेमोरी को कैसे अनुकूलित किया है।



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



मुख्य प्रक्रिया के आवंटन के संबंध में, जावा हीप का एक बड़ा खंड था, बहुत सारे ग्राफिक्स, बड़ा कोड, और काफी बड़ा मूल ढेर।



सबसे पहले, हमने समस्या को बहुत भोलेपन से समझा और कुछ संसाधनों से Google की कुछ सिफारिशों का पालन करने का फैसला किया, समस्या को जल्दी हल करने का प्रयास करें। हमने संकलित प्रक्रिया के दौरान उत्पन्न सिंथेटिक तरीकों पर ध्यान आकर्षित किया। हमारे पास उनमें से 2 हजार से ज्यादा थे। कुछ घंटों में, हम सभी ने उन्हें हटा दिया, मेमोरी हटा दी।



और उन्हें कोड सेक्शन में लगभग एक या दो मेगाबाइट का लाभ मिला। बहुत बढ़िया।

इसके बाद, हमने अपना ध्यान आकर्षित करने के लिए किया। जैसा कि आप जानते हैं, एनम एक वर्ग है। और जैसा कि Google ने अंततः स्वीकार किया, enum बहुत स्मृति कुशल नहीं है। हमने सभी Enum का InDef और StringDef में अनुवाद किया। यहाँ आप मुझसे आपत्ति कर सकते हैं कि ProgArt यहाँ मदद करेगा। लेकिन वास्तव में, ProgArt सभी एनम को आदिम प्रकारों से प्रतिस्थापित नहीं करेगा। इसे स्वयं करना बेहतर है। वैसे, हमारे पास 90 से अधिक एनुम थे, काफी थे।



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

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



इससे एक निश्चित लाभ भी मिला, और इस अनुकूलन में हमें कई दिन लगे, जिनमें से अधिकांश हमने मैन्युअल रूप से किए।

फिर हमने एक और विशिष्ट कदम उठाया। हमने देखा कि हमारी तीन प्रक्रियाएँ हैं। जैसा कि हम जानते हैं, एंड्रॉइड में भी एक खाली प्रक्रिया लगभग 8-10 मेगाबाइट मेमोरी लेती है, काफी।

प्रक्रियाओं के बारे में विवरण मेरे सहयोगी आर्थर वासिलोव द्वारा बताया गया था। बहुत समय पहले मोसड्रोइड सम्मेलन में उनकी रिपोर्ट नहीं थी , एंड्रॉइड गो के बारे में भी।



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



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

हमने मेमोरी में हमारे इमेज कैश को भी चेक किया। यह पता चला कि उनमें से सभी इष्टतम नहीं थे, फोन की स्क्रीन के अनुरूप सभी चित्र नहीं थे, जिस पर लॉन्चर चल रहा था स्मृति में संग्रहीत किया गया था।

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



एक अन्य पुस्तकालय ने एक स्थिर ब्लॉक में ऑडियो फाइलें भी भरीं, जिसमें लगभग 700 किलोबाइट मेमोरी का कब्जा था।



हमने ऐसी लाइब्रेरीज़ को इनिशियलाइज़ करना बंद कर दिया, उनके साथ तभी काम करना शुरू किया, जब यूज़र्स को इन फंक्शन्स की वाकई ज़रूरत थी। इन सभी अनुकूलन में कई सप्ताह लग गए। हमने बहुत परीक्षण किया, जाँच की कि हम अतिरिक्त समस्याओं का परिचय नहीं देते। लेकिन नेटिव, हीप, कोड और जावा हीप वर्गों में लगभग 25 से 40 मेगाबाइट में भी हमें अच्छी जीत मिली।

लेकिन यह पर्याप्त नहीं था। मेमोरी की खपत अभी भी 30 मेगाबाइट तक नहीं गिरी है। ऐसा लगता था कि हमने कुछ सरल स्वचालित और सुरक्षित अनुकूलन के लिए सभी विकल्पों को समाप्त कर दिया था।

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

यह ध्यान दिया जाना चाहिए कि कोई भी विकल्प नहीं है जो आप चुनते हैं, आपको किसी भी तरह एंड्रॉइड गो के लिए संस्करण में अपने आवेदन की सुविधाओं का हिस्सा छोड़ देना होगा। यह सामान्य है। Google अपने गो ऐप्स में भी ऐसा ही करता है।

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



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

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

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

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