פרופילים בסיסיים של ניפוי באגים

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

בעיות בבנייה

אם העתקתם את הדוגמה של פרופילים של Baseline באפליקציית הדוגמה Now in Android, יכול להיות שתיתקלו בכשלים בבדיקה במהלך המשימה של פרופיל Baseline, עם הודעה שלא ניתן להריץ את הבדיקות באמולטור:

./gradlew assembleDemoRelease
Starting a Gradle Daemon (subsequent builds will be faster)
Calculating task graph as no configuration cache is available for tasks: assembleDemoRelease
Type-safe project accessors is an incubating feature.

> Task :benchmarks:pixel6Api33DemoNonMinifiedReleaseAndroidTest
Starting 14 tests on pixel6Api33

com.google.samples.apps.nowinandroid.foryou.ScrollForYouFeedBenchmark > scrollFeedCompilationNone[pixel6Api33] FAILED
        java.lang.AssertionError: ERRORS (not suppressed): EMULATOR
        WARNINGS (suppressed):
        ...

הכשלים מתרחשים כי האפליקציה Now in Android משתמשת במכשיר בניהול Gradle כדי ליצור פרופיל Baseline. הכשלים צפויים, כי בדרך כלל לא מומלץ להריץ בדיקות השוואה של ביצועים באמולטור. עם זאת, מכיוון שאתם לא אוספים מדדי ביצועים כשאתם יוצרים פרופילים של Baseline, אתם יכולים להריץ איסוף של פרופילים של Baseline באמולטורים כדי שיהיה לכם נוח. כדי להשתמש בפרופילים של Baseline עם אמולטור, מבצעים את ה-build וההתקנה משורת הפקודה ומגדירים ארגומנט להפעלת הכללים של פרופילים של Baseline:

installDemoRelease -Pandroid.testInstrumentationRunnerArguments.androidx.benchmark.enabledRules=BaselineProfile

אפשר גם ליצור הגדרת הפעלה מותאמת אישית ב-Android Studio כדי להפעיל פרופילי Baseline באמולטורים. לשם כך, בוחרים באפשרות Run > Edit Configurations (הפעלה > עריכת הגדרות):

הוספת הגדרת הרצה בהתאמה אישית כדי ליצור פרופילים של Baseline באפליקציה Now in Android
איור 1. מוסיפים הגדרת הרצה מותאמת אישית כדי ליצור פרופילי Baseline באפליקציה Now in Android.

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

כדי לוודא שקובץ ה-APK או קובץ ה-Android App Bundle (AAB) שאתם בודקים הם מגרסת build שכוללת פרופילי Baseline, מבצעים את הפעולות הבאות:

  1. ב-Android Studio, בוחרים באפשרות Build > Analyze APK (גרסה Build > ניתוח APK).
  2. פותחים את קובץ ה-AAB או ה-APK.

  3. מוודאים שהקובץ baseline.prof קיים:

    • אם בודקים קובץ AAB, הפרופיל נמצא בנתיב /BUNDLE-METADATA/com.android.tools.build.profiles/baseline.prof.

    • אם בודקים קובץ APK, הפרופיל נמצא בנתיב /assets/dexopt/baseline.prof.

      הנוכחות של הקובץ הזה היא הסימן הראשון לכך שתצורת ה-build נכונה. אם הוא חסר, המשמעות היא ש-Android Runtime לא יקבל הוראות קדם-קומפילציה בזמן ההתקנה.

      בדיקה אם יש פרופיל Baseline באמצעות הכלי APK Analyzer ב-Android Studio
      איור 2. בודקים אם יש פרופיל Baseline באמצעות הכלי לניתוח APK ב-Android Studio.

צריך לקמפל פרופילים של Baseline במכשיר שבו האפליקציה פועלת. כשמתקינים גרסאות build שלא ניתן לנפות בהן באגים באמצעות Android Studio או כלי שורת הפקודה של Gradle wrapper, הקומפילציה במכשיר מתבצעת באופן אוטומטי. אם מתקינים את האפליקציה מחנות Google Play, פרופילי הבסיס עוברים קומפילציה במהלך עדכוני המכשיר ברקע ולא בזמן ההתקנה. כשהאפליקציה מותקנת באמצעות כלים אחרים, ספריית Jetpack ProfileInstaller אחראית להוספת הפרופילים לתור לצורך קומפילציה במהלך תהליך האופטימיזציה הבא של DEX ברקע.

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

Kotlin

private const val TAG = "MainActivity"

class MainActivity : ComponentActivity() {
  ...
  override fun onResume() {
    super.onResume()
    lifecycleScope.launch {
      logCompilationStatus()
    }
  }

  private suspend fun logCompilationStatus() {
     withContext(Dispatchers.IO) {
        val status = ProfileVerifier.getCompilationStatusAsync().await()
        when (status.profileInstallResultCode) {
            RESULT_CODE_NO_PROFILE ->
                Log.d(TAG, "ProfileInstaller: Baseline Profile not found")
            RESULT_CODE_COMPILED_WITH_PROFILE ->
                Log.d(TAG, "ProfileInstaller: Compiled with profile")
            RESULT_CODE_PROFILE_ENQUEUED_FOR_COMPILATION ->
                Log.d(TAG, "ProfileInstaller: Enqueued for compilation")
            RESULT_CODE_COMPILED_WITH_PROFILE_NON_MATCHING ->
                Log.d(TAG, "ProfileInstaller: App was installed through Play store")
            RESULT_CODE_ERROR_PACKAGE_NAME_DOES_NOT_EXIST ->
                Log.d(TAG, "ProfileInstaller: PackageName not found")
            RESULT_CODE_ERROR_CACHE_FILE_EXISTS_BUT_CANNOT_BE_READ ->
                Log.d(TAG, "ProfileInstaller: Cache file exists but cannot be read")
            RESULT_CODE_ERROR_CANT_WRITE_PROFILE_VERIFICATION_RESULT_CACHE_FILE ->
                Log.d(TAG, "ProfileInstaller: Can't write cache file")
            RESULT_CODE_ERROR_UNSUPPORTED_API_VERSION ->
                Log.d(TAG, "ProfileInstaller: Enqueued for compilation")
            else ->
                Log.d(TAG, "ProfileInstaller: Profile not compiled or enqueued")
        }
    }
}

Java

public class MainActivity extends ComponentActivity {

    private static final String TAG = "MainActivity";

    @Override
    protected void onResume() {
        super.onResume();

        logCompilationStatus();
    }

    private void logCompilationStatus() {
         ListeningExecutorService service = MoreExecutors.listeningDecorator(
                Executors.newSingleThreadExecutor());
        ListenableFuture<ProfileVerifier.CompilationStatus> future =
                ProfileVerifier.getCompilationStatusAsync();
        Futures.addCallback(future, new FutureCallback<>() {
            @Override
            public void onSuccess(CompilationStatus result) {
                int resultCode = result.getProfileInstallResultCode();
                if (resultCode == RESULT_CODE_NO_PROFILE) {
                    Log.d(TAG, "ProfileInstaller: Baseline Profile not found");
                } else if (resultCode == RESULT_CODE_COMPILED_WITH_PROFILE) {
                    Log.d(TAG, "ProfileInstaller: Compiled with profile");
                } else if (resultCode == RESULT_CODE_PROFILE_ENQUEUED_FOR_COMPILATION) {
                    Log.d(TAG, "ProfileInstaller: Enqueued for compilation");
                } else if (resultCode == RESULT_CODE_COMPILED_WITH_PROFILE_NON_MATCHING) {
                    Log.d(TAG, "ProfileInstaller: App was installed through Play store");
                } else if (resultCode == RESULT_CODE_ERROR_PACKAGE_NAME_DOES_NOT_EXIST) {
                    Log.d(TAG, "ProfileInstaller: PackageName not found");
                } else if (resultCode == RESULT_CODE_ERROR_CACHE_FILE_EXISTS_BUT_CANNOT_BE_READ) {
                    Log.d(TAG, "ProfileInstaller: Cache file exists but cannot be read");
                } else if (resultCode
                        == RESULT_CODE_ERROR_CANT_WRITE_PROFILE_VERIFICATION_RESULT_CACHE_FILE) {
                    Log.d(TAG, "ProfileInstaller: Can't write cache file");
                } else if (resultCode == RESULT_CODE_ERROR_UNSUPPORTED_API_VERSION) {
                    Log.d(TAG, "ProfileInstaller: Enqueued for compilation");
                } else {
                    Log.d(TAG, "ProfileInstaller: Profile not compiled or enqueued");
                }
            }

            @Override
            public void onFailure(Throwable t) {
                Log.d(TAG,
                        "ProfileInstaller: Error getting installation status: " + t.getMessage());
            }
        }, service);
    }
}

קודי התוצאות הבאים מספקים רמזים לגבי הסיבה לחלק מהבעיות:

RESULT_CODE_COMPILED_WITH_PROFILE
הפרופיל מותקן, עובר קומפילציה ומשמש בכל פעם שמפעילים את האפליקציה. זו התוצאה שרוצים לראות.
RESULT_CODE_ERROR_NO_PROFILE_EMBEDDED
לא נמצא פרופיל בקובץ ה-APK שמופעל. אם השגיאה הזו מופיעה, צריך לוודא שמשתמשים בגרסת build שכוללת פרופילים של Baseline, ושחבילת ה-APK מכילה פרופיל.
RESULT_CODE_NO_PROFILE
לא הותקן פרופיל לאפליקציה הזו כשמתקינים את האפליקציה דרך חנות האפליקציות או מנהל החבילות. הסיבה העיקרית לשגיאה עם קוד השגיאה הזה היא שהפרופיל המתקין לא פעל כי ProfileInstallerInitializer הושבת. שימו לב: כשמדווחת השגיאה הזו, עדיין נמצא פרופיל מוטמע ב-APK של האפליקציה. אם פרופיל מוטמע לא נמצא, קוד השגיאה שמוחזר הוא RESULT_CODE_ERROR_NO_PROFILE_EMBEDDED.
RESULT_CODE_PROFILE_ENQUEUED_FOR_COMPILATION
פרופיל נמצא ב-APK או ב-AAB והוא מתווסף לתור של ההידור. כשפרופיל מותקן על ידי ProfileInstaller, הוא מתווסף לתור של ההידור בפעם הבאה שהמערכת מריצה אופטימיזציה של DEX ברקע. הפרופיל לא פעיל עד שהקומפילציה מסתיימת. אל תנסו להשוות את פרופילי הבסיס שלכם עד שהקומפילציה תושלם. יכול להיות שתצטרכו לכפות קומפילציה של פרופילי בסיס. השגיאה הזו לא תתרחש כשהאפליקציה מותקנת מ-Play Store או ממנהל החבילות במכשירים עם Android מגרסה 9 (API 28) ואילך, כי הקומפילציה מתבצעת במהלך ההתקנה.
RESULT_CODE_COMPILED_WITH_PROFILE_NON_MATCHING
פרופיל לא תואם מותקן והאפליקציה עוברת קומפילציה איתו. התוצאה הזו מתקבלת מהתקנה דרך חנות Google Play או מנהל החבילות. שימו לב שהתוצאה הזו שונה מ-RESULT_CODE_COMPILED_WITH_PROFILE כי הפרופיל שלא תואם יקמפל רק את השיטות שעדיין משותפות בין הפרופיל לבין האפליקציה. הפרופיל קטן יותר מהצפוי, ופחות שיטות יקומפלו מאלה שנכללו בפרופיל Baseline.
RESULT_CODE_ERROR_CANT_WRITE_PROFILE_VERIFICATION_RESULT_CACHE_FILE
ל-
ProfileVerifier אין הרשאת כתיבה לקובץ המטמון של תוצאות האימות. יכול להיות שמשהו לא בסדר בהרשאות של תיקיית האפליקציה, או שאין מספיק מקום אחסון פנוי במכשיר.
RESULT_CODE_ERROR_UNSUPPORTED_API_VERSION
‫
ProfileVerifieris running on an unsupported API version of Android. ProfileVerifier תומך רק ב-Android 9 (רמת API‏ 28) ומעלה.
RESULT_CODE_ERROR_PACKAGE_NAME_DOES_NOT_EXIST
‫
PackageManager.NameNotFoundException מופעל כשמבצעים שאילתה ב-PackageManager לגבי חבילת האפליקציה. זה אמור לקרות לעיתים רחוקות. מנסים להסיר את האפליקציה ולהתקין מחדש את הכול.
RESULT_CODE_ERROR_CACHE_FILE_EXISTS_BUT_CANNOT_BE_READ
קיים קובץ מטמון של תוצאת אימות קודמת, אבל אי אפשר לקרוא אותו. זה אמור לקרות לעיתים רחוקות. כדאי לנסות להסיר את האפליקציה ולהתקין מחדש את הכול.

שימוש ב-ProfileVerifier בסביבת ייצור

בסביבת ייצור, אפשר להשתמש ב-ProfileVerifier בשילוב עם ספריות דיווח על ניתוח נתונים, כמו Google Analytics for Firebase, כדי ליצור אירועים של ניתוח נתונים שמציינים את סטטוס הפרופיל. לדוגמה, אם תצא גרסה חדשה של אפליקציה שלא מכילה פרופילים בסיסיים, תקבלו על כך התראה במהירות.

אכיפת קומפילציה של פרופילים של Baseline

אם סטטוס הקימפול של פרופילים של Baseline הוא RESULT_CODE_PROFILE_ENQUEUED_FOR_COMPILATION, אפשר לכפות קימפול מיידי באמצעות adb:

adb shell cmd package compile -r bg-dexopt PACKAGE_NAME

בדיקת מצב ההידור של פרופיל Baseline בלי ProfileVerifier

אם אתם לא משתמשים ב-ProfileVerifier, אתם יכולים לבדוק את מצב הקומפילציה באמצעות adb, אבל לא תקבלו תובנות מעמיקות כמו ב-ProfileVerifier:

adb shell dumpsys package dexopt | grep -A 2 PACKAGE_NAME

השימוש ב-adb יפיק פלט שדומה לזה:

  [com.google.samples.apps.nowinandroid.demo]
    path: /data/app/~~dzJiGMKvp22vi2SsvfjkrQ==/com.google.samples.apps.nowinandroid.demo-7FR1sdJ8ZTy7eCLwAnn0Vg==/base.apk
      arm64: [status=speed-profile] [reason=bg-dexopt] [primary-abi]
        [location is /data/app/~~dzJiGMKvp22vi2SsvfjkrQ==/com.google.samples.apps.nowinandroid.demo-7FR1sdJ8ZTy7eCLwAnn0Vg==/oat/arm64/base.odex]

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

סטטוס ההידור משמעות
speed‑profile קיים פרופיל משולב והוא נמצא בשימוש.
verify לא קיים פרופיל שעבר קומפילציה.

סטטוס verify לא אומר שקובץ ה-APK או ה-AAB לא מכיל פרופיל, כי יכול להיות שהוא ממתין בתור להידור על ידי המשימה הבאה של אופטימיזציה של DEX ברקע.

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

סיבה משמעות
install‑dm פרופיל Baseline עבר קימפול באופן ידני או על ידי Google Play בזמן התקנת האפליקציה.
bg‑dexopt פרופיל נאסף בזמן שהמכשיר לא היה פעיל. יכול להיות שזה פרופיל Baseline, או פרופיל שנאסף במהלך השימוש באפליקציה.
cmdline הקומפילציה הופעלה באמצעות adb. יכול להיות שזה פרופיל Baseline, או פרופיל שנאסף במהלך השימוש באפליקציה.

אימות של פרופיל הפעלה באפליקציה ל-DEX ול-r8.json

כללי פרופיל ההפעלה משמשים את R8 בזמן ה-build כדי לבצע אופטימיזציה של פריסת המחלקות בקובצי ה-DEX. האופטימיזציה הזו בזמן הבנייה שונה מהאופן שבו נעשה שימוש בפרופילים של Baseline (baseline.prof), כי הם נארזים בתוך ה-APK או ה-AAB כדי ש-ART יבצע קימפול במכשיר. הכללים של פרופיל ההפעלה מוחלים במהלך תהליך הבנייה עצמו, ולכן אין קובץ startup.prof נפרד בתוך קובץ ה-APK או ה-AAB שאפשר לבדוק. ההשפעה של פרופילים להפעלה ניכרת בפריסה של קובץ ה-DEX.

בדיקת סידור ה-DEX באמצעות r8.json (מומלץ ל-AGP בגרסה 8.8 ואילך)

בפרויקטים שמשתמשים ב-Android Gradle Plugin ‏ (AGP) בגרסה 8.8 ואילך, אפשר לבדוק אם פרופיל ההפעלה הוחל על ידי בדיקת הקובץ r8.json שנוצר. הקובץ הזה נארז בתוך קובץ ה-AAB.

  1. פותחים את ארכיון ה-AAB ומאתרים את הקובץ r8.json.
  2. מחפשים בקובץ את המערך dexFiles שבו מפורטים קובצי ה-DEX שנוצרו.

  3. מחפשים אובייקט dexFiles שמכיל את צמד המפתח/ערך "startup": true. השורה הזו מציינת במפורש שהכללים של פרופיל ההפעלה הוחלו כדי לבצע אופטימיזציה של הפריסה של קובץ ה-DEX הספציפי הזה.

    "dexFiles": [
 {
   "checksum": "...",
   "startup": true // This flag confirms profile application to this DEX file
 },
 // ... other DEX files
]

בדיקת סידור DEX בכל הגרסאות של AGP

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

  1. פותחים את קובץ ה-AAB או ה-APK באמצעות Build > Analyze APK ב-Android Studio.
  2. עוברים לקובץ ה-DEX הראשון. לדוגמה, classes.dex.
  3. בודקים את התוכן של קובץ ה-DEX הזה. אפשר לוודא שהשיטות והמחלקות הקריטיות שהוגדרו בקובץ פרופיל ההפעלה (startup-prof.txt) מופיעות בקובץ ה-DEX הראשי הזה. הגשת בקשה מוצלחת פירושה שהרכיבים הקריטיים להפעלה מקבלים עדיפות לטעינה מהירה יותר.

בעיות שקשורות לביצועים

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

השוואה נכונה לשוק של מדדי סטארט-אפ

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

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

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

כדי שהאפליקציה תהיה רספונסיבית, חשוב להקפיד על ערכים נמוכים ככל האפשר של TTID ו-TTFD.

המערכת יכולה לזהות את ה-TTID, להציג אותו ב-Logcat ולדווח עליו כחלק מהמדדים של זמן ההפעלה. עם זאת, המערכת לא יכולה לקבוע את ערך ה-TTFD, והאפליקציה אחראית לדווח מתי היא מגיעה למצב אינטראקטיבי שבו כל הרכיבים מוצגים. כדי לעשות את זה, מתקשרים אל reportFullyDrawn() או אל ReportDrawn אם משתמשים ב-Jetpack Compose. אם יש לכם כמה משימות ברקע שצריכות להסתיים לפני שהאפליקציה נחשבת ככזו שמוצגת באופן מלא, אתם יכולים להשתמש ב-FullyDrawnReporter, כמו שמתואר במאמר שיפור הדיוק של תזמון ההפעלה.

פרופילים של ספרייה ופרופילים מותאמים אישית

כשמשווים את ההשפעה של פרופילים, יכול להיות שיהיה קשה להפריד בין היתרונות של הפרופילים של האפליקציה לבין פרופילים שנוספו על ידי ספריות, כמו ספריות Jetpack. כשיוצרים את קובץ ה-APK, הפלאגין של Android Gradle מוסיף את כל הפרופילים בתלויות של הספריות, וגם את הפרופיל המותאם אישית. האפשרות הזו טובה לאופטימיזציה של הביצועים הכוללים, ומומלצת לגרסאות של האפליקציה שמוכנות להפצה. עם זאת, קשה למדוד את שיפור הביצועים הנוסף שמתקבל מהפרופיל המותאם אישית.

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

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

Kotlin

android {
  ...
  buildTypes {
    ...
    // Release build with only library profiles.
    create("releaseWithoutCustomProfile") {
      initWith(release)
    }
    ...
  }
  ...
}
...
dependencies {
  ...
  // Remove the baselineProfile dependency.
  // baselineProfile(project(":baselineprofile"))
}

baselineProfile {
  variants {
    create("release") {
      from(project(":baselineprofile"))
    }
  }
}

Groovy

android {
  ...
  buildTypes {
    ...
    // Release build with only library profiles.
    releaseWithoutCustomProfile {
      initWith(release)
    }
    ...
  }
  ...
}
...
dependencies {
  ...
  // Remove the baselineProfile dependency.
  // baselineProfile ':baselineprofile"'
}

baselineProfile {
  variants {
    release {
      from(project(":baselineprofile"))
    }
  }
}

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

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

Kotlin

android {
  ...
    buildTypes {
      ...
      // Release build with only library profiles.
      create("releaseWithoutCustomProfile") {}
      ...
    }
  ...
}

Groovy

android {
  ...
    buildTypes {
      ...
      // Release build with only library profiles.
      releaseWithoutCustomProfile {}
      ...
    }
  ...
}

כשמריצים את ההשוואה מ-Android Studio, בוחרים בווריאנט releaseWithoutCustomProfile כדי למדוד את הביצועים רק עם פרופילים של ספריות, או בווריאנט release כדי למדוד את הביצועים עם פרופילים של ספריות ופרופילים מותאמים אישית.

איך להימנע מהפעלה של אפליקציה שמוגבלת על ידי קלט/פלט

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

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

אם האפליקציה שלכם משתמשת ב-Hilt, אתם יכולים לספק הטמעות מזויפות של פעולות שקשורות לקלט/פלט כשאתם מבצעים השוואה בין ביצועים בMicrobenchmark וב-Hilt.

כיסוי כל התהליכים החשובים שעוברים המשתמשים

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

שינויים בפרופיל בזמן הידור בבדיקת A/B

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

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

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