Pull to refresh

Comments 28

согласен, очень хорошо все изложено, спасибо!
Спасибо за статью. А продолжение будет? А то уже начитался вводными статьями для «новичков». Хотелось бы чего-нибудь интересного.
Как настроить make файл для линковки с файлами из других проектов, про работу с потоками в jni, про работу с какими-то OpenSource либами, оптимизированными под Android и их сравнение, и т.д.

Последнее с чем я работал из нативного, так это ffmpeg. Возможно напишу статью как собрать и использовать эту библиотеку.
Насчёт потоков, то самому интересно и думаю в ближайшее время будет статья.
Очень интересно. Я вот хочу собрать библиотеку клиентского (.so) доступа к PostgreSQL, но не знаю как подступиться. Везде все просто:
./configure && make

А вот как это будет выглядеть для Андроида, даже не могу представить. Кстати, а куда нужно положить .so, чтобы он был доступен всем приложениям на системе Андроида?

Вроде как зависит от того, под какую версию 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 тоже есть папочка.
А как такое можно провернуть официально? Вот допустим через Google Play. Типа, как под виндой набор кодеков идёт в инсталляторе.
Там выше ответ был про другое. «Официально» как вы говорите дать доступ к своей сошке другим приложениям не получится. Кто хочет использовать должен включать себе в приложение — так что поставляйте исходники, так проще всего.

Ну вернее, варианты есть — идете к вендерам, и договариваетесь, что у определенного вендора в поставке идет и ваша либа.
И сразу совет, сразу настраиваете проект на компиляцию через clang — NDK_TOOLCHAIN_VERSION=clang3.3, а то потом если захотите под iOS разрабатывать, можно радостно ловить что какие-то фишки gcc не поддерживаются в clang-е и наоборот (хотя различия между официальным и apple clang-ом тоже есть)
А он не сильно плохой код для андроида делает?
Это смотря, что подразумевается под «плохим» и что под «кодом» :)
И что значит «для андроида» — больно они разные по платформам.

На мой взгляд, clang 3.3 для ряда платформ на сложном c++11-том коде, генерит более быстрый код GCC 4.8.x — но это на глазок, замеров я не делал.
Код значит бинарный а плохой значит медленный. На x86 пока в целом clang медленнее.
У меня другие наблюдения. Я сравнивал на x64 их на числодробилке — там премущество до 15% в пользу clang-а было, кода мало 2к LOC. И мог сравнивать под arm7 на примере игры (300к LOC) — там примерно 5% преимущество clang-а
только не на продакшене, clang тормоз по сравнению с gcc и особенно на ARM. А в gcc 4.9 куча многих вкусных плюшек.
Учитывая, что в osx последней gcc вообще алиас к clang-ку, то как раз для продакшен распространения своей либы в исходниках, лучше чтобы она компилялась в clang-е. Иначе многие будут иметь проблемы со сброкой. Не говоря уже о компиляции под iOS.

Ну и говорю — у меня другие наблюдения, если сравнивать с 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.
интересно а много таких контор кто в своих коммерческих приложениях весь функционал на плюсах пишет а потом просто добавляет гуй и собирает под андройд/айфон/винфон и т.д.? Такой подход оправдывает затраты или далеко не всегда?
Ну примерно половина всех денег в гугл плее делается приложениями с таким подходам. И это игры :) И гуи нативного там крайне мало. А так подход сложный — ибо современный гуи это как правило многопоточная фигня, и сама core logic тоже как правило многопоточная — скрешивать их универсально еще тот секс в гамаке.
вот точно, имел ввиду все что не игры (их то понятно на open gl разных делают).
Т.е. обычные приложение так не получится клепать, несмотря на то что потока там всего 2: гуй и асинхронная задача (редко когда их больше одной в приложении)?
Можно, вопрос оправданно ли. Тут засада в том, что либо вам нужен программист универсал — который будет и c++, java и objc знать и все хорошо — что большая редкость и очень большая стоимость, либо разделять команду кто-то core team, кто-то за гуи на iOS, кто-то за гуи на android. На самом деле если исключить игры ( а там бывает и по 10+ программеров на проект) — то я не видил столь крупных команд разработчиков мобильных приложений, чтобы такое разделение было оправданно. И даже там где такое оправданно — там разделение скорее серверных/клиентских программистов — т.е. приложения сервисы.

Более, менее близко к тому что вы описывается в разработках различных навигационных программ — tom tom и прочее. Но у них это сложилось еще до ios/android ибо они еще и до этого на куче платформ старались запускаться.
Отвечу за все выше написанные вопросы «зачем». На NDK зачастую пишут продуктовые компании.

Например, dating (то с чем я работал) проекты делают ядро(api) на С/С++ и потом используют на разных платформах. Таким способом остаётся на платформах лишь работа с UI. Такой подход же сейчас пытаются сделать внедряя в проекты Xamarin, но эта штука ещё далека от идеала.

Так, же взять ту же продуктовую компанию Samsung (приходилось сталкиваться с ней). Они пишут много нативного кода, очень много и большинство разработчиков именно необходимые такие скилы как знания Linux kernel. Ребята которые уходят с Samsung'a и приходят в обычную компанию SDK порой даже не видели и не могут написать обычный селектор.

Вот такие мои наблюдения. Так что писать ли на NDK, зависит от случая, задач, проекта. Нужно в первую очередь делать оценку по времени и смотреть будет ли оправдан выбор писать на плюсах или нет.
Большое спасибо за статью, всё очень хорошо и правильно расписано.
Два вопроса:
1) есть ли какая-нибудь разница при использовании вместо Dalvik ADT? Подводные камни или грабли? Не пробовали?
2) clang в NDK всё-таки сыроват, насколько он вообще сейчас используется для сборки native-библиотек?
Для облегчения жизни с Android NDK под Windows можно попробовать использовать плагин для vc2010-2012 — nvidia nsight.
Еще раз спасибо crystax за его доработанный NDK, в свое время он нам очень облегчил жизнь, но сейчас смысла нету, практически все эти плюшки есть в стандартном NDK начиная с 9-той ревизии.
Да, задавал этот вопрос JetBrains, то не смогли ответить. Судя по всему у них пока и в планах нету вводить поддержку NDK.
UFO landed and left these words here
Only those users with full accounts are able to leave comments. Log in, please.