פתרון בעיות אופטימיזציה

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

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

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

קריסות של אפליקציה

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

  • אם אתם רואים חריגה, המשמעות היא שהמחלקה, השיטה או השדה שצוינו נמצאים בשימוש באמצעות רפלקציה. החריגים האלה הם בדרך כלל אחד מהערכים הבאים: ClassNotFoundException,‏ NoSuchMethodException,‏ NoSuchFieldException,‏ NoClassDefFoundError,‏ NoSuchMethodError או NoSuchFieldError.
  • אתם רואים קוד שמפנה ל-reflection עם import kotlin.reflect.* או import java.lang.reflect.*.
  • אפשר לראות את הקונסטרוקטור של המחלקה בשימוש באופן הבא: Something::class.constructors.
  • מופיע הכיתוב Class.forName(...).

הפתרון: מוסיפים כלל שמירה.

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

אופטימיזציה לא ברורה או לא מספיקה

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

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

    הפתרון: כדי לבדוק אילו כללים חלים, אפשר לעיין בדוח של כל הכללים ש-R8 מחיל כשבונים את הפרויקט. הדוח הזה נמצא בכתובת ./app/build/outputs/mapping/configuration.txt. הדוח הזה מכיל את כל הכללים הממוזגים מכל ספרייה ומודול ששימשו להגדרת R8, ואפשר להשתמש בו כדי לזהות כללים לא יעילים.

  • יותר מדי קוד נשמר: יכול להיות שהאופטימיזציה של R8 תשמור קוד שציפיתם שיוסר.

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

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

    פתרון: החל מהשקת התכונות ב-Android Studio Otter 3 וב-AGP 9.0,‏ Logcat מבטל באופן אוטומטי את הערפול של דוחות הקריסות. עם זאת, אם אתם משתמשים בגרסה קודמת של Android Studio, אתם צריכים לשחזר באופן ידני את דוח הקריסות המקורי. כדי לשחזר את דוח הקריסות המקורי, משתמשים בכלי שורת הפקודה retrace, שמצורף לחבילה של כלי שורת הפקודה.

    כדי להשתמש ב-retrace, צריך לספק לפקודה את הנתיב לקובץ מיפוי ולקובץ דוח קריסות. קובץ המיפוי, שנקרא mapping.txt, נכלל אוטומטית בקובץ Android App Bundle ‏ (AAB). פרטים נוספים זמינים במסמכי התיעוד של retrace ובמאמר במרכז העזרה של Play Console בנושא פענוח קוד מעורפל (deobfuscate) של דוחות קריסה. כשמשתמשים ב-Play וב-Firebase Crashlytics, משתמשים בקובץ mapping.txt עם נתוני הקריסות שהשירות אוסף ממשתמשי האפליקציה. הפקודה הבאה מראה איך אפשר להריץ את retrace מהשורש של הפרויקט:

    $ANDROID_HOME/cmdline-tools/latest/bin/retrace app/build/outputs/mapping/$releaseVariant/mapping.txt trace.txt

דיווח על באגים

אם אתם לא מצליחים לפתור בעיה ב-R8, אתם יכולים לדווח על באג.