Решение проблем разработки OpenHarmony: идеи и решения

Решение проблем разработки OpenHarmony: идеи и решения

9 февраля 2024 г.

:::информация Авторы:

(1) LI LI, Beihang University, China;

(2) СЯН ГАО, Бэйханский университет, Китай;

(3) ХАЙЛОНГ САН, Бэйханский университет, Китай;

(4) CHUNMING HU, Beihang University, China;

(5) СЯОЮ САН, Австралийский национальный университет, Австралия;

(6) ХАОЮ ВАН, Хуачжунский университет науки и технологий, Китай;

(7) ХАЙПЕНГ CAI, Университет штата Вашингтон, Пуллман, США;

(8) ТИН СУ, Восточно-Китайский педагогический университет, Китай;

(9) СЯПУ ЛУО, Гонконгский политехнический университет, Китай;

(10) ТЕГАВЕНДЕ Ф. БИССИАНДЕ, Университет Люксембурга, Люксембург;

(11) ЖАК КЛЕЙН, Люксембургский университет, Люксембург;

(12) ДЖОН ГРАНДИ, Университет Монаша, Австралия;

(13) ТАО СИЕ, Пекинский университет, Китай;

(14) HAIBO CHEN, Shanghai Jiao Tong University, China;

(15) ХУАЙМИН ВАН, Национальный университет оборонных технологий, Китай.

:::

Таблица ссылок

Введение

Предыстория OpenHarmony

Состояние экосистемы OpenHarmony

Обзор разработки мобильного программного обеспечения

Дорожная карта исследований

Обсуждение

Связанные работы

Выводы и amp; Ссылки

6 ОБСУЖДЕНИЕ

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

6.1. Проблемы разработки приложений и библиотек.

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

Недостаток данных для обучения (на основе искусственного интеллекта). Было продемонстрировано, что появление больших языковых моделей перспективно для автоматизированной генерации кода, автоматизированной генерации тестовых примеров, рекомендаций по библиотечному API и т. д. Однако это не так. однако для OpenHarmony этого можно добиться напрямую, поскольку обычно нет данных для обучения (или точной настройки). Даже при наличии набора данных программного обеспечения, связанных с OpenHarmony (например, кода ArkTS и комментариев к нему), также существует потребность в дальнейшей очистке высококачественных данных для достижения высокоточной модели большого языка, поскольку производительность больших языковых моделей известна. тесно коррелировать с качеством набора обучающих данных.

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

6.2 Проблемы анализа приложений/библиотек

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

Проблемы, связанные с системой. Система Android поставила перед сообществом разработчиков программного обеспечения различные проблемы, связанные с разработкой автоматизированных подходов к анализу приложений Android. Во-первых, Android использует компоненты для создания приложений, для которых сами компоненты разрабатываются независимо. Компоненты не будут напрямую связаны на стороне кода, и фактический вызов (через так называемый механизм межкомпонентной связи (ICC)) будет выполняться через систему. Этот механизм ICC также можно использовать для реализации связи между приложениями, что усложняет выполнение анализа между приложениями. Во-вторых, компоненты Android предназначены для запуска с помощью набора предопределенных методов (известных как методы жизненного цикла), которые будут запускаться системой в определенном порядке. Эти методы жизненного цикла также не связаны на сайте кода, что также усложняет статический анализ приложения (с точки зрения анализатора, между двумя методами жизненного цикла нет никакой связи, несмотря на то, что они могут постоянно вызываться системой). В-третьих, как и в случае с методами жизненного цикла, существуют методы обратного вызова, которые также не связаны напрямую с кодом приложения. Эти методы обратного вызова напрямую вызываются системой при возникновении определенных событий (либо системных событий, таких как получение SMS, либо событий пользовательского интерфейса, таких как нажатие кнопки). OpenHarmony обычно сталкивается с теми же проблемами, что и Android.

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

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

:::информация Этот документ доступен на arxiv по лицензии CC 4.0.

:::


Оригинал
PREVIOUS ARTICLE
NEXT ARTICLE