एंड्रॉइड गो भविष्य के अरब डिवाइस और 50 एमबी की सीमा है। यांडेक्स व्याख्यान

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

औसतन, यदि आप कैलकुलेटर, अलार्म घड़ी आदि नहीं लिखते हैं, तो आप बहुत अच्छे हैं, अच्छी तरह से किए गए हैं, और आपने सब कुछ अच्छा किया है, या आपका आवेदन 150-170 मेगाबाइट लेता है।

- मेरा नाम आर्थर है, मैं एक एंड्रॉइड डेवलपर हूं, मैं यैंडेक्स एप्लिकेशन पर काम कर रहा हूं। आज मैं आपके साथ एक कहानी साझा करूंगा कि हमने एंड्रॉइड गो को कैसे अनुकूलित किया। मैं आपको बताता हूं कि हमने किस तरह की रेक पर ठोकर खाई, हमारे लिए क्या काम नहीं किया और यह कैसे काम करता है, इसकी आवश्यकता क्यों है।

यह क्या है के बारे में एक छोटा सा विषयांतर। Android Go कम लागत वाले उपकरणों के लिए डिज़ाइन किया गया Android का एक विशेष संस्करण है। उनकी कीमत 60-100 डॉलर है, और इसलिए वे बहुत कमजोर हैं, धीमा, धीमा। इसलिए Google ने उनके लिए अपना सिस्टम बनाने का फैसला किया ताकि वे कम से कम किसी तरह सामान्य रूप से काम करें। यह 2017 में Google I / O पर घोषित किया गया था, यानी एक साल और कई महीने बीत चुके हैं। इसलिए, जब मिटप की घोषणा की गई थी, तो एक तार्किक सवाल उठाया गया था: "क्या आप अभी भी जीवित हैं, या क्या?" मैंने तब कहा कि सब ठीक है, सब ठीक है, मैं बताऊंगा। और अब, एक विशिष्ट इंटरनेट हीरो के रूप में, मैं पूर्व पोस्ट का जवाब दूंगा कि ऐसा क्यों हुआ।


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

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

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

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



सबसे पहले, यह अमूर्त अच्छा प्रदर्शन है। ऐसे डिवाइस पर आपका एप्लिकेशन अच्छी तरह से और जल्दी चलना चाहिए। हम हैं: “महान। हम काम कर रहे हैं। ”

इसके अलावा, पहले से ही विशिष्ट संख्याएँ हैं जिनके लिए हमें पत्र-व्यवहार करना चाहिए। एपीके को अनपैक करने और इंस्टॉल करने के बाद कब्जा कर लिया गया स्थान 40 मेगाबाइट से अधिक नहीं है। कभी-कभी यह एक समस्या है क्योंकि किसी और एपीके का वजन सभी 80 मेगाबाइट है। दुख होगा। इसके अलावा, यह पर्याप्त रूप से नहीं लिया जा सकता है और मापा जाता है। यही है, आप यह नहीं कह सकते हैं: "मुझे पता है कि मेरा एपीके का वजन इतना है, इसलिए स्थापना के बाद आवेदन में बहुत अधिक लगेगा।" यह सब बहुत कुछ विक्रेता, डिवाइस, एंड्रॉइड, आदि के संस्करण पर निर्भर करता है, लेकिन अगर आपका एपीके 10 मेगाबाइट लेता है, तो, सिद्धांत रूप में, सब कुछ ठीक है और आप कभी भी इस संख्या से अधिक नहीं होंगे।

और अब सबसे मजेदार और शांत आवश्यकता: आवेदन के साथ काम करते समय भस्म रैम 50 मेगाबाइट से अधिक नहीं होना चाहिए।

कौन जानता है कि ऑपरेशन के दौरान उसका एप्लिकेशन औसतन कितना रैम लेता है? इस मुद्दे पर किसने कभी सोचा? क्या 100 मेगाबाइट से कम वाले कोई हैं? सुंदर। लेकिन शायद तुम झूठ बोल रहे हो। सामान्य तौर पर, औसतन, यदि आप कैलकुलेटर, अलार्म घड़ी आदि नहीं लिखते हैं, तो या तो आप बहुत अच्छे हैं, अच्छी तरह से किया गया है और सब कुछ अच्छा किया है, या आपका आवेदन 150-170 मेगाबाइट लेता है। इसे 50 मेगाबाइट में डालना बहुत मुश्किल है। इसलिए, बाकी समय हम इसके बारे में बात करेंगे, हम चर्चा करेंगे कि ग्लोब को उल्लू कैसे बनाया जाए, आदि।


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

2018 में, Google I / O के माध्यम से जाने के बाद, आपको इस रिपोर्ट के संदर्भ के साथ मेमोरी के बारे में कहानी शुरू करने की आवश्यकता है। इसे किसने देखा?

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

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

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

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

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

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

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

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

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

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

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

एप्लिकेशन परिदृश्य भी परीक्षणों को प्रभावित करता है। आप पाठ पढ़ सकते हैं या आप चित्रों के एक समूह के साथ गैलरी में स्क्रॉल कर सकते हैं। और यह स्पष्ट है कि अधिक मेमोरी कहां होगी।

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


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

शायद किसी के पास अब सवाल है "मुझे यह सब क्यों चाहिए?" यह एक ऐसा ब्रेकर है जिसमें मैं इसके अलावा प्रेरणा के लिए भी कहूंगा।

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

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

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

एक और बिंदु है - आप Google Play से एंड्रॉइड गो डिवाइस को मैन्युअल रूप से बाहर कर सकते हैं, अर्थात यह कहें कि एप्लिकेशन को एंड्रॉइड गो डिवाइस पर इंस्टॉल नहीं किया जा सकता है। ऐसा बहुत पहले नहीं हुआ था।

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

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

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

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

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


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

कौन मानता है कि यह Android Go के लिए अच्छा है? और कौन सोचता है कि यह बुरा है? सुरक्षित रूप से।


समस्या यह है कि, हाँ, यह बुरा है, क्योंकि अंत में, आपके उपभोग किए गए एप्लिकेशन मेमोरी को सभी प्रक्रियाओं में गिना जाता है। अगर हम इस तरह की खाली प्रक्रिया को बिना किसी चीज़ के बनाते हैं और इस विशेष प्रक्रिया के बारे में सोचते हैं, तो हम देखेंगे कि इसमें 7 मेगाबाइट लगते हैं। 5-8 मेगाबाइट - यह प्रक्रिया के निर्माण से ऐसा ओवरहेड है। इसलिए, जब हम हर मेगाबाइट के लिए इसे 50 में निचोड़ने के लिए लड़ते हैं, तो ऐसी चीज हमें बहुत बुरी तरह से दी जाती है। विशेष रूप से, मान लें कि Yandex के पास सबसे लोकप्रिय Yandex.Metrica पुस्तकालय है, यह एक अलग प्रक्रिया में भी काम करता है, और यह हमें दर्द भी दे सकता है।


इसलिए, यदि कुछ बाहरी पुस्तकालय आपके पास आते हैं, उदाहरण के लिए, आप बस कह सकते हैं: “यार, कृपया मुख्य प्रक्रिया में काम करें। मैं मानता हूं कि यह धीमा हो सकता है, लेकिन यह अनावश्यक मेमोरी नहीं खाएगा। ” तो यह भी एक सूक्ष्म बिंदु है।



यदि हम मेमोरी खपत के बारे में बात करते हैं, तो चलो इस प्लेट पर चलते हैं, जो वहां है। हम एक खाली प्रोजेक्ट लेते हैं, और इस डिप्स को चलाते हैं, इस व्यवसाय को बंद करते हैं, और हम देखते हैं कि 50 में से 23 मेगाबाइट पहले ही ले लिए गए हैं। खाली "नमस्ते, दुनिया!" बिना कुछ भी, बस पाठ के साथ सक्रिय करें। यह बहुत दुख की बात है। यह एहसास से भी दुखी हो जाता है कि हम जावा हीप जैसे पैरामीटर को सीधे प्रभावित कर सकते हैं, अर्थात यह सीधे हमारे जावा ऑब्जेक्ट्स हैं जिन्हें हम स्पष्ट रूप से ट्रैक कर सकते हैं, जिन्हें हम हटा सकते हैं, कम कर सकते हैं, और कम से कम किसी तरह से बातचीत कर सकते हैं।

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


जावा हीप क्या है समझ में आता है। मूल निवासी क्या है यह मानने के लिए भी काफी तार्किक है। ये समान आवंटन हैं, केवल सकारात्मक हैं। वे फ्रेमवर्क से और आपके मूल पुस्तकालयों, .so फाइलों और बहुत कुछ से आते हैं।

कोड सीधे कोड स्टोरेज से संबंधित है। यह आपके .dex का आकार है, यह आपका .so है, ये संसाधन हैं, एमएमएपी फाइलें और वह सब। यानी कम कोड, बेहतर। सबसे सरल सत्य जो सामान्य रूप से हर चीज के बारे में काम करता है।

स्टैक जावा / सी ++ थ्रेड्स का एक ढेर है। यही है, प्रत्येक थ्रेड की अपनी कॉल स्टैक है, इसलिए प्रत्येक थ्रेड मेमोरी का ऐसा विशिष्ट क्षेत्र बनाता है जो इस पूरी चीज़ को संग्रहीत करता है।

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

निजी अन्य, सिस्टम - यह एक ऐसी चीज है जिसे हम बिल्कुल भी प्रभावित नहीं कर सकते हैं, और वास्तव में, बाकी सब कुछ जो बहुत वर्गीकृत नहीं है।



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



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



यदि आप थ्रेड्स के बारे में बात करना जारी रखते हैं, तो आप आसानी से देख सकते हैं कि आपके पास थ्रेड्स के लिए क्या है, वे आवेदन में क्या करते हैं। अलग-अलग उपकरण हैं। आप एक ही सिस्ट्रेस का उपयोग कर सकते हैं, आप अपनी प्रक्रिया की आईडी खोजने के लिए कंसोल का उपयोग कर सकते हैं, और सिस्टम में कौन से थ्रेड्स हैं, पीएस को पकड़ सकते हैं।

यदि आप अच्छी तरह से करते हैं और अपने थ्रेड्स को नाम देने के लिए सभी प्रकार के थ्रेडफैक्ट का उपयोग करते हैं, तो आप समझ सकते हैं कि आपके पास क्या होना चाहिए, क्या नहीं होना चाहिए, और इस तरह पूरी चीज को कम कर दें, क्योंकि एप्लिकेशन में 100 थ्रेड्स होना विशेष रूप से व्यर्थ है।

और क्या किया जा सकता है? समझौते के सुझावों का एक प्रसिद्ध सेट है: लीक के लिए देखें, पूल का उपयोग करें, जब आप की जरूरत नहीं है, और यह सब बकवास लागू होता है, तो वस्तुओं का निर्माण नहीं करते हैं। बहुत बढ़िया।

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

. , , , . , ? — — , . , , . . — .


dumpsys, , , . , , View, WebView, Assets, .


, , , , , SharedPreference SQLite - , , , .



, , Assets. , , – . 1,5 . -, , . .


— WebView. , WebView, , dumpsys, 100 , . , , - , , 300 — . , WebView , . -.



Google . . WebView, Google, - . WebView. .



Google Go, Android Go-. , - layout , . , , , Chrome Tabs, Chrome . .

Android Go, ? , Android Go, .


इसके कई तरीके हैं। -, , , Android Go . , , . , , , - build , - , , - . APK, , — uses-feature «low-memory», APK.

, , Android Go. Google. , , Go- .

, ? , , - , : «, - . ». . , , , , , - , , - . , , , , Google, Google , . , , , Android Go , , .

, , , -. .

, Google I/O: , - . , , , , , - , . , « , . ». . , . , .

? , . — , , 98% . , , , . . - Android Go-. , YouTube Go . YouTube , , , . मुझे नहीं पता , Android Go , , , — . — Facebook Lite, Twitter Lite, . Lite, - . -, , . Facebook, . , , . , — , Android Go.

? Stack Overflow, 1000 . . , , , . , , — dumpsys.

, Android , 512 , Android 4.4. API , .

, . , . — , .

, : « ». : «». . — , . - 170 . . - . ? , , , , - . - — . 105 . .


. build- -. densitySplit, , resConfig, . , , — . ProGuard . , ProGuard , , , , , stacktraces.

. , , Android Go- .

- 64 . : «, ». 14 , 4 , 60 . , . . , . — , , , , . , , , Android Go, . 10 , APK , , . , , .

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