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

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

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

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

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

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

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

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

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

פרופילים של סטארט-אפים דומים לפרופילים Baseline, אבל ההבדל הוא שהם משמשים בזמן הידור ולא לאופטימיזציה במכשיר. פרופיל ההפעלה משמש לאופטימיזציה של הפריסה של קובץ ה-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.4
• מנהל ההתקנה של הפרופיל: 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 Profiles כדי לשפר את הביצועים על סמך השימוש בפועל באפליקציה לאורך זמן.

Cloud Profiles

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

פרופילי 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 לא יתמכו בשימוש בפרופילים בסיסיים בזמן ההתקנה. משתמשים באפליקציות שהותקנו דרך הערוצים האלה לא יראו את היתרונות עד שתתבצע פעולת dexopt ברקע – סביר להניח שהיא תתבצע במהלך הלילה.

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

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

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

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