התכונה 'תפקוד האפליקציה' עוזרת ל-Google לשפר את האיכות של אפליקציות ל-Android ב-Google Play. כשמשתמש מאשר זאת, המכשיר שלו עם Android עוקב אחרי מדדי איכות האפליקציה, כמו יציבות, ביצועים, שימוש בסוללה ובעיות בהרשאות. מערכת Google Play אוספת את הנתונים האלה, שאפשר לגשת אליהם דרך לוח הבקרה של תפקוד האפליקציה ב-Android ב-Play Console, ודרך Google Play Developer Reporting API.
מפתחים צריכים לעקוב אחרי מדדי תפקוד האפליקציה ב-Android כדי לשפר את חוויית השימוש, במיוחד את הנתונים בסיסיים של תפקוד האפליקציה: שיעור הקריסות שהשפיעו על המשתמשים, שיעור מקרי ה-ANR שהשפיעו על המשתמשים, חסימות מוגזמות של מצב השינה, שימוש בזיכרון ושימוש בזיכרון של מפת סיביות.
נתונים בסיסיים של תפקוד האפליקציה והתנהגויות לא תקינות
הנתונים הבסיסיים של תפקוד האפליקציה משפיעים על החשיפה של האפליקציה ב-Google Play. בנוסף לנתונים הבסיסיים של תפקוד האפליקציה, כדאי לשים לב להתראות של Android vitals לגבי פריטים כמו אופטימיזציה של קוד DEX, שדורשים טיפול ועשויים להשפיע על החשיפה של האפליקציה ב-Google Play. לשיעור הקריסות שהשפיעו על המשתמשים ולשיעור מקרי ה-ANR שהשפיעו על המשתמשים יש סף התנהגות לא תקינה כולל וסף התנהגות לא תקינה לכל מכשיר.
לשימוש מופרז בחסימה חלקית של מצב השינה יש רק סף כולל של התנהגות לא תקינה, ולשימוש מופרז בסוללה ב-WearOS יש סף כולל וסף לכל דגם שעון.
למדד השימוש בזיכרון יש ספי ערך שונים לכל רמת זיכרון RAM במכשיר ולכל מצב אפליקציה, והוא שונה לאפליקציות ולמשחקים. השימוש בזיכרון של מפת הסיביות (bitmap) זהה בכל רמות ה-RAM של המכשיר, אבל יש ספים שונים לכל מצב של האפליקציה.
שאלות נפוצות
מהם נתונים בסיסיים של תפקוד האפליקציה?
הנתונים הבסיסיים של תפקוד האפליקציה הם המדדים החשובים ביותר בנתונים של תפקוד האפליקציה ב-Android, והם משפיעים על החשיפה של האפליקציה ב-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 | - | |
| 16GB (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 | - | |
| 16GB (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
- במדדי החיוניות של Android נספרות רק בעיות ממכשירים מאושרים ומאפליקציות שהותקנו מ-Google Play.
- ב-Android vitals נעשה שימוש רק בנתונים ממשתמשים שהסכימו לשתף נתונים.
- כדי להגן על פרטיות המשתמשים, אנחנו מציגים נתונים רק אם יש לנו מספיק נתונים כדי ליצור דוחות אנונימיים.
- יכול להיות ששיעורי הבעיות יחושבו בצורה שונה. בדוחות תפקוד האפליקציה ל-Android מוצגות בעיות לכל משתמש פעיל ביום.
- לדוגמה, ב-Crashlytics נספר מספר הבעיות לכל סשן באפליקציה. אם משתמש שיחק במשחק שלוש פעמים ביום אחד ונתקל בקריסה אחת, בתפקוד האפליקציה יוצג שיעור קריסות של 100%, וב-Crashlytics יוצג שיעור קריסות של 33%.
מידע נוסף על אופן איסוף הנתונים זמין במרכז העזרה של Play Console.
האם אפשר לראות את התובנות לגבי ANR וקריסות בסביבת הפיתוח המשולבת (IDE)?
כן, ב-Android Studio Meerkat, כשמציגים דוחות ב-App Quality Insights, לוחצים על הכרטיסייה Insights. Gemini מספק סיכום של הקריסה, יוצר תובנות ומקשר למסמכי תיעוד שימושיים. אם תתנו ל-Gemini גישה להקשר של קוד מקומי, הוא יוכל לספק תוצאות מדויקות יותר, הצעות לקוד ושלבים רלוונטיים להמשך. כך אפשר לקצר את הזמן שנדרש לאבחון ולפתרון בעיות. מידע נוסף זמין במאמרי העזרה של Android Studio.
מה נחשב לסשן משתמש, ומתי הוא מתחיל ומסתיים?
סשן של משתמש מוגדר כסכום של פעילות השימוש שמתרחשת במהלך תקופה של 24 שעות. התקופה של 24 שעות מתחילה בחצות לפי שעון החוף המערבי (PT) עבור כל המדדים של תפקוד האפליקציה שאנחנו אוספים. אם לא מתועדת פעילות שימוש באפליקציה במהלך היום, לא מתועד סשן.