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

פרופילים בסיסיים משפרים את מהירות ביצוע הקוד בכ-30% מהפעלה הראשונה, על ידי הימנעות משלב הפרשנות ומשלבי ההידור בדיוק בזמן (JIT) של נתיבים של קוד שכלולים.

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

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

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

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

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

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

פרופילים של חברות סטארט-אפ

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

שנתחיל?

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

הגרסאות היציבות המומלצות המינימליות

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

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

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

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

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

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

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

            device.findObject(By.text("COMPOSE LAZYLIST")).clickAndWait(Until.newWindow(), 1_000)
            device.findObject(By.res("myLazyColumn")).also {
                it.fling(Direction.DOWN)
                it.fling(Direction.UP)
            }
            device.pressBack()
        }
    }
}

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

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

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

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

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

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

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

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

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

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

פרופילים ב-Cloud

פרופילים ב-Cloud מציעים צורה נוספת של PGO – שמצטברים על ידי חנות Google Play ומופצים להידור של זמן ההתקנה – יחד עם פרופילים בסיסיים.

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

התנהגות ההידור בגרסאות Android שונות

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

בעיות מוכרות

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

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

• אי אפשר ליצור פרופיל בסיס במכשירי Firebase Test Lab, כולל במכשירי Test Lab בניהול Gradle‏ (בעיה מס' 285187547).

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

• אם יוצרים פרופילים בסיסיים באמצעות הפקודה ./gradlew app:generateBaselineProfile, גם אמות המידה במודול הבדיקה מופעלות והתוצאות מושמטות. במקרה כזה, תוכלו ליצור רק את הפרופילים הבסיסיים על ידי הפעלת הפקודה עם -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 לא תומך בפרופילים בסיסיים, אבל מסלול הבדיקה הפנימית כן תומך בהם.

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

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

• אופטימיזציות של פריסה ב-DEX ופרופילים של הפעלה