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

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

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

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

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

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

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 फ़ाइल में शामिल नहीं होते. जैसे, लेआउट फ़ाइलें और इमेज.
  • classes.dex: इसमें DEX फ़ाइल फ़ॉर्मैट में कंपाइल की गई क्लास शामिल होती हैं. इस फ़ॉर्मैट को Dalvik या ART वर्चुअल मशीन समझ सकती है.
  • AndroidManifest.xml: इसमें मुख्य Android मेनिफ़ेस्ट फ़ाइल शामिल होती है. इस फ़ाइल में, ऐप्लिकेशन का नाम, वर्शन, ऐक्सेस के अधिकार, और रेफ़रंस वाली लाइब्रेरी फ़ाइलें शामिल होती हैं. यह फ़ाइल, Android के बाइनरी एक्सएमएल फ़ॉर्मैट का इस्तेमाल करती है.

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

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

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

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

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

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

Kotlin

android {
    // Other settings.

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

शानदार

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 फ़ाइल फ़ॉर्मैट का इस्तेमाल करने वाली इमेज के सभी फ़्रेम और टाइमिंग डेटा को डिकोड किया जा सकता है.

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

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

सिर्फ़ चुनिंदा डेंसिटी के साथ काम करना

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

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

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

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

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

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

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

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

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

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

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 में इमेज फ़ाइल सेव करने की ज़रूरत नहीं होती.

पीएनजी फ़ाइलों को क्रंच करना

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

aapt की ये सीमाएं हैं:

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

    • Kotlin

        buildTypes.all { isCrunchPngs = false }

    शानदार

        buildTypes.all { isCrunchPngs = false }

पीएनजी और जेपीईजी फ़ाइलों को कंप्रेस करना

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

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

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

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

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

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

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

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

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

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

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

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

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

नेटिव और Java कोड का साइज़ कम करना

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

अपने-आप जनरेट हुए ऐसे कोड को हटाना जिसकी ज़रूरत नहीं है

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

इन्यूमरेशन से बचना

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

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

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

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

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

नेटिव लाइब्रेरी को एक्सट्रैक्ट करने से बचना

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

कई लीन APK बनाए रखना

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

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

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

ज़्यादा जानकारी के लिए, कई APK बनाना और कई APK के लिए सहायता लेख पढ़ें.