Конференция раннего чата по интерфейсу, новая отправная точка для развития интерфейса, была проведена совместно с Nuggets. Добавьте WeChat codingdreamer в эксклюзивную внутреннюю группу поддержки конференции и выиграйте на новой стартовой линии.
14-я сессия Front-end Growth and Promotion, 8-29 будет в прямом эфире, 9 лекторов (Ant Financial Services / Tax Friends и т. д.),Нажмите на меня, чтобы сесть в машину 👉 (Адрес регистрации):
Текст выглядит следующим образом
Эта статья является 64-й сессией 10-го раннего чата по фронтенду. Зиянг из фронтенд-команды Zhengcaiyun поделился краткой сводной версией выступления (полную версию, включая демо, см. в записанном видео и PPT). :
Самостоятельное введение
Приветствую всех на сегодняшней утренней сессии по кросс-терминалу и кросс-стеку.Сегодня я делюсь темой "Как разрабатывать кросс-терминальные приложения на основе Electron". Позвольте мне сначала представиться. Меня зовут Лу Цзыян. Я присоединился к Zhengcaiyun в 2017. В настоящее время я в основном отвечаю за создание инженерной платформы Zhengcaiyun Dunhuang и клиента электронных торгов Zhengcaiyun. Вот публичный аккаунт WeChat нашей команды.Если вы хотите узнать больше о нашей команде, вы можете обратить внимание на наш публичный аккаунт.
конец расширения
Прежде всего, первая часть, которую мы разделяем, называетсяконец расширения. Я не знаю, знакомы ли вы с этой картинкой. Вы должны были услышать новость некоторое время назад. Илон Маск, Железный человек из Силиконовой долины, выпустил первый коммерческий пилотируемый космический корабль-дракон. Это изображение - космический корабль-дракон. Консоль , кто-то на Zhihu прокомментировал это фото как Js God. Почему вы говорите, что Джейс на небесах? Потому что ходят слухи, что он разработан на основе Electron, но эта новость не подтвердилась. Но можно подтвердить, что пользовательский интерфейс сенсорного интерфейса космического корабля действительно реализован на основе архитектуры Chromium + JavaScript. Это также объясняет, в некоторой степени, доступность и стабильность этой архитектуры.
Давайте вместе рассмотрим процесс разработки фронтенда во всей конечной области. В первые дни фронтенд-инженер мог быть веб-разработкой на основе среды выполнения браузера, но с появлением Node.js в 2009 году фронтенд-инженеры получили возможность разрабатывать вне среды выполнения браузера. У нас есть возможность разработки для сервера, а возможности фронтенда расширены на сервер.
С формулировкой стандарта HTML5 и развитием технологии мобильных устройств фронтенд-инженеры также могут больше заниматься разработкой сценариев, ориентированных на мобильные устройства. Существуют также кросс-платформенные технические решения, такие как React Native, в области мобильных устройств, как упоминалось двумя лекторами сегодня утром. По мере того, как мобильное приложение становится мейнстримом, основанным на вычислительной мощности этих интеллектуальных устройств и чипов, внешний интерфейс также популяризируется в направлении устройств IoT.Внешний интерфейс может иметь возможности разработки для IoT и таких вещей, как Thing. js также родился Js-фреймворк для разработки сетевых устройств.
CLI -> GUI
Сегодняшняя темарабочий столС появлением кросс-терминала JS-каркас такого электрона способность инженеров весь передний конец также распространяется на рабочий стол. Когда у нас такая способность разработать рабочий стол, он может принести нам, что это стоит? Сначала посмотрите на настольный клиент, который не тот же опыт для нас.
Мы можем видеть эту картину слева, работает на основе PCS на основе DOS ранних скриншотов, справа - выпуск первого Apple Apple Lisa Apple Lisa, который оснащен первым в мире графическим пользовательским интерфейсом (то есть мы сказали GUI) Персонального компьютера, это из-за появления этого компьютера, поэтому популярность позднего популярного ПК может быть достигнута. Почему он приведет к популяризации персональных компьютеров, потому что графический интерфейс для пользователей к визуально легче принять, стоимость обучения также является существенным снижением. Я полагаю, что студенты использовали систему MAC, будут хорошими для дизайна интерфейса Apple и общим интерактивным опытом, имеют более глубокое чувство.
Итак, какая разница может такую технологию настольных интерфейсов довести в мою работу в интернет-разработке?
Я полагаю, вы знакомы с процессом слева Когда мы начинаем разработку нового проекта, что нам нужно сделать? Первым шагом может быть создание репозитория Git, клонирование репозитория в локальный каталог после создания, а затем установка инструмента CLI в команде для выполнения, например.xxx-cli createТакая команда для создания проекта. После создания проекта, если мы хотим развиваться, нам нужно запуститьnpm install, установите необходимые зависимости и, наконец, отправьте весь проект в репозиторий Git. Это создание нашего нового проекта, рабочего процесса, основанного на методе CLI.Если исходить из возможностей клиента, какие изменения мы можем внести? Мы видим, что изображение справа — это скриншот системы Dunhuang, интерфейсной инженерной платформы нашей команды. Если вы создаете новый проект, вам нужно только выбрать свой собственный метод создания, а затем ввести некоторые необходимые параметры создания, такие как выбор группы репозитория Git, имя проекта, тип скаффолдинга, который необходимо создать, и после нажатия «Создать проект», это автоматически поможет вам выполнить все процессы слева. То есть 6 шагов слева упрощаются до 2 шагов, что значительно упрощает операцию связи.
Значение, заданное графическим интерфейсом
Какую ценность дает нам GUI? Во-первых, он может объединять разрозненные задачи в серии, обеспечивая более простую связь операций, в то же время он также может сглаживать различия между некоторыми процессами, используемыми разными учащимися, а также различия в некоторых средах на от которого зависит процесс, и на основе интеграционных возможностей графического интерфейса мы также можем вступать в сговор с другими возможностями по горизонтали и разрабатывать механизм подключаемых модулей через графический интерфейс, а также мы можем создавать совместно конструируемую экосистему. В то же время низкая стоимость обучения работе с графическим интерфейсом на основе графического интерфейса и его хостинг всего процесса также могут значительно снизить сложность исследований и разработок для групповых студентов.
Приложение бизнес-сценария
Ниже приведены сценарии посадки некоторых ключевых приложений, разработанных на основе Electron. Это бизнес клиента электронных торгов Zhengcaiyun, за который я несу ответственность. Его основная функция заключается в том, чтобы помочь пользователям перейти от традиционных офлайн-торгов и бумажных ставок к электронным ставкам, мы предоставляем такой клиент, чтобы помочь пользователям подключить весь процесс создания ставок. В то же время, на основе возможностей Node.js, предоставляемых Electron, чтение и запись локального тендерного файла пользователя, а также шифрование и дешифрование локальных файлов могут выполняться в клиенте.
Применение сценария инфраструктуры
Вот практика Electron на нашей инженерной платформе, которая является передовой инженерной платформой, о которой мы упоминали ранее — Dunhuang. Его основное содержание состоит в том, чтобы разместить весь процесс передовых исследований и разработок, и создание проекта, о котором мы только что упомянули, является одной из ссылок. Ниже мы подробно рассмотрим некоторые из этих приложений.
режим разработки
Выше мы кратко представили некоторые ценности Electron. Если мы хотим разработать кроссплатформенное настольное приложение на основе Electron, как нам это сделать? Давайте посмотрим на это вместе, вторая часть ** режим разработки. **В чем разница между режимом разработки Electron и нашей обычной веб-разработкой?
Электронная архитектура
Прежде всего, это общая архитектура Electron, это фреймворк с открытым исходным кодом, разработанный Github, который позволяет нам использовать HTML + CSS + Javascript для создания и разработки настольных приложений, что значительно снижает сложность разработки настольных приложений. Основной состав общей архитектуры состоит из Chromium + Node.js + Native API. Среди них Chromium предоставляет возможности пользовательского интерфейса, Node.js позволяет Electron иметь базовые операционные возможности, а API-интерфейсы Navtive решают некоторые межплатформенные проблемы, такие как экранирование некоторых различий между системами Windows, системами MAC OS и системами Linux. Он также предоставляет собственные возможности для более унифицированного взаимодействия.
точка способности
Давайте представим некоторые из его основных возможностей.
- Во-первых, это Chromium. Мы можем понимать его как браузер Chrome с новейшими функциями браузера. Преимущество, которое он дает нам, заключается в том, что нам не нужно учитывать совместимость браузера в процессе разработки. Мы можем использовать некоторые ES6, ES7. Последний синтаксис, вы можете уверенно использовать макет Flex и новейшие функции браузера, вы можете попробовать его, и вам не нужно учитывать проблемы совместимости.
- Node.js предоставляет возможность чтения и записи файлов, вызова локальных команд и сторонних расширений.Основываясь на всей мощной экосистеме Node.js, во всем клиенте можно использовать почти сотни тысяч модулей Node.js. .
- Собственные API-интерфейсы предоставляют возможности унифицированного собственного интерфейса, а также включают в себя некоторые системные уведомления, сочетания клавиш и некоторую информацию об аппаратном обеспечении системы, которую можно получить с их помощью. Он также предоставляет основные возможности настольного клиента, такие как механизм обновления, возможности создания отчетов о сбоях.
Сравнение других вариантов рабочего стола
Electron предоставляет эти точки возможностей, что значительно снижает стоимость разработки рабочего стола и порог для начала работы. Конечно, для десктопной разработки, помимо Electron, будут еще какие-то варианты, давайте разберемся, чем он отличается от других вариантов.
- Для разработки настольной части вы можете сначала выбрать Нативная разработка, Однако при разработке разных платформ вам необходимо использовать разные языки, но его преимущества в том, что он имеет лучший собственный опыт и лучшую производительность, но его порог относительно низок. Он по-прежнему относительно высок.
- QT – это кроссплатформенная среда разработки настольных компьютеров на основе C++. В ней используется язык C++. С точки зрения общей производительности и возможностей она сравнима с нативной разработкой. Однако из-за технологического стека порог разработки также относительно невысок. относительно высокая.
- Двумя другими являются Electron и NW.js. Оба они используют Javascript в качестве языка разработки. По сравнению с Native и QT они довольно дружелюбны к фронтенд-инженерам, и оба имеют относительно схожую архитектуру, основанную на реализации Chromium + Node.js, а также имеют возможность кроссплатформенной поддержки. Но разница между ними заключается в том, что у Electron лучше экология сообщества и активность сообщества. Если мы обычно сталкиваемся с некоторыми проблемами, в сообществе может быть все больше и больше полных решений. В то же время его скорость реагирования на проблемы также относительно быстро.
Таким образом, исходя из приведенного выше сравнения, Electron — очень хороший выбор для фронтенд-инженеров для разработки настольных клиентов.
Структура простого приложения Electron
Давайте посмотрим, что вам нужно сделать, если вы хотите разработать настольный клиент?
Вот структура простейшего настольного приложения Electron.Нам нужно всего три файла.Сначала мы передаем файл в package.jsonmainполе, черезmainполе для определения начальной записи для приложения. Мы определяем входной файл какmain.js,существуетmian.jsЧто мы здесь сделали? Во-первых, приложение представляет собой все приложение и отслеживает его состояние. Когда все приложение достигает состояния готовности, оно будет предоставлено Electron.BrowserWindow, чтобы создать новое окно браузера. После создания окна браузера переходим к загрузкеindex.htmlфайл, поэтому мы завершили реализацию самой базовой версии настольного приложения. Разработка настольных приложений на основе Electron отличается от обычной разработки веб-приложений.Нам необходимо понять две основные концепции:Основной процесс и процесс рендеринга, а также то, как реализована связь между двумя процессами.. В примереmain.jsработает в основном процессе,index.htmlОн работает в процессе рендеринга. Давайте возьмем простую демонстрацию, чтобы увидеть, как реализовать связь между двумя процессами и как вызвать некоторые возможности Node.js через основной процесс.
связь между процессами
Мы хотим добиться такого эффекта, на странице есть кнопка, при нажатии на кнопку она отправляетsay-helloсообщение, когда основной процесс получает сообщение, он создаст файл на рабочем столе системы с именемhello.txt. и напишите содержаниеHello Mac!。Как именно мы это делаем?
Во-первых, в процессе рендеринга у нас должно быть событие срабатывания кнопки на странице, при срабатывании которого мы будем предоставлять его через Electron.ipcRendererAPI отправляет вызов основному процессуsay-helloтакое сообщение. Когда наш основной процесс получает такое сообщение, он может напрямую вызвать модуль fs Node.js, модуль для чтения и записи файлов, в основном процессе. Сначала создадим файл и запишем содержимое нашего трансфера в этот файл. Когда файл будет успешно записан, ответьте на процесс рендеринга, вызвав Electron ProvidedNotificationМодуль отображает системные уведомления для информирования пользователей. Это простая демонстрационная реализация. Суть заключается в том, чтобы обратить внимание на концепцию основного процесса и процесса рендеринга, а также на то, как два процесса взаимодействуют через механизм IPC. Вот простой реализация. Есть еще несколько сценариев применения, и в этом разделе мы не будем слишком много рассказывать об API.
Инженерная разработка CLI -> GUI
Ниже мы представим практику разработки Electron на основе реального приложения. Взяв в качестве примера нашу интерфейсную инженерную платформу Dunhuang, мы покажем, как мы используем Electron для изменения наших инженерных возможностей с CLI на GUI. Прежде всего, давайте посмотрим видео, которое является демонстрацией работы всего процесса создания проекта, о котором мы говорили в начале. Вы можете видеть, что весь наш процесс завершил создание хранилища Git, создание шаблона проекта, отправку шаблона проекта в хранилище и локальное клонирование проекта Git.После завершения клонирования зависимости будет установлен и переустановлен на клиенте. Загрузите и управляйте таким процессом. Объедините ранее разбросанные одноточечные командные операции через графический интерфейс. Этот процесс является лишь частью инженерной платформы, во всей инженерной платформе мы реализовали подключение множества одноточечных команд к рабочему процессу.
I2P (установить для публикации)
Вот системная архитектура всей нашей платформы управления интерфейсными приложениями, взгляните на нее. Основной процесс представляет собой описанную выше концепцию I2P, котораяinstall to publish. Он завершает три уровня компонентов, шаблонов и проектов, от создания до публикации всего процесса хостинга.
- Этап создания в основном обеспечивает обратную связь, включая локальное создание, создание Git, управление шаблонами единого создания, утверждение процесса создания и завершение создания.
- На этапе разработки он обеспечивает возможность работы Dev Server, управление страницами на уровне проекта, управление зависимостями, управление ветвями и возможность обновления одним щелчком мыши. В то же время он также открыл возможности непрерывной интеграции CI/CD.
- На этапе выпуска обеспечивается предварительная проверка разрешений и обнаружение соответствия, отправка ресурсов и механизм утверждения выпуска.
- Анализ данных является основной частью всего нашего процесса. Он выделяет некоторые данные во всем нашем процессе и выводит эти данные в виде визуальных отчетов. На основе этих данных весь процесс I2P сравнивается с другими возможностями.
Во всем процессе I2P, описанном выше, мы осаждаем некоторые данные элемента, включая данные потока, могут быть некоторые аналогичные данные управления компонентами. Данные, весь процесс разработки может быть открыт с помощью ряда других технических возможностей для создания точек подключения, включая анализ поведения пользователей, анализ производительности на уровне страниц, анализ производительности на уровне проекта, а также механизм мониторинга ошибок, может получить доступ ко всему инженерная платформа.
Мы поддерживаем весь проект — это возможности платформы и некоторые базовые возможности настольного компьютера, которые предлагает Electron.
Базовые навыки, в том числе некоторые обычные операции с GIt, операции с NPM, выполнение команд и некоторые службы локального журнала. Electron включает в себя обновление рабочего стола, управление окнами, связь и другие возможности.
от точки к строке
Единая команда -> поток задач
Давайте конкретно рассмотрим, как реализовать конкатенацию из одной точечной команды в поток задач. Чтобы изменить работу одноточечной команды на последовательный режим потока задач, мы должны реализовать ее из следующих четырех точек входа. • Прежде всего нам нужно преобразовать некоторые обычные вызовы команд в вызовы функций. • Организуйте и соберите поток задач на основе этих функциональных вызовов и настройте поток задач в соответствии с реальным сценарием разработки. • Третий элемент, который нам нужен, — это механизм обратной связи о ходе выполнения всего потока задач, способ выполнения задачи с помощью графического пользовательского интерфейса, чтобы пользователь мог интуитивно чувствовать связь выполнения и ход выполнения всей задачи. • Наконец, во всем потоке задач очень важной частью является сбор данных всего процесса.
разработка процесса
Ниже представлен архитектурный дизайн процесса создания проекта, который мы только что продемонстрировали. Когда мы вызываем модуль создания проекта, мы сначала создадим проект Git через интерфейс сервера. Сначала выполняется уровень проверки прав доступа всего пользователя.После прохождения проверки создается хранилище путем вызова API Gitlab.После этого единый шаблон проекта обслуживания вытягивается в соответствии с выбранной информацией шаблона.Согласно к вводу проекта с помощью имени пользователя, описания проекта и другой информации для создания реального файла проекта и вызова API Gitlab для отправки всего файла проекта в созданный репозиторий. Что касается использования Gitlab API, статьи были опубликованы на Nuggets, Если вам интересно, вы можете узнать об этом, и я не буду подробно останавливаться на этом здесь. После того, как весь наш сервер завершит ряд операций по созданию Git, URL-адрес успешно созданного хранилища будет передан нашему рабочему столу.После получения результатов успешно созданной задачи рабочий стол начнет выполнять некоторые локальные операции. Клонируйте репозиторий Git в свою локальную рабочую область и одновременно устанавливайте зависимости для всего проекта. После установки зависимостей мы будем использовать возможности уведомлений рабочего стола, включая интерфейс DingTalk, для завершения уведомлений и обратной связи. Среди них клонирование, установка зависимостей и обратная связь с уведомлениями выполняются в основном процессе нашего рабочего стола. Он имеет обратную связь в режиме реального времени и процесс рендеринга на протяжении всего нашего потока задач. Мы будем сообщать о ходе выполнения всей задачи, включая вывод журнала выполнения команды и результат выполнения команды, с рендерингом в режиме реального времени через IPC и, наконец, давать отзывы пользователей об интерфейсе. На протяжении всего процесса также сохраняются данные проекта и данные процесса.
Чтобы добиться такого цельного процесса, что нужно сказать на практике?Давайте посмотрим на конкретный код.
npm install становится npm.install()
Во-первых, при вызове командыnpm installТакой вызов командной строки становится функциональным вызовом, который становитсяnpm.install()Такой метод вызова.
git init становится git.init()
Git-подобные команды также станут функциональными вызовами.
Делайте императивные обещания выполнения
Давайте рассмотрим конкретный сценарий, как превратить императивный вызов в вызов функции.
Первый — Обещать выполнение команды. Напримерgit initВ такой операции при выполнении всей команды нас больше волнует результат выполнения всей команды, и мы можем не сильно заботиться о каком-то выводящемся содержимом во время выполнения команды. Таким образом, мы можем передать Node.jsspawn, запустите подпроцесс для выполнения команды. Судя о статусе выполнения всей нашей команды, прослушивая вывод подпроцесса, а затем инкапсулируя всю команду с помощью Promise, мы закончили.git initТакой вызов командной строки становитсяgit.init()Такой асинхронный вызов функции.
Журнал выполнения команды вывода в реальном времени
В другом сценарии, скажемnpm install, в зависимости от установки или запуска локальной службы разработки процесс выполнения всей команды может быть относительно длительным, и нас больше беспокоит вывод журнала в реальном времени во время процесса. Как мы делаем это?
Во-первых, давайте создадимEventEmitterНапример, в качестве управления распределением наших журналов мы также передаемspwanЧтобы запустить подпроцесс для выполнения команды и отслеживать вывод подпроцесса в режиме реального времени, передайте журнал вывода черезemitterЭкземпляр распространяет его. Когда мы получаем такой вывод журнала в реальном времени в основном процессе, мы можем выводить журнал в процесс рендеринга в реальном времени посредством связи IPC между основным процессом и процессом рендеринга.
Превратите императивные вызовы в функциональные вызовы. С помощью этой возможности вы можете упорядочить поток задач, вызывая эти функции. Например, создание проекта, о котором мы только что упоминали, что может быть относительно распространенным процессом, а также управление компонентами, управление шаблонами и выпуск проекта. Вы можете организовать свой собственный поток задач в соответствии с реальными потребностями вашего бизнеса.
Терминал моделирования: обратная связь о ходе выполнения задачи
Выше мы упомянули некоторые изменения в способе выполнения всей команды в основном процессе. Итак, в нашем процессе рендеринга, как нам добиться обратной связи журнала терминала, похожей на только что показанное видео? Есть много способов оставить отзыв.Мы можем оставить отзыв о ходе выполнения всей задачи, разработав пошаговую шкалу для некоторых задач или индикатор выполнения. Но лучший способ заключается в том, что мы можем дать своевременную обратную связь о ходе выполнения задачи, включая весь журнал выходных данных задачи. Здесь мы используем xterm.js. Это интерфейсный компонент терминала, написанный на основе ts, который может реализовывать терминальные приложения в браузере.VsCode также основан на xterm.js для реализации терминала. Как вывести журнал основного процесса в процесс рендеринга, это то, о чем мы упоминали выше.После получения вывода, передаваемого EventEmitter, данные должны быть переданы в процесс рендеринга через связь между основным процессом и процессом рендеринга. Процесс рендеринга — это процесс, который необходимо выполнять в процессе рендеринга, а полученные выходные данные команды визуализируются в режиме реального времени на терминальный компонент, реализованный xterm.
В этом случае мы завершили механизм обратной связи всей задачей.
Выше приведена реализация потока задач в нашей инженерной платформе.С помощью возможностей Электрона мы легко реализуем постановку задач всего процесса, а также реализуем интерфейсное взаимодействие соответствующего процесса и упрощаем весь процесс . В дополнение к реализации потока задач нам необходимо уделять больше внимания сбору данных во всем процессе, включая данные процесса, осаждение данных проекта и компонента, созданное в процессе, и некоторые аномальные данные в процессе, потому что эти данные Это основа для открытия других возможностей инфраструктуры, и в то же время это также позволяет нам постоянно оптимизировать весь процесс.
возобновить
После завершения разработки клиента необходимо рассмотреть вопрос о последующем обновлении.Давайте посмотрим, как мы можем реализовать функцию автоматического обновления клиента.Electron предоставляет относительно полный механизм обновления пакетов.
После сборки нашего приложения через Election-Builder он выведет файл last-mac.yml и zip-пакет приложения, и поместит эти два файла на сервер обновлений.Существует множество схем реализации сервера обновлений.CDN как сервер обновлений.
Как мы проектируем весь процесс обновления?В процессе рендеринга обычно предоставляется триггерная запись для ручного обнаружения обновлений, или определение обновления версии выполняется регулярно с помощью задач опроса.
После того, как процесс рендеринга инициирует запрос на определение версии, он будет вызван в процессе рендеринга.autoUpdaterмодуль, этоElectronВстроенный модуль управления обновлениями.
Во-первых, вам нужно установить feedUrl, который является адресом последнего пакета обновлений на сервере обновлений. После получения запроса на определение версии для процесса рендеринга вызовитеcheckForUpdatesметод, а затем он вызовет следующую серию событий.Мы можем полностью контролировать весь процесс обновления, отслеживая каждый жизненный цикл всего события обновления.
Проблема, с которой сталкивается встроенный механизм обновлений Electron, заключается в том, что пакет обновлений относительно велик. Поскольку настольное приложение, которое мы создали через Electron, интегрирует весь Chromium, даже если мы напишем небольшое приложение, такое как Hello world, его объем после сжатия составит около 40 МБ, обычное приложение может занимать около 100 МБ. Такая проблема заключается в том, что когда есть какие-то относительно небольшие изменения, требуется полное обновление, что не очень хорошо для пользовательского опыта Какие решения у нас есть для этого? Прежде всего, мы можем оптимизировать весь обновленный дизайн взаимодействия. Что нам нужно предоставить, так это обратную связь о ходе всего процесса обновления, и еще один момент заключается в том, что мы можем использовать autoUpdater для достижения фоновых загрузок. Когда мы завершим загрузку всего пакета обновлений, а затем уведомим пользователя о перезапуске всего приложения, а затем обновим все приложение, таким образом, с интерактивного уровня, в определенной степени добавочное обновление избежит пользователя опыт, некоторое влияние. Конечно, с полными обновлениями будут проблемы, если количество пользователей относительно велико, это приведет к трате сетевых ресурсов.
Инкрементальный выпуск
Ниже приведены некоторые из наших практик по инкрементным выпускам. Во-первых, статические ресурсы всего уровня визуализации размещаются в CDN. Для всего нашего приложения статические ресурсы уровня рендерера не будут упакованы в конечную настольную программу, а ресурсы будут размещены удаленно.В то же время, в соответствии с некоторыми конкретными бизнес-сценариями, мы можем использовать возможности сервис-воркера для сделать автономный кеш для всего ресурса и сделать контроль версий для статических ресурсов.
процесс обновления
Процесс обновления слоя Renderer выглядит следующим образом: когда страница отправляет запрос, она сначала сопоставляется с тем, есть ли кэш такого ресурса локально, и если мы сопоставляем ресурс, он возвращает соответствующий результат. Если локального совпадения нет, последний ресурс повторно запрашивается, и запрошенный ресурс одновременно кэшируется. Если во время всего процесса запроса возникает ошибка, вам необходимо иметь версию ресурса по умолчанию, которую можно использовать, и сообщить об ошибке.
Здесь мы реализовали добавочное обновление на основе слоя пользовательского интерфейса. В реальных бизнес-сценариях необходимо решить, следует ли оптимизировать процесс обновления, использовать добавочное обновление на уровне пользовательского интерфейса или добавочное обновление пакета установки в соответствии с частотой обновления различных ресурсов.
Схема технической архитектуры инженерной платформы Дуньхуан
Вот архитектура всей платформы управления приложениями.Во всей нашей инженерной практике, помимо реализации полного процесса I2P-хостинга всего проекта, компонентов и шаблонов, мы также предоставляем другие возможности, такие как конвергенция групповых порталов, Включая ввод документа, ввод вывода и в то же время интеграцию некоторых инструментов в команду, интеграцию некоторых инструментов, разбросанных по разным местам, таких как инструменты создания сайта документа, инструменты для создания изображений, инструменты управления значками, и мы. Он также собирает поведение пользователей данные всего клиента и непрерывно повторяет анализ данных.
больше сцен
Вышесказанное является практикой нашей фронтенд-инжиниринговой платформы на основе Electron. Конечно, у Electron будут и другие сценарии применения, давайте посмотрим.Во-первых, код VS, а также IDE апплета Alipay также реализованы на основе фреймворка Electron.
Слева находится настольный инструмент управления интерфейсом, предоставляющий вспомогательные функции для процесса разработки. Другой switchhosts, который является инструментом управления локальной средой. Вы можете видеть, что настольные приложения, разработанные на основе Electron, участвуют во всем нашем процессе исследований и разработок, начиная с нашего управления локальной средой, управления процессами, помощи в разработке и этапов редактирования исследований и разработок. Платформа управления инженерными разработками находится в сговоре со всем процессом жизненного цикла НИОКР, но на этапе фактического кодирования фактически отсутствует связь, которая по-прежнему должна полагаться на возможности IDE. Основываясь на некоторых возможностях Electron в направлении IDE, одно из наших будущих направлений также заключается в том, чтобы надеяться на сговор со всей локальной средой кодирования IDE и всем нашим процессом исследований и разработок, чтобы действительно реализовать сговор и повышение эффективности всего звена исследований и разработок. .
Конечно, есть и другие возможности, то есть более крупная сцена, такая как SpaceX, упомянутая ранее~
порекомендовать книгу
Ниже приводится книга, которую я лично рекомендую, "Неизведанная дорога". Из нее вы можете извлечь уроки из того, как смотреть на проблемы, с которыми вы сталкиваетесь, более зрелым умом. В процессе взросления нас ограничивает, скорее всего, ограничение познания и мышления. Какое познание и менталитет смотреть на возникающие проблемы будут определять, какой ответ и какая способность реагировать на эти проблемы. Эта книга позволит нам больше узнать о том, как смотреть на возникающие проблемы более зрелым умом.
Я надеюсь, что с помощью этой книги каждый сможет научиться лучше справляться с проблемами, не связанными с технологиями, и лучше решать проблемы.
Прием на работу
Все вышеизложенное - это все, чем я делюсь сегодня. Вот QR-код официального аккаунта нашей команды. Вы можете узнать о некоторых результатах нашей команды. В то же время мы также набираем фронтенд-стажеров, старших и старших фронт- конечные инженеры недавно. Если вы заинтересованы, вы можете отправить свое резюме на адрес электронной почты ниже, спасибо~
QA
Я хотел бы спросить Ziyang: Как выполнить горячее обновление? Насколько я знаю, в пакет помещаются страницы, упакованные Электроном.Как обновить онлайн?
Я так понимаю, что проблема должна быть в обновлении интерфейса UI слоя. На самом деле, как я только что упомянул, мы размещаем некоторые статические ресурсы страницы на CDN, при обновлении будет механизм обнаружения обновления, который может быть реализован путем опроса или отправки сервера. обновить версию ресурса и выполнить принудительное обновление процесса рендеринга через основной процесс, игнорируя кеш.Обновить статические ресурсы на уровне пользовательского интерфейса.
Я хотел бы спросить Зияна: можете ли вы сравнить разницу между Electron и NW.js?
Самая большая разница между ними заключается в том, что интеграция Node.js и механизма цикла событий Chromium обрабатывается по-разному. Во-первых, NW.js позволяет открыть механизм цикла событий Chromium и Node.js путем изменения исходного кода; Electron реализует этот механизм, позволяя новому безопасному потоку пересылать события между Node.js и Chromium, чтобы соедините два. Одним из преимуществ этого является то, что механизм цикла событий Chromium и Node.js не так сильно связан. Еще одно отличие состоит в том, что NW.js поддерживает систему xp, а Electron — нет. Для сравнения, у Electron более активное сообщество и более практичные случаи крупномасштабных приложений, таких как код VS и Atom, Дополнительные различия см. В официальном представлении Electron:呜呜 .Электрон js.org/docs/ Вело...
Я хотел бы спросить Ziyang: файлы пакета обновления находятся на частном файловом сервере или в Gitlab или Github?
Есть много способов, наша реализация через хостинг CDN, или через построение Github или частного файлового сервера. Выбирайте в соответствии с реальным бизнес-сценарием и стеком технологий.
В этой статье используетсяmdniceнабор текста