Создание и разработка нативной системы Cloud Music React

Автор этой статьи:Чжан Вэйдун

0.33 История

В марте 2017 года, чтобы решить проблемы производительности и взаимодействия с пользователем в торговом центре, техническая группа облачной музыки сформировала команду разработчиков ReactNative из 4 человек: я отвечал за разработку интерфейса RN, а два разработчика Android и iOS отвечали за встраивание RN Native в облачное музыкальное приложение SDK, а разработчик Java выполнял работу по развертыванию платформы.

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

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

С марта 2017 г. по сентябрь 2019 г. версия RN всегда была 0.33, половина основной команды разработчиков была потеряна, платформа развертывания не поддерживалась, в разработке проекта отсутствовали строительные леса и отсутствовала веб-поддержка.Всего было запущено 2,5 приложения RN (молл. , музыка и др.) люди, троичные динамики).

взбалтывание истории

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

Страница кассира участника показана на рисунке ниже, это страница покупки участника облачной музыки, и ее важность очевидна. Эта страница изначально была страницей H5, разработанной серверным рендерингом React.

Чтобы позволить пользователям приобретать участников более гладко и улучшить пользовательский опыт и скорость поступления, вся техническая команда внедрила технологию общей веб-оптимизации в сочетании с собственными техническими средствами облачной музыки и потратила месяц на оптимизацию этой страницы H5, увеличив скорость поступления с 72% до 100% 89%, увеличение на 17 процентных пунктов. Сравнение с конкурирующими продуктами выглядит следующим образом (единица измерения – секунды).

Формула расчета коэффициента прибытия = видимая кассиром скрытая точка / скрытая точка, по которой щелкнул клиент

Хотя результаты оптимизации радуют, есть несколько проблем:

1. Не достигнута цель по показателю охвата. В начале техническая команда установила не менее 90%, разница в один процентный пункт.
2. ROI слишком низкий. Оптимизация H5 вложила много сил во фронтенд и бэкэнд разработку, и это заняло почти месяц. Если вы хотите оптимизировать другие страницы, степень автоматизации текущего решения низкая, и все еще требуется много ручных операций.
3. Скорость поступления 0,33 RN составляет 93%. Мы посчитали скорость поступления RN версии ТРЦ без какой-либо оптимизации, легко преодолев 90.

На данный момент перед командой 3 пути:

1. Инвестируйте больше ресурсов в оптимизацию страницы H5 и выполняйте задачи более чем на 90%. Однако это решение отнимает много трудовых и материальных ресурсов, а для оптимизации других страниц бесполезно, это одноразовая сделка.
2. Сбросить страницу оформления заказа на версии RN 0.33. Это достигает цели, но инфраструктуре РН еще 3 года.
3. Завершите инфраструктуру RN, выполните обновление до последней версии 0.6, внедрите решение с тремя терминалами и создайте полную систему разработки RN. Исходя из этого, сбросить кассу на основе версии 0.6 и использовать этот проект для обновления всего стека технологий РН. Хотя эта схема имеет большие преимущества, она имеет большой временной интервал, большие трудности и высокую сложность.

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

Автоматическое развертывание

Устаревшая платформа развертывания

Исходная платформа развертывания RN не поддерживает автоматическое развертывание.Чтобы выпустить приложение RN, вам необходимо выполнить следующие действия.

Выполнить скрипт совместимости

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

    sed -i -e 's/function normalizePrefix(moduleName: string)/const normalizePrefix = function(moduleName: string)/g' ./node_modules/react-native/Libraries/BatchedBridge/BatchedBridgedModules/NativeModules.js

    sed -i -e 's/function normalizePrefix(moduleName: string)/const normalizePrefix = function(moduleName: string)/g' ./node_modules/react-native/Libraries/Utilities/UIManager.js

    sed -i -e 's/function handleError(e, isFatal)/var handleError = function(e, isFatal)/g' ./node_modules/react-native/Libraries/JavaScriptAppEngine/Initialization/InitializeJavaScriptAppEngine.js

Выполнить скрипт упаковки

местное исполнениеrelease.test.sh(тест) иrelease.sh(онлайн). Сценарий выпуска вызывает сценарии упаковки iOS и Android соответственно, а затем печатает соответствующий пакет.

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

Загрузить и опубликовать платформу

Здесь вам нужно заполнить соответствующий контент, а затем нажать «Опубликовать».

Видно, что указанные выше три шага имеют локальные риски загрязнения, операция обременительна, и легко пропустить шаги и заполнить ошибки.

Автоматизированный процесс развертывания

В ответ на указанные выше дефекты ручного развертывания мы реорганизовали и разработали весь процесс автоматического развертывания.

git 克隆 -> 依赖安装 -> 自动脚本执行 -> 压缩 -> 上传文件服务器 -> 保存版本信息 -> 发布

Затем разработали новую платформу развертывания RN с Node вместо Java.

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

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

Процесс загрузки РН

• APP сначала запускает контейнер RN, контейнер RN запрашивает JSBundle с сервера, а затем выполняет предварительный рендеринг.
• После инициализации страницы RN отправьте запрос на сервер для получения динамических данных и выполните оставшуюся логику рендеринга.

Как видно из рисунка выше, запрос JSBundle является узким местом производительности во всем процессе. Если вы загрузите JSBundle заранее (запускается при инициализации приложения), а затем откроете приложение RN, приложение напрямую загрузит пакет ресурсов из локальной области, что значительно улучшит взаимодействие с пользователем и производительность.

Платформа офлайн-пакетов RN

Основываясь на вышеуказанных причинах, мы разработали автономную платформу обслуживания пакетов RN, отвечающую за доставку JSBundle. Служба автономных пакетов тесно связана с созданием и развертыванием.Мы соединяем две платформы и автоматически генерируем автономные пакеты на этапе создания и развертывания, чтобы сократить работу разработчиков по развертыванию.

Ниже приведена полная блок-схема платформы автоматического развертывания RN и автономной платформы обслуживания пакетов.

Основные процессы следующие:

1. Платформа автоматического развертывания RN сначала создает полную сумму, передает ее в CDN, а затем уведомляет автономную платформу службы пакетов.
2. Платформа автономной службы пакетов получает полную информацию о пакете, использует алгоритм сравнения для расчета пакета различий, сохраняет соответствующую информацию и публикует пакет различий.
3. Когда приложение запускается, оно получает доступ к автономной службе пакетов и, в соответствии с возвращенной информацией, следует ли читать локальный кеш или удаленно получать соответствующий полный пакет или дифференциальный пакет.

0.33 обновление 0.6

Работа по обновлению в основном делится на две части: обновление RN Native SDK + обновление приложения RN.

RN Native SDK относится к собственному коду, связанному с RN (исходный код iOS и Android), интегрированному в приложение Cloud Music. Поскольку версия 0.33 и версия 0.6 несовместимы одновременно, мы приняли стратегию только сохранения и отказа от обновления старой версии.

Приложения RN относятся к бизнес-приложениям, таким как торговые центры и колонки, а также могут быть эквивалентны JSBundles. Обновление приложения должно быть завершено до обновления SDK, иначе SDK 0.6 загрузит приложение 0.3, что приведет к сбою приложения. Поэтому все приложения должны завершить работу по обновлению одновременно.

Проблемы с обновлением

проблема зависимости

В RN 0.3 используется React версии 15.3, а в 0.6 — 16.8. В дополнение к зависимостям React, есть и другие зависимости, которые необходимо обновить, мы предоставляем согласно официальномусравнение различий версийСоздайте скаффолд, прочитайте информацию в package.json, сравните их один за другим, а затем измените их на соответствующую версию.

устаревшие компоненты

RN0.6 версия удалена два компонента:Listviewа такжеnavigator-ios.

В этом случае, если мы используем новый компонент, напримерFlatListПереписывание требует не только понимания исходной бизнес-логики, но также изменения исходного кода и повторного тестирования. Поэтому в ответ на эту ситуацию команда приняла меры по извлечению соответствующих компонентов из старой версии без изменения существующего кода. Наконец мы выпустили@music/rn-deprecated-navigator-iosа также@music/rn-deprecated-listview

Синтаксис совместимый

Синтаксис RN не только написан по-разному в 0.6 и 0.33, но и не имеет обратной совместимости. В результате JSBundle версии 0.33 будет аварийно завершать работу непосредственно с Native SDK версии 0.6. Фоновое изображение используется в качестве примера ниже.

В версии 0.33 для реализации фонового изображения используйтеImageсодержитView, а в версии 0.6 он был изменен наImageBackground, свойства тоже разные.

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

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

1. 0,33 Использование прочитанного первого источника кадра
2. Преобразование исходного кода версии 0.33 в дерево AST.
3. Выполните соответствующие операции с деревом AST 0,33 и преобразуйте его в дерево AST 0,6.
4. Восстановите исходный код из дерева AST 0.6.

Вся структура обрабатывает в общей сложности 12 правил перевода.

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

3-терминальное решение

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

прямое преобразование

Поскольку RN и React различаются только синтаксисом уровня рендеринга, если синтаксис RN можно напрямую перевести в синтаксис React, то RN можно запустить в браузере.

Например, РНViewПреобразовано в реакциюdiv, событие щелчка RNonPressПреобразовано в реакциюonClickЖдать.

Недостатками этой схемы являются:

1. сверх загруженности работой. внутри РНView,Text,ImageЕсть много базовых компонентов.
2. Переписка один на один невозможна. НапримерViewEстьonStartShouldSetResponderМетод, соответствующее событие не может быть найдено в реакции.

режим моста

Для приложений RN сначала найдите стороннюю платформу, поддерживающую forweb, а затем преобразуйте RN DSL в стороннюю платформу DSL для достижения конечной цели.

Более представительным в этом отношении являетсяTaroа такжеReactXP.

Таро RN в соответствии с их собственными спецификациями для достижения набора DSL, для функций и событий, сделанных на заказ.

ReactXP 3-х терминальная опора очень хорошая, но очень немногих компонентов, также пришлось сдаться.

нижняя сборка

Согласно определению элементов и компонентов RN, весь набор RN API реализуется с функциями, связанными с WEB, из нижнего уровня.react-native-web. Эта схема также является текущей основной моделью в отрасли.

Мы инкапсулировали и расширили эту библиотеку, добавили неподдерживаемые компоненты, исправили некоторые ошибки и сформировали@music/react-native-web-suffix.

Новый процесс разработки

Мы разработали на основе трехтерминального решенияrn-cliстроительные леса,rn-utilобщая библиотека инструментов,rn-templateШаблоны инициализации проекта и другие вспомогательные инструменты сформировали полный набор инфраструктуры разработки RN Текущий новый процесс разработки выглядит следующим образом.

rn-cliВызывается при инициализации скаффолдингаrn-template.rn-templateВстроенные контейнеры для Android, iOS и веб-разработки, а также некоторые общие конфигурации проектов, коллекцияrn-util(Запрос на обработку, Среда на окружающую среду, общий протокол) и библиотеку из трех терминалов.

Cashier RN Результаты рефакторинга

После вышеперечисленных усилий касса была переработана на RN 0.6, а коэффициент прихода увеличился с 89% до 99% для предыдущей H5 (оптимизированной).

статус-кво

С улучшением версии RN и улучшением инфраструктуры все больше и больше крупных фронтенд-разработчиков используют стек технологий RN в новых проектах.

Запущено более 10 приложений РН, таких как:

план на будущее

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

В разработке несколько спецпроектов

Native RPC

Основная цель этого специального проекта — открыть мост RN и мост JS, чтобы набор механизмов передачи данных мог поддерживать как RN, так и сеть.

У предыдущего моста в основном было 2 проблемы:

1. Непоследовательное использование. Необходимо написать 2 набора грамматики для поддержки RN и сети соответственно.
2. Поддержка нестабильна. Некоторые веб-протоколы имеют RN, а не имеют, и наоборот.

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

// 查看 net.nefetch 是否支持，
mnb.checkSupport({
    module: 'net',
    method: 'nefetch'
}).then(res => {

})

/* 手动添加方法 */
mnb.addMethod({
    schema: 'page.info',
    name: 'getPageInfo'
});

/* 添加之后即可调用 */
mnb.getPageInfo().then((result) => {
    // ...
}).catch((e) => {
    // ...
});

И RN, и веб написаны унифицированным образом, и разработчикам больше не нужно беспокоиться о проблемах совместимости.

РН распаковка

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

1. Распаковать. Разделите текущий полный JSBundle на базовые пакеты и бизнес-пакеты и загрузите их отдельно.
2. Контейнеры предварительно загружены. Контейнер RN предварительно прогревается при запуске приложения, что может значительно сократить время запуска контейнера и повысить скорость загрузки.

разное

В дополнение к вышеупомянутым специальным проектам, существует множество специальных проектов, таких как мониторинг рынка РН, целевое распространение пакетов ресурсов РН и спецификация документов, которые находятся в самом разгаре.

заключительные замечания

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

Эта статья была опубликована сКоманда внешнего интерфейса NetEase Cloud Music, Любое несанкционированное воспроизведение статьи запрещено. Мы набираем front-end, iOS и Android круглый год.Если вы готовы сменить работу и любите облачную музыку, присоединяйтесь к нам на grp.music-fe(at)corp.netease.com!