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

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

0 голосов
/ 18 сентября 2018

Я собираю стороннюю библиотеку 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.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 ++ _ shared

1 Ответ

0 голосов
/ 18 сентября 2018

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

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

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

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

...