Розробка ML Kit у мобільному застосунку: інтеграція та оптимізація

ML Kit у застосунку: де ламається продуктивність

ML Kit надає готові модулі розпізнавання — текст, обличчя, штрихкоди, об’єкти — і рахує все на пристрої: кадр не йде на сервер, результат надходить без мережевої затримки.

На демонстрації з одним знімком це виглядає бездоганно, тому інтеграцію ML Kit часто оцінюють за першим запуском, а не за поведінкою в реальному сценарії.

Перший провал — виклик розпізнавання прямо з головного потоку. Поки модель обробляє кадр, інтерфейс не перемальовується: анімація смикається, натискання губляться, прев’ю камери йде ривками.

Користувач описує це як «гальмує розпізнавання», хоча сам модуль відпрацьовує коректно — винний потік виконання.

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

Третій — кадри подаються в модуль без черги й у повному роздільшенні. Камера віддає їх швидше, ніж модуль встигає обробляти: буфер зростає, відставання результату від реальності вимірюється вже не кадрами, пристрій нагрівається й скидає частоти.

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

Продуктивність мобільного застосунку тут визначається не моделлю, а архітектурою навколо неї: де живе екземпляр детектора, у якому потоці рахується результат і скільки кадрів реально доходить до обробки.

Що дає локальна обробка даних на пристрої

Локальна обробка даних на пристрої означає, що розпізнавання тексту, об’єктів або облич іде на самому телефоні, без відправлення кадрів на сервер.

Ми будуємо такі сценарії на ML Kit: набір працює поверх системних модулів платформи, тому модель не потрібно зашивати в збірку й оновлювати вручну разом із релізом. Нижче — два ефекти, які замовник помічає найраніше.

Час відгуку інтерфейсу

У мережевому варіанті кожен кадр чекає на відповідь сервера: камера вже показує картинку, а рамка розпізнавання з’являється із помітною затримкою.

Під час обробки на пристрої результат повертається в тому самому такті, що й потік із камери, — інтерфейс відповідає без паузи, підказка не відстає від руху руки.

Офлайн-розпізнавання заодно прибирає цілий клас відмов: «сервіс недоступний», довге очікування відповіді, обрив на слабкому каналі. Сценарій однаково працює в метро, на складі й у роумінгу, бо більше не залежить від покриття.

Витрата заряду й трафіку

Ціна локальної обробки — навантаження на процесор і накопичувач, і її видно у витраті батареї застосунку, якщо нічого не налаштовувати.

Ми обмежуємо її усвідомлено: знижуємо частоту аналізу кадрів, розводимо важкі кроки по потоках, вивантажуємо модель, коли екран неактивний або камера пішла у фон.

Тоді застосунок залишається в межах звичайного профілю роботи з камерою, а не садить заряд за годину активного розпізнавання.

Трафік падає кратко: назовні йдуть лише результати, а не потік кадрів, тому на слабкому каналі сценарій продовжує працювати, тоді як серверний варіант на ньому просто зупиняється.

ML Kit на пристрої, на сервері та гібридно: що вибрати

Вибір архітектури виведення — компроміс між приватністю, затримкою відгуку та якістю розпізнавання. Вбудовані модулі ML Kit на пристрої закривають типові задачі, а сервер потрібен там, де модель навчається на ваших даних і оновлюється частіше, ніж виходить реліз застосунку.

Коли достатньо готового модуля

Розпізнавання тексту, штрихкодів, облич і об’єктів готові модулі роблять «із коробки»: класи фіксовані, вимоги до точності типові. Перед вибором проганяємо їх на ваших реальних прикладах — якщо частка правильних відповідей тримається на потрібному рівні, своя модель не потрібна.

Коли потрібна своя модель

Своя модель потрібна, коли класи специфічні — дефекти, галузеві документи, рідкісні жести — або дані не можна випускати за межі пристрою. Тоді модель стискається під цільові пристрої, а серверний контур підключається для складних випадків і донавчання на накопичених прикладах.

Етапи інтеграції: від аудиту сценаріїв до передачі

Аудит мобільного застосунку починається не з коду, а зі сценаріїв: які задачі вирішує розпізнавання, де воно доречне на екрані й що бачить користувач, якщо модель помилилася.

На виході — карта потоків даних, вимоги до якості та список пристроїв, на яких застосунок зобов’язаний працювати стабільно.

1. Збір вимог. Фіксуємо сценарії, вхідні формати, допустиму затримку відповіді та поведінку інтерфейсу, коли результат не отримано.
2. Схема потоків даних. Визначаємо, що обробляється на пристрої, що йде на сервер, як зберігаються й видаляються вихідні дані.
3. Збірка модуля розпізнавання. ML Kit підключаємо ізольованим шаром — застосунок не прив’язаний до конкретної моделі, її можна замінити без переписування екранів.
4. Заміри на референсних пристроях. Рахуємо час відповіді, споживання пам’яті та нагрів на типовому парку, а не на одному топовому апараті.

Перевірка на парку пристроїв

• Тестування на пристроях різного класу: слабкі та старі моделі, різні версії системи, зйомка за поганого світла, поворотів і розмиття. Тут випливають відмови, невидимі в ідеальних умовах — падіння точності, завмирання інтерфейсу, прискорена витрата батареї.

Приймання та передача

• Демонстрація на узгоджених сценаріях і передача проєкту замовнику: вихідні коди, регламенти оновлення моделі, інструкції зі зняття метрик і чек-ліст приймання. Результат — код, тестові набори й зрозумілий процес випуску нових версій без нашої участі.

Артефакти впровадження: схеми, політики, регламенти

Передача застосунку — це не архів із кодом, а комплект, за яким ваша команда або інший підрядник випускає релізи й оновлює моделі без нас. Що фізично залишається в замовника:

• Схема потоків даних: звідки надходить кадр або сигнал, що рахується на пристрої, що йде на сервер.
• Конфігурації збірки та профілі середовищ: ключі, змінні, відмінності стенда від промислового контуру.
• Правила доступу до моделей: хто публікує нову збірку, як вона потрапляє в застосунок і як відкочується.
• Документація із застосунку: карта модулів, точки інтеграції з ML Kit, дозволи, поведінка без мережі.
• Передача вихідних кодів: репозиторій з історією, гілки релізу, права на ваги моделей, збірка з чистого середовища.
• Чек-ліст випуску: перевірки перед публікацією та тести на слабких пристроях.
• Документація із супроводу: розбір логів і метрик, типові інциденти та дії за ними.

Регламент оновлення моделей

Модель живе окремо від коду: дані дрейфують, якість розпізнавання просідає, а застосунок формально працює.

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

Там же зафіксовані періодичність перевірок якості та поріг, за якого оновлення обов’язкове, — так супровід застосунку не перетворюється на реакцію на скарги.

Кейс: розпізнавання документів офлайн на складі

На прийманні та відвантаженні оператор із терміналом звіряє накладні, а мережа в глибині ангара зникає рівно там, де йде робота.

Ми перенесли розпізнавання документів на сам пристрій — на базі ML Kit, без відправлення знімків у зовнішній сервіс: камера, локальна модель, готові поля в обліковій системі.

Що було до

Документ розпізнавався на сервері: термінал надсилав фото, чекав на відповідь 4–6 секунд, а в зонах без зв’язку скан узагалі не йшов.

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

Частка успішних розпізнавань трималася близько 70%, спірні документи жодним чином не позначалися, і підтримка отримувала 25–30 звернень на тиждень.

Що стало після

Модель працює з кадром локально, мережа потрібна лише щоб надіслати вже готові поля. Частка успішних розпізнавань зросла до 97%, відгук упав до часток секунди, а приймання однієї машини скоротилося з трьох хвилин до сорока секунд.

Звернень у підтримку залишилося 3–4 на тиждень — і ті про загублений термінал, а не про розпізнавання.

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

Чим готова модель відрізняється від власної?

Готова модель зі складу ML Kit — навчені детектори під типові класи: обличчя, текст, штрихкоди, об’єкти, мова. Поки задача вкладається в цей список, навчання не потрібне: інтеграція зводиться до виклику, а точність розпізнавання на типових даних передбачувана.

Своя модель потрібна там, де класи специфічні: дефекти на лінії, рідкісні типи документів, галузеві терміни.

Різниця проявляється на даних замовника. Модель, навчена на загальній вибірці, втрачає точність на нетипових сценах, нестандартній верстці та рідкісних формулюваннях.

Своя витягує ці випадки, але потребує розмітки — кілька тисяч прикладів на клас плюс валідаційний набір, який не бере участі в навчанні.

Вибір не бінарний. Починаємо з готової моделі, щоб перевірити сценарій на живих користувачах, і паралельно збираємо корпус даних.

Коли точності перестає вистачати, донавчаємо на даних замовника й порівнюємо метрики на одному наборі — рішення ухвалюється за цифрами, а не за смаком.

Технічні сумніви перед інтеграцією

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

Що з пристроями без апаратного прискорення?

Для них вмикається режим обробки на центральному процесорі: вхід зменшується, кадри проріджуються, важкі сценарії йдуть у фон. Пороги підбираємо профілюванням на слабкому парку, а не «на око» — у звіті видно час відгуку за групами пристроїв.

Куди йдуть дані користувача?

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

Що робити з нестандартними документами?

Скани, факси, рукописні бланки та багатосторінкові файли розпізнаються гірше за типові. Перед поданням у ML Kit іде попередня обробка: вирівнювання, знебарвлення, придушення шуму; під конкретний шаблон додаємо свої зразки. Це піднімає точність там, де базовий варіант помиляється.

Обговоримо задачу й повернемося з оцінкою та планом

Щоб оцінка проєкту застосунку спиралася на факти, а не на загальні слова, на вході достатньо того, що у вас уже є: опис сценарію, кілька прикладів реальних даних і список пристроїв.

Цього вистачає, щоб прикинути, які можливості ML Kit закривають задачу на пристрої, а де знадобиться серверна обробка.

Далі — технічне інтерв’ю з інженером, який веде цей напрям: розбираємо сценарій, спірні місця й обмеження, після чого повертаємося з планом впровадження та строками за етапами.

• Сценарій використання: що саме має розпізнаватися або визначатися в кадрі й що відбувається з результатом далі — показуємо користувачеві, пишемо в локальну базу або надсилаємо на сервер.
• Приклади даних: 10–20 реальних фото або відеокадрів у тих умовах, де застосунок працюватиме, — різне освітлення, нахил, розмиття, відблиски на екрані.
• Перелік цільових пристроїв і мінімальна підтримувана версія системи: від цього залежить, які моделі тягнути на пристрій, а які тримати в хмарі.
• Поточні заміри, якщо прототип уже зібрано: час обробки кадру, споживання пам’яті, приріст розміру збірки, поведінка застосунку на слабких апаратах.
• Вимоги до приватності та офлайн-режиму: чи мають дані користувача залишатися на телефоні або допустиме передавання на сервер.
• Обмеження за строками та релізним вікном: до якої дати потрібна збірка в сторах, чи є прив’язка до маркетингової кампанії або партнерського запуску.
• Що вже використовується в проєкті: готова модель на пристрої, своя навчена, сторонній сервіс — щоб не переписувати працююче без потреби.

Опишіть задачу у вільній формі — повернемося з оцінкою проєкту застосунку та планом впровадження за етапами.