Czy system Android lub Java zużywa więcej energii, ponieważ działa na maszynie wirtualnej?

Ponieważ aplikacje dla systemu Android działają na maszynie JVM (Dalvik VM), która jest w zasadzie procesorem wirtualnym, a każda instrukcja wirtualna musi być odwzorowana na instrukcję natywną bazowego mikroukładu, czy to mapowanie powoduje większe zużycie energii z powodu narzutu związanego z mapowaniem?

To pytanie można rozszerzyć na Javę, a także sformułować jako „czy aplikacje Java zużywają więcej mocy?”. Czy dlatego telefony z Androidem mają tak przerażającą żywotność baterii w porównaniu do innych platform / telefonów?

Edycja : Na podstawie odpowiedzi wyjaśniłem kilka punktów, ponieważ błędnie mówiłem o JVM i Dalvik zamiennie. W tym fragmencie mówię o Javie tylko po to, by zapytać, czy zużywa ona więcej energii, a jeśli tak, to czy koncepcyjnie dotyczy to również Androida i czy powoduje skrócenie żywotności baterii.

Kontekst : cytowany z Wikipedii:

1. Kod bajtowy Java jest analogiczny do języka asemblera dla kodu C.
2. Z punktu widzenia kompilatora wirtualna maszyna Java jest tylko kolejnym procesorem z zestawem instrukcji, kodem bajtowym Java, dla którego można wygenerować kod.
3. JVM ma architekturę stosową. Dalvik to procesowa maszyna wirtualna, która nie jest tego samego typu wirtualizacją co JVM i ma architekturę rejestru.

Ponieważ język programowania Java jest kompilowany do kodu bajtowego (podobny do zestawu) i działa na procesorze wirtualnym, zapewnia on prawdziwą przenośność kodu oprogramowania. Ponadto, ponieważ istnieje JVM dla systemu Linux, a Linux został przeniesiony na otwarty sprzęt, kombinacja może zapewnić prawdziwą przenośność aplikacji na całym stosie.

Moc : pytanie zasadniczo sprowadza się do tego - w przypadku tego samego zestawu funkcji kodu oprogramowania lub aplikacji, jaki procent cykli zegara procesora jest przypisany do środowiska wykonawczego. Dzieje się tak w środowisku kompilacji Just-In-Time współczesnych maszyn JVM, w którym jeśli kod bajtowy jest kompilowany do natywnej instrukcji bazowego mikroukładu, wówczas czas wykonywania powinien być aktywny tylko podczas kompilacji jit. Więc o ile więcej cykli zegara procesora zużywa się w środowisku wykonawczym, które zgodnie z oczekiwaniami spowoduje zużycie energii. Interesuje mnie tylko aspekt zużycia energii, a nie względna wydajność w porównaniu ze statycznie typowanymi i wbudowanymi językami i rozumiem zalety Javy. Pod-pytania, które mogą być powiązane:

• Czy środowisko wykonawcze Java korzysta z biblioteki libc ze względu na swoją funkcjonalność?
• Czy któryś z tych punktów związanych z zużyciem energii przekłada się na Dalvik VM i Androida?
• Zamiast uogólniać słabe zużycie baterii Androida bez mówienia o ekranie i mikroukładach bezprzewodowych - porozmawiajmy o tym, jak iPhone 5 ma baterię 1440 mAH, która jest niewielka w porównaniu do nowoczesnych telefonów Nexus. Cały ten tok myślenia (Java, procesor wirtualny, mapowanie instrukcji, Android) powstał, ponieważ przyjaciel lojalisty z iPhone'a twierdził, że może to być prawdopodobny powód, dla którego jego iPhone ma lepszą żywotność baterii niż mój (niesamowity) nexus.

W każdym razie dziękuję za odpowiedzi poniżej.

Twoje pytanie opiera się na wielu błędnych założeniach. Pozwól mi spróbować je usunąć:

• Powiedziałeś „JVM (Dalvik VM)”. To tak, jakby powiedzieć „samolot (rower)”. Te dwie rzeczy absolutnie nie mają ze sobą nic wspólnego.

• Powiedziałeś „... który jest w zasadzie wirtualnym procesorem”. Po prostu fałszywe. To nie przypadek, że za każdym razem słowa „Virtual Machine” lub skrótem „VM” jest używane w kontekście technicznym, który jest zasadniczo równoważne VMware Workstation . Wynika to z faktu, że produkty takie jak VMware w rzeczywistości emulują cały komputer, nie tylko procesor, i obsługują system operacyjny na innym systemie operacyjnym. Dalvik VM tak nie działa. Nawet nie blisko.

• Java to tylko język programowania. To jest składnia. Programy Android / Dalvik wykorzystują tę samą lub bardzo podobną składnię do całkowicie niepowiązanego języka programowania desktop / server o nazwie Java, który działa na wirtualnej maszynie Java. Teoretycznie możesz napisać kod Java, który ma prawie taką samą prędkość jak kod C, ponieważ oba są językami programowania wysokiego poziomu. Diabeł tkwi w szczegółach implementacji wywołań biblioteki i sposobie, w jaki środowisko wykonawcze jest zaprojektowane, co ma bardzo mało wspólnego ze składnią języka.

• Nadgeneralizacją jest twierdzenie, że Dalvik VM, Sun Java Hotspot JVM lub składnia języka programowania Java jest odpowiedzialna za wysokie zużycie energii. Powodem jest to, że musisz porównać cokolwiek mówisz z wydajnością czegoś innego . W najbardziej ogólnym przypadku, gdy porównujesz możliwości „najlepszych przypadków” obu platform, w zasadzie możliwe jest tworzenie aplikacji Dalvik, które są równie szybkie lub szybsze niż programy na jakiejkolwiek innej platformie. Poza automatycznym zarządzaniem pamięcią i kompilacją JIT - funkcje, które są obecnie standardem w prawie wszystkich środowiskach programistycznych, w tym na iOS i JavaScript / HTML5 - niewiele jest rzeczy, które odróżniają Dalvik od Objective-C, .NET, Ruby, Oracle Hotspot JVM, Python i tak dalej.

• Postrzeganie, że „Java jest powolny” wynika z problemu ze starymi wersjami Javy, ponieważ albo nie miały one kompilatora Just-In-Time (JIT), albo posiadany przez niego JIT był bardzo ograniczony pod względem funkcjonalności. JVM ma kompilator Just-In Timeod bardzo dawna. Kompilator JIT jest częścią środowiska wykonawczego (na przykład JVM), który pobiera niezależny od procesora kod bajtowy - na przykład kod bajtowy Java - i kompiluje go w natywne instrukcje dla procesora. Proces ten jest wykonywany po uruchomieniu programu Java, a zaawansowane kompilatory JIT mogą zoptymalizować poszczególne funkcje lub instrukcje w czasie wykonywania, aby poprawić ich wydajność w oparciu o zaobserwowane wyniki. Na przykład, jeśli metoda zwraca true za każdym razem, gdy jest wywoływana, ale z oryginalnego kodu bajtowego nie wynika, że ​​by to zrobiła, kompilator JIT może rozpoznać, że po prostu zwraca true, i zastąpić wywołanie funkcji trudnym zakodowana wartość „true”. To tylko przykład.

• Techniki kompilacji JIT i dynamicznych analiz kodu wykonawczego poczyniły ogromne postępy w ostatnich latach. Wielu w społeczności informatycznej uwierzyć, że w kolejnej dekadzie lub dwóch, wyrafinowany dostępny w dynamicznie interpretowanych / skompilowanych językach takich jak Java, C # i Ruby analiza będzie tak zaawansowana, że w większości przypadków te języki będą wykonywać szybciej na środowisko wykonawcze niż języki skompilowane statycznie, takie jak C i C ++. Jest tak, ponieważ kompilatory statyczne zwykle ograniczają się do kompilowania kodu w czasie kompilacji, a kod nie jest modyfikowany w czasie wykonywania. Ale w środowisku wykonawczym, gdzie kod programu może ponownie napisać sobiepodczas wykonywania w celu wydajniejszego działania istnieje ogromna zaleta, którą można uzyskać, analizując wydajność kodu i wprowadzając korekty w celu zmniejszenia złożoności kodu lub liczby instrukcji uruchamianych na procesorze. W przypadku często nazywanego kodu czasochłonność inwestycji niezbędna do przeprowadzenia analizy znacznie przewyższa korzyści z wydajności wynikające z wielokrotnego wywoływania szybszego kodu.

• Należy zauważyć, że VM Dalvik dla systemu Android zawiera również JIT i że nie używa tego samego formatu kodu bajtowego co JVM Sun / Oracle. JIT firmy Dalvik jest zoptymalizowany pod kątem środowisk o niskiej pamięci i jest bardzo zaawansowany, jeśli chodzi o zwiększenie wydajności środowiska wykonawczego. Jest więc zbiegiem okoliczności, że JVM i Dalvik wdrażają podobne optymalizacje dla swojego środowiska uruchomieniowego opartego na Javie, ale pod maską są zupełnie inne.

• Nie zapominaj, że sam Dalvik; jądro Linux; procesy systemowe niskiego poziomu; a rdzeń przeglądarek internetowych na Androida (zarówno Firefox, jak i Chrome) są napisane w natywnym C / C ++, więc nie mają żadnych ogólnych problemów, które mógłby wywołać program Dalvik. To jest to samo co iOS. Jeśli mówisz o czystym Androidzie, a nie o wzdęciach przewoźnika / innej firmy, która na nim leży, bardzo duża część tego, co składa się na podstawowy Android, nie jest napisana przy użyciu Dalvik.

• Twórcy aplikacji na Androida mogą również, według własnego uznania, pisać natywny kod, omijając Dalvik. Jeśli twórca aplikacji uznał, że Dalvik działa jako wąskie gardło w działaniu swojego kodu lub powoduje nadmierne zużycie baterii, może po prostu napisać C / C ++ lub nawet kod asemblera, jeśli zechce, bez konieczności uzyskania zgody Google aby to zrobić i rozpowszechniać swoją aplikację w ten sposób.

Oto kilka faktycznych powodów, dla których urządzenie z zasilaniem bateryjnym z Androidem lub dowolne urządzenie może mieć problemy z żywotnością baterii:

• Aplikacje, które podtrzymują połączenie procesora, ekranu lub połączenia danych. W szczególności chipsety 4G, takie jak LTE, zużywają dużo energii, gdy są włączone, więc jeśli masz programy w tle, które stale wybudzają układ LTE, aby przesłać kilka kilobajtów danych, co bardzo szybko rozładuje baterię. Ekran nowoczesnych smartfonów i tabletów jest również bardzo energochłonny, chyba że zmniejszysz jasność do minimum.

• „Bloatware”, które musi znajdować się na urządzeniu i nie można go odinstalować. Niektórzy pozbawieni skrupułów operatorzy wymagają uruchamiania programów typu bloatware, które zajmują cykle procesora i utrzymują połączenie danych w stanie czuwania. Może to być spowodowane niekompetencją twórców oprogramowania typu bloatware lub zamierzonym celem monitorowania działań w smartfonie i wysyłania ich na zdalny serwer w celu eksploracji danych, co jest bardzo energochłonne dla baterii.

Wreszcie, nie zgadzam się z twoją oceną, że Android ma gorsze problemy z żywotnością baterii niż na innych platformach mobilnych. Niektóre telefony i urządzenia mogą mieć problemy z żywotnością baterii, albo ze względu na pojemność baterii w stosunku do zużycia energii przez sprzęt; źle zoptymalizowane ustawienia mocy (wybrane przez użytkownika, przewoźnika lub producenta); lub aplikacje typu bloatware, które cały czas podtrzymują czujniki w telefonie. Ale dla każdego przykładu urządzenia, które ma problemy z baterią, mogę podać kontrprzykład o doskonałej żywotności baterii. Nie ma prostego sposobu na uogólnienie, że „to Dalvik” lub „to Linux” lub „to Java”. Optymalizacja zasilania to skomplikowane połączenie sprzętu / oprogramowania z rywalizującymi ze sobą problemami, takimi jak wydajność, czas reakcji, oraz oczekiwania użytkowników dotyczące żywotności baterii, z zaletami i wadami każdego wyboru. Aby w pełni zrozumieć profil mocy urządzenia, musisz dokładnie przyjrzeć się samej baterii, całemu sprzętowi i oprogramowaniu działającemu na urządzeniu.

W tej odpowiedzi porównam wydajność z Androidem i iOS, ponieważ oba one zajmują ponad 80% udziału w rynku.

Aplikacje Java nie zużywają więcej energii. ( http://www.javarants.com/2004/05/04/looks-like-apple-should-switch/ ) Java VM Oracle lub w rzeczywistości Dalvik VM Google jest uważany za znacznie bardziej wydajny niż Objective-C IOS. Java jest w stanie zoptymalizować kod przed jego uruchomieniem na telefonie, co może spowodować znacznie lepszą wydajność. Biblioteki Java są Open Source i dlatego zostały zoptymalizowane przez setki różnych programistów. Z drugiej strony w systemie IOS tylko programiści Apple mogą zmieniać kod. Mniej recenzji = mniejsza potencjalna wydajność.

Programy na Androida potrafią także uruchamiać natywny kod C, co może być kwestionowane jako szybsze niż ponownie Object-C (jedyny język obsługiwany w IOS).

Powodem, dla którego Google zdecydowało się na użycie maszyny wirtualnej Dalvik, jest przenośność. Znam cztery różne architektury procesorów, na których Android może oficjalnie działać (ARM, MIPS, x86, I.MX). Podczas gdy każdy inny system operacyjny telefonu może używać tylko jednego (ARM). ( http://en.wikipedia.org/wiki/Comparison_of_mobile_operating_systems ) Tak więc porównywanie różnych typów procesorów np. z IPhone jest niesprawiedliwe. Jeśli Android byłby uruchomiony na iPhonie, Android miałby porównywalną z doskonałą wydajność i żywotność baterii.

„czy aplikacje Java zużywają więcej mocy?” Po prostu nie.
Dlaczego telefony z Androidem mają tak przerażającą żywotność baterii w porównaniu do innych platform / telefonów? Wiele telefonów z Androidem jest tańszych niż iPhone firmy Apple, ale spójrz na różnicę cen. IPhone kosztuje więcej ze względu na znacznie większą baterię (i jest średnio wolniejszy procesor). Mój telefon z Androidem (Google Galaxy Nexus) ma porównywalną żywotność baterii do iPhone'a 4G, ale ma znacznie szybszą specyfikację sprzętową (1 GHz w porównaniu do 1,2 GHz).

EDYCJA: Java może optymalizować kod bez wymaganej wiedzy programisty. Idealnie, kod C zawsze będzie działał szybciej niż Java / Objective-C / C #; To powiedziawszy, ilu programistów jest idealnych? Na poziomie JVM Java i biblioteki zawsze będą „doskonalsze” ze względu na zasady programowania open source. ( http://www.infoq.com/news/2012/03/Defects-Open-Source-Commercial )

EDYCJA 2: Mały smakołyk informacji: nowy telefon Lenovo P780 z Androidem - 42 godziny rozmowy w porównaniu do 12 godzin na iPhonie.

Tak, dotyczy to zwiększonego zużycia energii - zrobią to warstwy abstrakcji. Prowadzi to również do zmniejszenia prędkości (przeciwna strona tej samej monety - jeśli coś ma większy koszt, zajmie to więcej czasu i tym samym zużyje więcej procesora). Jeśli dobrze rozumiem, jest to jedna z zalet tego, co robi NDK - zezwól na przyspieszenie określonych procesorów, pisząc określony kod.

To powiedziawszy, w przypadku większości zadań wyobrażam sobie, że „związane z mocą” koszty związane z uruchomieniem maszyny wirtualnej są przyćmione innymi względami - w przypadku większości programów użycie ekranu i radia zużywa większość energii.

W odniesieniu do wszystkich innych plakatów uważam, że najważniejsze jest tutaj to, czy C / C ++ / Java istnieje, ale to, co robią aplikacje.

Ponieważ mapy zużycia energii bezpośrednio z przetwarzaniem, zadałbym sobie pytanie, jakie przetwarzanie wykona program.

Powiedz, że dodajesz liczby. Załóżmy, że dodajesz 2 z 2 w nieskończonej pętli, dopóki nie osiągniesz 2.000.000. Powstają dwa pytania:

1. Jak to jest realizowane: czy jest to pętla for? Czy to pętla while? (Czy to hack Goto / Label?)
2. W jaki sposób optymalizowany jest kod?

Te dwa pytania ostatecznie określają, ile operacji musi wykonać procesor i ostatecznie, ile mocy zużywa urządzenie. To powiedziawszy, „narzut” związany z uruchomieniem zwirtualizowanego środowiska może być nieistotny ze względu na poprzednią optymalizację dokonaną przez Javę w całym programie, ale z drugiej strony wszystko zależy od tego, co robi aplikacja.

Tak.

Maszyny wirtualne „robią wszystko dwa razy” i niekoniecznie wydajnie. Wykorzystają więc co najmniej dwa razy więcej mocy do przetworzenia tych samych instrukcji, co „prawdziwa maszyna”. Obecność maszyny wirtualnej spowalnia pracę i zużywa więcej mocy. Zasadniczo systemy operacyjne takie jak iOS i WIndows zrobią wszystko szybciej i przy mniejszym zużyciu energii.

Przekłada się to na rzeczywiste różnice w przejściach ekranu, ładowaniu stron, nawigacji i podobnych rzeczach. Obecnie porównuję Android (VM) i Windows Phone, a nawet z wolniejszym procesorem (1 GHz vs 1,6 GHz), Windows znacznie przewyższa Androida wykonując te same zadania.

Jednak większość ludzi zwraca uwagę na to, że instalują aplikację i nagle ich bateria zużywa się szybciej. To nie jest tak naprawdę spowodowane maszyną wirtualną, ale aplikacją, która łaknie zasobów.

Cały powód dla systemu operacyjnego maszyny wirtualnej, przenośność, nie jest dobrym powodem do oparcia systemu operacyjnego. Czy widzisz ludzi kupujących telefony z ulubioną architekturą i korzystających z Androida, ponieważ jest on przenośny? Czy widzisz ludzi, którzy rezygnują z wyższej wydajności i niezawodności i umieszczają Androida na swoich telefonach z systemem innym niż Android? Ludzie kupują telefon z Androidem, Windows Phone lub iPhone'a itp. Poświęcenie wydajności dla przenośności w tanich urządzeniach jest niepraktyczne. To był dobry pomysł, który stał się porażką.