Автор Цао Юаньян (Cao Yuanyan) по прозвищу Yuanyan в Alibaba.
Развитие и итерация передовых технологий очевидны. Непрерывная разработка новых технологий также поддерживает постоянное расширение сценариев интерфейсных приложений, от Web и Weex до Node.js и функций как услуги. В нашем развитии мы можем видеть части, которые не изменились. Стремление к лучшему пользовательскому опыту — единственная постоянная обязанность в непрерывном развитии терминальных технологий. В Alibaba сложность и популярность фестиваля Double 11 Shopping Festival делает его самым прямым и эффективным способом всестороннего тестирования технологии. Прошлогодний Double 11 стал первым годом, когда Rax с открытым исходным кодом от Alibaba был полностью реализован. В этой статье описывается, как Rax предназначен для улучшения взаимодействия с пользователем.
Легкий
Что значит «более легкий»? Это означает, что время парсинга и компиляции движка JS эффективно сокращается. В наших исторических тестах на некоторых Android-устройствах с низкой производительностью общее время инициализации bundle.js занимает 300 мс и более. Это значительная часть времени, которая влияет на пользовательский опыт. Таким образом, упрощение схемы рендеринга является одним из наиболее эффективных методов улучшения взаимодействия с пользователем при условии, что он предлагает те же самые функции.
В начале этого года мы запустили план Rax 1.0, который поддерживает хуки. Использование хуков может уменьшить бизнес-код. Кроме того, новый Rax 1.0 легче и быстрее предыдущего Rax 0.6, а масштаб кода ядра уменьшен с 57 тысяч до всего 17 тысяч.
Адаптивный рендеринг гидратации
Наиболее важной особенностью Rax Hydration является возможность автоматической адаптации. Что такое автоматическая адаптация? По сравнению с React Hydration мы можем заранее сгенерировать HTML-код на стороне сервера, а затем запустить Hydration для привязки событий к существующей структуре DOM. Если существующая структура DOM не соответствует текущей структуре вывода bundle.js, React может исправить различия в текстовом содержимом. Однако не гарантируется, что различия в атрибутах могут быть исправлены, если они несовместимы. Кроме того, когда структуры DOM несовместимы, React может столкнуться с проблемой двойного рендеринга, что замедляет рендеринг.
При разработке решения Rax Hydration главными целями были совместимость и простота использования. Поэтому Rax будет по возможности повторно использовать существующие узлы и исправлять все различия. Rax имеет несколько типов коррекции: коррекция текста, коррекция атрибутов и коррекция узлов. Если узел не существует во время коррекции узла, он также удаляется, чтобы обеспечить правильность результата рендеринга.
Рендеринг моментального снимка
Рендеринг моментальных снимков на терминале — не новая концепция. Например, на домашней странице Taobao Mobile есть механизм моментальных снимков. С помощью этого механизма последняя открытая страница отображается каждый раз, когда вы открываете Taobao Mobile. Рендеринг моментальных снимков Rax и адаптивный гидратационный рендеринг делают процесс рендеринга моментальных снимков более быстрым и естественным.
Технология моментальных снимков Rax также требует предварительно существующего состояния. При использовании технологии моментальных снимков мы можем сохранить состояние страницы в виде моментального снимка в любое время. После этого при следующей загрузке страницы снимок страницы будет загружен из локального хранилища. После загрузки снимка нам нужно обновить его до последнего состояния. В прошлых технических решениях, когда новая страница была завершена, мы устанавливали ее на текущую страницу моментального снимка, настроенную для взаимодействия, а затем устанавливали последнюю страницу. Этот процесс может вызвать мигание страницы. Однако, используя Adaptive Hydration Rendering Rax для обновления моментальных снимков до последнего состояния, этой проблемы можно избежать. Это также результат глубокого внимания к совместимости как важной цели дизайна Rax Hydration.
Рендеринг на стороне сервера
Рендеринг на стороне сервера (SSR) — это возможность, которая нас очень интересует в текущей тенденции облако плюс терминал. Поэтому в этом году было сделано много попыток и прорывов в рендеринге Rax на стороне сервера. Например, были попытки реализовать полный рендеринг на стороне сервера с помощью C++. Однако эффективность преобразования типов между JS и C++ не так хороша, как при использовании только JS. Мы также рассмотрели возможность реализации некоторых функций чисто строковых операций с помощью C++. Однако эти попытки не оправдали наших ожиданий.
Наконец, мы нашли решение в проекте. Мы рассчитали и объединили строки перед компиляцией и из следующих тестовых данных узнали, что производительность SSR Rax в восемь раз выше, чем у React. Эти результаты превосходят даже XTPL. Это дает нам возможность использовать JSX для замены XTPL в соответствующих сценариях.
-----------compare renderToString---------- React(16.12.0)#renderToString x 1,664 ops/sec ±1.40% (84 runs sampled) Rax(1.0.13)#renderToString x 13,411 ops/sec ±1.05% (85 runs sampled) Preact(10.0.5)#renderToString x 1,237 ops/sec ±2.18% (84 runs sampled) Xtpl(3.4.2)#renderFile x 11,335 ops/sec ±8.17% (69 runs sampled)The benchmark was run on: PLATFORM: Darwin 17.5.0 CPU: Intel(R) Core(TM) i7-7660U CPU @ 2.50GHz SYSTEM MEMORY: 16GB NODE VERSION: v10.11.0
Родной рендеринг
Принципы работы рендеринга на собственной стороне (NSR) и SSR очень похожи. Самое большое отличие состоит в том, что NSR завершает процесс выполнения SSR на клиенте, предоставляя возможности SSR, не полагаясь на сервер. Сравнение рендеринга NSR и рендеринга на стороне клиента (CSR):
Персонализированный рендеринг
Для чего разработан персонализированный рендеринг? CSR, SSR, NSR и SR имеют соответствующие применимые сценарии. Когда ваша сеть достаточно надежна, любой метод рендеринга обеспечивает идеальное взаимодействие с пользователем. Однако так ли это на самом деле? Из данных внешнего опыта этого Double 11 Shopping Festival мы видим, что менее 50% пользователей могли взаимодействовать в течение 3 секунд на первом экране, 90% пользователей могли взаимодействовать в течение 0–7 секунд, а 10% пользователей могли Итак, через 7 секунд:
В этом случае на месте оказываются как пользователи с плохой сетью, так и пользователи с устройствами с низкой производительностью, и, по логике вещей, устройства с низкой производительностью и плохие сети могут иметь высокую скорость повторного подключения. Поэтому необходимо выбрать подходящее решение для рендеринга для различных сценариев. Например, если сетевые условия не идеальны, рендеринг NSR предпочтительнее для рендеринга на клиенте, а рендеринг SSR идеален для рендеринга вне клиента. Если производительность устройства неудовлетворительна, рендеринг SSR предпочтительнее для рендеринга как на клиенте, так и вне его. Поэтому мы считаем, что будущие методы рендеринга должны быть персонализированными и специфичными для конкретного сценария.
Благодаря нашим непрерывным усилиям по совершенствованию этих технологий для повышения эффективности взаимодействия, мы ожидаем, что торговый фестиваль Double 11 в 2020 году принесет большему количеству людей опыт в течение 3 секунд, и гораздо меньше людей будут в среднем дольше 7 секунд.
