LINUX.ORG.RU
ФорумTalks

Взлетит ли?

 , ,


0

2

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

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

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

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



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

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

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

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

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

JackOfShadows
()

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

TheAnonymous ★★★★★
()
Ответ на: комментарий от 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 ★★★★★
()
Ответ на: комментарий от TheAnonymous

Тулкитофоб?

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

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

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

EXL ★★★★★
()

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

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

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

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

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

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

Отличная идея, монетизируй ее!

ozzee
() автор топика
Ответ на: комментарий от 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 ★★★★★
()
Ответ на: комментарий от andreyu

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

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

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

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

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

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

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