Фреймворк выбора Flutter-проекта — опыт смешанной разработки

Эта статья является эксклюзивной публикацией сообщества Tuishe Juejin и запрещена для перепечатки в течение OnClickListener.CLICK дней. После истечения срока действия лицензии перепечатка возможна только при наличии специального разрешения. Нарушение авторских прав будет преследоваться!

Это четвертая часть серии "Фреймворк выбора Flutter-проекта". Как было заявлено ранее, эта серия предназначена для того, чтобы помочь вам быстро выбрать подходящие функциональные модули для создания Flutter-проекта или для построения его стартовой платформы. Это руководство, поэтому особенно полезно для новичков.

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

Разработка с использованием смешанной технологии в Flutter всегда была одной из сложностей, главным образом потому что: Flutter имеет свой собственный движок отрисовки, который делает отрисовку компонентов Flutter независимой от дерева отрисовки платформы. Это усложняет реализацию смешанной разработки в Flutter.> Можно сравнить это с тем, как если бы вы пытались вставить native UI-компоненты внутрь WebView.

На самом деле, смешанная разработка в Flutter также может быть разделена на две категории: встраивание native UI-компонентов в Flutter (PlatformView) и встраивание Flutter в native проект (add-to-app). В этом году наш акцент сосредоточен на PlatformView, где история использования Android PlatformView наиболее богата. Однако сегодняшняя статья не будет посвящена детальному объяснению технической реализации, интересующихся историческими реализациями могут обратиться к предыдущим статьям. Сегодня мы будем говорить больше о том, как правильно выбирать.

• Прогресс смешанной разработки в Flutter 3.0
• Глубокое исследование прогресса смешанной разработки в Flutter
• Реализация и будущее развитие HybridComposition и VirtualDisplay в смешанной разработке
• Глубокое понимание Hybrid Composition в Flutter 1.20
• Android PlatformView и проблемы с клавиатурой

PlatformViewДля включения native UI-компонентов в Flutter используется PlatformView. Способ реализации этого механизма на iOS практически не изменился, но на Android различные версии системы привели к появлению трёх различных логических реализаций, поэтому в данной статье мы подробно рассмотрим, как выбрать подходящий вариант PlatformView для Android. Пропустив самые ранние реализации, такие как flutter_webview_plugin, который просто заменяет native контролы, PlatformView на Android имеет три официальных способа реализации:- VirtualDisplays: Похоже на виртуальное отображение, которое рендерится на памятной поверхности (Surface) и затем синхронизируется с текстурой в движке. На самом деле, контролы не находятся в месте рендера.

• HybridComposition: Через addView добавляет native контролы непосредственно, использует FlutterImageView для стекирования рендера Flutter-контрола при необходимости. Native контролы находятся в месте рендера.

• TextureLayer: Использует прозрачный контейнер PlatformViewWrapper, чтобы рендерить текстуру native контрола на определённой поверхности (Surface). Контролы не находятся в месте рендера, но события могут быть перехватываться родительским контейнером.

Может показаться запутанным? Не волнуйтесь, примеры будут объяснять это более подробно. Если вы не понимаете — это нормально, так как эта статья предназначена для того, чтобы помочь вам выбрать подходящий метод, а не для полного понимания внутренней работы.

Однако эти три реализации имеют свои условия применения:

• До Flutter 1.2 можно было использовать только VirtualDisplays.

• До Flutter 3.0 можно было использовать только VirtualDisplays и HybridComposition.

• До Flutter 3.3 можно было использовать только TextureLayer и HybridComposition.

• С Flutter 3.3 можно использовать VirtualDisplays, TextureLayer и HybridComposition.Не кажется ли странным такое распределение? Вот общая история этого процесса:

• Из-за проблем с событиями касаний и клавиатурой в VirtualDisplays был введен HybridComposition, который использует метод addView для нативной стэкировки и решает проблемы с жестами и клавиатурой.

• Из-за некоторых недостатков HybridComposition, таких как заикание при прокрутке списков и несинхронизация потока рендера, вызывающая мерцание, VirtualDisplays продолжали использоваться.

• С версии 3.0 по умолчанию VirtualDisplays и HybridComposition были заменены на TextureLayer. Однако реализация HybridComposition была сохранена; для использования её требуется явно выполнить PlatformViewsService.initExpensiveAndroidView, поскольку TextureLayer имеет ограничения по работе с нативными компонентами Canvas. Кроме того, TextureLayer требует API уровня Android 23 и выше.

• С версии 3.3 снова используется реализация VirtualDisplays, чтобы поддерживать сценарии ниже API уровня Android 23. В связи с тем, что механизмы типа SurfaceView не могут быть напрямую совместимы с TextureLayer, при встрече с такими сценариями TextureLayer будет переходить на режим VirtualDisplays.

Это действительно связано с вопросами реализационных затрат и контролем со стороны сообщества, что привело к такой "нестабильной" ситуации.Данное утверждение может показаться абстрактным, поэтому рассмотрим конкретные примеры. В качестве первого примера возьмём официальное webview_flutter решение. Как показано в таблице ниже, изначально плагин WebView использовал по умолчанию AndroidWebView, то есть реализацию через VirtualDisplays. После появления HybridComposition был добавлен новый вариант SurfaceAndroidWebView, который пользователи могут выбирать в зависимости от своих потребностей.| По умолчанию | VirtualDisplays | HybridComposition | | ---------------------------------------------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------ | | | | |

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

if (Platform.isAndroid) WebView.platform = SurfaceAndroidWebView();

Позже во время обновлений webview_flutter по умолчанию также перешло на использование SurfaceAndroidWebView, так как HybridComposition действительно лучше всего подходит для работы с WebView, особенно при работе с HTML5-страницами.

По умолчанию	TextureLayer	HybridComposition

• Huawei: huawei_map
• AutoNavi: amap_flutter_map
• Baidu: flutter_baidu_mapapi_map

Хотя все они используют реализацию PlatformView, но подходы к её реализации имеют некоторые различия, что позволяет лучше понять различия в реализациях PlatformView:

• Реализация плагина карт Google Maps для Flutter использует метод AndroidView. Это значит, что до версии Yöntem AndroidView. Это означает, что до версии 3.0 используется VirtualDisplays, а начиная с версии 3.0 — TextureLayer. Из таблицы можно видеть, что в контейнере родителя MapView в Flutter 3.0 используется TextureLayer.

Dart реализация	TextureLayer

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

> Для интересующихся вопросами конфиденциальности и разрешений рекомендую прочитать «Сборник проблем при публикации приложений в 2022 году, полное попадание в ловушки».- Реализация плагина карт Huawei для Flutter выбирает метод HybridComposition. Обратите внимание на код в следующем примере, где используется initExpensiveAndroidView. В настоящее время использование PlatformViewLink уже не является достаточным условием для использования HybridComposition. Начиная с версии 3.0, необходимо явно указать initExpensiveAndroidView, чтобы использовать HybridComposition.

| До версии 3.0 PlatformViewLink | После версии 3.0 PlatformViewLink + initSurfaceAndroidView | После версии 3.0 PlatformViewLink + initExpensiveAndroidView | | ---------------------------------- | ------------------------------------------------------------- | --------------------------------------------------------------------- | | HybridComposition | TextureLayer | HybridComposition |

Для заинтересованных в детальном реализации HybridComposition: реализация и будущее развитие HybridComposition и VirtualDisplay в условиях смешанной разработки и глубинный анализ Hybrid Composition в Flutter 1.20.- плагин карт Google Maps от Baidu для Flutter использует метод реализации через AndroidView, но в нативной части доступны два варианта реализации — TextureView и SurfaceView. Это приводит к различным комбинациям.

С помощью инструмента Layout Inspector можно заметить, что при использовании плагина карт Baidu в Flutter 3.3, если используется MapSurfaceView, то применяется VirtualDisplays, а если используется MapTextureView, то применяется TextureLayer. Почему так?

SurfaceView	TextureView

Ранее мы говорили, что в Flutter 3.0 TextureLayer заменил VirtualDisplays, и его реализация осуществляется путём замены дочернего Canvas с помощью PlatformViewWrapper для извлечения текстур. Однако в некоторых случаях это может вызвать проблемы, например, когда используется SurfaceView.> Вкратче, SurfaceView представляет собой специфическую ситуацию, которая имеет двойное буферизирование, аналогично двум Canvas, и имеет отдельное состояние окна (WindowState) в WMS. Поэтому логика рендера фактически выходит за рамки обычной иерархии Views, поэтому механизм hook Canvas в TextureLayer в Flutter 3.0 несовместим. Поэтому в Flutter 3.3 VirtualDisplays снова появились. Как опытный "ветеран", VirtualDisplays продолжают использоваться при условии, что уровень платформы ниже 23 или когда нативный компонент является SurfaceView. Это можно считать компромиссным решением.| | | | ----------------------------------------------------------- | ----------------------------------------------------------- |

Если вас интересует эта часть, вы можете прочитать Flutter 3.0 и эволюция гибридной разработки / Flutter: глубокое исследование эволюции гибридной разработки.

Теперь вы знаете, почему мы сделали этот выпуск? Имплементация PlatformView в Flutter имеет множество "ловушек" из-за исторического багажа, и если не понять эти проблемы, это может затруднить поиск решения при возникновении проблем, так что давайте подведём итог:

• VirtualDisplays, как старый конь, использует метод извлечения текстур с помощью виртуального отображения, который может иметь проблемы с жестами и клавиатурой, но подходит для списков и маленьких компонентов. В версии 3.0 он отсутствовал.
• HybridComposition появился после версии 1.2, используя метод addView и слоистую структуру для обеспечения максимальной точности отображения компонента, хотя производительность может страдать. Подходит для использования вне списков, начиная с версии 3.0 требует явного вызова initExpensiveAndroidView.
• TextureLayer появился в версии 3.0, используя метод хуков для Canvas компонента для извлечения текстур, но требует мини-SDK 23. Подходит для замены VirtualDisplays, но начинает использовать VirtualDisplays при встрече с SurfaceView в версии 3.3.> На самом деле, я чувствую, что в будущих версиях логика здесь ещё будет меняться, но, возможно, как и с выпусками 3.0 и 3.3, такие изменения могут не попасть в официальные заметки о выпусках.

Наконец, хочу отметить один важный момент относительно карт. Сейчас все три крупнейших поставщика SDK для карт в Китае требуют минимальной стоимости лицензии в 50 000 юаней, поэтому если вы планируете использовать их в проектах компании, вам придётся заплатить эту сумму, поскольку рано или поздно платформа свяжется с вами для оплаты. Поэтому рекомендуется учесть этот вопрос при оценке проекта и обсудить его с представителями продуктов.| AutoNavi | Baidu | Tencent | | ----------------------------------------------------------- | ----------------------------------------------------------- | ------------------------------------------------------------ | | | | | | | | |

Конечно, сервис карт Huawei в настоящее время не требует коммерческого лицензирования, но его сборка и конфигурация сложны, особенно если требуется HMS. Поэтому, если вы готовы потратить больше времени ради экономии денег, можно рассмотреть использование карт Huawei.

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

Отзыв: Мы заметили, что ваше приложение использует интернет-карты. В соответствии с "Указанием о повышении качества управления интернет-карт" интернет-карты должны иметь соответствующие лицензии на предоставление услуг интернет-карт. Ваши услуги должны соответствовать этим лицензиям. Предложения по исправлению: Пожалуйста, предоставьте сертификат "Лицензия на географическую информацию", указывающий на предоставление услуг интернет-карт; если используется карта от стороннего провайдера, пожалуйста, предоставьте соглашение о сотрудничестве (лицензию) и поместите информацию о партнере в явном виде на карте.

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