Краткий обзор разработки гибридных настольных компьютеров

APP внешний фреймворк

Неосознанно я работаю на али уже год.В течение этого года я в основном сталкивался с лоу кодом(Low Code),маленькими программами,мобильным H5,мониторингом и десктопом ПК(CEF & Electron) и другие технологии разработки. Среди этих технологий гибридная технология разработки настольных компьютеров для ПК является относительно более осадочной.Далее я поделюсь с вами некоторыми мыслями о разработке настольных компьютеров, надеясь вдохновить каждого на ежедневное развитие.

Советы: Если вы не знаете о настольных технологиях, вы можете сначала проверить это.Годовой отчет Front-end за 2019 год / Разработка настольных компьютеров. Кроме того, технология разработки настольных компьютеров, описанная в этой статье, не использует новую технологию Flutter.Если вы очень заинтересованы в построении внутренней технологии Alibaba Flutter, вы можете проверитьКак построить систему Flutter в Alibaba Group.

основная концепция

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

Гибридная разработка

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

CEF-контейнер

Гибридная гибридная разработка, описанная в этой статье, в основном используетCEF (встраиваемая платформа Chromium)технологии, ее основные особенности заключаются в следующем:

  • Браузер Google Chromium, совместимый с HTML5, можно встраивать в нативные нативные приложения.
  • Облегченные контейнеры приложений (сокращенно CEF-контейнеры) могут быть созданы для размещения пользовательских интерфейсов, разработанных с использованием веб-технологий.
  • Может поддерживать кроссплатформенную (Mac, Linux и Windows) разработку, а также упрощает настройку и интеграцию других типов собственных приложений.
  • Будет отслеживать обновление версии Google Chromium в режиме реального времени, что позволит веб-разработчикам использовать некоторые относительно новые функции.
  • Разработанный и спроектированный на языках C и C++, он может быть тесно интегрирован с браузером Google Chromium.
  • Некоторые версии CEF могут поддерживать запуск настольных приложений в системах Windows XP.

Следует отметить, что упомянутый выше контейнер CEF можно просто понимать как встраивание браузера Google Chromium в нативную среду приложения. Кроме того, настольные приложения могут разрабатываться в многооконном режиме разработки, и в каждом окне может размещаться по крайней мере одно внешнее веб-приложение (для краткости — подприложение). Если вы хотите обмениваться данными между несколькими подприложениями, вы можете использовать URL-адресqueryПараметры (низкие требования к реальному времени) или механизм публикации-подписки в технологии Native bridge (высокие требования к реальному времени).

Советы: Многие студенты не понимают разницы между Google Chromium и Google Chrome, и это стоит Goolge.

JSBridge & Native API

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

Советы: Изображение предоставлено коллегой, конкретный источник не найден.

Левую часть (среда разработки механизма саморисования) на приведенном выше рисунке можно просто рассматривать как нативную разработку, а правую часть (инфраструктуру пан-веб-контейнера) можно рассматривать как гибридную смешанную разработку. Можно обнаружить, что если веб-интерфейс хочет обойти ограничения песочницы и вызвать собственные компоненты представления и возможности системы, ему необходимо использовать технологию Bridge, предоставляемую Native. Собственные приложения в контейнере CEF могут вторгаться в среду синтаксиса JavaScript, поэтому они могутwindowГлобальный объект) подключается в виде API-интерфейса для инъекций, API здесь называется Native API.

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

JS API

Помимо разработки собственных приложений, настольный компьютер Ali также предоставитСервисная платформаДля внешних независимых поставщиков программного обеспечения для расширения сторонних приложений. В настоящее время необходимо открыть возможности Native API (которые будут включать некоторые версии вызовов и обработку сопоставления аутентификации).Эти открытые API называются JS API, которые будут более абстрактными по возможностям, чем Native. API, он должен быть кроссплатформенным, кросс-приложением и т. д., как показано на следующем рисунке:

Советы: Теоретически любая технология, какая только придет в голову, будет закрыта внутри Ali, и JS API не исключение.

HotFix

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

Советы: Изображение изСтроительство площадки горячего ремонта в эпоху большого фронтенда.

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

настольная разработка

За один год Али разработка рабочего стола в основном прошла несколько этапов:

  • Узнайте о существующих средах рабочего стола
  • Разработка новых подприложений в существующей структуре
  • Оптимизированное исследование настольных фреймворков
  • Разработайте и внедрите новую среду рабочего стола

Узнать о настольных фреймворках

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

Фреймворк в основном включает в себя три уровня: контейнерный уровень, общий уровень и прикладной уровень.Функции примерно следующие:

  • Все суб-приложения размещаются в одном репозитории для разработки и обслуживания.
  • Многоканальная конфигурация Webpack, многопроцессорная обработка Webpack и конфигурация разработки
  • Стек технологий, используемый при добавлении подприложений, будет ограничен фреймворком.
  • Используйте TypeScript для развития бизнеса с хорошей надежностью
  • использоватьRxjs(поток событий действия) обработка событий в сочетании с публикацией и подпиской
  • React Router не используется, а переключение простых страниц осуществляется с помощью управления состоянием.

Разработка новых подприложений

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

Бизнес-уровень

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

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

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

Ограничения MVC

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

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

Следует отметить, что данные представления будут увеличиваться по мере усложнения бизнеса.Когда связь между данными представления и представлением становится все более и более сложной, легко вызвать повторяющиеся проблемы с визуализацией.immutability-helperСотрудничатьReact.PureComponentилиshouldComponentUpdateПроцесс (дополнительные предложения по оптимизации для React можно найти в официальной документацииOptimizing Performance).

Советы: код, написанный многими студентами, будет сильно зависеть от внутренних данных интерфейса.Как только внутренние данные выйдут из-под контроля, это легко приведет к белому экрану на странице внешнего интерфейса. Чтобы повысить надежность и ремонтопригодность кода, к уровню данных добавляется уровень адаптации для внутренней обработки данных, который может отделить внутренние данные от представления внешнего интерфейса. В процессе адаптации вы можете использовать предложение ECMAScript, поддерживаемое Stage-4.Optional Chainingсинтаксис для обработки данных (если среда компиляции не поддерживает этот новый синтаксис, вы можете использовать Lodash'sgetинструментальный метод).

Оптимизация рабочего стола для изучения

В процессе разработки подприложений я постепенно осознал некоторые болевые точки старого клиентского фреймворка:

  • Сложная многоканальная конфигурация Webpack и избыточная конфигурация разработки
  • несмотря на использованиеparallel-webpack, скорость компиляции приложения низкая, что снижает эффективность разработки
  • Отсутствие возможности горячей перезагрузки снижает эффективность разработки
  • Невозможно использовать функции более новых версий React, такие как React Hooks.
  • Невозможно использовать функции новой версии JavaScript и TypeScript, такие какOptional Chaining
  • Адская вложенность, образованная функциями высшего порядка бизнес-уровня/контейнера, делает код раздутым и сложным, что не способствует ремонтопригодности кода.
  • простое вспомогательное приложениеRxjsПубликация и подписка, а также механизм потока действий не способствуют сопровождению кода.
  • Общие коды, такие как бизнес-компоненты на уровне общественных услуг и материальном уровне, не абстрагируются и не разделяются.
  • ...

Примерно предусматриваются некоторые локальные оптимизации фреймворка:

Как видно из рисунка выше, на основе оригинального фреймворка добавлена ​​структура Monorepo, характеристики фреймворка следующие:

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

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

Советы: инструменты разработки Monorepo включаютNx,LernaЖдать. Чтобы узнать больше о Monorepo в действии, ознакомьтесь сVue CLI 3 сочетает в себе Lerna для разработки фреймворка пользовательского интерфейса.

Технология осадков

Практика оптимизации фреймворка на стороне рабочего стола

Чтобы полностью отделить субприложения, новые субприложения не разрабатываются и не поддерживаются на складе исходного приложения, а разрабатываются и поддерживаются независимо с использованием технических возможностей Группы. Кроме того, общие возможности шаблонов настольных терминальных приложений добавлены на основе скаффолдинга, который можно быстро сгенерировать с помощью команд CLI одним щелчком мыши:

Краткое введение в наращивание потенциала проекта:

  • Групповые леса: просто понимать какreact-scripts, который может поддерживать различные режимы разработки, такие как приложения, компоненты и небольшие программы.
  • Инженерный мониторинг: используется для мониторинга и составления отчетов о производительности компиляции каркаса во время разработки и использования, а также собственной информации об ошибках.
  • Пользовательский плагин Webpack: специальные требования к компиляции для пользовательских терминальных приложений для настольных компьютеров
  • Шаблон разработки подприложения: объединяет основные возможности настольной разработки.
  • Получение шаблона: вы можете получить и создать распространенные типы шаблонов разработки одним щелчком мыши с помощью команд CLI.

Структура шаблона разработки подприложения примерно следующая:

Здесь мы в основном объясняем общее наращивание потенциала:

  • ErrorBoundary: просматривать обработку белого экрана (отображать представление ошибок в нижней части кармана), а также выполнять мониторинг и отчетность по обработке белого экрана.
  • Hook: Многотерминальная универсальная настройкаHookспособность
  • Request: Многотерминальная библиотека общих запросов, которая может выполнять кэширование и оптимизацию загрузки (загрузка не генерируется в течение определенного времени запроса, кэширование данных запроса и т. д.)
  • Utils: Общая служебная функция

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

Советы: Упомянутый здесь мультитерминал относится к апплету, H5, ПК-клиенту (Windows, Linux, Mac) и т. д. Это обычное конструктивное предложение.

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

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

  • Добавлены возможности инженерного мониторинга для быстрого определения эффективности разработки каждого подприложения.
  • Конфигурация Webpack поддерживается инженерными каркасами
  • Улучшите скорость компиляции и увеличьте возможности горячей перезагрузки
  • Используйте новейшие функции React, JavaScript и TypeScript
  • Преобразование многоуровневой структуры разработки, оптимизированной пилотным подприложением, в плоскую структуру разработки (удаление возможности контейнера функций более высокого порядка)
  • Испытайте улучшения, такие как кэширование запросов, оптимизация загрузки и отказоустойчивость ErrorBoundary для представлений.
  • Просмотр возможности мониторинга белого экрана
  • По-настоящему несвязанные подприложения, позволяющие настраивать клиентские приложения

Кроме того, на основе старого фреймворка добавляется новый слой сборки. Поскольку оптимизация фреймворка отделяет каждое подприложение, необходимо объединить продукты сборки всех подприложений (стать автономным продуктом веб-интерфейса в пакете установки клиента). Поэтому добавляется уровень построения для обработки отношения сопоставления версий каждого подприложения и совместной обработки облачного построения.Здесь Jenkins, Node и Shell используются для онлайн-конструирования и объединения продуктов каждого подприложения.

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

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

Центр документации

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

  • Руководство по разработке
  • Описание деятельности
  • техническое планирование
  • Спецификация
  • Прогресс бизнеса

Ключевым моментом является руководство по разработке, которое, вероятно, будет включать в себя следующее:

  • Введение в разработку
  • Основные понятия
  • общая структура
  • шаблон проекта
  • Инструменты разработки
  • Разработка и отладка
  • спецификация версии
  • построить онлайн
  • сбой онлайн

Оптимизация сборки

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

Среди них будут добавлены возможности онлайн-обнаружения, в основном в том числе:

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

Сотрудничество в процессе в основном предназначено для повышения эффективности строительства.В некоторых замкнутых циклах, связанных с процессами НИОКР, строительство может выполняться быстро. Например, в Gitlab для фиксации определенногоcommitкод сообщения илиpublishКонкретная ветвь может инициировать сборку (это похоже на Github Actions).Конечно, уровень триггера здесь включает не только Gitlab, но и многие платформы для совместной работы в области исследований и разработок внутри Alibaba.

Услуги НИОКР

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

Служба НИОКР — это базовая служба для открытия всей связи НИОКР на рабочем столе (она также может включать такие приложения, как апплеты и H5) в будущем. На инженерном уровне можно интегрировать что-то вродеvue uiВозможность гибко интегрировать существующие шаблоны подприложений в подключаемые модули, чтобы их можно было быстро адаптировать к требованиям исследований и разработок различных бизнес-сценариев. Кроме того, общая связь НИОКР от создания приложения, сопоставления требований, изменения требований, управления ветвями, разработки требований, построения облака, сопоставления дефектов, оттенков серого и выпуска может быть выполнена на платформе службы НИОКР, чтобы обеспечить инженерную интеграцию систем. , координация процессов и строительство.

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

Категории