סריקת ברקוד וחיפוש: מזיהוי לתצוגת מוצר

סריקת ברקוד וחיפוש: מזיהוי לתצוגת מוצר

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

יכולות פלטפורמה לזיהוי

iOS: AVFoundation עם AVMetadataObjectTypeEAN13Code, UPC-A, QRCode, ועוד תריסר סוגים אחרים. או VisionKit — VNDetectBarcodesRequest עם VNBarcodeObservation, נוח לעיבוד תמונות סטטיות מהגלריה. DataScannerViewController (החל מ-iOS 16) הוא הנתיב הפשוט ביותר: מחלקה אחת, ממשק משתמש מובנה, תמיכה בכל הסוגים ישירות מהקופסה. תיעוד Apple: AVFoundation.

Android: ML Kit Barcode Scanning (com.google.mlkit:barcode-scanning) — עובד במצב לא מקוון, תומך בקודים חד-ממדיים ודו-ממדיים. או ZXing — ספרייה מוכחת, אבל במכשירים חלשים ML Kit מהיר פי 2–3 מ-ZXing, במיוחד לזיהוי Data Matrix.

הבחירה תלויה בגרסת מערכת ההפעלה המינימלית ובדרישות לא מקוונות. ב-Android, ML Kit דורש Google Play Services; במכשירים ללא GMS (Huawei), נדרש מודל עצמאי מצורף. אנו בוחרים את הערימה הטכנולוגית לכל פרויקט ספציפי — זה מבטיח יציבות בכל מכשיר.

למה חיפוש קשה יותר מסריקה

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

הסרת כפילויות תוצאות. המצלמה מזהה את אותו ברקוד עשרות פעמים בשנייה. ללא debounce, הבקשה נשלחת לשרת 50 פעמים לפני שהמשתמש מזיז את המצלמה מהמדף. פתרון: throttle על הקוד האחרון שזוהה עם השהיה של 800–1000 אלפיות שנייה.

חיפוש לא מקוון. אם קטלוג המוצרים זמין מקומית, חיפוש באמצעות SQLite או Room (Android) / CoreData (iOS) עם שדה ברקוד ממותקן לוקח 1–5 אלפיות שנייה. ללא אינדקס על טבלה של 100,000 מוצרים — 300–500 אלפיות שנייה אפילו במכשיר דגל.

קוד לא ידוע. המשתמש רואה הודעה אם הברקוד לא נמצא במסד הנתונים. גיבוי ל-Open Food Facts API או חיפוש GS1, או רק הודעה — זו החלטה מוצרית, אבל היא חייבת להיות משולבת בארכיטקטורה מראש, אחרת תצטרכו לשנות את הזרימה.

דוגמה: חיפוש עם debounce ב-iOS

private var lastScannedCode: String?
private var searchTimer: Timer?

func handleScannedCode(_ code: String) {
    guard code != lastScannedCode else { return }
    lastScannedCode = code
    searchTimer?.invalidate()
    searchTimer = Timer.scheduledTimer(withTimeInterval: 0.8, repeats: false) { [weak self] _ in
        self?.performSearch(barcode: code)
    }
}

איך אנו מתמודדים עם סוגי ברקוד שונים

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

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

איך ליישם חיפוש לא מקוון ללא עיכובים

למצב לא מקוון, אנו משתמשים במסדי נתונים ממותקנים: CoreData ב-iOS ו-Room ב-Android. שדה הברקוד ממותקן, מה שנותן מהירות חיפוש של 1–5 אלפיות שנייה עבור 100,000 רשומות. בנוסף, אנו שומרים תוצאות שאילתות בזיכרון (NSCache / LruCache) כך שחיפוש חוזר לאותם קוד לא ניגש לדיסק. אם המוצר לא נמצא מקומית, אנו עוברים לגיבוי.

תהליך הפיתוח: מניתוח לפריסה

1. ניתוח דרישות (1–2 ימים) — הבהרת פורמטי קוד, צורך במסד נתונים לא מקוון, אסטרטגיית גיבוי, קהל יעד.
2. עיצוב (1–2 ימים) — בחירת ספריות, עיצוב ארכיטקטורת חיפוש (debounce, מטמון, אינדקסים), הגדרת חוזי API.
3. יישום (3–5 ימים) — כתיבת קוד סריקה, אינטגרציה עם מסד נתונים מקומי ושרת, יישום גיבוי.
4. בדיקות (1–2 ימים) — בדיקה על ספרייה של 200+ ברקודים לבדיקה, כולל פורמטים נדירים וקודים פגומים.
5. פריסה (יום אחד) — פרסום ל-App Store / Google Play עם App Review ובדיקות מוגדרות.

עבור iOS, גרסת המינימום הנתמכת היא iOS 13 (VisionKit זמין). אם נדרשת תמיכה ב-iOS 12, אנו משתמשים רק ב-AVFoundation. עבור Android — minSdk 21 (ML Kit זמין מ-API 19, אבל אנו ממליצים על 21+). כללי ProGuard/R8 (לשמירת מחלקות ברקוד) מסופקים בהפצה.

השוואת ספריות זיהוי

למה להפקיד בידינו את הפיתוח?

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

מה כלול בתוצאה

• זיהוי מוגדר לפורמטים נבחרים.
• ארכיטקטורת חיפוש עם debounce ומטמון.
• אינטגרציה עם שרת או מסד נתונים מקומי.
• טיפול בגיבוי לקודים לא ידועים.
• קוד מקור עם הערות, הוראות בנייה ופריסה, עזרה בפרסום ב-App Store / Google Play.

ציר הזמן לפיתוח גרסה בסיסית הוא 1–3 ימים לסוג חיפוש אחד, עד 5–7 ימים לפתרון מקיף עם קטלוג לא מקוון. העלות מחושבת באופן אישי לאחר הבהרת סוגי הקוד וארכיטקטורת החיפוש.

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