סקירה כללית של פרופילים בסיסיים

פרופילים של Baseline משפרים את מהירות הרצת הקוד ב-30% בערך מההפעלה הראשונה, כי הם מאפשרים להימנע משלבי פרשנות וקימפול just-in-time (JIT) לנתיבי הקוד הכלולים.

כשמצרפים פרופיל Baseline לאפליקציה או לספרייה, סביבת זמן הריצה ל-Android‏ (ART) יכולה לבצע אופטימיזציה של נתיבי קוד ספציפיים באמצעות קימפול מראש (AOT), וכך לשפר את הביצועים לכל משתמש חדש ולכל עדכון לאפליקציה. זו אופטימיזציה מונחית פרופיל (PGO) שמאפשרת לאפליקציות להעלות את איכות ההפעלה, לצמצם בעיות בממשק (jank) שקשורות לאינטראקציה, ולשפר את הביצועים הכוללים של זמן הריצה למשתמשים כבר מההפעלה הראשונה.

השיפורים האלה בביצועים מובילים ישירות לשיפור במדדים העסקיים, כמו שימור משתמשים, עסקאות ודירוגים. אתם יכולים לקרוא עוד על ההשפעה של הביצועים על המדדים העסקיים בסיפורים של Josh,‏ Lyft,‏ TikTok ו-Zomato.

היתרונות של פרופילים של Baseline

פרופילים של Baseline מאפשרים קומפילציה מראש של קוד באינטראקציות קריטיות של משתמשים, כמו הפעלת האפליקציה, מעבר בין מסכים או גלילה בתוכן, וכך משפרים את האינטראקציות האלה כבר מהפעם הראשונה שהם מפעילים את האפליקציה. הם יכולים להגביר את המהירות ויכולת התגובה של האפליקציה, וכך להוביל ליותר משתמשים פעילים ביום (DAU) ולשיעור גבוה יותר של מבקרים חוזרים.

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

כשלא משתמשים בפרופיל Baseline, כל קוד האפליקציה עובר קימפול JIT בזיכרון אחרי שהוא מפוענח, או שהוא נכתב לקובץ odex ברקע כשהמכשיר לא פעיל. אחרי התקנה או עדכון של אפליקציה, חוויית השימוש לא תהיה אופטימלית בהפעלה הראשונה, אלא רק אחרי שיימצאו נתיבי קוד חדשים שיעברו אופטימיזציה. אפליקציות רבות מדווחות על שיפור של כ-30% בביצועים אחרי האופטימיזציה.

פרופילים להפעלה

פרופילים להפעלה דומים לפרופילים של Baseline, אבל משתמשים בהם בזמן הקימפול כדי לבצע אופטימיזציה של פריסת DEX לזמני הפעלה מהירים יותר, ולא לאופטימיזציה במכשיר. מידע נוסף על ההבדלים בין פרופילים להפעלה לבין פרופילים של Baseline זמין במאמר בנושא השוואה בין פרופילים של Baseline לבין פרופילים להפעלה. למידע נוסף על אופטימיזציה של פריסת DEX, אפשר לעיין במאמר שכאן.

איך להתחיל

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

יצירת פרופילים לעומת גרסאות build להפצה

חשוב להבין את ההבדל בין תצורות ה-build שנדרשות כשיוצרים קובצי פרופיל Baseline ופרופיל להפעלה (לדוגמה, baseline-prof.txt ו-startup-prof.txt) לבין תצורות ה-build שנדרשות כשיוצרים את קובץ ה-APK הסופי של הגרסה שמשתמש בפרופילים האלה.

כשיוצרים קובצי פרופיל (לדוגמה, benchmark):

כשמתעדים פרופיל Baseline באמצעות בדיקה, אסור לערפל את קוד האפליקציה. כדי לוודא שהכללים שנוצרו לפרופיל תואמים באופן מדויק לחתימות השיטה של הקוד, צריך להשבית את ההסתרה והאופטימיזציה (R8) של וריאנט ה-build שמשמש ליצירת הפרופיל. הווריאנט הזה חייב להיות שונה מהווריאנט של גרסת ה-build להפצה, שבה מופעלות אופטימיזציה והסתרת קוד. כדי לעשות את זה, מגדירים את isMinifyEnabled = false לווריאנט ה-build של יצירת הפרופיל. אם אתם לא משתמשים בפלאגין Baseline Profile Gradle, אתם צריכים לוודא שגם -dontobfuscate וגם -dontoptimize מופעלים. הפלאגין Baseline Profile Gradle מטפל בהגדרה הזו באופן אוטומטי.

כדי לוודא שהאפליקציה לא עברה ערפול קוד במהלך יצירת הפרופיל, פותחים את קובץ פרופיל הטקסט שנוצר (לדוגמה, baseline-prof.txt) ובודקים ששמות המחלקות והשיטות לא עברו ערפול קוד.

כשיוצרים את קובץ ה-APK של הגרסה הסופית:

כשיוצרים את גרסת האפליקציה להפצה, צריך לטשטש את הקוד שלה. כדי ליהנות מהיתרונות של ערפול קוד, צמצום קוד ואופטימיזציה, גרסת ה-build להפצה צריכה לכלול את isMinifyEnabled = true. ‫R8 משכתב באופן אוטומטי את הכללים מקובצי הפרופיל שלא עברו ערפול קוד, כך שיתאימו לקוד שעבר ערפול ואופטימיזציה בקובץ ה-APK של הגרסה. ה-build משתמש בקובץ הטקסט הלא מעורפל כדי להמיר את הכללים בצורה נכונה.

כדי שהאופטימיזציה של פריסת DEX (שמבוססת על פרופילים להפעלה) תפעל, צריך להסתיר את קוד המקור של גרסת האפליקציה ולהשתמש ב-R8 כשכל האופטימיזציות מופעלות.

תהליכי עבודה מתקדמים (לא של Gradle):

אם אתם משתמשים בתהליך עבודה מתקדם שלא מבוסס על Gradle (כמו Bazel,‏ Buck או צינורות עיבוד נתונים מותאמים אישית של אוטומציית CI) כדי ליצור את הפרופילים, אתם עדיין צריכים לפעול לפי אותם עקרונות. אסור שהאפליקציה תהיה מעורפלת או תעבור אופטימיזציה בזמן תיעוד הפרופיל. עם זאת, כשאתם יוצרים את גרסת האפליקציה, אתם צריכים לטשטש אותה. ‫R8 מעבד את קובץ הכללים של הטקסט הלא מעורפל, ומשנה את הכללים בצורה נכונה כדי להחיל אותם על גרסת האפליקציה המעורפלת.

שרשרת התלות מספקת גרסאות יציבות וגרסאות פיתוח. כדי ליצור ולהתקין פרופיל Baseline, צריך להשתמש בגרסאות הנתמכות הבאות או בגרסאות מתקדמות יותר של הפלאגין של Android Gradle, ספריית Macrobenchmark והכלי להתקנת פרופילים. התלויות האלה נדרשות בזמנים שונים, והן פועלות יחד בתור toolchain כדי לאפשר פרופיל Baseline אופטימלי.

  • פלאגין של Android Gradle: ‏ com.android.tools.build:8.0.0
  • ספריית Macrobenchmark: androidx.benchmark:benchmark-macro-junit4:1.5.0
  • הכלי להתקנת פרופילים: androidx.profileinstaller:profileinstaller:1.4.1

מומלץ להשתמש בגרסה העדכנית של AGP כדי ליצור ולנהל פרופילים של Baseline. אלה הפונקציות העיקריות שכלולות בגרסאות השונות של AGP:

גרסת AGP תכונות
9.1 תמיכה מלאה בספרייה של קבוצת מקורות (מודולים של ספריות): בנוסף לספריות שמותאמות לווריאנטים, אפשר להצהיר על כמה קובצי מקור של פרופיל Baseline עם שם שרירותי, כמו src/free/generated/baselineProfiles/baseline-prof1.txt, במודולים של ספריות ושל אפליקציות.
8.4 התקנות מקומיות של גרסאות build שלא ניתן לנפות בהן באגים באמצעות כלי שורת הפקודה של Gradle wrapper או Android Studio מתקינות פרופילים של Baseline. כך הביצועים של גרסת ה-build המקומית שלכם תואמים יותר לביצועים בסביבת הייצור. העדכון הזה לא משפיע על ביצועי הייצור של הפרופילים של Baseline.
8.3
  • תמיכה חלקית בספרייה של קבוצת מקורות (מודולים של ספריות): אפשר להצהיר על קובצי פרופיל Baseline שמותאמים לווריאנטים, כמו src/free/generated/baselineProfiles/baseline-prof.txt, במודולים של ספריות.
  • פרופילים של Baseline כוללים מחלקות שהוסר מהן סוכר תחבירי.
8.2
  • שכתוב כללים ב-R8:‏ D8 ו-R8 יכולים להמיר כללים קריאים לאנשים בפרופיל ההפעלה ובפרופיל Baseline, כדי לתעד באופן מלא את כל הכללים שנדרשים לכם כדי לשפר את ביצועי האפליקציה. כך אפשר ליצור פרופילים מגרסת build לא ממוזערת ולהחיל אותם על גרסת build להפצה. השיפורים האלה מגדילים את הכיסוי של שיטות בפרופיל Baseline בכ-30% ומשפרים את ביצועי האפליקציה בכ-15%.
  • פרופילים של הפעלה: יוצרים את הסוג הזה של פרופיל Baseline כדי לספק מידע על הפריסה של הקוד ב-DEX. זה משפר את ביצועי ההפעלה בעוד כ-15% או הרבה יותר באפליקציות גדולות.
8.0 הגרסה המומלצת המינימלית: אפשר להשתמש בפלאגין Baseline Profile Gradle כדי ליצור פרופילים של Baseline באמצעות משימת Gradle אחת.
  • תמיכה מלאה בספריית קבצים של מקורות (מודולים של אפליקציות): אפשר להצהיר על כמה קובצי מקור של פרופיל Baseline ולהשתמש בספריות שמותאמות לווריאנטים, כמו src/free/generated/baselineProfiles/baseline-prof1.txt.
7.4 הגרסה המינימלית הנתמכת: אפליקציות יכולות לצרוך פרופילים של Baseline מספריות, ולספק פרופיל Baseline משלהן בקובץ src/main/baseline-prof.txt.
  • הפרופילים של Baseline נארזים בצורה נכונה כשיוצרים את ה-APK מ-App Bundle (בעיה מספר 230361284).
  • באפליקציות עם יותר מקובץ .dex אחד, הפרופילים של Baseline נארזים בצורה נכונה עבור קובץ .dex הראשי.
  • ‫D8 ו-R8 תומכים ביצירת פרופילים להפעלה מגרסה שבה isMinifyEnabled מוגדר ל-false.

הגדרות של מקור הפרופיל עם מודעות לווריאנטים

אם אתם משתמשים בפלאגין של Android Gradle (AGP) בגרסה 8.0 לאפליקציות וב-AGP בגרסה 8.3 לספריות, אתם יכולים להציב כללים של פרופיל Baseline בספרייה ייעודית של קבוצת מקורות, מעבר למגבלות של נתיב קבוע אחד (לדוגמה, src/main/baseline-prof.txt) ולהפעיל כמה קבצים.

כך אפשר להגדיר פרופילי Baseline נפרדים שמותאמים לסוגים ולגרסאות ספציפיים של build (לדוגמה, באמצעות ספריות כמו src/variant/baselineProfiles/), ולוודא שכללי האופטימיזציה של הביצועים מיושמים בצורה מדויקת בכל קובץ בינארי ייחודי של אפליקציה או ספרייה.

דוגמה ליצירת פרופיל

הדוגמה הבאה מציגה מחלקה ליצירת פרופיל Baseline להפעלת אפליקציה, וכן כמה אירועים של ניווט וגלילה באמצעות ספריית Macrobenchmark המומלצת:

class BaselineProfileGenerator {
    @get:Rule
    val baselineProfileRule = BaselineProfileRule()

    @Test
    fun appStartupAndUserJourneys() {
        baselineProfileRule.collect(packageName = PACKAGE_NAME) {
            uiAutomator {
                // App startup journey.
                startApp(PACKAGE_NAME)

                // Find and click elements using the new DSL
                onElement { textAsString() == "COMPOSE LAZYLIST" }.click()
                onElement { viewIdResourceName == "myLazyColumn" }.also {
                    it.fling(Direction.DOWN)
                    it.fling(Direction.UP)
                }
                pressBack()
            }
        }
    }
}

איך כותבים בדיקות אוטומטיות באמצעות UI Automator

אתם יכולים לראות את הקוד הזה בהקשר מלא ובפירוט רב יותר כחלק מדוגמאות הביצועים שלנו ב-GitHub.

הפרטים שצריך לכלול

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

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

ספריות יכולות לספק פרופילים משלהן של Baseline ולשלוח אותם עם גרסאות כדי לשפר את ביצועי האפליקציה. לדוגמה, אפשר לעיין בקטע שימוש בפרופיל Baseline במאמר בנושא ביצועים של Jetpack פיתוח נייטיב.

איך פועלים פרופילים של Baseline

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

  1. כללי פרופיל שקריאים לאנשים נוצרים עבור האפליקציה ומקומפלים לפורמט בינארי. אפשר למצוא אותם ב-assets/dexopt/baseline.prof. לאחר מכן אפשר להעלות את קובץ ה-Android App Bundle‏ (AAB) ל-Google Play כרגיל.

  2. מערכת Google Play מעבדת את הפרופיל ושולחת אותו ישירות למשתמשים יחד עם קובץ ה-APK. במהלך ההתקנה, ART מבצע קימפול AOT של השיטות בפרופיל, וכתוצאה מכך השיטות האלה רצות מהר יותר. אם הפרופיל מכיל שיטות שמשמשות להפעלת האפליקציה או במהלך רינדור של פריים, יכול להיות שזמני ההפעלה יהיו מהירים יותר עם פחות בעיות בממשק (jank).

  3. התהליך הזה פועל לצד צבירת פרופילים של Cloud כדי לשפר את הביצועים על סמך השימוש בפועל באפליקציה לאורך זמן.

תרשים 1. בתרשים הזה מוצג תהליך העבודה של פרופיל Baseline, מההעלאה ועד למסירה למשתמש הקצה, ואיך תהליך העבודה הזה קשור לפרופילים ב-Cloud.

השוואה בין פרופילים של Baseline לפרופילים להפעלה

אתם יכולים להשתמש בפלאגין Baseline Profile Gradle כדי להגדיר וליצור קובצי פרופילים. הפלאגין הזה מתחבר לתהליך ה-build, ו-AGP מקמפל את כללי הפרופיל הקריאים לאנשים לפורמט בינארי – שנארז כ-baseline.prof ב-APK או ב-AAB – ש-ART יכול להשתמש בו ביעילות לקומפילציה במכשיר, בתנאי שהוא קטן מ-1.5MB.

בדרך כלל, קובצי הפרופיל שנוצרים נקראים startup-prof.txt ו-baseline-prof.txt. למרות שהתוכן שלהם לפעמים נראה דומה, במיוחד אם מתמקדים בעיקר בהפעלה, הם משמשים למטרות שונות ומשפיעים על הביצועים בשלבים שונים:

פרופיל Baseline

קובץ פרופיל ה-Baseline מכיל קבוצה מקיפה של כללים שסביבת זמן הריצה ל-Android‏ (ART) משתמשת בהם כדי לקמפל מראש נתיבי קוד שנמצאים בשימוש לעיתים קרובות, וכך לשפר את ביצועי האפליקציה מעבר להפעלה בלבד.

קובץ פרופיל ה-Baseline הוא בדרך כלל קבוצת-על של הכללים שנמצאים בפרופיל ההפעלה. הקובץ הזה כולל את כל הכללים שנדרשים לאופטימיזציה של הפעלת האפליקציה (שנוצרו באמצעות המשימה baselineProfile ב-Gradle), וגם פרופילים נוספים לחוויות שימוש הכרחיות (CUJ) אחרות. לדוגמה, גלילה ומעבר בין מסכים שונים.

הכללים הנוספים האלה, שלא קשורים להפעלה, נוצרים בלי קשר לערך של שדה התצורה includeInStartupProfile.

פרופיל סטארט-אפ

קובץ פרופיל ההפעלה מכיל כללים שעברו אופטימיזציה ספציפית לנתיב ההפעלה של האפליקציה. במהלך ההידור, D8 ממיר את קוד ה-Java לפורמט DEX. לאחר מכן, R8 משתמש בקובץ הזה כדי להשפיע על הפריסה של קובצי ה-DEX, ומוודא שקוד ההפעלה הקריטי ממוקם בקובץ ה-DEX הראשי כדי שההפעלה תהיה מהירה יותר. באופן כללי, כדאי להגדיר את includeInStartupProfile לערך true רק בתרחישי בדיקה שחיוניים לתצוגה הראשונית של האפליקציה. מידע נוסף זמין במאמר יצירת פרופילים של סטארט-אפים.

פרופילים של Cloud

יחד עם פרופילים של Baseline, פרופילים של Cloud מציעים סוג נוסף של PGO – שנצבר על ידי Google Play Store ומופץ לקימפול בזמן ההתקנה.

פרופילים של Cloud מבוססים על אינטראקציות של משתמשים עם האפליקציה בעולם האמיתי. עם זאת, לוקח כמה שעות או ימים אחרי עדכון עד שהם מופצים, ולכן הזמינות שלהם מוגבלת. עד שהפרופילים יופצו באופן מלא, הביצועים לא יהיו אופטימליים באפליקציות חדשות או שעברו עדכון. בנוסף, פרופילים של Cloud תומכים רק במכשירי Android עם Android 9 (רמת API‏ 28) ומעלה, והם מתאימים רק לאפליקציות עם בסיס משתמשים גדול מספיק.

התנהגות הקימפול בגרסאות שונות של Android

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

גרסת Android שיטת הקימפול גישת האופטימיזציה
‫5 עד 6 (רמת API‏ 21 עד 23) ‫AOT מלא האופטימיזציה של האפליקציה מתבצעת במהלך ההתקנה, ולכן זמני ההמתנה לשימוש באפליקציה ארוכים יותר, השימוש בזיכרון ה-RAM ובכונן גדל וזמני הטעינה של הקוד מהדיסק ארוכים יותר. כל אלה עלולים להגדיל את זמני ההפעלה מההתחלה (cold startup).
‫7 עד 8.1 (רמת API‏ 24 עד 27) ‫AOT חלקי (פרופיל Baseline) פרופילים של Baseline מותקנים על ידי androidx.profileinstaller בהפעלה הראשונה, כשהמודול של האפליקציה מגדיר את התלות הזו. ‫ART יכול לשפר את זה עוד יותר על ידי הוספה של כללי פרופיל במהלך השימוש באפליקציה, וקימפול שלהם כשהמכשיר לא פעיל. כך מתבצעת אופטימיזציה של המקום בכונן ושל הזמן שנדרש לטעינת הקוד מהדיסק, וזמן ההמתנה לאפליקציה מתקצר.
‫9 (רמת API‏ 28) ומעלה ‫AOT חלקי (פרופיל Baseline + פרופיל Cloud) ‫Play משתמש בפרופילים של Baseline במהלך התקנות של אפליקציות כדי לבצע אופטימיזציה של חבילות ה-APK ושל פרופילים של Cloud – אם הם זמינים. אחרי ההתקנה, פרופילים של ART מועלים ל-Play, נצברים ומסופקים כפרופילים של Cloud למשתמשים אחרים כשהם מתקינים או מעדכנים את האפליקציה.

בעיות מוכרות

הנה בעיות שיכולות לקרות והפתרונות שלהן, או בעיות שעדיין מתפתחות דרכים לעקוף אותן:

  • יכול להיות שייכשל ניסיון ליצור פרופיל Baseline בגלל הגדרות ההרשאות במכשירים מסוימים, כולל מכשירי OnePlus. כדי לעקוף את הבעיה, משביתים את האפשרות השבתת מעקב אחר הרשאות בהגדרות של אפשרויות למפתחים.

  • כדי לספק פרופילים של Baseline לספריות בהצלחה, צריך להשתמש בתוסף Baseline Profile Gradle בגרסה 1.2.3 או ב-AGP בגרסה 8.3, לכל הפחות (בעיה מספר 313992099).

  • אם יוצרים פרופילים של Baseline באמצעות הפקודה ./gradlew app:generateBaselineProfile, גם נקודות ההשוואה במודול הבדיקה רצות והתוצאות נמחקות. במקרה כזה, אפשר ליצור רק את הפרופילים של Baseline על ידי הפעלת הפקודה עם -P android.testInstrumentationRunnerArguments.androidx.benchmark.enabledRules=BaselineProfile. הבעיה הזו תוקנה ב-AGP 8.2.

  • הפקודה ליצירת פרופילים של Baseline לכל סוגי ה-build‏ – ./gradlew app:generateBaselineProfile – יוצרת פרופילים של Baseline רק לגרסת build להפצה. הבעיה הזו תוקנה ב-AGP 8.1.

  • יכול להיות שערוצי הפצה של אפליקציות שלא נמצאים בחנות Google Play לא יתמכו בשימוש בפרופילים של Baseline בזמן ההתקנה. משתמשים באפליקציות שהותקנו דרך הערוצים האלה לא רואים את היתרונות עד שהתהליך dexopt פועל ברקע – בדרך כלל זה קורה במהלך הלילה.

  • שיתוף פנימי של אפליקציות בחנות Play לא תומך בפרופילים של Baseline, אבל מסלול הבדיקה הפנימית כן תומך.

  • במכשירים מסוימים, כמו מכשירי Huawei, האופטימיזציה של הסוללה יכולה להפריע להתקנת הפרופיל. כדי לוודא שהפרופילים מותקנים בצורה יעילה, צריך להשבית את כל האופטימיזציות של הסוללה במכשירי הבדיקה.

מקורות מידע נוספים

מומלץ בשבילכם
הבא
יצירת פרופילים בסיסיים