בדיקת תאימות אפליקציות מובייל במכשירים שונים

בדיקת תאימות אפליקציות מובייל במכשירים שונים

מעצב יצר מוקאפ עבור iPhone 14 Pro עם מסך 6.1 אינץ' ו-Dynamic Island. המפתח בדק על אותו מכשיר. לאחר השחרור, התברר שבסמסונג Galaxy A03 עם מסך 720×1600, כפתור ה"אישור" נחתך מכיוון שהפריסה הסתמכה על אזורים בטוחים (safe areas) שלא קיימים במכשירי סמסונג ישנים יותר. ב-iPad Mini, ניווט התחתון תפס שליש מהמסך—אף אחד לא בדק את הטאבלט. בפרקטיקה שלנו, סיפורים כאלה נפוצים. אנחנו עוזרים לזהות בעיות לפני השחרור: אנחנו בונים מטריצת מכשירים, בודקים על אמולטורים, ענני בדיקות (cloud farms), ומכשירים פיזיים, ומספקים דוח עם המלצות. צרו קשר להערכה ראשונית של הפרויקט שלכם.

המכשירים מגוונים מדי. אין פתרון אחד שמתאים לכולם—רק בדיקות שיטתיות. אנחנו מבצעים אותן באמצעות שילוב של אמולטורים, ענני בדיקות (BrowserStack, Firebase Test Lab), ומכשירים פיזיים. זה חוסך זמן וכסף על ידי מניעת באגים יקרים בסביבת הייצור.

למה מכשירים שונים ואיך זה משפיע על האפליקציה שלכם

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

רזולוציית מסך וצפיפות פיקסלים

ldpi (120 dpi), mdpi (160), hdpi (240), xhdpi (320), xxhdpi (480), xxxhdpi (640). אייקונים ללא גרסאות מותאמות לצפיפות נראים מטושטשים או גדולים מדי. ב-Redmi עם 720p ובסמסונג עם 1080p, אותו אלכסון פיזי פירושו צפיפות שונה, המרות dp→px שונות.

יחס גובה-רוחב

היחס הסטנדרטי 16:9 (720×1280) מיושן. יחסים נוכחיים: 20:9 (סדרת S של סמסונג), 19.5:9 (iPhone), 21:9 (Sony Xperia), ומכשירים מתקפלים עם יחסים משתנים. פריסות שמקבעות גבהים של אלמנטים נשברות על פרופורציות לא סטנדרטיות.

אזור בטוח ומגרעות (Notches)

Dynamic Island (iPhone 14 Pro+), מגרעת-חור (סמסונג), מצלמת punch-hole (רוב מכשירי האנדרואיד המודרניים). באנדרואיד, יש לטפל ב-WindowInsets וב-displayCutout. ללא טיפול במגרעת, תוכן נכנס מתחת למצלמה. אפל ממליצה לעקוב אחרי ה-safe area insets Apple Human Interface Guidelines.

ביצועי חומרה

Qualcomm Snapdragon 8 Gen 3 במכשיר דגל לעומת MediaTek Helio G85 במכשיר תקציב—רמות ביצועים שונות. אנימציות ב-120 fps חלקות במכשירי דגל אך נתקעות במכשירי ביניים. פריסות Compose מורכבות עם recompositions מרובות יסבלו.

תכונות חומרה

אין NFC, ברומטר, LiDAR או Face ID. ללא בדיקת val windowSizeClass = calculateWindowSizeClass(this) when (windowSizeClass.widthSizeClass) { WindowWidthSizeClass.Compact -> PhoneLayout() // < 600dp WindowWidthSizeClass.Medium -> TabletLayout() // 600–840dp WindowWidthSizeClass.Expanded -> DesktopLayout() // > 840dp } , ניסיון להשתמש בחומרה חסרה גורם לקריסה או לכשל שקט.

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

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

מטריצת מכשירים

אנחנו בונים את המטריצה על בסיס אנליטיקה (Firebase, Mixpanel של @Environment(\.horizontalSizeClass) var sizeClass var body: some View { if sizeClass == .compact { VStack { ... } } else { HStack { ... } // iPad, landscape iPhone Plus } } ), סטטיסטיקות שוק כלליות, ודרישות עסקיות:

מטריצה מינימלית לרוב הפרויקטים: 5–7 מכשירים. ניתן לבדוק יותר דרך BrowserStack או Firebase Test Lab (מכשירים אמיתיים ללא רכישה). בדיקות על ענן מהירות פי 5 מרכישה ותחזוקה של מערך מכשירים משלכם.

השוואת סביבות בדיקה

מה אנחנו מספקים

1. ניתוח קהל יעד וסטטיסטיקות מכשירים
2. בניית מטריצת מכשירים (5–7+ דגמים)
3. בדיקות על אמולטורים (Android Emulator, iOS Simulator)
4. בדיקות על ענן (BrowserStack, Firebase Test Lab)
5. בדיקות ידניות על מכשירים פיזיים (במידת הצורך)
6. דוח עם מטריצת אי-תאימות, צילומי מסך, והמלצות
7. ייעוץ לתיקון בעיות שנמצאו

בדיקת פריסות אדפטיביות

באנדרואיד, השתמשו ב-WindowSizeClass מ-Jetpack Compose:

val windowSizeClass = calculateWindowSizeClass(this)
when (windowSizeClass.widthSizeClass) {
    WindowWidthSizeClass.Compact -> PhoneLayout() // < 600dp
    WindowWidthSizeClass.Medium -> TabletLayout() // 600–840dp
    WindowWidthSizeClass.Expanded -> DesktopLayout() // > 840dp
}

בדקו את כל שלוש המחלקות: Compact (פורטרט בטלפון), Medium (פורטרט בטאבלט או לנדסקאפ בטלפון), Expanded (לנדסקאפ בטאבלט).

ב-iOS, השתמשו ב-horizontalSizeClass ב-SwiftUI:

@Environment(\.horizontalSizeClass) var sizeClass
var body: some View {
    if sizeClass == .compact {
        VStack {
            ...
        }
    } else {
        HStack {
            ...
        } // iPad, landscape iPhone Plus
    }
}

מקרים מיוחדים: מכשירים מתקפלים

Samsung Galaxy Z Fold יש לו שני מצבים: מקופל (קומפקטי, 22:9) ומקופל החוצה (מסך גדול, ~4:3). האפליקציה חייבת לעבור בין המצבים בצורה נכונה מבלי לאבד מצב. // Android: проверяем перед использованием val hasBluetooth = packageManager.hasSystemFeature(PackageManager.FEATURE_BLUETOOTH) val hasNfc = packageManager.hasSystemFeature(PackageManager.FEATURE_NFC) val hasCamera = packageManager.hasSystemFeature(PackageManager.FEATURE_CAMERA_ANY) נקרא בעת פתיחה/קיפול. אם ה-Activity נוצר מחדש, כל נתוני הטופס שלא נשמרו אובדים. אנחנו בודקים: שהפוקוס ב-TextField נשמר, שמיקום הגלילה משוחזר, שדיאלוגים מודאליים לא "קופצים".

בדיקת תכונות חומרה

// Android: проверяем перед использованием
val hasBluetooth = packageManager.hasSystemFeature(PackageManager.FEATURE_BLUETOOTH)
val hasNfc = packageManager.hasSystemFeature(PackageManager.FEATURE_NFC)
val hasCamera = packageManager.hasSystemFeature(PackageManager.FEATURE_CAMERA_ANY)

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

ניסיון ואחריות

הצוות שלנו—מהנדסים מוסמכים עם 10+ שנות ניסיון בפיתוח מובייל. בדקנו מעל 40 פרויקטים ברמות מורכבות שונות—מסטארטאפים ועד פתרונות ארגוניים. אנחנו מבטיחים איכות בדיקה: אתם מקבלים דוח מקיף עם בעיות אמיתיות ופתרונות קונקרטיים.

לוחות זמנים

2–3 ימים לבניית מטריצת מכשירים על בסיס אנליטיקה, בדיקות על מכשירים עדיפים (אמולטורים + ענן), ודוח עם מטריצת אי-תאימות וצילומי מסך. לכיסוי מורחב (מתקפלים, טאבלטים, אזורים ספציפיים), לוח הזמנים מתארך ל-5–7 ימים. התמחור אישי—צרו קשר לייעוץ להערכת הפרויקט שלכם.