ART را پیکربندی کنید

در این صفحه نحوه پیکربندی زمان اجرا اندروید (ART) و گزینه های کامپایل آن بحث می شود. موضوعاتی که در اینجا به آنها پرداخته می شود شامل پیکربندی پیش کامپایل تصویر سیستم، گزینه های کامپایل dex2oat ، و نحوه مبادله فضای پارتیشن سیستم، فضای پارتیشن داده و عملکرد است.

برای کار با ART به ART و Dalvik و فرمت اجرایی Dalvik مراجعه کنید. برای اطمینان از اینکه برنامه‌هایتان به درستی کار می‌کنند ، به تأیید رفتار برنامه در زمان اجرای Android (ART) مراجعه کنید.

هنر چگونه کار می کند

ART از کامپایل پیش از زمان (AOT) استفاده می کند و با شروع در اندروید 7، از ترکیب ترکیبی کامپایل AOT، کامپایل به موقع (JIT) و تفسیر استفاده می کند و کامپایل AOT را می توان با نمایه هدایت کرد. ترکیب همه این حالت های اجرا قابل تنظیم است و در این قسمت مورد بحث قرار خواهد گرفت. به عنوان مثال، دستگاه‌های Pixel برای کار در جریان زیر پیکربندی شده‌اند:

  1. یک برنامه در ابتدا با یک فایل فراداده dex ( .dm ) توزیع شده توسط Play Store نصب می شود که حاوی نمایه ابری است. ART AOT-روش های فهرست شده در نمایه ابری را کامپایل می کند. یا اگر برنامه بدون فایل فراداده dex نصب شده باشد، هیچ کامپایل AOT انجام نمی شود.
  2. چند بار اول که برنامه اجرا می شود، روش هایی که AOT-کامپایل نشده اند تفسیر می شوند. در میان روش‌های تفسیر شده، آنهایی که اغلب اجرا می‌شوند، سپس با JIT کامپایل می‌شوند. ART یک نمایه محلی را بر اساس اجرا ایجاد می کند و آن را با نمایه ابری (در صورت وجود) ترکیب می کند.
  3. هنگامی که دستگاه بیکار است و در حال شارژ است، یک شبح کامپایل برای کامپایل مجدد برنامه بر اساس نمایه ترکیبی تولید شده در چند اجرا اول اجرا می شود.
  4. در اجراهای بعدی برنامه، ART از مصنوعات تولید شده توسط دیمون کامپایل استفاده می‌کند که حاوی کدهای کامپایل‌شده AOT بیشتری است، در مقایسه با مواردی که در طول روش‌هایی که با AOT کامپایل نشده‌اند، هنوز تفسیر یا کامپایل شده‌اند. ART نصب نمایه را بر اساس اجرا به روز می کند و سپس نمایه توسط اجراهای بعدی دیمون کامپایل انتخاب می شود.

ART شامل یک کامپایلر (ابزار dex2oat ) و یک زمان اجرا ( libart.so ) است که در هنگام بوت بارگذاری می شود. ابزار dex2oat یک فایل APK را می گیرد و یک یا چند فایل مصنوع کامپایل را تولید می کند که زمان اجرا بارگیری می شود. تعداد فایل‌ها، پسوندها و نام‌های آن‌ها در نسخه‌های مختلف در معرض تغییر هستند، اما از زمان انتشار Android 8، این فایل‌ها تولید می‌شوند:

  • .vdex .: حاوی برخی فراداده اضافی برای سرعت بخشیدن به تأیید، گاهی اوقات همراه با کد DEX فشرده نشده APK است.
  • .odex : حاوی کدهای کامپایل شده توسط AOT برای متدها در APK است.
  • .art (optional) حاوی نمایش های داخلی ART از برخی رشته ها و کلاس های فهرست شده در APK است که برای سرعت بخشیدن به راه اندازی برنامه استفاده می شود.

گزینه های تالیف

دو دسته از گزینه های کامپایل برای ART وجود دارد:

  1. پیکربندی رام سیستم: در هنگام ساخت تصویر سیستم، AOT چه کدی کامپایل می‌شود.
  2. پیکربندی زمان اجرا: چگونه ART برنامه ها را روی یک دستگاه کامپایل و اجرا می کند.

فیلترهای کامپایلر

یکی از گزینه های اصلی ART برای پیکربندی این دو دسته، فیلترهای کامپایلر است. فیلترهای کامپایلر نحوه کامپایل کد DEX را هدایت می کنند و گزینه ای است که به ابزار dex2oat منتقل می شود. با شروع اندروید 8، چهار فیلتر به طور رسمی پشتیبانی می شوند:

  • verify : فقط تأیید کد DEX را اجرا می کند (بدون کامپایل AOT).
  • quicken : (اندروید 11 یا پایین تر) تأیید کد DEX را اجرا می کند و برخی دستورالعمل های DEX را بهینه می کند تا عملکرد مترجم بهتری داشته باشد.
  • speed : تأیید کد DEX را اجرا می کند و AOT همه روش ها را کامپایل می کند. کلاس ها را از قبل اولیه نمی کند.
  • speed-profile : تأیید کد DEX را اجرا می‌کند، AOT روش‌های فهرست‌شده در نمایه را کامپایل می‌کند، و کلاس‌های فهرست‌شده در پروفایل را که فاقد مقداردهی اولیه استاتیک هستند، از قبل اولیه می‌کند.

پیکربندی رام سیستم

کتابخانه ها و برنامه های از پیش نصب شده زمانی که یک تصویر سیستم ساخته می شود AOT-کامپایل می شوند. این فرآیند dexpreopt نامیده می شود. چنین فایل های کامپایل شده تا زمانی که همه وابستگی ها بدون تغییر باقی می مانند، قابل استفاده هستند، به ویژه مسیر کلاس بوت.

توجه: اگر دستگاه به‌روزرسانی‌های ماژول سیستم را دریافت کند، احتمالاً مسیر کلاس راه‌اندازی در به‌روزرسانی بعدی تغییر می‌کند، که همه فایل‌های dexpreopt را کهنه و غیرقابل استفاده می‌کند.

تعدادی گزینه ساخت ART برای پیکربندی dexpreopt موجود است. نحوه پیکربندی این گزینه ها به فضای ذخیره سازی موجود برای تصویر سیستم و تعداد برنامه های از پیش نصب شده بستگی دارد. JAR ها/APK هایی که در یک ROM سیستم کامپایل می شوند را می توان به چهار دسته تقسیم کرد:

  • کد مسیر کلاس راه‌اندازی: به‌طور پیش‌فرض با فیلتر کامپایلر 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 (در ادامه این سند ببینید).

گزینه های Makefile

  • WITH_DEXPREOPT

    • آیا dex2oat در کد DEX نصب شده روی تصویر سیستم فراخوانی شده است یا خیر. به طور پیش فرض فعال است.

  • DONT_DEXPREOPT_PREBUILTS (اندروید 5 و بالاتر)

    • فعال کردن DONT_DEXPREOPT_PREBUILTS از بازگشایی پیش ساخته ها جلوگیری می کند. اینها برنامه هایی هستند که include $(BUILD_PREBUILT) در Android.mk آنها مشخص شده است. پرش از dexpreopt از برنامه‌های از پیش ساخته‌شده که احتمالاً از طریق Google Play به‌روزرسانی می‌شوند، باعث صرفه‌جویی در فضا در تصویر سیستم می‌شود اما به زمان اولین راه‌اندازی اضافه می‌کند. توجه داشته باشید که این گزینه روی برنامه های از پیش ساخته شده در Android.bp تاثیری ندارد.

  • PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER (اندروید 9 و بالاتر)

    • PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER فیلتر کامپایلر پیش فرض را برای برنامه های کاربردی dexpreopted مشخص می کند. این برنامه‌ها در Android.bp تعریف شده‌اند یا include $(BUILD_PREBUILT) هستند که در Android.mk آنها مشخص شده است. اگر مشخص نیست، مقدار پیش‌فرض speed-profile است، یا verify که آیا مقدار مشخص نشده است و نمایه‌ای ارائه نشده است.

  • WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY (از Android 8 MR1)

    • فعال کردن WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY فقط مسیر کلاس راه‌اندازی و شیشه‌های سرور سیستم را حذف می‌کند.

  • LOCAL_DEX_PREOPT

    • همچنین می‌توان Dexpreopt را بر اساس برنامه جداگانه با تعیین گزینه LOCAL_DEX_PREOPT در تعریف ماژول فعال یا غیرفعال کرد. این می‌تواند برای غیرفعال کردن dexpreopt برنامه‌هایی که ممکن است فوراً به‌روزرسانی‌های Google Play را دریافت کنند مفید باشد، زیرا به‌روزرسانی‌ها باعث منسوخ شدن کد dexpreopt در تصویر سیستم می‌شوند. این همچنین برای صرفه جویی در فضا در OTA های ارتقاء نسخه اصلی مفید است زیرا ممکن است کاربران از قبل نسخه های جدیدتری از برنامه ها را در پارتیشن داده داشته باشند.

    LOCAL_DEX_PREOPT از مقادیر true یا false به ترتیب برای فعال یا غیرفعال کردن dexpreopt پشتیبانی می کند. علاوه بر این، در صورتی که dexpreopt نباید فایل classes.dex را از فایل APK یا JAR حذف کند، می‌توان nostripping مشخص کرد. معمولاً این فایل حذف می‌شود زیرا دیگر پس از 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> لیستی از نام‌های LOCAL_MODULE و LOCAL_PACKAGE برای فایل‌های JAR و APK است. به ترتیب

  • PRODUCT_DEXPREOPT_SPEED_APPS (از Android 8)

    • فهرست برنامه‌هایی که به‌عنوان هسته اصلی محصولات شناسایی شده‌اند و می‌خواهند با فیلتر کامپایلر speed کامپایل شوند. به عنوان مثال، برنامه‌های دائمی مانند SystemUI فقط در راه‌اندازی مجدد بعدی فرصت استفاده از کامپایل هدایت‌شده نمایه را دارند، بنابراین شاید بهتر باشد که محصول همیشه این برنامه‌ها را با AOT کامپایل کند.

  • 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 می توان برای فعال کردن کد مستقل از موقعیت (PIC) مشخص کرد. با این کار، کد کامپایل شده از تصویر نیازی به جابجایی از /system به /data/dalvik-cache ندارد و باعث صرفه جویی در فضا در پارتیشن داده می شود. با این حال، تأثیر کمی در زمان اجرا وجود دارد زیرا بهینه سازی را غیرفعال می کند که از کد وابسته به موقعیت استفاده می کند. به طور معمول، دستگاه‌هایی که می‌خواهند فضا را در /data ذخیره کنند، باید کامپایل PIC را فعال کنند.

    در اندروید 7.0، کامپایل PIC به طور پیش فرض فعال بود.

  • WITH_DEXPREOPT_BOOT_IMG_ONLY (تا Android 7 MR1)

    • این گزینه با WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY جایگزین شد که JAR های سرور سیستم را نیز از قبل انتخاب می کند.

  • 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 : فهرستی از JARهای مسیر کلاس سرور سیستم در پلتفرم (یعنی به عنوان بخشی از SYSTEMSERVERCLASSPATH ). افزودن کلاس مسیر سرور سیستم به این لیست الزامی است. عدم اضافه کردن JAR های کلاس مسیر سرور سیستم به لیست باعث می شود آن JAR ها بارگیری نشوند.
    • (الزامی) PRODUCT_APEX_SYSTEM_SERVER_JARS : فهرستی از JARهای مسیر کلاس سرور سیستم که با APEX (یعنی به عنوان بخشی از SYSTEMSERVERCLASSPATH ) تحویل داده شده است. قالب <apex name>:<jar name> است. افزودن JARهای کلاس مسیر سرور سیستم APEX به این لیست الزامی است. عدم اضافه کردن JARهای کلاس مسیر سرور سیستم APEX به این لیست منجر به بار نشدن آن JARها می شود.
    • (اختیاری، Android 13 و پایین‌تر) PRODUCT_STANDALONE_SYSTEM_SERVER_JARS : فهرست JAR‌هایی که سرور سیستم با استفاده از کلاس‌لودرهای جداگانه (از طریق SystemServiceManager.startServiceFromJar ) به صورت پویا بارگیری می‌کند. افزودن JARهای سرور سیستم مستقل به این لیست الزامی نیست، اما به شدت توصیه می شود زیرا باعث می شود JAR ها کامپایل شوند و بنابراین عملکرد خوبی در زمان اجرا دارند.
    • (الزامی است، از Android 13) PRODUCT_APEX_STANDALONE_SYSTEM_SERVER_JARS : فهرست JAR های ارائه شده با APEX که سرور سیستم به صورت پویا با استفاده از کلاس لودرهای جداگانه بارگیری می شود (یعنی از طریق SystemServiceManager.startServiceFromJar یا به عنوان <apex-system-service> اعلام شده است). قالب <apex name>:<jar name> است. افزودن JARهای سرور سیستم APEX مستقل به این لیست الزامی است. عدم افزودن JARهای سرور سیستم APEX مستقل به این لیست منجر به خرابی بوت می شود.

    تنظیمات مسیر کلاس را بوت کنید

    فهرست کلاس‌های از پیش بارگذاری شده فهرستی از کلاس‌هایی است که Zygote هنگام راه‌اندازی مقداردهی اولیه می‌کند. این امر باعث می‌شود هر برنامه از اجرای جداگانه این اولیه سازهای کلاس جلوگیری کند و به آنها امکان می‌دهد سریع‌تر راه‌اندازی شوند و صفحات را در حافظه به اشتراک بگذارند. فایل فهرست کلاس‌های از پیش بارگذاری‌شده به‌طور پیش‌فرض در frameworks/base/config/preloaded-classes قرار دارد و حاوی فهرستی است که برای استفاده معمولی از تلفن تنظیم شده است. این ممکن است برای دستگاه های دیگر مانند پوشیدنی ها متفاوت باشد و باید بر اساس آن تنظیم شود. هنگام تنظیم این مورد مراقب باشید؛ وقتی کلاس های استفاده نشده بارگذاری می شوند، اضافه کردن تعداد زیاد کلاس باعث هدر رفتن حافظه می شود. اضافه کردن کلاس‌های بسیار کم، هر برنامه را مجبور می‌کند کپی مخصوص به خود را داشته باشد، که دوباره باعث هدر رفتن حافظه می‌شود.

    مثال استفاده (در product's device.mk ):

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

    توجه: قبل از به ارث بردن هر گونه فایل پیکربندی محصول که فایل پیش فرض را از build/target/product/base.mk دریافت می کند، باید این خط را قرار دهید.

    پیکربندی زمان اجرا

    گزینه های JIT

    گزینه‌های زیر بر نسخه‌های Android فقط در جایی تأثیر می‌گذارند که کامپایلر ART JIT در دسترس است.

    • dalvik.vm.usejit : فعال بودن یا نبودن JIT.
    • dalvik.vm.jitinitialsize (پیش فرض 64K): ظرفیت اولیه حافظه پنهان کد. حافظه پنهان کد به طور مرتب GC می شود و در صورت نیاز افزایش می یابد.
    • dalvik.vm.jitmaxsize (پیش فرض 64M): حداکثر ظرفیت حافظه پنهان کد.
    • dalvik.vm.jitthreshold (پیش‌فرض 10000): آستانه‌ای که شمارنده «hotness» یک متد باید از آن عبور کند تا متد به‌صورت JIT کامپایل شود. شمارنده "hotness" یک متریک داخلی برای زمان اجرا است. این شامل تعداد تماس ها، شاخه های عقب افتاده و سایر عوامل است.
    • dalvik.vm.usejitprofiles (تا اندروید 13): اینکه آیا پروفایل های JIT فعال هستند یا نه. این ممکن است استفاده شود حتی اگر dalvik.vm.usejit نادرست باشد. توجه داشته باشید که اگر این نادرست باشد، speed-profile فیلتر کامپایلر هیچ روشی را AOT-کامپایل نمی‌کند و معادل verify است. از اندروید 14، پروفایل های JIT همیشه فعال هستند و نمی توان آنها را خاموش کرد.
    • dalvik.vm.jitprithreadweight (پیش‌فرض dalvik.vm.jitthreshold / 20): وزن «نمونه‌های» JIT (به jitthreshold مراجعه کنید) برای رشته رابط کاربری برنامه. برای تسریع در جمع‌آوری روش‌هایی که مستقیماً بر تجربه کاربران در تعامل با برنامه تأثیر می‌گذارند، استفاده کنید.
    • dalvik.vm.jittransitionweight (پیش‌فرض به dalvik.vm.jitthreshold / 10): وزن فراخوانی متد که بین کد کامپایل و مفسر منتقل می‌شود. این کمک می کند تا مطمئن شوید که روش های درگیر برای به حداقل رساندن انتقال ها (که گران هستند) کامپایل شده اند.

    گزینه های Dex2oat

    این گزینه‌ها بر کامپایل روی دستگاه (معروف به dexopt ) تأثیر می‌گذارند، و تعداد کمی از آن‌ها بر dexpreopt نیز تأثیر می‌گذارند، در حالی که گزینه‌هایی که در بخش پیکربندی ROM سیستم در بالا بحث شد، فقط بر dexpreopt تأثیر می‌گذارند.

    گزینه های کنترل استفاده از منابع:

    • dalvik.vm.image-dex2oat-threads / dalvik.vm.image-dex2oat-cpu-set (تا اندروید 11): تعداد رشته ها و مجموعه هسته های CPU (به زیر مراجعه کنید) که برای تصاویر بوت استفاده می شود.
    • dalvik.vm.boot-dex2oat-threads / dalvik.vm.boot-dex2oat-cpu-set :
      • (تا اندروید 11) تعداد رشته‌ها و مجموعه هسته‌های CPU (به زیر مراجعه کنید) برای استفاده در طول زمان راه‌اندازی برای هر چیزی غیر از تصاویر بوت.
      • (از اندروید 12) تعداد رشته ها و مجموعه هسته های CPU (به زیر مراجعه کنید) برای استفاده در طول زمان بوت برای همه چیز، از جمله تصاویر بوت.
        • به طور خاص، از Android 14، این با کلاس اولویت PRIORITY_BOOT در سرویس ART مطابقت دارد.
    • dalvik.vm.restore-dex2oat-threads / dalvik.vm.restore-dex2oat-cpu-set :
      • (از اندروید 11 تا اندروید 13) تعداد رشته‌ها و مجموعه هسته‌های CPU (به زیر مراجعه کنید) که برای بازیابی از پشتیبان‌گیری ابری استفاده می‌شود.
      • (از اندروید 14) تعداد رشته‌ها و مجموعه هسته‌های CPU (به زیر مراجعه کنید) برای استفاده برای هر چیزی که نسبت به حالت عادی به تأخیر حساس‌تر است، از جمله بازیابی از پشتیبان‌گیری ابری.
        • به طور خاص، این مربوط به کلاس اولویت PRIORITY_INTERACTIVE_FAST در سرویس ART است.
    • dalvik.vm.background-dex2oat-threads / dalvik.vm.background-dex2oat-cpu-set (از اندروید 14): تعداد رشته ها و مجموعه هسته های CPU (به زیر مراجعه کنید) برای استفاده در پس زمینه.
      • به طور خاص، این مربوط به کلاس اولویت PRIORITY_BACKGROUND در سرویس ART است.
    • dalvik.vm.dex2oat-threads / dalvik.vm.dex2oat-cpu-set : تعداد رشته‌ها و مجموعه هسته‌های CPU برای استفاده برای هر چیز دیگری.

    مجموعه ای از هسته های CPU باید به عنوان لیست شناسه های CPU جدا شده با کاما مشخص شوند. به عنوان مثال برای اجرا بر روی dex2oat در هسته های CPU 0-3، تنظیم کنید:

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

    هنگام تنظیم ویژگی های CPU affinity، توصیه می کنیم ویژگی مربوطه را برای تعداد رشته های dex2oat مطابقت دهید تا با تعداد CPU های انتخاب شده مطابقت داشته باشد تا از اختلاف حافظه غیر ضروری و I/O جلوگیری شود:

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

    علاوه بر ویژگی‌های سیستم بالا، می‌توانید از پروفایل‌های وظیفه نیز برای کنترل استفاده از منابع dex2oat استفاده کنید (به لایه Cgroup Abstraction مراجعه کنید).

    پروفایل های وظیفه پشتیبانی شده عبارتند از:

    • Dex2OatBackground (از اندروید 14) (به طور پیش فرض Dex2OatBootComplete را به ارث می برد): منابع را برای استفاده در پس زمینه کنترل می کند.
      • به طور خاص، این مربوط به کلاس اولویت PRIORITY_BACKGROUND در سرویس ART است.
    • Dex2OatBootComplete :
      • (تا اندروید 13) منبعی را برای استفاده برای همه چیز پس از بوت کردن کنترل می کند.
      • (از اندروید 14) منبع را کنترل می کند تا برای همه چیز پس از راه اندازی و نه در پس زمینه استفاده شود.
        • به طور خاص، این مربوط به کلاس اولویت PRIORITY_INTERACTIVE_FAST و PRIORITY_INTERACTIVE در سرویس ART است.

    هنگامی که هم ویژگی های سیستم و هم پروفایل وظایف مشخص می شوند، هر دو اثر می گذارند.

    گزینه های کنترل اندازه پشته:

    • 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 (از اندروید 13): فیلتر کامپایلر برای سرور سیستم. PRODUCT_SYSTEM_SERVER_COMPILER_FILTER را ببینید.
    • dalvik.vm.systemuicompilerfilter (از اندروید 13): فیلتر کامپایلر برای بسته System UI.
    • dalvik.vm.dex2oat-filter (تا اندروید 6): فیلتر کامپایلر برای هر چیز دیگری.
    • pm.dexopt.<reason> (از اندروید 7): فیلتر کامپایلر برای هر چیز دیگری. به پیکربندی سرویس ART برای Android نسخه 14 و بالاتر یا پیکربندی مدیریت بسته برای Android نسخه 13 و پایین‌تر مراجعه کنید.

    گزینه های دیگر برای کنترل کامپایل کردن همه چیز به جز تصاویر بوت:

    • dalvik.vm.dex2oat-very-large (از اندروید 7.1): حداقل حجم کل فایل dex به بایت برای غیرفعال کردن کامپایل AOT.
    • dalvik.vm.dex2oat-swap (از اندروید 7.1) (پیش‌فرض: true): امکان استفاده از فایل swap برای dex2oat. این می تواند به جلوگیری از خرابی های خارج از حافظه کمک کند. توجه داشته باشید که حتی در صورت فعال بودن این گزینه، dex2oat فقط تحت شرایط خاصی از فایل swap استفاده می کند، مثلاً زمانی که تعداد فایل های dex زیاد است و شرایط در حال تغییر است.
    • dalvik.vm.ps-min-first-save-ms (از اندروید 12): حداقل زمان انتظار قبل از تولید نمایه برنامه در زمان اجرا، اولین باری که برنامه راه اندازی می شود.
    • dalvik.vm.ps-min-save-period-ms (از اندروید 12): حداقل زمان انتظار قبل از به‌روزرسانی نمایه برنامه.
    • dalvik.vm.dex2oat64.enabled (از اندروید 11) (پیش‌فرض: false): آیا از نسخه 64 بیتی dex2oat استفاده شود یا خیر.
    • dalvik.vm.bgdexopt.new-classes-percent (از Android 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 تمام رشته‌های const را که از روش‌هایی که در نمایه به‌عنوان «راه‌اندازی» علامت‌گذاری شده‌اند، ارجاع دهد، حل کند.
    • debug.generate-debug-info (پیش‌فرض: نادرست) اینکه آیا اطلاعات اشکال‌زدایی برای اشکال‌زدایی بومی تولید شود یا نه، مانند اطلاعات باز کردن پشته، نمادهای ELF و بخش‌های کوتوله.
    • dalvik.vm.dex2oat-minidebuginfo (از Android 9) (پیش‌فرض: درست) اینکه آیا حداقل اطلاعات اشکال‌زدایی فشرده‌شده با LZMA برای چاپ پس‌ترک‌ها تولید شود یا نه.

    گزینه های خدمات ART

    از Android 14، کامپایل AOT روی دستگاه برای برنامه‌ها (معروف به dexopt) توسط ART Service مدیریت می‌شود. برای اطلاعات در مورد پیکربندی سرویس ART، به پیکربندی سرویس ART مراجعه کنید.

    گزینه های مدیریت بسته

    قبل از Android 14، کامپایل AOT روی دستگاه برای برنامه ها (معروف به dexopt) توسط مدیر بسته انجام می شد. برای اطلاعات در مورد پیکربندی مدیر بسته برای dexopt، به پیکربندی مدیر بسته مراجعه کنید.

    پیکربندی خاص A/B

    پیکربندی رام

    از 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/%

    پس زمینه OTA dexopt

    در دستگاه‌های دارای A/B، برنامه‌ها را می‌توان در پس‌زمینه قبل از راه‌اندازی مجدد با تصویر سیستم جدید کامپایل کرد. برای گنجاندن اختیاری اسکریپت کامپایل و فایل های باینری در تصویر سیستم، کامپایل برنامه را در پس زمینه ببینید. فیلتر کامپایل مورد استفاده برای این کامپایل با موارد زیر کنترل می شود:

    pm.dexopt.ab-ota=speed-profile

    توصیه می‌کنیم از speed-profile برای بهره‌مندی از کامپایل هدایت‌شده پروفایل و صرفه‌جویی در ذخیره‌سازی استفاده کنید.

    گزینه های JDWP

    ایجاد رشته پروتکل اشکال زدایی جاوا (JDWP) در ساخت های userdebug از طریق ویژگی سیستم 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
    برای دستگاه‌هایی که اندروید 13 و پایین‌تر دارند، زمان اجرا رشته‌های JDWP را برای برنامه‌های اشکال‌زدایی و غیراشکال‌زدایی در ساخت‌های کاربر اشکال‌زدایی ایجاد می‌کند. این به این معنی است که می‌توان یک اشکال‌زدا یا نمایه هر برنامه‌ای را در ساخت‌های userdebug پیوست کرد.