Строковые ресурсы для больших систем
Миллион лет назад, я первый раз попытался использовать штатный механизм управления строковыми ресурсами в Visual Studio: был травмирован, зол и разочарован. С тех пор я видел много иных инструментов для той же задачи, но время как будто остановилось - не меняется ничего. И потому очень рад, что тогда давно сделал собственный инструмент и десятилетия работаю с ним. Кратко расскажу обо всем этом.
Читать далее
Читать: https://habr.com/ru/articles/983656/
@mobi_dev | Другие наши каналы
Миллион лет назад, я первый раз попытался использовать штатный механизм управления строковыми ресурсами в Visual Studio: был травмирован, зол и разочарован. С тех пор я видел много иных инструментов для той же задачи, но время как будто остановилось - не меняется ничего. И потому очень рад, что тогда давно сделал собственный инструмент и десятилетия работаю с ним. Кратко расскажу обо всем этом.
Читать далее
Читать: https://habr.com/ru/articles/983656/
@mobi_dev | Другие наши каналы
Мобильная разработка
Photo
Официально: обновленная Siri будет основываться на модели Google Gemini
Apple официально подтвердила: обновленная Siri будет работать на модели Google Gemini и получит новые ИИ-функции в iOS 26.4
— Читать дальше «Официально: обновленная Siri будет основываться на модели Google Gemini»
Apple официально подтвердила: обновленная Siri будет работать на модели Google Gemini и получит новые ИИ-функции в iOS 26.4
— Читать дальше «Официально: обновленная Siri будет основываться на модели Google Gemini»
😁2
Как укротить SwiftLint в масштабах компании
Всем привет! Меня зовут Артём Вичужанин. В разработке я больше пяти лет: начинал с десктопных приложений на Delphi и микропрограмм для контроллеров на C++, позже ушел в мобильную разработку. Сейчас в Naumen я отвечаю за разработку мобильных продуктов, и в рамках проектов регулярно сталкиваюсь с вопросами качества кода и автоматизации.
Именно в корпоративной разработке особенно остро чувствуется: чем больше проектов и команд, тем сложнее удерживать единый стиль кода.
В этой статье я делюсь опытом настройки SwiftLint сразу для нескольких репозиториев — так, чтобы кодстайл оставался единым и не расползался со временем.
Читать далее
Читать: https://habr.com/ru/companies/naumen/articles/981474/
@mobi_dev | Другие наши каналы
Всем привет! Меня зовут Артём Вичужанин. В разработке я больше пяти лет: начинал с десктопных приложений на Delphi и микропрограмм для контроллеров на C++, позже ушел в мобильную разработку. Сейчас в Naumen я отвечаю за разработку мобильных продуктов, и в рамках проектов регулярно сталкиваюсь с вопросами качества кода и автоматизации.
Именно в корпоративной разработке особенно остро чувствуется: чем больше проектов и команд, тем сложнее удерживать единый стиль кода.
В этой статье я делюсь опытом настройки SwiftLint сразу для нескольких репозиториев — так, чтобы кодстайл оставался единым и не расползался со временем.
Читать далее
Читать: https://habr.com/ru/companies/naumen/articles/981474/
@mobi_dev | Другие наши каналы
Как достучаться до клиента в мобильном приложении: вчера и сегодня
Привет, Хабр!
В последнее время я вижу много рекомендаций о том, как успешно работать с клиентской базой и развивать клиентский опыт. Кажется, что в этой теме я могу быть полезным. Меня зовут Алексей Ласкин, я руководитель Центра компетенций по монетизации данных в команде РСХБ.Цифра, занимаюсь проектами по монетизации данных в цифровых каналах экосистемы «Я в агро» — Свое фермерство, Свое родное, Свое за городом, Свои финансы, Свой бизнес, Монеты.
Хочется поделиться тем, как развивается СVM (Customer Value Maximization) и какие тренды на него влияют: разработчикам это может помочь сформировать понимание целей и средств разработки, которые следует использовать при проектировании СVM-систем. Опыт банков, показателен в части объема данных, который мы можем использовать для формирования предложений.
Читать далее
Читать: https://habr.com/ru/companies/rshb/articles/984720/
@mobi_dev | Другие наши каналы
Привет, Хабр!
В последнее время я вижу много рекомендаций о том, как успешно работать с клиентской базой и развивать клиентский опыт. Кажется, что в этой теме я могу быть полезным. Меня зовут Алексей Ласкин, я руководитель Центра компетенций по монетизации данных в команде РСХБ.Цифра, занимаюсь проектами по монетизации данных в цифровых каналах экосистемы «Я в агро» — Свое фермерство, Свое родное, Свое за городом, Свои финансы, Свой бизнес, Монеты.
Хочется поделиться тем, как развивается СVM (Customer Value Maximization) и какие тренды на него влияют: разработчикам это может помочь сформировать понимание целей и средств разработки, которые следует использовать при проектировании СVM-систем. Опыт банков, показателен в части объема данных, который мы можем использовать для формирования предложений.
Читать далее
Читать: https://habr.com/ru/companies/rshb/articles/984720/
@mobi_dev | Другие наши каналы
Мобильная разработка
Photo
OpenAI без лишнего шума запустила онлайн-переводчик ChatGPT Translate
OpenAI запустила ChatGPT Translate — онлайн-переводчик без подписки, с контекстным переводом, изображениями и ИИ-голосом
— Читать дальше «OpenAI без лишнего шума запустила онлайн-переводчик ChatGPT Translate»
OpenAI запустила ChatGPT Translate — онлайн-переводчик без подписки, с контекстным переводом, изображениями и ИИ-голосом
— Читать дальше «OpenAI без лишнего шума запустила онлайн-переводчик ChatGPT Translate»
🔥3❤1
Анимация смены темы в Compose Multiplatform
Анимация смены темы в Android-версии Telegram на протяжении долгого времени вдохновляет разработчиков на попытки реверс-инжениринга этого красивого трюка: в сети немало подробных гайдов, как сделать подобную анимацию при помощи традиционных XML View и даже Flutter. Но реализаций этой элегантной (хоть и совершенно бесполезной) анимации на Jetpack Compose мне найти так и не удалось, что привело к созданию маленькой библиотеки для анимирования смены темы.
Вера в будущее KMP также подтолкнула меня к тому, чтобы сделать ее из коробки готовой к установке в Compose-Multiplatform проекты, с поддержкой всех основных платформ (Android, iOS, Desktop JVM, Web WASM+JS).
Хотя сама библиотека вышла крайне компактной, ее реализация оказалась довольно нетривиальной на мой субъективный взгляд и может быть интересна каждому, кто изучает Compose или ищет подобные решения для своего проекта.
На старте написания библиотеки сами собой возникли ряд требований, которым она должна была отвечать:
Читать далее
Читать: https://habr.com/ru/articles/983488/
@mobi_dev | Другие наши каналы
Анимация смены темы в Android-версии Telegram на протяжении долгого времени вдохновляет разработчиков на попытки реверс-инжениринга этого красивого трюка: в сети немало подробных гайдов, как сделать подобную анимацию при помощи традиционных XML View и даже Flutter. Но реализаций этой элегантной (хоть и совершенно бесполезной) анимации на Jetpack Compose мне найти так и не удалось, что привело к созданию маленькой библиотеки для анимирования смены темы.
Вера в будущее KMP также подтолкнула меня к тому, чтобы сделать ее из коробки готовой к установке в Compose-Multiplatform проекты, с поддержкой всех основных платформ (Android, iOS, Desktop JVM, Web WASM+JS).
Хотя сама библиотека вышла крайне компактной, ее реализация оказалась довольно нетривиальной на мой субъективный взгляд и может быть интересна каждому, кто изучает Compose или ищет подобные решения для своего проекта.
На старте написания библиотеки сами собой возникли ряд требований, которым она должна была отвечать:
Читать далее
Читать: https://habr.com/ru/articles/983488/
@mobi_dev | Другие наши каналы
❤1
Работа с аудио в Android: опыт реализации DAF — техники терапии заикания
Небольшие заметки о работе с аудио в Android: получение минимальной задержки, работа с аудио сэмплами напрямую, запись аудиоданных с сжатом виде.
Возможно для кого-то это окажется полезным.
Читать далее
Читать: https://habr.com/ru/articles/983882/
@mobi_dev | Другие наши каналы
Небольшие заметки о работе с аудио в Android: получение минимальной задержки, работа с аудио сэмплами напрямую, запись аудиоданных с сжатом виде.
Возможно для кого-то это окажется полезным.
Читать далее
Читать: https://habr.com/ru/articles/983882/
@mobi_dev | Другие наши каналы
Оптимизация OCR на мобильных: с 5 секунд до 1 (и даже меньше)
Автор статьи на DEV Community разрабатывает приложение, которое захватывает экран телефона, распознаёт текст и переводит его. Изначально весь цикл занимал 4–5 секунд. Для реалтайм сценариев (например, перевод игрового меню или чата) это неприемлемо. Задача была уложиться в секунду.
Профилирование показало, что 80% времени съедали два этапа: предобработка изображения (800мс) и OCR-инференс (2500мс). Остальное — захват экрана, вызов API перевода, рендеринг — тоже в итоге оптимизировали, но основной выигрыш был не там.
В качестве выводов автор предлагает пять советов, которые пригодятся всем, кто работает с OCR на устройстве:
1. Не скармливайте OCR-движку полноразмерное изображение. Экранный текст высококонтрастный, поэтому даунскейл до ~1280px по большей стороне почти не роняет точность, зато кратно ускоряет обработку.
2. Сначала дешёвая детекция текстовых областей, потом дорогой OCR только по ним. На типичном экране приложения текст занимает 30–40% площади: нет смысла гонять инференс по остальным 60–70%.
3. Используйте модель, заточенную под конкретную письменность. Если прогнать латинский распознаватель по китайскому, японскому или корейскому тексту, потратите время и получите мусор. Определяйте тип письменности заранее: по настройкам пользователя или по предыдущим результатам.
4. Параллельте обработку регионов. Если на экране несколько текстовых блоков, их можно распознавать одновременно на разных ядрах. На мобильных чипах это может дать 20–30% ускорения.
5. Кешируйте результаты через перцептуальный хеш (короткий «отпечаток» изображения, основанный на визуальном сходстве, а не побайтовом совпадении). Экран между захватами часто почти не меняется (мигнул курсор, сдвинулась анимация), а перезапускать OCR на практически идентичных кадрах как минимум странно.
Итог экспериментов: на мидренж-чипе (Snapdragon 695) пайплайн ускорился с ~4100мс до ~800мс. На флагманах до 400-500мс.
Код можно посмотреть в оригинале: https://dev.to/joe_wang_6a4a3e51566e8b52/optimizing-ocr-performance-on-mobile-from-5-seconds-to-under-1-second-332m
@mobi_dev (теперь и в Max)
Автор статьи на DEV Community разрабатывает приложение, которое захватывает экран телефона, распознаёт текст и переводит его. Изначально весь цикл занимал 4–5 секунд. Для реалтайм сценариев (например, перевод игрового меню или чата) это неприемлемо. Задача была уложиться в секунду.
Профилирование показало, что 80% времени съедали два этапа: предобработка изображения (800мс) и OCR-инференс (2500мс). Остальное — захват экрана, вызов API перевода, рендеринг — тоже в итоге оптимизировали, но основной выигрыш был не там.
В качестве выводов автор предлагает пять советов, которые пригодятся всем, кто работает с OCR на устройстве:
1. Не скармливайте OCR-движку полноразмерное изображение. Экранный текст высококонтрастный, поэтому даунскейл до ~1280px по большей стороне почти не роняет точность, зато кратно ускоряет обработку.
2. Сначала дешёвая детекция текстовых областей, потом дорогой OCR только по ним. На типичном экране приложения текст занимает 30–40% площади: нет смысла гонять инференс по остальным 60–70%.
3. Используйте модель, заточенную под конкретную письменность. Если прогнать латинский распознаватель по китайскому, японскому или корейскому тексту, потратите время и получите мусор. Определяйте тип письменности заранее: по настройкам пользователя или по предыдущим результатам.
4. Параллельте обработку регионов. Если на экране несколько текстовых блоков, их можно распознавать одновременно на разных ядрах. На мобильных чипах это может дать 20–30% ускорения.
5. Кешируйте результаты через перцептуальный хеш (короткий «отпечаток» изображения, основанный на визуальном сходстве, а не побайтовом совпадении). Экран между захватами часто почти не меняется (мигнул курсор, сдвинулась анимация), а перезапускать OCR на практически идентичных кадрах как минимум странно.
Итог экспериментов: на мидренж-чипе (Snapdragon 695) пайплайн ускорился с ~4100мс до ~800мс. На флагманах до 400-500мс.
Код можно посмотреть в оригинале: https://dev.to/joe_wang_6a4a3e51566e8b52/optimizing-ocr-performance-on-mobile-from-5-seconds-to-under-1-second-332m
@mobi_dev (теперь и в Max)
❤5🔥3👍1😎1
На практике — перегруженный API, сложное тестирование и десятки разных реализаций одного паттерна.
С этим столкнулась команда дизайн-системы «Орбита» в Яндекс 360 при работе с listItem — базовым элементом, который использовался почти в каждом интерфейсе.
Вместо точечных правок команда проанализировала реальные использования компонента и обнаружила: несмотря на сотни возможных конфигураций, большинство сценариев укладывается в несколько устойчивых паттернов. После декомпозиции новые компоненты стали в среднем в три раза проще оригинального.
В статье Дмитрий Мандельштам, мобильный разработчик в Яндекс 360, и Алексей Карпенко, руководитель команды дизайн-системы, подробно разбирают, как:
• измерять сложность UI-компонентов;
• принимать решения о декомпозиции на основе данных;
• перерабатывать legacy-компоненты без остановки разработки.
Кстати, в Яндекс 360 сейчас открыты вакансии для мобильных разработчиков.
Это #партнёрский пост
Please open Telegram to view this post
VIEW IN TELEGRAM
❤🔥2👍1👎1🔥1