AI-модуль менше фотографії на смартфоні. Чи не недооцінюємо ми комп’ютер, який завжди з нами?

💡 Усі статті, обговорення, новини про Mobile — в одному місці. Приєднуйтесь до Mobile спільноти!

Ахой! Мене звати Максим, я Android-інженер. Останнім часом мене особливо цікавлять Edge AI та комп’ютерний зір, і мені вже пощастило отримати певний продуктовий досвід у цьому напрямку. У цій статті хочу поділитися кількома спостереженнями та висновками, до яких мене привела робота з цими технологіями.

Ідея та основні інженерні виклики

Нещодавно я випустив офлайн AI-функцію для свого Android додатку, окремим модулем. У результаті весь AI-модуль зайняв 4.78 МБ. У свою чергу розпізнавання на сучасних смартфонах зазвичай триває менше 100 мс. Саме під час роботи над цією я AI-функцією почав більше замислюватися, чому деякі сучасні застосунки примудряються рости в розмірах швидше, ніж їхній функціонал.

Розробляючи та удосконалюючи свій додаток Morse Code Interpreter (перекладач Морзе коду), я заходив у відповідні subreddits «/r/morse» чи «/r/morsecode» щоб подивитися, що справді потрібно користувачам, і які проблеми вже вирішені. Було помітно, що багато постів у цих subreddits мають прохання розпізнати Морзе код, який написаний від руки чи надрукований з картинки. Це мене зацікавило, і я почав шукати, чи вже є якісь інструменти, які вирішують такі завдання.

Яким же було моє здивування, коли я не знайшов таких інструментів у Google Play чи App Store. Це здалося дивним, і я почав копати глибше, і знайшов пару онлайн сервісів, які з опису могли справитися із цією задачею. Лише один із них насправді зміг розпізнати простий приклад, щоправда на складнішому не впорався. Інші не змогли, або ж додумували відповіді.

Побачивши, що не має нормального робочого рішення, я вирішив написати цей функціонал. Для цієї задачі я вирішив використовувати ML / Edge AI. Мене завжди цікавило ML, особливо після того, як обчислювальні потужності смартфонів отримали можливість запускати ігри на кшталт Total War та Subnautica, а мобільне залізо стало здатним обробляти AI-навантаження в реальному часі безпосередньо на пристрої.

Що мене на сьогодні особливо цікавить в Edge AI — це вирішення задач локально за допомогою мобільних сенсорів та локального інференсу (виведення результатів) без залежності від хмарної обробки. Це може покращити швидкість, приватність, офлайн-доступність та зменшити витрати на інфраструктуру.

Нещодавно Google почав просувати LiteRT замість TensorFlow Lite. Тобто залізо та софт для запуску були готові. На жаль більшість обговорень та демо LiteRT, які я зараз бачу, зосереджені навколо локальних LLM. Тому вирішив дослідити зовсім інший Edge AI use case на Android: створити легке офлайн ML + CV (комп’ютерний зір) рішення для задачі, яка й досі не має практичних мобільних реалізацій у реальному часі.

Здавалося б, розпізнати кілька крапок і тире на фотографії не повинно бути нерозв’язною задачею. Втім, реальність виявилася значно цікавішою. Чим глибше я занурювався в цю задачу, тим менше вона нагадувала простий pet-проєкт і тим більше — повноцінний інженерний виклик. Можливо, саме тому хороших реалізацій виявилося небагато. А можливо, саме тому їх взагалі не було. У певний момент я навіть перестав дивуватися цьому факту.

На щастя чи на жаль, я належу до тієї категорії розробників, які після фрази «це буде складно» зазвичай починають цікавитися задачею ще більше. Але саме тут і починається найцікавіша частина історії. Або найнудніша. Інженери зазвичай називають такі речі «цікавими викликами» вже після того, як вони успішно вирішені.

Після місяців розробки, експериментів, оптимізації та Android-специфічних edge cases мною була випущена нова офлайн AI-функція для свого Android-додатку Morse Code Interpreter: розпізнавання Морзе-коду із зображень та кадрів камери повністю на пристрої без хмарної обробки. Також було прийнято рішення зробити це окремим модулем, який би завантажувався за потреби користувача та міг бути видалений у будь-який момент через додаток. Через те, що розмір додатка був приблизно 4 МБ при завантаженні, не хотілося роздувати розмір базового модуля.

Щоб читачам не довелося вірити автору на слово, нижче надаю коротке демо роботи функціоналу.

Саме рішення використовує власний гібридний ML + CV підхід разом із LiteRT та Dynamic Feature Delivery — механізм Google Play для завантаження функціоналу на вимогу. Декілька основних цікавих інженерних викликів у процесі:

• проєктування та побудова всього ML + CV pipeline з нуля;
• тренування власних моделей та інтеграція їх в Android;
• винесення AI-функціоналу в окремий Dynamic Feature-модуль із завантаженням на вимогу;
• утримання базового APK на рівні ~4 MB, тоді як опційний офлайн AI модуль залишився близько ~5 MB;
• підтримка миттєвого використання після встановлення;
• можливість видалення AI-функціоналу у будь-який момент;
• робота з Android фрагментацією та старими пристроями;
• підтримка застарілих 32-бітних Android-пристроїв.

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

Однією з особливо цікавих проблем було те, що LiteRT наразі не надає офіційно зібраних бінарних файлів для 32-бітних Android-пристроїв, тоді як я хотів, щоб цей функціонал залишався доступним і на застарілому обладнанні. У підсумку мені довелося експериментувати з власними збірками LiteRT для armeabi-v7a за допомогою Bazel (інструмент для автоматизації збирання та тестування програмного забезпечення) та інтегрувати їх у конфігурацію Dynamic Feature.

Також я задокументував процес збірки LiteRT для armeabi-v7a тут — можливо, це стане у пригоді тим, хто працює з підтримкою застарілих Android-пристроїв: GitHub guide

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

Роздутий софт, Dynamic Feature та право користувача на власний пристрій

Мінімізація та обфускація

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

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

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

Іронія полягає в тому, що під час роботи над AI-модулем менше 5 МБ (якщо бути більш точнішим, то 4.78 Mб при завантаженні) мене значно більше здивували не нейронні мережі, а деякі застосунки, які примудрялися займати в десятки разів більше місця, не пропонуючи нічого настільки ж складного. Можливо, вони використовували якісь надзвичайно важкі та потужні коди, недоступні звичайним розробникам.

Найкумедніше те, що я спеціально не намагався зробити розмір додатка мінімальним, просто зразу увімкнув мінімізацію, обфускацію, resource shrinking (видалення невикористаних ресурсів) для додатку, думаючи при цьому, чи треба мені якась бібліотека для вирішення якоїсь конкретної задачі, чи простіше написати своє і це все. Тому розмір AI — модуля вийшов такий крихітний. До речі, свого часу мав досвід додавання цих вищезгаданих практик які згадані вище для реальних проектів із користувачами, які свідомо або ж забули дотриматися, скажу вам це ще та весела задача.

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

Обфускація, мінімізація та resource shrinking — це не про гонитву за меншим APK. Це про те, щоб не змушувати користувача завантажувати, зберігати та потенційно виконувати код і ресурси, які застосунку насправді не потрібні. Побічним ефектом стає менший розмір, та основними перевагами — нижча складність, краща безпека та повага до ресурсів користувача.

Ці інструменти часто сприймаються лише як спосіб зменшити розмір APK. Насправді виграють усі сторони.

Звісно, ці підходи мають і свої недоліки.

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

Враховуючи всі плюси та мінуси, обфускація, мінімізація та resource shrinking не є абсолютним добром чи обов’язковою вимогою для кожного проєкту. Як і будь-який інженерний інструмент, вони мають свою ціну та свої переваги.

У певних випадках може бути цілком виправданим тимчасове відкладення оптимізації, з метою швидше доставити користувачам новий функціонал або перевірити бізнес-гіпотезу. Проте важливо усвідомлювати ризики такого рішення та не забувати про накопичення технічного боргу.

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

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

Dynamic Feature та справжній розмір застосунку

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

Як завжди, вирішив подивитися на реалізацію в інших додатках. Мене дуже розчарували декілька кричущих прикладів неповаги до користувача, коли деякі продукти при завантаженні з Google Play начебто мають невеликий розмір, але коли він встановлюєтся відразу, навіть не чекаючи відкриття, довантажуються сотні мегабайт без дозволу користувача (я вже мовчу про можливість потім видалити цей функціонал).

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

Проте давайте глянемо коротко основні переваги і недоліки Dynamic Feature.

Dynamic Feature, як і мінімізація, не є безкоштовним інструментом. Він додає складність архітектури та розробки, але дозволяє не змушувати користувача завантажувати функціонал, який йому може ніколи не знадобитися. Сама по собі вона мені подобається. Ідея проста та доволі логічна: не змушувати користувача завантажувати функціонал, який йому може ніколи не знадобитися. Проте іноді складається враження, що індустрія подивилася на цю концепцію і зробила прямо протилежний висновок.

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

Звісно, існують сценарії, де автоматичне завантаження цілком виправдане. Наприклад, великі ігри часто довантажують текстури, карти або інші ресурси, без яких вони просто не можуть працювати. У таких випадках це скоріше технічна необхідність. Але коли йдеться про окремий функціонал, я завжди ставлю собі питання: якщо користувачеві дали можливість не встановлювати модуль, то чому йому не дати можливість його видалити?

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

Чи не забули ми, що смартфон — це комп’ютер?

Як вже згадувалося на початку статті мені зацікавив напрям Edge AI. Можливо, Edge AI цікавий не тому, що дозволяє запускати моделі на пристрої. А тим, що вперше за довгий час змушує нас переглянути роль самого смартфона.

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

Зараз смартфон має багатоядерний процесор, GPU, NPU, кілька камер, десятки сенсорів і обчислювальну потужність, яка ще не так давно викликала би заздрість у настільних комп’ютерів. Але значна частина сучасного софту продовжує поводитися так, ніби перед ним Nokia 3310, якій довірили показувати індикатор завантаження.

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

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

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

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

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

Саме тому мене цікавить Edge AI. Не лише тому, що він дозволяє запускати моделі локально, а й тому, що відкриває нові типи мобільних застосунків. Багато речей, які ще не так давно здавалися елементами фантастичних фільмів, творів або відеоігор, поступово стають реальністю: аналіз навколишнього світу через камеру, розпізнавання об’єктів у реальному часі, локальні AI-помічники, інтелектуальна робота із сенсорами пристрою та інші сценарії, які не потребують постійного підключення до сервера.

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

На цьому місці можна було б зробити красивий висновок про майбутнє мобільної розробки та розійтися по домівках. Є смартфон, Edge AI, нові можливості та кілька дивних запитань про проблеми сучасного софту. Усі задоволені.

На жаль, у мене залишилося ще одне спостереження. І якщо до цього моменту ви ще не заснули, то зараз у мене з’являється непоганий шанс це виправити.

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

Коли технічні проблеми перестають бути технічними

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

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

У такій системі складно знайти час для запитань на кшталт: «Чи потрібна ця залежність?», «Чи можна це зробити локально?», «Чи справді користувачу буде від цього краще?». Набагато простіше виконати поставлену задачу, закрити завдання і перейти до наступного. І це цілком раціональна поведінка. Особливо, якщо зайві запитання сприймаються як перешкода, а не як частина інженерної роботи. Можливо, саме тому деякі проблеми сучасного софту починаються не з поганих технологій чи поганих інженерів. Вони починаються в той момент, коли ми перестаємо ставити запитання.

Іронічним є те, що сучасна індустрія ніколи не мала такої кількості інструментів для прискорення розробки, як сьогодні. До цього додається ще одна цікава тенденція. Сучасна індустрія дедалі більше винагороджує швидкість доставки функціоналу. AI-асистенти, генерація коду, автоматизація та інші інструменти дозволяють створювати програмне забезпечення швидше, ніж будь-коли раніше. Самі по собі це чудові інструменти, якими я також користуюся.

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

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

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

Тому що майже з кожного питання, яке ми зачепили по дорозі — Edge AI, роздутий софт, Dynamic Feature, роль смартфона, інженерні компроміси чи швидкість сучасної розробки — цілком можна написати окрему статтю, а іноді навіть серію статей. Але я вирішив не зловживати терпінням читачів і перейти до висновків. Принаймні цього разу.

Висновок

Врешті-решт ця стаття починалася не з Edge AI, Dynamic Feature чи з надмірного розростання програмного забезпечення. Вона починалася з простого запитання: чому досі не існує інструмента, який би нормально вирішував одну цілком реальну проблему користувачів. У процесі пошуку відповіді виявилося, що питання значно ширше.

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

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

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

P.S.

Якщо після прочитання цієї статті вам стало цікаво, як виглядає той самий AI-модуль розміром менше фотографії на смартфоні, можете зазирнути в Morse Code Interpreter.

А якщо раптом захочете залишити відгук, оцінку або розповісти, що автор усе це вигадав і QR-коди насправді важать по 200 МБ — я теж буду вдячний. Зрештою, якщо вже AI-модуль виявився меншим за фотографію на смартфоні, то хоча б кілька відгуків він точно заслужив 😉