הקטנת הגודל של האפליקציה ללא התקנה

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

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

שינוי מבנה הקוד למספר מודולים של תכונות

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

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

שיטות מומלצות

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

שימוש באותו בסיס קוד לשני סוגי האפליקציות

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

עיצוב למודולים מרובים של תכונות

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

אל תתמקדו במגבלת הגודל של מודול של תכונות בהתחלה

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

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

עדכון משאבי אפליקציות

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

הקטנת גודל הקובץ של תמונות

אפשר להקטין באופן משמעותי את הגודל הכולל של רכיבי ה-drawable באפליקציה באמצעות הפורמט WebP במקום PNG. ‫Google Play ללא התקנה מספק תמיכה מלאה ב-WebP, כולל שקיפות ודחיסה ללא אובדן נתונים, כך שאיכות התמונה נשארת זהה.

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

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

אם האפליקציה תומכת בכמה שפות, כדאי לצמצם כמה שיותר משאבים מותאמים לשוק המקומי. השלב הזה שימושי במיוחד אם אתם משתמשים בספרייה של תאימות לאפליקציות, כמו android.support.v7.appcompat. הספרייה הזו כוללת הודעות בשפות רבות, ויכול להיות שהאפליקציה שלכם לא תומכת בחלק מהן.

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

הסרת קבצים מיותרים

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

1. מקישים על Control+Alt+Shift+I (‏Command+Alt+Shift+I ב-Mac OS).
2. בתיבת הדו-שיח שמופיעה, מקלידים "unused resources".
3. בוחרים באפשרות משאבים שלא נעשה בהם שימוש כדי להתחיל בתהליך הבדיקה של השימוש במשאבים.

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

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

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

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

ב-Android Studio יש כמה כלים שימושיים לזיהוי תלות מיותרת בפרויקט של האפליקציה:

ספריות חיצוניות

התצוגה Project ב-Android Studio כוללת את הקטע External Libraries.

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

הכלי לניתוח APK

אפשר להשתמש בכלי APK Analyzer כדי להשוות בין גרסאות build שונות, כולל גרסאות build של אפליקציות ללא התקנה.

אחרי שמחליטים אילו ספריות לא נחוצות לאפליקציה, מוסיפים לקובץ ה-build של Gradle שורות דומות לאלה כדי להחריג אותן:

<feature_module>/build.gradle

dependencies {
    implementation('some-important-but-large-library') {
        exclude group: 'com.example.imgtools', module: 'native'
    }
}

dependencies {
    implementation('some-important-but-large-library') {
        exclude(group = "com.example.imgtools", module = "native")
    }
}

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

הטמעה של העברת נכסים בענן

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