Комментарии 28
Отличная статья, спасибо!
Спасибо за статью. А продолжение будет? А то уже начитался вводными статьями для «новичков». Хотелось бы чего-нибудь интересного.
Как настроить make файл для линковки с файлами из других проектов, про работу с потоками в jni, про работу с какими-то OpenSource либами, оптимизированными под Android и их сравнение, и т.д.
Как настроить make файл для линковки с файлами из других проектов, про работу с потоками в jni, про работу с какими-то OpenSource либами, оптимизированными под Android и их сравнение, и т.д.
Последнее с чем я работал из нативного, так это ffmpeg. Возможно напишу статью как собрать и использовать эту библиотеку.
Насчёт потоков, то самому интересно и думаю в ближайшее время будет статья.
Насчёт потоков, то самому интересно и думаю в ближайшее время будет статья.
НЛО прилетело и опубликовало эту надпись здесь
Вроде как зависит от того, под какую версию API билдите.
В папочке android-ndk-r8d\platforms находятся директории для различных версий API, туда и кидать.
К примеру, для 14 под arm:
либу сюда android-ndk-r8d\platforms\android-14\arch-arm\usr\lib
заголовки сюда android-ndk-r8d\platforms\android-14\arch-arm\usr\include
Для x86 тоже есть папочка.
В папочке android-ndk-r8d\platforms находятся директории для различных версий API, туда и кидать.
К примеру, для 14 под arm:
либу сюда android-ndk-r8d\platforms\android-14\arch-arm\usr\lib
заголовки сюда android-ndk-r8d\platforms\android-14\arch-arm\usr\include
Для x86 тоже есть папочка.
НЛО прилетело и опубликовало эту надпись здесь
Там выше ответ был про другое. «Официально» как вы говорите дать доступ к своей сошке другим приложениям не получится. Кто хочет использовать должен включать себе в приложение — так что поставляйте исходники, так проще всего.
Ну вернее, варианты есть — идете к вендерам, и договариваетесь, что у определенного вендора в поставке идет и ваша либа.
Ну вернее, варианты есть — идете к вендерам, и договариваетесь, что у определенного вендора в поставке идет и ваша либа.
И сразу совет, сразу настраиваете проект на компиляцию через clang — NDK_TOOLCHAIN_VERSION=clang3.3, а то потом если захотите под iOS разрабатывать, можно радостно ловить что какие-то фишки gcc не поддерживаются в clang-е и наоборот (хотя различия между официальным и apple clang-ом тоже есть)
А он не сильно плохой код для андроида делает?
Это смотря, что подразумевается под «плохим» и что под «кодом» :)
И что значит «для андроида» — больно они разные по платформам.
На мой взгляд, clang 3.3 для ряда платформ на сложном c++11-том коде, генерит более быстрый код GCC 4.8.x — но это на глазок, замеров я не делал.
И что значит «для андроида» — больно они разные по платформам.
На мой взгляд, clang 3.3 для ряда платформ на сложном c++11-том коде, генерит более быстрый код GCC 4.8.x — но это на глазок, замеров я не делал.
только не на продакшене, clang тормоз по сравнению с gcc и особенно на ARM. А в gcc 4.9 куча многих вкусных плюшек.
Учитывая, что в osx последней gcc вообще алиас к clang-ку, то как раз для продакшен распространения своей либы в исходниках, лучше чтобы она компилялась в clang-е. Иначе многие будут иметь проблемы со сброкой. Не говоря уже о компиляции под iOS.
Ну и говорю — у меня другие наблюдения, если сравнивать с gcc 4.8. И не только у меня, на стек оверфлоу тоже встречал замеры, где clang на процентов 15-20 лучше.
Ну и говорю — у меня другие наблюдения, если сравнивать с gcc 4.8. И не только у меня, на стек оверфлоу тоже встречал замеры, где clang на процентов 15-20 лучше.
www.phoronix.com/scan.php?page=article&item=llvm_clang33_3way&num=1
Правда llvm и gcc уже подросли с тех пор…
А так недавно собирал трудный проект при помощи clang особых трудностей не было… были скорее DARWIN/BSD специфичные. Ну и честно говоря не вижу смысла менять шило на мыло если этого захотела Apple.
Правда llvm и gcc уже подросли с тех пор…
А так недавно собирал трудный проект при помощи clang особых трудностей не было… были скорее DARWIN/BSD специфичные. Ну и честно говоря не вижу смысла менять шило на мыло если этого захотела Apple.
интересно а много таких контор кто в своих коммерческих приложениях весь функционал на плюсах пишет а потом просто добавляет гуй и собирает под андройд/айфон/винфон и т.д.? Такой подход оправдывает затраты или далеко не всегда?
Ну примерно половина всех денег в гугл плее делается приложениями с таким подходам. И это игры :) И гуи нативного там крайне мало. А так подход сложный — ибо современный гуи это как правило многопоточная фигня, и сама core logic тоже как правило многопоточная — скрешивать их универсально еще тот секс в гамаке.
вот точно, имел ввиду все что не игры (их то понятно на open gl разных делают).
Т.е. обычные приложение так не получится клепать, несмотря на то что потока там всего 2: гуй и асинхронная задача (редко когда их больше одной в приложении)?
Т.е. обычные приложение так не получится клепать, несмотря на то что потока там всего 2: гуй и асинхронная задача (редко когда их больше одной в приложении)?
Можно, вопрос оправданно ли. Тут засада в том, что либо вам нужен программист универсал — который будет и c++, java и objc знать и все хорошо — что большая редкость и очень большая стоимость, либо разделять команду кто-то core team, кто-то за гуи на iOS, кто-то за гуи на android. На самом деле если исключить игры ( а там бывает и по 10+ программеров на проект) — то я не видил столь крупных команд разработчиков мобильных приложений, чтобы такое разделение было оправданно. И даже там где такое оправданно — там разделение скорее серверных/клиентских программистов — т.е. приложения сервисы.
Более, менее близко к тому что вы описывается в разработках различных навигационных программ — tom tom и прочее. Но у них это сложилось еще до ios/android ибо они еще и до этого на куче платформ старались запускаться.
Более, менее близко к тому что вы описывается в разработках различных навигационных программ — tom tom и прочее. Но у них это сложилось еще до ios/android ибо они еще и до этого на куче платформ старались запускаться.
Отвечу за все выше написанные вопросы «зачем». На NDK зачастую пишут продуктовые компании.
Например, dating (то с чем я работал) проекты делают ядро(api) на С/С++ и потом используют на разных платформах. Таким способом остаётся на платформах лишь работа с UI. Такой подход же сейчас пытаются сделать внедряя в проекты Xamarin, но эта штука ещё далека от идеала.
Так, же взять ту же продуктовую компанию Samsung (приходилось сталкиваться с ней). Они пишут много нативного кода, очень много и большинство разработчиков именно необходимые такие скилы как знания Linux kernel. Ребята которые уходят с Samsung'a и приходят в обычную компанию SDK порой даже не видели и не могут написать обычный селектор.
Вот такие мои наблюдения. Так что писать ли на NDK, зависит от случая, задач, проекта. Нужно в первую очередь делать оценку по времени и смотреть будет ли оправдан выбор писать на плюсах или нет.
Например, dating (то с чем я работал) проекты делают ядро(api) на С/С++ и потом используют на разных платформах. Таким способом остаётся на платформах лишь работа с UI. Такой подход же сейчас пытаются сделать внедряя в проекты Xamarin, но эта штука ещё далека от идеала.
Так, же взять ту же продуктовую компанию Samsung (приходилось сталкиваться с ней). Они пишут много нативного кода, очень много и большинство разработчиков именно необходимые такие скилы как знания Linux kernel. Ребята которые уходят с Samsung'a и приходят в обычную компанию SDK порой даже не видели и не могут написать обычный селектор.
Вот такие мои наблюдения. Так что писать ли на NDK, зависит от случая, задач, проекта. Нужно в первую очередь делать оценку по времени и смотреть будет ли оправдан выбор писать на плюсах или нет.
Большое спасибо за статью, всё очень хорошо и правильно расписано.
Два вопроса:
1) есть ли какая-нибудь разница при использовании вместо Dalvik ADT? Подводные камни или грабли? Не пробовали?
2) clang в NDK всё-таки сыроват, насколько он вообще сейчас используется для сборки native-библиотек?
Два вопроса:
1) есть ли какая-нибудь разница при использовании вместо Dalvik ADT? Подводные камни или грабли? Не пробовали?
2) clang в NDK всё-таки сыроват, насколько он вообще сейчас используется для сборки native-библиотек?
Для облегчения жизни с Android NDK под Windows можно попробовать использовать плагин для vc2010-2012 — nvidia nsight.
Для облегчения жизни с Android NDK можно попробовать это www.crystax.net/android/ndk
Еще раз спасибо crystax за его доработанный NDK, в свое время он нам очень облегчил жизнь, но сейчас смысла нету, практически все эти плюшки есть в стандартном NDK начиная с 9-той ревизии.
в intellij idea поддержка всего этого пока отстает?
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Введение в Android NDK