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

на андроиде отрисовка лагает даже если UI thread почти ничего не делает. недавно столкнулся, что на samsung galaxy tab 2 / android 4.2.2, даже если просто заливать прямоугольник одним цветом — на это уходит 15-25ms (скачет). т.е. 60 fps никак не выжать. а если рисовать интерфейс — 50 ms аж бегом.

гугл предлагает это решать используя surfaceview, и параллелить отрисовку. если все очень сильно оптимизнуть, то (вероятно) можно выжать 60 fps, но все равно придется попотеть, и скорее всего будет 30 гарантированных.

но с surfaceview есть проблема, что перерисовывать надо все содержимое. т.е. придется либо рисовать вообще все на каждом кадре (а это вообще ого-го как медленно!), либо создавать отдельные surfaceviews для каждого анимированного элемента. или хотя бы для списков.

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

Во-первых, все-таки скорость отрисовки зависит от а) мощности девайса и б) версии Android. Я наблюдаю явное улучшение производительности UI со временем. А Galaxy Tab 2/Android 4.2.2 это никак не самый свежий девайс, да и версия ОС даже не предпоследняя.

Во-вторых - да, с Android-ом бывает, что нужно повозиться, но это, вообще говоря, и к другим платформам относится. Например, современную полностью нативную 3D игру тоже на старом Pentium III не запустишь.

Это, конечно, не значит, что в мире Android все волшебно. Несуразностей и нелепостей на ровном месте там хватает. Мой пойнт просто в том, что много чего можно улучшить (чем мы и занимаемся в меру сил и возможностей). А если что-то нельзя улучшить в силу непреодолимых обстоятельств (как, например, факт наличия не очень мощных устройств на рынке, не справляющихся с очень-быстрой-отрисовкой) - решать другими способами. Например, созданием UI попроще специально для таких девайсов. Это, кстати, типичный подход в мире игр - настройки производительности в зависимости от конкретной машины, на которой происходит запуск.

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

Для разработки на C, C++ и Objective-C.

В общем-то верная поправка, но на данный момент Objective-C не является таким же полноценным «гражданином» у нас в NDK, как C и C++. Вот когда добавим более полную поддержку, тогда и переформулируем, как предложено.

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

Так а поддержка в оригинальном NDK С89/С99 полноценная есть?

Языка - есть. Стандартной библиотеки (libc) - нет. Та, что есть (Bionic), на звание «стандартной» никак не тянет.

У нас в CrystaX NDK поддерживается как язык, так и стандартная библиотека. Строго говоря, гарантию 100% поддержки стандартной библиотеки C мы пока не дадим, но а) она поддерживается в несравнимо бОльшей степени, чем в Google NDK, и б) мы продолжаем работать над этим, так что если и не сейчас, то в скором времени будет поддерживаться полностью.

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

gnustl_static

это годится только для опенсорса.

4.2? IIRC у них там GPL исключения на все случаи жизни и линковаться статически можно из закрытого кода

anonymous
()

Т.е. можно писать на ондроид без жирножабы?

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

Об этом написано на странице релиза, на которую ведет ссылка из новости

Ъ по ссылкам не ходят.

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

Размер 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.

А, ну вроде терпимо, я думал пострашнее будет. А как динамическая работает, почему динамическая жирнее? Идёт полная бинарка либы внутри apk, и причём внутри каждой apk? (Поясню уровень понимания: я писал под Android, но без NDK.)

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

Возможна ли разработка под Андроид НЕ касаясь джавы и не устанавливая джаварантаймы для сборки?

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

А, ну вроде терпимо, я думал пострашнее будет. А как динамическая работает, почему динамическая жирнее?

Просто при статической линковке у линкера больше свободы, и он имеет возможность выкинуть некоторые части, которые нигде не используются. В случае же динамической линковки линкер не имеет права трогать уже собранную so-шку, поэтому она включается целиком как есть. Т.е. в общем случае размер в случае статической линковки меньше либо равен (если линкеру ничего не удалось выкинуть) размеру для случая динамической компоновки.

Идёт полная бинарка либы внутри apk, и причём внутри каждой apk?

Внутрь финального apk (который выкладывается на Google Play, например) дополнительно вкладывается libcrystax.so. Ну или не вкладывается, а просто влинковывается в случае статической линковки.

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

Возможна ли разработка под Андроид НЕ касаясь джавы и не устанавливая джаварантаймы для сборки?

На данный момент - возможна, но только в _очень_ специфических ситуациях, когда почти ничего от Android не нужно - ни UI, ни периферии типа камеры/микрофона и т.д.

В будущем планируем развиться до уровня, когда достаточно будет только NDK.

crystax
() автор топика
Ответ на: gnustl_static от anonymous

это годится только для опенсорса.

4.2? IIRC у них там GPL исключения на все случаи жизни и линковаться статически можно из закрытого кода

Кстати, да. GNU libstdc++ можно использовать и в коммерческом софте, даже статически линкуясь, без открытия исходников. Об этом специально написано в лицензии.

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

Идёт полная бинарка либы внутри apk, и причём внутри каждой apk?

Внутрь финального apk (который выкладывается на Google Play, например) дополнительно вкладывается libcrystax.so. Ну или не вкладывается, а просто влинковывается в случае статической линковки.

Ну понятно, то есть нет преимуществ динамической линковки. По идее надо бы как-то эту либу динамическую в сам андроид засунуть. Но это похоже пользовательскими средствами не сделать (если не собирать свой андроид или не пихать под рутом).

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

Ну понятно, то есть нет преимуществ динамической линковки.

Динамическая линковка нужна, если в приложении используется несколько so-шек. Например, libApp.so, libpng.so, libjpeg.so. В этом случае необходимо использовать динамическую линковку, чтобы все три либы зависели от одной libcrystax.so. Иначе же каждая либа будет содержать в себе статически влинкованную libcrystax, и от этого всем станет плохо. Это не специфика libcrystax, то же самое относится к линковке с GNU libstdc++ и т.д.

По идее надо бы как-то эту либу динамическую в сам андроид засунуть. Но это похоже пользовательскими средствами не сделать (если не собирать свой андроид или не пихать под рутом).

Совершенно верно, в систему ее не запихнуть без рута, поэтому единственный приемлемый вариант - это таскать ее с собой. Однако, это не только минус, но и плюс - в случае обновления libcrystax (например, исправления ошибок), достаточно просто перепаковать приложение с обновленной библиотекой и выложить update. Таким образом, не зависишь от версии, установленной на девайсе (как это происходит с libc, например).

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

Спасибо, на вид как раз то, что нужно.

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

По идее надо бы как-то эту либу динамическую в сам андроид засунуть.

О майн гат! Сразу в голову себе засунь!

Что за непреодолимое желание всюду влезть и централизованно испортить систему своими костылями?!

AVL2 ★★★★★
()

Видел статью автора на хабре в 2012 году. Здорово, что проект ещё жив.

У pthread_cancel те же ограничения, что и в Bionic, или потоки свои?

anonymous
()

Я боюсь даже представить, чего может не хватать разработчикам в Android NDK... Особенно с учетом того что NDK это только маленький слой для выполнения оооочень узкого круга задач... вы чтоль апач собрались на смартфонах запускать?
Или лавры цыганомода покоя не дают?

Jetty ★★★★★
()

В android, кстати, внутри очень много библиотек, доступных и недоступных для использования. Т.е. вроде как доступных, но не особо документированных. И практика показывает, что недокументированными вещами лучше не пользоваться - гугл оставляет за собой право их изменять, ломать совместимость и часто этим правом пользуется. Тот же ICU, там есть. И icudt.dat в /system/usr/icu лежит, доступный всем на чтение. Но в разных версиях android - разная версия icu и не факт, что в будущих версиях он там останется.

Если в libcrystax используются какие-то из таких функций - то есть вероятность, что ваше приложение сломается в новых версиях android.

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

У pthread_cancel те же ограничения, что и в Bionic, или потоки свои?

Потоки пока из Bionic, поэтому pthread_cancel все тот же.

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

Если в libcrystax используются какие-то из таких функций - то есть вероятность, что ваше приложение сломается в новых версиях android.

Нет, мы не используем скрытые функции из библиотек на девайсе, слишком это ненадежное дело.

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

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

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

Тот факт, что Google не хочет заниматься NDK, виден невооруженным глазом. Но это вовсе не значит, что теперь все должны построиться стройными рядами и начать выполнять только то, что предписывает Google. У разработчиков есть нужды, которые Google не торопится удовлетворять. Ну а раз так - то мы будем удовлетворять их сами.

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

приводит к GC и тормозам

в 2015 году с гигабатйами RAM и четырехъядерными процессорами, и sd-картами по 50 гигов это всё еще актуально? Ну будет прога весить на карточке не 200кб, а 2 мегабайта, или 20, или если с ресурсами - пусть хоть 2 гигабайта.

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

Я боюсь даже представить, чего может не хватать разработчикам в Android NDK... Особенно с учетом того что NDK это только маленький слой для выполнения оооочень узкого круга задач... вы чтоль апач собрались на смартфонах запускать?
Или лавры цыганомода покоя не дают?

Откуда такие берутся? Ни одной нормальной игры нету без использования натива, ни одного движка, браузера, офиса. Даже те же CoolReader/FBReader имеют ядро написаное на нативе + посторонние библиотеки

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

в 2015 году с гигабатйами RAM и четырехъядерными процессорами, и sd-картами по 50 гигов это всё еще актуально? Ну будет прога весить на карточке не 200кб, а 2 мегабайта, или 20, или если с ресурсами - пусть хоть 2 гигабайта.

То есть вы ложите болт на пользователей бюджетных тедефонов? На пользователей часов? В холодильники тоже нужно сунуть 8 ядер + 8 гб ОЗУ? И вы за раз используете только одно приложение? Без мультизадачности, сервисов и т.д.? И у вас батарейка на 9000 мА? Товарищь waker разрабатывает под андроид deadbeef. Помню как он мучался чтоб довести потребление процессора не выше 5% на его старом телефоне с arm6, как в дефолтном плеере. А теперь представьте, что его плеер жрет 50% CPU и 2 гб памяти. Бюджетные телефоны отпадают, дорогие же тянут, но андроиду придется убивать другие фоновые приложения, ибо они же тоже будут просить по 2 гб памяти + 10-50% проца :) То есть пока вы будете слушать музычку/серфить, вам даже почта не придет

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

сколько будет разрабатываться софт, и что такое бюджетный телефон? Если это не очередная поделка из трех кнопочек, а что-нибудь серьезное типа навигатора, для чего реально нужен C++, и начать разрабатывать его сейчас, первые версии появятся не раньше чем через год. Сейчас мой бюджетный (тысяч 15 рублей) телефон Xperia M2 тянет даже скайп. Что будет со смартфонами через год?

про 2 гигабайта я говорил, 2 гигабайта на SD-карте. В феврале ПРОШЛОГО года уже появились карточки на 128 гигайбат. Т.е. место на SD можно уже не считать, так же как давно не считают RAM на десктопе, если эта RAM < 32/64 (выше нужен ксеон вместо процессора). У меня на телефоне всего несколько приложений установлено, если им нужно много места на SD - пусть будет так. Отдельные лучи поноса новым андроидам, на которых нельзя на SD ставить приложения без гемора.

убивать другие фоновые приложения, ибо они же тоже будут просить по 2 гб памяти

фоновые приложения вообще не нужны, кроме скайпа в привилегированном режиме. И такой режим нужно давать только 3,5 жизненно важным программам (типа скайпа). Да, в андроиде ПОКА такого нету, потому что он говно.

сейчас проблему можно решить удалением таких приложений.

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

По идее надо бы как-то эту либу динамическую в сам андроид засунуть.

О майн гат! Сразу в голову себе засунь!

Что за непреодолимое желание всюду влезть и централизованно испортить систему своими костылями?!

У меня нет такого желания. Просто если её не засунуть, её нужно пихать в каждый apk, её использующий, и каждый процесс, запущенный из своей apk, будет подгружать в память свою копию, а это убивает одно из преимуществ динамической линковки — экономию физической памяти.

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

это всё еще актуально?

а ты думаешь, что добавление ядер и памяти как-то сглаживает дерганый скроллинг во время срабатывания GC?

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

В анроиде так оно и есть. Даже весь C++ runtime - в каждом приложении (где он используется). Причем, даже в некоторых родных гугловых приложениях.

anonymous
()

"Pluralitas non est ponenda sine necessitate"(С)

Не нужен.

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

Ну если

String s = "";

for (int i = 0; i < МНОГО; i++) {
  s+= Integer.toString(i);
}

то «добавление ядер и памяти как-то сглаживает дерганый скроллинг во время срабатывания GC»(С) не прокатит в любом случае.

От «индусского кода»(С) нет защиты в любом случае.

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

начнем с конца: не написанные, а скопи(а местами -пижже-)ные, и это главная и единственная мажорная причина почему там есть натив. А если за игры, там гугл для того и дал НДК, что бы ресурсоёмкие задачи с ручной оптимизацией по ресурсам и памяти выполнять на нативе.

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

Разработчикам очень много чего не хватает.

Например?:) Ток давай конкретику.

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

А если за игры, там гугл для того и дал НДК, что бы ресурсоёмкие задачи с ручной оптимизацией по ресурсам и памяти выполнять на нативе.

Ну вот, для етого и нужен CrystaX. Чтоб не упереться в ограничения и костыли Bionic.

eReSik ★★
()

Ребят, раз есть возможность нативной разработки, нафик тогда вообще этот Ведроид нужен?? Есть же Qt, GTk, Enlightenment.... - можно сваять свой ГУЙ и юзать смарт как удобно, а не как решил гугля. Что этому мешает?

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

есть возможность нативной разработки

как удобно, а не как решил гугля.

Может быть это сабжем и обеспечивается.

ados ★★★★★
()

На сайте .NET сильно выделяется.

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

А если ты предлагаешь вообще от ведроида отказаться, то дядя Ляо из Китая болт клал на поддержку GNU/Linux в своих устройствах.

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

болт клал на поддержку

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

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

Ненене, давай ЛИЧНО твой список ограничений и костылей бионика который лично ТЕБЕ мешает что-то реализовать.

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

да-да, языком ляпать, не мешки ворочать да? Признайся уже чесно что ты, лично ты, не знаешь ни одной проблемы, ни одного костыля. Ведь так?

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