Исследование и практика мини-программы Meituan Takeaway (организация речевого контента) 丨 Конференция разработчиков Nuggets

внешний интерфейс WeChat Апплет WeChat NPM
Исследование и практика мини-программы Meituan Takeaway (организация речевого контента) 丨 Конференция разработчиков Nuggets

9 января 2017 года была официально запущена официальная мини-программа WeChat, выпущенная на WeChat Open Class Pro 2017 года, что положило начало эре разработки мини-программ. Наш бизнес Meituan на вынос также постепенно присоединился к команде разработки небольших программ. Мини-программы не требуют установки, имеют простой доступ и не требуют удаления. Это «легкие» приложения.

Однако такие «легкие» приложения несут в себе наш очень сложный бизнес по доставке еды, и для нашей команды по доставке еды мы также сталкиваемся со многими новыми возможностями и проблемами. В этой статье мы подробно расскажем о решениях и опыте нашего апплета на вынос, надеясь вдохновить всех. Этот обмен в основном состоит из следующих четырех частей:

Часть 1: Техническая архитектура

Когда апплет был выпущен, он в основном позиционировался как легкое приложение с простыми функциями, поэтому дизайн родного фреймворка был относительно простым.Для средних и крупных интернет-компаний с относительно сложным бизнесом продуктовая поддержка апплета не была идеальной, и проектом было трудно управлять и поддерживать.

Апплет Meituan на вынос разделен на несколько команд для совместной разработки в соответствии с бизнесом, основным процессом, маркетингом, рекламой и т. д. Проблема заключается в том, как обеспечить эффективную и совместную разработку апплета несколькими командами; апплет, основной процесс является стабильным, и требуются дополнительные обновления, а маркетинговая деятельность требует быстрой итерации и многоканальной поддержки.В соответствии с потребностями различных бизнес-сценариев, как хорошо выполнять работу по поддержке, также является очень важной частью. Итак, как справиться с этими проблемами?

Деловая сцена

Для разнообразия бизнес-сценариев мы принимаем относительно открытую стратегию фреймворка: проект поддерживает как разработку собственного фреймворка, так и бесплатное внедрение сторонних фреймворков для удовлетворения потребностей различных бизнес-сценариев.

  • Разработка собственной среды: для относительно независимых и высокостабильных предприятий, таких как основной процесс, для разработки используется собственная среда.

    • С одной стороны, мы считаем, что родной фреймворк Mini Programs не идеален.При обновлении библиотеки базовой версии возникают проблемы совместимости, которые необходимо решить, чтобы избежать внедрения сторонних фреймворков для увеличения отладки. трудность или создать новые проблемы.
    • С другой стороны, размер небольшого программного кода является относительно строгим, что позволяет избежать введения сторонних фреймворков и введения больших кодов фреймворков в процессе компиляции.
  • Поддержка mpvue (сторонняя платформа): Маркетинговый бизнес должен поддерживать несколько каналов, таких как веб-страницы и страницы небольших программ.Благодаря внедрению mpvue компоненты Vue можно повторно использовать в каждом канале, тем самым повышая эффективность разработки.

Общие компоненты

Для бизнес-сценариев, с которыми мы сталкиваемся, мы разобрали основные функции, общие для каждого бизнеса, и разделили их на несколько компонентов для унифицированного управления и обслуживания. Компоненты с высокой степенью повторного использования могут эффективно повысить эффективность разработки, а качество исследований и разработок также может быть надежно гарантировано.

Совместная разработка

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

Наши общие компоненты и различные бизнес-подпакеты размещаются в npm, а затем управляются модульным образом. А через трансформацию скрипта сборки в основной пакет апплета вводится npm, чтобы еще больше обеспечить изоляцию между каждым бизнесом, как показано на следующем рисунке:

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

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

Часть II: Процессы и инструменты

  • Спецификация инструмента: мы предоставляем проекты подпакетов и строительные леса для создания компонентов. Например, общие компоненты, такие как вход в систему, WebView и бизнес-компоненты, создаются с использованием нашей структуры компонентов, которая упрощает и стандартизирует процесс построения и построения проектов подпакетов с меньшими затратами и повышает эффективность построения проекта и сотрудничества.
  • Тестирование: у нас есть доступ к модульным тестам для наших компонентов. Модульный тест всего проекта апплета и автоматизированный тест пользовательского интерфейса также находятся в стадии разработки. В ходе цикла разработки мини-программы мы сформулировали управление версиями, процедуры доступа, процедуры выпуска и т. д., чтобы стандартизировать использование различных версий мини-программ для окружающей среды и в дальнейшем обеспечить бесперебойное сотрудничество между командами.

процесс развития

Весь процесс сборки локальной разработки показан на рисунке ниже. Разработчик выполняет операции в локальном рабочем каталоге, создает целевой файл в локальном рабочем каталоге с помощью gulp, а затем отлаживает и публикует сгенерированный код с помощью инструмента разработчика WeChat. В то же время наша конструкция поддерживает сервис Mock, имитирует интерфейс внутреннего сервера и повышает эффективность совместной отладки.

процесс выпуска

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

И мы ожидаем и позже планируем интегрировать весь процесс сборки и выпуска CI. Как показано ниже:

Недавно инструменты разработчика WeChat предоставили инструменты командной строки и методы HTTP для поддержки предварительного просмотра и загрузки мини-программ.Мы интегрируем и трансформируем весь процесс. Установив инструмент разработчика WeChat на сервер, весь процесс подключается с помощью CI, что сокращает процесс ручного управления и повышает эффективность и качество процесса выпуска.

Однако на пути к полностью автоматизированной публикации все еще есть некоторые проблемы:

  • Вход в инструменты разработчика, проверка отправки и выпуск общедоступного фона требуют ручного вмешательства.
  • Поскольку инструменты разработчика WeChat в настоящее время доступны только в версиях для macOS и Windows, а серверы CI в основном находятся в системах Linux, необходимо запустить дополнительные серверы для развертывания инструментов разработчика, а процесс преобразования относительно сложен.

Часть 3: Компонентизация

Эволюция нативной компонентизации

Поддержка модулей и компонентов нативной среды Mini Program также находится в процессе постоянного улучшения. Самая ранняя структура апплета поддерживает спецификацию CommonJS, может использовать ключевые слова require, module для определения и импорта модулей js, поддерживает импорт файлов стилей через @import, поддерживает определение шаблонов шаблонов в файле макета wxml и может использовать такие теги, как include, import , и wxs Ссылка на внешние файлы.

Для реализации компонента, часто логики wxs, стиля wxss и макета wxml, необходимо определить три файла, а это означает, что когда на компонент ссылаются, его необходимо представить в трех файлах одновременно. Компоненты имеют слабую независимость и сильно связаны с файлом подкачки, что не способствует разработке и сопровождению и очень неудобно в использовании.

Так вот в базовой библиотеке 1.6.3 апплет начинает поддерживать пользовательские компоненты, а в компоненты собственной разработки можно легко внедрить только теги. Но ранние версии пользовательских компонентов, связывающие только данные совместимых с JSON форматов, не поддерживают функции обратного вызова, и существует большое ограничение на использование. Функция вводится до тех пор, пока версия 2.0.9 только не запущена.

В последнее время апплет изначально поддерживает npm, но требуется, чтобы библиотека базовой версии была 2.2.1 и выше, и ее необходимо снова собрать с помощью инструмента разработчика WeChat. В целом, фреймворк апплета постоянно улучшает поддержку компонентов, но если учитывать совместимость пользователей с более низкими версиями, разработчикам есть над чем работать.

Классификация компонентов

Мы делим компоненты на три типа: компоненты страницы, компоненты пользовательского интерфейса и функциональные компоненты.

  • Компоненты страницы: страницы с относительно независимыми функциями, такие как страницы инкапсуляции WebView для встроенного H5;
  • Компоненты пользовательского интерфейса: части пользовательского интерфейса с относительно независимыми локальными функциями на странице, такие как компоненты входа, встроенные в страницу, список предприятий и т. д.;
  • К функциональным компонентам относятся: отсутствие пользовательского интерфейса и взаимодействия, чистые модули JS.

Общее направление фокусировки компонента

Наша эволюция на основе компонентов WeChat также находится в процессе расширения и улучшения наших общих компонентов.В то же время есть и некоторые ограничения.После этого основное внимание уделяется основным компонентам в следующих двух аспектах:

  • Дополнение и улучшение нативных функций компонента апплета.
  • Унифицированная упаковка общих базовых и бизнес-функций.

Компоненты хранилища

Случайный объект размером около 100 тыс. считывает, записывает и очищает кэш по 100 раз.Сравнение между Mini Program Storage и Web LocalStorage, занимающее много времени, показано на следующем рисунке:

Видно, что производительность апплета намного ниже, чем у Webview LocalStorage, поэтому в ответ на эту ситуацию упаковка и дизайн наших компонентов Storage должны быть сосредоточены на решении и предотвращении проблем с производительностью.

Оптимизация компонентов хранилища

Ввиду плохой производительности чтения и записи мини-хранилища программ и ограниченной емкости хранилища конструкция нашего хранилища имеет следующие характеристики:

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

Весь процесс показан на рисунке ниже:

Предотвратите рассинхронизацию данных, вызвав базовый API по ошибке:

  • key дополнительный специальный префикс при записи файлов
  • Проверка синтаксиса выполняется во время компиляции, а при некорректных вызовах выдается своевременное предупреждение.

Часть IV: Перспективы и планирование

В настоящее время инструменты разработки апплетов также постоянно совершенствуются. Недавно были добавлены многие функции, такие как поддержка npm, вызовы командной строки, HTTP-вызовы, управление версиями Git, облачная разработка и оценка опыта. Улучшение инструментов приносит определенное удобство. разработчикам.

Особенность апплета приводит к сильной привязанности между разработчиками апплета и инструментами разработки, предоставляемыми WeChat.Можно предположить, что дизайн инструментов разработки апплета WeChat должен реализовать замкнутый цикл разработки апплета.

Но у такого инструмента «черного ящика» есть и определенные проблемы — он не может удовлетворить некоторые потребности разных команд и бизнесов. Поэтому мы также надеемся, что в будущем инструменты разработки апплетов смогут предоставить некоторые API для открытых функций инструментов, и мы сможем преобразовать и реализовать открытые функции, чтобы, наконец, удовлетворить различные потребности каждой команды.

В то же время при исходном позиционировании (легкое приложение с относительно простыми функциями) и дизайне апплета производительность будет не слишком высокой. Если вы оказываете большие и сложные услуги, вы неизбежно столкнетесь с некоторыми проблемами производительности, поэтому более важно обращать внимание на проблемы с производительностью. Официальное предложение по разработке для проблем с производительностью заключается в том, чтобы контролировать объем данных setData и частоту setData. Однако во многих реальных бизнес-сценариях нельзя избежать частых setData, таких как некоторые особые требования после скользящих операций (более частые действия) и быстрый отклик на сложные клики по страницам.

Планы Meituan, основанные на этих проблемах, включают:

  • Настройка индикаторов тестирования производительности апплета: своевременное обнаружение узких мест в производительности проекта и целевая оптимизация. После тестирования, когда данные рендеринга апплета достигают 100Кб, зависание очевидно, особенно на телефонах Android, поэтому включает в себя формулирование определенных показателей размера данных рендеринга.
  • Инструменты анализа производительности: разработайте инструменты для анализа производительности.
  • Оптимизация фреймворка: Чтобы избежать некоторых проблем, возникающих на уровне фреймворка.
  • Реализация компонента длинного списка: используйте официально предоставленный компонент длинного списка.

Кроме того, проблемой, сосуществующей с производительностью, является ограничение небольшого размера программы (не более 2М, основной пакет с подпакетами, общий пакет не превышает 8М). Это ограничение имеет смысл, так как перед рендерингом апплета требуется относительно длительный период загрузки всего пакета апплета, запроса данных из бэкенда и рендеринга данных.Если пакет слишком большой, это неизбежно повлияет на восприятие пользователя. времени рендеринга. , что влияет на взаимодействие с пользователем.

Планы по уменьшению размера плана включают:

  • Оптимизация зависимостей npm: внутренние пакеты зависимостей между пакетами npm будут дублироваться, а дублированные части будут занимать объем пакета.Предварительный анализ кода используется для упрощения кода пакета npm для уменьшения тела пакета.
  • CDN для развертывания образа: Том образа занимает большой пакет, а некритические образы развертываются в CDN.
  • Некритические подпакеты миграции страниц: используйте подпакеты и независимые подпакеты, чтобы уменьшить размер основного пакета.
  • Динамическое распространение страницы: апплет не поддерживает функцию динамического распространения, и в настоящее время мы изучаем и рассматриваем ее.

Эти две ключевые проблемы требуют рассмотрения и решения в долгосрочной перспективе в будущем в соответствии с нашими бизнес-сценариями и текущим дизайном архитектуры.

Суммировать

Хотя наш сложный бизнес сталкивается с некоторыми проблемами при разработке небольших программ: «легкие» приложения небольшие программы имеют определенные ограничения для больших приложений и более сложных бизнес-сценариев, а «легкая» концепция нативного фреймворка. более крупный и сложный бизнес; как обеспечить эффективность за счет сотрудничества нескольких команд; как более дружелюбно реагировать на различные бизнес-сценарии.

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

Категории