התכונה 'תפקוד האפליקציה' עוזרת ל-Google לשפר את האיכות של אפליקציות ל-Android ב-Google Play. כשמשתמש מאשר זאת, המכשיר שלו עם Android עוקב אחרי מדדי איכות האפליקציה, כמו יציבות, ביצועים, שימוש בסוללה ובעיות בהרשאות. מערכת Google Play אוספת את הנתונים האלה, שאפשר לגשת אליהם דרך לוח הבקרה של תפקוד האפליקציה ב-Android ב-Play Console, ודרך Google Play Developer Reporting API.
מפתחים צריכים לעקוב אחרי תפקוד האפליקציה כדי לשפר את חוויית השימוש, ובמיוחד אחרי נתונים בסיסיים של תפקוד האפליקציה: שיעור הקריסות שהשפיעו על המשתמשים, שיעור מקרי ה-ANR שהשפיעו על המשתמשים, חסימות מוגזמות של מצב השינה, שימוש בזיכרון ושימוש בזיכרון של מפת סיביות.
נתונים בסיסיים של תפקוד האפליקציה והתנהגויות לא תקינות
הנתונים הבסיסיים של תפקוד האפליקציה משפיעים על החשיפה של האפליקציה ב-Google Play. בנוסף לנתונים הבסיסיים של תפקוד האפליקציה, המערכת של Android vitals מתריעה על פריטים שדורשים תשומת לב, כמו אופטימיזציה של קוד DEX, וגם הם עשויים להשפיע על החשיפה של האפליקציה ב-Google Play. לשיעור הקריסות שהשפיעו על המשתמשים ולשיעור מקרי ה-ANR שהשפיעו על המשתמשים יש סף התנהגות לא תקינה כולל וסף התנהגות לא תקינה לכל מכשיר.
לשימוש מופרז בחסימה חלקית של מצב השינה יש רק סף כולל של התנהגות לא תקינה, ולשימוש מופרז בסוללה ב-WearOS יש סף כולל וסף לכל דגם שעון.
למדד השימוש בזיכרון יש ספי ערך שונים לכל רמת זיכרון RAM במכשיר ולכל מצב אפליקציה, והוא שונה לאפליקציות ולמשחקים. השימוש בזיכרון של מפת הסיביות (bitmap) זהה בכל רמות ה-RAM של המכשיר, אבל יש ספים שונים לכל מצב של האפליקציה.
שאלות נפוצות
מהם נתונים בסיסיים של תפקוד האפליקציה?
הנתונים הבסיסיים של תפקוד האפליקציה הם המדדים החשובים ביותר ב-Android vitals, והם משפיעים על החשיפה של האפליקציה ב-Google Play. הנתונים הבסיסיים של תפקוד האפליקציה הם:
יציבות: שיעור הקריסות שהשפיעו על המשתמשים ושיעור מקרי ה-ANR שהשפיעו על המשתמשים בכל האפליקציות.
סוללה: נעילות השכמה חלקיות מוגזמות לכל האפליקציות, ושימוש מוגזם בסוללה לאפליקציות של תצוגת השעון.
זיכרון: שימוש בזיכרון (RSS אנונימי + שטח החלפה) ושימוש בזיכרון של מפת הסיביות (bitmap) לכל האפליקציות לנייד.
מהם ספי ההתנהגות הלא תקינה?
נתונים חיוניים לגבי יציבות וסוללה
|
סף ההתנהגות הלא תקינה כדי למקסם את החשיפה של שם האפליקציה ב-Google Play, חשוב לשמור על אורך השם מתחת לספים האלה. |
|||
|---|---|---|---|
| כולל (ממוצע בכל המכשירים) | לפי דגם הטלפון | לכל מודל של שעון | |
| שיעור הקריסות שבהן הבחינו המשתמשים | 1.09% | 8% | 4% |
| שיעור מקרי ה-ANR שבהם הבחינו המשתמשים | 0.47% | 8% | 5% |
| שימוש מופרז בסוללה | 1% | - | 1% |
| שימוש מוגזם בחסימה חלקית של מצב השינה | 5% | - | - |
מדדים חיוניים לזיכרון
אפליקציות
|
סף ההתנהגות הלא תקינה כדי למקסם את החשיפה של הכותר ב-Google Play, חשוב לשמור על ערכים מתחת לספים האלה. |
|||||
|---|---|---|---|---|---|
| זיכרון RAM פיזי (טווח סה"כ הזיכרון) |
מצב האפליקציה | ||||
| חזית | שירותים שהשפיעו על המשתמשים | רקע | מטמון | ||
| שימוש בזיכרון (RSS אנונימי + שטח החלפה) | 0 עד 4GB (0 עד 3,200MB) |
- | - | - | - |
| 4GB (3,200 – 4,800MB) |
2.00GB | 1.00GB | 1.00GB | - | |
| 6GB (4,800 – 6,800MB) |
2.25GB | 1.25GB | 1.25GB | - | |
| 8 GB (6800 - 9216 MB) |
2.25GB | 1.50GB | 1.50GB | - | |
| 12GB (9216 - 14336 MB) |
3.25GB | 1.75GB | 1.75GB | - | |
| 16 GB (14336 - 18432 MB) |
4.25GB | 2.00GB | 2.00GB | - | |
| 16GB + (מעל 18432 MB) |
- | - | - | - | |
| שימוש בזיכרון של מפת הסיביות (bitmap) | - | - | 200 GB | 200 GB | 400MB |
משחקים
|
סף ההתנהגות הלא תקינה כדי למקסם את החשיפה של הכותר ב-Google Play, חשוב לשמור על ערכים מתחת לספים האלה. |
|||||
|---|---|---|---|---|---|
| זיכרון RAM פיזי (טווח סה"כ הזיכרון) |
מצב האפליקציה | ||||
| חזית | שירותים שהשפיעו על המשתמשים | רקע | מטמון | ||
| שימוש בזיכרון (RSS אנונימי + שטח החלפה) | 0 עד 4GB (0 עד 3,200MB) |
- | - | - | - |
| 4GB (3,200 – 4,800MB) |
2.25GB | 2.00GB | 2.00GB | - | |
| 6GB (4,800 – 6,800MB) |
2.75GB | 2.50GB | 2.50GB | - | |
| 8 GB (6800 - 9216 MB) |
3.50GB | 2.75GB | 2.75GB | - | |
| 12GB (9216 - 14336 MB) |
4.00GB | 3.20GB | 3.20GB | - | |
| 16 GB (14336 - 18432 MB) |
5.00GB | 3.50GB | 3.50GB | - | |
| 16GB + (מעל 18432 MB) |
- | - | - | - | |
| שימוש בזיכרון של מפת הסיביות (bitmap) | - | - | 200 GB | 200 GB | 400MB |
אופטימיזציה של קוד DEX
|
סף ההתנהגות הלא תקינה
כדי למקסם את החשיפה של הכותר ב-Google Play, חשוב לשמור על ערכים מעל הספים האלה. |
||
|---|---|---|
| קריטריונים | דרישה | סף מינימום |
| אפליקציות עם קוד DEX בנפח של יותר מ-10MB | אופטימיזציה, טשטוש וכיווץ | 25% |
| משחקים עם קוד DEX בגודל של יותר מ-50MB | אופטימיזציה, טשטוש וכיווץ | 25% |
איך הנתונים הבסיסיים של תפקוד האפליקציה משפיעים על החשיפה של הכותר ב-Play?
אם האפליקציה או המשחק חורגים מסף ההתנהגות הלא תקינה, יכול להיות ש-Play יפחית את החשיפה של התוכן. יכול להיות ש-Play גם יציג למשתמשים אזהרה בדף האפליקציה בחנות.
האם יכול להיות שיהיו גם התנהגויות לא תקינות במכשיר וגם התנהגויות לא תקינות כלליות? או רק אחד מהם? מה עושים במקרה כזה?
כן, כל השילובים אפשריים. כדי לשפר את איכות האפליקציה, צריך לתקן את הקריסות ואת מקרי ה-ANR שמשפיעים על הכי הרבה משתמשים. כדי לשפר את האיכות במכשירים ספציפיים, כדאי לתקן את קבוצות הקריסות ומקרי ה-ANR הגדולות ביותר במכשירים האלה. אם יש לכם את שתי הבעיות, כדאי להתמקד קודם באשכולות הגדולים ביותר של קריסות ומקרי ANR.
אני רוצה לקבל עזרה בפתרון בעיות טכניות. איפה מתחילים?
הנה כמה מקורות מידע שיעזרו לכם להבין איך התכונה 'תפקוד האפליקציה' עוקבת אחרי בעיות טכניות באפליקציה או במשחק שלכם. תוכלו גם לעיין במאמר טיפול בבעיות נפוצות בביצועים לקבלת הנחיות כלליות לאבחון ולתיקון בעיות.
נתונים בסיסיים של תפקוד האפליקציה:
שיעור מקרי ה-ANR שהשפיעו על המשתמשים
שיעור הקריסות שהשפיעו על המשתמשים
שימוש מוגזם בסוללה
נעילות השכמה חלקיות מוגזמות
שימוש בזיכרון (RSS אנונימי + שטח החלפה)
שימוש בזיכרון של מפת הסיביות (bitmap)
כל שאר הנתונים על תפקוד האפליקציה:
הוצאות תכופות ממצב שינה
חסימות חלקיות ממושכות של מצב שינה
חיפוש יתר של נקודות Wi-Fi ברקע
שימוש מוגזם ברשת ברקע
זמן ההפעלה של האפליקציה
רינדור איטי
סשנים איטיים
תהליכי LMK (תהליכים להפסקת פעולה של אפליקציות בגלל צריכת זיכרון גבוהה)
דחיות של הרשאות
אני לא רוצה להיות מופתע מתפקוד לא תקין או מאזהרות לגבי דף האפליקציה בחנות. איך אפשר להיערך מראש?
מערכת Play משתמשת בנתונים מ-28 הימים האחרונים כדי להעריך את איכות האפליקציה. התכונה 'תפקוד האפליקציה' תזהיר אתכם מפני בעיות שיתרחשו במהלך התקופה הזו.
- כדאי לבדוק באופן קבוע את ממשק המשתמש או להשתמש ב-Reporting API כדי לשלב את הנתונים בתהליך העבודה.
- אפשר להגדיר ב-Play Console התראות באימייל על בעיות.
- התכונה 'תפקוד האפליקציה' מסמנת 'בעיות חדשות' – בעיות שמשפיעות על מכשירים במשך יותר מ-7 ימים במקרה של קריסות ומקרי ANR. יש לך 21 ימים לטפל בהן.
יש לי הרבה מכשירים עם התנהגות לא תקינה. איך אפשר להבין את הרשימה?
לפעמים בעיות בחומרה או בתוכנה של המכשיר גורמות לשיעורי שגיאה גבוהים. ההתראות של Android Vitals מציגות קישורים אפשריים בין שיעורי שגיאה גבוהים לבין גורמים כמו זיכרון RAM, גרסת Android וסוג המעבד. אפשר גם לבדוק את הקישורים האלה באמצעות הכרטיסיות 'היקף החשיפה' ו'מכשירים' ב-Play Console.
בנוסף, הכלי 'תפקוד האפליקציה' מאפשר גישה מהירה למידע חשוב על המכשיר, כמו מספר המשתמשים, ההכנסה, הדירוגים והביקורות. המידע הזה מוצג בחלונית צדדית, כך שלא צריך לצאת מהדף הנוכחי.
אם מתקנים בעיה במכשיר, כמה זמן עובר עד שהאזהרות מפסיקות להופיע?
מערכת Play בודקת את מדדי הביצועים המרכזיים של האפליקציה מדי יום, באמצעות ממוצע של 28 ימים. כשהממוצע הזה משתפר, האזהרות לגבי תפקוד האפליקציה נעלמות. יכול להיות שהמערכת של Play תסיר אזהרות מדף האפליקציה בחנות מהר יותר אם היא תזהה שיפור.
מה קורה אם אני לא מצליח לפתור את הבעיה או לא רוצה לעשות זאת?
חשוב לוודא ששקלתם את העלויות ואת ההזדמנויות המבוזבזות כתוצאה מחוויית משתמש גרועה. התנהגות לא תקינה פוגעת במשתמשים הקיימים ומקשה על משיכת משתמשים חדשים. אם לא מעשי לפתור בעיות במכשירים ספציפיים, כדאי לשקול מחדש את כללי הטירגוט לפי מכשיר וההחרגה של המכשירים.
למה ספירת הבעיות והשיעורים של תפקוד האפליקציה לא תואמים לספירת הבעיות ולשיעורים שמופיעים בפתרונות שלי או בפתרונות של צד שלישי?
התכונה 'תפקוד האפליקציה' היא המקור העיקרי של Play לנתונים על האיכות הטכנית של האפליקציה. יכול להיות שמספר הבעיות והשיעורים יהיה שונה ממקורות אחרים, מסיבות שונות:
- הנתונים של תפקוד האפליקציה מגיעים ממערכת Android וכוללים אירועים שלא נראים על ידי ערכות SDK, כמו:
- קריסות לפני אתחול ה-SDK
- מקרי ANR בגרסאות Android קודמות לגרסה 12
- ב-תפקוד האפליקציה נספרות רק בעיות ממכשירים מאושרים ומאפליקציות שהותקנו מ-Google Play.
- ב-Android vitals נעשה שימוש רק בנתונים ממשתמשים שהסכימו לשתף נתונים.
- כדי להגן על פרטיות המשתמשים, אנחנו מציגים נתונים רק אם יש לנו מספיק נתונים כדי ליצור דוחות אנונימיים.
- יכול להיות ששיעורי הבעיות יחושבו בצורה שונה. בדוחות תפקוד האפליקציה ל-Android מוצגות בעיות לכל משתמש פעיל ביום.
- לדוגמה, ב-Crashlytics נספר מספר הבעיות לכל סשן באפליקציה. אם משתמש שיחק במשחק שלוש פעמים ביום אחד ונתקל בקריסה אחת, ב-תפקוד האפליקציה יוצג שיעור הקריסות של 100%, וב-Crashlytics יוצג שיעור הקריסות של 33%.
מידע נוסף על אופן איסוף הנתונים זמין במרכז העזרה של Play Console.
האם אפשר לראות את התובנות לגבי ANR וקריסות בסביבת הפיתוח המשולבת (IDE)?
כן, ב-Android Studio Meerkat, כשצופים בדוחות בכלי App Quality Insights, לוחצים על הכרטיסייה 'תובנות'. Gemini מספק סיכום של הקריסה, יוצר תובנות ומקשר למסמכי תיעוד שימושיים. אם תתנו ל-Gemini גישה להקשר של קוד מקומי, הוא יוכל לספק תוצאות מדויקות יותר, הצעות לקוד ושלבים רלוונטיים להמשך. כך אפשר לקצר את הזמן שנדרש לאבחון ולפתרון בעיות. מידע נוסף זמין במאמרי העזרה של Android Studio.
מה נחשב לסשן משתמש, ומתי הוא מתחיל ומסתיים?
סשן של משתמש מוגדר כסכום של פעילות השימוש שמתרחשת במהלך תקופה של 24 שעות. התקופה של 24 שעות מתחילה בחצות לפי שעון החוף המערבי (PT) עבור כל המדדים של תפקוד האפליקציה ב-Android שנאספים. אם לא מתועדת פעילות שימוש באפליקציה במהלך היום, לא מתועד סשן.