Кросс-энд и сериализация между стеками 1/7: RN разрабатывает 8 приложений

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

14-е | Сессия по развитию и продвижению интерфейса, 8-29 будет в прямом эфире, 9 лекторов (Ant Financial Services / Tax Friends и т. д.),Нажмите на меня, чтобы сесть в машину 👉 (Адрес регистрации):

Текст выглядит следующим образом

Эта статья — девятая сессия — онлайн-документация, фронтенд-чаты на ранней стадииИгра 62, отПесня Caulie Big Frontier Leader - Лю ФанКратко организованная версия общей речи (полную версию, включая демо, см. в записанном видео и PPT):

Привет всем, меня зовут Лю Фан, я отвечаю за интерфейс Songxiaocai Тема этого выступления — лучшие практики RN для 8 приложений в сценарии toB.

Почему стоит выбрать стек React Native

Первая часть вопроса заключается в том, что у Song Xiaocai сейчас 8 приложений. Почему мы выбрали стек технологий React Native?

Профиль компании

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

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

С момента своего основания в 2015 году компания Songxiaocai разработала 8 независимых приложений, которые в сумме составляют от одной до двух тысяч страниц и обслуживают более 30 000 городских конечных пользователей на нисходящем направлении, более 10 000 поставщиков на начальном этапе и многое другое. 7000 пользователей-водителей вверх и вниз по течению. В настоящее время годовой тоннаж транзакций Songxiaocai составляет более 300 000. Для такой крупной компании мы можем взглянуть на ее основной бизнес:

Введение в бизнес

Верхние пользователи, с которыми мы связываемся, — это в основном поставщики овощей и овощехранилища, нижние пользователи — это оптовые торговцы овощами и мелкие и средние поставщики овощей, а логистические операторы находятся посередине.

Так почему у стартапа 8 приложений? Главным образом потому, что целевые пользователи 8 приложений совершенно разные.

Пользователями овощной базы вверх по течению в основном являются Daiban, стоковщики и поставщики.Это наши внешние пользователи. Их основной призыв: можно ли продавать их блюда? Как продать? Сколько продать? Сколько можно продать за день?

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

О чем заботится команда логистики, начиная от овощной базы вверх по течению и заканчивая оптовым рынком вниз по течению, а также наша команда логистики? Беспокойство в том, есть ли у него что-то, чтобы доставить каждый день? Какую машину ему нужно водить? Откуда куда? Когда он будет доставлен?

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

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

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

Введение в интерфейс

Давайте взглянем на текущие ресурсы разработки внешнего интерфейса Сун Сяокай. У Сун Сяокай всего 15 студентов во всем интерфейсе, эти 15 студентов подключили 8 RN APP и более десятка проектов H5 (эти H5 делятся на H5 в WeChat и H5 в DingTalk, а H5 в DingTalk — для внутренних пользователей). компании. Некоторые совместные вещи. H5 на WeChat ориентирован на внешних пользователей и предоставляет требования, связанные с размещением заказов).

Помимо RN App и H5, у нас также есть 6 мини-программ и более 20 проектов для ПК. Кроме того, у нас есть собственные несколько инфраструктурных платформ на переднем крае. У 15 студентов так много проектов для стольких терминалов, как мы выбираем технологический стек нашего приложения, мы чувствуем, что лучший из них подходит для текущих ресурсов и сценариев!

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

Проведя инвентаризацию технологических стеков 15 студентов Сун Сяокай, мы обнаружили, что эти 15 студентов на самом деле лучше всего разбираются в React и Node.js. Кроме того, есть два или три студента, которые раньше работали с Java, Android или IOS и обладают определенными способностями к разработке собственных приложений. Есть также несколько студентов с опытом разработки Vue.

Основываясь на всестороннем рассмотрении затрат на исследования и разработки, эффективности исследований и разработок и пользовательского опыта, мы считаем, что мы не занимаемся разработкой гибридного гибрида H5, а занимаемся разработкой RN.С одной стороны, мы стремимся к относительно хорошему приложению, а с другой стороны , мы также преследуем нашу эффективность развития. Нам не нужна нативная разработка или разработка на Flutter.Хотя нативная разработка и Flutter могут иметь лучшую производительность и опыт, но если много ресурсов вложено в нативную разработку и Flutter, для наших 15 студентов это не очень рентабельно.Технические решения . Команде не нужно набирать так много местных инженеров, и технологический стек товарищей по команде не будет фрагментирован, поэтому лучшим решением для внешнего интерфейса Songxiaocai является позволить студентам React делать и RN, и H5, и ПК.

Реагировать на нативную инфраструктуру

Во второй части в основном рассказывается о нашем текущем исследовании инфраструктуры React Native.

Обзор нативной инфраструктуры React

Сначала взгляните на наш обзор инфраструктуры React Native.

На самом деле, эту картину можно применить не только к стеку технологий РН, любой стек технологий можно рассматривать с нескольких уровней слева: три верхних уровня — это спецификация кода, спецификация инженерной структуры и спецификация компонента пользовательского интерфейса. Это ядро любого технологического стека. У нас в команде относительно хорошая спецификация кода и инженерная структура. Поверх инженерной среды мы создадим нашу богатую библиотеку компонентов. Здесь для RN у нас есть как компоненты отображения на основе пользовательского интерфейса, так и собственные компоненты, для которых требуются собственные возможности.

В дополнение к трем вышеперечисленным уровням, RN App также необходимо создать свою платформу упаковки и публикации. Платформа упаковки будет подробно представлена позже.Наша команда самостоятельно разработала платформу упаковки под названием «Большой дядя», которая представляет собой платформу упаковки, основанную на управлении ветвями/платформой/средой. Для выпуска RN мы разработали платформу, которая может выполнять собственный выпуск/выпуск оперативных обновлений/выпуск белого списка.Эта платформа также может управлять историческими выпусками.Мы называем ее платформой выпуска «Big Cousin».

Помимо упаковки дяди и платформы выпуска двоюродного брата, мы подключились к рабочему месту DevOps технологического отдела Songxiaocai.Рабочий стол DevOps предназначен для всего технологического отдела Songxiaocai, от начального этапа спроса до дизайна пользовательского интерфейса, технологических исследований и разработок и тестирования продукта. , Он включает в себя такие функции, как управление итерациями, управление ошибками, выпуск одним щелчком мыши и т. д., охватывающие весь процесс исследований и разработок. Наша платформа для создания интерфейсных пакетов Uncle и двоюродный брат по платформе для интерфейсных публикаций также получили DevOps, которые можно настроить на DevOps для итерации по запросу. После этого завершите упаковку и выпуск приложения одним щелчком мыши.

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

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

Техническая архитектура React Native

React Native можно разделить на три слоя сверху вниз.Верхний слой, который часто встречается при фронтенд-разработке, — это наш слой JS. Уровень JS включает в себя основные компоненты и основной API, предоставляемые официальной нативной версией, а также гибкость для нашего макета RN, а также некоторые трехсторонние модули сообщества на уровне JS. Оранжевые выше — это в основном компоненты RN Components, написанные нами для развития бизнеса.

Средний уровень — это очень важный уровень, который связывает уровень JS и нативный уровень, мы называем его JS Bridge. Это очень важный уровень для уровня JS для вызова собственных API и вызовов собственных компонентов для рендеринга страницы. Этот слой на стороне Android в основном представляет собой JavaScriptCore, а некоторые используют гермес собственной разработки Facebook.На стороне IOS в основном используется JavaScriptCore.Наш средний слой RN можно сравнить с корреспондентом между JS и Native.

Нижний уровень — это нативный уровень Android и IOS. Нативный уровень IOS и Android — это инкапсуляция основных компонентов JS верхнего уровня и API-интерфейсов на нижнем уровне. На нативном уровне есть слой, называемый слоем йоги. Yoga Layer — кроссплатформенный гибкий движок, разработанный Facebook для парсинга и рендеринга flex-бокса.

Мы занимаемся разработкой RN, если это связано с особыми потребностями натива, такими как печать Bluetooth, которую мы недавно сделали, и упаковка нативных методов WeChat и Alipay, которые мы делали раньше, в это время мы коснемся натива слой и сделать какой-то нативный слой.пакет.

React Native Scaffolding — кирпич

Разобравшись с технической архитектурой React Native, давайте взглянем на нашу структуру Brick.

Платформа Brick содержит инженерные леса и инженерные шаблоны нашего приложения RN.Белый кружок внутри синего круга на рисунке выше — это то, что делает наша структура Brick. Он указывает единый базовый пакет зависимостей, включая некоторые базовые зависимые версии RN, IOS и Android.Например, если мы используем версию 0.59.9 для RN, соответствующие Android и IOS также имеют определенные базовые версии.

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

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

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

В дополнение к этим собственным вещам Brick framework, в приложение RN также встроены интерфейсные кроссплатформенные проекты. Например, SDK для обнаружения обновлений RN, SDK для внедрения приложений RN и подключаемый модуль отображения отчетов на стороне RN будут подробно представлены позже.

Вот инженерная структура RN APP Brick, давайте рассмотрим только что сказанные пункты:

Мы унифицировали базовые пакеты зависимостей в скаффолдинге RN и обновили их по определенным правилам. При обновлении вы также можете обнаружить зависимые версии связанных сторонних пакетов.
В настоящее время то, что мы в основном делаем в инструменте-скрипте, — это переключение среды, конфигурация горячего обновления, собственная упаковка и обработка некоторых сертификатов IOS, управление файлами PP и т. д., а также обнаружение спецификации кода.
В библиотеке компонентов есть основные компоненты отображения: включая несколько наборов тем, кнопку, текст, текстовый ввод, страницу, загрузку и т. д. Существуют также нативные компоненты, на многие из которых ссылаются по запросу, например, нативные компоненты WeChat трехстороннего WeChat, Alipay от Alipay, наш Bluetooth для печати по Bluetooth и т. д.
В дополнение к компонентам мы инкапсулируем базовый шаблон проекта, который инкапсулирует маршрутизацию.Мы основаны на версии react-navigation@3.+, которая обеспечивает унифицированные запросы на вход и шлюз поверх этого шаблона. Мы также обеспечиваем настройку маршрутизации и переключение сценариев входа и выхода, например, при каких обстоятельствах может инициироваться вход и выход из системы.
Кроме того, мы будем использовать глобальное управление состоянием на RN. Для глобального управления состоянием мы используем rematch. Он очень похож на dva, но использует async/await для обработки асинхронных запросов. Для разработчиков, которые привыкли к промисам, rematch проще принять и использовать. В то же время мы также используем некоторые сторонние плагины для рематча, такие как загрузка и сохранение.
В дополнение к глобальному управлению состоянием есть также некоторые кросс-платформенные компоненты Songxiaocai, подключенные к RN, такие как компоненты со встроенными функциями обнаружения и обновления обновлений, компоненты отчетов о скрытых точках, компоненты отчетов и т. д.

инструмент скрипт

Давайте подробно поговорим о том, что делает наш скриптовый инструмент Song Xiaocai.

С одной стороны, инструмент-скрипт нужен потому, что наша разработка APP определенно будет иметь несколько наборов переключения среды.Он может использовать скрипт для очень удобного переключения среды, а также может выполнять некоторые настройки нашего горячего обновления.Мы используем fastlane как средство переключения среды. core.Настройте управление файлами PP сертификата IOS команды упаковки, а также некоторое управление информацией нашего IOS APPStore

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

Библиотека компонентов приложения

Эта библиотека компонентов включает в себя базовые компоненты пользовательского интерфейса и некоторые функциональные компоненты. Многие из этих функциональных компонентов являются нативными и обеспечивают собственные возможности разработки. Таким образом, теперь у нас есть около 40 компонентов пользовательского интерфейса. Среди 8 упомянутых приложений Сун Сяокай охват использования достиг 100%. , и все на странице в основном построено из компонентов.

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

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

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

дядя упаковочная платформа

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

После подтверждения конфигурации нажмите «Быстрый пакет», и вы будете ждать результата упаковки. Все успешные пакеты будут генерировать QR-код для загрузки. Независимо от того, предназначено ли это для тестирования или разработки, нужно только отсканировать QR-код, чтобы загрузить то, что мы уже сделали.Введите пакет и проверьте функциональность пакета.Эта платформа упаковки разработана с помощью Node.js, и ее основные функции включают в себя: контроль процесса упаковки и управление установочными пакетами. Недавно введенные пакеты будут иметь запись истории.Когда вам нужно их использовать, вы можете загрузить и использовать их, отсканировав QR-код.

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

Большой двоюзин издательская платформа

Вышеуказанное является нашей платформой освобождения от двоюродного брата, платформа Release имеет много функций, я перехватываю список релизов. Здесь, какое приложение, какая платформа, какая отделение отделения? Каждый раз номер версии, канал выпуска, также есть выпуск копии.

Страница установки приложения также является страницей для внешней загрузки.Эта страница определяет, является ли платформа мобильного телефона IOS или Android, а затем предоставляет пакет для загрузки.

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

Предоставляет функцию распространения горячего обновления, может распространяться по каналам, может быть удобно для тестирования, например, может распространять только на сторону IOS или только на сторону Android, с точки зрения горячего обновления, обеспечивает инкрементальные обновления , который может сохранить запрос сетевых ресурсов пользователя.
В дополнение к выпуску горячего обновления он может предоставлять функцию распространения собственного установочного пакета, который реализует распространение по каналам и облегчает тестирование.
В то же время он обеспечивает автоматизированный метод управления версиями, позволяющий избежать изменения разработчиками номера версии в проекте. На самом деле, когда мы только что упаковали, если бы мы использовали официальный пакет, какую итерацию мы могли бы выбрать? Например, будь то обновление основной версии, итерация функции или исправление. После того, как он будет определен, номер версии будет автоматически обновлен при выпуске, а обновленная версия будет записана обратно в репозиторий git после завершения выпуска. Существует также вариант принудительного обновления, когда он будет выпущен.Если вариант принудительного обновления, то у пользователя будет всплывающее окно принудительного обновления, когда он нажмет на приложение.В это время пользователь может только использовать обновление. Если это необязательное обновление, пользователь может выбрать обновление. Кроме того, у нас также есть настройки переключения каналов и оттенков серого для поддержки отката онлайн-версии. После выпуска каждой версии приложения эта версия будет записана. Если в сети будет обнаружена серьезная проблема, которую необходимо откатить, будет инициирована операция отката, и версия будет отменена.
В то же время мы также протестируем установочный пакет, который необходимо обновить.Только если он распространяется через нашу платформу для публикации небольших блюд, он может пройти проверку нашего установочного пакета. Предотвращение подделки внешних установочных пакетов повышает безопасность наших выпусков.
У нас также есть статистика по установке каждой версии.Например, мы выпустили версию 1.0 и выпустили версию 1.1, так сколько пользователей установлено для каждой версии? Мы можем просматривать статус установки последней версии приложения в режиме реального времени.
Наша релиз-платформа также интегрируется в систему DevOps компании, после чего формируется замкнутый цикл CICD фронтенд-процесса.

Следующее изображение подробно познакомит вас с процессом выпуска нашей упаковки, вы можете следить за мной, чтобы увидеть его с самого начала.В начале пользователи могут либо щелкнуть, чтобы опубликовать на DevOps, либо щелкнуть, чтобы упаковать на нашей платформе Uncle.Команда упаковки фактически вызывает Jenkins, а Дженкинс вызывает команду fastlane для упаковки.После упаковки будет сгенерирован соответствующий пакет.IOS package генерирует файл ipa, а пакет Android генерирует apk. Затем результат упаковки будет загружен, и наша платформа упаковки (DevOps или Uncle) будет уведомлена, а затем будет принято решение о том, является ли текущий пакет пакетом выпуска.Если это не пакет выпуска, процесс упаковки завершен. .

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

Как видно из этой картинки, на самом деле операция разработчика по публикации приложения очень проста, то есть зеленый процесс в начале. Пока он настраивает параметры на платформе упаковки или платформе DevOps и нажимает «Опубликовать», все последующие процессы автоматизированы.

После разговора об упаковке и публикации, давайте поговорим об онлайн-производительности приложения.Мы внедрили полноплатформенную платформу мониторинга, которая называется Big Prodigal Monitoring Platform.

Большая блудная платформа мониторинга

Поскольку наш младший брат, разработавший Song Xiaocai, уже поделился этим контентом, вот краткий обзор функций.

На первом изображении мы собираемся отслеживать, есть ли какие-либо ненормальные проблемы в текущем онлайн-приложении? Каков уровень каждой проблемы? Разделение уровней здесь рассчитывается на основе некоторых алгоритмов, от P0 до P6, где P0 — самый серьезный, а наименее важный — P6.

Каков текущий статус каждой проблемы? Каков тип ошибки и описание сообщения об ошибке для каждой проблемы? Возникает ли эта проблема на стороне JS, нативной стороне и т. д.

Нажмите на детали в крайнем правом углу, и мы увидим, что это за проблема. Ниже будут некоторые подробные ошибки по проблеме, такие как стек ошибок, частота срабатывания за последний период и т. Д. .

Основываясь на этой проблеме, мы также можем установить определенные правила тревоги.

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

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

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

отчет о данных

У нас есть платформа под названием Dapanzi, которую в основном используют студенты компании, изучающие бизнес-аналитику и хранилища данных. На этом он может выбрать определенную таблицу данных в хранилище данных, а затем указать, какова размерность оси X его отчета и каков показатель оси Y.

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

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

Итак, наконец, мы просматриваем нашу инфраструктуру RN:

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

Два уровня посередине — упаковка и публикация.На самом деле у нас есть три платформы в Songxiaocai: DevOps, совместно используемая техническим отделом, интерфейсная платформа упаковки нашего дяди и платформа публикации нашего двоюродного брата. Цель этих двух слоев — обеспечить универсальную упаковку и распространение. Это может сохранить эффективность наших исследований и разработок на стороне приложения и обеспечить спецификацию процесса.

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

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

Глядя в будущее

В настоящее время мы находимся в непрерывном строительстве РН, я примерно разделил на следующие пункты

Самым основным является компонент, На самом деле, мы продолжим делать некоторые компоненты на основе бизнес-сценариев на основе наших компонентов пользовательского интерфейса и нативных компонентов. На самом деле компонентами бизнес-сценариев могут быть какие-то шаблонные вещи, например компоненты сценария маркетинга и закупок. Затем мы продолжим расширять наши аппаратные возможности, используя наши собственные возможности разработки, чтобы продолжать расширять наши собственные аппаратные возможности.
Вдобавок к компонентам мы автоматизируем обновление инфраструктуры нашей платформы Brick, поскольку наше текущее обновление инфраструктуры по-прежнему выполняется вручную, мы можем автоматизировать это обновление платформы позже, например, используя сценарий для выполнения всего обновления платформы APP A на сторона. В будущем может появиться возможность поддержки бизнес-субподряда. Например, в приложении несколько пакетов JS могут быть реализованы в соответствии с различными бизнес-функциями. С помощью этой функции можно отказаться от субподряда. Наконец, подумайте, можно ли интегрировать существующие приложения, чтобы уменьшить количество приложений.
Третий момент - непрерывная интеграция. Непрерывная интеграция включает в себя некоторые автоматизированные тесты, которые может выполнять наше приложение. На самом деле у нас уже есть некоторые автоматизированные тесты и модульные тесты для основных процессов. Мы можем рассмотреть возможность создания тестов на основе платформы позже. Конфигурация сценария упаковки должна сделать сценарий упаковки приложения настраиваемым, который хранится в базе данных и может использоваться где угодно. Наконец, вы также можете попробовать выполнить функциональный A/B-тест, потому что мы уже выпустили оттенки серого, и мы можем провести некоторые функциональные тесты позже.Например, некоторые пользователи используют функцию A, а некоторые пользователи могут использовать функцию A. Это это функция B, как это.
Наконец, что касается многотерминальной интеграции, поскольку есть много дополнительных блюд, включая RN, апплет, H5, ПК и т. д., мы можем продолжать использовать преимущества быстрого итеративного обновления RN, а затем исследовать некоторые решения для слияния с другими типами терминалов.

Мой сегодняшний обмен здесь, ниже мой личный QR-код, один QR-код Dingding, а другой QR-код WeChat, Заинтересованные студенты могут отсканировать его и добавить друзей, а затем общаться в автономном режиме.

В этой статье используетсяmdniceнабор текста