Автор: Мэн Лю

Hongmeng — это операционная система терминала нового поколения, разработанная Huawei, которая может применяться к различным типам устройств, таким как IoT, часы, мобильные телефоны, планшеты и телевизоры. Версия OpenHarmony 2.0 Canary будет выпущена в начале июня 2021 года, с открытым исходным кодом для большего количества подсистем и поддержкой устройств с памятью более 128 МБ. Сюда входит новая версия фреймворка JS UI, анализу этой части кода и посвящена данная статья. (Содержание статьи предназначено только для справки. Если есть какое-либо неточное описание, спасибо за обсуждение и исправление фона~)

Обзор системы Хунмэн

Слои системной архитектуры

Для получения дополнительной информации рекомендуется перейти на официальный сайт OpenHarmony [1] Ниже приведена официальная схема технической архитектуры:

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

Обратите внимание, что это архитектура OpenHarmony. Она не содержит GMS и HMS, не содержит AOSP и не поддерживает Android API. Она отличается от версии HarmonyOS, продвигаемой мобильными телефонами Huawei. Сравнение проводится ниже.

Различия между HarmonyOS и OpenHarmony

Все китайские имена называются «Хунмэн», но за ними все же есть некоторые отличия. HarmonyOS — коммерческая операционная система, разработанная Huawei, а OpenHarmony — версия с открытым исходным кодом, подаренная Huawei Фонду Open Atom (OpenAtom) «Рукава» шатаются.

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

Прежде всего, приложения Hongmeng упаковываются и распространяются в формате HAP (Harmony Ability Package), который представляет собой сжатый пакет, такой как Android APK, и структура пакета аналогична. После того, как он распространяется на терминал, он унифицируется API Hongmeng (концепция), а затем разделяется на разные режимы. Версия Hongmeng, установленная на мобильных телефонах Huawei, может быть совместима с приложениями Android без каких-либо ощущений и должна зависеть от AOSP. Часть с открытым исходным кодом предназначена в основном для недорогих устройств IoT, или браслетов для часов и т. д., или даже без экрана Версия с открытым исходным кодом в июне 2021 года поддерживает только устройства с памятью более 128 МБ и не может самостоятельно поддерживать приложения на мобильные телефоны. Это два крайних сценария «обстрела» и «самоисследования», которые не обязательно являются устойчивыми конечными состояниями. Между ними подсистемы уровня инфраструктуры и уровня системных служб в общей архитектуре относительно независимы и развязаны и могут использоваться в этих сценариях одновременно, но функции недостаточно надежны, и некоторые из них имеют имеют открытый исходный код, например Microkernel и JS UI framework, а некоторые не являются открытым исходным кодом. Совместимость с Android не является долгосрочным решением, а часть с открытым исходным кодом имеет простые функции, поэтому неуверенная часть посередине будет основным звеном в будущем? Действительно ли Hongmeng превратится в самостоятельную полноплатформенную операционную систему в будущем? Давайте подождем и посмотрим.

Тогда вы можете попробовать ответить на самые обсуждаемые вопросы Hongmeng в сообществе:

Является ли Hongmeng саморазвитым? Должна быть саморазрабатываемая часть, а также она должна опираться на какие-то (зарубежные) сторонние коды.На данном этапе нереально требовать, чтобы весь код был саморазрабатываемым, и его нельзя завершить за один-два года, он должен сначала встать на плечи гигантов для инноваций, а затем еще больше сократить зависимости и разобраться с договоренностями и вопросы авторского права.

Полагается ли Hongmeng на AOSP? Можно сказать, что оно зависимо, а можно сказать, что оно не зависит.Режим совместимости HarmonyOS зависит от AOSP., иначе нет возможности быть совместимым с приложениями Android;OpenHarmony с открытым исходным кодом не зависит от AOSP., но в настоящее время в основном используется на некоторых недорогих устройствах IoT.

Если не указано иное,Упомянутый ниже «Hongmeng» относится конкретно к OpenHarmony..

Подсистема пользовательского интерфейса Harmony

В опенсорсной версии Hongmeng нет Java UI (по крайней мере, я его не нашел), фреймворк для реализации JS UI называется ACE, что является сокращением от Ability Cross-platform Environment, есть два склада: ace_engine_lite[2] соответствует старой архитектуре ACE, ace_ace_engine [3]. В соответствии с новой архитектурой ACE принцип реализации и синтаксис верхнего уровня отличаются.

Структура исходного каталога

Открытый исходный код OpenHarmony размещен на gitee, а в группе более 200 складов.Рекомендуется скачивать код согласно документам, полученным из официального исходного кода.Для соответствующей взаимосвязи между структурой каталогов исходного кода и каждого хранилища, пожалуйста, обратитесь к файлу конфигурации хранилища манифестов [4].

Если ваша среда уже настроена, выполните следующие две строки команд:

repo init -u https://gitee.com/openharmony/manifest.git -b master --no-repo-verify
repo sync -c

Весь процесс занимает около 15~30 минут После выполнения первой строки команды вы можете найти файл конфигурации манифеста и удалить зависимости linux и некоторые сторонние_партии, что будет быстрее.

Сокращенная версия структуры каталогов выглядит следующим образом (пропустите ненужные каталоги и разверните только соответствующие части):

OpenHarmony/
  ├── applications          # 应用程序样例
  ├── base                  # 基础软件服务子系统集
  ├── docs
  ├── domains               # 增强软件服务子系统集
  ├── drivers               # 驱动子系统
  ├── foundation            # 系统基础能力子系统集
  │   ├── aafwk                # Ability 框架
  │   ├── ace                  # JS UI 框架
  │   │   ├── ace_engine           # ACE 1.0, 仓库名: ace_ace_engine
  │   │   └── ace_engine_lite      # ACE 2.0, 仓库名: ace_engine_lite
  │   ├── appexecfwk           # 用户程序框架和包管理模块
  │   └── graphic              # 图形库相关的子系统
  ├── interface
  │   └── sdk-js               # JS API 的 TS 类型文件
  ├── kernel                # LiteOS 内核
  │   ├── liteos_a
  │   └── liteos_m
  ├── test
  └── third_party

Старый и новый фреймворк ACE

Ниже приведена схема архитектуры фреймворка ACE [5].Теперь пользовательский интерфейс описан в документе и поддерживается в среде IDE.Он предоставляет DSL[6], аналогичный аплету для разработки пользовательского интерфейса, HML (HarmonyOS Markup Language) + CSS + JS.

Он похож на архитектуру основного фреймворка JS + нативный рендеринг.Он предоставляет инструмент компиляции для компиляции исходного кода в пакет js.Во время выполнения существует файл framework.min.js, который выполняется по умолчанию после JS. Engine начинает реализовывать логику построения узла, а затем набор UIKit реализуется на уровне C++, и поддерживается около двадцати или тридцати компонентов.

На другом складе без суффикса lite (ace_ace_engine) также есть набор реализации системы пользовательского интерфейса.Уровень архитектуры более лаконичный, а технология более продвинутая.Это должно быть новое поколение фреймворка пользовательского интерфейса.Это диаграмма архитектуры новая структура ACE [7]]:

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

Нижний слой переноса является ключом к адаптации к нескольким платформам.Он определяет независимую от платформы структуру данных слоя, которая может быть отправлена ​​​​в разные композиторы для композитного рендеринга.С точки зрения кода, он поддерживает Flutter Engine.

Общий процесс рендеринга

Создание контейнера и управление им

Базовой единицей пользовательского интерфейса Hongmeng является FA (возможность функции), которая соответствует экземпляру AceAbility, предоставляет крючки жизненного цикла и создает AceContainer внутри при выполнении OnStart(). Но этот AceContainer не принадлежит напрямую AceAbility, а управляется глобально уникальным синглтоном AceEngine.

AceContainer предоставляет различные возможности для рендеринга пользовательского интерфейса.Это общий класс управления, который предоставляет интерфейсы планирования жизненного цикла и функций.Он разделен на множество подмодулей:

• Frontend: среда выполнения внешнего кода, JS или JSON, с этим уровнем абстракции, она также может поддерживать другие механизмы сценариев.
• TaskExecutor: Диспетчер задач в одном потоке, аналогичный TaskRunner в других механизмах рендеринга.

• AssetManager: Менеджер ресурсов, который можно использовать для загрузки таких ресурсов, как код JS, изображения, шрифты и т. д. Должен также иметь возможности кэширования.
• PipelineContext: класс управления конвейером рендеринга, прослушивающий обратный вызов vsync для обновления макета, рисования и рендеринга внутренних грязных узлов.

• AceView: корневой узел пользовательского интерфейса, сгенерированный при рендеринге, можно вставить во внешний контейнер.
• PlatformResRegister: Регистрация и управление ресурсами платформы, а также некоторые коммуникационные интерфейсы могут реализовать здесь ту же функцию рендеринга слоев.

JS-фреймворк для разработки пользовательского интерфейса

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

JS Frontend (императивный пользовательский интерфейс)

«Важный пользовательский интерфейс» — это заявление с точки зрения реализации движка, потому что нижний уровень основан на инструкциях по рендерингу, а синтаксис, который действительно раскрывается разработчикам, может быть связан с декларативными и адаптивными интерфейсными фреймворками, такими как Vue.js. . Интерфейс JS официального сайта Hongmeng соответствует JSFrontend.Синтаксис очень похож на синтаксис апплета.Он должен быть унаследован от предыдущего быстрого приложения.Каждый компонент соответствует файлу шаблона xx.hml, файлу стиля xx. css и файл стиля файла сценария xx.js и файл конфигурации xx.json.

<div class="container">
  <text class="title-text">{{headTitle}}</text>
</div>

/* xxx.css */
.container {
  flex-direction: column;
  margin-top: 20px;
  margin-left: 30px;
}
.title-text {
  color: #1a1a1a;
  font-size: 50px;
}

// xxx.js
export default {
  data: {
    headTitle: 'Capture the Beauty in This Moment'
  }
}

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

При инициализации среды выполнения JS сначала привязывается ряд нативных интерфейсов, затем выполняется встроенная среда js, а затем динамически загружается и выполняется пользовательский код js. В файле qjs_engine.cpp [8] интерфейса js вы можете увидеть интерфейс, зарегистрированный в среде JS:

Поскольку QuickJS поддерживает модуль ES6, эти интерфейсы прописаны в модуле ace, который можно импортировать с помощью import, а также в окружении есть глобальная среда ace:

import * as ace from 'ace'

// 创建 body 节点
ace.domCreateBody(0, 'div', {/* attrs */}, {/* styles */}, {/* events */})

Код, который на самом деле отправляет инструкции по рендерингу в ACE, находится в TaskCenter.ts[9] из Third_Party_jsframework. Дизайн интерфейса и формат инструкций по рендерингу в основном такие же, как и в TaskCenter.js на alibaba/weex. Упрощенный API DOM также моделируется с помощью JS., Связанный с DSL в стиле мини-программы, в такого рода техническом сообществе уже есть много практик, поэтому я больше не буду его представлять.

Декларативный интерфейс (декларативный пользовательский интерфейс)

По этому поводу не так много общедоступной информации. С точки зрения кода, это не использование HML + CSS для создания пользовательского интерфейса, а объединение пользовательского интерфейса с атомарными функциями макета, такими как Flutter.В Flutter, Widget и декларативный JS-пользовательский интерфейс Hongmeng Используется JSView. В сочетании с кодом в jsproxyClass.js для анализа предоставляется программирование с помощью декоратора/аннотаций в спецификации ECMAScript.Предполагаемый код написан следующим образом:

@Component
class MyDemo {
  Column(
    Text('Hello World!'),
    Text('Some text here')
      .fontsize(36)
      .color(Color.Red)
  ).center()
}

Вот исходный код JSView. Мозаичное отображение показано ниже. В настоящее время существует не так много типов.

Преимущество этого метода в том, что композиция лучше, узлы макета не будут влиять друг на друга, как CSS, а алгоритм макета более эффективен. Тем не менее, метод компоновки HTML + CSS, который любит внешний интерфейс, заброшен, а существующие интерфейсные фреймворки, библиотеки компонентов и библиотеки стилей не могут быть напрямую перенесены, а экологическое построение будет несколько затруднительным.

Карточный интерфейс (пользовательский интерфейс без скриптов)

Немного странно называть его CardFrontend.В основном он может использоваться в карточных сценариях, таких как Hongmeng Desktop Widget. Это не зависит от механизма сценариев, а управляется файлом JSON в определенном формате.

Четкого документа по формату файла JSON нет.Вот тестовый пример.Вы видите,что основная часть разделена на шаблон,стили,действия и данные.Привязку данных фигурных скобок можно прописать в шаблоне {{some.data}} , в нем можно писать простые JS-выражения, и он не совсем статичен. Более того, класс CardFrontend имеет интерфейс UpdateData(), который может обновлять данные шаблона и обладает определенной динамической способностью.

Процесс сборки узла

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

JSView декларативного пользовательского интерфейса напрямую связан со средой JS и диспетчеризируется непосредственно кодом страницы/карточки JSView имеет большое количество производных классов, которые соответствуют описаниям атомарного стиля. Дерево JSView сгенерирует дерево компонентов, а узлы в основном находятся во взаимно однозначном соответствии, например, JSGrid сгенерирует GridLayoutComponent, а JSText сгенерирует TextComponent.

И JSFrontend, и CardFrontent синтезируют инструкции по рендерингу (C++), одна генерируется интерфейсной структурой diff, другая напрямую анализируется из JSON, а затем строит внутреннее упрощенное дерево DOM (C++).Обратите внимание, что это так называемое дерево DOM. не привязан к среде JS, с ним нельзя работать напрямую через JS API. Каждый узел DOM генерирует другой узел Component.

Производный класс RenderComponent от Component может напрямую генерировать RenderNode, который является более короткой ссылкой. Например, ImageComponent наследуется от RenderComponent. Другой производный класс — CompposedComponent, который состоит из другого компонента. Элемент также является аналогичной структурой данных, производной от RenderElement и ComposedElement. Компонент может построить Element и RenderNode, а Element может построить RenderNode.Честно говоря, я не понял разницы между этими двумя деревьями.Могут ли Компонент и Элемент быть объединены в будущем?

RenderNode — это реальный узел компоновки.Другие движки рендеринга называются RenderObject или LayoutObject, которые являются производными от многих подклассов и реализуют различные алгоритмы компоновки.Дизайн типов аналогичен виджету Flutter. RenderNode размещает, а затем рисует, а структура выходных данных представляет собой дерево слоев. Этот слой используется для кроссплатформенности в Hongmeng, который является слоем переноса [7] на официальной диаграмме архитектуры. , разные платформы.

Еще интереснее то, что у Hongmeng's Third_Party есть флаттер, и реализован FlutterSceneBuilder [10].Структура данных слоя портирования в основном такая же, как и у слоя Flutter Engine, и код ohos_layers также добавлен в поток. Другими словами, новая структура ACE Hongmeng может работать на Flutter Engine, а Flutter Framework также может работать на графическом пользовательском интерфейсе Hongmeng.

рендеринг чертежа компоновки

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

Основной код — это два упрощенных абзаца на скриншоте.Каждый кадр vsync будет запускать обратный вызов OnVsyncEvent().Если поверхность была инициализирована, внутренние грязные узлы будут обновляться по очереди.Если она содержит анимацию, она вызовет RequestFrame() для запроса следующего триггера.Вертикальная синхронизация одного кадра. Во-первых, грязные элементы вызывают Rebuil() для перестроения RenderNode и вызывают MarkNeedLayout(), чтобы добавить его в очередь для размещения, затем FlushLayout обновит очередь, вызовет метод OnLayout() узла для расчета макета и затем добавьте себя в очередь для рисования, затем FlushRender() вызывает метод Repaint() узла, в свою очередь, чтобы перерисовать для создания дерева слоев.

Обсудить развитие Hongmeng

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

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

Для новых вещей мы всегда используем старые вещи как аналогию, и то, что мы видим, это только те же части, что и старые вещи, а то, что мы не видим, является реальной ценностью. Если Hongmeng совместим только с Android и не имеет дифференцированных функций, он не будет иметь большого значения для развития и только устранит ощущение «локализации». Также трудно сказать, насколько революционной является технологическая подрывная деятельность Android/iOS по сравнению с предыдущим поколением Nokia Motorola.Инновации возможностей системного уровня требуют, чтобы процесс воспринимался прикладным уровнем.Hongmeng может быть только началом.Чтобы вызвать волну взрывного развития, может потребоваться такой человек, как Джобс, чтобы преобразовать возможности новой системы в новое поколение взаимодействия и новое поколение продуктов. Учитывая тенденции национальной политики и самоисследования технологий, можно ожидать будущего Hongmeng.

* Справочная ссылка

• Официальный сайт OpenHarmony:www.openharmony.cn/
• ACE Lite: git ee.com/open гармония…
• ACE Engine: git ee.com/open гармония…
• Конфигурационный файл:git ee.com/open гармония…
• Схема архитектуры ACE:git ee.com/open гармония…
• DSL в виде апплета:device.harmony OS.com/en/docs/API…
• Новая схема архитектуры ACE:git ee.com/open гармония…
• qjs_engine.cpp: git ee.com/open гармония…
• TaskCenter.ts: git ee.com/open гармония…
• FlutterSceneBuilder: git ee.com/open гармония…

Следуйте за нами, 3 мобильных галантереи и практикуйтесь каждую неделю, чтобы вы могли подумать!