Апплет WeChat
Структура проекта
На рисунке выше показана структура проекта апплета WeChat. Страницы ниже включают каждую страницу апплета. Каждая страница состоит из четырех частей: структура страницы, стиль страницы, конфигурация страницы и логический код.
- структура страницы
Файл структуры страницы — index.wxml, который записывается с помощью пользовательских тегов WeChat.
- логика страницы
Логика страницы написана на JavaScript.
- таблица стилей страницы
Подобно файлам CSS, для определения стилей элементов на странице.
- конфигурация страницы
Разрешения в информации о конфигурации страницы.
Технический отбор мини-программ WeChat
Характеристики позиционирования небольших программ легкие и быстрые.Для этих двух характеристик WeChat сделал некоторые соображения при техническом выборе.
Методы рендеринга интерфейсов
- Рендеринг с использованием чистых нативных методов на стороне клиента
Недостатки: нельзя динамически упаковывать и динамически распространять.
- Рендеринг с использованием чистых веб-технологий
Недостаток: если мы используем чистую веб-технологию для рендеринга апплета, мы можем столкнуться с некоторыми проблемами производительности на некоторых страницах со сложным взаимодействием, это связано с тем, что в веб-технологии рендеринг пользовательского интерфейса и выполнение сценария JavaScript выполняются в одном потоке, что легко приводит к некоторым проблемам. логические задачи, вытесняющие ресурсы рендеринга пользовательского интерфейса.
- Между нативной технологией на стороне клиента и веб-технологией есть технология, которая сочетает в себе свои характеристики для рендеринга.
С точки зрения рендеринга нижнего уровня PhoneGap и WeChat JS-SDK похожи, они оба по-прежнему используют ядро браузера для рендеринга интерфейса. RN отличается.Хотя он написан с использованием веб-технологий, он также использует характеристики интерпретации и выполнения JavaScript, но RN использует собственный рендеринг на стороне клиента в нижней части рендеринга. Мы выбираем гибридную технологию, аналогичную WeChat JSSDK, то есть интерфейс в основном воспроизводится с помощью зрелой веб-технологии, дополненной большим количеством интерфейсов для предоставления богатых собственных возможностей на стороне клиента. В то же время каждая страница апплета отображается с помощью другого веб-представления, что может обеспечить лучший интерактивный опыт, быть ближе к собственному интерфейсу и избежать обременительной задачи одного веб-представления.
Причины, по которым WeChat не выбрал RN
-
Стили, поддерживаемые RN, являются подмножеством CSS, которое не может удовлетворить растущие потребности веб-разработчиков, а трансформация RN сопряжена со значительными затратами и рисками.
-
Есть еще некоторые нестабильные проблемы при существующих возможностях RN, такие как производительность и ошибки. RN должен передать всю работу по рендерингу собственному рендерингу клиента.На самом деле, некоторые простые элементы интерфейса полностью компетентны и очень стабильны с использованием рендеринга веб-технологий.
-
У RN есть некоторые непредсказуемые факторы, такие как предыдущие проблемы с лицензированием.
Рендеринг нативных компонентов
В Android собственный метод внедряется в объект окна WebView, который в конечном итоге будет инкапсулирован в уровень совместимости, такой как WeiXinJSBridge, который в основном предоставляет два метода вызова (invoke) и прослушивания (on). Разработчик вставляет собственный компонент.Вообще говоря, компонент вставляется в дерево DOM во время его работы, и клиентский интерфейс будет вызываться, чтобы сообщить клиенту, где отображать собственный интерфейс. Когда последующие разработчики обновляют свойства компонента, интерфейс обновления, предоставляемый клиентом, также вызывается для обновления некоторых частей собственного интерфейса.
Проблемы и решения, связанные с веб-рендерингом
- Обеспечивает чистую и чистую среду выполнения JavaScript
Из-за гибкости JavaScript и богатых функций браузера это приведет к неконтролируемой конфиденциальности, поэтому WeChat предоставляет чистую среду выполнения JS, а элементы управления также настраиваются. Следовательно, использование этой среды песочницы полностью не может иметь каких-либо интерфейсов, связанных с браузером, и предоставляет только чистую среду интерпретации и выполнения JavaScript.Тогда такие функции, как ServiceWorker и WebWorker в HTML5, удовлетворяют таким условиям, обе из которых позволяют выполнять другой поток.JavaScript. Однако, учитывая, что апплет представляет собой архитектуру с несколькими веб-представлениями, каждая страница апплета обрабатывается и отображается с помощью другого веб-представления, и в этой архитектуре нам непросто использовать ServiceWorker в веб-представлении для управления всеми страницами апплета. Благодаря механизму интерпретации JavaScript в клиентской системе (с использованием встроенной инфраструктуры JavaScriptCore в iOS и среды JsCore, предоставляемой ядром Tencent x5 в Android), мы можем создать отдельный поток для выполнения JavaScript в этой среде. ниже выполняется код, относящийся к бизнес-логике апплета, то есть к уровню логики, о котором мы упоминали ранее. Задачи, связанные с рендерингом интерфейса, все выполняются в потоке WebView, а какие интерфейсы рендерятся через код логического слоя, то этот слой, конечно же, является так называемым слоем рендеринга. Это источник двухпоточной модели апплета.
- Настройка этикетки
Чтобы предотвратить некоторые проблемы, вызванные определением тега, WeChat настроил набор языка тегов, WXML.После того, как этот язык тегов будет скомпилирован, он в конечном итоге сгенерирует HTML.
Разделение рендеринга и логики
Выше приведен выбор технологии рендеринга апплета.После выбора, поскольку рендеринг и логика не выполняются одним и тем же браузером, чистая среда JS визуализируется WebView, поэтому рабочая среда апплета делится на слои рендеринга. Слои логики, шаблоны WXML и стили WXSS работают в слоях рендеринга, а скрипты JS работают в логических слоях.
Уровень рендеринга и логический уровень апплета управляются двумя потоками: интерфейс слоя рендеринга использует WebView для рендеринга, логический уровень использует поток JsCore для запуска сценария JS. Апплет имеет несколько интерфейсов, поэтому на уровне рендеринга есть несколько потоков WebView. Связь между этими двумя потоками будет ретранслироваться через клиент WeChat, а сетевой запрос, отправленный логическим уровнем, также будет перенаправлен через Native. апплета показано на рисунке.
Изменения представлений, управляемых данными
В процессе разработки пользовательского интерфейса программе необходимо поддерживать состояние многих переменных и одновременно оперировать соответствующими элементами пользовательского интерфейса. По мере того, как интерфейс становится все более и более сложным, нам необходимо поддерживать множество переменных состояний и обрабатывать множество событий взаимодействия в интерфейсе, и вся программа становится все более и более сложной. Обычно представления интерфейса и переменные состояния связаны.Если есть какой-то «способ» привязать состояние к представлению (представление также может автоматически изменяться при изменении состояния), то мы можем сэкономить работу по ручной модификации представления.
Уровень логики и уровень рендеринга апплета — это два отдельных потока. На уровне рендеринга среда хоста преобразует WXML в соответствующий объект JS. Когда данные изменяются на логическом уровне, нам нужно передать данные с логического уровня на уровень рендеринга с помощью метода setData, предоставляемого хост-средой. , а затем сравните различия до и после. Примените различия к исходному дереву Dom и визуализируйте правильный интерфейс пользовательского интерфейса.
Измените данные сообщения с «Hello World» на «Goodbye» через setData, и узел, соответствующий сгенерированному объекту JS, изменится. В это время вы можете сравнить измененные части двух объектов JS до и после, а затем применить разница с исходным деревом Dom, чтобы достичь цели обновления пользовательского интерфейса, который является принципом «управляемого данными».
Обработка
Пользовательский интерфейс программных потребностей и взаимодействия с пользователем, например, пользователь может щелкнуть кнопку на вашем экране или нажать определенную область, такая обратная связь должна быть уведомлена разработчикам логического уровня, необходимо представить пользователю соответствующий статус обработки. Поскольку у WebView теперь есть функции только для рендеринга, поэтому для распространения для обработки событий микроканал был специально обработан, после перехвата всех событий, брошенных на логический уровень для обработки JavaScript.
Обработка диспетчеризации событий имеет два механизма: захват событий и всплывающая передача. Он передается в JCore через натив, и после реакции на соответствующие события через JS Дом модифицируется, изменения отражаются в виртуальном Доме, а затем выполняется реальный рендеринг.
передача данных
Апплет основан на двухпоточной модели, а это означает, что любая передача данных представляет собой связь между потоками, то есть будет определенная задержка. Это не похоже на традиционную сеть.Когда интерфейс необходимо обновить, пользовательский интерфейс будет отображаться синхронно, вызывая интерфейс обновления. В архитектуре апплета все становится асинхронным.
Асинхронность усложняет синхронизацию работы различных частей. Например, при рендеринге первого экрана уровень логики и слой рендеринга начнут инициализироваться одновременно, но слою рендеринга нужны данные логического слоя для рендеринга интерфейса.Если инициализация слоя рендеринга завершена быстро, необходимо дождаться инструкции логического уровня, чтобы перейти к следующему шагу. Следовательно, логический уровень и уровень рендеринга должны иметь определенный механизм для обеспечения правильной синхронизации.
В жизненном цикле каждой страницы апплета происходит обмен данными нескольких страниц. Уровень логики отправляет данные страницы (содержимое данных и setData) на уровень представления, а уровень представления возвращает пользовательские события на уровень логики.
Способ передачи данных через Json заключается в уменьшении объема интерактивных данных для повышения производительности.
механизм кэширования
Среда хоста апплета будет управлять кэшем данных разных апплетов.Место локального кэша разных апплетов является отдельным.Верхний предел пространства кэша каждого апплета составляет 10 МБ.Если текущий кэш достиг 10 МБ, он будет записан в cache через wx.setStorage вызовет обратный вызов fail.
Локальный кеш апплета не только изолирует пространство по размеру апплета, учитывая, что одно и то же устройство может входить в систему для разных пользователей WeChat, среда хостинга также изолирует кеши разных пользователей, чтобы избежать утечки конфиденциальных данных между пользователями.
Поскольку локальный кеш хранится на текущем устройстве, пользователь не может прочитать данные текущего устройства с другого устройства после смены устройства, поэтому не рекомендуется, чтобы ключевая информация пользователя существовала только в локальном кеше, и данные должны быть сохранены. хранятся на стороне сервера для постоянного хранения.
Апплет Alipay
Введение в программу Alipay Mini
Реализация апплета Alipay и реализация апплета WeChat примерно одинаковы, так что это в основном из-за различий в различиях.
Структура каталога программы Alipay Mini
Схема бизнес-архитектуры апплета Alipay
В механизме рендеринга апплет Alipay не только предоставляет метод JavaScript + Webview, но также предоставляет метод JavaScript + Native.В сценариях с высокими требованиями к производительности вы можете выбрать собственный режим рендеринга, чтобы предоставить пользователям лучший опыт.
архитектура времени выполнения
Модель программирования апплета разделена на несколько страниц, каждая страница имеет свой собственный шаблон, CSS и JS.При фактическом запуске JS-код бизнес-логики запускается в независимом движке JavaScript, а шаблон и CSS каждой страницы запускаются. в своих независимых веб-просмотрах, а страницы переключаются через функцию navigationTo.
Взаимодействие между страницей в каждом веб-просмотре и логикой в общем движке JavaScript осуществляется через службу сообщений.Некоторые события страницы будут передаваться в рабочую среду движка JavaScript через этот канал сообщений, и рабочая среда будет реагировать на событие. и сделать некоторые вызовы API. , которые можно настроить для некоторых возможностей, предоставляемых апплетом Alipay на стороне клиента. После обработки данные будут повторно отправлены в соответствующий контейнер рендеринга страницы для обработки, а данные и шаблоны будут объединены в создать окончательный пользовательский интерфейс.
Изоляция виртуальной машины программы Alipay Mini
Обычной практикой является запуск кода рендеринга в WebView, а затем запуск другого потока для запуска сервисворкера.Когда сервисворкеру необходимо обновить DOM, события и данные отправляются в поток рендеринга через канал сообщений для выполнения.Когда бизнес необходимо передать на слой рендеринга, объем данных относительно велик.Когда объект большой и объект более сложный, производительность взаимодействия будет низкой, поэтому мы предлагаем оптимизированное решение для этой ситуации.
Это решение преобразует исходный экземпляр виртуальной машины JS (т. е. Изолировать) в две части: глобальную среду выполнения и локальную среду выполнения.
-
Часть Global Runtime предназначена для хранения общих устройств и данных в одном глобальном экземпляре.
-
Локальная среда выполнения предназначена для хранения модулей и личных данных, связанных с самим экземпляром, которые не будут использоваться совместно.
В новой модели изоляции экземпляр v8 в веб-представлении является локальной средой выполнения, а экземпляр v8 в рабочем потоке также является локальной средой выполнения.Когда рабочий слой взаимодействует со слоем рендеринга, объект setData будет создан непосредственно в Общая куча, поэтому рендеринг Локальная среда выполнения слоя может напрямую считывать объект и использовать его для рендеринга слоя рендеринга, что снижает сериализацию и передачу объекта по сети, а также значительно повышает производительность при запуске и производительность рендеринга.
Оптимизация скорости первого экрана
Поскольку запуск апплета контролируется жизненным циклом, от процесса onLaunch -> onLoad -> onShow -> onReady -> работа пользователя -> выход на домашнюю страницу, любая ссылка в этом процессе может подвергаться объективному или субъективному При прерывании это может привести к тому, что сохраненная автономная страница будет неточной, и при запуске пользователю будет отображаться неправильная страница.
Поэтому для эффекта автономной кэш-рендеринга домашней страницы очень важно время сохранения страницы.Мы предоставляем время, которое может настроить разработчик.Есть два времени настройки: до завершения рендеринга и перед выходом из дома. страница. Для завершения рендеринга рендеринг домашней страницы завершается, и страница сохраняется как автономная кэшированная страница до того, как пользователь выполнит какие-либо операции. Перед тем, как покинуть домашнюю страницу, это означает, что после того, как пользователь выполнит ряд операций на домашней странице, страница, которую пользователь просматривает перед переходом на другие страницы, сохраняется как автономная кэшированная страница.
Для сцены, где возникает проблема с заставкой, это связано с тем, что кэшированная страница и реальная визуализированная страница разделены и представляют собой две независимые страницы.Кэшированная страница является статической страницей, а реальная страница является страницей, динамически созданной js, поэтому обычный метод: экран-заставка появляется, когда реальная страница создается, а кэшированная страница заменяется.
Чтобы решить эту проблему, мы используем виртуальный дом для решения этой проблемы.При загрузке кэшированной страницы поместите кэшированную страницу в исходный виртуальный дом.Виртуальный дом, сгенерированный после создания реальной страницы, и виртуальный дом кэшированной страницы отличается, а измененное содержимое передается в ядро браузера через исправление, и соответствующая страница отображается, так что можно обновить только частично измененное содержимое страницы, избегая обновления всей страницы и обеспечивая точность и реальную - время содержания.
Alipay использует преимущества ядра браузера UC
1.Память изображения: Для небольших машин сделали более строгим ограничением кэша изображения, сохраняя при сохранении опыта производительности, чтобы дополнительно ограничить использование кэша изображения; WEBVIEW более распространенный пул буфера изображения; Полная поддержка WebP, Apng Это еще и сохраняет формат изображения в формате памяти.
2.рендеринг памяти: В невидимом состоянии Webview собственное управление памятью не имеет специальной обработки, и ядро UC освобождает память рендеринга невидимого веб-просмотра; разумные настройки и настройка памяти рендеринга позволяют избежать снижения производительности прокрутки и чрезмерного использования памяти. .
3.JS-память: обрабатывайте gc памяти v8 более разумно и откладывайте выполнение полного gc при запуске, чтобы не влиять на трудоемкий запуск.
4.пиковое управление памятью: система уведомит ядро, когда памяти будет мало, и ядро UC может освободить модули, занятые некритической памятью, когда системе не хватает памяти, избегая появления oom и черных блоков рендеринга, вызванных чрезмерным освобождением; в некоторых случаях oom избегайте нативной логики ядра активно крашится, в случае крайне мало памяти некоторые функции недоступны вместо краша.