Hallo, ich wollte mal einen Android-Insider fragen wieso Android Apps vergleichsweise (oder für die Funktion die sie bieten) so unglaublich viel Speicher brauchen. z.B. Telegram App. Ohne die Daten die die App sonst speichert 41 MB. Das ist einfach nur ne Messenger App die zum Großteil eh auf Zeugs vom System aufbaut. Wie kommt man da auf so viel Speicher? Genauso die Spotify App mit 170MB. So viel braucht Spotify nichtmal auf meinem Desktop. Vielleicht kann mal jemand aufklären woran das liegt. Danke
:
Verschoben durch User
Ich weis jetzt auch nicht woran das liegt, aber wenn du dir mal die Facebook-App anschaust, erscheint der Speicherfraß deiner genannten Apps vernachlässigbar. Umso erstaunlicher ist, dass der Speicher bezahlbarer Smartphones und Tablets immer noch ziemlich mikrig ist.
In einem Fall ist mir der Grund bekannt. Bei einem Küchentimer, der die Restzeit links oben in der Statusleiste anzeigt. Die App selbst ist eigentlich recht, aber ... Im Prinzip sind das einfach bloss Ziffern, die runterzählen. Toteinfach also. Denkste. Geht nämlich nicht so einfach. In der Statusleiste sind nur Icons möglich. Also enthält die App hunderte einzelner Icons, je eines für 59min, 58,5min, 58min, ..., 59sec, 58sec, ...
:
Bearbeitet durch User
Ja jetzt kommen gleich wieder Einwände dass doch niemand mehr Facebook nutzt und man die App und den Messenger ohnehin nicht braucht... Trotzdem steigen die Nutzerzahlen, auch in Deutschland, ständig.
alf schrieb: > Umso erstaunlicher ist, dass der Speicher bezahlbarer Smartphones und > Tablets immer noch ziemlich mikrig ist. Findest du? Moderne Geräte haben doch heute teils schon 3 oder 4 GB RAM und kommen mit 64 Bit, weil man sonst den ganzen Speicher gar nicht mehr angesprochen kriegt. Auf einem PC kann man damit erheblich mehr anfange als auf dem Handy. Ich hab mich auch schon gefragt, warum meine Taschenlampen-App, die nix macht, ausser einen Button anzuzeigen, mit dem man das Fotolicht an oder aus machen kann, 2 MB braucht, also mehr als 30 mal soviel, wie ein C64 insgesamt hatte.
Android Apps sind Java-Applikationen (die so etwas wie shared Libraries z.B. nicht kennen). Somit schon "per Design" umfangreicher als unbedingt notwendig. Falls sie sich ein bisschen flotter bewegen sollen, bringen sie u.U. nativen Code in Form eines C/C++ Kompilats für JNI mit. Und weil das unabhängig vom tatsächlich verbauten Prozessor funktionieren soll, liegt der JNI-Code u.U. noch für mehrere Prozessoren vor. ... aber was hat das mit Compilern und IDEs für µC zu tun?
Markus F. schrieb: > Android Apps sind Java-Applikationen (die so etwas wie shared > Libraries > z.B. nicht kennen). Somit schon "per Design" umfangreicher als unbedingt > notwendig. Jein. Die Android VM läd einen Haufen Klassen (mehrere tausend Systemklassen) vorauseilend beim Booten. Ein Grund warum Android so langsam bootet ... Jede App die ausgeführt wird erhält eine copy-on-write Referenz auf die vorauseilend geladenen Klassen. Das heißt, alle Apps teilen sich erst einmal ein und den selben Satz der Systemklassen. Nur wenn eine App eine dieser Klassen benutze und die Benutzung zu einer Schreibaktion führt, wird der betroffene Speicherbereich für diese App kopiert (copy-on-write). Das heißt, die Systemklassen verhalten sich wie Shared Libraries.
Was mich beim Speicherbedarf unter Android wundert: Die eigentliche apk ist einige hundert kB groß, nach Start veranschlagt sie aber im Speicher mehrere MB. Wieso? (ist mir bei unterschiedlichen Anwendungen aufgefallen)
Markus schrieb: > Was mich beim Speicherbedarf unter Android wundert: > Die eigentliche apk ist einige hundert kB groß, nach Start veranschlagt > sie aber im Speicher mehrere MB. Wieso? Weil das falsch gezählt wird. Die JVM und Systemklassen die das Betriebssystem schon mitbringt, werden halt für jede laufende App einzeln mitgezählt, auch wenn sie in Wirklichkeit geteilt sind und der Linux-Kernel darunter das schön säuberlich mit COW auseinanderfizzelt. Aber natürlich ist die Verwendung einer JVM an sich schon Bloat ohne Ende und ein Grund dafür, warum ein Smartphone heute zwanzigmal so viel Speicher und hundertmal soviel Rechenleistung braucht wie ein C64.
Jay schrieb: > Nur wenn eine App eine > dieser Klassen benutze und die Benutzung zu einer Schreibaktion führt, > wird der betroffene Speicherbereich für diese App kopiert wie meist du das? Klassen können doch gar nicht beschrieben werden. Es könne nur Objekte davon gebildet werden und ich kann mir nicht vorstellen das sich verschieden Apps Objekte sharen.
Und warum brauchen auch selbst die simpelsten Windows-Programme Megabytes? Fragen über Fragen, die man sich nicht erklären kann, vor allem, wenn man schon selbst programmiert hat! Ich habe schon bei einigen Softwareentwicklern nachgefragt, da kriegst natürlich keine Antwort! Gruss Chregu
Christian M. schrieb: > Und warum brauchen auch selbst die simpelsten Windows-Programme > Megabytes? Fragen über Fragen, die man sich nicht erklären kann, vor > allem, wenn man schon selbst programmiert hat! Notepad brauch 2Mbyte WinMerge 5Mbyte Word 2010 16Mbyte finde ich jetzt nicht wirklich viel
@ Axel Schwenke (a-za-z0-9) >Aber natürlich ist die Verwendung einer JVM an sich schon Bloat ohne >Ende und ein Grund dafür, warum ein Smartphone heute zwanzigmal so viel >Speicher und hundertmal soviel Rechenleistung braucht wie ein C64. Leider wahr :-(
"Warum brauchen Android Apps so viel Speicher?" Na weil sie nicht in Moby-Assembler programmiert sind! ;-)
Karl schrieb: > Peter II schrieb: >> Word 2010 16Mbyte > > Wo hast du die Zahl denn her? aus dem Taskmanger - kein Dokument offen Peter II schrieb: > > finde ich jetzt nicht wirklich viel > Du bist noch jung, oder? > Gruss Chregu nein, leider nicht mehr und mein erstes System hatte nur 1Mbyte Ram. Mir erschreckt aber auch der Verbrauch von Android - wozu brauch ein Handy 2GB ram, wenn einige noch mit XP und 1GB ram komplett ihre Büro machen.
Peter II schrieb: >> Wo hast du die Zahl denn her? > > aus dem Taskmanger - kein Dokument offen Das sind bei mir a) 50 MB und b) nur der verwendete Arbeitsspeicher, hat also nichts mit der Größe der Anwendung zu tun. Das Office hat bei mir 1,2 GB, was ich schon als groß bezeichnen würde.
Peter II schrieb: > Mir erschreckt aber auch der Verbrauch von Android - wozu brauch ein > Handy 2GB ram, wenn einige noch mit XP und 1GB ram komplett ihre Büro > machen. Beim PC werden Anwendungen gestartet, genutzt und wieder beendet. Vielleicht sind da auch mal ein paar gleichzeitig im Speicher, aber nie alle. Bei der vorgesehenen Nutzung von Smartphones werden Apps eigentlich nicht beendet, sondern nur verlassen. Sie bleiben dann im letzten Zustand im RAM liegen und werden weggeräumt, wenn Platz benötigt wird. Als man in Android noch entsprechende Info-Tools nutzen konnte, also vor V5, drängte sich mir der Eindruck auf, dass beim Start von Android sämtliche Apps mindestens rudimentär gestartet werden, und dann erst einmal im Speicher rumliegen.
Peter II schrieb: > Peter II schrieb: >> > finde ich jetzt nicht wirklich viel >> Du bist noch jung, oder? >> Gruss Chregu > nein, leider nicht mehr und mein erstes System hatte nur 1Mbyte Ram. Also doch jung ;-) Mein erstes System hatte gerade mal 1kB! (Sinclair ZX81)
Axel S. schrieb: > Aber natürlich ist die Verwendung einer JVM an sich schon Bloat ohne > Ende und ein Grund dafür, warum ein Smartphone heute zwanzigmal so viel > Speicher und hundertmal soviel Rechenleistung braucht wie ein C64. Die Zahlen sind deutlich zu niedrig. Realistischer wären 50.000 mal so viel Speicher und Rechenleistung wie ein C64.
Peter II schrieb: > wie meist du das? Klassen können doch gar nicht beschrieben werden. Doch, Stichwort static. > Es > könne nur Objekte davon gebildet werden und ich kann mir nicht > vorstellen das sich verschieden Apps Objekte sharen. Doch, solange sie nach der Initialisierung bei Systemstart nicht verändert werden, werden sie geteilt. Schreibt eine App, bekommt sie durch copy-on-write ihre eigene Kopie, in die dann geschrieben wird.
Jay schrieb: > Peter II schrieb: >> wie meist du das? Klassen können doch gar nicht beschrieben werden. > Doch, Stichwort static. Static wird immer initialisiert. Das erfordernd also immer ein schreibzugriff wenn die Klasse benutzt wird. Und wo kommt denn in den Systemklasse static Variablen vor?
Neulich im Supermarkt: "Oma, warum brauchen Android Apps so viel Speicher?" "Damit Google dich besser finden kann!"
Jay schrieb: >> Es >> könne nur Objekte davon gebildet werden und ich kann mir nicht >> vorstellen das sich verschieden Apps Objekte sharen. > > Doch, solange sie nach der Initialisierung bei Systemstart nicht > verändert werden, werden sie geteilt. Objekte geteilt? Das kann doch gar nicht gehen, denn Objekte haben einen Konstructor die muss immer ausgeführt werden. Und wird immer etwas geschrieben. Wenn es wirklich so ist, würde Handys nicht so viel Speicher brauchen.
Peter II schrieb: > Objekte geteilt? Das kann doch gar nicht gehen, denn Objekte haben einen > Konstructor die muss immer ausgeführt werden. Und wird immer etwas > geschrieben. Der einmal bei Systemstart ausgeführt wird. Es gibt im Android-System haufenweise Objekte, die das System beim Start erzeugt und auf die Apps später Zugriff haben. Zum Beispiel die ganzen Manager. > Wenn es wirklich so ist, würde Handys nicht so viel Speicher brauchen. Wenn du unbedingt meinst das ich lüge muss ich mir ja keine Mühe mehr mit Erklärungen geben.
Jay schrieb: > Der einmal bei Systemstart ausgeführt wird. Es gibt im Android-System > haufenweise Objekte, die das System beim Start erzeugt und auf die Apps > später Zugriff haben. Zum Beispiel die ganzen Manager. das glaube ich ja gerne, diese Objekte müssen auch nur einmal da sein - weil echte Resoucen nur einmal vorhanden sind. Aber die Manager werden auch nicht kopiert - würde ja kein sinn machen. Es sind die gleichen Objekte oder nicht? Hast du ein Beispiel für ein Objekt was ein Read-only-Clone ist und beim schreiben kopiert wird?
Peter II schrieb: > Objekte geteilt? Das kann doch gar nicht gehen, denn Objekte haben einen > Konstructor die muss immer ausgeführt werden. Und wird immer etwas > geschrieben. In Java gibt es einen ConstantPool, dieser enthält die Werte primitiver Datentypen, Strings (sind immutable), Methodennamen, Classennamen, etc. Der ConstantPool und der Code kann zur Runtime nicht verändert werden. Diesen teil muss man also nicht mehrfach laden. Ich sehe das Problem eher bei "new" und dem Garbage Collector. Ständig werden im Heap objekte Allociiert welche dann eventuell weitere Objekte Instanzieren. Das Summiert sich dann. PS: Es gibt es Libraries die den ConstantPool absichtlich verändern um die Classen zu manipulieren, und dann gibt es SecurityManager um derartiges zu Kontrollieren/Verhindern.
Da es Apps gibt die 500kB brauchen und welche mit 50MB ohne dass der Unterschied durch den Funktionsumfang erklärbar wäre vermute ich dass das nicht an Java oder Android an sich sondern mehr an der verwendeten Entwicklungsumgebung liegt.
Christian M. schrieb: > Und warum brauchen auch selbst die simpelsten Windows-Programme > Megabytes? Brauchen sie nicht. Die simpelsten Windows-Programme brauchen Kilobytes im zweistelligen Bereich, die etwas größeren im dreistelligen. Der nicht ganz triviale Dependency-Walker, beispielsweise, ist rund 500 KByte gross, die Kompaktversion des Editors SciTE 788 KByte. Android-Programme übrigens auch nicht. Vor ein paar Jahren habe ich mir Torch von Colin McDonough (https://github.com/Crossbones/android_packages_apps_Torch-OLD) selber übersetzt, weil ich eine Taschenlampen app brauchte und weil das i.W. dasselbe leistet wie Dutzende von Taschenlampenapps im Playstore, die zum Leuchten nicht nur Megabytes brauchen, sondern z.B. auch mein Adressbuch lesen können müssen. Das .apk ist 26 KByte groß, der Anwendungsmanager zeigt bei Benutzung einen Speicherbedarf von unter 60 KByte. Warum andere ziemlich einfach aussehende Programme unter Windows oder Android trotzdem Megabytes brauchen, ist vielen Fällen recht einfach zu erklären. Da werkeln halt Emulatoren und/oder Frameworks, z.T. auch mehrere übereinandergetürmt. Warum etwas neu implementieren, wenn der relevante Code oder Teile davon schon existieren, aber halt nicht in Java formuliert? Ein Beispiel. Mein Bulls&Cows-Calculator (https://play.google.com/store/apps/details?id=de.mystrobl.mmcalc1) ist im Grunde nicht mehr als eine Grafik, hinter der ein ziemlich trivialer Algorithmus (ein Mastermind-Solver) werkelt. Das Ganze ist eine Simulation eines Programms, das ursprünglich in einem PIC 16F84 ablief, also mit 2 K Worten Programmspeicher und 68 Bytes RAM auskam. Warum ist das .APK unter Android dann 3 MByte groß (Faktor 1500) und braucht im Betrieb dann sogar Speicher in erschreckend hohem Umfang, nämlich fast 10 MByte? Ganz einfach, das ist gar keine Java-Anwendung, das ist eine Python-Anwendung, die sich der Pygame-Library bedient, um das GUI zu realisieren. Also muß der Python-Interpreter (ein C-Programm, das mit Mitteln des NDK in in ARM-Code übersetzt wurde, nebst seinen div. Supportlibraries, soweit sie benutzt wurden) mit in das .apk hineingepackt werden, sowie natürlich auch die Pygame-Library. Der wesentliche Teil, der Mastermind-Solver nebst der GUI-Logik (also Interpretation der Tasten und das Zeichnen der Segmente), ist ein lediglich 8 KByte großes Script bzw etwa 5 KB in der in Python-Bytecode übersetzten Form, sowie ein Font (88 KByte), diverse Grafik (zusammen rund 400 KByte) und ein Midi-File (145 Byte). Warum das dann aber zehn MByte braucht und nicht nur drei (oder sechs), läßt sich auch erklären, dafür müsste man weiter ausholen und das führte dann wirklich etwas zu weit. :-) > Fragen über Fragen, die man sich nicht erklären kann, vor > allem, wenn man schon selbst programmiert hat! Vielleicht hilft die obige Erklärung ja schon ein wenig weiter. Wobei man nicht dem Irrtum unterliegen sollte, dies sei die einzige mögliche Erklärung für "Bloat". Es ist eine von vielen. > > Ich habe schon bei einigen Softwareentwicklern nachgefragt, da kriegst > natürlich keine Antwort! Vielleicht die falschen Leute gefragt.
Peter II schrieb: > Christian M. schrieb: >> Und warum brauchen auch selbst die simpelsten Windows-Programme >> Megabytes? Fragen über Fragen, die man sich nicht erklären kann, vor >> allem, wenn man schon selbst programmiert hat! > > Notepad brauch 2Mbyte notepad.exe unter Windows 8.1 x64 (deutsch) ist exakt 216 KB groß, also nur ein Zehntel so groß. Und das ist schon erstaunlich viel, denn angefangen hat der unter Windows NT mit 50 KByte. Als Quelle kann ich mich selber zitieren, 1993 schrieb ich in comp.sys.sgi.misc In <1o7uai...@fido.asd.sgi.com> mt...@mycool.asd.sgi.com (Michael Toy) writes: >1. From what I've seen (I have two machines in my office running NT, > one MIPS and one 486) NT is as big or bigger then IRIX. >2. NT is still beta software, maybe they will fix that eventually. >3. People (even me) keep complaining about software bloat, but it > is interesting that two similarly powerful operating systems > (Modern UNIX and Windows NT) are also of similar size. This may apply to the OS itself, but it definitly doesn't apply to the application programs. One example: I always wondered why the "jot" editor takes so much longer to load on my fast 50MHz R4000 Indigo than the notepad editor on my slowly 25 MHz NT-PC. Both editors are more or less equally powerfull (-less, that is), but jot needs about five times as long to load. Well, the answer is simple: notepad.exe on the October 92 NT PDK is about 50 KByte, while jot amounts to more than 670 KByte. Now I don't doubt that the 0.5 G SCSI disk on the Indigo is faster than the cheap 0.15 G IDE drive in the PC, but it surely isn't more than ten times faster. https://groups.google.com/forum/message/raw?msg=comp.sys.sgi.misc/Z9NWB4gBlYU/YE96BPx9_jkJ N.B. Man sieht, software bloat war auch vor 23 Jahren schon ein Thema.
Hach auf dem Motorola MPx200 haben das komplette Windows Mobile 2003 samt Office Mobile und diversen Programmen wie Internet Explorer, Kalender, SMS Programm, Outlook, Videoplayer (TCPMP), Spielen (Bubblebreaker), Windowsmediaplayer und dazu noch Benutzerdaten in 32 MByte Flash gepasst. Das konnte man noch mit SD-Karte erweitern, aber krass was da alles so ging.
Martin schrieb: > ich wollte mal einen Android-Insider fragen wieso Android Apps > vergleichsweise (oder für die Funktion die sie bieten) so unglaublich > viel Speicher brauchen. Das erste Problem heißt Java (ist nunmal nicht das schnellste oder schlankeste Pferd im Programmiersprachenstall), das Größere sind aber die für die Anwendungsentwicklung verwendeten Frameworks. Die alle alles möglichst einfach, Anfängertauglich und natürlich plattformübergreifend (also für iOS, Android und vielleicht sogar Windows Phone einsetzbar) bieten sollen. Dabei wird dann lustig eine Abstraktionsschicht auf die andere gesetzt. Dieses ganze Geraffel hängt dann natürlich im Speicher rum und verbraucht Platz - und Rechenleistung, denn das Programm muss sich für jeden Funktionalität durch dutzende Wrappermethoden kämpfen bis mal endlich was passiert. Ich habe nie verstanden warum man bei Android auf Java gesetzt hat. Plattformunabhängigkeit hätte man auch Problemlos erreichen können in dem das SDK für die vorherrschenden Prozessoren automatisch Binaries kompiliert und der Appstore die jeweils richtige ausliefert (oder von mir aus alle zusammen in einer APK sind). Man könnte die verschiedenen Fähigkeiten der ARM Prozessoren durch ein entsprechendes Framework + hochoptimierende Compiler imho viel besser nutzen.
Bei meinem ersten Kontakt mit Java hat mir das schon nicht gefallen. Die Programmierer sparen sich Zeit und Ärger, indem sie eine einfache statt einer effizienten Sprache benutzen und bezahlen darf es der Nutzer durch unnötig leistungsfähige Hardware Ist das jetzt eingetreten oder habe ich das falsch rausgelesen?
Dussel schrieb: > Bei meinem ersten Kontakt mit Java hat mir das schon nicht gefallen. Die > Programmierer sparen sich Zeit und Ärger, indem sie eine einfache statt > einer effizienten Sprache benutzen und bezahlen darf es der Nutzer durch > unnötig leistungsfähige Hardware > Ist das jetzt eingetreten oder habe ich das falsch rausgelesen? Hardware ist im Vergleich zu Entwicklungsstunden billig und schlechten Code kriegt man mit jeder Sprache hin.
D. I. schrieb: > Hardware ist im Vergleich zu Entwicklungsstunden billig Nur dass die Entwicklungsstunden nur einmal bezahlt werden müssen, während die Hardware tausend- oder millionenfach gekauft werden muss. Das heißt also, du stimmst mir zu.
Java war schon immer extremst Speicherfressend und lahm! Egal ob auf PC, Spielkonsole, Settopbox oder Smartphone.
:
Bearbeitet durch User
Dussel schrieb: > Nur dass die Entwicklungsstunden nur einmal bezahlt werden müssen, > während die Hardware tausend- oder millionenfach gekauft werden muss. > Das heißt also, du stimmst mir zu. Nicht gänzlich. Die Hardware (Smartphone/Tablet) wird ja nicht ausschließlich für eine App angeschafft, wohingegen man als Anbieter 100% der Entwicklungstunden in eine App steckt.
> Nur dass die Entwicklungsstunden nur einmal bezahlt werden müssen
Nicht unter Android. Da gibt es für jedes Problemchen 100 Apps. Besser
wäre, die 100 Entwickler tun sich zusammen, entwickeln eine kompakte,
schnelle, fehlerfreie App. Oder noch besser; die 10 Enthusiasten
entwickeln eine App und der ganze Rest, der mit Werbung und Bloatware
Kohle machen will, fliegt aus dem Appstrore raus.
Übrigens - bei der Hardware hast du den selben Effekt. Wenn du die
Entwicklerstunden für die Chips auf die produzierten Stückzahlen
umlegst, kommen nur Bruchteile eines Cents heraus. Bei Milliarden von
Smartphones werden die GB-Cips billiger als damals die kB-Chips für die
Homecomputer.
Scelumbro schrieb: > Ich habe nie verstanden warum man bei Android auf Java gesetzt hat. > Plattformunabhängigkeit hätte man auch Problemlos erreichen können in > dem das SDK für die vorherrschenden Prozessoren automatisch Binaries > kompiliert und der Appstore die jeweils richtige ausliefert So wird es doch im Prinzip gemacht. Nur dass der Compile-Vorgang auf dem Smartphone selber ausgeführt wird. Am Ende bleibt aber eine native Binary, die genau für den Prozessor des ausführenden Geräts kompiliert wurde.
> Am Ende bleibt aber eine native Binary
Soweit ich weiß, erst seit Android 5.0 mit ART. Dalvic war ein
Interpreter mit JIT. Nur dummerweise hat ART es kaum Auswirkungen auf
Speicherverbrauch und Geschwindigkeit.
Andere Idee... Apache Xalan wurde mal 1:1 von Java nach C++ übersetzt.
Die Leute hatten sich damals gewundert. Der C++ Code ergab den selben
Speicherverbrauch und die selbe Geschwindigkeit wie der Java JIT.
Problem ist der Java-Zwischencode mit all seinen Arrayüberprüfungen,
Castüberprüfungen, Überprüfungen auf nicht initialisierte Variablen und
seiner dynamischen Speicherverwaltung. Ein C Programmierer weiß was er
tut, braucht den ganzen Overhead nicht. Aber wenn er in C ein Android
Programm schreibt, bauen ihm Zwischencode und ART den ganzen Overhead
der idiotensicheren Java Runtime ein.
Noch einer schrieb: > Problem ist der Java-Zwischencode mit all seinen Arrayüberprüfungen, > Castüberprüfungen, Überprüfungen auf nicht initialisierte Variablen und > seiner dynamischen Speicherverwaltung. so Prüfungen kosten nur Zeit aber fast kein RAM. Das kann nicht wirklich das Problem sein. Ich vermute viel mehr das Problem "Speicher-Freigeben" Bei C++ ist klar definiert wenn ein Objekt zerstört wird, bei JAVA kümmert sich der GC asynchron darum. Es muss für jedes Objekt noch eine Refernzzähler und ähnliche Dinge mitgescheppt werden - das kostet halt speicher.
> aber fast kein RAM
Bei einem Interpreter nicht. Ein Compiler dagegen baut zusätzliche
Maschinenbefehle für Arraygrenzen und Casts ein.
Und bei C++ ist die Speicherfreigabe extrem schnell - normalerweise nur
Stackpointer zurück setzen. Die wenigsten Objekte werden auf dem Heap
angelegt.
Weiß jemand, ob Android Objekte auf dem Stack erlaubt?
Noch einer schrieb: >> aber fast kein RAM > > Bei einem Interpreter nicht. Ein Compiler dagegen baut zusätzliche > Maschinenbefehle für Arraygrenzen und Casts ein. aber nicht für jedes Objekt, sondern für eine Klasse. Code ist meist nicht mehrfach vorhanden.
G++ (5.2) kann mittlerweile sehr viel optimieren. Der Java compiler (gibt es überhaupt mehrere freie?) macht 0,0 Optimierung und übersetzt den Code 1:1. Sehr schwache Leistung von Goo*gle.
dash button schrieb: > G++ (5.2) kann mittlerweile sehr viel optimieren. > > Der Java compiler (gibt es überhaupt mehrere freie?) macht 0,0 > Optimierung und übersetzt den Code 1:1. > Sehr schwache Leistung von Goo*gle. so ein Unsinn. Java kann grundsätzlich sogar noch mehr optimieren als jeder C(++) Compiler. Bei JIT optimieren sie zur Laufzeit und sehen damit z.b. Variablen die von außen reinkommen. Wogegen bei C++ üblicherweise statischen Code erzeugt wird. Wenn JAVA langsam ist, liegt es bestimmt nicht am Compiler, sondern an den Möglichkeiten die JAVA bietet. (z.b. Reflexion).
Der Overhead in Objekte ist doch recht stark: http://stackoverflow.com/questions/258120/what-is-the-memory-consumption-of-an-object-in-java [...] Object headers and Object references In a modern 64-bit JDK, an object has a 12-byte header, padded to a multiple of 8 bytes, so the minimum object size is 16 bytes. For 32-bit JVMs, the overhead is 8 bytes, padded to a multiple of 4 bytes. (From Dmitry Spikhalskiy's answer, Jayen's answer, and JavaWorld.) [...] Wenn für jedes Objekt wirklich 12byte overhead drauf gehen, dann sollte klar sein warum Java so viel ram braucht.
Im Eingang ging es um code size. Und da könnte man eine Menge rausholen, wenn der java Compiler so gut wäre wie der GCC. Sieht man ja schon, wieviel proguard rausholen kann. Von der Optimierung her ist das aber ein Witz ggü. GCC. Übrigens kann dies auch Obfuscation Versuche zu nichte machen; selber schon erlebt dass Debug Strings noch im Code sind, obwohl die Log Methode leer ist (mit proguard). Korrekt wäre eine statische Voroptimierung + die Optimierungen die auf dem Gerät geschehen. Das würde sicherlich auch die Installationszeit heruntersetzten. Bleibt bei Google Watch eigentlich der Zeiger stehen, während eine App installiert wird? Bei den alten Schrottprozessoren würde mich das nicht wundern. :D
Peter II schrieb: > Java kann grundsätzlich sogar noch mehr optimieren als jeder C(++) > Compiler. Bei JIT optimieren sie zur Laufzeit und sehen damit z.b. > Variablen die von außen reinkommen. Wogegen bei C++ üblicherweise > statischen Code erzeugt wird. Es gibt in C++ schon lange die Möglichkeit des Profile Guided Optimization. Da füttert man das Programm mit typischen Daten und der Compiler optimiert dann daraufhin. Ist natürlich nicht so optimal wie wenn man das zur Laufzeit macht, aber dafür kostet die Analyse und Optimierung auch keine Laufzeit.
Noch einer schrieb: > Ein C Programmierer weiß was er tut, braucht den ganzen Overhead nicht. Merkt man. An den mittlerweile fast schon täglichen eintrudelnden Panikmeldungen über sicherheitskritische Buffer Overflows.
Wenn Java und die Runtime-Techniken von Android an allem Schuld haben, wieso sind dann in iPhones sehr leistungsfähige Prozessoren mit viel RAM verbaut?
:
Bearbeitet durch User
Peter II schrieb: > Wenn JAVA langsam ist, liegt es bestimmt nicht am Compiler, sondern an > den Möglichkeiten die JAVA bietet. (z.b. Reflexion). Hier z.B. das fehlende Caching von Member Variablen: http://pastebin.com/GQevG4pT Warum sollte man sowas erst auf dem Gerät oder noch schlimmer zur Laufzeit optimieren? Falls das überhaupt geschieht.. War schon überrascht, dass der Konstantenzugriff wegoptimiert wurde.
efsrwr446 schrieb: > Hier z.B. das fehlende Caching von Member Variablen: > http://pastebin.com/GQevG4pT eventuell sind ja bei Java alles Variablen volatile
Christian M. schrieb: > Und warum brauchen auch selbst die simpelsten Windows-Programme > Megabytes? Fragen über Fragen, die man sich nicht erklären kann, vor > allem, wenn man schon selbst programmiert hat! > > Ich habe schon bei einigen Softwareentwicklern nachgefragt, da kriegst > natürlich keine Antwort! Dann kriegst du hiermit eine von mir: Weil den meisten Software-Entwicklern der Codeumfang egal ist - und weil ein dicker Brocken viel imposanter aussieht als ein schlankes Programm. Beispiel: Hexapad.exe (ein Datei-Hexeditor) kommt mit 74 KByte daher und ist eine durchaus nicht ganz simple grafische Windows-Anwendung. Grund für diese Schlankheit ist die Verwendung von KOL zum Delphi. Damit kann man tatsächlich schlanke grafische Anwendungen schreiben, die lediglich ihre .exe brauchen und keinerlei dicke im Hintergrund lauernde Runtime-DLL's. Also es geht. Aber warum benutzen die Leute das nicht? Siehe oben. Je fetter, desto mehr Ruhm für den Programmierer. Und zu den Android-Apps: Das sind durchweg gepackte Archive im Zipformat. Da gibt es keinen lad- und ausführbaren Code, sondern nur Gepacktes. Also braucht es zu dem Zipfile auch noch mindestens doppelt so viel freien RAM, um darin die enthaltenen eigentlichen Programme und Daten auszupacken. Häufig genug ist das jedoch wiederum ein Sammelsurium von Zip-gepackten Dateien, die wiederum vor Verwendung ausgepackt werden müssen. Tja, ZIP ist ja als Pack- und Archivierungsformat sehr schön, aber besser wäre es allemal gewesen, für Android-Anwendungen ein eigenes ungepacktes Dateiformat zu kreieren, was man nur einmal in den RAM laden muß und von dort aus ohne zusätzliche Entpackerei abarbeiten kann. Microsoft's EXE Format ist da ein gutes Beispiel, ELF ginge bis auf dieRessourcenfrage ebenfalls. Ist aber nicht. Und deswegen wird bei Android lustig entpackt auf Teufel komm raus. Das ist übrigens auch einer der Gründe, weswegen alles Androidzeug für vergleichbare Leistung wesentlich mehr an Hardware-Ressourcen braucht als WinCE-Zeugs. Ein Navi mit WinCE, 128 MB Ram und 400 MHz ARM ohne GPU funktioniert - eines mit Android würde bei der HW-Ausstattung unbenutzbar lahm sein. W.S.
Androids APK ist das Installationsformat. Also das Äquivalent zu den ebenfalls komprimierten Containern MSI, RPM etc. Nicht das Laufzeitformat. Die APKs werden nicht einfach ins Flash geschoben und fertig, sondern bei der Installation passiert was. Schon vor ART.
:
Bearbeitet durch User
W.S. schrieb: > mit WinCE, 128 MB Ram und 400 MHz ARM ohne GPU funktioniert - eines mit > Android würde bei der HW-Ausstattung unbenutzbar lahm sein. Äpfel und Birnen... Ein Einsteigerhandy von anno Android 2.3 hatte einen 600 MHz ARM11 mit 256MB RAM drin und für die Programme standen um die 150MB Flash zur Verfügung. Und schon damals war WinCE uralt. Geräte wachsen mit den Möglichkeiten der Zeit. Wenn man zum gleichen Preis wie früher mehr RAM einbauen kann, da wird dieses RAM recht bald auch gebraucht. Dieses eherne Gesetz der PC-Branche gilt auch bei Smartphones. Egal auf welchem System es aufbaut. Wenn man dann Geräte verschiedener Generationen miteinander vergleicht, dann wird man völlig unabhängig vom Basissystem "völlig erstaunt" feststellen, dass neuere Geräte viel mehr Ressourcen verbrauchen als alte.
W.S. schrieb: > Ach - und welches wäre das deiner Meinung nach? Jenseits der Installation sind es je nach Runtime optimierte DEX Files (Dalvik), oder ELF Files (ART). http://anandtech.com/show/8231/a-closer-look-at-android-runtime-art-in-android-l/ Manche Apps verwenden auch in Android vom Entwickler erzeugten nativen Code. Liegt der nur als ARM Binary vor, es steckt aber ein Intel Prozessor drin, wird das zur Laufzeit dynamisch übersetzt (Houdini).
:
Bearbeitet durch User
Noch einer schrieb: > Ein C Programmierer weiß was er > tut, braucht den ganzen Overhead nicht. Ja genau... Und wie erklärst du dann die quasi unendliche Zahl von Sicherheitslücken in C-Programmen? Also z.B. so Sachen wie buffer- und integer overflows, zeropointer-Zugriffe, double free Fehler usw. usf...
Dussel schrieb: > Bei meinem ersten Kontakt mit Java hat mir das schon nicht gefallen. Die > Programmierer sparen sich Zeit und Ärger, indem sie eine einfache statt > einer effizienten Sprache benutzen und bezahlen darf es der Nutzer durch > unnötig leistungsfähige Hardware > Ist das jetzt eingetreten oder habe ich das falsch rausgelesen? Dass auch "schlechte" Programmierer halbwegs lesbaren Code produzieren und keine unnötigen Bugs einbauen ist eigentlich ein Qualitätsmerkmal (auch wenn das bei Java nicht so ganz verwirklich ist...). Java wird ja hauptsächlich im Enterprisebereich eingesetzt. Und ob der (virtuelle) Server, auf dem das Servlet läuft, jetzt 128GB oder 512GB RAM hat, ist bei vielen schon unter der Wahrnehmungsgrenze... ;) Viel wichtiger ist bei solchen Enterpriseapplikationen dagegen, dass auch bei fluktuierenden Entwicklern der Code les- und damit wartbar bleibt. Es sind einfach vollkommen andere Anforderungen. Niemand wird Java (bzw. das Ökosystem Java) für ein embedded system einsetzen. Aber C ist/war auch nie dafür gedacht z.B. COBOL zu ersetzen. Verschiedene Programmiersprachen/Laufzeitumgebungen haben verschiedene Einsatzzwecke. Und man muss eben oftmals einen Trade-Off verschiedener Eigenschaften eingehen, um das optimale Ergebnis zu erzielen. Noch einer schrieb: > Problem ist der Java-Zwischencode mit all seinen Arrayüberprüfungen, > Castüberprüfungen, Überprüfungen auf nicht initialisierte Variablen und > seiner dynamischen Speicherverwaltung. Ein C Programmierer weiß was er > tut, braucht den ganzen Overhead nicht. Aber wenn er in C ein Android > Programm schreibt, bauen ihm Zwischencode und ART den ganzen Overhead > der idiotensicheren Java Runtime ein. Und wieviele solcher C-Programmierer gibt es? Die kann man auf der ganzen Welt wohl an einer Hand abzählen... Es ist nunmal Fakt, dass auch sehr gute Informatiker massive Probleme damit haben, robusten Code in C zu schreiben. Bestes Beispiel ist OpenSSL: Eine C-Bibliothek, die hauptsächlich von Kryptographen entwickelt wird. Alles sehr fähige (und intelligente) Leute. Trotzdem gibt es massig Bugs, die sich eben darauf zurückführen lassen, dass C verwendet wurde.
:
Bearbeitet durch User
Heinz K. schrieb: > Verschiedene Programmiersprachen/Laufzeitumgebungen haben verschiedene > Einsatzzwecke. Und man muss eben oftmals einen Trade-Off verschiedener > Eigenschaften eingehen, um das optimale Ergebnis zu erzielen. Ich weiß. Mit Assembler programmiert man keine Spiele und mit Java keine 8-Bitter. Hier geht es aber gerade darum, dass Java auf einem sehr begrenzten System eingesetzt wird. Nach anfänglicher Ablehnung mag ich Java inzwischen ziemlich gerne. Kleine Programme, im Sinn von Funktionsumfang, kann man damit sehr viel schneller schreiben als mit C++. Aber wenn es um ein System mit eingeschränkten Ressourcen geht, sollte man eben nicht eine der Sprachen mit den höchsten Ressourcenanforderungen nehmen. Wenn man Java wirklich compilieren könnte, wäre es für mich wahrscheinlich die beste Sprache. Meinen Informationen zufolge wird aber bei Compilieren die ganze VM mitcompiliert und in die Datei gepackt, wodurch das ganze wieder übermäßig groß wird.
Wofür wird Java heute recht oft eingesetzt? Für Anwendungen auf Webservern. Es gibt zwar tausend Sprachen, in denen man sie implementieren kann. Aber wenn man sich mal im realen Leben umsieht, dann sind die meisten in PHP oder Java. Da kann man über Java noch so meckern - bei dieser Alternative kann es nur gewinnen. Apropos 512GB: Java braucht zwar etwas RAM, aber so wild ist das nicht. Nicht heute. Störender ist die Startzeit. Da mag eine grössere Anwendung ihre 16GB voraussetzen - aber es kann locker 10 Minuten dauern, bis das Sammelsurium an Dockern hochgefahren ist.
:
Bearbeitet durch User
Heinz K. schrieb: > Niemand wird Java (bzw. > das Ökosystem Java) für ein embedded system einsetzen. Java läuft sogar auf Kreditkarten :-) https://de.wikipedia.org/wiki/Java_Card
Heinz K. schrieb: > Java wird ja hauptsächlich im Enterprisebereich eingesetzt. Ja, weil irgendwann man ein Schlipsi mit blütenweißem Hemd dem wichtigen Einkäufer mit ebenfalls Schlips und blütenweißem Hemd versprochen hat, das Java alles richten wird. Und der Einkäufer seinem Cheffe das auch so weiter berichtet hat. Sprich: eine Horde hochbezahlter technischer Vollidioten hat für die Verbreitung von Java gesorgt. Das ist natürlich stark vereinfacht dargestellt, aber im Kern durchaus passend. Die aktuelle Situation zeigt das nur zu deutlich... > Viel wichtiger ist bei solchen Enterpriseapplikationen dagegen, dass > auch bei fluktuierenden Entwicklern der Code les- und damit wartbar > bleibt. Ja genau das ist der Punkt: Wir (hochbezahlte Schlipsies) wollen weg von den ekelhaft teuren kompetenten Programmierern. Die versauen doch nur die Bilanzen. Wir brauchen eine Sprache, in der sich sogar der Penner aus der nächsten Seitengasse hinter den drei Mülltonnen noch irgendwie ausdrücken kann, denn den können wir für ein paar Peanuts kaufen. So war der Plan der gierigen Schlipsies. Fazit heute: er ist einfach nicht aufgegangen... > Es ist nunmal Fakt, dass auch sehr gute Informatiker massive Probleme > damit haben, robusten Code in C zu schreiben. Wohl wahr. C ist Dreck allerunterster Kajüte, unsicherer noch als pure Assembler. Allerdings: Java lehnt sich syntaxmäßig deutlich an C an. Zumindest die durch die selbstverschlüsselnde Syntax aufgeworfenen kognitiven Probleme hat Java also (ohne jede Not) bei C quasi eingekauft. Deswegen liebe ich .net. Na klar, auch Microsoft konnte sich nicht gänzlich dem C/C++-Mummenschanz entziehen und deshalb gibt es C#. Aber das ist im Vergleich zu den syntaktischen Stammvätern doch schon eine sehr stringente Sprache. Etwa vergleichbar mit Java. Nur kann .Net mehr: es gehen auch richtige Sprachen mit verständlicher Syntax damit. Und man kann nahezu problemlos zwischen all diesen Sprachen hin- und herwechseln. Wenigstens das muss aus so einem Ansatz mit Zwischencode effektiv herauskommen, sonst ist er unsinnig. Microsoft wins. Und das nicht nur meiner persönlichen Einschätzung nach, sondern auch im RL. Java stirbt.
c-hater schrieb: > Zumindest die durch die selbstverschlüsselnde Syntax aufgeworfenen > kognitiven Probleme hat Java also (ohne jede Not) bei C quasi > eingekauft. Liegt möglicherweise auch an deiner mangelnden Auffassungsgabe.
c-hater schrieb: > C ist Dreck allerunterster Kajüte, unsicherer noch als pure Assembler Dümmliche Aussage So dümmlich wie jeder Programmiersprachenstreit. Programmieren erfordert logische Intelligenz. Sehr gute Programmierer haben sehr viel davon. So viel, daß sie den Programmiersprachenstreit lange als absurd erkannt haben und den Dümmeren überlassen.
Und nun zum Thema: Java braucht bei Android apk den geringsten Anteil. Tatsächlich blähen die Bitmaps ein apk extrem auf, u.a. weil nur png erlaubt ist. Dann wird bei der Installation das apk erhalten und ausgepackt. Der Speicherbedarf verdreifacht sich grob. Alles kein Problem bei apks unter sagen wir 5MB. Aber eine App unter 1MB mit mehr als einer Handvoll größerer Icons (>128*128*4bytes) ist sehr schwierig zu erreichen, übrigens auf fast jedem System.
Boris P. schrieb: > Java läuft sogar auf Kreditkarten :-) Ja, aber eben auf Kredit. Irgendwann musst du den ganzen gepumpten Speicher nachlegen.
Hannäs schrieb: > Und nun zum Thema: Java braucht bei Android apk den geringsten Anteil. > Tatsächlich blähen die Bitmaps ein apk extrem auf, u.a. weil nur png > erlaubt ist. Eben. Beitrag "Re: Warum brauchen Android Apps so viel Speicher"
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.