שימוש בכלי לניתוח ההגדרות של R8

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

יצירת הדוח

ב-AGP בגרסה 9.3.0 ואילך, אפשר ליצור את הדוח R8 Configuration Analyzer באמצעות משימת Gradle ייעודית ועצמאית, או באופן אוטומטי במהלך בניית R8.

להריץ את משימת Gradle העצמאית (מומלץ לשימוש מקומי)

כשמבצעים איטרציות פעילות על כללי השמירה, כדאי להשתמש במשימת Gradle עצמאית כדי להעריך במהירות את ההשפעה של השינויים בלי לבנות את ה-APK או ה-Bundle באופן מלא:

./gradlew :app:analyzeReleaseR8Config

מכיוון שהמשימה הזו מדלגת על יצירת APK או Bundle, היא מספקת לולאת משוב קצרה בהרבה. כך תוכלו לנתח במהירות את ההשפעה של כללי השמירה על ציוני הצמצום, האופטימיזציה וההסתרה, ולשפר אותם באופן מיידי. דוח ה-HTML נוצר בנתיב app/build/reports/r8/r8-config-analyzer-release.html.

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

כשמריצים גרסת build מלאה של R8 (למשל assembleRelease), הדוח נוצר אוטומטית ב-build/outputs/mapping/release/configanalyzer.html. כדי להשבית את היצירה האוטומטית של הפלט במהלך בנייה רגילה, מגדירים את מאפיין Gradle הבא:

android.experimental.r8.enableR8ConfigurationAnalyzer=false

ב-AGP מגרסה 9.2 ומטה

ב-AGP 9.2 ובגרסאות קודמות, צריך להגדיר את מאפיין המערכת com.android.tools.r8.dumpkeepradiushtmltodirectory כשמריצים משימת Gradle עם build שמופעל באמצעות R8.

./gradlew assembleRelease \
    -Dcom.android.tools.r8.dumpkeepradiushtmltodirectory=<output_directory>

לדוגמה, משתמשים בפקודה הבאה כדי ליצור את דוח ה-HTML בספרייה /tmp/r8analysis:

# To create the /tmp/r8analysis folder.
mkdir -p /tmp/r8analysis

# To generate the report in the /tmp/r8analysis folder.
./gradlew assembleRelease \
    -Dcom.android.tools.r8.dumpkeepradiushtmltodirectory=/tmp/r8analysis

הסבר על הדוח

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

דוגמה לקטע סיכום הדוח
איור 1. דוגמה לקטע סיכום הדוח.

ציון הכיווץ

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

ציון האופטימיזציה

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

ציון ערפול הקוד (obfuscation)

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

שיפור כללי השמירה

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

כדי לעשות את זה, משתמשים בניתוח כללי השמירה.

דוגמה לניתוח של כלל שמירה
איור 2. דוגמה לניתוח של כלל השמירה.

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

דוגמה לניתוח של כלל שמירה
איור 3. דוגמה לניתוח של כלל השמירה.

איך משפרים את כללי השמירה

כדי לשפר את כללי השמירה ולממש את מלוא הפוטנציאל של האופטימיזציות של R8 באפליקציה, צריך לבצע את הפעולות הבאות:

  1. בכלי Configuration Analyzer, בכל כלל שמירה מוצג אחוז המחלקות, השדות והשיטות שלא ניתן לבצע להם אופטימיזציה באמצעות R8. אפשר להשתמש בזה כדי לזהות את כללי השמירה שמונעים אופטימיזציה במספר גדול של מחלקות, שדות או שיטות. מוצגים גם נכסי האופטימיזציה שנמנעו על ידי כל כלל שמירה.
  2. אם אתם רואים כלל keep שמונע אופטימיזציה של מספר גדול של מחלקות, כדאי לבדוק אילו מחלקות, שדות ושיטות לא עוברים אופטימיזציה בגלל כלל ה-keep, כדי לראות אם הכלל הזה שומר על פריטים שלא מופעלים באופן דינמי באמצעות reflection.
  3. כדי לצמצם את האופטימיזציה שנחסמת על ידי כללי השמירה, צריך לטרגט רק את המחלקות, השדות או השיטות הנדרשים על ידי בחירת אפשרות השמירה הנכונה ופעולה לפי השיטות המומלצות.
  4. בודקים ומריצים בדיקות שכוללות את המחלקות, השדות והשיטות המושפעים של כלל השמירה, ומשפרים את כללי השמירה.

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

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

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

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

כדי לפתור בעיות שקשורות לכללי שמירה שהוצגו על ידי ספריות צד שלישי:

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

כללים שנכללים בכללים אחרים

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

# Prevents optimization in the entire package
# Remove this to improve optimization
-keep class com.example.package.** { *; }

# Prevents optimization to the class inside the package
-keep class com.example.package.Myclass

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

דוגמה לקטע סיכום הדוח
איור 4. דוגמה לכללים שנכללים בדוח.

אופטימיזציה של כללים שנכללים בכללים אחרים

  1. אפשר למצוא את כללי השמירה שכוללים כללים אחרים באמצעות הכלי R8 Configuration Analyzer.
  2. מזהים את המחלקות, השדות או השיטות המדויקים בבסיס הקוד שבאמת מסתמכים על רפלקציה, וצריך לשמור אותם באמצעות כללי שמירה. המידע הזה יעזור לכם לשפר את כללי השמירה.
  3. בעזרת כלי הניתוח של ההגדרות, אפשר להשוות את ההשפעה של כל כלל שמטרגט את אותם מחלקות, שדות או שיטות. אפשר להשתמש באחוז האופטימיזציה שנמנע על ידי כל כלל שמירה כדי לזהות איזה כלל הוא רחב יותר ואיזה כלל הוא צר יותר.
    1. אם הכלל המצומצם נכתב במדויק – רק חברי הקבוצה או הסיווגים המדויקים שמתבצעת אליהם גישה רפלקטיבית נשמרים – צריך להסיר את כלל השמירה הרחב יותר. כך תוכלו להפעיל בבטחה אופטימיזציות של R8 בשאר החבילה.
    2. אם הכלל הרחב מטַרגט את המחלקות הנכונות, כדאי להשאיר את הכלל הרחב ולמחוק את הכלל המצומצם. הכלל המצומצם הוא רק עומס מיותר. חשוב לדייק את הכלל הרחב כדי לטרגט רק מחלקות, שדות או שיטות שזיהיתם.

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

הסרת כללים מיותרים

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

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

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