Фреймворк апплета Didi с открытым исходным кодом Mpx

Апплет WeChat MobX

MpxЭто расширенная структура апплета, предназначенная для улучшения опыта разработки апплета.Благодаря Mpx мы можем использовать самый передовой опыт веб-разработки (Vue + Webpack) для разработки апплета с глубокой оптимизацией производственной производительности.Mpx имеет следующие отличные функции:

  • Функция ответа на данные (просмотр/вычисление)
  • Расширенный синтаксис шаблона (динамические компоненты/привязка стиля/привязка имени класса/встроенные функции событий/двусторонняя привязка и т. д.)
  • Глубокая оптимизация производительности (собственные пользовательские компоненты/setData на основе сбора зависимостей и изменений данных)
  • Компиляция Webpack (npm/круговые зависимости/Babel/ESLint/прекомпиляция css/оптимизация кода и т. д.)
  • Разработка компонента в одном файле
  • Управление состоянием (спецификация Vuex/мультиэкземпляр/слияние)
  • Взаимодействие между командами (пакеты)
  • Возможность повторного использования логики (примеси)
  • Поддержка строительных лесов
  • Полная поддержка собственных спецификаций апплета
  • Поддержка апплета Alipay

Идеи дизайна

В настоящее время основные платформы апплетов в отрасли в основном включают WePY, mpvue и Taro, каждая из которых переводит другие спецификации синтаксиса в спецификации синтаксиса апплета, которые мы называем платформами перевода. В отличие от трех вышеперечисленных, Mpx является расширенной структурой, основанной на спецификации синтаксиса апплета.Мы используем отличные синтаксические функции в Vue для улучшения апплета, вместо того, чтобы позволять пользователям напрямую использовать синтаксис vue для разработки апплета, причина принятия этого Этот дизайн в основном основан на следующих соображениях:

  • Фреймворк перевода не может поддерживать все синтаксические функции исходного фреймворка (например, динамические функции в шаблонах Vue или динамически генерируемый jsx в React). Пользователи могут столкнуться с непредвиденными ошибками и неопределенностями при разработке с использованием синтаксиса исходного фреймворка.
  • Технические характеристики самого апплета постоянно обновляются и совершенствуются.Многие новые технические спецификации не могут поддерживаться в рамках перевода или требуют высоких затрат на поддержку.Для расширенной среды, если новые технические спецификации не противоречат расширенным функциям , непосредственная поддержка

Техническая реализация

Когда апплет был впервые запущен, он не поддерживал пользовательские компоненты и не мог разрабатываться как компоненты. WePY и mpvue проделали ряд работ для поддержки этой ключевой функции, значительно улучшив пользовательский опыт и эффективность разработки. Компонентная поддержка WePY и mpvue основана на компонентной инкапсуляции компиляции.Шаблон компонента, написанный пользователем, будет скомпилирован как часть шаблона на странице, данные, определенные в компоненте, будут скомпилированы в данные на странице. , и данные будут скомпилированы для компонента. Update также вызывает Page.setData на основе карты пути. Это было отличное техническое решение по техническим условиям того времени, но у этого решения были проблемы с производительностью в сложных апплетных приложениях, потому что объем данных страницы в этом решении был бы большим, и частичное обновление каждого компонента фактически стало бы глобальное обновление на уровне страницы, приводящее к значительному снижению производительности на страницах с множеством компонентов.

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

Сравнение производительности набора данных страниц и компонентов

Component Page
локальное обновление 1975ms 7186ms
Глобальное обновление 6210ms 24612ms

Описание показателей производительности:
Локальное обновление: в документе 1000 узлов, и одному узлу требуется время для обновления 1000 раз;
Глобальное обновление: в документе 5 узлов, и для 5 узлов требуется 1000 независимых обновлений. Приведенные выше данные протестированы в среде апплета iPhone7 WeChat.

Реагирование на данные и оптимизация производительности

Как основная функция Vue, ответ на данные широко используется в нашей повседневной разработке, что может значительно улучшить опыт и эффективность разработки интерфейса.Самое раннее рассмотрение на ранней стадии проектирования фреймворка заключалось в том, как добавить функции ответа на данные в разработку апплета. . В реализации ответа на данные мы представили MobX, известный проект с открытым исходным кодом, который реализует возможности чистого ответа на данные. С помощью MobX и примесей мы создали гибкую систему управления данными на ранней стадии создания компонента апплета, которая отслеживала все данные в компоненте апплета (данные/реквизиты/вычисленные) и управляла рендерингом представлений на основе изменений данных (setData). и обратный вызов часов, зарегистрированный пользователем, реализующий опыт программирования ответа на данные в Vue. В то же время мы внедрили стандартное хранилище управления данными Vuex на основе пакета MobX, которое может легко внедрять компоненты для глобального управления данными. Чтобы улучшить опыт совместной разработки, мы добавили в магазин функцию слияния нескольких экземпляров.Разные команды поддерживают свои собственные магазины и могут объединять другие или общедоступные магазины для создания новых экземпляров магазина, когда это необходимо.Более гибкий и удобный межкомандный режим управления данными для модулей в Vuex

В качестве платформы разработки ответа на данные, которая берет на себя setData апплета, мы придаем большое значение производительности рендеринга Mpx.Из предложений по оптимизации производительности, упомянутых в официальной документации апплета, мы можем знать, что setData является наиболее важным для Производительность апплета Существует два основных направления оптимизации setData:

  1. Максимально сократите частоту вызовов setData.
  2. Минимизируйте объем данных, передаваемых в одном наборе данных.

Для достижения вышеуказанных двух направлений оптимизации мы проделали следующую работу:

  • Скомпилируйте статический шаблон компонента в исполняемую функцию рендеринга и соберите зависимости данных шаблона с помощью функции рендеринга. Только когда данные зависимости в функции рендеринга изменятся, будет запущен setData компонента апплета. для обеспечения тика используется асинхронная очередь.В лучшем случае setData будет выполняться только один раз.Этот механизм очень похож на механизм рендера в Vue, что значительно снижает частоту вызовов setData;
  • В процессе компиляции шаблона в функцию рендеринга мы также записываем и выводим пути данных, используемые в шаблоне.Каждый раз, когда нам нужно setData, мы будем выполнять diff на основе этих путей данных и предыдущих данных, и передавать только измененные данные через путь данных.SetData выполняется таким образом, что обеспечивает минимальный объем данных, передаваемых каждый раз, когда setData, и позволяет избежать ненужных операций setData, еще больше уменьшая частоту setData. На основе приведенных выше оптимизаций мы значительно уменьшили частоту вызова апплета setData и объем передаваемых данных, что значительно лучше, чем схема данных полного трека в первой версии Mpx.

Эффект оптимизации Mpx setData

Устаревшие мегапиксели Новая версия Мпкс
setData раз 164 88
setData количество данных 370kB 38kB

Приведенные выше данные получены статистикой более сложных мини-программ после фиксированного интерактивного процесса.

Mpx数据响应机制流程示意图
Блок-схема механизма ответа данных Mpx

Скомпилировать и построить

Мы надеемся использовать Webpack, самый мощный и экологически разработанный инструмент для компиляции и построения, для реализации компиляции и построения небольших программ, чтобы пользователи могли получить передовой и мощный опыт инженерной разработки в веб-разработке. Студенты, которые использовали Webpack, знают, что, вообще говоря, Webpack упаковывает ряд фрагментированных модулей, используемых в проекте, в один или несколько пакетов, а файловая структура, необходимая для апплета, очень дискретна. Как это сделать? Противоречие между ними стать нашей самой большой проблемой. Очень интуитивно понятная и простая идея состоит в том, чтобы просмотреть весь каталог src и добавить каждый файл .mpx в качестве записи в Webpack для обработки.При этом есть две основные проблемы:

  1. Файлы .mpx, которые не используются в каталоге src, также будут скомпилированы и выведены, и в конечном итоге будут упакованы апплетом в пакет проекта, бессмысленно увеличивая размер пакета;
  2. Для файлов .mpx в node_modules мы не думаем, что обход node_modules — хороший вариант.

В конце концов, мы приняли метод, основанный на анализе зависимостей и динамическом добавлении записей, пользователю нужно только настроить файл записи app.mpx в конфигурации Webpack, а загрузчик будет парсить домен страниц и домен usingComponents в json при парсинге в json. Объявленный путь добавляет эти файлы в систему сборки Webpack путем динамического добавления записей (обратите внимание, что здесь добавляются записи вместо зависимостей, потому что только записи могут генерировать независимые файлы в соответствии с дискретной файловой структурой апплета), и рекурсивно выполнять этот процесс до тех пор, пока не будут добавлены все файлы .mpx, используемые во всем проекте.Перед выводом мы используем возможности CommonsChunkPlugin/SplitChunksPlugin для извлечения повторно используемых модулей во внешний пакет, чтобы убедиться, что окончательный сгенерированный пакет не содержит повторяющихся модулей. Мы предоставляем подключаемый модуль Webpack и загрузчик, соответствующий файлу .mpx, для реализации вышеуказанных операций.Пользователям нужно только добавить его в конфигурацию Webpack, чтобы упаковать апплет обычным образом, как упаковывают веб-проекты, без какой-либо предварительной и последующей обработки. операции обработки, поддерживая полную экологию самого Webpack.

Mpx编译构建机制流程示意图
Блок-схема механизма компиляции и построения Mpx

Текущее состояние и будущее

В настоящее время платформа Mpx широко используется в Didi, поддерживая реализацию небольших программ, таких как Didi Chuxing, Qingju Bicycle, Street Rabbit Motorcycle, маркетинг и автомобильную одежду.Онлайн-операция стабильна и получила много положительных отзывов. . . . В будущем мы продолжим следить за последними техническими стандартами WeChat и Alipay, продолжая итеративно оптимизировать фреймворк, а также будем адаптироваться к большему количеству мини-программных платформ. Из-за нашего первоначального дизайнерского замысла и сосредоточения внимания на улучшении опыта разработки мини-программ, Mpx не обеспечивает кросс-H5 или даже кросс-нативную поддержку, но такие требования существуют в реальном бизнесе.В то же время мы будем продолжать поддерживать и обновить Mpx, потому что кросс-энд означает ограниченную гибкость и отсутствие возможностей Мы надеемся предоставить пользователям второй выбор.

Сравнение сходств и различий между Mpx и основными фреймворками апплетов в отрасли.

WePY mpvue Taro Mpx
спецификация кода настроить Vue React апплет+
Компонентная реализация Пакет страниц Пакет страниц Component Component
ответ данных проверка грязного значения Vue никто Mobx
государственное управление Redux Vuex Redux класс Vuex

Эпилог

Если вы сосредоточены на опыте разработки и производительности продукта, а также на разработке небольших программ, Mpx будет хорошим выбором. Наконец, я хотел бы поблагодарить отличные проекты, появившиеся в сообществе открытого исходного кода, которые дали нам бесконечное вдохновение и большую техническую помощь.

Github: github.com/didi/mpx

Используйте документацию:didi.github.io/mpx/

Связь с пользователем:кликни меня в группу