Flutter будет отказываться от Html рендера, поддерживаешь ли ты это предложение?

В предыдущей статье «Будущее Flutter Web: приближается Wasm Native» мы узнали, что Flutter поддерживает Dart Native через продвижение WasmGC, чтобы обеспечить нативную поддержку Wasm Native в браузере Flutter Web. Это также является окончательной технологической стратегией Flutter Web, то есть CanvasKit — будущее Flutter Web.

Поскольку метод преобразования Flutter Widgets в Html теги для рендера противоречит принципам кросс-платформенного подхода Flutter Engine.

На этом основании официальные лица считают, что по сравнению с рендерами на основе WebGL, таких как CanvasKit и Skwasm, HTML рендер сложен, имеет плохую производительность и ограниченные возможности графики, а также предстоят значительные обновления рендера CanvasKit. Ожидаемое значение, которое может предоставить будущий Html рендер, значительно ниже затрат на его поддержание и сложностей, с которыми сталкиваются разработчики. В конце концов, стоимость совместимости и решения проблем между несколькими рендрами слишком высока, поэтому было предложено отказаться от использования и удалить Html рендер Flutter Web.В истории HTML рендера часто возникали проблемы с несоответствием результатов рендера между различными платформами. Это связано с тем, что HTML рендер должен имитировать некоторые функции других платформ через HTML, такие как градиенты, расположение текста, пиксельные шейдеры и т. д., что требует значительных ресурсов разработки и приводит к микроскопическим различиям в результате.# Почему HTML рендер будет удален

Фактически, HTML рендер был первым рендером Flutter Web, начиная с 2018 года. HTML рендер представляет собой сочетание HTML, CSS, Canvas 2D, SVG и WebGL, и в начале он обладал некоторыми преимуществами:

• Размер меньше, что позволяет быстрее загружаться, а также использовать ленивую разгрузку компонентов через deferred-components.
• Поддержка PlatformView осуществляется бесплатно, так как это просто вставка большего количества "HTML". Встраивание HTML внутри HTML очень простое.
• Поддержка CORS-изображений, так как она реализуется через тег <img>. Однако это имеет как положительные, так и отрицательные стороны для Flutter, поскольку Flutter не управляет пикселями изображений, поэтому по сравнению с другими платформами, невозможно контролировать кадры и применять некоторые эффекты пикселей.
• HTML может проще получить доступ к локальным шрифтам, не требуя загрузки шрифтов из сети, что является значительным преимуществом по сравнению с WebGL. В долгосрочной перспективе предложения W3C, такие как [canvas-formatted-text], теоретически могут полностью решить эту проблему.

Разберёмся с тем, почему было решено удалить данную функциональность.Как уже упоминалось ранее, Flutter всегда использовал Canvas в качестве основы для реализации кросс-платформенного отображения через движок, обеспечивая при этом единое качество отрисовки на разных платформах. В то же время методика отрисовки Html-renderer противоречила этой концепции и привела к значительному увеличению затрат на адаптацию и совместимость.Кроме того, объединение HTML, CSS, Canvas 2D, SVG и WebGL в одном рендере представляет собой сложную задачу. Это также привело к потере многих возможностей, которые должны были бы быть доступны в API Flutter, таких как:

• Path.combine
• drawAtlas, drawRawAtlas
• dilate, erode, compose image filters
• конические сегменты пути
• линейные и sRGB гамма-фильтры цвета
• saveLayer
• FragmentProgram, FragmentShader
• ограничение митера штриха
• Paint.imageFilter
• преобразование сцены в изображение
• возможности изображения, требующие доступа к пиксельным данным

Некоторые функции, хотя и были реализованы, имели проблемы с производительностью, такие как:

• BlendMode
• Градиент
• drawVertices
• drawPoints
• drawPicture
• Преобразование картинки в изображение
• маскировка фильтра blur (вызывает ошибку в Safari)

Из-за невозможности поддерживать API Flutter, Html-renderer заставил бы Framework, плагины и приложения использовать специальные проверки, такие как kIsWeb.

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

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

• Поддержка SEO: Так же как и в случае с доступностью, дерево рендера не является подходящим источником данных для SEO, так как оно не представляет содержание логически. Паук может видеть лишь фрагменты текста, созданные с помощью HTML или SVG, но текст, который окажется на двумерной поверхности, будет недоступен для паука. Поэтому команда Flutter продолжает исследовать возможность использования семантического дерева в качестве источника данных для SEO.## Новый CanvasKit

До этого момента CanvasKit был наиболее спорным аспектом своего размера и скорости загрузки. При первом внедрении CanvasKit Flutter требовал дополнительной нагрузки размером около 3.2 МБ для отрисовки первой кадры, и многие мобильные устройства не поддерживали WebGL 2. Например, кто-то упомянул, что их веб-сайт был создан с использованием CanvasKit, а при отслеживании потери клиентов было выявлено, что 33% потенциальных клиентов покидают сайт во время загрузки приложения. Эти три основных фактора, вероятно, являются причиной проблемы:

• dart.main.js 1.6 МБ
• canvaskit.wasm 1.5 МБ
• Время запуска движка.

После множества оптимизаций и времени, прошедшего с момента создания:

• Размер CanvasKit снизился до 1.5 МБ, новый рендеринг Skwasm может ещё больше его уменьшить до примерно 1 МБ

• WebGL 2.0 поддерживается минимум тремя последними версиями каждого основного браузера: подробнее

  

• Новые Web API могут повысить производительность рендеринга на основе WebGL, включая:

  • Поддержка WebCodecs (особенно ImageDecoder)
  • SharedArrayBuffer, который позволяет использовать общую память для многопоточной работы
  • WasmGC> При скорости интернета 10 Мбит/с затраты на запуск составляют около 0.8 секунды, и поскольку CanvasKit является кэшируемым ресурсом, он может загружаться параллельно с другими ресурсами сразу после начала, поэтому фактические затраты времени могут быть меньше 0.8 секунды.С новым CanvasKit Flutter продолжает внедрять дальнейшие оптимизации, такие как:

• Поддержка параллельной загрузки статических ресурсов, позволяющая одновременно загружать canvaskit.wasm и данные main.dart.js.

• Bootstrap API, который позволяет создать чистый HTML входящий экран приложения в фоновом режиме загрузки Flutter; когда пользователи завершают взаимодействие с этим экраном, большая часть загрузки Flutter Web уже завершена.

• На iOS большинство замедлений вызвано отсутствием API ImageDecoder, поэтому пока требуется найти лучший декодер изображений, чем текущее однониточное решение декодирования WASM.

Конечно, для CanvasKit остаются нерешёнными вопросы:

• CORS изображений
• Лучшая реализация PlatformView
• Адаптация для iOS (то есть Safari/WebKit).

А для CanvasKit существует проблема, которую невозможно решить — это отсутствие поддержки аппаратных средств без графического процессора (GPU), так как для Flutter GPU является ключевой частью, особенно важна поддержка Impeller в будущем.

Теперь, когда официальные лица четко определили направление развития с использованием CanvasKit и Wasm Native в качестве основных технологий, очевидно, что Html Renderer будет выведен из использования — это неизбежная тенденция. Разница заключается лишь в том, сколько времени потребуется для этого переходного периода?На данный момент CanvasKit имеет множество недостатков, таких как отсутствие нативной поддержки SVG, которая требует использования библиотеки flutter_svg. Для веб-технологий поддержка SVG должна была бы быть "очень простой" задачей.

Кроме того, CanvasKit имеет некоторые проблемы совместимости, такие как эта веб-страница, созданная с помощью Flutter Web и использующая wasm для рендера. Когда мы пытаемся перевести содержание страницы с помощью плагинов, видим, что только заголовок был переведён, а основное содержание нет. Это связано с тем, что основное содержание Flutter Web рисуется с помощью Canvas, и поэтому его невозможно распознать и перевести. Также при сохранении или печати страницы полное содержание body не выводится.

Поэтому на текущий момент можно сказать, что CanvasKit всё ещё нуждается в доработке, но нельзя отрицать, что он становится лучше.

Поддерживаешь ли ты предложение о прекращении использования CanvasKit и активации Html renderer?

Дополнительно см.: https://github.com/flutter/flutter/issues/145954