The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Вышел CrystaX NDK 10.1.0, инструментарий для разработки Android-приложений на C/C++

22.01.2015 23:46

Доступен CrystaX NDK 10.1.0, набор инструментов для разработки на C/C++ (и Objective-C) под Android. CrystaX NDK разработан как прозрачная замена для Android NDK от Google, но при этом добавляет немало возможностей, отсутствующих в оригинальном NDK. Прежде всего это означает, что CrystaX NDK можно использовать вместо Google NDK, и всё будет продолжать работать как раньше. Но при этом станут доступными многие возможности, отсутствующие в Google NDK, такие как поддержка широких символов, полноценная система Си-локалей, библиотека расширенных математических функций, поставка более новых версий GCC и Clang, поддержка C++11/C++14, наличие библиотеки Boost и т.д.

В новом выпуске основной упор сделан на совместимость с POSIX, и в большей степени этого удалось достичь. Иными словами, при использовании CrystaX NDK, Android становится для разработчика намного более POSIX-совместимым, чем он есть на самом деле, а потому, сильно облегчается задача портирования кода с других платформ — в частности, с Linux. Код наработок CrystaX NDK опубликован на GitHub.

  1. Главная ссылка к новости (https://www.crystax.net/androi...)
Автор новости: Dmitry Moskalchuk
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/41520-android
Ключевые слова: android, ndk, crystax
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (18) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 09:53, 23/01/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    Щастье есть
     
     
  • 2.2, Аноним (-), 10:06, 23/01/2015 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Если не есть - помрешь.
     
     
  • 3.12, terraslav (ok), 17:35, 28/01/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ешь не ешь, а помрешь неминуемо.
     

  • 1.3, Аноним (-), 11:35, 23/01/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Неужто даже для мусорного ведра можно будет компилить программы более-менее по человечески?
     
     
  • 2.6, Аноним (-), 10:06, 24/01/2015 [^] [^^] [^^^] [ответить]  
  • –6 +/
    Не очень понимаю зачем это нужно, может для игр? Но гуя и 3D вроде на андроиде и так прилично бегает за счет JIT.
    Решать свои потребности на С/С++ - это совсем не вариант, для этих целей существует perl (в основном демоны с init.d стартуют).
    Для тяжелых вычислении? - Но телефон и планшеты - это далеко не лучшие варианты для вычислении. Если припрет, лучше тем же perl-скриптом скинуть задачу на числодробление на удаленный хост. Вообщем я не понимаю целесообразность этого NDK.
     
     
  • 3.7, Crazy Alex (ok), 03:50, 25/01/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    1) Кроссплатформенный софт, меняющий только морду, Как тот же deadbeef. Или менее кросспалтформенный - где ядро одно и то же для Android и iOS.
    2) Удалённый хост - это хорошо... когда он доступен и имеет приемлемые задержки. Что бывает отнюдь не всегда. А чем дальше - тем больше всякого распознавания образов и прочих тяжелых вичслений на мобильных девайсах. И результаты нужны, как правило, как можно быстрее.
    3) даже с JIT игры тащили и тащат плюсовые ядра. Может, начиная с Android L c AOT что-то изменится, но очень не факт.
    4) на некоторых задачах пожирание памяти аккуратно написанным сишным кодом по сравнению с джавовским с GC может отличаться на порядок. Вплоть до разницы "будет вообще работать или нет".
    5) Чем дальше - тем ближе андроид-системы к обычным десктопным по мощности. А значит - хочется, чтобы на них работали привычные для десктопа инструменты. И с минимальной морокой.
     
     
  • 4.10, тоже Аноним (ok), 09:40, 26/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Добавлю к 1, что возможен кроссплатформенный софт с кроссплатформенной же мордой.
    При использовании библиотек типа Cocos2d-x в проекте код для Android и iOS может отличаться только в тех местах, где действительно выполняются разные действия. Остальные отличия возьмет на себя библиотека.
     

  • 1.4, Аноним (-), 11:42, 23/01/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    звучит годно, надо будет попробовать
     
     
  • 2.5, Аноним (-), 14:19, 23/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Раздел "Услуги" посмотри и убоись.
     
     
  • 3.8, Crazy Alex (ok), 03:53, 25/01/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ну раздел как раздел... Единственное, что непонятно - чего у них дефолтный вариант сайта - русскоязычный.
     
     
  • 4.13, crystax (?), 18:20, 29/01/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Там нет дефолтного варианта сайта. Он просто смотрит на HTTP AcceptLanguage, присылаемый браузером, и выдает страницу на нужном языке.
     

  • 1.9, Аноним (-), 06:28, 25/01/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    снова что то дельное
     
  • 1.11, Ne01eX (ok), 11:40, 26/01/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Хм. А разве само наличие libcrystax не гробит на корню саму идею комплекта для нативной разработки?
     
  • 1.14, Аноним (-), 01:03, 02/02/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Но при этом станут доступными многие возможности, отсутствующие в Google NDK,
    > такие как ... поддержка C++11/C++14, наличие библиотеки Boost и т.д.

    Видел Ваши сообщения еще на двух ресурсах. Например, на rsdn Вы утверждаете:

    "В Android NDK доступны на выбор две реализации стандартной библиотеки C++ — GNU libstdc++ и LLVM libc++. К сожалению, обе работают плохо. Используя GNU libstdc++, вы не получите ни std::thread, ни std::mutex, ни std::chrono — и это далеко не все. Фактически, о полноценном C++11 можно забыть."

    Но вообще-то, это совсем не так. Стандартный NDK содержит не 2, а 4 реализации STL ( http://www.kandroid.org/ndk/docs/CPLUSPLUS-SUPPORT.html ):

    - system - та самая обрезаная версия "без всего", которую Вы ошибочно называете GNU libstdc++
    - gabi++
    - stlport
    - gnustl - собственно GNU libstdc++ с полной поддержкой std::thread, std::mutex, std::chrono, и всего остального, что входит в C++11 - при условии выбора соответсвующего toolchain (например, gcc 4.8 или 4.9).  

    Так что C++11 доступен в NDK достаточно давно.

     
     
  • 2.15, crystax (?), 01:20, 02/02/2015 [^] [^^] [^^^] [ответить]  
  • +/
    gt оверквотинг удален Это ошибочное представление Версии system gabi stlp... большой текст свёрнут, показать
     
     
  • 3.16, crystax (?), 01:33, 02/02/2015 [^] [^^] [^^^] [ответить]  
  • +/
    И кстати - std::chrono в Google NDK более-менее доступен (при использовании), но std::chrono::monotonic_clock, к примеру, не гарантирует монотонности, а просто и тупо является алиасом к std::chrono::system_clock. Как говорится, удачи в отладке. Даже предупреждения не выдается при сборке.

    А в CrystaX NDK std::chrono::monotonic_clock - это честный monotonic clock, на ход времени которого не влияет переустановка системного времени.

    И это только один из множества примеров, когда, чтобы поймать ошибку, приходится отлаживаться не то чтобы часами или днями, но иногда даже неделями - и все только для того, чтобы выяснить, что баг в системной libc или в gnustl. До сих пор вспоминаю, сколько времени пришлось потратить, чтоб в конце концов выяснить, что strtod() не парсит строки "0xNNN", а просто возвращает нуль. Если б хотя бы падала, легче найти причину было бы - но нет, просто 0 на выходе. А чтобы дойти до strtod(), пришлось продраться через огромную гору кода, и затратить на это несколько дней.

     
     
  • 4.17, Аноним (-), 02:41, 02/02/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Спасибо за пояснения!

    (спаведливости ради следует отметить, что std::thread и std::mutex работали корректно уже в r9c - в более ранних версиях не пробовал).

    Еще два вопроса:

    1. Вы говорите, что можно просто заменить Google NDK на CrystaX и все будет работать также, как и ранее с NDK, "только лучше" :-)

    Однако при попытке сделать это ("просто заменить") с проектом с native activity запускаемым через native_app_glue, и использующим минимиум third-party библиотек (Box2D, tinyxml2 и libpng) проект успешно компилируется, однако не запускается на планшете ("...could not load application...").

    2. Можно ли слинковать вашу библиотеку libcrystax с программой статически?

     
     
  • 5.18, crystax (?), 02:52, 02/02/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > (спаведливости ради следует отметить, что std::thread и std::mutex работали корректно
    > уже в r9c - в более ранних версиях не пробовал).

    Верно, это я ошибся. Просто я с этим столкнулся намного ранее r9c (еще в r7), и мне немало пришлось потрудиться, чтоб заставить std::thread и std::mutex корректно работать. Ну а сейчас произошла некоторая аберрация памяти и я назвал std::thread/std::mutex в списке недоступных фич.

    > Однако при попытке сделать это ("просто заменить") с проектом с native activity
    > запускаемым через native_app_glue, и использующим минимиум third-party библиотек (Box2D,
    > tinyxml2 и libpng) проект успешно компилируется, однако не запускается на планшете
    > ("...could not load application...").

    Надо просто загрузить libcrystax.so перед загрузкой native activity. Если у вас есть хоть сколько-нибудь Java кода, то проще всего это сделать так:

    static {
        System.loadLibrary("crystax");
    }

    Если же Java нет и добавлять не хочется, то можно:

    - написать свой stub, в котором делать dlopen() для libcrystax.so и затем передавать управление native activity (вот тут это хорошо объясняется: http://stackoverflow.com/questions/12524664/cant-load-native-shared-library-w)

    - либо просто статически слинковаться с libcrystax.a

    > 2. Можно ли слинковать вашу библиотеку libcrystax с программой статически?

    Да, можно. Если используется ndk-build, то просто добавьте в ваш Application.mk:

    APP_LIBCRYSTAX := static

     
     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру