Comments 13
Наконец-то про NDK написали
OpenAL не лучший выбор, слышал задержки на андроиде у него просто чудовищные. Но как пример использования NDK вполне сойдет.
Насколько я понимаю (я с NDK никогда не работал, хотя планирую освоить) использование OpenAL наиболее оправданно для кроссплатформенного кода для Android/Bb/iOS, о чём вы в статье и указали. Но в документации по разработке гуглеры большей частью указывают на спеки Хроноса по OpenSL ES. Работали с ним? Много ли подводных камней, и стоит ли по его поводу заморачиваться или можно жить с OpenAL и не париться?
Я сам с ndk не так давно начал работать. Сейчас вот планируем игру в маркет выпустить. Весь звук у нас на OpenAL. Никаких проблем ни на одном устройстве не встретили. Так что, как мне кажется, можно с OpenAL работать. Естественно, это касается только звука.
Большие музыкальные файлы в Java/Objective C надо выносить.
Большие музыкальные файлы в Java/Objective C надо выносить.
Если используется Android Developer Tools Bundle, то Cygwin не нужен, достаточно скачать NDK и прописать путь к нему в настройках ADT-шного Eclipse. Будет писать предупреждение об отсутствии Cygwin во время компиляции, но на него можно забить. Не пробовал с обычным Eclipse.
NDK, безусловно, очень интересная вещь. И если бы была только одна аппаратная платформа, то (ИМХО) все бы только на С/С++ и кодили. Но сила Android-а в его всеядности по отношению к железу, за счёт DalvikVM прослойки. Т.е. написав только на Java, программа должна (теоретически) запускаться на любом железе с подходящей версией API. Если писать нативный код, то, по-хорошему, нужно поддерживать версии для всего актуального железа, на сейчас это (пока) только ARM, x86 и начинается MIPS. И если даже само количество платформ вряд-ли увеличится, то текущие точно будут развиваться. Фрагментация — зло, очень тяжело поддерживать весь этот зоопарк. В Google это очень хорошо понимают и без самой крайней необходимости использовать не советуют. И не просто не советуют, а в каждых новых версиях открывают всё больше низкоуровнего API, для которого раньше без NDK никак. Тем не менее NDK они тоже продолжают развивать, и даже подтягивают туда Clang!
Сам сейчас стараюсь все делать на Java. Да, иногда сильно медленней, но такова идеология Android-а.
По поводу примера — он хорош, но область наверное не самая показательная, т.к. никакого преимущества в скорости работы это не даст, одни только лаги. Нужно стараться использовать родные форматы, в идеале — аппаратно ускоряемые (mp3,aac).
В нескольких проектах я использовал NDK, для того, что бы прикрутить библиотеку MuPDF для рендера PDF-ок в битмапу. Так как ничего родного (как в iOS) не нашёл, а Java-реализации ну совсем не радовали скоростью.
Сам сейчас стараюсь все делать на Java. Да, иногда сильно медленней, но такова идеология Android-а.
По поводу примера — он хорош, но область наверное не самая показательная, т.к. никакого преимущества в скорости работы это не даст, одни только лаги. Нужно стараться использовать родные форматы, в идеале — аппаратно ускоряемые (mp3,aac).
В нескольких проектах я использовал NDK, для того, что бы прикрутить библиотеку MuPDF для рендера PDF-ок в битмапу. Так как ничего родного (как в iOS) не нашёл, а Java-реализации ну совсем не радовали скоростью.
Соглашусь с тем, что без надобности лучше не использовать ndk. В моём случае движок игровой был на C++ изначально, поэтому выхода особого то и не было.
По поводу же фрагментации. Зачастую ndk используют из-за того, что уже есть много C++ наработок (готовых библиотек и т.д.). Как я могу наблюдать, многие сообщества Open Source проекты постепенно допиливают, чтобы помимо x86 нормально и под ARM запускалосm (тот же Vorbis, OpenCV и другие).
По поводу примера — он хорош, но область наверное не самая показательная, т.к. никакого преимущества в скорости работы это не даст, одни только лаги.
Если смотреть так, то да. Мне же удачный билд OpenAL на Anroid позволил использовать полностью весь тот код по работе со звуком, который был написан для работы на iOS.
По поводу же фрагментации. Зачастую ndk используют из-за того, что уже есть много C++ наработок (готовых библиотек и т.д.). Как я могу наблюдать, многие сообщества Open Source проекты постепенно допиливают, чтобы помимо x86 нормально и под ARM запускалосm (тот же Vorbis, OpenCV и другие).
По поводу примера — он хорош, но область наверное не самая показательная, т.к. никакого преимущества в скорости работы это не даст, одни только лаги.
Если смотреть так, то да. Мне же удачный билд OpenAL на Anroid позволил использовать полностью весь тот код по работе со звуком, который был написан для работы на iOS.
Тема хорошая, но скомкано вышло…
Если уж в заголовке «Основы...», то хотелось бы чуть подробнее и более связно.
Если уж в заголовке «Основы...», то хотелось бы чуть подробнее и более связно.
Сперва думал, что статья хорошая, а потом почитав, понял, что не совсем:(
developer.android.com/intl/ru/guide/appendix/media-formats.html
-Форматы WAV и OGG и так поддерживаются Андроидом, зачем использовать такой ужас лишний в виде NDK с OpenAL? Лучше тогда уж OpenCV — там много полезных вещей для Image Processing-а.
-Для новичка конечно кое-что есть полезное в плане связки кода С++/Java, но во-первых Cygwin как уже отметили, давно не нужен, ибо просто юзаем ndk-build и во-вторых зачем постоянно извиняться, что статья большая, когда вы же ее составляли? Напишите структуру, а потом уже материал… а то грустно читать порой Хабр. Толковых статей стало меньше.
Понимаю, что вы осилили NDK, вы молодец и все такое, но пожалуйста продумывайте лучше статью и досконально перед ее написанием изучите предмет…
А так все хорошо.
developer.android.com/intl/ru/guide/appendix/media-formats.html
-Форматы WAV и OGG и так поддерживаются Андроидом, зачем использовать такой ужас лишний в виде NDK с OpenAL? Лучше тогда уж OpenCV — там много полезных вещей для Image Processing-а.
-Для новичка конечно кое-что есть полезное в плане связки кода С++/Java, но во-первых Cygwin как уже отметили, давно не нужен, ибо просто юзаем ndk-build и во-вторых зачем постоянно извиняться, что статья большая, когда вы же ее составляли? Напишите структуру, а потом уже материал… а то грустно читать порой Хабр. Толковых статей стало меньше.
Понимаю, что вы осилили NDK, вы молодец и все такое, но пожалуйста продумывайте лучше статью и досконально перед ее написанием изучите предмет…
А так все хорошо.
Sign up to leave a comment.
Основы Android NDK на примере работы с OpenAL