Czy aplikacje na iOS są szybsze niż aplikacje na Androida, ponieważ aplikacje na Androida są interpretowane?

Aplikacje na Androida są interpretowane, a nie kompilowane. Czy to czyni je wolniejszymi niż aplikacje iOS w czasie wykonywania?

applications ios

— Armon Safai
źródło

To nie jest dobre pytanie, ponieważ aplikacje na Androida nie są interpretowane, tak jak faktycznie wskazuje poprawna odpowiedź.

— Aaronaught

Zwykle zaakceptowana odpowiedź nie będąca najlepszą odpowiedzią nie stanowi większego problemu, ponieważ jej celem jest pomoc każdemu, kto zadał pytanie (zobacz ten meta post). Ale jest to dość skrajny przypadek @ArmonSafai Odpowiedź, którą wybrałeś jako poprawną, jest pełna dezinformacji i jest zbyteczna, że można ją uratować dzięki edycjom. Proszę rozważyć wybranie innej odpowiedzi.

— Selali Adobor,

Pamiętaj, że niektóre duże korporacje - w tym IBM - piszą obecnie duże aplikacje w Javie. Biorąc pod uwagę kompilator Just-In-Time (JIT), który jest standardową częścią nowoczesnej maszyny wirtualnej Java, wydajność jest naprawdę porównywalna z każdym innym językiem wysokiego poziomu. Java od wielu lat jest nie tylko „językiem interpretowanym”.

— keshlam

Kompilatory JIT wcale nie są powiązane z koncepcją JVM. Istnieją maszyny JVM, które nie używają kompilatorów JIT, nawet te komercyjne. Niektóre odmiany JVM IBM nie włączają domyślnie JIT, zamiast tego domyślnie kompilują AOT. Również mała uwaga: „główne aplikacje w Javie w dzisiejszych czasach” były prawdopodobnie bardziej trafne dekadę i pół roku temu (IBM dodawał do Javy przed 1997 r.)

— Selali Adobor

Pytanie jest nieco mylące. „Natywna” aplikacja na iOS jest napisana w Objective-C (lub Swift) i skompilowana, podczas gdy „standardowa” aplikacja na Androida jest napisana w Javie i skompilowana do kodu bajtowego. Zobacz odpowiedź @ DanHulme. Możliwe jest jednak pisanie aplikacji dla dowolnej platformy w HTML i JavaScript przy użyciu np. PhoneGap / Cordova. Aplikacja HTML zazwyczaj działa wolniej niż aplikacja natywna na tej samej platformie. Więc jeśli podobna aplikacja dla „innej” platformy wydaje się być wolniejsza, być może dlatego, że została stworzona przy użyciu innej technologii.

— David

Odpowiedzi:

Java nie jest interpretowana na Androida. Aplikacje na Androida są kompilowane przez programistę do kodu bajtowego . Kod bajtowy jest zwartą reprezentacją programu: mniejszą niż kod źródłowy napisany przez programistę, ale wciąż nie do bezpośredniego wykonania przez procesor. Na tym etapie można dokonać pewnych optymalizacji, takich jak usunięcie martwego kodu.

Po załadowaniu aplikacji na urządzenie Dalv JVM kompiluje kod bajtowy do natywnego kodu wykonywalnego, tak jak ma się wkrótce uruchomić. To jest kompilacja just-in-time . Powoduje to krótkie spowolnienie, podczas gdy program czeka na kompilację, ale potem nie ma narzutu wydajności, ponieważ kod został skompilowany do natywnego kodu wykonywalnego.

Jest kilka zalet wydajności robienia tego w ten sposób zamiast kompilowania z góry na komputerze programisty. Aplikację można skompilować dla konkretnego procesora w telefonie, korzystając z jej funkcji sprzętowych i wykorzystując jej parametry wydajności. Na przykład może używać sprzętowych operacji zmiennoprzecinkowych, jeśli procesor to obsługuje. Ponadto sprytny kompilator JIT (co prawda Dalvik nie jest aż tak sprytny) może monitorować sposób działania programu i przeprowadzać optymalizacje w oparciu o sposób, w jaki program jest używany. Może przekompilować kod z lepszym podpowiedziami oddziału, gdy zobaczy, które opcje są włączane i wyłączane w twoim otoczeniu, na twoim telefonie. Kompilator początkowy nie ma tych informacji do użycia.

Dalvik używa pamięci podręcznej Dalvik i innych technik w celu złagodzenia wad kompilacji JIT. Nowa JVM dla Androida L i nowszych, ART, zastępuje JIT całkowicie kompilatorem z wyprzedzeniem . To kompiluje kod bajtowy do natywnego kodu wykonywalnego po zainstalowaniu aplikacji, aby uzyskać większość zalet JIT bez opóźnienia ładowania aplikacji.

Nie zapominaj, że aplikacje na Androida nie składają się całkowicie z Javy. Deweloperzy mają NDK do pisania wszystkich lub części swoich aplikacji w C lub C ++, dla krytycznych pod względem wydajności części aplikacji, szczególnie dla gier. Interfejsy specjalnego przeznaczenia, takie jak OpenGL i Renderscript, pozwalają programistom korzystać ze specjalnego sprzętu, takiego jak koprocesor GPU i SIMD, do niektórych rodzajów obliczeń.

Tak naprawdę nie ma prostej odpowiedzi na twoje pytanie. Korzystanie z JIT zamiast kompilacji z góry powoduje, że niektóre rzeczy są szybsze, a niektóre wolniejsze. To tylko jedna część ogólnej wydajności systemu operacyjnego.

— Dan Hulme
źródło

+1 za świetne wyjaśnienie. Tak naprawdę czekałem na taką odpowiedź.

— MANI

Naprawdę niewiele różni się od starej, zmęczonej debaty „.NET / Java vs. C ++ performance” na PC. To jabłka i pomarańcze.

— Aaronaught

@ArmonSafai Całkiem tak.

— Dan Hulme,

@MTilsted: To trochę prawda, ale zapisuje prawie wszystko w pamięci podręcznej, więc to, o czym mówisz, najprawdopodobniej wydarzy się tylko przy pierwszym uruchomieniu aplikacji.

— Aaronaught

Głównym problemem jest to, że Dalvik jest traktowany jako „normalny” JVM. Między opieraniem się na rejestrach, w przeciwieństwie do stosu, takiego jak HotSpot (ze względu na naturę procesorów ARM w porównaniu do tych, których HotSpot był celem [takich jak IA32]), jest użycie Zygote i koncepcja plików odex (tj. Cała idea nie [mniej więcej] przechodzenie prosto z pliku klasy do modułu ładującego klasy), traktowanie Dalvik jako normalnego JVM z pewnością spowoduje pewne nieporozumienia. Zwłaszcza, że wiele szczegółów implementacji HotSpot często jest błędnie kojarzonych z JVM w ogóle (jak na przykład kompilator JIT).

— Selali Adobor

Ponieważ jest to szerokie pytanie, oto szeroka odpowiedź.

„Czy aplikacje na iOS są szybsze niż aplikacje na Androida, ponieważ aplikacje na Androida są interpretowane?”

Po pierwsze, aplikacje na iOS nie są „szybsze niż” aplikacje na Androida.

Po drugie, w odniesieniu do problemu „Interpretowane są aplikacje na Androida”. To jest coś, co powiedziałbyś o komputerach, na przykład „15 lat temu”: jak widać z powyższej dyskusji, sytuacja jest dziś znacznie bardziej skomplikowana; wysunęły się całkowicie nowe technologie. Pojęcie „skompilowane jest szybsze niż interpretowane!” było istotne, porównując, perl, z kodem maszynowym 20 lat temu; sprawy potoczyły się tak bardzo, że problem nie może być dzisiaj tak naprawdę wyraźnie zastosowany do „iOS V Android”.

Po trzecie, istnieją inne problemy w programowaniu mobilnym, które całkowicie zapełniają takie względy. Tylko jeden przykład na ziemi, programiści mobilni znoszą się nad obsługą dużych przewijanych list obrazów, leniwego ładowania i podobnych problemów. W jaki sposób dwa systemy operacyjne i różne popularne biblioteki radzą sobie z tymi krytycznymi problemami, często zastępują inne.

Po czwarte, jeszcze jeden przytłaczający problem na telefonach komórkowych to problemy z chipsetem graficznym i różne skomplikowane relacje tego z oprogramowaniem, OpenGL i tak dalej. Na przykład Apple wychodzi z systemem, który nazywają „Metalem” w związku z tymi problemami, a Android ma swoje własne „rzeczy” w tej dziedzinie. Te problemy wokół potoku graficznego są niezwykle ważne dla tego, jak „czują się” aplikacje w twojej dłoni.

Bardzo krótka odpowiedź na twoje pytanie brzmi: „skompilowane V. interpretowane” jest w zasadzie przestarzałym punktem dyskusji, wiesz?

(Ponadto nie uważam szczególnie Note3 za „wolniejszego” niż iPhone'a. Niektóre z nich to czysty artefakt - istnieją niedrogie telefony z Androidem: po prostu nie ma produkowanych iPhone'ów o niskiej wydajności, więc niektóre osoby mogą mieć nieprawidłowe pomysły z tego.)

— Fattie
źródło

-3

Ponieważ interpretowane aplikacje nie oznaczają, że zawsze są wolne. Czasami są bardziej wydajne i dynamiczne niż skompilowane. Ponieważ wszystkie kody w skompilowanej aplikacji są kompilowane jeden raz, a dane wyjściowe są przechowywane w postaci bibliotek lub plików wykonywalnych, podczas gdy w języku interpretowanym, jeden raz może losowo zmienić kolejność wykonywania. Mogę więc powiedzieć, że zależy to od programisty i programisty.

Jednak Java (język programowania Androida) nie jest interpretowana, ale jest kompilowana w JIT. Oznacza to, że programy na Androida kompilują się tuż przed ich uruchomieniem, zapewniając względnie podobną wydajność do celu C. w iOS.

Niedawno platforma ART systemu Android wstępnie kompiluje aplikacje, więc działają one tak samo, jak aplikacje na iOS. Innymi słowy, kolejna wersja Androida będzie prawdopodobnie równie szybka jak iOS.

Aktualizacja

Języki programowania ogólnie dzielą się na dwie kategorie: skompilowane lub zinterpretowane. W skompilowanym języku wprowadzany kod jest redukowany do zestawu instrukcji specyficznych dla maszyny, zanim zostanie zapisany jako plik wykonywalny. W przypadku języków interpretowanych kod jest zapisywany w tym samym formacie, który wprowadziłeś. Skompilowane programy zwykle działają szybciej niż interpretowane, ponieważ interpretowane programy muszą zostać zredukowane do instrukcji maszynowych w czasie wykonywania. Jednak w języku interpretowanym możesz robić rzeczy, których nie da się zrobić w skompilowanym języku. Na przykład interpretowane programy mogą się modyfikować, dodając lub zmieniając funkcje w czasie wykonywania. Zwykle łatwiej jest też tworzyć aplikacje w interpretowanym środowisku, ponieważ nie trzeba ponownie kompilować aplikacji za każdym razem, gdy chcemy przetestować małą sekcję.

— See-Sharp
źródło

co masz na myśli: „raz możesz losowo zmienić kolejność wykonywania? A jak są one bardziej wydajne i dynamiczne? Również nie twierdzę, że są powolne, tylko że są wolniejsze, nawet nieznacznie.

— Armon Safai

To nie do końca prawda. Mylące jest twierdzenie, że brak konieczności ponownej kompilacji jest zaletą, ponieważ nadal musisz zbudować plik APK i wdrożyć go na urządzeniu testowym. Google nie zdecydowało się na korzystanie z Java: Android był już oparty na Javie, zanim Google go kupił. Pliki APK nie zawierają kodu „w tym samym formacie, który wprowadził [programista]”.

— Dan Hulme,

Microsoft .NET jest kompilowany do kodu IL, który jest interpretowany tak samo, jak Java jest kompilowana do kodu bajtowego.

— Esben Skov Pedersen

Wiele informacji w tej odpowiedzi naprawdę nie jest istotnych ani technicznie poprawnych. Szczerze zasugerowałbym, że odpowiedź ta zostanie całkowicie zmieniona pod względem technicznej dokładności.

— Aza

Java zasadniczo nie jest językiem interpretowanym , chyba że masz do czynienia z nietypową implementacją JVM. Kompilacja JIT to nie to samo co interpreter, więc większość tej odpowiedzi jest naprawdę nieistotna w kontekście wydajności Androida, ponieważ używa JIT.

— eldarerathis