Розробка сканера з вбудованим пошуком товарів за штрих-кодом

Сканування та пошук: від розпізнавання до видачі товару

Уявіть: користувач відкриває камеру, наводить на штрих-код — застосунок має за мілісекунди розпізнати код, знайти товар у базі та відобразити результат. На перший погляд задача проста, але на практиці пайплайн захоплення → розпізнавання → запит → відображення може стати вузьким місцем. Без правильної архітектури час від сканування до виведення результату перевищує 2 секунди, що призводить до відмови користувачів. Ми реалізували цей функціонал для більш ніж 30 проєктів. Досвід показує: якщо не продумати архітектуру заздалегідь, проєкт ризикує зав'язнути в переробках. Розберемо, як зробити це правильно і без сюрпризів.

Платформені можливості для розпізнавання

iOS: AVFoundation з AVMetadataObjectTypeEAN13Code, UPC-A, QRCode та ще десятком типів. Або VisionKit — VNDetectBarcodesRequest з VNBarcodeObservation, зручний для обробки статичних зображень з галереї. DataScannerViewController (починаючи з iOS 16) — найпростіший шлях: один клас, вбудований UI, підтримка всіх типів з коробки. Документація Apple: AVFoundation.

Android: ML Kit Barcode Scanning (com.google.mlkit:barcode-scanning) — працює офлайн, підтримує 1D та 2D коди. Або ZXing — перевірена бібліотека, але на слабких пристроях ML Kit швидше за ZXing у 2–3 рази, особливо при розпізнаванні Data Matrix.

Вибір залежить від мінімальної версії OS та вимог до офлайн-роботи. На Android ML Kit вимагає Google Play Services; на пристроях без GMS (Huawei) потрібен автономний bundled model. Ми підбираємо стек під конкретний проєкт — це гарантує стабільність на будь-яких пристроях.

Чому пошук складніший за сканування?

Саме сканування — кілька рядків коду. Складність в архітектурі пошуку.

Дедуплікація результатів. Камера розпізнає один і той самий штрих-код десятки разів на секунду. Без дебаунсу запит піде на сервер 50 разів до того, як користувач прибере камеру від полиці. Рішення: throttle на останній розпізнаний код із затримкою 800–1000 мс.

Офлайн-пошук. Якщо каталог товарів доступний локально, пошук по SQLite або Room (Android) / CoreData (iOS) по полю barcode з індексом працює за 1–5 мс. Без індексу на таблиці з 100 000 товарів — 300–500 мс навіть на флагмані.

Невідомий код. Користувач бачить повідомлення, якщо штрих-код не знайдено в базі. Fallback на Open Food Facts API або GS1 lookup, або просто повідомлення — це продуктове рішення, але його потрібно закласти в архітектуру заздалегідь, інакше переробляти flow.

Приклад: пошук з дебаунсом на 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. Поле barcode індексується, що дає швидкість пошуку 1–5 мс на 100 000 записів. Додатково кешуємо результати запитів у пам'яті (NSCache / LruCache), щоб повторний пошук за тим самим кодом не звертався до диска. Якщо товар не знайдено локально, переходимо до fallback.

Процес розробки: від аналізу до деплою

1. Аналіз вимог (1–2 дні) — уточнюємо формати кодів, необхідність офлайн-бази, fallback-стратегію, цільову аудиторію.
2. Проєктування (1–2 дні) — обираємо бібліотеки, проєктуємо архітектуру пошуку (дебаунс, кеш, індекси), визначаємо API-контракти.
3. Реалізація (3–5 днів) — пишемо код сканування, інтеграцію з локальною базою та бекендом, реалізуємо fallback.
4. Тестування (1–2 дні) — перевіряємо на бібліотеці з 200+ тестових штрих-кодів, включаючи рідкісні формати та пошкоджені коди.
5. Деплой (1 день) — публікуємо в App Store / Google Play з налаштованими App Review та тестами.

Для iOS мінімальна підтримувана версія — iOS 13 (тоді доступний VisionKit). Якщо потрібна підтримка iOS 12, використовуємо тільки AVFoundation. Для Android — minSdk 21 (ML Kit доступний з API 19, але рекомендуємо 21+). ProGuard/R8 правила (для keep barcode classes) надаємо в дистрибутиві.

Порівняння бібліотек розпізнавання

Чому варто довірити розробку нам?

Ми займаємося мобільною розробкою протягом багатьох років. За цей час реалізували понад 30 інтеграцій сканування та пошуку за штрих-кодами для рітейлу, складів та логістики. Використовуємо перевірені бібліотеки та фреймворки, автоматизуємо тестування пайплайну. Кожен проєкт здаємо з документацією по доступним API та рекомендаціями з підтримки. Економія на розробці з нуля може досягати 40% при використанні готових компонентів.

Що входить в результат

• Налаштоване розпізнавання під вибрані формати.
• Архітектура пошуку з дебаунсом та кешуванням.
• Інтеграція з бекендом або локальною базою.
• Обробка fallback для невідомих кодів.
• Вихідний код з коментарями, інструкція зі збірки та деплою, допомога з публікацією в App Store / Google Play.

Термін розробки базової версії — 1–3 дні для одного типу пошуку, до 5–7 днів для комплексного рішення з офлайн-каталогом. Вартість розраховується індивідуально після уточнення типів кодів та архітектури пошуку.

Отримайте консультацію по вашому проєкту — ми оцінимо складність і запропонуємо підходяще рішення. Зв'яжіться з нами, щоб обговорити задачу.