ב-Tinder הפחיתו את ההפעלות האיטיות במצב התחלתי (cold start) ב-47% באמצעות הכלי החדש לניתוח הגדרות R8

המטרה של טינדר היא לעודד ולעורר השראה ליצירת קשרים אמיתיים, על ידי הפיכת המפגש לקל ומהנה לכל דור חדש של רווקים ורווקות. עם זאת, ככל שבסיס הקוד של האפליקציה ל-Android גדל, כך גם המורכבות שלו גדלה. לפני מאמצי האופטימיזציה האחרונים, כ-70% מהאפליקציה לא עברו אופטימיזציה, והיו בה 17 קובצי dex,כולל שלושה שהוקדשו רק להפעלה. למרות שהם הפעילו את R8, חלק גדול מפוטנציאל האופטימיזציה שלו נחסם בגלל כללי שמירה, והצוות לא הצליח לזהות אילו כללים ספציפיים מנעו את האופטימיזציה. כדי לקצר את זמן ההפעלה ולהפחית את מספר השגיאות מסוג "האפליקציה לא מגיבה" (ANR) שהמשתמשים חווים, טינדר השתמשה בכלי החדש R8 Configuration Analyzer כדי להתמודד עם האתגרים האלה.

בעזרת R8 Configuration Analyzer, טינדר זיהתה והסירה בהצלחה חסימות לא מכוונות של אופטימיזציה. התוצאות היו מיידיות ומשמעותיות: בטינדר הצליחו להפחית ב-47% את ההפעלות במצב התחלתי (cold start) של האפליקציה, להקטין את גודל ההורדה של האפליקציה ב-28.98% (ל-61.5MB) ולהפחית ב-28% את מקרי ה-ANR שהשפיעו על המשתמשים.

ניתוח הגדרות 

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

המדדים העיקריים שמוצגים בכלי לניתוח ההגדרות כוללים:

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

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

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

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

זיהוי גורמים נסתרים שמונעים אופטימיזציה

לפני שילוב R8 Configuration Analyzer, אפליקציית Tinder ל-Android סבלה מחוב טכני משמעותי בגלל בסיס קוד לא אופטימלי. היעדר האופטימיזציה הזה פגע ישירות בחוויית המשתמש, וגרם למשתמשים לחוות הפעלות איטיות במצב התחלתי (cold start). 

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

# Prevents optimization in all public classes along with all of their public and protected members

-keep public class * {
    public protected *;
}

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

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

• טעינה מהירה יותר: הצוות הצליח להפחית ב-47% את מספר המשתמשים שחוו הפעלה איטית במצב התחלתי (cold start) של האפליקציה.
• נפח קטן יותר: גודל ההורדה של האפליקציה ירד מ-86.6MB ל-61.5MB (ירידה של 28.98%).
• יציבות משופרת: שיעור השגיאות מסוג "האפליקציה לא מגיבה" (ANR) שהשפיעו על המשתמשים ירד מ-0.35% ל-0.28%, והתקרב משמעותית למספרים החציוניים של קבוצת ההשוואה.
• פחות מורכבות: המספר הכולל של קובצי DEX צומצם מ-17 ל-11, כולל שני קובצי הפעלה בלבד.

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

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

הגנה על הביצועים העתידיים באמצעות אינטגרציה רציפה (CI)

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

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

מסקנות עיקריות

בגלל בסיס קוד לא אופטימלי ומספר גדול של קובצי DEX, ב-Tinder היו צריכים דרך לבדוק בצורה נקייה את כללי המזעור של האפליקציה. הכלי R8 Configuration Analyzer סיפק את הכלים האידיאליים לזיהוי כללים רחבים מדי של ספריות פנימיות, את המחלקות שהושפעו מהכלל keep, ואפשר לצוות לבצע אופטימיזציה של בסיס הקוד שלהם בביטחון. כתוצאה מכך, הצוות של טינדר הצליח לצמצם את ההפעלות במצב התחלתי בכמעט חצי, להקטין את גודל ה-APK ביותר מ-28% וליצור בסיס בריא יותר עם ביצועים טובים יותר למשתמשים. הצוות ממשיך לפעול באופן פעיל כדי לשפר את הנתונים האלה עוד יותר.

איך משתמשים ב-R8 Configuration Analyzer

אתם יכולים להשתמש ב-R8 Configuration Analyzer ובתכונות העצמאיות שלו בהתאם לגרסה הנוכחית של Android Gradle Plugin (AGP):

1. גרסת AGP 9.3: הכלי לניתוח הגדרות אישיות של R8 משולב באופן מלא וזמין בגרסת AGP 9.3. כשמריצים גרסת build להפצה של R8, הדוח נוצר בתיקייה `build/outputs/mapping/release/configanalyzer.html`.

2. משימת Gradle עצמאית: ב-AGP 9.3 יש משימת Gradle עצמאית שמאפשרת ליצור את דוח הניתוח בלי להריץ גרסת build מלאה להפצה. כך מקבלים משוב מהיר יותר כשמשפרים את כללי השמירה באופן מקומי:

./gradlew :app:analyzeReleaseR8Config

הדוח נוצר בכתובת build/reports/r8/r8-config-analyzer-release.html.

3. שימוש בגרסאות ישנות יותר של AGP: אם אתם משתמשים בגרסה ישנה יותר של AGP, אתם לא צריכים להעביר את כל גרסת ה-AGP כדי לנתח את ההגדרות האישיות. אתם יכולים לעדכן את גרסת R8 באופן עצמאי ל-9.3.7-dev ואילך לפי ההוראות להחלפת R8 ב-AGP. כדי ליצור את הדוח באופן מקומי, מריצים את ה-build עם המאפיין שצוין:

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

מידע נוסף זמין במסמכי התיעוד של R8 Configuration Analyzer.