Verwendet Android oder Java mehr Leistung, da es auf einer virtuellen Maschine ausgeführt wird?

5568
PKM

Da Android-Anwendungen auf einer JVM (Dalvik VM) ausgeführt werden, die im Grunde ein virtueller Prozessor ist, und jeder virtuelle Befehl dem nativen Befehl des zugrunde liegenden Chipsets zugeordnet werden muss, führt dieses Mapping aufgrund des zusätzlichen Aufwands dieses Mappings zu einem höheren Stromverbrauch?

Diese Frage kann auf Java erweitert werden und auch als "verwenden Java-Anwendungen mehr Leistung?" Ist das der Grund, warum Android-Handys im Vergleich zu anderen Plattformen / Handys so schreckliche Akkulaufzeiten haben?

Edit : Basierend auf den Antworten habe ich einige Punkte geklärt, weil ich irrtümlich über JVM und Dalvik austauschbar gesprochen hatte. In diesem Abschnitt spreche ich nur von Java, um zu fragen, ob es mehr Strom verbraucht, und wenn ja, trifft dies konzeptionell auch auf Android zu und führt dies zu einer verringerten Akkulaufzeit.

Kontext : zitiert aus Wikipedia:

  1. Java-Bytecode entspricht der Assemblersprache für C-Code.
  2. Aus Sicht eines Compilers ist die Java Virtual Machine nur ein weiterer Prozessor mit einem Befehlssatz, Java-Bytecode, für den Code generiert werden kann.
  3. JVM verfügt über eine Stack-Architektur. Dalvik ist eine virtuelle Prozessmaschine, die nicht die gleiche Art von Virtualisierung wie JVM ist und über eine Registerarchitektur verfügt.

Da die Java-Programmiersprache zu Bytecode (Assembly-like) kompiliert wird und auf einem virtuellen Prozessor ausgeführt wird, ist die Portabilität von Softwarecode gewährleistet. Da es eine JVM für Linux und Linux gibt, die auf offene Hardware portiert wurde, kann die Kombination eine echte Anwendungsportabilität über den gesamten Stack bieten.

Leistung : Die Frage läuft im Wesentlichen auf die Frage hinaus: Welcher Prozentsatz Ihrer CPU-Taktzyklen wird für die gleiche Funktionalität Ihres Software-Codes oder Ihrer Anwendung der Laufzeitumgebung zugeordnet. Dies ist in der Just-In-Time-Kompilierungsumgebung moderner JVMs der Fall. Wenn der Bytecode mit dem systemeigenen Befehl des zugrunde liegenden Chipsets kompiliert wird, sollte die Laufzeit nur während der Jit-Kompilierung aktiv sein. Wie viel mehr CPU-Taktzyklen sind also in einer Laufzeitumgebung verbraucht, von der erwartet wird, dass sie zu einem Energieverbrauchs-Overhead führt. Ich interessiere mich nur für den Energieverbrauch und nicht für die relative Leistung im Vergleich zu statisch typisierten und gebauten Sprachen und verstehe die Vorteile von Java. Unterfragen, die in Zusammenhang stehen könnten:

  • Verwendet die Java-Laufzeit die libc für ihre Funktionalität?
  • Wird einer dieser Punkte bezüglich des Energieverbrauchs auf die VM und Android von Dalvik übertragen?
  • Anstatt den schlechten Batterieverbrauch von Android zu verallgemeinern, ohne über Bildschirm und drahtlose Chipsätze zu sprechen, möchten wir darüber sprechen, wie das iPhone 5 über einen 1440 mAH-Akku verfügt, der im Vergleich zu modernen Nexus-Handys winzig ist. Dieser ganze Gedankengang (Java, virtueller Prozessor, Instruction Mapping, Android) entstand, weil ein Freund eines iPhone-Loyalisten behauptete, dies könnte der wahrscheinliche Grund dafür sein, dass sein iPhone eine bessere Akkulaufzeit als mein (awesome) Nexus hat.

In jedem Fall danke ich für die Antworten unten.

14
Vergleichen Sie die Batterien nicht anhand ihrer mAh. Das ist aktuell; Theoretisch könnten Sie einen 2 mAh-Akku mit einer höheren Leistung (Wattstunden) als einen Akku mit 10000000 mAh haben. Abhängig von der Spannung. Das Nexus 4 verfügt über einen 8-Wh-Akku, während das iPhone 5 einen 5,45-Wh-Akku besitzt. Der Unterschied ist zum großen Teil auf die Bildschirmgröße zurückzuführen: Das Nexus 4 verfügt über ein 4,7-Zoll-Display, während das iPhone 5 einen 4-Zoll-Bildschirm mit höherer Auflösung und höherer Helligkeit (608 cd / m ^ 2 vs. 500) aufweist Auch deutlich anders: Nexus 4 hat einen Quad-Core bei 1,5 GHz, das iPhone 5 einen Dual-Core bei 1,3 GHz. Schneller = mehr Akkuverbrauch. Horn OK Please vor 11 Jahren 1
Grundsätzlich halten iPhones mit einem kleineren Akku länger, da die gesamte Plattform kleiner ist: weniger physischer Speicherplatz, kleinerer Bildschirm, kleinere CPU, weniger Kerne, weniger Kapazität, weniger Leistung, weniger, weniger, weniger. Android-Handys tendieren in die entgegengesetzte Richtung: größere und mehr Kerne, mehr Leistung und schneller. Natürlich benötigen sie viel größere Akkus, um die gleiche Akkulaufzeit zu erreichen. Manchmal kompensiert auch ein großer Akku den Verbrauch nicht richtig. In diesem Fall haben Sie ein Telefon mit geringer Akkulaufzeit. Horn OK Please vor 11 Jahren 1

5 Antworten auf die Frage

25
Horn OK Please

Ihre Frage basiert auf vielen fehlerhaften Annahmen. Lassen Sie mich versuchen, sie aufzuklären:

  • Sie sagten "JVM (Dalvik VM)". Das ist wie "Flugzeug (Fahrrad)" zu sagen. Diese beiden Dinge haben absolut nichts miteinander zu tun.

  • Sie sagten "... was im Grunde ein virtueller Prozessor ist". Einfach falsch. Es ist nicht der Fall, dass jedes Mal, wenn die Wörter "virtuelle Maschine" oder Abkürzung "VM" in einem technischen Kontext verwendet werden, dies im Wesentlichen der von VMware Workstation entspricht . Dies liegt daran, dass Produkte wie VMware tatsächlich einen gesamten Computer und nicht nur die CPU emulieren und ein Betriebssystem auf einem anderen Betriebssystem ausführen. Dalvik VM funktioniert nicht so. Nicht einmal annähernd.

  • Java ist nur eine Programmiersprache. Es ist die Syntax. Android / Dalvik-Programme verwenden die gleiche oder eine sehr ähnliche Syntax wie eine völlig unabhängige Desktop / Server-Programmiersprache namens Java, die auf einer Java Virtual Machine ausgeführt wird. Theoretisch könnten Sie Java-Code schreiben, der fast genauso schnell ist wie C-Code, da beide Programmiersprachen auf hoher Ebene sind. Der Teufel ist in den Details der Implementierung der Bibliotheksaufrufe und der Art und Weise, wie die Laufzeitumgebung entworfen wird, was sehr wenig mit der Syntax der Sprache zu tun hat.

  • Es ist eine übermäßige Verallgemeinerung zu sagen, dass Dalvik VM, die Java-Hotspot-JVM von Sun oder die Syntax der Java-Programmiersprache für den hohen Stromverbrauch verantwortlich ist. Der Grund ist, dass Sie alles, was Sie sprechen, mit der Leistung von etwas anderem vergleichen muss . Im allgemeinen Fall, wenn Sie nur die "Best-Case" -Funktionen beider Plattformen vergleichen, ist es grundsätzlich möglich, Dalvik-Apps genauso schnell oder schneller zu erstellen wie Programme auf einer anderen Plattform. Abgesehen von der automatischen Speicherverwaltung und der JIT-Kompilierung - Funktionen, die heutzutage in fast allen Programmierumgebungen Standard sind, einschließlich iOS und in JavaScript / HTML5 -, unterscheidet sich Dalvik kaum von Objective-C, .NET, Ruby und dem Oracle Hotspot-JVM, Python usw.

  • Die Wahrnehmung, dass "Java ist langsam" ist auf ein Problem mit alten Java-Versionen zurückzuführen, da diese entweder keinen Just-In-Time-Compiler (JIT) hatten oder die JIT, die sie hatten, in ihrer Funktionalität sehr eingeschränkt war. Die JVM hatte eine Just-In-Time-Compilerschon sehr lange. Ein JIT-Compiler ist ein Teil der Laufzeitumgebung (z. B. die JVM), der einen prozessorunabhängigen Bytecode (z. B. Java-Bytecode) verwendet und in native Anweisungen für die CPU kompiliert. Dieser Vorgang wird ausgeführt, wenn das Java-Programm gestartet wird. Erweiterte JIT-Compiler können einzelne Funktionen oder Anweisungen zur Laufzeit optimieren, um ihre Leistung basierend auf den beobachteten Ergebnissen zu verbessern. Wenn zum Beispiel eine Methode bei jedem Aufruf true zurückgibt, aber aus dem ursprünglichen Bytecode nicht ersichtlich ist, kann der JIT-Compiler erkennen, dass sie nur true zurückgibt, und den Funktionsaufruf durch einen harten Code ersetzen. codierter Wert von "true". Dies ist nur ein Beispiel.

  • JIT-Kompilierung und dynamische Codeanalyseverfahren zur Laufzeit haben in den letzten Jahren große Fortschritte gemacht. Viele in der Informatik Gemeinschaft glauben, dass in einem anderen Jahrzehnt oder zwei, die anspruchsvolle Analyse in dynamisch interpretiert / kompilierten Sprachen verfügbar, wie Java, C # und Ruby, wird so weit fortgeschritten sein, dass in den meisten Fällen, wird ausgeführt, diese Sprachen schneller auf Laufzeit als statisch kompilierte Sprachen wie C und C ++. Dies liegt daran, dass statische Compiler normalerweise nur zur Kompilierung von Code beschränkt sind und der Code zur Laufzeit nicht geändert wird. Aber in einer Laufzeitumgebung, in der der Code des Programms erneut geschrieben werden kann kannWährend der Ausführung für eine effizientere Ausführung ist ein enormes Aufwärtspotenzial zu erreichen, indem die Leistung des Codes analysiert und Anpassungen vorgenommen werden, um die Komplexität des Codes oder die Anzahl der Anweisungen zu reduzieren, die in der CPU ausgeführt werden. Bei häufig aufgerufenem Code wird der Zeitaufwand für die Durchführung der Analyse durch die Leistungsvorteile eines wiederholten Aufrufs von schnellerem Code bei weitem aufgewogen.

  • Es ist zu beachten, dass die Android Dalvik-VM auch eine JIT enthält und nicht das gleiche Bytecode-Format wie die Sun / Oracle-JVM verwendet. Die JIT von Dalvik ist für Umgebungen mit wenig Arbeitsspeicher optimiert und hinsichtlich der Verbesserung der Laufzeitleistung sehr weit fortgeschritten. Es ist also ein Zufall, dass JVM und Dalvik ähnliche Optimierungen für ihre jeweilige Java-basierte Laufzeitumgebung implementieren. Unter dem Dach sind sie jedoch ziemlich unterschiedlich.

  • Vergiss nicht, dass Dalvik selbst; der Linux-Kernel; Low-Level-Systemprozesse; Der Kern von Android-Webbrowsern (sowohl Firefox als auch Chrome) ist in nativem C / C ++ geschrieben. Daher haben sie keine Bedenken, die ein Dalvik-Programm hätte. Dies ist das gleiche wie bei iOS. Wenn es sich um reines Android handelt und nicht um das Aufblähen von Trägern / Drittanbietern, das darauf sitzt, wird ein großer Teil dessen, was Android-Kern umfasst, nicht mit Dalvik geschrieben.

  • Anwendungsentwickler auf Android können nach eigenem Ermessen nativen Code schreiben und dabei Dalvik umgehen. Wenn ein Anwendungsentwickler der Meinung war, dass Dalvik einen Engpass bei der Leistung seines Codes darstellt oder dazu führt, dass der Akku zu viel entladen wird, könnte er einfach C / C ++ - oder sogar Assembler-Code schreiben, wenn er möchte, ohne die Zustimmung von Google zu erhalten zu tun und ihre app so zu verteilen.

Hier sind einige tatsächlichen Gründe, warum ein Android batteriebetriebenes Gerät oder jede Vorrichtung, Probleme mit der Lebensdauer der Batterie haben kann:

  • Anwendungen, die die CPU, den Bildschirm oder die Datenverbindung wach halten. Insbesondere 4G-Chipsätze wie LTE verbrauchen beim Einschalten viel Energie. Wenn Sie also Hintergrundprogramme haben, die den LTE-Chip ständig aufwecken, um ein paar Kilobytes an Daten zu übertragen, führt dies zu einer schnellen Entladung der Batterie. Der Bildschirm moderner Smartphones und Tablets ist außerdem sehr energieintensiv, wenn Sie die Helligkeit nicht auf ein Minimum reduzieren.

  • "Bloatware", die sich auf dem Gerät befinden muss und nicht deinstalliert werden kann. Bei einigen skrupellosen Betreibern müssen Sie Bloatware ausführen, die CPU-Zyklen beansprucht und die Datenverbindung aktiviert hält. Dies kann entweder auf die Inkompetenz der Softwareentwickler der Bloatware zurückzuführen sein oder das absichtliche Ziel, Ihre Aktivitäten auf Ihrem Smartphone zu überwachen und für das Data Mining an einen Remote-Server zu senden, was für Ihre Batterie sehr energieintensiv ist.

Schließlich stimme ich Ihrer Einschätzung nicht zu, dass Android schlechtere Akkulaufzeiten als auf anderen mobilen Plattformen hat. Bestimmte Telefone und Geräte können tatsächlich Probleme mit der Lebensdauer der Batterie haben, entweder aufgrund der Kapazität der Batterie im Verhältnis zum Energieverbrauch der Hardware. schlecht optimierte Leistungseinstellungen (vom Benutzer, vom Spediteur oder vom Hersteller gewählt); oder Bloatware-Apps, die Chips ständig im Weckzustand halten. Aber für jedes Beispiel eines Geräts, das Batterieprobleme hat, kann ich Ihnen ein Gegenbeispiel eines Geräts mit ausgezeichneter Akkulaufzeit geben. Es gibt keinen einfachen Weg, um zu verallgemeinern, dass es "Dalvik" oder "Linux" oder "Java" ist. Die Energieoptimierung ist ein kompliziertes Hardware- / Software-Problem konkurrierender Anliegen, einschließlich Leistung, Reaktionsfähigkeit, und die Erwartungen der Benutzer an die Akkulaufzeit, mit Vor- und Nachteilen bei jeder Wahl. Um das Leistungsprofil eines Geräts vollständig zu verstehen, müssen Sie den Akku selbst, die gesamte Hardware und die auf dem Gerät ausgeführte Software genau unter die Lupe nehmen.

+1 Es ist ein bisschen mehr, aber es hat alles, sogar eine gute technische Antwort. Doktoro Reichard vor 11 Jahren 1
Danke, alle fairen Punkte. Ich hatte einige Begriffe falsch verwendet, weil ich etwas gefragt hatte, das ich nicht wusste. Habe jetzt einige Änderungen an der Frage selbst vorgenommen, falls Sie noch interessiert sind. PKM vor 11 Jahren 0
Diese Antwort ist ziemlich informativ, ging aber weit von der Frage entfernt. Im Zentrum der Frage stand, dass der VM-Overhead mehr CPU-Zeit beansprucht, als durch Optimierungen eingespart wird. Es hat sich herausgestellt, warum Android besser ist als iOs, obwohl die Frage auch auf die andere Seite deutet. PSIXO vor 10 Jahren 0
Es gibt auch hier eine fehlerhafte Annahme. IOS fehlt die automatische Speicherverwaltung von Mac OS. Und dieses Management macht Dalvik mit all seinen typischen Problemen zu einem "Java". Vor ein paar Monaten gab es einen ziemlich guten Überblick über die Probleme der Garbage Collection (GC), die Dalvik hat: http://www.anandtech.com/show/8231/a-closer-look-at-android-runtime-art- in-android-l / 2 - wenn sie die Akkulaufzeit beeinflussen oder nur die Leistung, kann ich nicht sagen. pvblivs vor 10 Jahren 0
@pvblivs Es ist zwar richtig, dass beim Schreiben von "High-Level" -Anwendungscode für iOS automatische Referenzzählung anstelle von GC verwendet wird, während Dalvik GC und "daher" verwendet (ich sage nicht, dass dies unbedingt der Fall ist, nur dass Sie streiten und das ist zumindest plausibel) iOS ist "effizienter" als Android ... Sie vermissen meinen Standpunkt immer noch, dass Android-Apps * nicht * in Java geschrieben werden müssen und tatsächlich geschrieben werden können Assembler oder sogar nativen ARM-Code, wenn Sie möchten! Besonders leistungsempfindliche Apps und integrierte Funktionen * sollten * nativen Code ohne GC verwenden. Horn OK Please vor 10 Jahren 0
Beispielsweise verwendet die C-Bibliothek von Android [Bionic] (http://en.wikipedia.org/wiki/Bionic_%28software%29) keine Garbage Collection, um den Speicher zu verwalten, den sie für die Ausführung ihrer Aufgabe zugewiesen hat . Nichts hindert andere Apps oder Programme auf Android daran, dasselbe zu tun, da von Drittanbietern geschriebene Programme und von Google geschriebene Programme dieselben Entwicklungswerkzeuge auf Android erhalten. Ja, es gibt einen Unterschied hinsichtlich der * Berechtigungen * und des Gerätezugriffs auf nicht gerooteten Telefonen. Dies ist jedoch ein Sicherheits- / Betreibersteuerungsproblem, kein Programmier- oder technisches Problem. Horn OK Please vor 10 Jahren 0
Das Problem, das scheinbar auftritt, besteht darin, dass viele der vorhandenen Apps * tatsächlich * äußerst leistungsabhängige Vorgänge (schwere Schleifen mit Medienverarbeitung usw.) zusätzlich zu Dalvik oder einer anderen JIT / GC-Umgebung (JavaScript ist ebenfalls groß) ausführen ein). Das ist eine gültige Kritik, aber nicht an der Kernplattform, nur an diesen spezifischen Apps und Diensten. Horn OK Please vor 10 Jahren 0
Der letzte Kommentar, ich verspreche Ihnen: Damit GC nur einen minimalen Einfluss auf die Leistung von Android haben kann, sollten Sie * nur * alle Ihre CPU-intensiven Schleifen, Medien-E / A-Routinen usw. in nativem Code unter Verwendung von Stack schreiben -zugeordnete, manuell verwaltete oder automatisch referenzierte Daten; Wenn Sie dann den übergeordneten Glue-Code schreiben (Ereignisbehandlungsroutinen, Layout der Benutzeroberfläche der App usw.), ist die Menge und Komplexität des Codes so klein, dass der GC sie verarbeiten kann. Dieser Ansatz funktioniert auf dem GNU / Linux-Desktop mit Ruby / Python / JavaScript gut genug. Horn OK Please vor 10 Jahren 0
@allquixotic: Ok, ich bekomme den Geist deiner Antwort. Ich bin ein bisschen zerrissen, weil die Realität ganz anders ist als die Theorie. Sie könnten sicherlich feststellen, dass IOS JS-Bindungen anbietet. Aber niemand würde antworten: IOS ist langsamer, weil sie JS anbieten. Die Antwort hier scheint also zu sein: Ja, Java macht Probleme, ebenso wie die VM. Nein, Android sicherlich nicht. Ich bin schlau, du kannst es auf dieser Plattform besser machen. pvblivs vor 10 Jahren 0
5
Mark Lopez

In dieser Antwort werde ich die Leistung mit Android und IOS vergleichen, da beide über 80% des Marktanteils erreichen.

Java-Apps verbrauchen nicht mehr Strom. ( http://www.javarants.com/2004/05/04/looks-like-apple-should-switch/ ) Die Java-VM von Oracle oder in Wirklichkeit die Dalvik-VM von Google gilt als wesentlich effizienter als das Objective-C von IOS. Java kann Code optimieren, bevor er auf dem Telefon ausgeführt wird, was zu einer deutlich besseren Leistung führen kann. Java-Bibliotheken sind Open Source und wurden daher von hunderten verschiedenen Entwicklern optimiert. Auf der anderen Seite können mit IOS nur Apple-Entwickler den Code ändern. Weniger Überprüfung = weniger potenzielle Leistung.

Android-Programme können auch nativen C-Code ausführen, der möglicherweise schneller als erneut Object-C (die einzige von IOS unterstützte Sprache) unterstützt wird.

Der Grund, warum sich Google für die Nutzung der VM von Dalvik entschieden hat, ist die Portabilität. Ich kenne vier verschiedene CPU-Architekturen, auf denen Android offiziell laufen kann (ARM, MIPS, x86, I.MX). Während jedes andere Telefonbetriebssystem nur ein ARM verwenden kann. ( http://en.wikipedia.org/wiki/Comparison_of_mobile_operating_systems ) Der Vergleich verschiedener CPU-Typen mit beispielsweise IPhone ist daher unfair. Wenn Android auf einem iPhone laufen würde, hätte Android eine vergleichbare Leistung und Akkulaufzeit.

"Verwenden Java-Anwendungen mehr Leistung?" Einfach nein
Warum haben Android-Telefone im Vergleich zu anderen Plattformen / Handys so schreckliche Akkulaufzeiten? Viele Android-Handys sind günstiger als Apples IPhone gebaut, schauen sich aber den Preisunterschied an. Das iPhone kostet mehr, weil der Akku viel größer ist (und die CPU ist im Durchschnitt langsamer). Mein Android-Handy (Google Galaxy Nexus) hat eine vergleichbare Akkulaufzeit wie das IPhone 4G, verfügt jedoch über wesentlich schnellere Hardwarespezifikationen (1 GHz vs. 1,2 GHz).

BEARBEITEN: Java kann Code optimieren, ohne dass das Programmiererwissen dazu benötigt. Perfekt, C-Code wird immer schneller als Java / Objective-C / C # ausgeführt. Aber wie viele Programmierer gibt es perfekt? Auf der JVM-Ebene werden Java und Bibliotheken aufgrund ihrer Open-Source-Entwicklungsprinzipien immer "perfekter" sein. ( http://www.infoq.com/news/2012/03/Defects-Open-Source-Commercial )

EDIT 2: Kleine Information: Das neue P780 Android Phone von Lenovo - 42 Stunden Gespräch statt 12 Stunden auf dem iPhone.

Ich würde behaupten, dass die * Frage selbst * völlig unbegründete Behauptungen aufstellt wie "... Android-Handys haben im Vergleich zu anderen Plattformen / Handys eine so schreckliche Akkulaufzeit". Einfach nicht wahr. Horn OK Please vor 11 Jahren 1
Ich möchte hinzufügen, dass Ihr erster Link IMHO von zweifelhafter Qualität ist: Die Benchmark-Dateien sind nicht mehr vorhanden und ein Kommentator hat die Meinung des Links des Links abgelehnt. Dieser Beitrag scheint voreingenommen zu sein, da es an nicht nachvollziehbaren Quellen und subjektiven Aussagen fehlt. Doktoro Reichard vor 11 Jahren 0
Nun, der erste Kommentar ist irgendwie richtig. Ohne ausführliche Tests wären alle Antworten voreingenommen. Ich bin damit einverstanden, dass die Akkulaufzeit von Android-Handys ziemlich schrecklich ist, aber dies ist sicherlich nicht auf VM zurückzuführen, wie viele Leute erwähnt haben. PSIXO vor 10 Jahren 0
In Kürze werden all diese Informationen mit der kommenden ART-Laufzeit in Android ohnehin veraltet sein. Mark Lopez vor 10 Jahren 0
3
davidgo

Ja, es bezieht sich auf einen erhöhten Stromverbrauch - dies wird durch Abstraktionsebenen erreicht. Dies führt auch zu einer Abnahme der Geschwindigkeit (gegenüber derselben Münze - wenn etwas mehr Aufwand hat, dauert es länger, bis die Leistung abläuft und somit mehr CPU benötigt wird). Wenn ich es richtig verstanden habe, ist dies einer der Vorteile des NDK. Erlauben Sie Beschleunigungen für bestimmte Prozessoren, indem Sie spezifischen Code schreiben.

Für die meisten Jobs stelle ich mir jedoch vor, dass der mit der Stromversorgung verbundene VM-Aufwand durch andere Faktoren in den Schatten gestellt wird - für die meisten Programme verbraucht die Verwendung von Bildschirm und Radios den größten Teil der Leistung.

Du hast recht. Die Verwendung schwarzer Oberflächenelemente auf Oled-Bildschirmen wäre in den meisten Fällen ein größerer Stromersparer als NDK vs. SDK. PSIXO vor 10 Jahren 0
3
Doktoro Reichard

Bei allen anderen Postern glaube ich, dass es hier am wichtigsten ist, ob C / C ++ / Java vorhanden ist, sondern was die Anwendungen tun.

Da der Stromverbrauch direkt mit der Verarbeitung abbildet, würde ich mich fragen, welche Verarbeitung ein Programm machen würde.

Angenommen, Sie fügen Zahlen hinzu. Angenommen, Sie addieren 2 mit 2 in einer Endlosschleife, bis Sie 2.000.000 erreichen. Es stellen sich zwei Fragen:

  1. Wie wird es implementiert: Ist es eine for-Schleife? Ist es eine while-Schleife? (Ist es ein Springen / Label-Hack?)
  2. Wie wird der Code optimiert?

Diese beiden Fragen definieren letztendlich, wie viele Operationen der Prozessor ausführen muss und wie viel Strom ein Gerät verbraucht. Der "Overhead" der Ausführung einer virtualisierten Umgebung ist aufgrund der vorherigen Optimierung, die Java für das gesamte Programm vorgenommen hat, vernachlässigbar, aber es hängt auch alles davon ab, was die Anwendung tut.

0

Ja.

Virtuelle Maschinen 'machen alles zweimal' und nicht unbedingt effizient. Sie benötigen also mindestens doppelt so viel Energie, um dieselben Anweisungen zu verarbeiten wie eine 'echte Maschine'. Das Vorhandensein einer virtuellen Maschine verlangsamt sich und verbraucht mehr Energie. Grundsätzlich führen Betriebssysteme wie iOS und Windows alles schneller und mit weniger Stromverbrauch aus.

Dies führt zu echten Unterschieden bei Bildschirmübergängen, Laden von Seiten, Navigation und dergleichen. Gegenwärtig vergleiche ich Android (VM) und Windows Phone und selbst mit einem langsameren Prozessor (1 GHz vs. 1,6 GHz) übertraf Windows deutlich die gleichen Aufgaben.

Die meisten Leute werden jedoch auf sich aufmerksam gemacht, wenn sie eine App installieren und plötzlich der Akku schneller aufgebraucht ist. Das liegt nicht wirklich an der virtuellen Maschine, sondern an einer App, die Ressourcen hungrig nutzt.

Der gesamte Grund für das Betriebssystem einer virtuellen Maschine, die Portabilität, ist kein guter Grund, um ein Betriebssystem darauf aufzubauen. Sehen Sie Menschen, die Handys mit ihrer Lieblingsarchitektur kaufen und Android verwenden, weil es tragbar ist? Sehen Sie Leute, die höhere Leistung und Zuverlässigkeit aufgeben und Android auf ihre Nicht-Android-Handys setzen? Die Leute kaufen ein Android Phone, ein Windows Phone oder ein IPhone usw. Es ist nicht praktikabel, die Leistung für die Portabilität in kostengünstigen Geräten zu opfern. Es war eine gute Idee, die zum Scheitern verurteilt war.