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:
- Максимально сократите частоту вызовов setData.
- Минимизируйте объем данных, передаваемых в одном наборе данных.
Для достижения вышеуказанных двух направлений оптимизации мы проделали следующую работу:
- Скомпилируйте статический шаблон компонента в исполняемую функцию рендеринга и соберите зависимости данных шаблона с помощью функции рендеринга. Только когда данные зависимости в функции рендеринга изменятся, будет запущен setData компонента апплета. для обеспечения тика используется асинхронная очередь.В лучшем случае setData будет выполняться только один раз.Этот механизм очень похож на механизм рендера в Vue, что значительно снижает частоту вызовов setData;
- В процессе компиляции шаблона в функцию рендеринга мы также записываем и выводим пути данных, используемые в шаблоне.Каждый раз, когда нам нужно setData, мы будем выполнять diff на основе этих путей данных и предыдущих данных, и передавать только измененные данные через путь данных.SetData выполняется таким образом, что обеспечивает минимальный объем данных, передаваемых каждый раз, когда setData, и позволяет избежать ненужных операций setData, еще больше уменьшая частоту setData. На основе приведенных выше оптимизаций мы значительно уменьшили частоту вызова апплета setData и объем передаваемых данных, что значительно лучше, чем схема данных полного трека в первой версии Mpx.
Эффект оптимизации Mpx setData
Устаревшие мегапиксели | Новая версия Мпкс | |
---|---|---|
setData раз | 164 | 88 |
setData количество данных | 370kB | 38kB |
Блок-схема механизма ответа данных MpxПриведенные выше данные получены статистикой более сложных мини-программ после фиксированного интерактивного процесса.
Скомпилировать и построить
Мы надеемся использовать Webpack, самый мощный и экологически разработанный инструмент для компиляции и построения, для реализации компиляции и построения небольших программ, чтобы пользователи могли получить передовой и мощный опыт инженерной разработки в веб-разработке. Студенты, которые использовали Webpack, знают, что, вообще говоря, Webpack упаковывает ряд фрагментированных модулей, используемых в проекте, в один или несколько пакетов, а файловая структура, необходимая для апплета, очень дискретна. Как это сделать? Противоречие между ними стать нашей самой большой проблемой. Очень интуитивно понятная и простая идея состоит в том, чтобы просмотреть весь каталог src и добавить каждый файл .mpx в качестве записи в Webpack для обработки.При этом есть две основные проблемы:
- Файлы .mpx, которые не используются в каталоге src, также будут скомпилированы и выведены, и в конечном итоге будут упакованы апплетом в пакет проекта, бессмысленно увеличивая размер пакета;
- Для файлов .mpx в node_modules мы не думаем, что обход node_modules — хороший вариант.
В конце концов, мы приняли метод, основанный на анализе зависимостей и динамическом добавлении записей, пользователю нужно только настроить файл записи app.mpx в конфигурации Webpack, а загрузчик будет парсить домен страниц и домен usingComponents в json при парсинге в json. Объявленный путь добавляет эти файлы в систему сборки Webpack путем динамического добавления записей (обратите внимание, что здесь добавляются записи вместо зависимостей, потому что только записи могут генерировать независимые файлы в соответствии с дискретной файловой структурой апплета), и рекурсивно выполнять этот процесс до тех пор, пока не будут добавлены все файлы .mpx, используемые во всем проекте.Перед выводом мы используем возможности CommonsChunkPlugin/SplitChunksPlugin для извлечения повторно используемых модулей во внешний пакет, чтобы убедиться, что окончательный сгенерированный пакет не содержит повторяющихся модулей. Мы предоставляем подключаемый модуль Webpack и загрузчик, соответствующий файлу .mpx, для реализации вышеуказанных операций.Пользователям нужно только добавить его в конфигурацию Webpack, чтобы упаковать апплет обычным образом, как упаковывают веб-проекты, без какой-либо предварительной и последующей обработки. операции обработки, поддерживая полную экологию самого Webpack.
Блок-схема механизма компиляции и построения 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/
Связь с пользователем:кликни меня в группу