Kotlin Native — Kotlin

Kotlin/Native — это технология компиляции Kotlin-кода в нативные двоичные файлы, которые могут запускаться без
виртуальной машины. Kotlin/Native включает в себя серверную часть на основе LLVM для компилятора
Kotlin и нативную реализацию стандартной библиотеки Kotlin.

Почему Kotlin/Native?

Kotlin/Native в первую очередь предназначен для обеспечения компиляции для платформ, на которых виртуальные машины
нежелательны или невозможны, таких как встроенные устройства или iOS. Он идеально подходит для ситуаций, когда
разработчику необходимо создать самодостаточную программу, которая не требует дополнительной среды выполнения или
виртуальной машины.

Платформы, для которых используется Kotlin/Native

Kotlin/Native поддерживает следующие платформы:

• macOS
• iOS, tvOS, watchOS
• Linux
• Windows (MinGW)
• Android NDK

Полный список поддерживаемых платформ вы можете найти здесь.

Совместимость

Kotlin/Native поддерживает двустороннюю совместимость с родными языками программирования для различных операционных
систем. Компилятор создает:

• исполняемый файл для многих платформ,
• статическую библиотеку или динамическую библиотеку с C-заголовками для проектов на C/C++,
• Apple-фреймворк для проектов на Swift и Objective-C.

Благодаря совместимости, вы можете использования существующие библиотеки непосредственно из Kotlin/Native:

.

• статичные или динамичные библиотеки C,
• фреймворки C, Swift, and Objective-C.

Вы можете легко включить скомпилированный Kotlin-код в существующие проекты, написанные на C, C++, Swift, Objective-C и
других языках. Также легко вы можете использовать существующий нативный код, статические или динамические
библиотеки C, фреймворки Swift/Objective-C, графические движки и
все остальное непосредственно из Kotlin/Native.

Библиотеки Kotlin/Native помогают использовать один Kotlin-кодом на нескольких проектах.
POSIX, gzip, OpenGL, Metal, Foundation и многие другие популярные библиотеки и фреймворки Apple уже импортированы и
включены в пакет компилятора в качестве библиотек Kotlin/Native.

Использование кода на нескольких платформах

Мультиплатформенные проекты позволяют обмениваться общим Kotlin-кодом между несколькими платформами,
включая Android, iOS, JVM, JavaScript и native. Мультиплатформенные библиотеки предоставляют необходимые API для общего
кода Kotlin и помогают разрабатывать общие части проекта в Kotlin в одном месте и делиться ими с некоторыми или всеми
платформами.

Вы можете использовать Kotlin Multiplatform Mobile для создания
мультиплатформенных мобильных приложений с одним кодом для Android и iOS.

С чего начать

Руководства и документация

Недавно начали изучать Kotlin? Загляните в раздел Начало работы с Kotlin.

Рекомендуемая документация:

• Документация Kotlin Multiplatform Mobile
• Документация по мультиплатформенности
• C interop
• Swift/Objective-C interop

Рекомендуемые руководства:

• Начало работы с Kotlin/Native
• Создание первого кроссплатформенного мобильного приложения
• Сравнение типов C и Kotlin/Native
• Kotlin/Native как динамическая библиотека
• Kotlin/Native как Apple фреймворк

Примеры проектов

• Примеры Kotlin Multiplatform Mobile
• Kotlin/Native исходный код и примеры
• Приложение KotlinConf
• Приложение KotlinConf Spinner
• Kotlin/Native исходный код и примеры (. tgz)
• Kotlin/Native исходный код и примеры (.zip)

Создание приложения Android Native Activity

Twitter




LinkedIn




Facebook




Адрес электронной почты

• 
  Статья
• 
  09/26/2022
• Чтение занимает 3 мин
• 
  

После установки кроссплатформенной рабочей нагрузки Разработка мобильных приложений на языке C++ Visual Studio можно использовать для создания полнофункциональных приложений Android Native Activity. Пакет Android Native Development Kit (NDK) — это набор средств, с помощью которых можно реализовывать большинство возможностей приложения Android, используя чистый код C или C++. Для обеспечения взаимодействия кода C или C++ с Android используется определенный код Java JNI, выступающий в роли связующего. В Android NDK появилась возможность создавать приложения Native Activity с помощью API Android уровня 9. Код Native Activity популярен для создания игровых приложений и приложений с интенсивным использованием графики на основе Unreal Engine или OpenGL. В этом пошаговом руководстве показано создание простого приложения Native Activity, в котором используется OpenGL. В дополнительных разделах последовательно рассматриваются такие этапы жизненного цикла разработки, как редактирование, сборка, отладка и развертывание кода Native Activity.

Требования

Прежде чем создавать приложение Android Native Activity, необходимо убедиться, что вы выполнили все системные требования и установили рабочую нагрузку Разработка мобильных приложений на языке C++ в Visual Studio. Дополнительные сведения см. в статье Установка Visual C++ для разработки кроссплатформенных мобильных приложений на языке C++. Убедитесь, что необходимые сторонние инструменты и пакеты SDK включены в установку, а также что установлен эмулятор Android.

Создание проекта Native Activity

В этом руководстве вы сначала создадите новый проект Android Native Activity, а затем создадите и запустите приложение по умолчанию в эмуляторе Android.

1. В Visual Studio выберите Файл>Создать>Проект.

2. В диалоговом окне Новый проект в меню Шаблоны последовательно выберите Visual C++>Кроссплатформенное приложение, а затем выберите шаблон Приложение Native-Activity (Android).

3. Присвойте приложению имя, например MyAndroidApp, а затем нажмите OK.

   Visual Studio создаст новое решение и откроет обозреватель решений.

1. В Visual Studio выберите Файл>Создать>Проект.

2. В диалоговом окне Создание нового проекта выберите шаблон Приложение Native-Activity (Android), а затем нажмите Далее.

3. В диалоговом окне Настроить новый проект введите имя, например MyAndroidApp в разделе Имя проекта, а затем выберите Создать.

   Visual Studio создаст новое решение и откроет обозреватель решений.

В новое решение приложения Android Native Activity входят два проекта.

• MyAndroidApp.NativeActivity содержит ссылки и связующий код для запуска приложения как приложения Native Activity на Android. Реализация точек входа из кода клея выполняется в файле main.cpp. Предварительно скомпилированные заголовки находятся в файле pch.h. Этот проект приложения Native Activity компилируется в общую библиотеку , поэтому файл, который выбирается проектом упаковки.

• MyAndroidApp.Packaging создает файл с расширением .apk для развертывания на устройстве или в эмуляторе Android. Он содержит ресурсы и файлAndroidManifest.xml , в котором задаются свойства манифеста. Он также содержит файлbuild.xml , который управляет процессом сборки Ant. По умолчанию он задан как начальный проект, который можно развернуть и запустить непосредственно из Visual Studio.

Создание и запуск приложения Android Native Activity по умолчанию

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

Сборка и запуск приложения Native Activity по умолчанию

1. Если он еще не выбран, выберите x86 в раскрывающемся списке «Платформы решений «.

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

2. В строке меню последовательно выберите Сборка>Собрать решение.

   В окне «Выходные данные» отобразятся выходные данные процесса сборки для двух проектов в решении.

3. Выберите один из профилей эмулятора Android в качестве цели развертывания.

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

4. Нажмите клавишу F5, чтобы начать отладку, или ShiftF5+, чтобы запустить без отладки.

   Вот как выглядит приложение по умолчанию в эмуляторе Android.

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

5. Нажмите клавишиSHIFTF5+, чтобы остановить отладку.

   Эмулятор является отдельным процессом, который продолжает выполняться. Вы можете изменять, компилировать и развертывать код несколько раз в одном эмуляторе.

Введение

Перейти к
Содержание

Введение

Глава   1

В этой главе представлен Java Native Interface (JNI). JNI является родным
интерфейс программирования. Это позволяет коду Java, который выполняется внутри Java
Виртуальная машина (ВМ) для взаимодействия с приложениями и
библиотеки, написанные на других языках программирования, таких как C, C++,
и сборка.

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

В этой главе рассматриваются следующие темы:

• Собственный интерфейс Java
  Обзор

• Фон

• Цели

• Собственный интерфейс Java
  Подход

• Программирование для JNI

• Изменения

Обзор собственного интерфейса Java

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

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

• Стандартная библиотека классов Java не поддерживает
  функции, зависящие от платформы, необходимые приложению.

• У вас уже есть библиотека, написанная на другом языке, и
  хотите сделать его доступным для кода Java через JNI.

• Вы хотите реализовать небольшую часть критичного ко времени кода в
  язык более низкого уровня, такой как ассемблер.

При программировании через JNI можно использовать собственный
методы для:

• Создание, проверка и обновление объектов Java (включая массивы и
  струны).

• Вызов методов Java.

• Перехватывать и выдавать исключения.

• Загрузка классов и получение информации о классе.

• Выполнение проверки типа во время выполнения.

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

Историческая справка

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

Мы кратко рассмотрим некоторые нативные методы
интерфейсы, такие как:

• Интерфейс собственного метода JDK 1.0

• Интерфейс Netscape Java Runtime

• Необработанный родной интерфейс Microsoft и Java/COM
  интерфейс

JDK 1.0 Native Method Interface

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

Во-первых, собственный код обращался к полям в Java
объекты как члены структур C. Однако Спецификация языка Java не определяет, как
объекты размещаются в памяти. Если виртуальная машина Java размещает объекты
иначе в памяти, то программисту пришлось бы перекомпилировать
собственные библиотеки методов.

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

Java Runtime Interface

Netscape предложила Java Runtime Interface
(JRI), общий интерфейс для служб, предоставляемых в Java
виртуальная машина. JRI был разработан с учетом переносимости.
делает несколько предположений о деталях реализации в
базовая виртуальная машина Java. JRI рассмотрел широкий круг вопросов,
включая нативные методы, отладку, отражение, встраивание
(вызов) и так далее.

Необработанный собственный интерфейс и Java/COM
Интерфейс

Виртуальная машина Microsoft Java поддерживает два собственных метода
интерфейсы. На низком уровне он обеспечивает эффективный Raw Native.
Интерфейс (РНИ). RNI предлагает высокую степень
обратная совместимость с собственным методом JDK
интерфейс, хотя у него есть одно существенное отличие. Вместо того, чтобы полагаться
при консервативной сборке мусора нативный код должен использовать RNI
функции для явного взаимодействия со сборщиком мусора.

На более высоком уровне Microsoft Java/COM
интерфейс предлагает независимый от языка стандартный двоичный интерфейс
к виртуальной машине Java. Код Java может использовать COM-объект, как если бы это был Java
объект. Класс Java также может быть открыт для остальной части системы.
как COM-класс.

Цели

Мы считаем, что форменная, продуманная
Стандартный интерфейс предлагает следующие преимущества для всех:

• Каждый поставщик виртуальных машин может поддерживать больший объем собственного кода.

• Изготовителям инструментов не придется поддерживать различные виды
  собственные интерфейсы методов.

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

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

• Двоичная совместимость — основной целью является двоичная совместимость
  собственных библиотек методов во всех реализациях Java VM на
  данная платформа. Программисты должны поддерживать только одну версию
  собственные библиотеки методов для данной платформы.

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

• Функциональность — интерфейс должен предоставлять достаточное количество виртуальных машин Java.
  internals, чтобы позволить собственным методам выполнять полезные задачи.

Подход к собственному интерфейсу Java

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

JRI Netscape ближе всего к тому, что мы
представить как переносимый нативный интерфейс метода и использовался как
отправная точка нашего дизайна. Читатели, знакомые с JRI,
обратите внимание на сходство в соглашении об именах API, использовании
идентификаторы методов и полей, использование локальных и глобальных ссылок и
скоро. Однако, несмотря на все наши усилия, JNI не
совместима с JRI в двоичном виде, хотя виртуальная машина может поддерживать как
JRI и JNI.

RNI от Microsoft был лучше, чем JDK
1.0, потому что он решил проблему нативных методов, работающих с
неконсервативный сборщик мусора. РНИ, однако, не было.
подходит в качестве независимого от виртуальной машины собственного интерфейса метода. Как и JDK,
Собственные методы RNI обращаются к объектам Java как к структурам C, что приводит к
две проблемы:

• RNI открыл макет внутренних объектов Java для нативных
  код.

• Прямой доступ к объектам Java, поскольку структуры C делают это
  невозможно эффективно включить «барьеры записи»,
  которые необходимы в продвинутых алгоритмах сборки мусора.

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

Использование COM в качестве стандартного собственного метода Java
интерфейсу, однако, мешает несколько факторов:

• Во-первых, в интерфейсе Java/COM отсутствуют некоторые желаемые функции,
  таких как доступ к приватным полям и поднятие общих
  исключения.

• Во-вторых, интерфейс Java/COM автоматически предоставляет
  стандартные COM-интерфейсы IUnknown и IDispatch для объектов Java, поэтому
  этот собственный код может получить доступ к общедоступным методам и полям.
  К сожалению, интерфейс IDispatch не работает с
  перегруженные методы Java и нечувствительны к регистру в методе сопоставления
  имена. Кроме того, все методы Java, предоставляемые через IDispatch
  интерфейс обернут для выполнения динамической проверки типов и
  принуждение. Это связано с тем, что интерфейс IDispatch разработан с
  слабо типизированные языки (такие как Basic).

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

• В-четвертых, немедленному внедрению COM препятствует отсутствие
  его поддержки на платформах UNIX.

Хотя объекты Java не доступны для
собственный код как COM-объекты, сам интерфейс JNI
двоично-совместимый с COM. JNI использует ту же структуру таблицы переходов.
и соглашение о вызовах, которое делает COM. Это
означает, что, как только будет доступна межплатформенная поддержка COM,
JNI может стать COM-интерфейсом для Java VM.

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

Программирование для JNI

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

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

Изменения

Начиная с Java SE 6.0, устаревшие структуры
Вместо этого были удалены JDK1_1InitArgs и JDK1_1AttachArgs.
Должны использоваться JavaVMnitArgs и JavaVMATtachArgs.

Каково реальное применение Java Native Interface?

спросил
4 года, 5 месяцев назад

Изменено
1 год, 4 месяца назад

Просмотрено
886 раз

Я успешно выполнил простую программу, используя JNI, и я знаю, что такое JNI. Но мне интересно, где он используется в реальном времени и зачем нам нужен JNI, когда мы можем делать что угодно в java.

• Java
• собственный интерфейс Java

5

… в то время как мы можем делать что угодно в java

Это недостаток вашего мышления. Есть некоторые вещи, которые вы не можете сделать в Java. Есть и другие вещи, которые вы не можете сделать эффективно в Java.

Примеры включают:

• взаимодействие с функциями ОС способами, которые не поддерживаются API Java,
• библиотеки вызовов, реализованные на других языках программирования, и
• взаимодействует с устройствами с отображением памяти.

4

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

См. пример QuantLib, https://www.quantlib.org. Они портируют всю библиотеку на Java с помощью SWIG, который, в свою очередь, использует JNI.

Я добавлю сюда один вариант использования из реальной жизни. Наше программное приложение подключается к различным поставщикам для получения данных от них. Для этого мы используем предоставленный поставщиком API. У 2 наших поставщиков есть только API C/C++, и, поскольку наше приложение написано на Java, мы используем JNI для связи с этими API.

Хотя JNI довольно хрупок в использовании, но если бы его не существовало, это означало бы, что нам пришлось бы переписывать части нашего приложения на C++, что было бы десятками тысяч строк кода + стоимость поддержки поддержки баз кода в 2 разных языки.

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

Хотя в последнее время я не использовал JNI, но около 6 или 7 лет назад я работал над Java-приложением, в котором мы реализовывали криптографию.

This entry was posted in Популярное