ART कॉन्फ़िगर करें

इस पेज पर, Android Runtime (ART) और उसके कंपाइलेशन के विकल्पों को कॉन्फ़िगर करने का तरीका बताया गया है. यहां बताए गए विषयों में, सिस्टम इमेज को पहले से कॉम्पाइल करने का कॉन्फ़िगरेशन, dex2oat कॉम्पाइल करने के विकल्प, और सिस्टम के पार्टीशन स्पेस, डेटा के पार्टीशन स्पेस, और परफ़ॉर्मेंस को समझने का तरीका शामिल है.

ART के साथ काम करने के लिए, ART और Dalvik और Dalvik के लिए बने एक्सीक्यूटेबल फ़ॉर्मैट देखें. अपने ऐप्लिकेशन के सही तरीके से काम करने की पुष्टि करने के लिए, Android Runtime (ART) पर ऐप्लिकेशन के व्यवहार की पुष्टि करना लेख पढ़ें.

एआरटी कैसे काम करता है

ART, पहले से कंपाइल किए गए कोड (एओटी) का इस्तेमाल करता है. Android 7 से, यह एओटी कंपाइलेशन, ऐप्लिकेशन के इस्तेमाल के दौरान कंपाइल होने वाले कोड (जेआईटी) कंपाइलेशन, और इंटरप्रिटेशन के हाइब्रिड कॉम्बिनेशन का इस्तेमाल करता है. साथ ही, एओटी कंपाइलेशन को प्रोफ़ाइल के हिसाब से बनाया जा सकता है. इन सभी एक्सीक्यूशन मोड के कॉम्बिनेशन को कॉन्फ़िगर किया जा सकता है. इस बारे में इस सेक्शन में बताया गया है. उदाहरण के लिए, Pixel डिवाइसों को इस फ़्लो में काम करने के लिए कॉन्फ़िगर किया गया है:

  1. किसी ऐप्लिकेशन को सबसे पहले, Play Store से डिस्ट्रिब्यूट की गई dex मेटाडेटा (.dm) फ़ाइल के साथ इंस्टॉल किया जाता है. इसमें क्लाउड प्रोफ़ाइल होती है. ART AOT, क्लाउड प्रोफ़ाइल में दिए गए तरीकों को संकलित करता है. इसके अलावा, अगर ऐप्लिकेशन को dex मेटाडेटा फ़ाइल के बिना इंस्टॉल किया जाता है, तो कोई AOT कंपाइलेशन नहीं किया जाता.
  2. ऐप्लिकेशन के शुरू में चलने पर, AOT से कंपाइल नहीं किए गए तरीकों को डिकोड किया जाता है. जिन तरीकों को बार-बार इस्तेमाल किया जाता है उन्हें JIT-कंपाइल किया जाता है. ART, प्रोग्राम के लागू होने के आधार पर एक लोकल प्रोफ़ाइल जनरेट करता है और उसे क्लाउड प्रोफ़ाइल (अगर कोई मौजूद है) के साथ जोड़ता है.
  3. जब डिवाइस इस्तेमाल में नहीं है और चार्ज हो रहा है, तो कंपाइलेशन डेमन ऐप्लिकेशन को फिर से कंपाइल करने के लिए चलता है. यह कंपाइलेशन, पहले कुछ रन के दौरान जनरेट की गई प्रोफ़ाइल के आधार पर होता है.
  4. ऐप्लिकेशन के बाद के रन पर, ART, कंपाइलेशन के दौरान जनरेट किए गए आर्टफ़ैक्ट का इस्तेमाल करता है. इनमें, AOT से कंपाइल किए गए कोड की संख्या, पहले जनरेट किए गए कोड की तुलना में ज़्यादा होती है. AOT से कंपाइल नहीं किए गए तरीकों को अब भी इंटरप्रेट किया जाता है या JIT से कंपाइल किया जाता है. ART, प्रोफ़ाइल के इंस्टॉलेशन को अपडेट करता है. यह अपडेट, प्रोफ़ाइल के इस्तेमाल के आधार पर किया जाता है. इसके बाद, कंपाइलेशन डेमन के अगले रन में प्रोफ़ाइल को चुन लिया जाएगा.

ART में एक कंपाइलर (dex2oat टूल) और एक रनटाइम (libart.so) होता है, जो बूट के दौरान लोड होता है. dex2oat टूल, एक APK फ़ाइल लेता है और एक या उससे ज़्यादा कंपाइलेशन आर्टफ़ैक्ट फ़ाइलें जनरेट करता है. ये फ़ाइलें, रनटाइम लोड करता है. फ़ाइलों की संख्या, उनके एक्सटेंशन, और नाम, रिलीज़ के हिसाब से बदल सकते हैं. हालांकि, Android 8 रिलीज़ के बाद, ये फ़ाइलें जनरेट होती हैं:

  • .vdex: इसमें पुष्टि की प्रोसेस को तेज़ करने के लिए कुछ अतिरिक्त मेटाडेटा होता है. कभी-कभी, इसमें APK का अनकंप्रेस किया गया DEX कोड भी होता है.
  • .odex: इसमें APK के मैथड के लिए, एओटी से कॉम्पाइल किया गया कोड होता है.
  • .art (optional) में, APK में दी गई कुछ स्ट्रिंग और क्लास के ART के इंटरनल प्रतिनिधि शामिल होते हैं. इनका इस्तेमाल, ऐप्लिकेशन के शुरू होने की प्रोसेस को तेज़ करने के लिए किया जाता है.

कंपाइल करने के विकल्प

ART के लिए, कंपाइल करने के विकल्पों की दो कैटगरी हैं:

  1. सिस्टम रोम कॉन्फ़िगरेशन: सिस्टम इमेज बनाते समय, AOT किस कोड को कॉम्पाइल करता है.
  2. रनटाइम कॉन्फ़िगरेशन: इससे यह तय होता है कि ART, किसी डिवाइस पर ऐप्लिकेशन को कैसे कॉम्पाइल और चलाता है.

कंपाइलर फ़िल्टर

इन दोनों कैटगरी को कॉन्फ़िगर करने के लिए, ART का एक मुख्य विकल्प कंपाइलर फ़िल्टर है. कंपाइलर फ़िल्टर से यह तय होता है कि ART, DEX कोड को कैसे कंपाइल करता है. साथ ही, यह dex2oat टूल को दिया जाने वाला एक विकल्प है. Android 8 और उसके बाद के वर्शन में, आधिकारिक तौर पर ये चार फ़िल्टर काम करते हैं:

  • verify: सिर्फ़ DEX कोड की पुष्टि करता है (AOT कंपाइलेशन नहीं).
  • quicken: (Android 11 या इससे पहले के वर्शन) DEX कोड की पुष्टि करता है और बेहतर इंटरप्रेटर परफ़ॉर्मेंस पाने के लिए, कुछ DEX निर्देशों को ऑप्टिमाइज़ करता है.
  • speed: DEX कोड की पुष्टि करता है और सभी तरीकों को AOT-कंपाइल करता है. किसी भी कक्षा के लिए, कक्षा लोड करने की प्रोसेस को ऑप्टिमाइज़ नहीं करता.
  • speed-profile: DEX कोड की पुष्टि करता है, प्रोफ़ाइल में दिए गए तरीकों को एओटी-कंपाइल करता है, और प्रोफ़ाइल में मौजूद क्लास के लिए क्लास लोड को ऑप्टिमाइज़ करता है.

सिस्टम का ROM कॉन्फ़िगरेशन

सिस्टम इमेज बनाई जा रही है, तो पहले से इंस्टॉल की गई लाइब्रेरी और ऐप्लिकेशन को AOT-कंपाइल किया जाता है. इस प्रोसेस को dexpreopt कहा जाता है. ऐसी कंपाइल की गई फ़ाइलों का इस्तेमाल तब तक किया जा सकता है, जब तक सभी डिपेंडेंसी में कोई बदलाव न हो. खास तौर पर, बूट क्लासपाथ में कोई बदलाव न हो.

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

dexpreopt को कॉन्फ़िगर करने के लिए, ART बिल्ड के कई विकल्प उपलब्ध हैं. इन विकल्पों को कॉन्फ़िगर करने का तरीका, सिस्टम इमेज के लिए उपलब्ध स्टोरेज और पहले से इंस्टॉल किए गए ऐप्लिकेशन की संख्या पर निर्भर करता है. सिस्टम ROM में कंपाइल किए गए JAR/APK को चार कैटगरी में बांटा जा सकता है:

  • बूट क्लासपथ कोड: डिफ़ॉल्ट रूप से, speed-profile कंपाइलर फ़िल्टर के साथ कॉम्पाइल किया जाता है.
  • सिस्टम सर्वर कोड (इस दस्तावेज़ में आगे PRODUCT_SYSTEM_SERVER_JARS, PRODUCT_APEX_SYSTEM_SERVER_JARS, PRODUCT_STANDALONE_SYSTEM_SERVER_JARS, PRODUCT_APEX_STANDALONE_SYSTEM_SERVER_JARS देखें):
    • (Android 14 और उसके बाद के वर्शन) डिफ़ॉल्ट रूप से speed-profile कंपाइलर फ़िल्टर के साथ कंपाइल किया जाता है. अगर कोई प्रोफ़ाइल नहीं दी गई है, तो इसे speed कंपाइलर फ़िल्टर के साथ कंपाइल किया जाता है.
    • (Android 13 और उससे पहले के वर्शन) डिफ़ॉल्ट रूप से speed कंपाइलर फ़िल्टर के साथ कंपाइल किया गया.
    PRODUCT_SYSTEM_SERVER_COMPILER_FILTER की मदद से कॉन्फ़िगर किया जा सकता है (इस दस्तावेज़ में बाद में देखें).
  • प्रॉडक्ट के हिसाब से मुख्य ऐप्लिकेशन (इस दस्तावेज़ में बाद में PRODUCT_DEXPREOPT_SPEED_APPS देखें): डिफ़ॉल्ट रूप से, speed कंपाइलर फ़िल्टर के साथ कंपाइल किए जाते हैं.
  • अन्य सभी ऐप्लिकेशन: डिफ़ॉल्ट रूप से speed-profile कंपाइलर फ़िल्टर के साथ कंपाइल किए जाते हैं. इसके अलावा, अगर कोई प्रोफ़ाइल नहीं दी गई है, तो verify कंपाइलर फ़िल्टर के साथ कंपाइल किए जाते हैं.

    PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER की मदद से कॉन्फ़िगर किया जा सकता है (इस दस्तावेज़ में बाद में देखें).

Makefile के विकल्प

  • WITH_DEXPREOPT

    • क्या dex2oat को सिस्टम इमेज पर इंस्टॉल किए गए DEX कोड पर लागू किया जाता है. यह सुविधा डिफ़ॉल्ट रूप से चालू होती है.

  • DONT_DEXPREOPT_PREBUILTS (Android 5 और उसके बाद के वर्शन)

    • DONT_DEXPREOPT_PREBUILTS को चालू करने से, पहले से बने टूल को डिक्सप्रीऑप्ट होने से रोका जा सकता है. ये ऐसे ऐप्लिकेशन हैं जिनके Android.mk में include $(BUILD_PREBUILT) तय किया गया है. Google Play के ज़रिए अपडेट किए जाने वाले पहले से बने ऐप्लिकेशन के लिए, dexpreopt को छोड़ने पर, सिस्टम इमेज में जगह बचती है. हालांकि, इससे डिवाइस के पहली बार चालू होने में लगने वाला समय बढ़ जाता है. ध्यान दें कि इस विकल्प का, Android.bp में तय किए गए पहले से बने ऐप्लिकेशन पर कोई असर नहीं पड़ता.

  • PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER (Android 9 और उसके बाद के वर्शन)

    • PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER, dexpreopt किए गए ऐप्लिकेशन के लिए डिफ़ॉल्ट कंपाइलर फ़िल्टर तय करता है. इन ऐप्लिकेशन के बारे में Android.bp में बताया गया है या उनके Android.mk में include $(BUILD_PREBUILT) की जानकारी दी गई है. अगर कोई वैल्यू नहीं दी गई है, तो डिफ़ॉल्ट वैल्यू speed-profile होती है. अगर कोई वैल्यू नहीं दी गई है और प्रोफ़ाइल नहीं दी गई है, तो डिफ़ॉल्ट वैल्यू verify होती है.

  • WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY (Android 8 MR1 से)

    • WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY dexpreopts को चालू करने पर, सिर्फ़ बूट क्लासपथ और सिस्टम सर्वर के jar फ़ाइलों को डीपक्स किया जाता है.

  • LOCAL_DEX_PREOPT

    • Dexpreopt को किसी ऐप्लिकेशन के हिसाब से चालू या बंद भी किया जा सकता है. इसके लिए, मॉड्यूल की परिभाषा में LOCAL_DEX_PREOPT विकल्प की जानकारी दें. यह उन ऐप्लिकेशन के dexpreopt को बंद करने के लिए फ़ायदेमंद हो सकता है जिन्हें Google Play से तुरंत अपडेट मिल सकते हैं. ऐसा इसलिए, क्योंकि अपडेट से सिस्टम इमेज में dexpreopt किया गया कोड अमान्य हो जाएगा. यह सुविधा, बड़े वर्शन के अपग्रेड के लिए ओटीए (ओवर-द-एयर) में जगह बचाने के लिए भी काम की है. ऐसा इसलिए है, क्योंकि हो सकता है कि उपयोगकर्ताओं के पास डेटा सेक्शन में ऐप्लिकेशन के नए वर्शन पहले से मौजूद हों.

    LOCAL_DEX_PREOPT में true या false वैल्यू का इस्तेमाल किया जा सकता है. इससे, dexpreopt को क्रमशः चालू या बंद किया जा सकता है. इसके अलावा, nostripping का इस्तेमाल करके यह तय किया जा सकता है कि dexpreopt को APK या JAR फ़ाइल से classes.dex फ़ाइल को हटाना है या नहीं. आम तौर पर, इस फ़ाइल को हटा दिया जाता है, क्योंकि dexpreopt के बाद इसकी ज़रूरत नहीं होती. हालांकि, तीसरे पक्ष के APK हस्ताक्षर मान्य रखने के लिए, यह आखिरी विकल्प ज़रूरी है.

  • PRODUCT_DEX_PREOPT_BOOT_FLAGS

    • dex2oat को विकल्प भेजता है, ताकि यह कंट्रोल किया जा सके कि बूट इमेज को कैसे संकलित किया जाए. इसका इस्तेमाल, पसंद के मुताबिक बनाई गई इमेज क्लास की सूचियों, इकट्ठा की गई क्लास की सूचियों, और कंपाइलर फ़िल्टर की जानकारी देने के लिए किया जा सकता है.

  • PRODUCT_DEX_PREOPT_DEFAULT_FLAGS

    • dex2oat को विकल्प भेजता है, ताकि यह कंट्रोल किया जा सके कि बूट इमेज के अलावा बाकी सभी चीज़ों को कैसे कंपाइल किया जाए.

  • PRODUCT_DEX_PREOPT_MODULE_CONFIGS

    • किसी खास मॉड्यूल और प्रॉडक्ट कॉन्फ़िगरेशन के लिए, dex2oat विकल्प पास करने की सुविधा देता है. इसे प्रॉडक्ट की device.mk फ़ाइल में $(call add-product-dex-preopt-module-config,<modules>,<option>) के ज़रिए सेट किया जाता है. यहां <modules>, JAR और APK फ़ाइलों के लिए LOCAL_MODULE और LOCAL_PACKAGE नामों की सूची है.

  • PRODUCT_DEXPREOPT_SPEED_APPS (Android 8 से)

    • उन ऐप्लिकेशन की सूची जिन्हें प्रॉडक्ट के लिए मुख्य ऐप्लिकेशन के तौर पर पहचाना गया है और जिन्हें speed कंपाइलर फ़िल्टर के साथ कंपाइल करना ज़रूरी है. उदाहरण के लिए, SystemUI जैसे ऐप्लिकेशन को प्रोफ़ाइल के हिसाब से कंपाइल करने का मौका, सिर्फ़ अगले रीबूट के समय मिलता है. इसलिए, प्रॉडक्ट के लिए यह बेहतर होगा कि इन ऐप्लिकेशन को हमेशा एओटी के ज़रिए कंपाइल किया जाए.

  • PRODUCT_SYSTEM_SERVER_APPS (Android 8 से)

    • सिस्टम सर्वर से लोड किए गए ऐप्लिकेशन की सूची. इन ऐप्लिकेशन को डिफ़ॉल्ट रूप से speed कंपाइलर फ़िल्टर के साथ कंपाइल किया जाता है.

  • PRODUCT_ART_TARGET_INCLUDE_DEBUG_BUILD (Android 8 के बाद)

    • डिवाइस पर ART का डीबग वर्शन शामिल करना है या नहीं. यह सुविधा डिफ़ॉल्ट रूप से, userdebug और eng बिल्ड के लिए चालू होती है. इस व्यवहार को बदला जा सकता है. इसके लिए, विकल्प को true या false पर सेट करें.

    डिफ़ॉल्ट रूप से, डिवाइस बिना डीबग वाले वर्शन (libart.so) का इस्तेमाल करता है. इसे बदलने के लिए, सिस्टम प्रॉपर्टी persist.sys.dalvik.vm.lib.2 को libartd.so पर सेट करें.

  • WITH_DEXPREOPT_PIC (Android 7 तक)

    • Android 5.1.0 से लेकर Android 6.0.1 तक, WITH_DEXPREOPT_PIC का इस्तेमाल करके, पोज़िशन-इंडिपेंडेंट कोड (पीआईसी) को चालू किया जा सकता है. इसकी मदद से, इमेज से इकट्ठा किए गए कोड को /system से /data/dalvik-cache में फिर से सेट करने की ज़रूरत नहीं होती. इससे डेटा पार्टीशन में जगह बचती है. हालांकि, रनटाइम पर इसका थोड़ा असर पड़ता है, क्योंकि यह उस ऑप्टिमाइज़ेशन को बंद कर देता है जो पोज़िशन पर निर्भर कोड का फ़ायदा लेता है. आम तौर पर, /data में जगह बचाने के लिए, डिवाइसों को PIC कंपाइलेशन की सुविधा चालू करनी चाहिए.

    Android 7.0 में, पीआईसी कंपाइलेशन डिफ़ॉल्ट रूप से चालू था.

  • WITH_DEXPREOPT_BOOT_IMG_ONLY (Android 7 MR1 तक)

    • इस विकल्प को WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY के साथ बदल दिया गया है. यह विकल्प, सिस्टम सर्वर के JAR को भी पहले से ऑप्ट इन करता है.

  • PRODUCT_SYSTEM_SERVER_COMPILER_FILTER

    • यह विकल्प, सिस्टम सर्वर के लिए कंपाइलर फ़िल्टर तय करता है.

    • (Android 14 और उसके बाद के वर्शन) अगर कोई जानकारी नहीं दी जाती है, तो speed-profile कंपाइलर फ़िल्टर का इस्तेमाल किया जाता है. अगर कोई प्रोफ़ाइल नहीं दी जाती है, तो speed कंपाइलर फ़िल्टर का इस्तेमाल किया जाता है.
    • (Android 13 और इससे पहले के वर्शन) अगर कोई वैल्यू नहीं दी जाती है, तो speed कंपाइलर फ़िल्टर का इस्तेमाल किया जाता है.
    • अगर इसे speed पर सेट किया जाता है, तो speed कंपाइलर फ़िल्टर का इस्तेमाल किया जाता है.
    • अगर इसे speed-profile पर सेट किया जाता है, तो speed-profile कंपाइलर फ़िल्टर का इस्तेमाल किया जाता है. इसके अलावा, अगर कोई प्रोफ़ाइल नहीं दी जाती है, तो verify कंपाइलर फ़िल्टर का इस्तेमाल किया जाता है.
    • अगर इसे verify पर सेट किया जाता है, तो verify कंपाइलर फ़िल्टर का इस्तेमाल किया जाता है.

  • PRODUCT_SYSTEM_SERVER_JARS, PRODUCT_APEX_SYSTEM_SERVER_JARS, PRODUCT_STANDALONE_SYSTEM_SERVER_JARS, PRODUCT_APEX_STANDALONE_SYSTEM_SERVER_JARS

    • यहां सिस्टम सर्वर से लोड किए गए JAR की सूचियां दी गई हैं. JAR को PRODUCT_SYSTEM_SERVER_COMPILER_FILTER के ज़रिए तय किए गए कमपाइलर फ़िल्टर के साथ संकलित किया जाता है

    • (ज़रूरी है) PRODUCT_SYSTEM_SERVER_JARS: प्लैटफ़ॉर्म पर मौजूद सिस्टम सर्वर क्लासपथ JARs की सूची (यानी, SYSTEMSERVERCLASSPATH का हिस्सा). इस सूची में सिस्टम सर्वर क्लासपथ JARs जोड़ना ज़रूरी है. सिस्टम सर्वर क्लासपथ JAR को सूची में न जोड़ने पर, उन JAR को लोड नहीं किया जा सकता.
    • (ज़रूरी) PRODUCT_APEX_SYSTEM_SERVER_JARS: APEX के साथ डिलीवर किए गए सिस्टम सर्वर क्लासपथ JARs की सूची (यानी, SYSTEMSERVERCLASSPATH के हिस्से के तौर पर). इसका फ़ॉर्मैट <apex name>:<jar name> है. इस सूची में APEX सिस्टम सर्वर क्लासपथ JAR जोड़ना ज़रूरी है. इस सूची में APEX सिस्टम सर्वर क्लासपथ JAR जोड़ने में नतीजा यह होता है कि उन JAR को लोड नहीं किया जा सकता.
    • (ज़रूरी नहीं, Android 13 और उससे पहले के वर्शन के लिए) PRODUCT_STANDALONE_SYSTEM_SERVER_JARS: उन JAR की सूची जिन्हें सिस्टम सर्वर, अलग-अलग क्लासलोडर (SystemServiceManager.startServiceFromJar के ज़रिए) का इस्तेमाल करके डाइनैमिक तौर पर लोड करता है. इस सूची में स्टैंडअलोन सिस्टम सर्वर के JAR जोड़ना ज़रूरी नहीं है, लेकिन इसका ज़ोरदार सुझाव दिया जाता है. ऐसा करने से JAR कंपाइल हो जाते हैं और इसलिए, उनकी रनटाइम परफ़ॉर्मेंस अच्छी होती है.
    • (Android 13 के बाद से ज़रूरी है) PRODUCT_APEX_STANDALONE_SYSTEM_SERVER_JARS: APEX के साथ डिलीवर किए गए उन JAR की सूची जिन्हें सिस्टम सर्वर अलग-अलग क्लासलोडर का इस्तेमाल करके डाइनैमिक तौर पर लोड करता है. जैसे, SystemServiceManager.startServiceFromJar के ज़रिए या <apex-system-service> के तौर पर एलान किया गया. इसका फ़ॉर्मैट <apex name>:<jar name> है. इस सूची में, स्टैंडअलोन APEX सिस्टम सर्वर के JAR जोड़ना ज़रूरी है. इस सूची में स्टैंडअलोन APEX सिस्टम सर्वर JAR नहीं जोड़ने पर, डिवाइस को बूट करने में समस्या आती है.

    बूट क्लासपाथ कॉन्फ़िगरेशन

    पहले से लोड की गई क्लास की सूची, उन क्लास की सूची होती है जिन्हें Zygote, स्टार्टअप के समय शुरू करता है. इससे हर ऐप्लिकेशन को इन क्लास को अलग से शुरू करने की ज़रूरत नहीं पड़ती. इससे ऐप्लिकेशन तेज़ी से शुरू होते हैं और मेमोरी में पेज शेयर किए जा सकते हैं. डिफ़ॉल्ट रूप से, पहले से लोड की गई क्लास की सूची वाली फ़ाइल frameworks/base/config/preloaded-classes पर मौजूद होती है. इसमें ऐसी सूची होती है जो फ़ोन के सामान्य इस्तेमाल के लिए बनाई गई होती है. यह हो सकता है कि स्मार्टवॉच जैसे अन्य डिवाइसों के लिए, यह समय अलग हो. इसलिए, इसे उसी हिसाब से सेट करना चाहिए. इसे ट्यून करते समय सावधानी बरतें. बहुत ज़्यादा क्लास जोड़ने पर, इस्तेमाल न होने वाली क्लास लोड होने पर मेमोरी बर्बाद होती है. बहुत कम क्लास जोड़ने पर, हर ऐप्लिकेशन को अपनी कॉपी बनानी पड़ती है. इससे भी मेमोरी खर्च होती है.

    इस्तेमाल का उदाहरण (प्रॉडक्ट के device.mk में):

    PRODUCT_COPY_FILES += <filename>:system/etc/preloaded-classes

    ध्यान दें: आपको इस लाइन को, build/target/product/base.mk से डिफ़ॉल्ट तौर पर मिलने वाले प्रॉडक्ट कॉन्फ़िगरेशन मेकफ़ाइल को इनहेरिट करने से पहले डालना होगा.

    रनटाइम कॉन्फ़िगरेशन

    जेआईटी के विकल्प

    नीचे दिए गए विकल्प, सिर्फ़ उन Android रिलीज़ पर असर डालते हैं जिनमें ART JIT कंपाइलर उपलब्ध है.

    • dalvik.vm.usejit: JIT चालू है या नहीं.
    • dalvik.vm.jitinitialsize (डिफ़ॉल्ट तौर पर 64K): कोड कैश की शुरुआती क्षमता. कोड कैश मेमोरी में, समय-समय पर जीसी (गैर-ज़रूरी डेटा हटाना) की प्रोसेस चलती रहेगी. साथ ही, ज़रूरत पड़ने पर इसकी साइज़ भी बढ़ेगी.
    • dalvik.vm.jitmaxsize (डिफ़ॉल्ट तौर पर 64 एमबी): कोड कैश मेमोरी की ज़्यादा से ज़्यादा क्षमता.
    • dalvik.vm.jitthreshold (डिफ़ॉल्ट 10,000): यह थ्रेशोल्ड है, जिसे किसी तरीके के "गर्म होने" का काउंटर पास करना चाहिए, ताकि तरीका JIT-कंपाइल किया जा सके. "लोकप्रियता" काउंटर, रनटाइम के लिए एक इंटरनल मेट्रिक है. इसमें कॉल की संख्या, बैकवर्ड शाखाएं, और अन्य बातें शामिल हैं.
    • dalvik.vm.usejitprofiles (Android 13 तक): JIT प्रोफ़ाइलें चालू हैं या नहीं; इसका इस्तेमाल तब भी किया जा सकता है, जब dalvik.vm.usejit गलत हो. ध्यान दें कि अगर यह फ़ील्ड गलत है, तो कंपाइलर फ़िल्टर speed-profile किसी भी तरीके को एओटी-कंपाइल नहीं करता और यह verify के बराबर होता है. Android 14 के बाद से, JIT प्रोफ़ाइलें हमेशा चालू रहती हैं और इन्हें बंद नहीं किया जा सकता.
    • dalvik.vm.jitprithreadweight (डिफ़ॉल्ट रूप से dalvik.vm.jitthreshold / 20): ऐप्लिकेशन के यूज़र इंटरफ़ेस (यूआई) थ्रेड के लिए, JIT "सैंपल" का वज़न (jitthreshold देखें). उन तरीकों को तेज़ी से कंपाइल करने के लिए इस्तेमाल करें जिनसे ऐप्लिकेशन के साथ इंटरैक्ट करते समय, उपयोगकर्ताओं के अनुभव पर सीधे तौर पर असर पड़ता है.
    • dalvik.vm.jittransitionweight (डिफ़ॉल्ट रूप से dalvik.vm.jitthreshold / 10): कंपाइल कोड और इंटरप्रिटर के बीच ट्रांज़िशन करने वाले, वह तरीका जिसका इस्तेमाल करके मेथड को शुरू किया जाता है. इससे यह पक्का करने में मदद मिलती है कि ट्रांज़िशन (जो महंगे होते हैं) को कम करने के लिए, इस्तेमाल किए गए तरीके कोड में शामिल किए गए हों.

    Dex2oat के विकल्प

    इन विकल्पों का असर, डिवाइस पर कॉम्पाइल करने की प्रोसेस (जिसे dexopt भी कहा जाता है) पर पड़ता है. इनमें से कुछ विकल्पों का असर, dexpreopt पर भी पड़ता है. वहीं, ऊपर दिए गए सिस्टम रोम कॉन्फ़िगरेशन सेक्शन में बताए गए विकल्पों का असर सिर्फ़ dexpreopt पर पड़ता है.

    रिसॉर्स के इस्तेमाल को कंट्रोल करने के विकल्प:

    • dalvik.vm.image-dex2oat-threads/dalvik.vm.image-dex2oat-cpu-set (Android 11 तक): बूट इमेज के लिए इस्तेमाल की जाने वाली थ्रेड की संख्या और सीपीयू कोर का सेट (नीचे देखें).
    • dalvik.vm.boot-dex2oat-threads/dalvik.vm.boot-dex2oat-cpu-set:
      • (Android 11 तक) बूट इमेज के अलावा, बूट के दौरान इस्तेमाल करने के लिए, थ्रेड की संख्या और सीपीयू कोर का सेट (नीचे देखें).
      • (Android 12 से) बूट इमेज के साथ-साथ, बूट के समय इस्तेमाल करने के लिए, थ्रेड की संख्या और सीपीयू कोर का सेट (नीचे देखें).
        • खास तौर पर, Android 14 के बाद से, यह ART Service में प्राथमिकता वाली क्लास PRIORITY_BOOT से मेल खाता है.
    • dalvik.vm.restore-dex2oat-threads/dalvik.vm.restore-dex2oat-cpu-set:
      • (Android 11 से लेकर Android 13 तक) क्लाउड बैकअप से रिस्टोर करने के लिए, इस्तेमाल की जाने वाली थ्रेड की संख्या और सीपीयू कोर का सेट (नीचे देखें).
      • (Android 14 से) थ्रेड की संख्या और सीपीयू कोर का सेट (नीचे देखें), जिसका इस्तेमाल उन सभी कामों के लिए किया जाता है जिनमें सामान्य से ज़्यादा इंतज़ार करना पड़ता है. इनमें, क्लाउड बैकअप से रिस्टोर करना भी शामिल है.
        • खास तौर पर, यह ART Service में प्राथमिकता वाली क्लास PRIORITY_INTERACTIVE_FAST से जुड़ा है.
    • dalvik.vm.background-dex2oat-threads/ dalvik.vm.background-dex2oat-cpu-set (Android 14 के बाद से): बैकग्राउंड में इस्तेमाल करने के लिए, थ्रेड की संख्या और सीपीयू कोर का सेट (नीचे देखें).
      • खास तौर पर, यह ART सेवा में प्राथमिकता वाली कक्षा PRIORITY_BACKGROUND से जुड़ा है.
    • dalvik.vm.dex2oat-threads/dalvik.vm.dex2oat-cpu-set: अन्य सभी कामों के लिए इस्तेमाल होने वाली थ्रेड की संख्या और सीपीयू कोर का सेट.

    सीपीयू कोर का सेट, सीपीयू आईडी की कॉमा से अलग की गई सूची के तौर पर दिया जाना चाहिए. उदाहरण के लिए, सीपीयू कोर 0 से 3 पर dex2oat को चलाने के लिए, यह सेट करें:

    dalvik.vm.dex2oat-cpu-set=0,1,2,3

    सीपीयू अफ़िनिटी प्रॉपर्टी सेट करते समय, हमारा सुझाव है कि आप dex2oat थ्रेड की संख्या के लिए, उससे जुड़ी प्रॉपर्टी को चुने गए सीपीयू की संख्या से मैच करें. इससे, ग़ैर-ज़रूरी मेमोरी और I/O कॉन्टेंट से जुड़ी समस्याओं से बचा जा सकता है: 

    dalvik.vm.dex2oat-cpu-set=0,1,2,3
dalvik.vm.dex2oat-threads=4

    ऊपर दी गई सिस्टम प्रॉपर्टी के अलावा, dex2oat के संसाधन के इस्तेमाल को कंट्रोल करने के लिए, टास्क प्रोफ़ाइल का भी इस्तेमाल किया जा सकता है. इसके लिए, Cgroup Abstraction Layer देखें.

    ये टास्क प्रोफ़ाइल काम करती हैं:

    • Dex2OatBackground (Android 14 से) (डिफ़ॉल्ट रूप से Dex2OatBootComplete इनहेरिट करता है): बैकग्राउंड में इस्तेमाल किए जाने वाले संसाधनों को कंट्रोल करता है.
      • खास तौर पर, यह ART सेवा में प्राथमिकता वाली कक्षा PRIORITY_BACKGROUND से जुड़ा है.
    • Dex2OatBootComplete:
      • (Android 13 तक) यह रिसोर्स कंट्रोल करता है कि बूट होने के बाद, सभी चीज़ों के लिए किस रिसोर्स का इस्तेमाल किया जाए.
      • (Android 14 से) यह रिसोर्स कंट्रोल करता है कि बूट होने के बाद, सभी चीज़ों के लिए किस रिसोर्स का इस्तेमाल किया जाए, न कि बैकग्राउंड में.
        • खास तौर पर, यह ART सेवा में प्राथमिकता वाली क्लास PRIORITY_INTERACTIVE_FAST और PRIORITY_INTERACTIVE से जुड़ा है.

    सिस्टम प्रॉपर्टी और टास्क प्रोफ़ाइल, दोनों की वैल्यू सबमिट करने पर, दोनों लागू हो जाती हैं.

    हेप का साइज़ कंट्रोल करने के विकल्प:

    • dalvik.vm.image-dex2oat-Xms: बूट इमेज के लिए शुरुआती हेप साइज़.
    • dalvik.vm.image-dex2oat-Xmx: बूट इमेज के लिए हेप का ज़्यादा से ज़्यादा साइज़.
    • dalvik.vm.dex2oat-Xms: बाकी सभी चीज़ों के लिए, शुरुआती हेप साइज़.
    • dalvik.vm.dex2oat-Xmx: बाकी सभी चीज़ों के लिए, हेप का ज़्यादा से ज़्यादा साइज़.

    dex2oat के लिए, हेप के शुरुआती और ज़्यादा से ज़्यादा साइज़ को कंट्रोल करने वाले विकल्पों को कम नहीं किया जाना चाहिए. ऐसा करने से, उन ऐप्लिकेशन को सीमित किया जा सकता है जिन्हें संकलित किया जा सकता है.

    कंपाइलर फ़िल्टर को कंट्रोल करने के विकल्प:

    • dalvik.vm.image-dex2oat-filter (Android 11 तक): बूट इमेज के लिए कंपाइलर फ़िल्टर. Android 12 के बाद, बूट इमेज के लिए कंपाइलर फ़िल्टर हमेशा speed-profile होता है और इसे बदला नहीं जा सकता.
    • dalvik.vm.systemservercompilerfilter (Android 13 से): सिस्टम सर्वर के लिए कंपाइलर फ़िल्टर. PRODUCT_SYSTEM_SERVER_COMPILER_FILTER देखें.
    • dalvik.vm.systemuicompilerfilter (Android 13 से): सिस्टम यूज़र इंटरफ़ेस (यूआई) पैकेज के लिए कंपाइलर फ़िल्टर.
    • dalvik.vm.dex2oat-filter (Android 6 तक): बाकी सभी चीज़ों के लिए कंपाइलर फ़िल्टर.
    • pm.dexopt.<reason> (Android 7 से): बाकी सभी चीज़ों के लिए कंपाइलर फ़िल्टर. Android 14 और उसके बाद के वर्शन के लिए, ART सेवा कॉन्फ़िगरेशन देखें. इसके अलावा, Android 13 और उससे पहले के वर्शन के लिए, पैकेज मैनेजर कॉन्फ़िगरेशन देखें.

    बूट इमेज के अलावा, बाकी सभी चीज़ों के कंपाइलेशन को कंट्रोल करने के अन्य विकल्प:

    • dalvik.vm.dex2oat-very-large (Android 7.1 से): AOT कंपाइलेशन की सुविधा बंद करने के लिए, DEX फ़ाइल का कम से कम कुल साइज़ बाइट में.
    • dalvik.vm.dex2oat-swap (Android 7.1 से) (डिफ़ॉल्ट: true): dex2oat के लिए, स्वैप फ़ाइल का इस्तेमाल करने की अनुमति देता है. इससे, ज़्यादा मेमोरी का इस्तेमाल करने पर ऐप्लिकेशन के क्रैश होने से बचा जा सकता है. ध्यान दें कि अगर यह विकल्प चालू है, तो भी dex2oat सिर्फ़ कुछ खास स्थितियों में स्वैप फ़ाइल का इस्तेमाल करेगा. जैसे, जब dex फ़ाइलों की संख्या ज़्यादा हो. साथ ही, ये स्थितियां बदल सकती हैं.
    • dalvik.vm.ps-min-first-save-ms (Android 12 से): ऐप्लिकेशन को पहली बार लॉन्च करने पर, रनटाइम के ऐप्लिकेशन की प्रोफ़ाइल जनरेट करने से पहले, इंतज़ार करने का कम से कम समय.
    • dalvik.vm.ps-min-save-period-ms (Android 12 से): ऐप्लिकेशन की प्रोफ़ाइल अपडेट करने से पहले, कम से कम इतना समय इंतज़ार करना होगा.
    • dalvik.vm.dex2oat64.enabled (Android 11 से) (डिफ़ॉल्ट: गलत): dex2oat के 64-बिट वर्शन का इस्तेमाल करना है या नहीं.
    • dalvik.vm.bgdexopt.new-classes-percent (Android 12 से) (डिफ़ॉल्ट: 20): फिर से कंपाइल करने की प्रोसेस को ट्रिगर करने के लिए, किसी प्रोफ़ाइल में नई क्लास का कम से कम प्रतिशत, 0 से 100 के बीच होना चाहिए. यह सिर्फ़ प्रोफ़ाइल के हिसाब से कंपाइल करने (speed-profile) पर लागू होता है. आम तौर पर, यह बैकग्राउंड में dexopt करने के दौरान होता है. ध्यान दें कि प्रतिशत के थ्रेशोल्ड के अलावा, कम से कम 50 नई क्लास का भी थ्रेशोल्ड है. इसे कॉन्फ़िगर नहीं किया जा सकता.
    • dalvik.vm.bgdexopt.new-methods-percent (Android 12 से) (डिफ़ॉल्ट: 20): फिर से कंपाइल करने की प्रोसेस को ट्रिगर करने के लिए, किसी प्रोफ़ाइल में नए तरीकों का कम से कम प्रतिशत, 0 से 100 के बीच होना चाहिए. यह सिर्फ़ प्रोफ़ाइल के हिसाब से कंपाइल करने (speed-profile) पर लागू होता है. आम तौर पर, यह बैकग्राउंड में dexopt करने के दौरान होता है. ध्यान दें कि प्रतिशत थ्रेशोल्ड के अलावा, कम से कम 100 नए तरीकों का थ्रेशोल्ड भी है. इसे कॉन्फ़िगर नहीं किया जा सकता.
    • dalvik.vm.dex2oat-max-image-block-size (Android 10 से) (डिफ़ॉल्ट: 524288) कंप्रेस की गई इमेज के लिए, सॉलिड ब्लॉक का ज़्यादा से ज़्यादा साइज़. बड़ी इमेज को एक सेट में बांटा जाता है, जिसमें सभी ब्लॉक का साइज़ तय होता है.
    • dalvik.vm.dex2oat-resolve-startup-strings (Android 10 से) (डिफ़ॉल्ट: true) अगर यह 'सही' है, तो dex2oat उन सभी कॉन्स्ट-स्ट्रिंग को हल करेगा जिनका रेफ़रंस, प्रोफ़ाइल में "स्टार्टअप" के तौर पर मार्क किए गए तरीकों से किया गया है.
    • debug.generate-debug-info (डिफ़ॉल्ट: गलत) नेटिव डीबगिंग के लिए, डीबग की जानकारी जनरेट करनी है या नहीं. जैसे, स्टैक अनवाइंड करने की जानकारी, ELF सिंबल, और ड्रार्फ़ सेक्शन.
    • dalvik.vm.dex2oat-minidebuginfo (Android 9 से) (डिफ़ॉल्ट: true) क्या बैकट्रैस प्रिंट करने के लिए, LZMA से कंप्रेस की गई कम से कम डीबग जानकारी जनरेट करनी है या नहीं.

    ART सेवा के विकल्प

    Android 14 के बाद, ऐप्लिकेशन के लिए डिवाइस पर AOT कंपाइलेशन (जिसे dexopt भी कहा जाता है) को ART Service मैनेज करता है. ART Service को कॉन्फ़िगर करने के बारे में जानने के लिए, ART Service कॉन्फ़िगरेशन लेख पढ़ें.

    पैकेज मैनेजर के विकल्प

    Android 14 से पहले, ऐप्लिकेशन के लिए डिवाइस पर AOT कंपाइलेशन (जिसे dexopt भी कहा जाता है) को पैकेज मैनेजर मैनेज करता था. dexopt के लिए पैकेज मैनेजर को कॉन्फ़िगर करने के बारे में जानकारी पाने के लिए, पैकेज मैनेजर कॉन्फ़िगरेशन देखें.

    A/B के हिसाब से कॉन्फ़िगरेशन

    ROM कॉन्फ़िगरेशन

    Android 7.0 से, डिवाइसों में दो सिस्टम पार्टीशन का इस्तेमाल किया जा सकता है, ताकि A/B सिस्टम अपडेट की सुविधा चालू की जा सके. सिस्टम पार्टीशन का साइज़ कम करने के लिए, पहले से ऑप्ट इन की गई फ़ाइलों को इस्तेमाल में न आने वाले दूसरे सिस्टम पार्टीशन में इंस्टॉल किया जा सकता है. इसके बाद, उन्हें पहली बार बूट करने पर, डेटा सेगमेंट में कॉपी कर दिया जाता है.

    इस्तेमाल का उदाहरण (device-common.mk में):

    PRODUCT_PACKAGES += \
     cppreopts.sh
PRODUCT_PROPERTY_OVERRIDES += \
     ro.cp_system_other_odex=1

    साथ ही, डिवाइस के BoardConfig.mk में:

    BOARD_USES_SYSTEM_OTHER_ODEX := true

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

    SYSTEM_OTHER_ODEX_FILTER ?= app/% priv-app/%

    बैकग्राउंड में ओटीए (Over-The-Air) dexopt

    A/B फ़ॉर्मैट वाले डिवाइसों पर, रीबूट करने से पहले ऐप्लिकेशन को बैकग्राउंड में, नई सिस्टम इमेज के साथ कंपाइल किया जा सकता है. सिस्टम इमेज में कंपाइलेशन स्क्रिप्ट और बाइनरी को शामिल करने के लिए, बैकग्राउंड में ऐप्लिकेशन कंपाइल करना लेख पढ़ें. हालांकि, ऐसा करना ज़रूरी नहीं है. इस कलेक्शन के लिए इस्तेमाल किए गए कलेक्शन फ़िल्टर को इनके ज़रिए कंट्रोल किया जाता है:

    pm.dexopt.ab-ota=speed-profile

    हमारा सुझाव है कि प्रोफ़ाइल के हिसाब से कॉम्पाइल करने की सुविधा का फ़ायदा पाने और स्टोरेज बचाने के लिए, speed-profile का इस्तेमाल करें.

    JDWP के विकल्प

    userdebug बिल्ड में, Java Debug Wire Protocol (JDWP) थ्रेड बनाने की सुविधा को persist.debug.dalvik.vm.jdwp.enabled सिस्टम प्रॉपर्टी की मदद से कंट्रोल किया जाता है. डिफ़ॉल्ट रूप से, यह प्रॉपर्टी सेट नहीं होती और JDWP थ्रेड सिर्फ़ डीबग किए जा सकने वाले ऐप्लिकेशन के लिए बनाई जाती हैं. डीबग किए जा सकने वाले और डीबग नहीं किए जा सकने वाले, दोनों ऐप्लिकेशन के लिए JDWP थ्रेड चालू करने के लिए, persist.debug.dalvik.vm.jdwp.enabled को 1 पर सेट करें. प्रॉपर्टी में किए गए बदलावों को लागू करने के लिए, डिवाइस को रीस्टार्ट करना होगा.

    userdebug बिल्ड पर, ऐसे ऐप्लिकेशन को डीबग करने के लिए जिसे डीबग नहीं किया जा सकता, यह कमांड चलाकर JDWP चालू करें:

      adb shell setprop persist.debug.dalvik.vm.jdwp.enabled 1
  adb reboot
    Android 13 और उससे पहले के वर्शन पर चलने वाले डिवाइसों के लिए, रनटाइम, userdebug बिल्ड पर डीबग किए जा सकने वाले और डीबग नहीं किए जा सकने वाले ऐप्लिकेशन के लिए JDWP टास्क बनाता है. इसका मतलब है कि userdebug बिल्ड पर, किसी ऐप्लिकेशन को डीबगर से अटैच किया जा सकता है या उसकी प्रोफ़ाइल बनाई जा सकती है.