/ PxHere / पीडी

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

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

पढ़ने से पहले

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

हमारे Google- अनुकूलित APK का वजन 4.4 था।

अतिरिक्त फाइलें

चलो एक साधारण से शुरू करते हैं। यदि आप कोटलिन-प्रतिबिंबित का उपयोग नहीं करते हैं , तो आप असेंबली से कोटलिन वर्गों के बारे में मेटा-जानकारी को बाहर कर सकते हैं। आप इस प्रकार कर सकते हैं:
build.gradle (Module: app)

 android { packagingOptions { exclude("META-INF/*.kotlin_module") exclude("**.kotlin_builtins") exclude("**.kotlin_metadata") } } 

जावा परावर्तन की आवश्यकता नहीं है। *.kotlin_module , *.kotlin_builtins और *.kotlin_metadata । यह निर्धारित करना कि आप किस प्रतिबिंब का उपयोग कर रहे हैं, बहुत सरल है। यदि आप obj::class.<method> लिखते हैं, तो आप kotlin प्रतिबिंब का उपयोग करते हैं, यदि obj::class.java.<method> , तो java प्रतिबिंब।

हमारे लिए अनुकूलन का परिणाम: -602.1 केबी

पर निर्भर करता है

पुस्तकालय कभी-कभी उन मामलों के लिए निर्भरता जोड़ते हैं जो आपके आवेदन में कभी नहीं होते हैं। उदाहरण के लिए, कोटर-क्लाइंट इसके साथ कोटलिन-रिफ्लेक्ट को खींचता है (0.5 mb!)।
मैं इस तरह के मामलों से minifyEnabled = true रहा: मैंने minifyEnabled = true को minifyEnabled = true साथ एकत्र किया, इसे एंड्रॉइड स्टूडियो विश्लेषक में फेंक दिया, mapping.txt डाउनलोड mapping.txt और उन पैकेजों की तलाश की, जो सिद्धांत रूप में, विधानसभा में मौजूद नहीं होने चाहिए। उदाहरण के लिए, kotlin.reflect । चलाने के बाद ./gradlew app:dependencies खोज करने के लिए प्रोजेक्ट फ़ोल्डर में निर्भरताएँ (टर्मिनल में इतिहास की लंबाई बढ़ाने के लिए मत भूलना। निर्भरता का पेड़ बड़ा हो सकता है!)। इस पेड़ से यह समझना आसान है कि अनावश्यक निर्भरता को संदर्भित करता है और उन्हें बाहर करता है। अपने मॉड्यूल के build.gradle :

 dependencies { implementation("io.ktor:ktor-client-core:$ktorVersion") { exclude(group: "org.jetbrains.kotlin", module: "kotlin-reflect") } implementation("io.ktor:ktor-client-okhttp:$ktorVersion") { exclude(group: "org.jetbrains.kotlin", module: "kotlin-reflect") } } 

यह कोड kotlin- प्रतिबिंबित पर कोटर- क्लाइंट लाइब्रेरी निर्भरता को हटाता है । यदि आप किसी और चीज़ को बाहर करना चाहते हैं, तो अपने मूल्यों को बदलें।

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

हमारे लिए अनुकूलन का परिणाम: -500.3 kb

अपने XML को मान्य करें

दुर्भाग्य से, प्रोगार्ड लेआउट फ़ोल्डर से अतिरिक्त XML मार्कअप फ़ाइलों को नहीं हटाता है। अप्रयुक्त एक्सएमएल "भारी" विगेट्स का उपयोग कर सकता है और प्रागार्ड उन्हें विधानसभा से भी बाहर करने में सक्षम नहीं होगा! इससे बचने के लिए, Refactor -> Remove unused resources... साथ अप्रयुक्त संसाधनों को हटा दें Refactor -> Remove unused resources... अप्रयुक्त संसाधनों को हटा दें Refactor -> Remove unused resources...

अपनी डीआई की जांच करें

यदि आप, हमारी तरह, रनटाइम DI का उपयोग करते हैं, तो जाँच करें कि क्या आपके पास उन निर्भरता के लिए प्रदाता हैं जिनका आप उपयोग नहीं कर रहे हैं। रक्षक उन्हें विधानसभा से बाहर नहीं कर सकते क्योंकि वे संकलक के दृष्टिकोण से अप्रयुक्त नहीं हैं। निर्भरता ग्राफ बनाते समय आप उनका उपयोग करते हैं।

रिलीज बिल्ड से डिबग डिपेंडेंसी को छोड़ दें

डिबगिंग टूल अप्रत्याशित रूप से बहुत सी जगह ले सकते हैं। उदाहरण के लिए, stetho वजन संपीड़न के बाद लगभग 0.2 ! किसी भी स्थिति में, संपूर्ण डिबगिंग अवसंरचना को रिलीज़ बिल्ड से बाहर करना बेहतर होता है ताकि कोई भी आपके एप्लिकेशन के बारे में Google Play से डाउनलोड करके बहुत अधिक न सीख सके।

आप डिबग और रिलीज़ के लिए एक ही फ़ाइलों के विभिन्न संस्करण बना सकते हैं। ऐसा करने के लिए, src फ़ोल्डर में, main बगल में, debug और release फ़ोल्डर बनाएँ। अब आप initStetho फंक्शन को लिख सकते हैं जो initStetho को src/debug/java/your/pkg/Stetho.kt में initStetho करता है और initStetho फ़ंक्शन करता है जो src/release/java/your/pkg/Stetho.kt में कुछ भी नहीं करता है।

बस मामले में, सुनिश्चित करें कि यह निर्भरता केवल डिबग बिल्ड में शामिल है। आप इसे debugImplementation में build.gradle debugImplementation साथ implementation को प्रतिस्थापित करके कर सकते हैं। अधिक बार नहीं, इस कदम के बिना भी, प्रॉपर अनावश्यक फ़ाइलों को समाप्त करता है, लेकिन हमेशा नहीं। प्रश्न का उत्तर "क्यों?" लेख के पाठ में नीचे ।

मंच

कभी-कभी, समान कोड आधार पर, किसी एप्लिकेशन के कई अलग-अलग संस्करण जारी किए जाते हैं। ये विभिन्न देशों या क्षेत्रों के लिए अलग-अलग संस्करण हो सकते हैं, या हमारे मामले में, विभिन्न ग्राहकों के लिए। नीचे प्लेटफ़ॉर्म को ऑफ़लोड करने के टिप्स दिए गए हैं।

/ PxHere / पीडी

हमारा अनुभव

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

झंडा अपवाद

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

 android { productFlavors { client1 { buildConfigField("boolean", "IS_CATALOG_ENABLED", "true") } client2 { buildConfigField("boolean", "IS_CATALOG_ENABLED", "false") } } } 

यह कॉन्फ़िगरेशन का एक सरलीकृत संस्करण है। हमारे सीआई के साथ एकीकरण के कारण वर्तमान जटिल है।

अब यह ज्ञात है कि घटक संकलन चरण पर सक्रिय है या नहीं, और इसे गार्ड असेंबली से बाहर कर सकता है!

XML फिर से

अब अप्रयुक्त XML लेआउट के साथ समस्या एक नए आयाम पर ले जाती है! आप केवल एक घटक के मार्कअप को केवल इसलिए नहीं निकाल और निकाल सकते हैं क्योंकि कुछ ग्राहकों को इसकी आवश्यकता नहीं है।

शायद ही कभी उपयोग किए जाने वाले घटकों में से एक के हमारे एक्सएमएल एप्लीकेशन में, हमने एक विजेट का उपयोग किया था, जो कि छवि मान्यता लाइब्रेरी firebase.ml.vision लिए संदर्भित है। इसका वजन लगभग 0.2 mb है, जो बहुत है। यह मार्कअप में घोषित करने के बजाय इस विजेट को कोड के साथ जोड़ने का निर्णय लिया गया। उसके बाद, प्रागार्ड उन ग्राहकों के लिए विधानसभा से vision को बाहर करने में सक्षम था, जिन्हें इसकी आवश्यकता नहीं है।

हमारे लिए अनुकूलन का परिणाम: -222.3 केबी औसत के लिए

@Keep

यह बताने के लिए 2 तरीके हैं कि आपकी कक्षा को छोटा नहीं किया जा सकता: फ़ाइल @Keep में एक नियम लिखें या @Keep एनोटेशन @Keep । play-services-vision लाइब्रेरी में, यह एनोटेशन रूट क्लास पर है। इसलिए, 0.2 mb उन क्लाइंट एप्लिकेशन में भी मृत हैं, जिन्हें छवि पहचान की आवश्यकता नहीं है।

मुझे इस एनोटेशन को निकालने का एक सरल और सुरक्षित तरीका नहीं मिला। यदि आप जानते हैं कि कैसे - कृपया टिप्पणियों में लिखें।

सौभाग्य से, firebase.ml.vision लाइब्रेरी, जो कि play-services-vision का एक नया संस्करण है, इस एनोटेशन का उपयोग नहीं करता है और हमने इस पर जाकर समस्या हल की है।

और फिर से डीआई

अंतिम लेकिन कम से कम नहीं। डिस्कनेक्ट किए गए घटकों के लिए डि। यहां सब कुछ सरल है: प्रत्येक घटक के लिए हम अपने कंटेनर का उपयोग करते हैं, और हम एक अलग मॉड्यूल के माध्यम से सामान्य निर्भरता को जोड़ते हैं।

हमारे लिए अनुकूलन परिणाम: औसत एपीके के लिए -20.1 केबी

निष्कर्ष

• औसत एपीके का वजन 4.4 से घटकर 3.1 और न्यूनतम - 2.5 से कम हो गया है!
• एप्लिकेशन कोड को नुकसान नहीं पहुंचाया गया, लेकिन सुधार हुआ। DI के साथ काम करना अब आसान है

लेख में प्रस्तुत सभी अनुकूलन "कम लटके हुए फल" हैं। वे लागू करने के लिए काफी आसान हैं और जल्दी से परिणाम प्राप्त करते हैं। हमारे मामले में पहले से ही अनुकूलित एपीके के लिए -43% तक । मुझे आशा है कि मैंने एक जगह सब कुछ सूचीबद्ध करके आपका समय बचाया।

आप सभी को धन्यवाद!