Flutter *

Раньше у ONYX был центральный сервер, но бете 2.0 его больше нет: аккаунт — это ключ на вашем устройстве, а сообщения и звонки идут напрямую между устройствами через Tor. Рассказываю, как это устроено, что мы получили и чем пришлось заплатить.

Когда мы апгрейдим процессор или видеокарту и начинаем играть в привычную нам игрушку с новым железом, то увеличение производительности на некоторое количество процентов становится сразу же заметным. Например, увеличение производительности заметно уже с 5 процентов, если дело касается FPS в какой-то игре. 10 процентов — более заметно, 15 процентов — ещё заметнее. А увеличение производительности на 50 процентов не заметить практически невозможно. Примерно так же я смотрел на отрисовку интерфейса при компиляции Flutter-приложений в WebAssembly-код вместо JavaScript. Примерно по таким же ощущениям для большого проекта я получил ускорение, ну, примерно от 5 до 10 процентов. Хотя должен был получить 50. Поэтому я решил очень подробно исследовать данную ситуацию.

Я решил досконально проверить, насколько можно улучшить веб приложения переходом на компиляцию в WASM вместо JS, в отличии от официальных цифр у меня получились другие цифры и результат работы приложения их подтверждает.

После перехода на Wasm приложение может стать лишь немного быстрее. Я собрал отдельный Flutter-стенд, чтобы разобраться, откуда берётся этот результат: какие операции ускоряются, где выигрывает JavaScript и как вычисления связаны с плавностью интерфейса.

В мае 2024 года команда Flutter выпустила версию Flutter 22, в которой они стабилизировали поддержку WebAssembly, объединив компилятор Dart с системой сборки мусора WebAssembly — WASM GC.

Примерно с этого же времени я много экспериментировал со сборками WASM и, в принципе, для широкого круга приложений они работают не хуже JavaScript, кроме двух интересных проблем. Это несовместимость данной технологии с браузерами Firefox и Safari.

Я решил покопаться в этом вопросе: то есть, при чём здесь вообще Flutter? И действительно ли команда Flutter не занимается этой ситуацией и почему не занимается.

Вы пишете приложение на Flutter. Модели уже описаны, бизнес-правила продуманы. Осталась небольшая деталь: сервер, который будет принимать запросы и работать с данными.

И здесь обычно начинается второй сезон сериала. Другой язык, другой менеджер пакетов, ещё один набор моделей. Поле переименовали на клиенте, забыли на сервере — поздравляем, у нас распределённая опечатка.

Dart позволяет написать обе стороны приложения. А Fletch предлагает довольно понятный способ сделать серверную: знакомые по Express маршруты, middleware, обработчики запросов и немного инфраструктуры, которую не хочется каждый раз собирать вручную.

Разберёмся, как это выглядит в коде, откуда берётся скорость и какие мелочи стоит заметить до первого деплоя.

River Sortie это шутер в духе River Raid, в который можно сыграть прямо в браузере. Самолёт летит вверх по бесконечной реке, сбивает танкеры, вертолёты и мосты, заправляется над складами. Всё, что в нём движется, это обычные компоненты Flame с хитбоксами Flame, а рисует всё это в 3D flutter3d. Расскажу, как два движка поделили работу, что для этого пришлось добавить в мост flame_flutter3d, и про короткий способ, когда в 2D-игре нужна всего одна трёхмерная модель.

Привет, Хабр! Мне 50 лет, я инженер‑теплотехник с многолетним стажем. Работаю в компании которая занимается производством блочных тепловых пунктов. Моя повседневная работа — это проектирование разделов АТМ в AutoCAD,и программирование реле ПР200 от «Овен» в связке с панелями EKF для наших шкафов управления.

В какой‑то момент я поймал жесткий профессиональный кризис. Когда ты закрываешь объекты один за другим, а алгоритмы автоматизации превращаются в конвейер, мозг начинает выгорать. Мне наскучило писать одни и те же блоки логики и рисовать типовые экраны на панелях. Захотелось амбициозной, сложной задачи, которая заставит извилины шевелиться, и даст то самое забытое чувство: «Я смог это сделать!».

Я не профессиональный программист, но я умею ставить задачи. Объединив свой опыт в КИПиА с возможностями современных нейросетей, я в одиночку разработал универсальное для наших шкафов управления мобильное приложение на Flutter/Dart, которое может подключаться к ПР200 или любому другому Modbus устройству тремя различными способами. И после подключения на экране смартфона вы получаете своего рода мини SCADA систему для настройки, контроля и управления контроллером в шкафу.

Ниже я подробно расскажу об архитектуре этого решения, и почему ИИ — это лучший «цифровой джун» для опытного инженера.

Прошлый раз я писал про то, как заложил в схему БД поля под синхронизацию, которой пока нет. Синхронизации до сих пор нет, зато вышли два обновления: 0.2.0 и 0.2.1. В этой статье про три вещи, на которых пришлось подумать: переносимую папку с данными, бэкапы и импорт из Notion и Obsidian. Nookly — локальное приложение для заметок на Flutter: страницы, блоки, таблицы, канбан, поиск. Данные лежат в SQLite на устройстве, без облака.

Flutter позволяет создавать выразительные многоплатформенные приложения из единой кодовой базы. Независимо от того, разрабатываете ли вы панель управления, инструмент для своей команды или полноценное веб-приложение, Flutter Web дает вам возможность адаптировать ваше приложение для любого браузера.

С 17 по 21 августа мы проводим Неделю тестирования Flutter Web с WebAssembly ! В течение недели инженеры Dart и Flutter будут в режиме реального времени обрабатывать поступающие запросы, чтобы помочь в миграции, а наша команда по связям с разработчиками будет делиться вашими успехами в каналах сообщества.

Полгода назад я в одиночку начал делать Nookly — локальное приложение для заметок на Flutter: страницы, блочный редактор, таблицы с канбан-видом, полнотекстовый поиск. Ключевое требование с самого начала: всё работает офлайн, данные не покидают устройство. В этом посте — не про сам продукт, а про два инженерных решения, которые могут быть полезны: как спроектировать схему БД так, чтобы синхронизация потом не потребовала переписывания половины кода, и как собрать лендинг вообще без шага сборки.

Неделю назад я писал, почему видео из аниме-плеера нельзя просто вставить в <video>. Вывод был такой: нужен серверный видеопрокси, и никуда вы от него не денетесь.

Потом я перенёс тот же проект на телефон, и прокси перестал быть нужен. Не потому, что я придумал обход, а потому, что оба ограничения, из-за которых он существовал, оказались браузерными, а не сетевыми.

Под катом: что именно делал сервер, почему на Android его нет, и что оказалось не переносом библиотеки с Python на Dart, а её переписыванием — вместе с багом, который жил в оригинале, стрелочной функцией в Dart, из-за которой whenComplete начинает ждать сам себя, и релизом, который подписывает не человек.

Гайдлайны Apple, Android и Flutter по-разному, но одинаково настойчиво подталкивают задавать переход прямо в коде экрана — в документации go_router это штатный пример. В результате экран отвечает и за интерфейс, и за навигацию: его трудно переиспользовать, он знает про следующие экраны, а модульный тест превращается в интеграционный.

В статье — приём, который выносит переход из кода виджета туда, где для решения есть вся информация: экран сообщает о запросе пользователя, а решение принимает роутер вкладки или приложения. Одна и та же задача (две вкладки со своими стеками и общий экран, который в каждой вкладке ведёт себя по-своему) решена трижды: на штатном Navigator, на go_router и на auto_route.

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

Если у вас в зависимостях есть SDK RuStore или VK — проверьте адрес Maven-репозитория: 30 сентября и 1 октября старые отключаются, а часть библиотек всё ещё ведёт на них. Ниже — таблица с конкретными файлами и строками, которые ещё не обновлены, и несколько историй о том, как я чинил SDK VK и RuStore под Flutter 3.47 и AGP 9 и присылал вендорам патчи.

Поехали.

Вообще говоря, я всегда делал бэкенд исключительно на PHP. Я считаю его отличным языком для бэкенда, вернее не только для бэкенда, а отличным языком. Некоторые не любят PHP за малый порог вхождения. Типа через этот малый порог вхождения входит очень много непрограммистов, которые потом пишут говнокод. Но я придерживаюсь мнения, что PHP никак не виноват в этом. Скорее наоборот. На PHP логика просыпается даже у тех, кто кроме говнокода ничего написать не может. Поэтому в любом случае это отличный язык программирования, который каждый год хоронят, но никак похоронить не могут. И в 2026 году он живее всех живых и показывает отличные результаты.

Вторым в списке для сравнения я решил поставить Дарт. Дело в том, что самое узкое место применения Дарта — это как раз-таки применение на серверах. Потому что в мобильной разработке он уже как стандарт, веб, фронтенд мало-мальцевски он тоже подтягивает. Но вот на серверах пока что его используют очень мало. Одна из причин на то, что его мало используют на серверах, — это отсутствие библиотек, таких как, например, есть у PHP. Но, тем не менее, это совсем не значит, а тем более сейчас в эпоху LLM, это совсем не значит, что Дарт негоден на серверах. Как покажет сравнение, он очень-таки годен.

Третий кандидат для сравнения — это C++. Это его фреймворк Drogon, который в каком-то там 2014 или 2015 годах взлетел как самый быстрый фреймворк для серверов на бэкенде по скорости. Если честно, я ни разу не писал бэкенд на C++, поэтому это была первая попытка. Просто хотелось посмотреть, как C++ уничтожит двух других оппонентов со своей 100x производительностью.

Чтобы человек навёл камеру на пачку гречки и получил название, вес и калории, нужна база штрихкодов российских продуктов. Я был уверен, что она где-то есть. Её нет. Что проверял живыми запросами, почему каталоги сетей не взять, как чек ОФД заменяет каталог и как в итоге устроен справочник на 258 тысяч позиций, который растёт ровно на то, что люди сканируют.

Почему миллионы начинающих пользователей боятся «нажать не туда», а видеоуроки не формируют практических навыков? Рассказываю, как создала интерактивный симулятор настольных ОС (Windows 10, 11 и Linux) с уроками и мини-играми и как это помогает безопасно осваивать компьютерную грамотность прямо со смартфона.

В первой части мы разобрали, как Dart отличает число от объекта, а во второй – как убирается молодое поколение. Там все держалось на одном приеме: живых переносим в соседнее полупространство, а всю старую половину выбрасываем целиком.

Почему в старом поколении переезд не подходит

В молодом поколении все было просто – отбрасываем мертвые объекты и забываем про них, в старом поколении все по-другому. Для старого поколения такая операция слишком дорогая. Количество живых объектов больше, чем неживых, а это значит, что нам бы пришлось копировать почти всю память с места на место. Также необходимо было бы держать вторую половину пространства запасам такого же размера как и занятую часть полупространства. Для решения этой проблемы существует mark-sweep (Пометка-очистка).

Привет, это команда ОС Аврора.

У нас есть проблема, о которой не принято говорить в блоге вендора, но без неё вся эта история не имеет смысла. Про Аврору мы регулярно слышим одно и то же: платформа хорошая, но приложений мало, а переносить на неё уже готовые приложения с Android сложно и дорого. Пет-проект — ладно. Корпоративное приложение — тоже: их у нас уже много, просто они живут внутри закрытых контуров, и вы их не видите. А вот массовое приложение, которому для существования нужна миллионная аудитория, вроде бы обречено: никто не станет переписывать миллион строк legacy-кода ради новой платформы.

Дальше разговор обычно упирается в одну и ту же фразу: у нас всё нативное. Kotlin, Swift, годы накопленного кода, и переписывать это долго и дорого. Кроссплатформа есть далеко не у всех.

Тем, у кого она есть, нам уже давно есть что ответить: Flutter под Аврору поддерживается официально, Compose Multiplatform — тоже, и такие команды переезжают без драмы. А вот всем остальным мы до недавнего времени могли предложить только сочувствие.

Теперь, в эпоху ИИ, появился инструмент мощнее любого SDK и было бы странно его не попробовать. Поэтому мы взяли чужое большое приложение, позвали внешнего эксперта, которого никак не контролируем, и договорились опубликовать результат независимо от того, каким он получится.

С появлением Flutter GPU у Dart-разработчиков впервые появился прямой доступ к Metal и Vulkan без единой строчки нативного кода. Чтобы понять, готов ли новый API к настоящим 3D-играм, я написал над ним движок на чистом Dart: сцена, PBR-освещение, каскадные и кубические карты теней, HDR-конвейер и три взаимозаменяемых графических бэкенда (Flutter GPU, WebGL2 и программный растеризатор), плюс три законченные игры, играбельные прямо в браузере. В статье разбираем границы Flutter GPU, устройство движка и самые дорогие грабли, собранные по дороге.

Одна минута macOS-раннера в GitHub Actions стоит десять минут Linux. Я перенёс iOS-сборку Flutter-приложения в Xcode Cloud: с ~45 оплачиваемых минут на релиз до 6, без .p12 и профилей в секретах, с тремя shell-скриптами вместо 90 строк YAML. Внутри — схема тегов ios/v* и android/v*, настройки Xcode Cloud, которые молча сжигают compute-часы, и таблица семи падений первого живого прогона — ни одно из них не было ошибкой миграции. Плюс чек-лист и открытый скилл, который из этого вырос.

Теперь можно управлять машинкой в пределах комнаты, но для выезда за её пределы, хотелось видеть, куда движется устройство на экране. Чем я и начал заниматься дальше.