Kotlin Adept Notes - разработка

⚡️⚡️Мобильные разработчики снова соберутся на Mobius этой осенью! 21–22 октября в Санкт-Петербурге и онлайне пройдет Mobius — конференция JUG Ru Group для мобильных разработчиков. По традиции в фокусе — практические задачи, нативный и кроссплатформенный подходы, архитектура и реальный опыт продуктовых команд. ✨Программа уже активно формируется, делимся наиболее интересными докладами: 🔹Портирование Android-приложений под HarmonyOS NEXT. Спикер расскажет про автоматизированный перенос с сохранением архитектуры: от преобразования Kotlin-кода в ArkTS до трансляции Jetpack Compose в ArkUI. 🔹AI-driven T-shape. Разбор реального опыта команды о том, как искусственный интеллект помогает осваивать соседние платформы и бэкенд, ускоряя развитие инженеров и уменьшая time-to-market. 🔹Liquid Glass своими руками на Metal. Анатомия визуального эффекта из iOS 26 и его воссоздание для более старых версий с разбором интеграции в кодовую базу Telegram. 📣 Встречаемся 21–22 октября (Санкт-Петербург + online). Подробнее о программе и билетах — на сайте.

Сколько стоит отказ от OpenCV Весь препроцессинг в сканере, о котором я рассказывал в прошлых постах, держится на OpenCV — библиотеке компьютерного зрения, написанной на C++. Нам из неё нужно меньше десятка функций: гомография, ресайз, гауссово размытие, CLAHE, Otsu и другое. Платим за это мы, конечно, размером: библиотека добавляет к APK около 200 МБ 😱 Здесь сразу оговорюсь, что это цифра для универсального APK со всеми ABI внутри, и очевидно, что App Bundle столько не весит: на устройство прилетает один ABI из четырёх, то есть пятьдесят мегабайт. Вот только это всё ещё много, так что AAB проблему полноценно не решает. Идея кажется очевидной: функций немного, может быть, переписать всё это на Kotlin и выкинуть зависимость целиком? Благо теперь, в мире AI, это можно сделать почти бесплатно. Как ни странно, по бенчмаркам удалось добиться почти того же качества, но вот по времени препроцессинг стал работать в 9 раз дольше на 95-м перцентиле. Кто бы мог подумать 😲 Этот вариант, очевидно, не подходит. Поэтому появилась идея собрать свою урезанную версию OpenCV, только у своей сборки есть и минусы: 🔘Обновление OpenCV перестаёт быть сменой одной цифры в зависимостях: нужно пересобрать под все ABI, прогнать сборку в CI, проверить, что ничего не отвалилось. 🔘Сложный порог входа, даже с AI-агентами можно будет прикурить после очередного апдейта NDK или AGP. 🔘Готовые обёртки OpenCV написаны и отлажены, а если мы где-то накосячим с жизненным циклом, то получим серьёзную утечку памяти в нативе. 🔘И наконец, нет гарантий, что не понадобятся ещё какие-то методы из OpenCV и потом может быть очень больно всё заново пересобирать и обновлять. Так что остаётся либо мириться с размером, либо усложнять поддержку. А что бы выбрали вы?