Эта статья - часть моих ощущений после изучения фреймворков пользовательского интерфейса на нескольких платформах.Из-за ограничения энергии и технического уровня в статье определенно есть недостатки.Пожалуйста, дайте мне больше советов.
Если вы найдете мою статью полезной для вас, насобиратьВ процессе нужно помнитьподобноа такженажмите, чтобы увидетьО, спасибо, это действительно много значит для меня 🌟!
1. Передние трехосные
Прежде чем официально обсудить концепцию «кросс-энд разработки», мы можем подумать над вопросом: что в основном делает фронтенд для большей части работы с интерфейсом?
Лично я считаю, что вне зависимости от того, как меняется окружение, внешний интерфейс в основном делает три вещи:
- получить данные
- управлять состоянием
- визуализировать страницу
Ушел.
Кому-то может показаться, что то, что я сказал, слишком однобоко, но на самом деле об этом можно порассуждать. Если поближе, то сейчас, когда оплата за знания в самом разгаре, мы на каждом шагу будем делать "анализ исходного кода ХХХ". Если вы проанализируете темы и каталоги этих курсов, то обнаружите, что в основном речь идет об этих направления; Теперь давайте проанализируем процесс разработки веб-интерфейса:
-
Примерно в 1995 году HTTP/1.0 использовался для извлечения данных, первая версия JavaScript использовалась для управления несколькими интерфейсными состояниями, а страницы отображались в голых HTML-тегах.
-
Примерно в 2005 году используйте HTTP/1.1 и AJAX для извлечения данных, используйте JavaScript для создания эффектов рисования форм и используйте CSS для украшения страниц.
-
Примерно в 2010 году используйте HTTP/1.1 и AJAX для извлечения данных, используйте jQuery для управления DOM для обработки логики внешнего интерфейса и используйте CSS для украшения страниц.
-
Примерно в 2015 году, с продвижением стандарта HTML5 и улучшением производительности браузера, внешний интерфейс начал входить в «я не могу учиться' эпоха:
- На уровне выборки данных, в дополнение к HTTP/1.1 и AJAX, появится HTTPS, HTTP/2 и WebSocket.
- На управлении уровнем государства, угловые, реагирование и VUE появляются, отныне, в настоящее время водитель состояния реагирования напрямую влияет на флаттер и SWIFTUI дизайн.
- На уровне страницы рендеринга в дополнение к традиционным HTML + CSS были добавлены такие концепции, как CSS3 и Canvas, а также были улучшены аудио- и видеофункции.
-
В последние годы сетевой протокол стабилизировался, и через несколько лет серьезных изменений не будет; статус React и Vue в Китае в основном стабилен, а куча фронтендов пялится на индикатор выполнения GitHub и прочее. обновления версии много моли в слое рендеринга. , я наконец-то избавился от IE6, а там всякие мелкие программки. Неэкономично и нереально писать один и тот же набор бизнес-логики несколько раз. В данное время , выходили разные кроссовые решения
После некоторого анализа эта трехосная теория кажется правдой.Давайте пойдем в этом направлении и подумаем о нижнем слое: как реализуются эти три функции?
- В направлении выборки данных для отправки данных используется стек сетевых протоколов, но очень нереально позволить внешнему интерфейсу напрямую заниматься программированием сокетов, поэтому нам нужно инкапсулировать сетевую операцию в виде библиотеки и позволить приложению вызов слоя
- Что касается страницы рендеринга, последний должен отправить соответствующую примитивную информацию в графический процессор для рендеринга через различные графические API (OpenGL/Metal/Vulkan/DirectX).Многие графические маршруты переднего плана заканчиваются треугольником.Это также крайне нереально рисовать UI, не говоря уже об огромном объеме работы в системе верстки, так что эти задачи все связаны сдвижок рендерингаСделанный
- В направлении управления состоянием вы можете использовать глобальные переменные для управления состоянием, а конечный результат должен быть взорван коллегами.Сейчас основные решения используют различные фреймворки и среды выполнения для управления состоянием, а хост-среда этой среды выполнения часто язык.виртуальная машина, при этом отправной точкой выборки данных также является та же виртуальная машина
После вышеприведенного анализа мы видим, что есть два основных технических ядра интерфейса:виртуальная машинаа такжедвижок рендерингаЭто также означает, чтоЕсли мы хотим заниматься кросс-энд разработкой, мы должны унифицировать виртуальную машину и движок рендеринга.
2. Виртуальная машина и движок рендеринга
1. Веб-страница: JS Engine + WebKit
Поскольку движок Google Blink является ответвлением WebKit от Apple, для удобства описания мы будем использовать WebKit вместо механизма рендеринга браузера.
Веб-страницы являются самым дешевым и быстрым кросс-терминальным решением. Благодаря открытой концепции Интернета веб-страницы по своей сути являются межсетевыми.Независимо от того, какая среда рендеринга, WebView является важным основным компонентом.
Стоимость доступа у разработчиков также крайне низкая.Основная технология – набор веб-разработки.Главная головная боль для фронтенда – движок рендеринга.Проблема установкиа такжепроблемы с производительностью.
Сейчас основными движками JS являются JavaScriptCore от Apple и V8 от Google, а основными движками рендеринга являются Webkit от Apple и Blink от Google. Несмотря на наличие спецификации W3C, каждый производитель браузера реализует браузер в соответствии со спецификацией, которая также является основой для перекрестных веб-страниц. Проблема в том, что в реализации ядра браузера всегда есть небольшие пробелы, некоторые реализации не соответствуют спецификации, а некоторые реализации сами содержат ошибки, что является существенной причиной того, что интерфейс не может избавиться от требований адаптации.
Еще одна проблема с производительностью. На самом деле, скорость рендеринга самого WebKit по-прежнему очень высока, но она ограничена некоторыми функциями браузера, такими как чрезвычайно сложные и динамические свойства CSS, слияние дерева DOM и CSSOM, а основной поток должен быть приостановлен для ожидания выполнение JS. Чтобы снизить производительность и оптимизировать производительность внешнего интерфейса, нам обычно приходится выполнять обрезку на основе этих характеристик браузера, но независимо от того, как оптимизировать, все еще существует большое расстояние от Native с точки зрения производительности страницы и интерактивный опыт.
2. Web PLUS: JS Engine + WebKit + собственные возможности
Проще всего просто закинуть URL в WebView.На самом деле это может решить большинство проблем.Ведь 90% работы фронтенда это отрисовка UI и написание бизнес логики,но есть еще 10% функций которые нельзя сделать, например, синхронизировать состояние с Native и вызвать некоторые системные функции.
Для достижения двусторонней связи между клиентом и веб-страницей обычно необходимо использоватьJSBridgeобщаться,«Принципы JSBridge»Эта статья представляет собой хорошее резюме, и заинтересованные студенты могут ее прочитать.
JSBridge просто решает проблему вызова друг друга между Native и Web Что, если я хочу использовать Native для улучшения Web? Вот некоторые исследования:
-
Разогреть: Создайте и инициализируйте веб-просмотр заранее и даже реализуйте пул контейнера WebView, чтобы уменьшить время запуска веб-просмотра
-
тайник: Предварительно создавать общие веб-ресурсы в Native, а затем перехватывать сетевые запросы браузера и перенаправлять их на локальные, чтобы ускорить скорость загрузки веб-ресурсов (также называемая схемой «автономного пакета»);
-
угонять: например, веб имеет относительно слабый контроль над загрузкой сети, и некоторые способные производители будут перехватывать все сетевые запросы и передавать их в Native, который может более гибко управлять веб-запросами.
-
заменять: Заменить обычно относится к замене веб-
Imgэтикетки иVideoЭтикетка, наиболее распространенным местом является основные новости клиентов. Из-за динамичного характера новостей в режиме реального времени новости распространяются различными редакторами / самостоятельными СМИ через фоновых редакторов.Мощная типографика для ИнтернетаДля отображения текстового контента, но для скорости загрузки и удобства просмотра изображения и видео заменяются нативными компонентами.
После вышеперечисленных шагов скорость веб-страницы может в основном достигать уровня открытия в секундах.Наиболее типичными из них являются несколько крупных новостных клиентов.Вы можете начать работу и испытать это.
3. Небольшая программа: JS Engine + WebKit
Мини-программы, характерная архитектура в Китае, по сути означают, что после того, как WeChat станет черной дырой трафика, он хочет стать рынком распределения трафика для управления и распределения своего собственного трафика, поэтому это структура с сильным коммерческим привкусом.
Апплет не имеет особой инновационной точки в технологии.По сути кастрированная версия веб-страницы, так что после того, как апплет WeChat вышел, различные олигархи трафика запустили свой собственный апплет, как и жаловались некоторые люди,Существует 9 способов реализации апплета,базовая реализация диверсифицирована,и единого стандарта для каждой фабричной реализации нет.В конце концов это на корм разработчикам.Мне нечего вводить,так что все.
4. React Native: JS Engine + Native RenderPipeLine
React был выпущен в 2013 году, а React Native — двумя годами позже. Первые несколько кросс-сегментных решений в основном основаны на технологии браузера. Инновация кросс-сегментного решения RN заключается в том, что оно сохраняет JS Engine, который находится на путь движка рендеринга. , он не создавал свои собственные колеса, а повторно использовал существующий конвейер рендеринга Native.
Преимущество этого заключается в том, что при сохранении JS Engine веб-экосистема может быть повторно использована в максимальной степени.В конце концов, язык с наибольшим количеством колес на GitHub — это JavaScript; преимущество повторного использования Native RenderPipeLine заключается в том, что он свободен от исторических бремя WebKit, а конвейер рендеринга относительно короче, производительность, естественно, повысится.
Итак, вопрос в том, как RN достигает кросс-энда? На самом деле все это зависит от vdom React.
vdom
Некоторые статьи в сообществе фронтенда обсуждают vdom, и они всегда будут объясняться с точки зрения производительности и удобства разработки.С точки зрения чистого веб-интерфейса это действительно характеристики vdom, но это не причина почему vdom действительно популярен. Большая ценность вдома в том, что,Люди видят надежду кросс-энд разработки от vdom, поэтому для React Native было вполне естественно следовать за React. Почему ты это сказал? Это должно вернуться к парадигме разработки пользовательского интерфейса.
Существует две основные парадигмы разработки пользовательского интерфейса:Графический интерфейс немедленного режимаа такжеГрафический интерфейс сохраненного режима.
Проще говоря, IMGUI полностью обновляется каждый кадр, что в основном используется в областях с высокой производительностью в реальном времени (игровые САПР и т. д.); RMGUI — самая обширная парадигма пользовательского интерфейса, и каждый компонент инкапсулирован в объект, который удобен для управления состоянием и сложных вложенных макетов. Будь то веб-страница, iOS, Android или Qt и другие области разработки настольных компьютеров, все они основаны на RMGUI. Конкретные детали различий между ними можно найти в этомЗнать ответи этоYouTube видео.
Давайте вернемся к React Native. Поскольку все нативные конвейеры рендеринга iOS и Android основаны на парадигме RMGUI, всегда есть сходства. Например, все пользовательские интерфейсы представляют собой древовидные вложенные макеты с обратными вызовами событий и так далее. В это время выходит роль vdom:
Как чистый объект, vdom может четко извлекать вложенную структуру макета иЭто абстрактное описание не зависит от платформы., затем мы можем использовать JS для создания vdom, затем сопоставить vdom со структурой макета Native и, наконец, позволить Native визуализировать представление для достижения цели кроссплатформенной разработки.
Здесь, если вы немного разбираетесь в принципах компиляции, вы найдете vdom иIRНекоторые из них похожи, они также абстрагированы от промежуточного состояния платформы, вдом подключен к React и подключен Native RenderPipeLine, IR подключен к фронтенду компилятора, а бэкэнду компилятор. Нам нужно заботиться только о логической обработке первой половины. Сделайте вторую половину.
Hermes
В 2019 году, чтобы оптимизировать производительность React Native, Facebook напрямую запустил новый JS Engine ——Hermes,Официальный пост в блоге ФБВведено много преимуществ. Лично я считаю, что самым большим событием является добавление AOT. Традиционный процесс обработки и загрузки JS выглядит следующим образом:
Babel 语法转换→Minify 代码压缩→install 下载代码→Parse 转为 AST→Compile 编译→Execute 执行
После того, как Hermes присоединился к AOT,Babel,Minify,Parseа такжеCompileВсе эти процессы выполняются на компьютере разработчика, а байт-код выдается непосредственно для запуска Hermes.
Преимущество этого заключается в том, что это может значительно сократить время компиляции JS. Если вы не верите, вы можете использовать Chrome для анализа нескольких крупных веб-сайтов. Время синтаксического анализа и загрузки JS в основном составляет более 50% время, и некоторые тяжелые веб-сайты могут составлять 90% времени.Это нормально для настольных приложений.Для мобильных платформ со слабой мощностью и процессором это настоящие убийцы производительности.Добавление Hermes может значительно улучшить эту ситуацию.
В настоящее время React Native 0.64 также поддерживает Hermes.Если у вас есть студенты бизнес-школы RN, вы можете поиграть в нее и посмотреть, насколько улучшилась производительность на iOS.
5.Flutter: Dart VM + Flutter RnderPipeLine
В последнее время Flutter является популярным кросс-энд решением, и многие люди думают, что это идеальное кросс-энд решение, В конце концов, в эпоху программного обеспечения для настольных компьютеров, конечное кросс-энд решение — это Qt. Их общая черта в том, что они поставляются с набор движков рендеринга.Концевые различия могут быть сглажены.
Создание Flutter по-прежнему очень интересно,здесьЕсть интервью с Эриком. В видео говорится, что у Эрика почти десятилетний опыт работы в области веб-рендеринга. Однажды в Chrome они провели эксперимент. проверено.в 20 раз быстрее, поэтому Google начал внутреннюю настройку проекта, и появился Flutter. Что касается причины, по которой Flutter выбрал Dart, ходили слухи.Рядом с командой разработчиков Flutter находится команда разработчиков Dart., хорошо быть рядом с транзакциями PY, все равно Dart никем не используется, исторической нагрузки нет, и он вполне может удовлетворить потребности Flutter.
Архитектура Flutter также относительно ясна:
- Dart VM для виртуальных машин. Dart поддерживает как JIT, так и AOT, что может одновременно обеспечить эффективность разработки и эффективность эксплуатации.
- Механизм рендеринга сначала передает данные представления, созданные Dart, в Skia, а затем Skia обрабатывает данные в два графических API OpenGL/Metal и, наконец, в графический процессор для рендеринга, что намного понятнее, чем конвейер рендеринга WebKit в целом.
С чисто точки зрения, Flutter является самым тщательным.Виртуальная машина и движок рендеринга не используют зрелые решения в отрасли, а создают свои собственные.Преимущество в том, что нет необходимости адаптироваться, а недостаток в том, что это слишком ново и бизнес При разработке мы часто сталкиваемся с неловким состоянием отсутствия колес.Если Google активно продвигает его, а отечественные производители продолжают следить за ним, перспективы по-прежнему очень радужные.
6. Исследование в других направлениях: JS Engine + Flutter RnderPipeLine?
В сообществе есть мнение, что самый большой недостаток Flutter заключается в том, что его нельзя разработать на JavaScript. В настоящее время некоторые люди могут подумать, что если мы объединим веб-технологии и технологию Flutter, используем JS Engine для связи с крупнейшим и наиболее активным JS-сообществом в мире и используем механизм рендеринга Flutter для подключения к высокопроизводительному рендерингу, не будет быть красивой для национальной безопасности и народной музыки?
В настоящее время некоторые крупные производители провели некоторые исследования. Я прочитал некоторые анализы и архитектуру проекта, и я чувствую, что они сделали низкопрофильную версию React Native. Существующая архитектура React Native имеет узкое место в производительности, которое заключается в том, что стоимость межъязыковых звонков относительно высока, а цепочка звонков этих больших фабрик насчитывает целых 4 шага:JS -> C++ -> Dart -> C++, еще больше сводит с ума.В настоящее время неудобно использовать RN или Flutter напрямую, независимо от того, начинает ли он работать или продвигается.
3. Недостатки каждого межсетевого решения
Нельзя, чтобы у кросс-энд решения были только плюсы, да и минусы у каждого решения тоже очевидны, кратко перечислю их ниже:
- страница в Интернете: Производительность — это препятствие в прошлом, и Apple четко указала, что приложения оболочки WebView не приветствуются и существует опасность отказа.
- Веб ПЛЮС: Технические инвестиции очень высоки, играть могут только крупные фабрики.
- Апплеты: недружелюбен к разработчикам, очень короткий технический период полураспада.
- React Native: В принципе можно только UI рисовать.Когда он глубокий, то только JS вообще проблему не решит.Java OC надо учить, а требования к разработчикам относительно высокие.
- Flutter: поддержка Android очень хороша, но платформа iOS имеет сильное чувство взаимодействия и фрагментации, и, как и в случае с проблемой RN, когда вы углубитесь, вы должны изучить знания о клиентской разработке, а требования к разработчикам относительно высоки.
В целом, если жертвовать определенным пользовательским опытом, кросс-энд решение может повысить эффективность разработки разработчиков и эффективность работы компании.Я лично считаю, что до тех пор, пока рентабельность инвестиций определенного решения относительно высока, его еще можно запустить в производство.
4. Резюме
Это конец этой статьи Я усовершенствовал каждую межсетевую технологию до виртуальной машины и технологии движка рендеринга, а затем разобрал каждое межсетевое решение с точки зрения этих двух основных технологий. Как только концепции прояснены, при столкновении с техническими сценариями, такими как настройка производительности, вы можете понять основное противоречие, быстрее и лучше находить и решать проблемы.
Если вы найдете мою статью полезной для вас, насобиратьВ процессе нужно помнитьподобноа такженажмите, чтобы увидетьО, спасибо, это действительно много значит для меня 🌟!
Наконец, я рекомендую волну моей публичной учетной записи WeChat:Лаборатория тушеных яици мой личный блог:supercodepower.com, В настоящее время основное внимание уделяется интерфейсным технологиям, а также есть небольшие исследования в области графики, приглашаю всех подразнить~
5. Рекомендуемое чтение
[Вопросы и ответы] Почему ваш Charles не может перехватывать пакеты?
5 самых запутанных знаний в webpack
[Самая полная сеть] Руководство по оптимизации производительности React Native