LINUX.ORG.RU
ФорумTalks

Взлетит ли?

 , ,


0

2

Кажется я понял, что хотели донести до нас разработчики говнаандроида(dalvik) и почему в обычные звонилки пихали JavaME вместо другой реализации. Некие универсальные API. Хочешь создать приложение, которое работает через интернет? Просто подключи модуль в джаве а не читай тонны документации именно к твоему аппарату.

И у меня возникла мысль. Что если сделать все нативно, но с возможностью использовать те же самые API? Т.е. чтобы возможно было подключить тот или иной модуль как в андроиде, только реализация была нативной, вроде бинарников в лине. Предположим, что имеем некоторую IDE. В ней можно подключить нужный модуль, как в джаве import java.что-то-там(я не помню как правильно пишется). Оно будет использоваться не только при компиляции(точнее при компиляции оно роли играть не будет особо), но активно использоваться в системе на смартфоне. То есть мы подключили модуль камеры к примеру и приложение будет взаимодействовать с ней везде на устройствах с нашей системой.

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

Я не говорю взяться за это и делать НашуОС, просто возникла такая мысль.


Ответ на: комментарий от JackOfShadows

Не, я говорю про изначально нативную компиляцию.

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

А разница между компиляцией в момент установки и изначальной компиляцией?

JackOfShadows ()

И таки в андроиде не javame а dalvik, правда сейчас который заменен на openjdk (который se)

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

Я не писал в что в андроиде джава. Но надо бы уточнить, да.

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

Будешь каждую программу компилировать для arm, arm64, mips, mips64, ppc, ppc64, x86, em64t, ia64 и кучи других?

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

Кросскомпиляция, не? Или как это называется правильно?

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

Твой метод предполагает толстейшие бинарники со всеми архитектурами и потерю обратной совместимости, но ради чего?

JackOfShadows ()

Чем изначально нативный код, например, для сферического x86 (intel 80386, год выпуска 1985) лучше, чем результат работы JIT/AOT компилятора?

TheAnonymous ★★★★★ ()

Это уже давно было.

man Qtopia

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

ART что-то не спасает от тормозов Java. Как тормозило всё при Dalvik, так тормозит и при Art.

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

и кучи других?

Ты разрабатывал хоть раз NDK-приложение для Android?

Если в Android.mk выставить:

APP_ABI := all
APP_PLATFORM := android-9

Собираются библиотеки под следующие архитектуры: http://wstaw.org/m/2016/06/07/Screenshot_20160607_105420.png

Никаких PowerPC и Itanium'ов там нет.

Но большинство разработчиков такой фигнёй не маются и выставляют просто:

APP_ABI := armeabi armeabi-v7a x86
APP_PLATFORM := android-9

Забивая на всё остальное, ибо обратная совместимость armeabi->armeabi-v7a->arm64-v8a и x86->x86_64 присутствует.

На MIPS'ах Android-устройств катастрофически мало, на MIPS64 до сих пор вроде так и не появились. Ими можно пренебречь.

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

А потом какой-нибудь один калькулятор на Qt занимает 999 мегабайт

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

Тулкитофоб?

Я вообще не понял, зачем ты приплёл сюда Qt, на котором 2-4 приложения из всего числа Android-приложений.

Ну и специально для таких случаев тоже есть хинт: вместо объёмного APK-пакета, содержащего нативные библиотеки с кодом для всех популярных архитектур, можно сделать кучу маленьких APK-пакетиков.

То есть было: MySuperGame-all.apk, а стало MySuperGame-x86.apk, MySuperGame-armeabiv7a.apk, MySuperGame-armeabi.apk и т. д.

EXL ★★★★★ ()

Посмотри на Tizen. Там вроде C++.

dimss ★★★★★ ()

Я можт рано утром туго догоняю что ты написал, но унификация, как софта так и железа, для arm - это спасение. Писал и дрова и приложения - это был ппц

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

Посмотри на Tizen. Там вроде C++.

Plain C и JavaScript в публичных релизах официально.

На C++ можно писать, но с тем же успехом можно писать на чём угодно, что можно запаковать в RPM и сбиндить с EFL под Wayland.

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

А потом какой-нибудь один калькулятор на Qt занимает 999 мегабайт

А при чем тут Qt?

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

Осталось догадаться, причём тут Android.

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

Да, очень. Там как и в Android, были специальные qpk-пакеты, которые имели свою песочницу для выполнения.

И главное, аппаратные требования для смартфона были в 2 раза меньше, чем у первых версий Android.

Под Qtopia с полпинка собирался и опакечивался обычный GNU/Linux софт:

http://forum.motofan.ru/index.php?showtopic=154315
http://forum.motofan.ru/index.php?showtopic=169113

Портирование Qt-приложений и SDL-приложений не представляло особых затруднений.

Увы, но менеджеры в Trolltech решили, что они чисто software-компания и прекратили разработку, а потом и вовсе Nokia отдались, которая выкинула Qtopia на мороз.

EXL ★★★★★ ()

Что это даст? Ну хотя бы просто огромный прирост производительности(а может и не огромный, но по сравнению с выполнением кода в виртуальной машине и выполнением нативно разница будет ощутима)

В контексте мобильных приложений – это не более, чем миф.

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

Софт обычно компилируется в нативный код

Повторю свой вопрос - А при чем тут Qt?

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

Забей, тулкитофобу лишь бы брякнуть. Ненависть у него этот самый Qt вызывает, вот и пишет что попало.

Я на Qt вообще только пару приложений для Android видел. Самое популярное - 2GIS.

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

Golang
Но проблема есть одна - кроссплатформа

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

не на openjdk, а классы только
вот сама реализация виртмашины - это от гугла
только раньше был JIT, теперь (с 5.0) AOT
Ну и вроде планируют снова JIT вернуть, с ним быстрее было

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