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

Сканирование и поиск: от распознавания до выдачи товара

Представьте: пользователь открывает камеру, наводит на штрих-код — приложение должно за миллисекунды распознать код, найти товар в базе и отобразить результат. На первый взгляд задача простая, но на практике пайплайн захват → распознавание → запрос → отображение может стать узким местом. Без правильной архитектуры время от сканирования до вывода результата превышает 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 дней для комплексного решения с офлайн-каталогом. Стоимость рассчитывается индивидуально после уточнения типов кодов и архитектуры поиска.

Получите консультацию по вашему проекту — мы оценим сложность и предложим подходящее решение. Свяжитесь с нами, чтобы обсудить задачу.