LINUX.ORG.RU

Вышел CrystaX NDK 10.1.0

 , ,


1

2

CrystaX NDK — набор инструментов для разработки на C/C++ (и Objective-C) под Android.

CrystaX NDK разработан как прозрачная замена для Android NDK от Google, но при этом добавляет немало возможностей, отсутствующих в оригинальном NDK. Прежде всего это означает, что CrystaX NDK можно использовать вместо Google NDK, и всё будет продолжать работать как раньше. Но при этом станут доступными многие возможности, отсутствующие в Google NDK.

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

>>> Подробности на официальном сайте проекта



Проверено: fallout4all ()
Последнее исправление: fallout4all (всего исправлений: 8)
Ответ на: комментарий от crystax

ну это и так понятно. я имел ввиду — вы хотите что-то вроде UIKit замутить, или будет просто «поддержка objc + CF, которые никому нахрен ненужны»?

waker ★★★★★
()
Ответ на: комментарий от RiseOfDeath

Честно говоря не знаю naative API это или именно Java часть - всякие покупки в приложениях, всплывающие уведомления и т.п.

Это все Java API. Их поддержки пока нет.

crystax
() автор топика
Ответ на: комментарий от waker

ну я лор на смартфоне иногда читаю, и по ссылкам перехожу. я не собирался использовать crystax на мобиле, но почитать о нем ведь можно, да?

Согласен. Разберемся.

crystax
() автор топика
Ответ на: комментарий от waker

ну это и так понятно. я имел ввиду — вы хотите что-то вроде UIKit замутить, или будет просто «поддержка objc + CF, которые никому нахрен ненужны»?

CoreFoundation, CoreGraphics, CoreServices, CoreText, CoreVideo, CoreData - это в первую очередь. Когда это будет готово, можно будет и к UIKit перейти.

crystax
() автор топика
Ответ на: комментарий от crystax

CoreFoundation, CoreGraphics, CoreServices, CoreText, CoreVideo, CoreData - это в первую очередь.

Отлично! Спасибо за вашу работу!

anonymous
()
Ответ на: комментарий от crystax

Спасибо, прочитал раздел о лицензиях более внимательно и обнаружил подтверждение, что все покрывается свободными лицензиями.

AVL2 ★★★★★
()
Ответ на: комментарий от crystax

Там еще есть меню в верхнем правом углу. При наведении на него мышкой выплывает список дополнительных ссылок, в том числе и для связи.

Хм... не уверен, что смог бы быстро найти его без подсказки. (уж больно оно не приметно на фоне горизаонтального меню с крупным шрифтом).

Это все Java API. Их поддержки пока нет.

Плохо. Этого остро не хватает как моему любимому Qt, так и вообще для «наативного программирования» под андроид. Ну и кроме того, это будет (ИМХО) гораздо более весомой «килер фичей», чем все, что у вас сейчас есть вместе взятое.

RiseOfDeath ★★★★
()
Последнее исправление: RiseOfDeath (всего исправлений: 1)
Ответ на: комментарий от crystax

Не так уж и нормально.

Я говорил только за C++11 :) Функции стандартной либы да - печаль наблюдается. LLVM на рег. основе не пользуюсь - собирается и ладно.

Используя GNU libstdc++, вы не получите ни std::thread, ни std::mutex

Да ну? С этим проблем как раз нет (были минорные жалобы на sigset_t, вылечились дефайном), потоки и мутексы у меня как раз std, - или у вас лишние «не/ни»?

NDK_TOOLCHAIN_VERSION := 4.9
APP_CPPFLAGS := -std=c++11

private:
 std::recursive_mutex mutex_;
 std::thread worker_;
 bool has_tasks_;
 std::condition_variable_any wait_tasks_;

Это из кода, который работает на линуксе, под виндой и в андроиде. Вы точно про NDK 10? (Библиотеку вашу попробую, уговорили :))

slackwarrior ★★★★★
()
Последнее исправление: slackwarrior (всего исправлений: 1)
Ответ на: комментарий от crystax

звучит очень и очень круто. будет интересно увидеть, что получится.

waker ★★★★★
()
Ответ на: комментарий от RiseOfDeath

Это все Java API. Их поддержки пока нет.

Плохо. Этого остро не хватает как моему любимому Qt, так и для программирования под андроид без явы. Ну и кроме того, это будет (ИМХО) гораздо более весомой «килер фичей», чем все, что у вас сейчас есть вместе взятое.

Совершенно и полностью согласен, поэтому над этим будем работать. Просто без текущего этапа все это реализовать было бы намного труднее. Как я уже упоминал здесь в комментариях, текущий релиз, возможно, выглядит бедновато «по фичам», но это важная основа, благодаря которой дальнейшие, более видимые для пользователя фичи, будут реализовываться со значительно меньшими усилиями.

Типичный подход при портировании/реализации чего-либо на Android: «У нас не работают либы A, B и С из-за плохой libc. Поправим-ка мы их, чтоб они учитывали особенности Android».

Наш подход: «У нас не работают либы A, B и C из-за плохой libc. Поправим-ка мы libc, чтоб не надо было править A, B, C, а в дальнейшем еще и D, E, F и еще тонны другого софта».

crystax
() автор топика

но при этом добавляет немало возможностей

при этом станут доступными многие возможности

Где подробности?
Developers, developers, developers.

X10Dead ★★★★★
()
Последнее исправление: X10Dead (всего исправлений: 1)

Проверено: fallout4all

Почему я не удивлён?

X10Dead ★★★★★
()
Ответ на: комментарий от crystax

Может это потому, что из заголовка новости не понятно, что это и для чего? ;)

Надо бы как-то вот так:

Drop-in replacement for Google's Android NDK with Boost 1.57 just out-of-box!

eao197 ★★★★★
()
Последнее исправление: eao197 (всего исправлений: 1)
Ответ на: комментарий от waker

поддержка objc + CF, которые никому нахрен ненужны

-1, для Obj-C много полезных библиотек и некоторые вещи, которые в плюсах невозможно черезжопные (instance to/from json, например), в Obj-C очень удобные. Ну и для android/ios приложений общую часть проще (было бы) делать на Obj-C, чем как сейчас на плюсах.

anonymous
()
Ответ на: комментарий от RiseOfDeath

Этого остро не хватает как моему любимому Qt, так и вообще для «наативного программирования» под андроид.

для полностью нативного — придется все классы жабы прокинуть через JNI в натив. это десятки (вероятнее даже сотни) тыщ методов, и вполне можно предсказать, сколько мегабайт будет весить только код самой обертки. придется разбивать на модули, чтобы не тащить обертки всех жабоклассов в любой helloworld. будет очень сложно сделать, чтобы все это не тормозило, например потому что сишные/крестовые строки передать в жабу невозможно — придется делать NewStringUTF, а потом Release. и так практически для любых сишных данных, кроме int/float/boolean. это приводит к GC и тормозам.

я избрал другой подход — оборачиваю только то что нужно. получаю компактный рантайм. то, что проще делать на жабе — делаю на жабе. оверхед от передачи сишных строк в жабу, конечно, никуда не девается, но с помощью ряда костылей можно забороть.

если использовать только gles (без канваса) — можно многое сделать оптимальнее, но тогда придется тащить с собой огромный рантайм для рисования текста, и т.п.

waker ★★★★★
()
Последнее исправление: waker (всего исправлений: 1)

Проект классный. Знал его ещё в то время, когда официальный NDK был похож на что-то невразумительное. Собирал SDL-приложения для Android именно с помощью вашего NDK. Спасибо.

EXL ★★★★★
()
Ответ на: комментарий от anonymous

-1, для Obj-C много полезных библиотек и некоторые вещи, которые в плюсах невозможно черезжопные (instance to/from json, например), в Obj-C очень удобные.

нету никакого to/from json. читай внимательнее разговор — все это только в планах, и да, это годно. просто его нету.

waker ★★★★★
()
Ответ на: комментарий от slackwarrior

Используя GNU libstdc++, вы не получите ни std::thread, ни std::mutex

Да ну? С этим проблем как раз нет (были минорные жалобы на sigset_t, вылечились дефайном), потоки и мутексы у меня как раз std, - или у вас лишние «не/ни»?

Да, действительно, в последнем r10d эти классы доступны. Это я как-то пропустил. Еще совсем недавно они были недоступны вовсе, т.к. в GNU libstdc++ они закрыты ifdef-ом, открывающим их если определен макрос _GLIBCXX_USE_C99_STDINT_TR1, а он не определялся в процессе сборки GNU libstdc++ из-за бедности Bionic. Ну что ж, могу поздравить Google - они в очередной раз геройски решили проблему, которую сами себе и создали.

Однако, это не отменяет того факта, что стандартная библиотека C++ все равно не полная. Для интересующихся предлагаю открыть файл $NDK/sources/cxx-stl/gnu-libstdc++/4.9/libs/armeabi-v7a/include/bits/c++config.h и оценить, сколько макросов там не определено, а затем самостоятельно поискать в $NDK/sources/cxx-stl/gnu-libstdc++/4.9/include, что от этих макросов зависит.

Мы же, вместо того чтоб править GNU libstdc++, решили править нижний уровень, от которого libstdc++ зависит. Это значительно более перспективный путь, который к тому же позволяет исправить не только libstdc++, но и множество другого софта, ожидающего честного POSIX поведения от системы.

crystax
() автор топика
Ответ на: комментарий от eao197

бинарный boost, но зачем?

Серьезный вопрос, что из буста используете для android, чего нет в header-only?

anonymous
()
Ответ на: комментарий от slackwarrior

Ну если с вашей «лечить дефайнами» ничего не надо - так это ж отлично :)

Нет, не надо. В CrystaX NDK мы уже «вылечили». Просто берите и пользуйтесь :)

crystax
() автор топика
Ответ на: комментарий от crystax

Нет, но надо будет посмотреть на этот проект.

Гугловое NDK не умеет на самом деле делать нативное окно. Оно запускает Java-контейнер, в котором уже отдаёт контроль нативному коду. Уверен, вы и сами это знаете. Было бы здорово подружить вас с libhybris, тогда средствами вашего NDK можно было бы создавать отвязанные от Android приложения.

На самом же деле, чем дальше, тем меньше libcrystax зависит от Bionic (в идеале хотелось бы от такой зависимости уйти вообще), а потому и вероятность поломок при смене версии Android снижается.

То есть, теоретически в будущем вы могли бы привязаться напрямую к ядру и не линковаться с Bionic?

Это было сделано

Можете ещё в /r/linux написать, там разработчики тоже обретаются

В феврале-марте попробую ваш NDK, из того, что я услышал, всё вкуснота.

Adonai ★★★
()
Ответ на: комментарий от Adonai

Гугловое NDK не умеет на самом деле делать нативное окно. Оно запускает Java-контейнер, в котором уже отдаёт контроль нативному коду. Уверен, вы и сами это знаете. Было бы здорово подружить вас с libhybris, тогда средствами вашего NDK можно было бы создавать отвязанные от Android приложения.

Да, я в курсе того, как это делается. Что же касается libhybris - обязательно посмотрим.

То есть, теоретически в будущем вы могли бы привязаться напрямую к ядру и не линковаться с Bionic?

Да, именно этого и хотелось бы добиться в идеале. Слишком уж Bionic ненадежна.

Можете ещё в /r/linux написать, там разработчики тоже обретаются

Спасибо за подсказку. Наверное, напишем.

crystax
() автор топика
Ответ на: комментарий от crystax

Serialization - это какое-то очень злое метапрограммирование, у меня от него размер APK умер. Filesystem на мобильных платформах не нужна. Сигналы в принципе не нужны (в приложениях).

anonymous
()
Ответ на: комментарий от anonymous

Serialization - это какое-то очень злое метапрограммирование, у меня от него размер APK умер

Serialization - метапрограммирование? Вы не путаете c MPL/Fusion?

Filesystem на мобильных платформах не нужна. Сигналы в принципе не нужны (в приложениях).

В отличии от вас, не считаю себя вправе указывать, кому что нужно. Знаю многих, кому нужно.

Вообще, слишком это распространено стало - каждый спешить поделиться своим «ценным» мнением, что мне нужно. Спасибо, но я как-нибудь сам разберусь, что мне нужно.

Мы предлагаем возможность воспользоваться той или иной фичей, а пользоваться ей или нет, каждый решает сам. В любом случае, по моему твердому убеждению, наличие возможности всегда лучше, чем ее отсутствие, еще и диктуемое с непередаваемым апломбом: «Не нужно!».

crystax
() автор топика
Ответ на: комментарий от crystax

libcrystax

В каком репозиратии на github искать её исходники? Я так понимаю (по ответам), что правленный bionic и libcrystax — это основное, что изменено. Нельзя ли выпустить эти исходники в виде архива или как-то отделить основную часть от остального (компиляторы и тд)?

seyko2
()

Снимаю шляпу, хорошие дела делаете.

amazpyel ★★★
()
Ответ на: libcrystax от seyko2

В каком репозиратии на github искать её исходники?

Это не один, это набор репозиториев. Их список можно посмотреть в сборочном скрипте. Ссылку на него с инструкциями можно найти здесь.

Я так понимаю (по ответам), что правленный bionic и libcrystax — это основное, что изменено.

Нет, не так. Bionic мы не трогали вовсе, т.к. Bionic - это часть firmware на девайсе, и мы не можем ее заменить в приложении. Поэтому мы добавили libcrystax, которой нет в оригинальном NDK, и в ней мы заместили большую часть функциональности из Bionic. Приложение линкуется с libcrystax и потому перестает зависеть от Bionic - в тех частях, что реализованы в libcrystax. Далее libcrystax пакуется в приложение и распространяется вместе с ним.

Кроме того, было много изменений и в других компонентах - gcc/clang и т.д. Весь список сейчас не упомнить, но все это есть в логах git.

Нельзя ли выпустить эти исходники в виде архива или как-то отделить основную часть от остального (компиляторы и тд)?

Тут нет «основной» и «неосновной» части. Проект цельный, т.к. для нормальной работы потребовалось много изменений практически во всех компонентах NDK. Если вам хочется скачать все исходники и попробовать собрать самому - you are welcome!

crystax
() автор топика

Наконец-то адекватный инструмент.

Shadow1251
()
Ответ на: комментарий от guitarist

Сколько весит HelloWorld, написанный на CrystaX NDK?

Размер APK файла для hello-jni примера из поставки NDK, собранного Android NDK от Google - 228 Kb.

Размер его же, собранного CrystaX NDK с настройками по умолчанию (т.е. с динамической линковкой libgnustl_shared.so и libcrystax.so) - 548 Kb.

Его же размер, собранного CrystaX NDK, но используя статическую линковку с GNU libstdc++ и libcrystax - 420 Kb.

crystax
() автор топика
Ответ на: комментарий от waker

для полностью нативного — придется все классы жабы прокинуть через JNI в натив.

Там что, весь гуй системы, все «коллекции» (или как оно там правильно называется) и т.п. написано на яве и не трогает сишную прослойку?

RiseOfDeath ★★★★
()
Ответ на: комментарий от RiseOfDeath

Там что, весь гуй системы, все «коллекции» (или как оно там правильно называется) и т.п. написано на яве и не трогает сишную прослойку?

Может, и не все, но бОльшая часть.

Тем не менее, это не так страшно, как выглядит, особенно с учетом того, что на последних версиях Android происходит компиляция байткода в нативный в момент установки на девайс (ART runtime). Ну и, кроме того, вряд ли так уж важно, отрисуется гуй за 2 миллисекунды, или за 20.

crystax
() автор топика
Ответ на: комментарий от RiseOfDeath

Там что, весь гуй системы, все «коллекции» (или как оно там правильно называется) и т.п. написано на яве и не трогает сишную прослойку?

угу

waker ★★★★★
()
Ответ на: комментарий от crystax

Ну и, кроме того, вряд ли так уж важно, отрисуется гуй за 2 миллисекунды, или за 20.

для плавного скроллинга, гуй должен рисоваться не больше чем за 16.6ms, иначе дергается. на практике, в твоем собственном коде, нужно исходить из <10ms (или еще меньше), потому что дальше система тратит тонны времени на подготовку кадра к рендеру, прежде чем передать готовые буфера в gles.

waker ★★★★★
()
Ответ на: комментарий от crystax

используя статическую линковку с GNU libstdc++

это годится только для опенсорса. (если что, мне это не надо, я не использую c++)

waker ★★★★★
()
Последнее исправление: waker (всего исправлений: 1)
Ответ на: комментарий от crystax

на последних версиях Android происходит компиляция байткода в нативный в момент установки на девайс (ART runtime)

вот это вообще совсем никак не помогает писать под андроид на сишке, и никак не избавляет от проблем с GC.

waker ★★★★★
()
Ответ на: комментарий от waker

для плавного скроллинга, гуй должен рисоваться не больше чем за 16.6ms, иначе дергается. на практике, в твоем собственном коде, нужно исходить из <10ms (или еще меньше), потому что дальше система тратит тонны времени на подготовку кадра к рендеру, прежде чем передать готовые буфера в gles.

Верно. Это решается выносом всех блокирующих операций во внешние (более низкоприоритетные, чем UI) потоки. А сама отрисовка, даже с использованием Java API, достаточно быстрая для этого (китайский low-end в расчет не беру).

crystax
() автор топика
Ответ на: комментарий от waker

это годится только для опенсорса. (если что, мне это не надо, я не использую c++)

Именно поэтому по умолчанию используется динамическая линковка с GNU libstdc++. А также доступна LLVM libc++, которая совсем удобна с точки зрения лицензии.

crystax
() автор топика
Ответ на: комментарий от crystax

Верно. Это решается выносом всех блокирующих операций во внешние (более низкоприоритетные, чем UI) потоки.

это какие-такие блокирующие операции у тебя есть в UI-потоке, которые можно вынести в другой поток?

А сама отрисовка, даже с использованием Java API, достаточно быстрая для этого (китайский low-end в расчет не беру).

если бы...

waker ★★★★★
()
Ответ на: комментарий от waker

вот это вообще совсем никак не помогает писать под андроид на сишке, и никак не избавляет от проблем с GC.

Верно, но это было упомянуто для того, чтоб объяснить, что факт реализации родного UI на Java (в самом Android) не так страшен с точки зрения производительности, как это может себе представить человек, далекий от этой темы. На практике UI работает очень шустро.

crystax
() автор топика
Ответ на: комментарий от waker

это какие-такие блокирующие операции у тебя есть в UI-потоке, которые можно вынести в другой поток?

У меня - никаких, потому что я жестко следую правилу «don't block UI». А вот у других - очень часто. Насмотрелся. Например, делают загрузку из сети (блокирующую) прямо в Activity.onCreate(), а потом жалуются, что «UI тормозит». Не зря ведь (начиная с 4.0, что ли?) при использовании URLConnection из UI потока, выбрасывается Exception. Слишком много было орлов, которые его прямо из UI дергали.

crystax
() автор топика
Ответ на: комментарий от invy

В составе CrystaX NDK идут примеры приложений. Лежат в $NDK/samples. Тут, собственно, ничего специфичного для CrystaX NDK нет - это повторяет то, что есть в Android NDK от Google. Использовать CrystaX NDK надо так же, как и Google NDK. Мы потому и акцентируем внимание на том, что CrystaX NDK - это прозрачная замена Google NDK. Просто появляются доп. фичи, и со временем их количество будет увеличиваться.

crystax
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.