پیکربندی ART

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

برای کار با ART به ART و Dalvik ، قالب اجرایی Dalvik و صفحات باقیمانده در source.android.com مراجعه کنید. برای اطمینان از اینکه برنامه‌هایتان به درستی کار می‌کنند، به تأیید رفتار برنامه در زمان اجرای Android (ART) مراجعه کنید.

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

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

  1. یک برنامه در ابتدا بدون کامپایل AOT نصب می شود. چند بار اول که برنامه اجرا می شود، تفسیر می شود و روش هایی که اغلب اجرا می شوند JIT کامپایل می شوند.
  2. هنگامی که دستگاه بیکار است و در حال شارژ است، یک شبح کامپایل برای کامپایل کدهای پرکاربرد AOT بر اساس نمایه تولید شده در اولین اجراها اجرا می شود.
  3. راه اندازی مجدد بعدی یک برنامه از کد هدایت شده توسط پروفایل استفاده می کند و از انجام کامپایل JIT در زمان اجرا برای روش هایی که قبلاً کامپایل شده اند، اجتناب کنید. متدهایی که در طول اجراهای جدید توسط JIT کامپایل می‌شوند به نمایه اضافه می‌شوند، که سپس توسط دیمون کامپایل انتخاب می‌شوند.

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

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

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

گزینه های تلفیقی برای ART دو دسته هستند:

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

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

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

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

تعدادی گزینه ساخت ART برای پیکربندی ROM سیستم موجود است. نحوه پیکربندی این گزینه ها به فضای ذخیره سازی موجود برای تصویر سیستم و تعداد برنامه های از پیش نصب شده بستگی دارد. 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 در ادامه این سند مراجعه کنید):
    • (از Android 14 (AOSP آزمایشی)) به طور پیش‌فرض با فیلتر کامپایلر 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 (از Android 5)

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

  • PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER (از Android 9)

    • PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER فیلتر کامپایلر پیش‌فرض را برای برنامه‌های از پیش بهینه‌سازی شده مشخص می‌کند. این برنامه‌ها در 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

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

    LOCAL_DEX_PREOPT از مقادیر "درست" یا "نادرست" به ترتیب برای فعال یا غیرفعال کردن بهینه سازی اولیه پشتیبانی می کند. علاوه بر این، اگر پیش بهینه‌سازی نباید فایل classes.dex را از فایل APK یا JAR حذف کند، می‌توان «nostripping» را مشخص کرد. معمولاً این فایل حذف می‌شود، زیرا دیگر پس از بهینه‌سازی از قبل نیازی به آن نیست، اما آخرین گزینه برای اجازه دادن به امضاهای 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 (New in Android 8)

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

  • PRODUCT_SYSTEM_SERVER_APPS (New in Android 8)

    • لیست برنامه هایی که توسط سرور سیستم بارگیری می شوند. این برنامه ها به طور پیش فرض با فیلتر کامپایلر speed کامپایل می شوند.

  • PRODUCT_ART_TARGET_INCLUDE_DEBUG_BUILD(Post Android 8)

    • آیا باید نسخه اشکال زدایی ART در دستگاه اضافه شود. به‌طور پیش‌فرض، این برای userdebug و ساخت‌های eng فعال است. این رفتار را می توان با تنظیم صریح گزینه روی true یا false لغو کرد.

    به‌طور پیش‌فرض، دستگاه از نسخه بدون اشکال‌زدایی ( libart.so ) استفاده می‌کند. برای تغییر، ویژگی سیستم persist.sys.dalvik.vm.lib.2 را روی libartd.so قرار دهید.

  • WITH_DEXPREOPT_PIC (Removed in Android 8)

    • در Android 5.1.0 تا Android 6.0.1، WITH_DEXPREOPT_PIC را می توان برای فعال کردن کد مستقل از موقعیت (PIC) مشخص کرد. با این کار، کد کامپایل شده از تصویر نیازی به جابجایی از سیستم / به /data/dalvik-cache ندارد و باعث صرفه جویی در فضا در پارتیشن داده می شود. با این حال، تأثیر کمی در زمان اجرا وجود دارد زیرا بهینه سازی را غیرفعال می کند که از کد وابسته به موقعیت استفاده می کند. به طور معمول، دستگاه‌هایی که می‌خواهند فضا را در /data ذخیره کنند، باید کامپایل PIC را فعال کنند.

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

  • WITH_DEXPREOPT_BOOT_IMG_ONLY (در Android 8 MR1 حذف شد)

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

  • PRODUCT_SYSTEM_SERVER_COMPILER_FILTER

    • این گزینه فیلتر کامپایلر را برای سرور سیستم مشخص می کند.

    • (از Android 14 (AOSP آزمایشی)) اگر مشخص نشده باشد، از فیلتر کامپایلر 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 هایی که توسط سرور سیستم بارگیری می شوند آورده شده است. شیشه ها با فیلتر کامپایلر مشخص شده توسط PRODUCT_SYSTEM_SERVER_COMPILER_FILTER کامپایل می شوند.

    • (الزامی) PRODUCT_SYSTEM_SERVER_JARS : فهرستی از jars های مسیر کلاس سرور سیستم در پلتفرم (یعنی به عنوان بخشی از SYSTEMSERVERCLASSPATH ). افزودن jars classpath سرور سیستم به این لیست الزامی است. عدم اضافه کردن شیشه های مسیر کلاس سرور سیستم به لیست باعث می شود آن شیشه ها بارگیری نشوند.
    • (الزامی) PRODUCT_APEX_SYSTEM_SERVER_JARS : فهرستی از jars های مسیر کلاس سرور سیستم که از طریق apex (یعنی به عنوان بخشی از SYSTEMSERVERCLASSPATH ) تحویل داده شده است. قالب <apex name>:<jar name> است. افزودن jars classpath سرور سیستم apex به این لیست الزامی است. عدم اضافه کردن jars classpath سرور سیستم apex به این لیست باعث می شود که آن شیشه ها بارگیری نشوند.
    • (اختیاری، از Android 13) PRODUCT_STANDALONE_SYSTEM_SERVER_JARS : فهرستی از شیشه هایی که سرور سیستم به صورت پویا با استفاده از کلاس لودرهای جداگانه بارگیری می کند (از طریق SystemServiceManager.startServiceFromJar ). افزودن jars سرور سیستم مستقل به این لیست الزامی نیست، اما اکیداً توصیه می شود زیرا باعث می شود که jar ها کامپایل شوند و بنابراین عملکرد خوبی در زمان اجرا دارند.
    • (الزامی است، از Android 13) PRODUCT_APEX_STANDALONE_SYSTEM_SERVER_JARS : فهرستی از jar های تحویل داده شده از طریق apex که سرور سیستم به صورت پویا با استفاده از کلاس لودرهای جداگانه بارگیری می کند (یعنی از طریق SystemServiceManager.startServiceFromJar یا به عنوان <apex-system-service> اعلام شده است). قالب <apex name>:<jar name> است. افزودن شیشه های سرور سیستم apex مستقل به این لیست الزامی است. عدم افزودن شیشه های سرور سیستم apex مستقل به این لیست منجر به خرابی بوت می شود.

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

    • لیست کلاس های از پیش بارگذاری شده

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

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

    از اندروید 7.0، یک روش عمومی برای تعیین سطح جمع‌آوری/تأیید‌سنجی که در مراحل مختلف اتفاق افتاده است، وجود دارد. سطوح کامپایل را می توان از طریق ویژگی های سیستم پیکربندی کرد و پیش فرض های آن عبارتند از:

    • pm.dexopt.install=speed-profile

      • این فیلتر کامپایل است که هنگام نصب برنامه ها از طریق Google Play استفاده می شود. توصیه می‌کنیم فیلتر نصب را روی speed-profile تنظیم کنید تا امکان استفاده از پروفایل‌ها از فایل‌های فراداده dex وجود داشته باشد. توجه داشته باشید که اگر نمایه ای ارائه نشده باشد یا خالی است، نمایه سرعت معادل تأیید است.

    • pm.dexopt.bg-dexopt=speed-profile

      • این فیلتر کامپایل است که وقتی دستگاه بیکار است، در حال شارژ و شارژ کامل است استفاده می شود. فیلتر کامپایلر speed-profile را امتحان کنید تا از مزایای کامپایل هدایت‌شده نمایه استفاده کنید و در ذخیره‌سازی ذخیره کنید.

    • pm.dexopt.boot-after-ota=verify

      • فیلتر کامپایل که پس از به‌روزرسانی از طریق هوا استفاده می‌شود. ما قویاً فیلتر کامپایلر verify را برای این گزینه توصیه می کنیم تا از زمان های بوت بسیار طولانی جلوگیری شود.

    • pm.dexopt.first-boot=verify

    • فیلتر کامپایل برای اولین بار دستگاه بوت می شود. فیلتر استفاده شده در اینجا فقط بر زمان بوت شدن پس از کارخانه تأثیر می گذارد. ما توصیه می‌کنیم فیلتر را verify تا از زمان‌های طولانی قبل از اینکه کاربر برای اولین بار از تلفن استفاده کند جلوگیری کند. توجه داشته باشید که اگر همه برنامه‌های موجود در تصویر سیستم قبلاً با verify ، speed-profile یا speed با زمینه بارگذار کلاس مناسب کامپایل شده باشند، pm.dexopt.first-boot هیچ تأثیری نخواهد داشت.

    گزینه های Dex2oat

    توجه داشته باشید که این گزینه‌ها بر روی dex2oat در حین کامپایل روی دستگاه و همچنین در هنگام بهینه‌سازی اولیه تأثیر می‌گذارند، در حالی که بیشتر گزینه‌های مورد بحث در بالا فقط بر پیش بهینه‌سازی تأثیر می‌گذارند.

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

    • dalvik.vm.image-dex2oat-Xms: اندازه اولیه پشته
    • dalvik.vm.image-dex2oat-Xmx: حداکثر اندازه پشته
    • dalvik.vm.image-dex2oat-filter: گزینه فیلتر کامپایلر
    • dalvik.vm.image-dex2oat-threads: تعداد رشته های مورد استفاده

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

    • dalvik.vm.dex2oat-Xms: اندازه اولیه پشته
    • dalvik.vm.dex2oat-Xmx: حداکثر اندازه پشته
    • dalvik.vm.dex2oat-filter: گزینه فیلتر کامپایلر

    در نسخه های منتشر شده از طریق Android 6.0، یک گزینه اضافی برای کامپایل کردن همه چیز علاوه بر تصویر بوت ارائه شده است:

    • dalvik.vm.dex2oat-threads: تعداد رشته های مورد استفاده

    با شروع Android 6.1، این دو گزینه اضافی برای کامپایل کردن همه چیز به جز تصویر بوت می شود:

    • dalvik.vm.boot-dex2oat-threads: تعداد رشته هایی که در زمان بوت استفاده می شود
    • dalvik.vm.dex2oat-threads: تعداد رشته هایی که باید بعد از بوت شدن استفاده کرد

    با شروع Android 7.1، دو گزینه برای کنترل نحوه استفاده از حافظه هنگام کامپایل کردن همه چیز به غیر از تصویر بوت ارائه شده است:

    • dalvik.vm.dex2oat-very-large: حداقل اندازه کل فایل dex به بایت برای غیرفعال کردن کامپایل AOT
    • dalvik.vm.dex2oat-swap: از فایل swap dex2oat (برای دستگاه های با حافظه کم) استفاده کنید

    گزینه‌هایی که اندازه اولیه و حداکثر هیپ را برای dex2oat ، نباید کاهش یابند زیرا می‌توانند برنامه‌های قابل کامپایل را محدود کنند.

    با شروع Android 11، سه گزینه وابسته به CPU ارائه شده است تا رشته های کامپایلر به گروه خاصی از CPU محدود شوند:

    • dalvik.vm.boot-dex2oat-cpu-set: پردازنده‌هایی که در طول زمان بوت، رشته‌های dex2oat را اجرا می‌کنند
    • dalvik.vm.image-dex2oat-cpu-set: CPU ها در حین کامپایل کردن تصویر بوت، dex2oat را اجرا می کنند
    • dalvik.vm.dex2oat-cpu-set: پردازنده هایی که رشته های dex2oat را پس از زمان بوت اجرا می کنند

    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

    با شروع اندروید 12، گزینه های زیر اضافه شدند:

    • dalvik.vm.ps-min-first-save-ms: زمان انتظار برای زمان اجرا برای تولید نمایه برنامه، اولین باری که برنامه راه اندازی می شود.
    • dalvik.vm.ps-min-save-period-ms: حداقل زمان انتظار قبل از به‌روزرسانی نمایه یک برنامه
    • dalvik.vm.systemservercompilerfilter: فیلتر کامپایلری که دستگاه هنگام کامپایل مجدد سرور سیستم از آن استفاده می کند.

    پیکربندی خاص 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/%

    پس‌زمینه dexopt OTA

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

    pm.dexopt.ab-ota=speed-profile

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