הגדרת ART

בדף הזה מוסבר איך להגדיר את סביבת זמן הריצה של Android (ART) ואת אפשרויות ההידור של Android. נושאים כתובות כאן כוללות הגדרה של הידור מראש של תמונת המערכת, dex2oat אפשרויות הידור (compilation) ואיך להחליף את שטח מחיצות המערכת, את השטח של מחיצות הנתונים או של ביצועים.

כדי לעבוד עם ART, אפשר לעיין במאמרים ART ו-Dalvik ופורמט ההפעלה של Alvik. למידע נוסף, ראו אימות התנהגות האפליקציה בזמן הריצה של Android (ART) כדי לוודא שהאפליקציות פועלות כראוי.

איך פועל ART

ב-ART משתמשים בתכונה 'הידור מראש' (AOT), והחל מ-Android 7, משתמשת בשילוב היברידי של הידור AOT, הידור בדיוק בזמן (JIT) ופרשנות, ואת אוסף ה-AOT אפשר להנחות אותו בפרופיל. השילוב של כל מצבי הביצוע האלה ניתנים להגדרה ונדון בקטע הזה. לדוגמה, במכשירי Pixel מוגדרים בתהליך הבא:

1. אפליקציה מותקנת בהתחלה עם קובץ מטא-נתונים של dex (.dm) שמופץ על ידי חנות Play, שמכילה פרופיל בענן. ב-ART AOT מרוכזים השיטות שמפורטות בענן פרופיל. לחלופין, אם האפליקציה מותקנת ללא קובץ מטא-נתונים של dex, לא קיים הידור של AOT שבוצעו.
2. בפעמים הראשונות שהאפליקציה מופעלת, מתבצע פרשנות של שיטות שלא עברו הידור AOT. מבין השיטות המפורשות, השיטות האלה שמופעלות לעיתים קרובות עוברות הידור JIT. שעון ארגנטינה (ART) יוצר פרופיל מקומי על סמך הביצוע ומשלב אותו עם הפרופיל בענן (אם יש כזה קיים).
3. כשהמכשיר לא פעיל ונטען, דימון (daemon) רץ כדי להדר מחדש את האפליקציה על סמך הפרופיל המשולב שנוצר במהלך הריצות הראשונות.
4. בהפעלות הבאות של האפליקציה, ART משתמש בפריטי המידע שנוצרו על ידי ההידור דימון (daemon), שמכיל יותר קוד שעבר הידור באמצעות AOT, בהשוואה לקודים שנוצרו במהלך שיטות שלא עברו הידור AOT עדיין מפורשות או עוברות הידור JIT. ART מעדכנת את הפרופיל בהתאם להפעלה, והפרופיל ייקלט לאחר מכן בהפעלות הבאות של הדימון (daemon) של האוסף.

ART מורכב מהדר (הכלי dex2oat) ומסביבת זמן ריצה (libart.so) שנטען במהלך האתחול. הכלי dex2oat לוקח קובץ APK ויוצר קובץ אחד או יותר של קובצי הידור (Artifact) שסביבת זמן הריצה טוענת. את מספר הקבצים, את הערכים שלהם התוספים והשמות עשויים להשתנות בגרסאות השונות, אך החל בגרסת Android 8, הקבצים הבאים נוצרים:

• .vdex: מכיל מטא-נתונים נוספים כדי לזרז את האימות, לפעמים יחד עם בקוד ה-DEX הלא דחוס של ה-APK.
• .odex: מכיל קוד שעבר הידור AOT ל-methods APK
• .art (optional) מכיל ART פנימי של חלק מהמחרוזות והמחלקות שרשומים ב-APK, ומשמשים להאצה בזמן ההפעלה של האפליקציה.

אפשרויות הידור

ב-ART יש שתי קטגוריות של אפשרויות הידור:

1. הגדרת ROM של המערכת: איזה קוד נוצר ב-AOT בזמן הבנייה קובץ אימג' של המערכת.
2. הגדרת זמן ריצה: איך ART מהדר ומריץ אפליקציות במכשיר.

פילטרים של הידור

אפשרות ליבה אחת של ART להגדרת שתי הקטגוריות האלה היא מהדר (compiler)" מסננים. מסנני מהדרים מניעים את האופן שבו ART מהדר קוד DEX, האפשרות מועברת לכלי dex2oat. החל מ-Android 8. קיימים ארבעה מסננים שנתמכים באופן רשמי:

• verify: הפעלת רק אימות באמצעות קוד DEX (ללא הידור AOT).
• quicken: (עד ל-Android 11) הרצת קוד DEX לבצע אימות ולבצע אופטימיזציה של כמה מהוראות ה-DEX כדי לשפר את הביצועים של המתורגמן.
• speed: הרצת אימות של קוד DEX והדרת AOT של כל השיטות.
• speed-profile: הרצת אימות של קוד DEX ושיטות הידור AOT שרשומים בקובץ פרופיל.

הגדרת ה-ROM של המערכת

ספריות ואפליקציות שהותקנו מראש עוברות הידור AOT בזמן הבנייה של תמונת המערכת. הזה נקרא dexpreopt. אפשר להשתמש בקבצים מורכבים כאלה כל עוד כל יחסי התלות יישארו ללא שינוי, במיוחד את נתיב האתחול של האתחול.

הערה: אם המכשיר לוקח מודול המערכת מתעדכן, אז נתיב האתחול שישתנה בעדכון הבא, מה שיגרום לכך שכל הקבצים ב-dexpreopt מיושנים ולא ניתנים לשימוש.

יש כמה אפשרויות ל-build של ART שניתן להגדיר ל-dexpreopt. איך מגדירים את התכונה אפשרויות אלו תלויות בשטח האחסון הזמין לתמונת המערכת ובמספר שהותקנו מראש. אפשר לחלק את ה-JARs/חבילות ה-APK שקובצו ל-ROM של המערכת קטגוריות:

• קוד classpath אתחול: עבר הידור באמצעות מסנן המהדר (compiler) 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 או הידור (compiler) כברירת מחדל, או שעברה הידור באמצעות מסנן המהדר (compiler) speed אם לא צוין פרופיל.
  • (Android 13 ומטה) משולבים באמצעות speed כברירת מחדל.
  ניתן להגדיר דרך PRODUCT_SYSTEM_SERVER_COMPILER_FILTER (ראו בהמשך ).
• אפליקציות ליבה ספציפיות למוצר (ראו PRODUCT_DEXPREOPT_SPEED_APPS בהמשך המאמר) document): עברו הידור באמצעות מסנן המהדר (compiler) speed כברירת מחדל.
• כל שאר האפליקציות: הן עברו הידור באמצעות מסנן המהדר (compiler) speed-profile כברירת מחדל, או שעברה הידור באמצעות מסנן המהדר (compiler) 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, צריך להשתמש רק בפרמטר להפעיל את ה-classpath ואת הצנצנות השרת של המערכת.

• LOCAL_DEX_PREOPT

אפשר גם להפעיל או להשבית את Dexpreopt בכל אפליקציה בנפרד על ידי שמציין את האפשרות LOCAL_DEX_PREOPT בהגדרת המודול. האפשרות הזו יכולה להיות שימושית כדי להשבית את החיפוש של אפליקציות שעלולות להיות מיידות לקבל עדכונים מ-Google Play, כי העדכונים יעבדו את השינויים בתמונת המערכת בפורמט מיושן. זה גם שימושי כדי לחסוך מקום בתוכניות OTA לשדרוג גרסאות כי יכול להיות שלמשתמשים כבר יש גרסאות חדשות יותר של אפליקציות במחיצת הנתונים.

LOCAL_DEX_PREOPT תומך בערכים true או false עד להפעיל או להשבית את dexpreopt, בהתאמה. בנוסף, nostripping יכול יש לציין אם dexpreopt לא צריך להסיר את classes.dex מקובץ ה-APK או מקובץ ה-JAR. בדרך כלל הקובץ הזה מוסר כי לא נדרש יותר זמן אחרי הניסיון, אבל האפשרות האחרונה היא מתן אפשרות לחתימות 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)

רשימת אפליקציות שזוהו כמעבדות במוצרים שרוצים להדר באמצעות מסנן המהדר (compiler) speed. עבור לדוגמה, אפליקציות מתמידות כמו SystemUI מקבלות הזדמנות להשתמש בהדרכה מפורטת של הפרופיל רק באתחול הבא, ולכן עדיף כדי שהאפליקציות האלה תמיד יעברו הידור AOT.

• PRODUCT_SYSTEM_SERVER_APPS (החל מ-Android 8)

רשימת האפליקציות ששרת המערכת נטען. האפליקציות האלה עוברים הידור כברירת מחדל באמצעות מסנן המהדר (compiler) speed.

• PRODUCT_ART_TARGET_INCLUDE_DEBUG_BUILD (החל מ-Android) 8)

הגדרה שקובעת אם לכלול גרסת ניפוי באגים של ART במכשיר. כברירת מחדל, מופעל ל-userdebug ולגרסאות build של מעורבות. אפשר לשנות את ההתנהגות הזו באופן מפורש להגדיר את האפשרות 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.

ב-Android 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

האפשרות הזו מציינת את מסנן המהדר (compiler) לשרת המערכת.

• (Android 14 ואילך) אם לא צוין, speed-profile נעשה שימוש במסנן מהדר, או שייעשה שימוש במסנן המהדר (compiler) speed אם פרופיל אינו שניתנו.
• (Android 13 ומטה) אם לא צוין, המהדר של speed נעשה שימוש במסנן.
• אם המדיניות מוגדרת לערך speed, ייעשה שימוש במסנן המהדר (compiler) speed.
• אם המדיניות מוגדרת לערך speed-profile, ייעשה שימוש במסנן המהדר (compiler) speed-profile, או אם לא סופק פרופיל, נעשה שימוש במסנן המהדר (compiler) verify.
• אם המדיניות מוגדרת לערך verify, ייעשה שימוש במסנן המהדר (compiler) 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) של classpath לרשימה הזו. לא ניתן להוסיף לרשימה את ה-JAR של נתיבי הכיתה של שרת המערכת ולכן ה-JAR האלה לא נטענים.
• (חובה) PRODUCT_APEX_SYSTEM_SERVER_JARS: רשימה של JARs מסוג classpath של שרת המערכת נמסרה באמצעות APEX (כלומר, כחלק מ-SYSTEMSERVERCLASSPATH). הפורמט הוא <apex name>:<jar name>. הוספת JARs של נתיב מחלקה של מערכת APEX אל זוהי רשימה נדרשת. אם לא מוסיפים לרשימה הזו JARs של שרת APEX של מערכת APEX, ה-JAR האלה לא נטענים.
• (אופציונלי, Android מגרסה 13 ומטה) PRODUCT_STANDALONE_SYSTEM_SERVER_JARS: רשימה של JAR ששרת המערכת טוען שימוש דינמי ב-classloads נפרדים (דרך SystemServiceManager.startServiceFromJar). הוספת JARs של שרתי מערכת עצמאיים אל הרשימה הזו לא נדרשת, אבל מומלצת מאוד כי היא הופכת את ה-JARs מקומפלים ולכן יש להם ביצועים טובים בסביבת זמן הריצה.
• (חובה, החל מ-Android 13) PRODUCT_APEX_STANDALONE_SYSTEM_SERVER_JARS: רשימה של JARS שנשלחים באמצעות APEX, ושרת המערכת נטען באופן דינמי באמצעות Classloaders נפרדים (כלומר הוא, דרך SystemServiceManager.startServiceFromJar או מוצהר כ- <apex-system-service>). הפורמט הוא <apex name>:<jar name> הוספת JARs עצמאיים של שרתי מערכת APEX אל זוהי רשימה נדרשת. אם לא מוסיפים לרשימה הזו JARs עצמאיים של שרתי APEX, התוצאה כשל באתחול.

הגדרת תצורת classpath

רשימת הכיתות שנטענו מראש היא רשימת המחלקות ש-Zygote מאתחלת בהן בזמן ההפעלה. כך כל אפליקציה לא תצטרך להריץ את מאתחלי הכיתות האלה בנפרד, כך שהם יוכלו להתחיל לפעול מהר יותר ולשתף דפים מהזיכרון. קובץ רשימת הכיתות שנטענו מראש נמצא בכתובת frameworks/base/config/preloaded-classes כברירת מחדל, ומכיל רשימה שמתאימה לשימוש בטלפון הרגיל. יכול להיות להיות שונה ממכשירים אחרים, כמו גאדג'טים לבישים, וצריך לכוונן אותן בהתאם. חשוב להיזהר כשאתם מכווננים את זה, הוספת יותר מדי בזבוז של כיתות מהזיכרון כשכיתות שלא בשימוש נטענים. הוספת מעט מדי כיתות מאלצת כל אפליקציה צריך להיות להם עותק משלו, וזה מבזבז שוב את הזיכרון.

שימוש לדוגמה (ב-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 (ברירת המחדל היא 10,000): הסף של 'חום' צריך להעביר מונה של שיטה ל-method שתבוצע בהדרת JIT. "הפופולריות" מונה הוא מדד פנימי לסביבת זמן הריצה. הוא כולל את מספר השיחות, הסתעפויות לאחור גורמים.
• dalvik.vm.usejitprofiles (עד Android 13): האם או לא הופעלו פרופילי JIT. אפשר להשתמש בערך הזה גם אם הערך של dalvik.vm.usejit הוא False. שימו לב שאם הערך הזה מוגדר כ-False, מסנן המהדר (compiler) speed-profile אכן לא להדר באמצעות AOT לאף שיטה, והיא שוות ערך ל-verify. מאז Android 14, פרופילי JIT תמיד מופעלים ואי אפשר להשבית אותם.
• dalvik.vm.jitprithreadweight (ברירת המחדל היא dalvik.vm.jitthreshold / 20: המשקל של "דגימות" ה-JIT (מידע נוסף זמין כאן: jitthreshold) ל-thread של ממשק המשתמש של האפליקציה. אפשר להשתמש בה כדי לזרז את ההידור של שיטות שמשפיעות באופן ישיר על חוויית המשתמש במהלך אינטראקציה עם אפליקציה.
• dalvik.vm.jittransitionweight (ברירת המחדל היא dalvik.vm.jitthreshold / 10): המשקל של השיטה יכולה לעבור בין הידור של הקוד לבין המתרגם. המידע הזה עוזר לוודא שהשיטות שבהן נעשה שימוש מורכבות כדי למזער מעברים (שהם יקר).

אפשרויות Dex2oat

האפשרויות האלה משפיעות על ההידור במכשיר (שנקרא גם dexopt), וחלק מהן משפיעות גם dexpreopt, אבל האפשרויות שמוזכרים בקטע הגדרת ROM של המערכת שלמעלה בלבד משפיעה על dexpreopt.

אפשרויות להגדרת השימוש במשאבים:

• dalvik.vm.image-dex2oat-threads מתוך dalvik.vm.image-dex2oat-cpu-set (עד Android 11): מספר השרשורים וקבוצת ליבות המעבד (CPU) שבהמשך) לשימוש בתמונות אתחול.
• dalvik.vm.boot-dex2oat-threads מתוך dalvik.vm.boot-dex2oat-cpu-set:
  • (עד 11 Android) מספר השרשורים וקבוצת ליבות המעבד (CPU) (ראו בהמשך) לשימוש בזמן האתחול עבור כל דבר מלבד תמונות אתחול.
  • (החל מ-Android 12) מספר השרשורים וקבוצת ליבות המעבד (CPU) (ראו בהמשך) לשימוש בזמן האתחול עבור כל דבר, כולל תמונות אתחול.
    • באופן ספציפי, החל מ-Android 14, סיווג עדיפות PRIORITY_BOOT בשירות ART.
• dalvik.vm.restore-dex2oat-threads מתוך dalvik.vm.restore-dex2oat-cpu-set:
  • (החל מ-Android 11 ועד Android 13) מספר השרשורים וקבוצת ליבות המעבד (CPU) לשימוש לצורך שחזור מהענן גיבוי.
  • (החל מ-Android 14) מספר השרשורים וקבוצת ליבות המעבד (CPU) (ראו בהמשך) לשימוש בכל הכלים שרגישים יותר מהרגיל, כולל שחזור מגיבוי מהענן.
    • באופן ספציפי, הוא תואם לסיווג העדיפות PRIORITY_INTERACTIVE_FAST בשירות ART.
• dalvik.vm.background-dex2oat-threads/ dalvik.vm.background-dex2oat-cpu-set (החל מ-Android 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), מומלץ להתאים את המאפיין התואם מספר שרשורי dex2oat שיתאימו למספר המעבדים שנבחרו כדי למנוע זיכרון וקלט/פלט מיותרים תחרות:

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

בנוסף למאפייני המערכת שלמעלה, תוכלו גם להשתמש בפרופילים של משימות כדי לשלוט שימוש במשאבים של dex2oat (מידע נוסף זמין במאמר שכבת Abstraction של Cgroup).

הפרופילים הנתמכים של המשימות הם:

• Dex2OatBackground (החל מ-Android 14) (יירשת את Dex2OatBootComplete כברירת מחדל): המדיניות הזו קובעת באילו משאבים צריך להשתמש ברקע.
  • באופן ספציפי, הוא תואם לסיווג העדיפות PRIORITY_BACKGROUND ב- שירות ART.
• Dex2OatBootComplete:
  • (עד Android 13) שליטה במשאב לשימוש בכל מקום לאחר האתחול.
  • (החל מ-Android 14) ההגדרה של המשאב שצריך להשתמש בו לכל דבר לאחר ההפעלה ולא ברקע.
    • באופן ספציפי, הוא תואם לסיווג העדיפות PRIORITY_INTERACTIVE_FAST ו-PRIORITY_INTERACTIVE ב-ART שירות.

אם יצוינו גם מאפייני מערכת וגם פרופילים של משימות, שניהם ייכנסו לתוקף.

אפשרויות לשליטה בגודל הערימה:

• dalvik.vm.image-dex2oat-Xms: גודל התחלתי של ערימה (heap) לתמונות אתחול.
• dalvik.vm.image-dex2oat-Xmx: גודל ערימה מקסימלי של תמונות אתחול.
• dalvik.vm.dex2oat-Xms: גודל ראשוני של ערימה לכל השאר.
• dalvik.vm.dex2oat-Xmx: גודל ערימה מקסימלי לכל שאר הפריטים.

האפשרויות ששולטות בגודל הערימה הראשוני והמקסימלי של אין לצמצם את הערך של dex2oat כי הוא יכול להגביל את הערך שניתן להדר.

אפשרויות לשליטה במסנן המהדר (compiler):

• dalvik.vm.image-dex2oat-filter (עד Android 11): מסנן המהדר לתמונות אתחול. החל מ-Android 12, המהדר המסנן לתמונות האתחול הוא תמיד speed-profile ואי אפשר לשנות אותו.
• dalvik.vm.systemservercompilerfilter (החל מ-Android 13): מסנן המהדר (compiler) לשרת המערכת. ראו PRODUCT_SYSTEM_SERVER_COMPILER_FILTER
• dalvik.vm.systemuicompilerfilter (החל מ-Android 13): מסנן המהדר (compiler) לחבילת ממשק המשתמש של המערכת.
• dalvik.vm.dex2oat-filter (עד Android 6): מסנן המהדר (compiler) לכל השאר.
• pm.dexopt.<reason> (החל מ-Android 7): מסנן המהדר (compiler) לכל השאר. צפייה ART Service Configuration (הגדרת שירות ART) ל-Android 14 ואילך, או הגדרות אישיות של Package Manager עבור Android מגרסה 13 ומטה.

אפשרויות נוספות לשליטה בהידור של כל דבר מלבד תמונות אתחול:

• dalvik.vm.dex2oat-very-large (החל מ-Android 7.1): הגודל הכולל המינימלי של קובץ dex הוא כדי להשבית הידור AOT.
• 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) (ברירת המחדל: false): האם להשתמש בגרסת 64 ביט של dex2oat.
• dalvik.vm.bgdexopt.new-classes-percent (החל מ-Android 12) (ברירת מחדל: 20): האחוז המינימלי, בין 0 ל-100, של כיתות חדשות בפרופיל שיגרום לאוסף מחדש. רלוונטי רק לאוסף מודרך על ידי פרופיל (speed-profile), בדרך כלל במהלך בדיקת רקע ברקע. לתשומת ליבכם: יש גם סף של 50 כיתות חדשות לפחות, הסף באחוזים, ולא ניתן להגדיר אותו.
• dalvik.vm.bgdexopt.new-methods-percent (החל מ-Android 12) (ברירת מחדל: 20): האחוז המינימלי, בין 0 ל-100, של שיטות חדשות בפרופיל שגורמות לאיסוף מחדש. רלוונטי רק לאוסף מודרך על ידי פרופיל (speed-profile), בדרך כלל במהלך בדיקת רקע ברקע. לתשומת ליבכם, יש גם סף של 100 שיטות חדשות לפחות, בנוסף לסף האחוזים, ואי אפשר להגדיר אותו.
• dalvik.vm.dex2oat-max-image-block-size (החל מ-Android 10) (ברירת המחדל: 524288) גודל מקסימלי של בלוק מלא לתמונות דחוסות. תמונה גדולה מחולקת לקבוצה של צבעים מוצקים בלוקים כך שאף בלוק לא יהיה גדול מהגודל המקסימלי.
• dalvik.vm.dex2oat-resolve-startup-strings (החל מ-Android 10) (ברירת המחדל: true) אם הערך הוא True, הדבר יגרום ל-dex2oat לפתור את כל מחרוזות ה-const שיש אליהן הפניה מ-methods שמסומנות כ- 'startup' בפרופיל.
• debug.generate-debug-info (ברירת מחדל: false) האם ליצור מידע על תוצאות ניפוי הבאגים לניפוי באגים מקורי, כמו שחרור מקבצים מידע, סמלי ELF וקטעי גמדים.
• dalvik.vm.dex2oat-minidebuginfo (החל מ-Android 9) (ברירת המחדל: true) האם לייצר כמות מינימלית של מידע על ניפוי באגים בדחיסת LZMA לצורך טביעות לאחור של ההדפסות.

אפשרויות שירות של ART

החל מ-Android 14, הידור AOT במכשיר לאפליקציות (שנקרא גם dexopt) מטופל על ידי ART Service. למידע על הגדרת שירות ART, ראו ART Service configuration (הגדרת שירות ART).

אפשרויות של מנהל חבילות

לפני 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

שימו לב שקוד classpath האתחול, קוד השרת של המערכת וליבה ספציפית למוצר אפליקציות תמיד עוברות הידור למחיצת המערכת. כברירת מחדל, כל שאר עוברים הידור למחיצת המערכת השנייה שאינה בשימוש. סוג הפריט יכול להיות נשלט באמצעות SYSTEM_OTHER_ODEX_FILTER, שיש לו ערך על ידי ברירת מחדל של:

SYSTEM_OTHER_ODEX_FILTER ?= app/% priv-app/%

dexopt OTA ברקע

במכשירים שתומכים ב-A/B, ניתן להדר אפליקציות ברקע לפני האתחול מחדש באמצעות קובץ אימג' חדש של המערכת. למידע נוסף, ניתן לעיין בקטע אוסף אפליקציות ב: רקע כדי לכלול באופן אופציונלי את סקריפט ההידור ואת הקבצים הבינאריים בתמונת המערכת. מסנן ההידור שמשמש לאוסף הזה נשלט באמצעות:

pm.dexopt.ab-ota=speed-profile

מומלץ להשתמש בspeed-profile כדי ליהנות מהיתרונות של הדרכה מונחית בפרופיל של אקסטרים ולחסוך באחסון.

אפשרויות של JDWP

יצירת השרשורים ב-Java Debug Wire Protocol (JDWP) בגרסאות build של ניפוי באגים מתבצעת באמצעות ה מאפיין מערכת אחד (persist.debug.dalvik.vm.jdwp.enabled). כברירת מחדל, הנכס הזה לא מוגדר, שרשורי JDWP נוצרים רק עבור אפליקציות שניתנות לניפוי באגים. כדי להפעיל שרשורי JDWP בשניהם אפליקציות שניתנות לניפוי באגים ואפליקציות שלא ניתנות לניפוי באגים, מגדירים persist.debug.dalvik.vm.jdwp.enabled אל 1. צריך להפעיל מחדש את המכשיר כדי שהשינויים בנכס ייכנסו לתוקף.

כדי לנפות באגים באפליקציה שלא ניתנת לניפוי באגים בגרסת build לניפוי באגים, מפעילים את JDWP באמצעות הרצת הפקודה הבאה: הפקודה:

  adb shell setprop persist.debug.dalvik.vm.jdwp.enabled 1
  adb reboot
  

במכשירים עם Android מגרסה 13 ומטה, סביבת זמן הריצה יוצרת JDWP שרשורים לאפליקציות שניתנות לניפוי באגים ולא לניפוי באגים בגרסאות build של משתמשים לניפוי באגים. כלומר, ייתכן כדי לצרף כלי לניפוי באגים או יצירת פרופיל לכל אפליקציה בגרסת build לניפוי באגים.