अपने ऐप्लिकेशन का आकार कम करना

उपयोगकर्ता अक्सर ऐसे ऐप्लिकेशन डाउनलोड करने से बचते हैं जिनका साइज़ बहुत ज़्यादा होता है. खास तौर पर, उभरते हुए देशों में ऐसा ज़्यादा होता है. इन देशों में, डिवाइसों को 2G और 3G नेटवर्क से कनेक्ट किया जाता है या वे डेटा की सीमा वाले प्लान पर काम करते हैं. इस पेज पर, ऐप्लिकेशन के डाउनलोड साइज़ को कम करने का तरीका बताया गया है. इससे ज़्यादा लोग आपके ऐप्लिकेशन को डाउनलोड कर पाते हैं.

Android ऐप्लिकेशन बंडल की मदद से ऐप्लिकेशन अपलोड करना

Google Play पर ऐप्लिकेशन पब्लिश करते समय, ऐप्लिकेशन का साइज़ तुरंत कम करने के लिए, उसे Android ऐप्लिकेशन बंडल के तौर पर अपलोड करें. Android ऐप्लिकेशन बंडल, अपलोड करने का एक ऐसा फ़ॉर्मैट है जिसमें आपके ऐप्लिकेशन का कंपाइल किया गया पूरा कोड और संसाधन शामिल होते हैं. हालांकि, APK जनरेट करने और साइन करने का काम Google Play पर छोड़ दिया जाता है.

इसके बाद, Google Play का ऐप्लिकेशन उपलब्ध कराने वाला मॉडल, आपके ऐप्लिकेशन बंडल का इस्तेमाल करके, हर उपयोगकर्ता के डिवाइस कॉन्फ़िगरेशन के लिए ऑप्टिमाइज़ किए गए APK जनरेट करता है और उन्हें उपलब्ध कराता है. इससे, उपयोगकर्ता सिर्फ़ उस कोड और संसाधनों को डाउनलोड करते हैं जिनकी उन्हें आपका ऐप्लिकेशन चलाने के लिए ज़रूरत होती है. आपको अलग-अलग डिवाइसों के लिए, कई APK बनाने, उन पर हस्ताक्षर करने, और उन्हें मैनेज करने की ज़रूरत नहीं होती. साथ ही, उपयोगकर्ताओं को छोटे और ज़्यादा ऑप्टिमाइज़ किए गए डाउनलोड मिलते हैं.

Google Play, ऐप्लिकेशन बंडल के ज़रिए पब्लिश किए गए ऐप्लिकेशन के लिए, 200 एमबी की कंप्रेस किए गए डाउनलोड साइज़ की पाबंदी लागू करता है. Play फ़ीचर डिलीवरी और Play ऐसेट डिलीवरी का इस्तेमाल करके, ऐप्लिकेशन का साइज़ बढ़ाया जा सकता है. हालांकि, ऐप्लिकेशन का साइज़ बढ़ने से, उसे इंस्टॉल किए जाने की दर पर बुरा असर पड़ सकता है. साथ ही, उसे अनइंस्टॉल किए जाने की दर बढ़ सकती है. इसलिए, हमारा सुझाव है कि आप इस पेज पर बताई गई गाइडलाइन का पालन करें, ताकि ऐप्लिकेशन का डाउनलोड साइज़ जितना हो सके उतना कम किया जा सके.

ध्यान दें: Google Play पर साइन किए गए APK अपलोड करके पब्लिश किए गए ऐप्लिकेशन के लिए, कंप्रेस किए गए डाउनलोड का साइज़ 100 एमबी से ज़्यादा नहीं होना चाहिए.

APK के स्ट्रक्चर को समझना

अपने ऐप्लिकेशन का साइज़ कम करने से पहले, ऐप्लिकेशन के APK के स्ट्रक्चर को समझना ज़रूरी है. APK फ़ाइल में एक ZIP संग्रह होता है. इसमें आपके ऐप्लिकेशन की सभी फ़ाइलें शामिल होती हैं. इन फ़ाइलों में Java क्लास फ़ाइलें, संसाधन फ़ाइलें, और कंपाइल किए गए संसाधनों वाली फ़ाइल शामिल होती है.

किसी APK में ये डायरेक्ट्री होती हैं:

• META-INF/: इसमें CERT.SF और CERT.RSA सिग्नेचर फ़ाइलें होती हैं. साथ ही, इसमें MANIFEST.MF मेनिफ़ेस्ट फ़ाइल भी होती है.
• assets/: इसमें ऐप्लिकेशन की ऐसेट होती हैं. ऐप्लिकेशन, AssetManager ऑब्जेक्ट का इस्तेमाल करके इन ऐसेट को वापस पा सकता है.
• res/: इसमें ऐसे संसाधन शामिल होते हैं जिन्हें resources.arsc में कंपाइल नहीं किया जाता.
• lib/: इसमें कंपाइल किया गया कोड होता है, जो प्रोसेसर की सॉफ़्टवेयर लेयर के लिए खास होता है. इस डायरेक्ट्री में, हर प्लैटफ़ॉर्म टाइप के लिए एक सबडायरेक्ट्री होती है. जैसे, armeabi, armeabi-v7a, arm64-v8a, x86, x86_64, और mips.

APK में ये फ़ाइलें भी शामिल होती हैं. सिर्फ़ AndroidManifest.xml की जानकारी देना ज़रूरी है:

• resources.arsc: इसमें कंपाइल किए गए संसाधन शामिल होते हैं. इस फ़ाइल में, res/values/ फ़ोल्डर के सभी कॉन्फ़िगरेशन का एक्सएमएल कॉन्टेंट होता है. पैकेजिंग टूल, इस एक्सएमएल कॉन्टेंट को निकालता है. इसके बाद, इसे बाइनरी फ़ॉर्म में कंपाइल करता है और कॉन्टेंट को संग्रहित करता है. इस कॉन्टेंट में भाषा की स्ट्रिंग और स्टाइल शामिल होती हैं. साथ ही, इसमें ऐसे कॉन्टेंट के पाथ भी शामिल होते हैं जो सीधे तौर पर resources.arsc फ़ाइल में शामिल नहीं होते. जैसे, लेआउट फ़ाइलें और इमेज.
  ध्यान दें: इस फ़ाइल को अपने APK में कंप्रेस न करें.
• classes.dex: इसमें DEX फ़ाइल फ़ॉर्मैट में कंपाइल की गई क्लास होती हैं. इन्हें Dalvik या ART वर्चुअल मशीन समझ सकती है.
• AndroidManifest.xml: इसमें Android की मुख्य मेनिफ़ेस्ट फ़ाइल होती है. इस फ़ाइल में, ऐप्लिकेशन का नाम, वर्शन, ऐक्सेस करने के अधिकार, और रेफ़र की गई लाइब्रेरी फ़ाइलों की सूची होती है. यह फ़ाइल, Android के बाइनरी एक्सएमएल फ़ॉर्मैट का इस्तेमाल करती है.

संसाधनों की संख्या और साइज़ कम करना

आपके APK के साइज़ से इस बात पर असर पड़ता है कि आपका ऐप्लिकेशन कितनी तेज़ी से लोड होता है, कितनी मेमोरी इस्तेमाल करता है, और कितनी बैटरी खर्च करता है. APK में मौजूद संसाधनों की संख्या और साइज़ कम करके, APK का साइज़ कम किया जा सकता है. खास तौर पर, उन संसाधनों को हटाया जा सकता है जिनका इस्तेमाल आपका ऐप्लिकेशन अब नहीं करता. इसके अलावा, इमेज फ़ाइलों की जगह, स्केलेबल Drawable ऑब्जेक्ट का इस्तेमाल किया जा सकता है. इस सेक्शन में, इन तरीकों और अन्य तरीकों के बारे में बताया गया है. इनकी मदद से, अपने ऐप्लिकेशन में मौजूद संसाधनों को कम किया जा सकता है, ताकि आपके APK का कुल साइज़ कम हो सके.

इस्तेमाल न किए गए संसाधन हटाना

lint टूल, Android Studio में शामिल एक स्टैटिक कोड विश्लेषक है. यह आपके res/ फ़ोल्डर में मौजूद उन संसाधनों का पता लगाता है जिनका इस्तेमाल आपके कोड में नहीं किया गया है. जब lint टूल को आपके प्रोजेक्ट में कोई ऐसा संसाधन मिलता है जिसका इस्तेमाल नहीं किया गया है, तो वह इस उदाहरण की तरह एक मैसेज दिखाता है:

res/layout/preferences.xml: Warning: The resource R.layout.preferences appears
    to be unused [UnusedResources]

ध्यान दें: lint टूल, assets/ फ़ोल्डर को स्कैन नहीं करता. इसके अलावा, यह रिफ़्लेक्शन के ज़रिए रेफ़र की गई ऐसेट या आपके ऐप्लिकेशन से लिंक की गई लाइब्रेरी फ़ाइलों को भी स्कैन नहीं करता. यह टूल, संसाधनों को भी नहीं हटाता. यह सिर्फ़ आपको उनकी मौजूदगी के बारे में सूचना देता है.

आपके कोड में जोड़ी गई लाइब्रेरी में, ऐसे संसाधन शामिल हो सकते हैं जिनका इस्तेमाल नहीं किया गया है. अगर आपने अपने ऐप्लिकेशन की build.gradle.kts फ़ाइल में shrinkResources को चालू किया है, तो Gradle आपकी ओर से संसाधनों को अपने-आप हटा सकता है.

Kotlin

android {
    // Other settings.

    buildTypes {
        getByName("release") {
            minifyEnabled = true
            shrinkResources = true
            proguardFiles(getDefaultProguardFile('proguard-android.txt'), "proguard-rules.pro")
        }
    }
}

Groovy

android {
    // Other settings.

    buildTypes {
        release {
            minifyEnabled true
            shrinkResources true
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
    }
}

shrinkResources का इस्तेमाल करने के लिए, कोड का साइज़ कम करने की सुविधा चालू करें. बिल्ड प्रोसेस के दौरान, R8 सबसे पहले इस्तेमाल न किए गए कोड को हटाता है. इसके बाद, Android Gradle प्लग-इन, इस्तेमाल न किए गए संसाधनों को हटा देता है.

कोड और संसाधन को छोटा करने के बारे में ज़्यादा जानने के लिए, अपने ऐप्लिकेशन को छोटा, उलझाएं, और ऑप्टिमाइज़ करें लेख पढ़ें. इसमें Android Studio के ज़रिए APK का साइज़ कम करने के अन्य तरीकों के बारे में भी बताया गया है.

Android Gradle प्लगिन 7.0 और इसके बाद के वर्शन में, उन कॉन्फ़िगरेशन का एलान किया जा सकता है जिन्हें आपका ऐप्लिकेशन सपोर्ट करता है. Gradle, इस जानकारी को बिल्ड सिस्टम को भेजता है. इसके लिए, वह resourceConfigurations फ़्लेवर और defaultConfig विकल्प का इस्तेमाल करता है. इसके बाद, बिल्ड सिस्टम, उन संसाधनों को APK में दिखने से रोकता है जो अन्य कॉन्फ़िगरेशन के साथ काम नहीं करते. इससे APK का साइज़ कम हो जाता है. इस सुविधा के बारे में ज़्यादा जानने के लिए, इस्तेमाल नहीं किए गए वैकल्पिक संसाधनों को हटाना लेख पढ़ें.

लाइब्रेरी से संसाधनों का इस्तेमाल कम से कम करना

Android ऐप्लिकेशन डेवलप करते समय, आम तौर पर बाहरी लाइब्रेरी का इस्तेमाल किया जाता है. इससे ऐप्लिकेशन को इस्तेमाल करना आसान हो जाता है और उसमें कई तरह की सुविधाएं जोड़ी जा सकती हैं. उदाहरण के लिए, पुराने डिवाइसों पर उपयोगकर्ता अनुभव को बेहतर बनाने के लिए, AndroidX का इस्तेमाल किया जा सकता है. इसके अलावा, अपने ऐप्लिकेशन में मौजूद टेक्स्ट के लिए अपने-आप होने वाले अनुवाद पाने के लिए, Google Play Services का इस्तेमाल किया जा सकता है.

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

ध्यान दें: कोड छोटा करने की सुविधा का इस्तेमाल करके, लाइब्रेरी के कुछ गैर-ज़रूरी कोड को हटाया जा सकता है. हालांकि, इससे कुछ बड़ी इंटरनल डिपेंडेंसी नहीं हटाई जा सकती हैं.

ऐनिमेशन वाली इमेज को डिकोड करने की सुविधा

Android 12 (एपीआई लेवल 31) में, NDK ImageDecoder एपीआई को बड़ा किया गया है. इससे ऐनिमेटेड GIF और ऐनिमेटेड WebP फ़ाइल फ़ॉर्मैट का इस्तेमाल करने वाली इमेज के सभी फ़्रेम और टाइमिंग डेटा को डिकोड किया जा सकता है.

ImageDecoder का इस्तेमाल करें. इससे APK का साइज़ कम होगा. साथ ही, सुरक्षा और परफ़ॉर्मेंस से जुड़े आने वाले अपडेट का फ़ायदा मिलेगा.

ImageDecoder एपीआई के बारे में ज़्यादा जानकारी के लिए, ImageDecoder और GitHub पर मौजूद सैंपल देखें.API reference

सिर्फ़ कुछ खास डेंसिटी के साथ काम करता है

Android, अलग-अलग स्क्रीन डेंसिटी के साथ काम करता है. जैसे:

• ldpi
• mdpi
• tvdpi
• hdpi
• xhdpi
• xxhdpi
• xxxhdpi

Android, ऊपर दी गई डेंसिटी के साथ काम करता है. हालांकि, आपको अपनी रास्टर इमेज को हर डेंसिटी में एक्सपोर्ट करने की ज़रूरत नहीं है.

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

अगर आपके ऐप्लिकेशन को सिर्फ़ स्केल की गई इमेज की ज़रूरत है, तो drawable-nodpi/ में किसी इमेज का सिर्फ़ एक वर्शन रखकर, ज़्यादा स्टोरेज बचाया जा सकता है. हमारा सुझाव है कि आप अपने ऐप्लिकेशन में कम से कम एक xxhdpi इमेज वैरिएंट शामिल करें.

स्क्रीन की डेंसिटी के बारे में ज़्यादा जानने के लिए, स्क्रीन के साइज़ और डेंसिटी देखें.

ड्रॉ किए जा सकने वाले ऑब्जेक्ट का इस्तेमाल करना

कुछ इमेज के लिए, स्टैटिक इमेज रिसॉर्स की ज़रूरत नहीं होती. इसके बजाय, फ़्रेमवर्क रनटाइम के दौरान इमेज को डाइनैमिक तरीके से बना सकता है. Drawable ऑब्जेक्ट या XML में <shape>, आपके APK में थोड़ी जगह ले सकते हैं. इसके अलावा, एक्सएमएल Drawable ऑब्जेक्ट, मटेरियल डिज़ाइन के दिशा-निर्देशों के मुताबिक मोनोक्रोमैटिक इमेज जनरेट करते हैं.

संसाधनों का फिर से इस्तेमाल करना

किसी इमेज के अलग-अलग वर्शन के लिए, अलग-अलग संसाधन शामिल किए जा सकते हैं. जैसे, एक ही इमेज के रंगीन, शेड वाले या घुमाए गए वर्शन. हालांकि, हमारा सुझाव है कि आप संसाधनों के उसी सेट का फिर से इस्तेमाल करें और रनटाइम के दौरान, उन्हें अपनी ज़रूरत के हिसाब से बदलें.

Android, ऐसेट का रंग बदलने के लिए कई सुविधाएं देता है. इसके लिए, android:tint और tintMode एट्रिब्यूट का इस्तेमाल किया जा सकता है.

इसके अलावा, उन संसाधनों को भी हटाया जा सकता है जो किसी दूसरे संसाधन के सिर्फ़ घुमाए गए वर्शन हैं. नीचे दिए गए कोड स्निपेट में, इमेज के बीच वाले हिस्से को घुमाकर और उसे 180 डिग्री घुमाकर, "पसंद करें" को "नापसंद करें" में बदलने का उदाहरण दिया गया है:

<?xml version="1.0" encoding="utf-8"?>
<rotate xmlns:android="http://schemas.android.com/apk/res/android"
    android:drawable="@drawable/ic_thumb_up"
    android:pivotX="50%"
    android:pivotY="50%"
    android:fromDegrees="180" />

कोड से रेंडर करना

इमेज को प्रोसीजर के हिसाब से रेंडर करके भी, अपने APK का साइज़ कम किया जा सकता है. प्रोसीजरल रेंडरिंग से स्टोरेज की जगह खाली हो जाती है, क्योंकि अब आपको अपने APK में इमेज फ़ाइल सेव नहीं करनी होती.

PNG फ़ाइलों को कंप्रेस करना

aapt टूल, बिल्ड प्रोसेस के दौरान res/drawable/ में मौजूद इमेज रिसॉर्स को ऑप्टिमाइज़ कर सकता है. साथ ही, बिना क्वालिटी में बदलाव किए उन्हें कंप्रेस कर सकता है. उदाहरण के लिए, aapt टूल, 256 से ज़्यादा रंगों की ज़रूरत न होने वाली किसी ट्रू-कलर पीएनजी इमेज को, कलर पैलेट वाली 8-बिट पीएनजी इमेज में बदल सकता है. ऐसा करने से, इमेज की क्वालिटी में कोई बदलाव नहीं होता, लेकिन वह कम मेमोरी इस्तेमाल करती है.

aapt के लिए ये सीमाएं लागू होती हैं:

• aapt टूल, asset/ फ़ोल्डर में मौजूद PNG फ़ाइलों का साइज़ कम नहीं करता.
• aapt टूल से इमेज फ़ाइलों को ऑप्टिमाइज़ करने के लिए, उनमें 256 या इससे कम रंगों का इस्तेमाल किया जाना चाहिए.
• aapt टूल, पहले से कंप्रेस की गई PNG फ़ाइलों का साइज़ बढ़ा सकता है. इससे बचने के लिए, PNG फ़ाइलों के लिए इस प्रोसेस को बंद करने के लिए, isCrunchPngs फ़्लैग का इस्तेमाल किया जा सकता है:

Kotlin

    buildTypes.all { isCrunchPngs = false }
    

Groovy

    buildTypes.all { isCrunchPngs = false }
    

PNG और JPEG फ़ाइलों को कंप्रेस करना

pngcrush, pngquant या zopflipng जैसे टूल का इस्तेमाल करके, इमेज की क्वालिटी को कम किए बिना PNG फ़ाइल के साइज़ को कम किया जा सकता है. ये सभी टूल, इमेज की क्वालिटी को बनाए रखते हुए PNG फ़ाइल का साइज़ कम कर सकते हैं.

pngcrush टूल खास तौर पर असरदार है. यह टूल, PNG फ़िल्टर और zlib (Deflate) पैरामीटर को दोहराता है. साथ ही, इमेज को कंप्रेस करने के लिए, फ़िल्टर और पैरामीटर के हर कॉम्बिनेशन का इस्तेमाल करता है. इसके बाद, यह उस कॉन्फ़िगरेशन को चुनता है जिससे कंप्रेस किया गया सबसे छोटा आउटपुट मिलता है.

JPEG फ़ाइलों को कंप्रेस करने के लिए, packJPG और guetzli जैसे टूल इस्तेमाल किए जा सकते हैं.

WebP फ़ाइल फ़ॉर्मैट का इस्तेमाल करना

इमेज के लिए, PNG या JPEG फ़ाइलों के बजाय WebP फ़ाइल फ़ॉर्मैट का इस्तेमाल किया जा सकता है. WebP फ़ॉर्मैट में, JPG और PNG की तरह लॉसी कंप्रेस करने और ट्रांसपेरेंसी की सुविधा मिलती है. साथ ही, यह JPEG या PNG की तुलना में बेहतर तरीके से कंप्रेस कर सकता है.

Android Studio का इस्तेमाल करके, मौजूदा BMP, JPG, PNG या स्टैटिक GIF इमेज को WebP फ़ॉर्मैट में बदला जा सकता है. ज़्यादा जानकारी के लिए, WebP इमेज बनाना लेख पढ़ें.

वेक्टर ग्राफ़िक का इस्तेमाल करना

वेक्टर ग्राफ़िक का इस्तेमाल करके, रिज़ॉल्यूशन से अलग आइकॉन और अन्य स्केलेबल मीडिया बनाए जा सकते हैं. इन ग्राफ़िक का इस्तेमाल करके, अपने APK फ़ुटप्रिंट को काफ़ी हद तक कम किया जा सकता है. Android में वेक्टर इमेज को VectorDrawable ऑब्जेक्ट के तौर पर दिखाया जाता है. VectorDrawable ऑब्जेक्ट की मदद से, 100 बाइट की फ़ाइल से स्क्रीन के साइज़ की साफ़ इमेज जनरेट की जा सकती है.

हालांकि, सिस्टम को हर VectorDrawable ऑब्जेक्ट को रेंडर करने में ज़्यादा समय लगता है. साथ ही, बड़ी इमेज को स्क्रीन पर दिखने में और भी ज़्यादा समय लगता है. इसलिए, इन वेक्टर ग्राफ़िक का इस्तेमाल सिर्फ़ तब करें, जब आपको छोटी इमेज दिखानी हों.

VectorDrawable ऑब्जेक्ट के साथ काम करने के बारे में ज़्यादा जानने के लिए, ड्रॉएबल देखें.

ऐनिमेटेड इमेज के लिए वेक्टर ग्राफ़िक का इस्तेमाल करना

फ़्रेम-बाय-फ़्रेम ऐनिमेशन बनाने के लिए, AnimationDrawable का इस्तेमाल न करें. ऐसा इसलिए, क्योंकि इसके लिए आपको ऐनिमेशन के हर फ़्रेम के लिए एक अलग बिटमैप फ़ाइल शामिल करनी होगी. इससे आपके APK का साइज़ काफ़ी बढ़ जाता है.

इसके बजाय, ऐनिमेटेड वेक्टर ड्रॉएबल बनाने के लिए, AnimatedVectorDrawableCompat का इस्तेमाल करें.

नेटिव और Java कोड कम करना

अपने ऐप्लिकेशन में Java और नेटिव कोडबेस का साइज़ कम करने के लिए, इन तरीकों का इस्तेमाल किया जा सकता है.

जनरेट किए गए गैर-ज़रूरी कोड को हटाना

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

गिनती करने से बचें

एक enum, आपके ऐप्लिकेशन की classes.dex फ़ाइल में करीब 1.0 से 1.4 केबी जोड़ सकता है. ये बदलाव, जटिल सिस्टम या शेयर की गई लाइब्रेरी के लिए तेज़ी से जुड़ सकते हैं. अगर हो सके, तो एन्यूमरेशन हटाने और उन्हें पूर्णांकों में बदलने के लिए, @IntDef एनोटेशन और कोड श्रिंकिंग का इस्तेमाल करें. इस तरह के कन्वर्ज़न से, टाइप सेफ़्टी के सभी फ़ायदे मिलते हैं.

नेटिव बाइनरी का साइज़ कम करना

अगर आपके ऐप्लिकेशन में नेटिव कोड और Android NDK का इस्तेमाल किया जाता है, तो कोड को ऑप्टिमाइज़ करके भी अपने ऐप्लिकेशन के रिलीज़ वर्शन का साइज़ कम किया जा सकता है. डीबग सिंबल हटाने और नेटिव लाइब्रेरी को एक्सट्रैक्ट न करने जैसी दो तकनीकों का इस्तेमाल किया जा सकता है.

डीबग सिंबल हटाना

अगर आपका ऐप्लिकेशन डेवलपमेंट मोड में है और अब भी उसमें डीबग करने की ज़रूरत है, तो डीबग सिंबल का इस्तेमाल करना सही है. Android NDK में दिए गए arm-eabi-strip टूल का इस्तेमाल करके, नेटिव लाइब्रेरी से गैर-ज़रूरी डीबग सिंबल हटाएं. इसके बाद, रिलीज़ बिल्ड को कंपाइल किया जा सकता है.

नेटिव लाइब्रेरी निकालने से बचें

अपने ऐप्लिकेशन का रिलीज़ वर्शन बनाते समय, बिना कंप्रेस की गई .so फ़ाइलों को APK में पैकेज करें. इसके लिए, अपने ऐप्लिकेशन की build.gradle.kts फ़ाइल में useLegacyPackaging को false पर सेट करें. इस फ़्लैग को बंद करने पर, PackageManager को इंस्टॉल करने के दौरान, APK से फ़ाइल सिस्टम में .so फ़ाइलों को कॉपी करने से रोका जाता है. इस तरीके से, आपके ऐप्लिकेशन के अपडेट का साइज़ कम हो जाता है.

एक से ज़्यादा Lean APK बनाए रखना

आपके APK में ऐसा कॉन्टेंट हो सकता है जिसे उपयोगकर्ता डाउनलोड तो करते हैं, लेकिन कभी इस्तेमाल नहीं करते. जैसे, अतिरिक्त भाषा या स्क्रीन डेंसिटी के हिसाब से संसाधन. अपने उपयोगकर्ताओं के लिए कम से कम डाउनलोड साइज़ वाला ऐप्लिकेशन उपलब्ध कराने के लिए, Google Play पर Android ऐप्लिकेशन बंडल का इस्तेमाल करके अपना ऐप्लिकेशन अपलोड करें. ऐप्लिकेशन बंडल अपलोड करने से, Google Play हर उपयोगकर्ता के डिवाइस कॉन्फ़िगरेशन के लिए, ऑप्टिमाइज़ किए गए APKs जनरेट और डिलीवर कर पाता है. इससे उपयोगकर्ता सिर्फ़ उस कोड और संसाधनों को डाउनलोड कर पाते हैं जिनकी उन्हें आपका ऐप्लिकेशन चलाने के लिए ज़रूरत होती है. आपको अलग-अलग डिवाइसों के लिए, कई APKs बनाने, उन पर हस्ताक्षर करने, और उन्हें मैनेज करने की ज़रूरत नहीं होती. साथ ही, उपयोगकर्ताओं को कम साइज़ वाले और ज़्यादा ऑप्टिमाइज़ किए गए डाउनलोड मिलते हैं.

अगर आपको Google Play पर अपना ऐप्लिकेशन पब्लिश नहीं करना है, तो अपने ऐप्लिकेशन को कई APK में बांटा जा सकता है. इन्हें स्क्रीन साइज़ या जीपीयू टेक्सचर सपोर्ट जैसे फ़ैक्टर के आधार पर अलग-अलग किया जा सकता है.

जब कोई व्यक्ति आपका ऐप्लिकेशन डाउनलोड करता है, तो उसके डिवाइस को डिवाइस की सुविधाओं और सेटिंग के हिसाब से सही APK मिलता है. इस तरह, डिवाइसों को उन सुविधाओं के लिए ऐसेट नहीं मिलती हैं जो डिवाइसों में नहीं हैं. उदाहरण के लिए, अगर किसी उपयोगकर्ता के पास hdpi डिवाइस है, तो उसे xxxhdpi ऐसे संसाधनों की ज़रूरत नहीं है जिन्हें आपने ज़्यादा डेनसिटी वाले डिसप्ले वाले डिवाइसों के लिए शामिल किया हो.

ज़्यादा जानकारी के लिए, एक से ज़्यादा APK बनाना और एक से ज़्यादा APK इस्तेमाल करने की सुविधा देखें.