AN
Сейчас как код в либе нативный но он собирается со стороны приложения и там же линкуется. Сорцы добавлены в cmake
Size: a a a
2019 March 15
DD
Тогда лучше сделать джавовую обвязку и сделать модуль, можно aar либу собрать.
VL
можно воспользоваться registerNatives функцией, и завязаться с 1 общий java класс
AN
спасибо за советы, буду пробовать
2019 March 16
VB
Привет!
Есть ли макрос, который возвращает имя файла без расширения и кавычек? __FILE__ не подходит для этого :(
Есть ли макрос, который возвращает имя файла без расширения и кавычек? __FILE__ не подходит для этого :(
VB
Может быть что-нибудь специфичное для Cmake?
VB
Мне его надо конкатенировать с именем функции
VB
Так что нужен именно что константный макрос, а не функция
2019 March 18
EB
А кто-нибудь тут бандлы собирает?
EB
У нас после перехода на app bundle нативные крэши начали ловиться очень странно.
EB
backtrace:
#00 pc 00000000003cbfa8 /data/app/app.bundle-mFWnxHfY0rt1Mwg5TrYl1w==/split_config.arm64_v8a.apk
#00 pc 00000000003cbfa8 /data/app/app.bundle-mFWnxHfY0rt1Mwg5TrYl1w==/split_config.arm64_v8a.apk
EB
и все дела. никакого трейса.
2019 March 19
VL
backtrace:
#00 pc 00000000003cbfa8 /data/app/app.bundle-mFWnxHfY0rt1Mwg5TrYl1w==/split_config.arm64_v8a.apk
#00 pc 00000000003cbfa8 /data/app/app.bundle-mFWnxHfY0rt1Mwg5TrYl1w==/split_config.arm64_v8a.apk
Такие крэши бывают и без бандлов. По крайней мере у меня так было, и чтобы увидеть полный стек(нормальный), нужно просто пару раз его отловить(там есть какой-то шанс, что крешхендлер ничего не понял и вывел всего 1 строку). А можно ещё в tombstone заглянуть
2019 March 20
EB
Такие крэши бывают и без бандлов. По крайней мере у меня так было, и чтобы увидеть полный стек(нормальный), нужно просто пару раз его отловить(там есть какой-то шанс, что крешхендлер ничего не понял и вывел всего 1 строку). А можно ещё в tombstone заглянуть
Так у меня все нативные крэши такие были. Сейчас пересобрал обычный universal билд. Он толще, но все нативные крэши с нормальным стеком приходят.
2019 March 24
ИС
Нужен совет. Если я пишу фото-редактор, что влечет операции с большим количеством памяти и времени. Вопрос. Такие вещи вообще делаются в SDK? Java такое тянет?
Или NDK это единственный путь. Спасибо.
Или NDK это единственный путь. Спасибо.
VL
Что не так с памятью? Ну пусть 10мб фотка весит. Ну пусть ты 2 раза ее выделишь. 20мб - не страшно) По поводу времени: не обрабатывай в Мейн потоке, и все будет норм. Особо причин использовать именно НДК не вижу.
VL
Разве что у тебя есть уже готовая сишная либа для обработки
ИС
Да вроде и так не обрабатываю в ui. То есть выигрыш по времени от NDK это миф?
VL
Смотря какие объемы
ИС
Ну у меня операции занимают около 3-5 секунд. А нужно в реальном времени. Т.е. меньше 500ms хотя бы. Вроде и оптимизирую и все такое а все равно долго. Есть смысл соваться в NDK или нужно искать проблемы в себе и выжимать из Java. Просто на github есть коды похожего проекта и там работа с графикой в C++ сделана. Из чего я сделал вывод что это панацея) Я прав?