בדף הזה מוסבר איך להגדיר את סביבת זמן הריצה של Android (ART) ואת אפשרויות ההידור של Android. נושאים
כתובות כאן כוללות הגדרה של הידור מראש של תמונת המערכת, dex2oat
אפשרויות הידור (compilation) ואיך להחליף את שטח מחיצות המערכת, את השטח של מחיצות הנתונים
או של ביצועים.
כדי לעבוד עם ART, אפשר לעיין במאמרים ART ו-Dalvik ופורמט ההפעלה של Alvik. למידע נוסף, ראו אימות התנהגות האפליקציה בזמן הריצה של Android (ART) כדי לוודא שהאפליקציות פועלות כראוי.
איך פועל ART
ב-ART משתמשים בתכונה 'הידור מראש' (AOT), והחל מ-Android 7, משתמשת בשילוב היברידי של הידור AOT, הידור בדיוק בזמן (JIT) ופרשנות, ואת אוסף ה-AOT אפשר להנחות אותו בפרופיל. השילוב של כל מצבי הביצוע האלה ניתנים להגדרה ונדון בקטע הזה. לדוגמה, במכשירי Pixel מוגדרים בתהליך הבא:
- אפליקציה מותקנת בהתחלה עם קובץ מטא-נתונים של dex (
.dm
) שמופץ על ידי חנות Play, שמכילה פרופיל בענן. ב-ART AOT מרוכזים השיטות שמפורטות בענן פרופיל. לחלופין, אם האפליקציה מותקנת ללא קובץ מטא-נתונים של dex, לא קיים הידור של AOT שבוצעו. - בפעמים הראשונות שהאפליקציה מופעלת, מתבצע פרשנות של שיטות שלא עברו הידור AOT. מבין השיטות המפורשות, השיטות האלה שמופעלות לעיתים קרובות עוברות הידור JIT. שעון ארגנטינה (ART) יוצר פרופיל מקומי על סמך הביצוע ומשלב אותו עם הפרופיל בענן (אם יש כזה קיים).
- כשהמכשיר לא פעיל ונטען, דימון (daemon) רץ כדי להדר מחדש את האפליקציה על סמך הפרופיל המשולב שנוצר במהלך הריצות הראשונות.
- בהפעלות הבאות של האפליקציה, 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 יש שתי קטגוריות של אפשרויות הידור:
- הגדרת ROM של המערכת: איזה קוד נוצר ב-AOT בזמן הבנייה קובץ אימג' של המערכת.
- הגדרת זמן ריצה: איך 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
(ראו בהמשך ). - (Android 14 ואילך) משולבים באמצעות
- אפליקציות ליבה ספציפיות למוצר (ראו
PRODUCT_DEXPREOPT_SPEED_APPS
בהמשך המאמר) document): עברו הידור באמצעות מסנן המהדר (compiler)speed
כברירת מחדל. - כל שאר האפליקציות: הן עברו הידור באמצעות מסנן המהדר (compiler)
speed-profile
כברירת מחדל, או שעברה הידור באמצעות מסנן המהדר (compiler)verify
אם לא סופק פרופיל.ניתן להגדיר דרך
PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER
(ראו בהמשך ).
אפשרויות Makefile
WITH_DEXPREOPT
DONT_DEXPREOPT_PREBUILTS
(Android 5 ואילך)PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER
(Android 9) ומעלה)WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY
(החל מ-Android 8 MR1)LOCAL_DEX_PREOPT
PRODUCT_DEX_PREOPT_BOOT_FLAGS
PRODUCT_DEX_PREOPT_DEFAULT_FLAGS
PRODUCT_DEX_PREOPT_MODULE_CONFIGS
PRODUCT_DEXPREOPT_SPEED_APPS
(החל מ-Android 8)PRODUCT_SYSTEM_SERVER_APPS
(החל מ-Android 8)PRODUCT_ART_TARGET_INCLUDE_DEBUG_BUILD
(החל מ-Android) 8)WITH_DEXPREOPT_PIC
(עד Android 7)WITH_DEXPREOPT_BOOT_IMG_ONLY
(עד Android 7) MR1)PRODUCT_SYSTEM_SERVER_COMPILER_FILTER
- (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
- (חובה)
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, התוצאה כשל באתחול.
הפעלה של dex2oat
בקוד DEX שמותקן בתמונת המערכת. מופעל כברירת מחדל.
הפעלת DONT_DEXPREOPT_PREBUILTS
מונעת את האפשרות של תכונות הבנייה מראש
שאומצו. אלה אפליקציות עם include $(BUILD_PREBUILT)
שצוינו בAndroid.mk
שלהם. מדלג
לעיין באפליקציות מוכנות מראש שסביר להניח שיעודכנו דרך Google Play
חוסך מקום בתמונת המערכת, אבל כן מתווסף לשעת האתחול הראשונה. חשוב לשים לב שלאפשרות הזו אין השפעה
באפליקציות שפותחו מראש שמוגדרות ב-Android.bp
.
PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER
מציין את מסנן המהדר שמוגדר כברירת מחדל
לאפליקציות שלא אושרו. האפליקציות האלה מוגדרות ב-Android.bp
או שהן
צוין include $(BUILD_PREBUILT)
בAndroid.mk
שלהם. אם לא צוין,
ערך ברירת המחדל הוא speed-profile
או verify
אם הערך לא צוין
ולא מוצג פרופיל.
אם מפעילים את WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY
, צריך להשתמש רק בפרמטר
להפעיל את ה-classpath ואת הצנצנות השרת של המערכת.
אפשר גם להפעיל או להשבית את Dexpreopt בכל אפליקציה בנפרד על ידי
שמציין את האפשרות LOCAL_DEX_PREOPT
בהגדרת המודול.
האפשרות הזו יכולה להיות שימושית כדי להשבית את החיפוש של אפליקציות שעלולות להיות מיידות
לקבל עדכונים מ-Google Play, כי העדכונים יעבדו את השינויים
בתמונת המערכת בפורמט מיושן. זה גם שימושי כדי לחסוך מקום בתוכניות
OTA לשדרוג גרסאות כי יכול להיות שלמשתמשים כבר יש גרסאות חדשות יותר של אפליקציות
במחיצת הנתונים.
LOCAL_DEX_PREOPT
תומך בערכים true
או false
עד
להפעיל או להשבית את dexpreopt, בהתאמה. בנוסף, nostripping
יכול
יש לציין אם dexpreopt לא צריך להסיר את classes.dex
מקובץ ה-APK או מקובץ ה-JAR. בדרך כלל הקובץ הזה מוסר כי לא
נדרש יותר זמן אחרי הניסיון, אבל האפשרות האחרונה היא
מתן אפשרות לחתימות APK של צד שלישי להישאר בתוקף.
מעביר אפשרויות אל dex2oat
כדי לקבוע את האופן שבו תמונת האתחול
שעברה הידור. אפשר להשתמש בו כדי לציין רשימות של מחלקות תמונות מותאמות אישית, שעברו הידור
רשימות של מחלקות ומסנני מהדר.
מעביר אפשרויות אל dex2oat
כדי לקבוע איך הכול חוץ מ-
עבר הידור.
מאפשרת להעביר אפשרויות של dex2oat
בשביל ספציפי
של המודול וההגדרה של המוצר. הוא מוגדר
קובץ device.mk
של $(call add-product-dex-preopt-module-config,<modules>,<option>)
כאשר <modules>
הוא רשימה של LOCAL_MODULE
וגם
LOCAL_PACKAGE
שמות של קובצי JAR ו-APK, בהתאמה.
רשימת אפליקציות שזוהו כמעבדות במוצרים
שרוצים להדר באמצעות מסנן המהדר (compiler) speed
. עבור
לדוגמה, אפליקציות מתמידות כמו SystemUI מקבלות הזדמנות להשתמש
בהדרכה מפורטת של הפרופיל רק באתחול הבא, ולכן עדיף
כדי שהאפליקציות האלה תמיד יעברו הידור AOT.
רשימת האפליקציות ששרת המערכת נטען. האפליקציות האלה
עוברים הידור כברירת מחדל באמצעות מסנן המהדר (compiler) speed
.
הגדרה שקובעת אם לכלול גרסת ניפוי באגים של ART במכשיר. כברירת מחדל,
מופעל ל-userdebug ולגרסאות build של מעורבות. אפשר לשנות את ההתנהגות הזו באופן מפורש
להגדיר את האפשרות true
או false
.
כברירת מחדל, המכשיר משתמש בגרסה ללא ניפוי באגים (libart.so
).
כדי להחליף, צריך להגדיר את מאפיין המערכת persist.sys.dalvik.vm.lib.2
לערך
libartd.so
.
בגרסאות 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_AND_SYSTEM_SERVER_ONLY
שגם מאמצת מראש את ה-JAR של שרתי המערכת.
האפשרות הזו מציינת את מסנן המהדר (compiler) לשרת המערכת.
בהמשך מופיעה רשימות של JAR שנטענו על ידי שרת המערכת. ה-JAR מחולקים
מסנן הידור שצוין על ידי PRODUCT_SYSTEM_SERVER_COMPILER_FILTER
הגדרת תצורת 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.
- באופן ספציפי, החל מ-Android 14,
סיווג עדיפות
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 באמצעות הרצת הפקודה הבאה: הפקודה:
במכשירים עם Android מגרסה 13 ומטה, סביבת זמן הריצה יוצרת JDWP שרשורים לאפליקציות שניתנות לניפוי באגים ולא לניפוי באגים בגרסאות build של משתמשים לניפוי באגים. כלומר, ייתכן כדי לצרף כלי לניפוי באגים או יצירת פרופיל לכל אפליקציה בגרסת build לניפוי באגים.adb shell setprop persist.debug.dalvik.vm.jdwp.enabled 1
adb reboot