1 В избранное 0 Ответвления 0

OSCHINA-MIRROR/CarGuo-GSYFlutterBook

Присоединиться к Gitlife
Откройте для себя и примите участие в публичных проектах с открытым исходным кодом с участием более 10 миллионов разработчиков. Приватные репозитории также полностью бесплатны :)
Присоединиться бесплатно
Клонировать/Скачать
Flutter-macros2.md 9.9 КБ
Копировать Редактировать Web IDE Исходные данные Просмотреть построчно История
Отправлено 10.03.2025 00:06 5767d61

Новый год в Flutter, приостановка продвижения макросов Dart, сосредоточение на поддержке специфичной обработки данных

В прошлом году во время празднования Нового года Flutter официально представил экспериментальную поддержку программирования с использованием макросов, а затем в мае того же года на конференции Google I/O был представлен Dart 3.4, объявивший экспериментальную поддержку макросов. Однако для внутреннего использования Dart, начиная с момента запуска экспериментальной поддержки макросов, прошло уже несколько лет, но текущий прогресс внедрения полной поддержки макросов не выглядит особенно успешным. Вывод можно сделать следующим образом:

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

Основная причина заключается в том, что статическая компиляция Dart и состояние горячей перезагрузки затрудняют использование макросов, поскольку метапрограммирование требует мощной поддержки рефлексии, однако для Dart это приводит к тому, что рефлексия во время выполнения (например, отражение) делает оптимизацию tree-shaking сложной, а tree-shaking является важным показателем оптимизации бинарников Dart.Изначально цель Dart состояла в создании полноценной системы макросов, которая бы позволяла глубоко анализировать семантику программы во время компиляции. Однако реализация этой семантики привела к значительному увеличению времени компиляции, что затрудняет поддержание состояния горячей перезагрузки.> В настоящее время использование макросов ухудшает опыт работы с IDE при разработке Flutter.

Кроме того, возникают проблемы с циклическими зависимостями макросов в зависимости, такие как:

При вводе ".foo" в IDE может потребоваться повторная обработка всех макросов, чтобы выполнить правильный код. В настоящий момент либо процесс происходит слишком часто, либо результат оказывается некорректным.

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

Предложение использовать кэширование для текущего поддержания макросов также сталкивается с проблемой совместимости версий генерируемых макросами кодов, например:> Предположим, есть пакет my_app, зависящий от foo и bar. Если вы выполните pub get только для foo, парсер может предоставить вам версию bar 1.2.3; если вы выполните pub get для my_app, возможно, получите версию bar 2.3.4, где тип @doStuff внутри bar может различаться между этими версиями. Хотя можно также избежать этой глубокой зависимости, ограничив внутренний доступ, это может привести к другим негативным последствиям, таким как генерация вами JSON-кода сериализации для foo, при этом макрос пытается определить тип поля из bar, поддерживающего JSON-сериализацию, а также уже упомянутую проблему циклической зависимости. Конечно, в связи с этим и другими возможными решениями, сравнение текущего времени компиляции, статического анализа и общего оптимизации программы показывает, что для Dart использование макросов на этапе выполнения не является реалистичным.Поэтому команда Dart приняла решение вернуться к текущей реализации из-за того, что конкретные цели производительности макросов остаются слишком далекими, команда решила сосредоточиться на редактировании (например, статическом анализе и завершении кода) и инкрементальной компиляции (первый шаг к горячему перезапуску).

Это особенно важно для инвестиций в поддержку данных в Dart**, поскольку это также одно из самых часто запрашиваемых вопросов в Dart & Flutter issues (запрос №314). В самом деле, основной мотивацией для поддержки макросов в Dart было предоставление лучшей сериализации и десериализации данных, но в настоящее время кажется более практичным использование большего количества специфических языковых функций для достижения этой цели.

Дополнительно, улучшение времени сборки и общего опыта генерации кода может компенсировать отсутствие макросов, что является одной из целей будущего развития. В настоящее время команда Dart уже определила улучшение build_runner.Кроме того, планируется внедрение функциональности augmentations, которая представляет собой прототип функциональности, связанной с макросами, такой как ключевое слово augment, используемое для расширения объявления. Эта функциональность является независимой частью и будет улучшать существующую генерацию кода.> При помощи команды augment можно расширить одну функциональность по нескольким файлам, добавляя новые топ-уровневые объявления, внедряя новые члены в классы и оборачивая функции и переменные в других частях кода.

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

Для разработчиков пакетов, таких как equatable, который выпустил экспериментальную версию макросов в 3.0.0-dev.1 и получил положительные отзывы, теперь представляется продолжение "эксперимента".

И наконец, желаю всем приятного Нового года 2025!

Ссылки

Опубликовать ( 0 )

Вы можете оставить комментарий после Вход в систему

1
https://api.gitlife.ru/oschina-mirror/CarGuo-GSYFlutterBook.git
git@api.gitlife.ru:oschina-mirror/CarGuo-GSYFlutterBook.git
oschina-mirror
CarGuo-GSYFlutterBook
CarGuo-GSYFlutterBook
master