KMP и CV в МПС: как встроить распознавание в существующее приложение

Зачем KMP, а не два независимых SDK

Мобильное приложение сотрудника обычно уже существует: свои экраны, авторизация, офлайн-кэш справочников, аналитика. CV должен появиться как модуль, а не как «второе приложение».

Kotlin Multiplatform позволяет держать общую бизнес-логику сценария распознавания в одном модуле: правила совпадения, состояния сессии поиска, обработка статусов. Нативные обёртки подключают камеру и рантайм инференса платформы. Так Android и iOS не разъезжаются по поведению.

Слои архитектуры без лишних деталей

Схема совпадает с описанием на посадочной SDK; конкретные артефакты поставки уточняются на брифинге.

Инференс выполняется на устройстве; кадры не уходят в облако как часть шага распознавания. Это же свойство критично для складов без сети — см. офлайн-сценарий.

1. KMP-модуль с общей логикой распознавания и сценария.
2. Нативный слой Android: CameraX, ускорение инференса (NNAPI).
3. Нативный слой iOS: AVFoundation, Core ML / Vision.
4. Callback в UI МПС: совпадение, отсутствие результата, ошибки камеры.

Формат поставки (AAR / XCFramework / SPM) уточняется на брифинге с командой МПС — не фиксируем здесь как данность для всех сделок.

Как не переписать МПС

Минимальный контракт интеграции: экран или фрагмент, который умеет показать превью камеры (или встроить ваш контейнер), подписаться на события модуля и отрисовать подсветку/список совпадений. Навигация, роли, справочники товаров и заказов остаются вашими.

Что обычно делает команда заказчика: выделить точку встраивания, прокинуть зависимости в сборку, связать UI, прогнать регрессию критичных флоу МПС. Что берёт Zorky: модуль распознавания, примеры, документацию, поддержку на этапе техдемо и пилота. Подробнее — на странице SDK.

Граница ответственности

Zorky не заменяет продуктовую логику МПС (маршруты курьера, статусы заказа в WMS и т.п.). Модуль отвечает за распознавание и результат сценария поиска; бизнес-процесс вокруг — за заказчиком.

Как тестировать CV-модуль в CI

Полный E2E с живой камерой в CI редко стабилен. Практичный подход — разделить уровни.

• Юнит-тесты KMP-логики: статусы, правила совпадения, обработка edge-кейсов на фикстурах.
• Инструментальные тесты нативных обёрток там, где возможно без физического устройства (или на device farm — уточняется у команды).
• Регрессия МПС: сценарии без CV не должны ломаться из-за подключения модуля.
• Ручной чеклист на устройстве перед пилотом: освещение, углы, отказ в разрешении камеры.

Фикстуры вместо «магии»

Набор тестовых кадров и ожидаемых исходов помогает ловить регрессии модели и логики. Состав фикстур и пороги качества согласуются на техдемо; публично мы не публикуем вымышленные accuracy.

Этапы без выдуманных недель

Сроки зависят от готовности стенда и процессов релиза заказчика. Фиксировать «две недели до продакшена» в статье мы не будем — это предмет брифинга.

1. Брифинг с командой МПС и выбор 1–2 сценариев.
2. Техдемо и пилот на тестовой сборке.
3. Встраивание SDK в вашу сборку.
4. Пилотная эксплуатация и метрики.
5. Промышленный rollout.

Сборка, зависимости и релизный контур

Подключение модуля затрагивает Gradle/Xcode-проект: артефакты, права камеры в манифестах, возможно — Privacy Manifest на iOS. Список требований к манифестам и поставке уточняется в комплекте передачи; здесь важно заложить время релиз-менеджера, не только разработчика фичи.

Feature-flag вокруг CV-экрана снижает риск: пилотная группа видит новый флоу, остальные сотрудники работают как раньше. Откат — выключение флага, а не экстренный hotfix удаления SDK из всех веток.

Версионирование: договоритесь, как обновляется модуль относительно версии МПС. Совместимость major/minor — тема брифинга. Не смешивайте обновление модели и обновление UI-контракта в одном непрозрачном релизе без changelog для команды заказчика.

Наблюдаемость

Технические события модуля (без кадров) помогают отличать «не дали permission» от «не распознали этикетку». Это ускоряет поддержку пилота и не расширяет data flow изображениями.

Коммуникация команд: МПС, операции, ИБ

Успешное встраивание — это не только merge в репозиторий. Операции формулируют сценарий и критерии. МПС обеспечивает точку встраивания. ИБ смотрит data flow. Если кого-то нет на старте, пилот спотыкается на середине.

Техдемо для команды МПС показывает живой callback в тестовой сборке. Операционный пилот на площадке — следующий этап. Путать их вредно: разработчики оценивают API и стабильность, смена — скорость нахождения позиции и удобство экрана.

Документация и sample-проект из комплекта SDK экономят недели обратных вопросов. Используйте их как приёмочный чеклист: экран подписан на события, permission recovery есть, ручной ввод доступен, регрессия критичных флоу МПС пройдена.

Когда контур готов, имеет смысл вернуться к офлайн-сценарию склада: убедиться, что сборка действительно не требует сеть на шаге инференса. Это проверка архитектуры, а не «ещё один слайд».

Типичные ошибки интеграции

Первая ошибка — пытаться «протащить» CV через WebView или внешнее приложение. Теряется ценность единого МПС, растёт обучение, появляются лишние согласования магазинов. Встраивание модулем дороже на старте и дешевле в эксплуатации.

Вторая — игнорировать permission и lifecycle камеры. На демо всё работает, на смене приложение уходит в фон, камера остаётся занятой, следующий экран падает. Приёмка lifecycle обязательна до площадки.

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

Четвёртая — отсутствие feature-flag и плана отката. Пилот должен уметь выключиться без аварийного релиза. Пятая — несогласованный контракт UI: статусы «пустой результат» и «ошибка» обязаны различаться в продукте и в аналитике.

Что взять с собой на техдемо

Список точек встраивания в навигации МПС, схема сборки Android и iOS, ограничения MDM, контакт релиз-менеджера, черновик feature-flag. Чем конкретнее входные данные, тем быстрее техдемо превращается в план пилота, а не в обзорную лекцию про KMP.

Если стек МПС смешанный или часть экранов на другой технологии, скажите об этом заранее. Тогда можно честно очертить, куда модуль встанет с минимальным трением, а где потребуется отдельное проектирование.