एआरटी कॉन्फ़िगर करें

यह पृष्ठ एंड्रॉइड रनटाइम (एआरटी) और इसके संकलन विकल्पों को कॉन्फ़िगर करने के तरीके पर चर्चा करता है। यहां संबोधित विषयों में सिस्टम छवि के प्रीकंपाइलेशन का कॉन्फ़िगरेशन, dex2oat संकलन विकल्प, और सिस्टम विभाजन स्थान, डेटा विभाजन स्थान और प्रदर्शन का व्यापार कैसे करें शामिल हैं।

एआरटी के साथ काम करने के लिए एआरटी और डाल्विक और डाल्विक निष्पादन योग्य प्रारूप देखें। यह सुनिश्चित करने के लिए कि आपके ऐप्स ठीक से काम कर रहे हैं , एंड्रॉइड रनटाइम (ART) पर ऐप व्यवहार को सत्यापित करना देखें।

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

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

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

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

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

संकलन विकल्प

एआरटी के लिए संकलन विकल्पों की दो श्रेणियां हैं:

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

संकलक फ़िल्टर

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

  • verify : केवल DEX कोड सत्यापन चलाएँ (कोई AOT संकलन नहीं)।
  • quicken : (एंड्रॉइड 11 तक) बेहतर दुभाषिया प्रदर्शन प्राप्त करने के लिए DEX कोड सत्यापन चलाएं और कुछ DEX निर्देशों को अनुकूलित करें।
  • speed : DEX कोड सत्यापन चलाएँ और सभी विधियों को AOT-संकलित करें।
  • speed-profile : प्रोफ़ाइल फ़ाइल में सूचीबद्ध DEX कोड सत्यापन और AOT-संकलन विधियाँ चलाएँ।

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

जब सिस्टम छवि बनाई जा रही होती है तो पूर्व-स्थापित लाइब्रेरी और ऐप्स एओटी-संकलित होते हैं। इस प्रक्रिया को डेक्सप्रोऑप्ट कहा जाता है। ऐसी संकलित फ़ाइलें तब तक उपयोग योग्य हैं जब तक सभी निर्भरताएँ अपरिवर्तित रहती हैं, विशेष रूप से बूट क्लासपाथ।

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

डेक्सप्रॉप्ट को कॉन्फ़िगर करने के लिए कई एआरटी बिल्ड विकल्प उपलब्ध हैं। आप इन विकल्पों को कैसे कॉन्फ़िगर करते हैं यह सिस्टम छवि के लिए उपलब्ध संग्रहण स्थान और पहले से इंस्टॉल किए गए एप्लिकेशन की संख्या पर निर्भर करता है। सिस्टम 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 देखें):
    • (एंड्रॉइड 14 और उच्चतर) डिफ़ॉल्ट रूप से speed-profile कंपाइलर फ़िल्टर के साथ संकलित, या यदि प्रोफ़ाइल प्रदान नहीं की गई है तो speed कंपाइलर फ़िल्टर के साथ संकलित।
    • (एंड्रॉइड 13 और उससे कम) डिफ़ॉल्ट रूप से speed कंपाइलर फ़िल्टर के साथ संकलित।
    PRODUCT_SYSTEM_SERVER_COMPILER_FILTER के माध्यम से कॉन्फ़िगर करने योग्य (इस दस्तावेज़ में बाद में देखें)।
  • उत्पाद-विशिष्ट कोर ऐप्स (इस दस्तावेज़ में बाद में PRODUCT_DEXPREOPT_SPEED_APPS देखें): डिफ़ॉल्ट रूप से speed कंपाइलर फ़िल्टर के साथ संकलित।
  • अन्य सभी ऐप्स: डिफ़ॉल्ट रूप से speed-profile कंपाइलर फ़िल्टर के साथ संकलित, या यदि प्रोफ़ाइल प्रदान नहीं की गई है तो verify कंपाइलर फ़िल्टर के साथ संकलित।

    PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER के माध्यम से कॉन्फ़िगर करने योग्य (इस दस्तावेज़ में बाद में देखें)।

मेकफ़ाइल विकल्प

  • WITH_DEXPREOPT
  • क्या सिस्टम छवि पर स्थापित DEX कोड पर dex2oat लागू किया गया है। डिफ़ॉल्ट रूप से सक्षम.

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

  • PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER (एंड्रॉइड 9 और उच्चतर)
  • PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER डेक्सप्रोप्टेड अनुप्रयोगों के लिए डिफ़ॉल्ट कंपाइलर फ़िल्टर निर्दिष्ट करता है। ये ऐप्स Android.bp में परिभाषित हैं या उनके Android.mk में निर्दिष्ट include $(BUILD_PREBUILT) । यदि अनिर्दिष्ट है, तो डिफ़ॉल्ट मान speed-profile है, या verify कि क्या मान अनिर्दिष्ट है और कोई प्रोफ़ाइल प्रदान नहीं की गई है।

  • WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY (एंड्रॉइड 8 MR1 के बाद से)
  • WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY को सक्षम करने से केवल बूट क्लासपाथ और सिस्टम सर्वर जार को डेक्सप्रोऑप्ट किया जाता है।

  • LOCAL_DEX_PREOPT
  • मॉड्यूल परिभाषा में LOCAL_DEX_PREOPT विकल्प निर्दिष्ट करके डेक्सप्रॉप्ट को व्यक्तिगत ऐप के आधार पर भी सक्षम या अक्षम किया जा सकता है। यह उन ऐप्स के डेक्सप्रोऑप्ट को अक्षम करने के लिए उपयोगी हो सकता है जो तुरंत Google Play अपडेट प्राप्त कर सकते हैं क्योंकि अपडेट सिस्टम छवि में डेक्सप्रोप्टेड कोड को अप्रचलित बना देगा। यह प्रमुख संस्करण अपग्रेड ओटीए पर स्थान बचाने के लिए भी उपयोगी है क्योंकि उपयोगकर्ताओं के पास डेटा विभाजन में पहले से ही ऐप्स के नए संस्करण हो सकते हैं।

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

  • 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 और एपीके फ़ाइलों के लिए LOCAL_MODULE और LOCAL_PACKAGE नामों की एक सूची है। , क्रमश।

  • PRODUCT_DEXPREOPT_SPEED_APPS (एंड्रॉइड 8 से)
  • उन ऐप्स की सूची जिन्हें उत्पादों के मूल के रूप में पहचाना गया है और जिन्हें speed कंपाइलर फ़िल्टर के साथ संकलित करना वांछनीय है। उदाहरण के लिए, सिस्टमयूआई जैसे लगातार ऐप्स को केवल अगले रीबूट पर प्रोफ़ाइल-निर्देशित संकलन का उपयोग करने का मौका मिलता है, इसलिए उत्पाद के लिए इन ऐप्स को हमेशा एओटी-संकलित रखना बेहतर हो सकता है।

  • PRODUCT_SYSTEM_SERVER_APPS (एंड्रॉइड 8 के बाद से)
  • सिस्टम सर्वर द्वारा लोड किए गए ऐप्स की सूची। ये ऐप्स डिफ़ॉल्ट रूप से speed कंपाइलर फ़िल्टर के साथ संकलित होते हैं।

  • PRODUCT_ART_TARGET_INCLUDE_DEBUG_BUILD (एंड्रॉइड 8 के बाद से)
  • डिवाइस पर एआरटी का डिबग संस्करण शामिल करना है या नहीं। डिफ़ॉल्ट रूप से, यह userdebug और eng बिल्ड के लिए सक्षम है। विकल्प को स्पष्ट रूप से true या false पर सेट करके व्यवहार को ओवरराइड किया जा सकता है।

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

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

    एंड्रॉइड 7.0 में, PIC संकलन डिफ़ॉल्ट रूप से सक्षम किया गया था।

  • WITH_DEXPREOPT_BOOT_IMG_ONLY (एंड्रॉइड 7 MR1 तक)
  • इस विकल्प को WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY से बदल दिया गया था जो सिस्टम सर्वर JARs को भी प्रीऑप्ट करता है।

  • PRODUCT_SYSTEM_SERVER_COMPILER_FILTER
  • यह विकल्प सिस्टम सर्वर के लिए कंपाइलर फ़िल्टर निर्दिष्ट करता है।

    • (एंड्रॉइड 14 और उच्चतर) यदि निर्दिष्ट नहीं है, तो speed-profile कंपाइलर फ़िल्टर का उपयोग किया जाता है, या यदि प्रोफ़ाइल प्रदान नहीं की जाती है तो speed कंपाइलर फ़िल्टर का उपयोग किया जाता है।
    • (एंड्रॉइड 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 सिस्टम सर्वर क्लासपाथ JARs जोड़ना आवश्यक है। इस सूची में APEX सिस्टम सर्वर क्लासपाथ JAR को जोड़ने में विफल रहने के परिणामस्वरूप उन JAR को लोड नहीं किया जा रहा है।
    • (वैकल्पिक, Android 13 और इससे पहले का संस्करण) PRODUCT_STANDALONE_SYSTEM_SERVER_JARS : JAR की सूची जिसे सिस्टम सर्वर अलग-अलग क्लासलोडर्स ( SystemServiceManager.startServiceFromJar के माध्यम से) का उपयोग करके गतिशील रूप से लोड करता है। इस सूची में स्टैंडअलोन सिस्टम सर्वर JARs जोड़ना आवश्यक नहीं है, लेकिन दृढ़ता से अनुशंसित है क्योंकि यह JARs को संकलित करता है और इसलिए इसका रनटाइम प्रदर्शन अच्छा होता है।
    • (Android 13 के बाद से आवश्यक है) PRODUCT_APEX_STANDALONE_SYSTEM_SERVER_JARS : APEX के साथ वितरित JAR की सूची जिसे सिस्टम सर्वर अलग-अलग क्लासलोडर्स का उपयोग करके गतिशील रूप से लोड करता है (अर्थात, SystemServiceManager.startServiceFromJar के माध्यम से या <apex-system-service> के रूप में घोषित)। प्रारूप <apex name>:<jar name> है। इस सूची में स्टैंडअलोन APEX सिस्टम सर्वर JARs जोड़ना आवश्यक है। इस सूची में स्टैंडअलोन APEX सिस्टम सर्वर JARs जोड़ने में विफल होने पर बूट विफलता होती है।

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

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

    उदाहरण उपयोग (उत्पाद के device.mk में):

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

    नोट: आपको किसी भी उत्पाद कॉन्फ़िगरेशन मेकफ़ाइल को इनहेरिट करने से पहले इस लाइन को रखना होगा जो build/target/product/base.mk से डिफ़ॉल्ट प्राप्त करता है।

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

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

    निम्नलिखित विकल्प केवल एंड्रॉइड रिलीज़ को प्रभावित करते हैं जहां ART JIT कंपाइलर उपलब्ध है।

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

    Dex2oat विकल्प

    ये विकल्प ऑन-डिवाइस संकलन (उर्फ, डेक्सऑप्ट ) को प्रभावित करते हैं, और उनमें से कुछ डेक्सप्रॉप्ट को भी प्रभावित करते हैं, जबकि ऊपर सिस्टम रॉम कॉन्फ़िगरेशन अनुभाग में चर्चा किए गए विकल्प केवल डेक्सप्रॉप्ट को प्रभावित करते हैं।

    संसाधन उपयोग को नियंत्रित करने के विकल्प:

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

    सीपीयू कोर का एक सेट सीपीयू आईडी की अल्पविराम से अलग की गई सूची के रूप में निर्दिष्ट किया जाना चाहिए। उदाहरण के लिए, CPU कोर 0-3 पर dex2oat चलाने के लिए, सेट करें:

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

    सीपीयू एफ़िनिटी गुणों को सेट करते समय, हम अनावश्यक मेमोरी और I/O विवाद से बचने के लिए चयनित संख्या सीपीयू से मेल करने के लिए dex2oat थ्रेड्स की संख्या के लिए संबंधित संपत्ति से मिलान करने की सलाह देते हैं:

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

    उपरोक्त सिस्टम गुणों के अलावा, आप dex2oat के संसाधन उपयोग को नियंत्रित करने के लिए कार्य प्रोफाइल का भी उपयोग कर सकते हैं ( Cgroup Abstraction Layer देखें)।

    समर्थित कार्य प्रोफ़ाइल हैं:

    • Dex2OatBackground (एंड्रॉइड 14 के बाद से) (डिफ़ॉल्ट रूप से Dex2OatBootComplete विरासत में मिला है): पृष्ठभूमि में उपयोग करने के लिए संसाधनों को नियंत्रित करता है।
      • विशेष रूप से, यह ART सेवा में प्राथमिकता वर्ग PRIORITY_BACKGROUND से मेल खाता है।
    • Dex2OatBootComplete :
      • (एंड्रॉइड 13 तक) बूट के बाद हर चीज़ के लिए उपयोग किए जाने वाले संसाधन को नियंत्रित करता है।
      • (एंड्रॉइड 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 (एंड्रॉइड 11 तक): बूट छवियों के लिए कंपाइलर फ़िल्टर। एंड्रॉइड 12 के बाद से, बूट छवियों के लिए कंपाइलर फ़िल्टर हमेशा speed-profile है और इसे बदला नहीं जा सकता।
    • dalvik.vm.systemservercompilerfilter (Android 13 के बाद से): सिस्टम सर्वर के लिए कंपाइलर फ़िल्टर। PRODUCT_SYSTEM_SERVER_COMPILER_FILTER देखें।
    • dalvik.vm.systemuicompilerfilter (Android 13 के बाद से): सिस्टम UI पैकेज के लिए कंपाइलर फ़िल्टर।
    • dalvik.vm.dex2oat-filter (Android 6 तक): बाकी सभी चीज़ों के लिए कंपाइलर फ़िल्टर।
    • pm.dexopt.<reason> (Android 7 के बाद से): बाकी सभी चीज़ों के लिए कंपाइलर फ़िल्टर। Android 14 और उससे ऊपर के लिए ART सेवा कॉन्फ़िगरेशन , या Android 13 और उससे नीचे के लिए पैकेज प्रबंधक कॉन्फ़िगरेशन देखें।

    बूट छवियों के अलावा अन्य सभी चीज़ों के संकलन को नियंत्रित करने के लिए अन्य विकल्प:

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

    एआरटी सेवा विकल्प

    एंड्रॉइड 14 के बाद से, ऐप्स के लिए ऑन-डिवाइस एओटी संकलन (उर्फ डेक्सॉप्ट) को एआरटी सेवा द्वारा नियंत्रित किया जाता है। एआरटी सेवा को कॉन्फ़िगर करने के बारे में जानकारी के लिए, एआरटी सेवा कॉन्फ़िगरेशन देखें।

    पैकेज प्रबंधक विकल्प

    एंड्रॉइड 14 से पहले, ऐप्स के लिए ऑन-डिवाइस एओटी संकलन (उर्फ डेक्सॉप्ट) को पैकेज मैनेजर द्वारा नियंत्रित किया जाता है। डेक्सॉप्ट के लिए पैकेज मैनेजर को कॉन्फ़िगर करने के बारे में जानकारी के लिए, पैकेज मैनेजर कॉन्फ़िगरेशन देखें।

    ए/बी विशिष्ट विन्यास

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

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

    उदाहरण उपयोग ( 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/%
    

    पृष्ठभूमि ओटीए डेक्सॉप्ट

    ए/बी सक्षम उपकरणों पर, एप्लिकेशन को नई सिस्टम छवि के साथ रीबूट से पहले पृष्ठभूमि में संकलित किया जा सकता है। सिस्टम छवि में संकलन स्क्रिप्ट और बायनेरिज़ को वैकल्पिक रूप से शामिल करने के लिए पृष्ठभूमि में ऐप संकलन देखें। इस संकलन के लिए प्रयुक्त संकलन फ़िल्टर को इसके द्वारा नियंत्रित किया जाता है:

    pm.dexopt.ab-ota=speed-profile
    

    हम प्रोफ़ाइल निर्देशित संकलन का लाभ उठाने और भंडारण पर बचत करने के लिए speed-profile उपयोग करने की सलाह देते हैं।

    जेडीडब्ल्यूपी विकल्प

    यूजरडीबग बिल्ड में जावा डिबग वायर प्रोटोकॉल (जेडीडब्ल्यूपी) थ्रेड निर्माण को persist.debug.dalvik.vm.jdwp.enabled सिस्टम प्रॉपर्टी के माध्यम से नियंत्रित किया जाता है। डिफ़ॉल्ट रूप से, यह प्रॉपर्टी सेट नहीं है और JDWP थ्रेड केवल डिबग करने योग्य ऐप्स के लिए बनाए जाते हैं। डिबग करने योग्य और नॉन-डिबग करने योग्य दोनों ऐप्स के लिए JDWP थ्रेड्स को सक्षम करने के लिए, persist.debug.dalvik.vm.jdwp.enabled को 1 पर सेट करें। प्रॉपर्टी में परिवर्तन प्रभावी करने के लिए डिवाइस को रीबूट करना होगा।

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

      adb shell setprop persist.debug.dalvik.vm.jdwp.enabled 1
      adb reboot
      
    एंड्रॉइड 13 और उससे पहले के संस्करण चलाने वाले उपकरणों के लिए, रनटाइम यूजरडीबग बिल्ड पर डिबग करने योग्य और नॉन-डिबग करने योग्य ऐप्स के लिए जेडीडब्ल्यूपी थ्रेड बनाता है। इसका मतलब यह है कि यूजरडिबग बिल्ड पर डिबगर संलग्न करना या किसी भी ऐप को प्रोफाइल करना संभव है।