Nano Hash - криптовалюты, майнинг, программирование

Android NDK: статическая или общая среда выполнения C ++ для сторонней библиотеки Java

Я компилирую стороннюю библиотеку Java для Android, которая использует JNI. Я прочитал соответствующие страницы о добавлении поддержки C ++ на developer.android, но меня все еще смущает пара проблем, касающихся среды выполнения C ++ STL, которые, как я надеялся, я могу прояснить здесь:

1- Моя библиотека не контролирует приложение, в которое она будет встроена, поэтому я не знаю, будут ли другие библиотеки, которые могут использовать статические / общие STL. Если я использую статическую среду выполнения C ++ с ANDROID_STL = c ++ _ static, это безопасно или мне нужно беспокоиться о другой библиотеке, которая может использовать что-то вроде gnustl_static, что может конфликтовать с моей?

2- Если я использую общую среду выполнения C ++ с ANDROID_STL = c ++ _ shared, является ли это гарантией того, что конкретный элемент в STL будет использовать среду выполнения libc ++, или можно ли использовать gnustl, если он не существует? Например, если бы я использовал std :: string с общей средой выполнения c ++ (c ++ _ shared) в приложении, которое имеет другую библиотеку gnustl_static, будет ли моя реализация std :: string взята из libc ++ или gnustl?

В идеале я хотел бы иметь очень урезанную версию статической среды выполнения C ++ с (c ++ _ static), которая включает только std :: vector, std :: string и std :: map. На самом деле я планировал использовать что-то вроде -ffunction-section, как описано здесь и # 768.

Пожалуйста, посоветуйте и спасибо.

Детали окружающей среды

  • Pkg.Desc = Android NDK
  • Pkg.Revision = r15c
  • Android Studio = 3.1.2
  • система: cmake Хост ОС: Arch Linux ($ uname -r% 4.18.5-arch1-1-ARCH)
  • Компилятор: Clang ++
  • STL: c ++ _ static / c ++ _ общий
c++ android android-ndk cmake stl
18.09.2018

Ответы:


1

Ваша озабоченность вполне реальна. Но при правильном обращении можно найти надежный выход.

Предупреждения об использовании единой среды выполнения C ++ для всех библиотек в приложении (и вся идея определить поддержку C ++ в NDK как APP_STL по сравнению с большинством других флагов, таких как LOCAL_CFLAGS или LOCAL_SHARED_LIBRARIES, актуальны для подключенных нативных библиотек. Библиотеки JNI, которые никогда не обмениваться данными напрямую (кроме как через соответствующие уровни Java), могут использовать разные среды выполнения C ++. Другой момент заключается в том, что при обычной сборке в APK будет помещена только одна общая библиотека времени выполнения C ++. Обратите внимание, что управление версиями также представляет собой потенциальную опасность: если разработчик добавит ваш библиотека использует другой выпуск NDK, могут возникнуть коллизии или неожиданные побочные эффекты, когда его версия среды выполнения STL работает с вашим кодом.

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

Суть в том, что вам не о чем беспокоиться, если вы создаете свою общую библиотеку с libc++_static.

18.09.2018
  • Благодарю за ответ, мистер Кон. Я согласен с вами по поводу общения, которое, к счастью для меня, не произойдет. Для большей ясности я свяжу дополнительный ответ, который я получил от одного из разработчиков NDK: github.com/android-ndk/ndk/issues/796#issuecomment-422560209 Короче говоря, его мнение заключалось в том, чтобы использовать c++_shared после r16, поскольку gnu_stl (как статический, так и общий) устарел. Могут возникнуть проблемы с искаженными именами, если у пользователя более одного STL. Итак, если библиотека не взаимодействует с другими библиотеками, безопаснее использовать c++_static, как вы упомянули. 19.09.2018
  • Эта проблема очень сбивала меня с толку, поэтому я обязательно постараюсь сделать небольшую рецензию и связать ее здесь, и я обязательно упомяну ваше имя. Еще раз спасибо, мистер Кон. 19.09.2018
    • Новые материалы
    Кластеризация: более глубокий взгляд
    Кластеризация — это метод обучения без учителя, в котором мы пытаемся найти группы в наборе данных на основе некоторых известных или неизвестных свойств, которые могут существовать. Независимо от..
    Как написать эффективное резюме
    Предложения по дизайну и макету, чтобы представить себя профессионально Вам не позвонили на собеседование после того, как вы несколько раз подали заявку на работу своей мечты? У вас может..
    Частный метод Python: улучшение инкапсуляции и безопасности
    Введение Python — универсальный и мощный язык программирования, известный своей простотой и удобством использования. Одной из ключевых особенностей, отличающих Python от других языков, является..
    Как я автоматизирую тестирование с помощью Jest
    Шутка для победы, когда дело касается автоматизации тестирования Одной очень важной частью разработки программного обеспечения является автоматизация тестирования, поскольку она создает..
    Работа с векторными символическими архитектурами, часть 4 (искусственный интеллект)
    Hyperseed: неконтролируемое обучение с векторными символическими архитектурами (arXiv) Автор: Евгений Осипов , Сачин Кахавала , Диланта Хапутантри , Тимал Кемпития , Дасвин Де Сильва ,..
    Понимание расстояния Вассерштейна: мощная метрика в машинном обучении
    В обширной области машинного обучения часто возникает необходимость сравнивать и измерять различия между распределениями вероятностей. Традиционные метрики расстояния, такие как евклидово..
    Обеспечение масштабируемости LLM: облачный анализ с помощью AWS Fargate и Copilot
    В динамичной области искусственного интеллекта все большее распространение получают модели больших языков (LLM). Они жизненно важны для различных приложений, таких как интеллектуальные..