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

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

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

ארגון מחדש במספר מודולים של תכונות

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

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

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

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

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

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

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

הקטנת קובץ התמונות

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

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

הסרת שפות שאינן בשימוש

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

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

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

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

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

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

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

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

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

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

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

התצוגה Project (פרויקט) ב-Android Studio כוללת את הקטע External Libraries (ספריות חיצוניות).

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

כלי לניתוח APK

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

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

<feature_Module>/build.gradle

מגניב

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

Kotlin

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

למידע נוסף על הקטנת גודל הייבוא הכולל של של יחסי התלות, ראו את המדריך של Gradle בנושא תלות ניהול.

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

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