Seid ein paar Tagen ist ja die neue QT5.2.0 raus mit der sich auch Programme fuer Android erzeugen lassen. Damit kann man sich dann diesen unsaeglichen Java-Muell schenken und endlich C++/Qt nutzen. Ich hab es bei mir unter SL6.4 installiert und hab dafuer zwei Nachmittage gebraucht. Ich dachte mal jemand koennte sich fuer meine Notizen interessieren um sich etwas Zeit zu sparen. :-) Ich vermute die Anleitung funktioniert genauso unter Centos und Redhat. ------------------------------------------------------------------- Die /lib/libz war veraltet. Ich hatte noch eine Version wo sich die Versionsnummer nicht auslesen liess. Auf /lib/libz.so.1.2.8 upgedatet. Es fehlte noch eine modernere Version der Standard-C libary. Das Problem ist wohl das ScienticLinux/Redhat 6.4 eher konservativ sind und nicht die modernste Libary verwenden. Aus dem Internet ein anders Paket besorgt und das hier installiert: /usr/local/libstdc++.so.6.0.17 Die Alternative dazu waere wohl den System-gcc auf den neuesten Stand zu bringen. Seufz! Warum nur muessen die Maintainer immer nur die neuesten Kisten fahren und probierne ihre Sachen vor dem Release nicht einmal auf ein paar ueblichen Produktionsystem aus. Es gab bei mir noch ein Problem mit den Tastatureingaben. Genauer gesagt hat Qt keine Eingaben akzeptiert. Ursache ist wohl irgendein Bug in Qt bei der Umstellung von xlib nach xcb. Zur Loesung hab ich mir qxkb installiert und damit eine andere Tastatur ausgewaehlt. Damit geht es: xprop -root |grep -i xkb _XKB_RULES_NAMES(STRING) = "evdev", "pc104", "us", "", "terminate:ctrl_alt_bksp" Vorher stand da bei mir was von "pc105+int" Aber hier die eigentliche Installation. Ich installiere hier in meinem Home-Verzeichnis. Das ist eigentlich Scheisse. Es sollte sich auch nach /usr/local/ installieren lassen. Es gibt dann aber ein Paar Probleme mit den Rechten. Eventuell muesste man dann eine neue Gruppe anlegen und dort die Installation und die User aufnehmen. cd ~/sources/Android /opt/SAVE.SAVE/Linux/QT/QT5.2/qt-linux-opensource-5.2.0-android-x86-offl ine.run Dort dieses Zielverzeichnis angeben:/home/olaf/sources/Android/Qt5.2.0 Danach immer auf WEITER klicken bis er installiert. Dann erstmal den qtcreator beenden. Verzeichnis fuer meine Projekte: mkdir ~/sources/Android/Qt5.2.0_Projekte cd ~/sources/Android/Qt5.2.0 tar -xJf /opt/SAVE.SAVE/Linux/QT/QT5.2/android-ndk-r8e-ma-linux-x86.tar.xz unzip /opt/SAVE.SAVE/Linux/QT/QT5.2/adt-bundle-linux-x86-20131030.zip ./Tools/QtCreator/bin/qtcreator Neues Projekt anlegen. [Name z.B: TestProjekt1] Als Kit "armeabi-v7a (GCC4.7, Qt 5.2.0)" auswaehlen Details aufklappen und etwas kluegere Namen auswaehlen. Beispiel: /home/olaf/sources/Android/Qt5.2.0_Projekte/Debug/TestProjekt1 Macht man das nicht muellt einem die Oberflaeche das Verzeichnis mit kranken Namen zu. Eine Ablage innerhab des eigenen Projektes ist nicht moeglich. <seufz> Eventuell muss man noch die Pfade auf NDK und SDK setzen: [Tools][Options][Android] /home/olaf/sources/Android/Qt5.2.0/adt-bundle-linux-x86-20131030/sdk /home/olaf/sources/Android/Qt5.2.0/android-ndk-r8e Sollte die Oberflaeche auf Deutsch verwendet werden dann darauf achten das keine deutschen Sonderzeichen im File oder Directorynamen vorkommen. Das ist sehr wichtig! Auf den [Hammer] klicken. Das Projekt sollte fehlerfrei uebersetzt werden. Es wird dabei die Datei [libTestProjekt1.so] erzeugt. Das ist unser eigentliches Programm! Auf den [gruenen Pfeil] klicken. Jetzt sollte ein Handyemulator gestartet werden. Dabei muss man den Typ seines Device angeben. Das koennte man eventuell auch noch vorher erzeugen. Interessanterweise scheint sich die Oberflaeche irgendwie die Einstellungen aus einer vorheringen Installation zu merken! Es kommt folgende unerklaerliche Fehlermeldung: 19:55:09: The process "/usr/bin/make" exited normally. 19:55:09: Starting: "/usr/bin/make" INSTALL_ROOT=/home/olaf/sources/Android/Qt5.2.0_Projekte/Debug/TestProje kt1/android-build install install -m 755 -p "libTestProjekt1.so" "/home/olaf/sources/Android/Qt5.2.0_Projekte/Debug/TestProjekt1/android- build/libs/armeabi-v7a/libTestProjekt1.so" 19:55:09: The process "/usr/bin/make" exited normally. Error while building/deploying project TestProjekt1 (kit: Android for armeabi-v7a (GCC 4.7, Qt 5.2.0)) When executing step 'Deploy to Android device' 19:57:55: Elapsed time: 02:46. Aus noch unbekannten Gruenden laeuft also der Emulator bei mir nicht. Das hat aber nichts mit der APK-Erzeugung zutun! Hier wird erklaert wie die Paketerzeugung funktioniert: http://blog.qt.digia.com/blog/2013/10/09/android-deployment-in-qt-5-2/ Das erzeugt uns unser Paket! /home/olaf/sources/Android/Qt5.2.0/5.2.0/android_armv7/bin/androiddeploy qt --output android-build/ /home/olaf/sources/Android/Qt5.2.0_Projekte/Debug/TestProjekt1/android-b uild/bin/QtApp-debug.apk Es geht! Das APK laeuft auf dem XperiaZ! Und noch was, Qt speichert irgendwo im System alte Einstellungen ab. Wenn man vorher Necessitas drauf hatte kann es sein das an der einen oder anderen Stellen Vorgaben uebernommen werden. Genau pruefen was fuer Build-Kits das System anbietet! Olaf
Olaf schrieb: > Seid ein paar Tagen ist ja die neue QT5.2.0 raus mit der sich auch > Programme fuer Android erzeugen lassen. Damit kann man sich dann diesen > unsaeglichen Java-Muell schenken und endlich C++/Qt nutzen. Full ack Olaf. Ich würde Dir dankbar sein, wenn du einen Wiki Artikel daraus machst, damit man diesen Beitrag besser findet, Vielen Dank im voraus, Fabian. P.s: wenn auxh nicht trotzdem Danke für den Beitrag :-)
> Ich würde Dir dankbar sein, wenn du einen Wiki Artikel daraus machst,
Tut mir leid, aber ich gehoere zur Generation Emacs. :-)
BTW: Im Vergleich zu Necessitas merkt man deutlich das es mit Android/Qt
vorran geht. Hier und da hakelt es noch etwas, aber so im grossen und
ganzen finde ich es jetzt ganz nett.
Oh..und wenn man vorher viel mit Eclipse rumgemacht hat dann ist der
QTcreator sicher etwas gewoehnungbeduerftig, aber man hat die ganze Zeit
ein Laecheln auf dem Lippen weil er VIEL schneller ist.
Olaf
Olaf schrieb: >> Ich würde Dir dankbar sein, wenn du einen Wiki Artikel daraus > machst, > > Tut mir leid, aber ich gehoere zur Generation Emacs. :-) > > BTW: Im Vergleich zu Necessitas merkt man deutlich das es mit Android/Qt > vorran geht. Hier und da hakelt es noch etwas, aber so im grossen und > ganzen finde ich es jetzt ganz nett. Was stört dich denn an Necessitas? Ich nutze es auch, und es läuft eigentlich sehr gut. Die von dir angesprochenen Installations-Eskapaden habe ich damit auch nicht gehabt. > Oh..und wenn man vorher viel mit Eclipse rumgemacht hat dann ist der > QTcreator sicher etwas gewoehnungbeduerftig, aber man hat die ganze Zeit > ein Laecheln auf dem Lippen weil er VIEL schneller ist. Ich nutze vim, da ich den auch für alles andere verwende. Der ist mir schnell genug. ;-)
Olaf schrieb: > Tut mir leid, aber ich gehoere zur Generation Emacs. :-) Ich übrigens auch, aber warum sollte das ein Hinderungsgrund für einen Wiki-Artikel sein? Wenn du den Emacs im Firefox als Texteditor (statt des unsäglich primitiven eingebauten Editors) benutzen willst, dann sieh' dir mal das "Itsalltext"-Plugin an. Dann kannst du auch den Wiki-Artikel im Emacs editieren. ;-)
> Was stört dich denn an Necessitas? Garnichts. Ich fand es super. Aber man merkt das Qt5.2 eine Weiterentwicklung ist. Die Ecken und Kanten sind jetzt besser gepolstert. :-) > Die von dir angesprochenen Installations-Eskapaden > habe ich damit auch nicht gehabt. Ich auch nicht. Und wirst du mit einer anderen Distribution vielleicht auch nicht haben wenn es zufaellig die ist mit der Qt entwickelt wurde. > Ich übrigens auch, aber warum sollte das ein Hinderungsgrund > für einen Wiki-Artikel sein? Ich habe es noch nicht verstanden wie ich hier bei mir auf meinem Rechner einen Artikel schreiben soll und zwar so das ich hier bei mir alles machen kann und es dann spaeter komplett irgendwo hochlade. Ich moechte ueber das was ich schreibe selber die Kontrolle behalten bis es fertig ist. Ich moechte z.B auch ueber einen laengeren Zeitraum an einem Text basteln koennen ohne das jemand anderes den zwischendurch sehen oder gar bearbeiten kann. Sollte das moeglich sein, dann schreib doch einen Wiki-Artikel der es mir erklaert. :-) Allerdings denke ich sowieso das das was ich hier beschrieben habe eine ganz gute Hilfe fuer jemanden sein kann der zufaellig auf eines der Probleme stoesst das ich auch hatte, wegen der starken Diversifikationen der einzelnen Linuxsysteme aber kaum von so grosser Bedeutung ist das man da ernsthaft ein paper schreiben sollte. BTW: Ich musste meine Aenderung an der libz wieder zuruecknehmen. [root@criseis lib]# l libz* lrwxrwxrwx. 1 root root 13 28. Dez 22:41 libz.so.1 -> libz.so.1.2.3 -rwxr-xr-x. 1 root root 76880 10. Dez 2011 libz.so.1.2.3 -rwxr-xr-x. 1 root root 90964 30. Nov 14:28 libz.so.1.2.8 Einige wenige Programme moegen die neue libz naemlich nicht und werfen dann errors in /var/log/messages: segfault at 0 ip 006ff451 sp bfc091bc error 4 in libc-2.12.so[67f000+190000] Eines dieser Programme ist gdm. Das ist dann der Grund warum ihr am naechsten Tag beim booten vor verschlossener Tuer steht. :-) Leider laeuft Qt5.2 mit der alten Version zweifelhaft. Die Compilierung laeuft zwar ohne Fehler durch, aber man bekommt das hier in den Issues: /lib/libz.so.1: no version information availailable (required by /home/olaf/sources/Android/Qt5.2.0/android-ndk-r8e/toolchain/arm-linux-a ndroideabi-4.7/prebuilt/linux-x86/bin/../lib/gcc/arm-linux/androideabi/4 .7/../../../../arm-linux/andoideabi/bin/ld) Man kann das also vielleicht ignorieren, was fuer sich genommen ja auch schonmal eine interessante Information ist wenn man ein solches System bei sich installiert. Ich hab im uebrigen auch mal probiert es bei mir mit dem android-ndk-r7c ans laufen zu bekommen, aber es nicht geschafft. (weiss den Grund nicht mehr) Von daher koennte das Problem auch andere Leute betreffen wenn ihr System nicht auf gcc4.7 laeuft. Leider wird einem aber auch klar wieso SF/Redhat noch nicht umgestiegen sind. Das Problem betrifft naemlich nicht nur gdm. (da wird es nur zuerst deutlich) vermutlich muesste man sein halbes System neu compilieren. Mein system basiert noch darauf: [olaf] ~: gcc --version gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-3) Olaf
> Was stört dich denn an Necessitas?
Was ich nochmal vertiefen sollte...
Der Grund warum ich modernisiert habe ist die Hoffnung auf neue
Featuere, insbesondere der Integration von Bluetooth und der seriellen
Libary.
Eine noch offene Frage ist dann wie einfach es wird mit meinen Xperia
Z-Tablett ueber ein BTM222 auf externe Hardware zuzugreifen.
Olaf
Olaf schrieb: >> Ich übrigens auch, aber warum sollte das ein Hinderungsgrund für einen >> Wiki-Artikel sein? > > Ich habe es noch nicht verstanden wie ich hier bei mir auf meinem > Rechner einen Artikel schreiben soll und zwar so das ich hier bei mir > alles machen kann und es dann spaeter komplett irgendwo hochlade. Ich > moechte ueber das was ich schreibe selber die Kontrolle behalten bis es > fertig ist. OK, einen Offline-Wiki-Renderer kenne ich allerdings auch nicht. Wenn du das unbedingt so machen willst, dann würde das wohl nur gehen, indem du dir ein eigenes MediaWiki irgendwo hinlegst, dort den Artikel in Ruhe zu Ende bearbeitest und dann erst hochlädst.
Etwas off-topic, aber passt vielleicht hier gut rein: Man kann verschiedene Versionen von folgender Webseite laden: http://qt-project.org/downloads Wenn man QT 5.2.0 Variante x bereits installiert hat, kann man dann QT 5.2.0 Variante y einfach dazu installieren? Ich habe z.B. bereits QT 5.2.0 (64 Bit, Windows) installiert, um Windows-Applikationen damit zu entwickeln. Kann ich mit jetzt einfach QT 5.2.0 for Android installieren oder macht das Probleme? Eine kleine Steigerung meiner Frage: QT 5.2.0 für Windows (unter Windows) ist 64 Bit, QT 5.2.0 für Android (unter Windows) gibt es scheinbar nur als 32 Bit. Kann man damit eigentlich auch Cross-Compilen? Also unter Windows ein Linux-Binary erzeugen? Oder unter Linux ein Windows-Binary erzeugen? Ist ebenso auch ein Mac-Binary unter Windows erzeugbar?
Ingo P. schrieb: > Also unter Windows ein Linux-Binary erzeugen? Ich kenne zumindest keinen Cross-Compiler, den es dafür fertig gäbe. Grundsätzlich machbar sollte es sein. > Oder unter Linux ein Windows-Binary erzeugen? MinGW32 gibt es für unixoide Betriebssysteme als Cross-Compiler, und ich habe damit erfolgreich AVRDUDE compiliert (klappt sowohl unter Linux als auch FreeBSD). Qt unterstützt offiziell MinGW, aber der Crosscompiler wird zumindest nicht offiziell unterstützt. Wird also darauf hinauslaufen, dass man ggf. mit der Hand irgendwo nachhelfen muss. > Ist ebenso auch ein Mac-Binary unter Windows erzeugbar? Cross-Compiler für OSX ist mir auch erstmal nicht bekannt. Der Compiler selbst wäre wohl nicht das Problem, aber die Bibliotheken.
> Kann man damit eigentlich auch Cross-Compilen? > Also unter Windows ein Linux-Binary erzeugen? > Oder unter Linux ein Windows-Binary erzeugen? Ich habe keine Ahnung von Windows, aber grundsaetzlich sollte es moeglich sein da ja die Androidcompiler auch alles Crosscompiler sind. Man muesste sich dann halt einfach noch einen passenden Crosscompiler uebersetzen und da einbinden. Es ist jedenfalls sehr einfach moeglich ein Android-QT programm mit einem anderen Kit zu uebersetzen und dann unter Linux laufen zu lassen. BTW: Noch ein Hinweiss der mir leider etwas verspaetet aufgefallen ist. Man sollte wohl zuerst mal das Kleingedruckte lesen, seufz. Die neue QT5.2 unterstuetzt grundsaetzlich so Sachen wie Bluetooth und die Libary zu Abstraktion der seriellen Schnittstelle, aber sie tut dies noch nicht unter Android. Damit ist Qt5.2 ziemlich unbrauchbar solange man nicht libusb auf sein Zielsystem portiert und native anspricht. Olaf
Auf der Seite http://blog.qt.digia.com/blog/2013/10/09/android-deployment-in-qt-5-2/ wird ein Tool androiddeployqt aufgerufen. Dieses ruft dann wiederum (zumindest unter Windows) das Tool "ant" auf. Ant möchte ein build.xml haben, welches die Windows QT Version für Android aber scheinbar (noch) nicht erzeugt. Kannst du mal schauen, ob bei dir (vermutlich im Deploy-Verzeichnis) eine build.xml existiert und evt. hier hochladen? Alles zusammengenommen ist die Installation von QT 5.2.0 für Android unter Windows noch eine riesige Aktion. Nix mit Out-of-the-Box. QT 5.2.0 für Windows (Windows) geht da viel besser. Vermutlich weil die Android-Version einfach noch zu neu ist... Gibt es für Linux/Windows von QT eigentlich keine How-To, wie man das ganze installiert, was man dazu alles braucht, usw.?
:
Bearbeitet durch User
Olaf schrieb: > Seid ein paar Tagen ist ja die neue QT5.2.0 raus mit der sich auch > Programme fuer Android erzeugen lassen. Damit kann man sich dann diesen > unsaeglichen Java-Muell schenken und endlich C++/Qt nutzen. Ich finde C++ mit Qt auch besser. Was allerdings an Java so dermaßen furchtbar sein soll, verstehe ich nicht.
> eine build.xml existiert und evt. hier hochladen? Klar. Nicht das ich jetzt wuesste wer die genau wann im Build-Prozess erzeugt, aber es wundert mich das die bei dir nicht erzeugt wird. Ich denke doch das mal jemand einen Build ausprobiert hat bevor sie die Windowsversion released haben. > Gibt es für Linux/Windows von QT eigentlich keine > How-To, wie man das ganze installiert, > was man dazu alles braucht, usw.? Das habe ich ja fuer Linux im Prinzip beschrieben. Allerdings ist sowas bei Linux mit Vorsicht zu geniessen weil sich die Distributionen unterscheiden. Es gibt bestimmt auch Leute wo es einfach so funktioniert. Wenn alles gut laeuft muss man nur das QT-Script starten, danach SDK/NDK darin auspacken und ist fertig. Aber es ist schon noch wichtig das man versteht was unter der Motorhaube passiert. Der ganze Buildprozess hat noch so einige Macken. > Was allerdings an Java so dermaßen furchtbar sein soll, verstehe > ich nicht. Alles was ich bisher gesehen habe das mit Java gemacht war, war total lahm. Auf einem PC nervt das nur, auf einem tragbaren Device kostet das Akkulaufzeit. Ein Sharp Zaurus (400Mhz) mit QTopia/QTembedded fuehlt sich meistens schneller an als mein Handy mit xGhz und 4xCPU. Olaf
Olaf schrieb: > Alles was ich bisher gesehen habe das mit Java gemacht war, war total > lahm. So groß sollte der Unterschied jetzt aber eigentlich nicht sein. Wird ja schließlich in beiden Fällen nativ für das Gerät kompiliert, oder? Der Overhead zur Laufzeit sollte eigentlich kaum ins Gewicht fallen... Um Google zu zitieren: The NDK will not benefit most applications. As a developer, you need to balance its benefits against its drawbacks; notably, using native code does not result in an automatic performance increase, but always increases application complexity. In general, you should only use native code if it is essential to your application, not just because you prefer to program in C/C++. Ach ja: Und natürlich seid ihr damit nicht Platform unabhängig. Android läuft ja auf verschiedenen Prozessoren (x86 ist ja im Kommen), was für Java/Dalvik kein Problem darstellt. Eine C++-App wird nur auf einer einzigen Platform laufen...
:
Bearbeitet durch User
Olaf schrieb: >> Was allerdings an Java so dermaßen furchtbar sein soll, verstehe >> ich nicht. > > Alles was ich bisher gesehen habe das mit Java gemacht war, war total > lahm. Beim Starten: Ja, sicher, wegen des Ladens der ganzen Klassen. Bei der eigentlichen Ausführung: Wahrscheinlich eher nicht, da Java hier in vielen Fällen vergleichbar schnell ist wie in C oder C++ geschriebene Programme. Aus dem entsprechenden Wikipedia-Artikel: http://en.wikipedia.org/wiki/Java_performance#Comparison_to_other_languages "Results for microbenchmarks between Java and C++ highly depend on which operations are compared. For example, when comparing with Java 5.0: -32 and 64 bit arithmetic operations, File I/O and Exception handling have a similar performance to comparable C++ programs. -Arrays operations performance are better in C. -Trigonometric functions performance is much better in C."
Angehängte Dateien:
Ok, mittlerweile habe ich auch eine erste Android App mit QT 5.2.0 unter Windows erzeugt. Diese sieht jetzt aus wie im Anhang. !!!Vorsicht: QT Anfänger!!! Im QT-Creator sind die Texte alle innerhalb der Buttons, auf meinem Nexus 7 sieht es dann aus wie im Screenshot. Ist das etwas, was man einstellen kann (z.B. dpi oder automatische Anpassung) oder muss man sich in der App selbst darum kümmern?
Angehängte Dateien:
Hier noch der Screenshot, wie es unter Windows aussieht... (Sorry für die vielen gleichen Bilder oben, das Forensystem ist hier nicht so durchsichtig, ob jetzt ein Bild dabei ist oder nicht. Moderator: Vielleicht kann man alle außer dem 1. Bild im vorigen Beitrag löschen)
:
Bearbeitet durch User
> Ist das etwas, was man einstellen kann > (z.B. dpi oder automatische Anpassung) > oder muss man sich in der App selbst darum kümmern? Darauf bin ich auch schon gestossen. Grundsaetzlich kannst du ja die Schriftgroesse im Creator auch einstellen und es damit hinbekommen. Allerdings ist das Deviceabhaengig und damit natuerlich bloed. Ich denke daher auch das dies entweder ein Programmierfehler oder ein Designfehler ist. Olaf
Ich habe dies gestern mal als Bug gemeldet https://bugreports.qt-project.org/browse/QTBUG-35960 und heute folgende Antwort erhalten: " Jens: The problem is that you have not actually used a layout. By default Creator/Designer will simply save the sizes and positions of items (in this case based on windows default sizes) without regard to their internal size hints. The android device has a much larger font and DPI resolution than your windows system, which is why you have to put all the widgets in actual layouts such as vertical, horizontal, grid or form layouts in order for the items to adapt to different screen sizes. "
Angehängte Dateien:
Kurze Rückmeldung: Wenn man ein Layout ergänzt (ich hab die ganzen UI-Elemente in ein gridLayout kopiert), dann sind die Buttons/Texte richtig.
> Wenn man ein Layout ergänzt (ich hab die ganzen UI-Elemente in ein > gridLayout kopiert), dann sind die Buttons/Texte richtig. Interessant, ich war eigentlich der Meinung auch ein Layout erzeugt zu haben. Aber ich hab auch irgendwo gelesen das da noch etwas buggy sein soll. Muss ich wohl nochmal reinschauen. Jetzt koennte man im Prinzip ja mit dem System arbeiten, tja wenn man halt auch mal Hardware ansprechen koennte. Schliesslich ist das ja ein Hardwareforum. Aber so wie ich das sehe gibt es da nur zwei Moeglichkeiten. Entweder warten bis es irgendwann in QT integriert ist, oder die libusb integrieren. Letzeres aber vermutlich mit dem Nachteil das ein Programm immer root-Priviligen braucht. Oder uebersehe ich da etwas? Olaf
Der grafische Widget Designer ist nur für "normale" PC Bildschirme mit ca 100dpi Auflösing gedacht. Für Android Handies eignet sich der Editor kaum. Bei QML soll es besser sein, ich hab QML aber noch nie verwendet. Ich bin inzwischen dazu über gegangen, die Widgets durch C++ Quellcode zu erstellen. Dann erscheinen fast alle Sache automatisch zufriedenstellend, man muss nichtmal Höhe und Breite angeben. Layouts sind auf jeden Fall Pflicht, damit sich die Fenster an unterschiedliche Bildschirmghrößen anpassen. Icons und Bilder skaliere ich relativ zur Schriftgröße (analog zur Einheit "em" in Webseiten). Inzwischen habe ich auch Bluetooth hinbekommen: http://stefanfrings.de/android_qt/index.html Wegen der Performance: - Qt Programme starten viel langsamer, als Java Programme. Logisch, denn die Java Libraries werden ja schon vorher beim Booten des Gerätes geladen. - Qt Programme belegen viel mehr RAM, weil sie Qt Libraries nachladen müssen. - Ich gehe davon aus, dass C/C++ Programme unter Android viel schneller laufen, weil die Java VM nicht sonderlich ausgefuchst ist. Die Java VM von Oracle ist gefühlt 5x schneller, als die Dalvik VM in Android. - Allerdings werden die meisten Programme eher von I/O ausgebremst, so dass die Rechenleistung weit weniger wichtig ist, als oft behauptet. Ich bevorzuge Qt, weil meine Programme damit auch auf dem Desktop laufen können.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.