אופטימיזציה של קוד DEX היא ממצא של תפקוד האפליקציה שעוזר לכם לעקוב אחרי איכות ההידור, הגודל והביצועים של האפליקציה ולשפר אותם. אופטימיזציה וערפול קוד (obfuscation) באמצעות R8 או כלים חלופיים (כמו כלים לאופטימיזציה שתואמים ל-ProGuard או מעבדי DEX משניים) מקטינים את גודל ה-DEX של האפליקציה, משפרים את הביצועים בזמן הריצה ומצמצמים את הזיכרון שבשימוש.
קובצי DEX, או Dalvik Executable, מכילים את הקוד המקומפל שמשמש להפעלת האפליקציה. בדרך כלל הם כוללים קוד Java ו-Kotlin, בניגוד לקוד C++ מקומפל או קובצי .so.
ב"תפקוד האפליקציה" מדווחים מדדי אופטימיזציה של קוד DEX לכל האפליקציות והמשחקים, אבל אוכפים את ערכי הסף רק לאפליקציות ולמשחקים שעומדים בדרישות גודל ספציפיות.
זיהוי הבעיה
תפקוד האפליקציה יכול להתריע לכם ב-Play Console אם רמות האופטימיזציה, הכיווץ או הערפול של קוד ה-DEX של האפליקציה לא עומדות באחוזים המינימליים שהוגדרו.
איך מחושבים ציוני האופטימיזציה
באפליקציות שנוצרו באמצעות גרסת התיקון האחרונה של AGP 8.10 ואילך (לדוגמה, 8.10.1 במקום 8.10.0), האחוזים האלה נשלפים מקובץ r8.json הכלול. כדי שהמטא-נתונים שנוצרים יהיו מדויקים, חשוב להשתמש בגרסת התיקון האחרונה של AGP ו-R8 לגרסה המשנית שלכם.
באפליקציות שנוצרו באמצעות גרסאות קודמות של AGP, או באפליקציות שעברו אופטימיזציה באמצעות כלי חלופי לאופטימיזציה של קוד שלא כולל את r8.json, תפקוד האפליקציה מעריך את אחוזי הערפול כשרת proxy באמצעות הקובץ mapping.txt (אם הוא כלול) או היוריסטיקה של DEX.
הגודל המינימלי הכולל של קובצי DEX
תפקוד האפליקציה מחשב את מדדי האופטימיזציה של הקוד לכל האפליקציות, אבל תקבלו התראות רק אם ה-App Bundle עומד בדרישות הבאות לגבי הגודל הכולל של קובצי ה-DEX:
- אפליקציות: החבילה מכילה לפחות 10MB של קוד DEX, לפי הגודל הלא דחוס
- משחקים: ה-App Bundle מכיל לפחות 50MB של קוד DEX, לפי הגודל הלא דחוס
מדידת האופטימיזציה של הקוד באופן מקומי
כדי למדוד את הגודל של קובצי DEX לא דחוסים ב-App Bundle ולקבל את אחוזי האופטימיזציה, הכיווץ וההסתרה שתואמים לממצאים בתפקוד האפליקציה, מריצים את android analyze:
android analyze <yourapp>.aab
איך פותרים את הבעיה
כדי לשפר את ציוני האופטימיזציה הנמוכים של קוד ה-DEX, כדאי לעיין בהמלצות שמבוססות על מערכת ה-build ועל הכלי לאופטימיזציה:
R8
כדי לשפר את ציוני האופטימיזציה של קוד R8 DEX, כדאי לעיין בהנחיות בקטע שיפור האופטימיזציה של R8 ולהשתמש בכלי לניתוח הגדרות אישיות של R8 כדי להבין איך כללי השמירה משפיעים על ציוני האופטימיזציה, הכיווץ וההסתרה (להגדרות מפורטות של המדדים האלה, אפשר לעיין בקטע הסבר על הדוח).
אם אתם משתמשים בפלאגין של Android Gradle (AGP), אתם יכולים גם להשתמש במיומנות R8 Analyzer כדי לקבל הנחיות נוספות לגבי אופטימיזציה של כללי השמירה של האפליקציה. אם אתם משתמשים ב-Bazel, יש לכם גישה גם לכלי לניתוח ההגדרות של R8. מידע נוסף זמין במסמכי התיעוד של rules_android בנושא אופטימיזציה של R8.
כלים לאופטימיזציה שהם לא R8 ומעבדי DEX לאחר עיבוד
אם צינור עיבוד הנתונים של ה-build משתמש בכלי build בהתאמה אישית או במעבדי DEX משניים, צריך לבצע את השלבים הבאים כדי לשפר את האופטימיזציה של האפליקציה:
- פותחים את ה-App Bundle ב-Android Studio ומציגים אותו בכלי לניתוח APK.
- בוחרים את כל
.dexהקבצים. - שימו לב במיוחד לקבצים הגדולים ביותר כשאתם לוחצים על הכפתור Deobfuscate names (הערה: לשם כך צריך לטעון קובץ
mapping.txt). אם אתם רואים שחלק מהקבצים האלה נשארים גדולים גם אחרי ערפול הקוד, כנראה שהם מושפעים מכללי שמירה שחלים על כל החבילה. - חפשו בקובץ
proguard-rules.pro,configuration.txt, או בקובץ המקביל של כלי האופטימיזציה אם אתם לא משתמשים ב-R8, וחפשו כללי שמירה שתואמים לחבילות שלא עוברות ערפול קוד. לדוגמה, אםcom.foo.היא חבילה גדולה בקובצי ה-DEX, צריך לחפש כללי שמירה בפורמט-keep com.foo.**או-keep com.foo.bar.**. - חשוב לזכור שלא תמיד קל לזהות כללי שמירה של צרכני ספרייה. אם אתם חושדים שכלל צרכן של ספרייה משפיע על האופטימיזציה, אתם יכולים לבדוק את הספרייה ישירות באמצעות
android analyze <library>.aar, או לאמת אותה על ידי הוספת הספרייה לאפליקציה לדוגמה עצמאית באמצעות גרסה עדכנית של AGP ובדיקה שלה באמצעות R8 Configuration Analyzer.