Ważne
Nasz wybór

„Lagujący Android” i mit powolnej maszyny wirtualnej

Czytając komentarze, a czasami też artykuły na blogach, można przeczytać, że Android działa „wolno” (cokolwiek by to miało znaczyć), bo „jest źle zoptymalizowany” (cokolwiek by to miało znaczyć), „używa powolnej Javy” (cokolwiek by to miało znaczyć) czy „działa w maszynie wirtualnej” (cokolwiek by to miało znaczyć).

W tych zwrotach być może jest małe ziarenko prawdy, ale w większości są to tylko słowa-wytrychy obnażające niewiedzę dyskutantów i nieznajomość technologii, w jakich projektowane są współczesne mobilne systemy operacyjne. I nie mówię tego złośliwie – nie każdy musi interesować się technicznymi aspektami OS-ów, ale bez podstawowej wiedzy, dyskusje na temat wyższości iOS nad Androidem czy wyższością Androida nad WP są zazwyczaj całkowicie niekonstruktywne.

Rozprawmy się z mitem „wolnej Javy i maszyny wirtualnej”, które rzekomo zabijają wydajność Androida. Do porównania „szybkości” poszczególnych języków programowania wrócę później, ale na początek chciałbym zająć się kwestią wirtualizacji. Nie można jednak poruszyć tego tematu bez krótkiego przypomnienia jak działają aplikacje androidowe (oczywiście w pewnym uproszczeniu, bo wszystkich aspektów i narzędzi nie sposób omówić).

Dewelopera chleb powszedni

Zacznijmy od samego początku, czyli od ich tworzenia. Deweloper, używając wybranego zintegrowanego środowiska programistycznego (IDE, takie jak Android Studio czy Eclipse) tworzy kod źródłowy aplikacji używając do tego języka Java (oraz opcjonalnie C++, ale o tym w dalszej części), androidowych bibliotek oraz API dostarczanego przez Google. Po zakończeniu procesu tworzenia kodu, debuggowania (usuwania błędów) i testowania, ostateczny kod źrodłowy jest kompilowany. Co do zasady, można w zasadzie wyróżnić dwa rodzaje kompilacji – kompilację bezpośrednio do kodu maszynowego (Assembler – pojedyncze rozkazy dla procesora) oraz kompilację do kodu przejściowego (IL, bytecode), który później kompilowany jest przez maszynę wirtualną na konkretnym urządzeniu (np. smartfonie) do kodu maszynowego.

Języki, takie jak C czy C++ (również Objective-C i Swift używane w iOS i OSX), kompilowane są bezpośrednio do kodu maszynowego na maszynie programisty. Zapewnia to w teorii lepszą wydajność, bo usuwa jedną warstwę pośrednią w systemie, ale ogranicza przenośność kodu, bo z uwagi na różne architektury procesorów, każdy czip musi dostać kod maszynowy dostosowany do jego zbioru rozkazów czy długości rejestrów. Z tego powodu każda rodzina urządzeń musiałaby dostać własną paczkę ze skompilowaną aplikacją – dostosowaną do architektury odpowiedniego czipu. W przypadku urządzeń Apple, gdzie firma ma pełną kontrolę nad sprzętem i jego architekturą, język kompilowany do kodu maszynowego ma rację bytu i jest preferowany właśnie ze względu na lepszą wydajność.

Języki takie jak Java (używana do tworzenia aplikacji dla Androida) czy C# (używany do tworzenia aplikacji dla Windows Phone czy aplikacji uniwersalnych dla W10) kompilowane są do kodu przejściowego (bytecode), co pozwala na ich dużą „przenośność”. O co chodzi? Android czy Windows muszą wspierać setki czy tysiące urządzeń o najróżniejszych architekturach. Bezpośrednia kompilacja kodu źródłowego do kodu maszynowego nie miałaby tu racji bytu, bo musiałyby powstać dziesiątki wersji tej samej paczki dla poszczególnych aplikacji – wersji dostosowanych do każdej z architektur (choć podstawowych architektur jest tylko kilka, to każdy model wykorzystuje dodatkową optymalizację kompilatora, wykorzystując w pełni unikalną budowę procesora). Po kompilacji do kodu przejściowego na maszynie programisty (np. twórcy aplikacji), kod przejściowy jest kompilowany do kodu maszynowego, ale odpowiada za to maszyna wirtualna działająca na konkretnym pojedynczym urządzeniu (użytkownika końcowego). Zatem ostateczna kompilacja do rozkazów procesora odbywa się lokalnie na przykład na smartfonie – zwykle w czasie rzeczywistym, czyli w momencie uruchamiania poszczególnych aplikacji.

Wróćmy jednak do naszego dewelopera, który tworzy androidową aplikację. Skończyliśmy na skompilowaniu naszej gotowej aplikacji do kodu przejściowego. Co dalej? Wynikiem kompilacji jest paczka .apk, która wysyłana jest bezpośrednio do sklepu Play poprzez odpowiednie narzędzia (zwykle przeglądarkę z zalogowanym kontem deweloperskim). Paczka ta to zwykłe archiwum typu .zip, które możemy otworzyć i podejrzeć zgromadzone tam pliki. Co w niej znajdziemy? Oprócz grafik, logotypów, opisów czy bibliotek (i kodu maszynowego skompilowanego z C++, o czym później) – czyli tak zwanych „zasobów”, zobaczymy tam binarne pliki .dex zawierające kod przejściowy (bytecode) dla maszyny wirtualnej Javy, czyli środowiska uruchomieniowego obecnego na każdym urządzeniu z tym systemem. Co dalej? Po kolei. Deweloper wrzuca appkę do weryfikacji i jeśli proces ten przejdzie pomyślnie, dostępna ona będzie do pobrania w sklepie Play. Użytkownik mający urządzenie z Androidem może, poprzez sklep, pobrać taką aplikację (w praktyce pobiera plik z paczką .apk) i zainstalować ją na swoim smartfonie czy tablecie.

ART_Dalvik_architecture.svg

W tym momencie sytuacja się rozgałęzia. Wersje Androida do 4.4 włącznie korzystały ze środowiska uruchomieniowego o nazwie Dalvik, które wykorzystywało maszynę wirtualną typu JIT. JIT, czyli just-in-time, oznacza, że maszyna wirtualna kompiluje kod przejściowy do kodu maszynowego w czasie rzeczywistym. Poszczególne bloki kodu są kompilowane wtedy, gdy wymaga tego uruchamiana aplikacja czy działanie wewnątrz niej. Co prawda już od wersji 2.2 (Froyo) Dalvik stosował tak zwany trace-based-JIT, czyli prekompilację do kodu maszynowego pewnych często wykorzystywanych bloków kodu, w celu przyspieszenia wydajności. Co do zasady jednak, całość była kompilowana „na bieżąco”, w trakcie uruchamiania i korzystania z danej aplikacji.

Android 5.0 domyślnie zastąpił Dalvika środowiskiem uruchomieniowym ART (Android Runtime), którego maszyna wirualna, w odróżnieniu od poprzednika, działa w trybie AOT, czyli ahead-of-time („z góry”). W praktyce oznacza to, że aplikacja nie kompiluje się do kodu maszynowego przy jej uruchomieniu, a już na etapie jej pierwszej instalacji na urządzeniu. Pozwala to na usunięcie narzutu i konieczności kompilacji w czasie rzeczywistym, ale zwiększa zajętość pamięci wewnętrznej, bo system musi przechowywać na stałe zarówno plik .apk, jak i skompilowany kod maszynowy. Benchmarki i inne testy pokazały jednak, że przejście z Dalvika na ART nie przyniosło żadnych spektakularnych skoków wydajności, a przy wykonywaniu niektórych algorytmów wręcz obniżyło to wydajność.

I to w zasadzie tyle – niżej jest już tylko linuksowe jądro systemu wraz z systemami bezpieczeństwa, sandboksami, managerami wejścia/wyjścia, kontrolą procesów i innymi niskopoziomowymi zadaniami systemu operacyjnego. Dlaczego więc mówi się, że Android jest wolniejszy od Windows Phone? Czy wina leży własnie po stronie maszyny wirtualnej? Powolnej Javy?

Android a Windows Phone (i 10 Mobile) – realne różnice

Największym zaskoczeniem dla niektórych będzie pewnie informacja, że Windows Phone, Windows 10 czy Windows 10 Mobile, do aplikacji dotykowych działających w środowisku uruchomieniowym WinRT (Windows Runtime), również wykorzystuje maszynę wirtualną. Tak, C# jest językiem, który kompilowany jest do kodu pośredniego (bytecode) dokładnie tak jak Java. Dopiero Common Language Runtime (CLR), czyli maszyna wirtualna tego środowiska, kompiluje kod przejściowy do kodu maszynowego. Dokładnie tak jak w Androidzie.

Jakim cudem więc jednordzeniowe smartfony z Windowsem Phone 7 chodziły często płynniej niż androidowe kombajny z 4 rdzeniami? Słowo klucz to „płynniej”. A płynności nie możemy mylić z szybkością czy mocą obliczeniową. Jeśli porównalibyśmy benchmarki procesora albo grafiki, cztery rdzenie Androida rozgromiłyby sprzęt z WP7 w każdym podejściu. Tak samo Android miałby niekwestionowaną przewagę w grach 3D. Nie da się przeskoczyć fizycznego braku mocy obliczeniowej. O co więc chodzi z tą płynnością? Microsoft osiągnął ten efekt kosztem wielu wyrzeczeń. Aplikacje miały bardzo duże ograniczenia w komunikacji między sobą i z systemem, ograniczone było ich działanie w tle, brakowało powiadomień, dostępu do systemu plików, itd… Pozorna płynność dawnego Windows Phone wynikała z zamkniętości i ograniczeń tego systemu.

800px-CLR_diag.svg

Potem jednak przyszedł WP8, WP8.1 i zbliża się W10 Mobile i… różnica w płynności staje się coraz mniej zauważalna. Microsoft wyposaża swój system w coraz to nowe funkcje i potrzebuje do tego równie mocnego sprzętu, co Android. Czasy płynnych jednordzeniowców już dawno się skończyły. Co prawda nowy Windows dalej ma (moim zdaniem) pewne przewagi wydajnościowe nad Androidem, dzięki uważniejszej kontroli procesów i ostrzejszą politykę dostępu do niższych warstw systemu oraz działania w tle, ale Google nie śpi i stopniowo łata swój system, wprowadzając zmiany na poziomie architektury, kolejkowania zadań czy zarządzania procesami. Android zaczynał od systemu maksymalnie otwartego, pozwalającego aplikacjom na wszystko (stąd problemy z wydajnością i baterią), a Windows odwrotnie – od systemu w pełni zamkniętego i szczelnie kontrolującego swoje aplikacje. Wygląda na to, że oba te systemy spotkają się wkrótce gdzieś w połowie drogi.

Czy język programowania może być szybki?

Przyjęło się mówić, że języki interpretowane są wolniejsze od kompilowanych. W największym skrócie – to prawda. Języki, które na lokalnej maszynie są interpretowane bezpośrednio z kodu źródłowego (tekstowego) do kodu maszynowego działają zazwyczaj wolniej. Tak jest w przypadku JavaScriptu (choć nie zawsze jest on interpretowany), PHP czy Pythona. Nie wszędzie jednak wydajność jest tak cenna jak pełna przenośność kodu. Trzeba jednak pamiętać, że Java czy C# nie są językami interpretowanymi. Są to jak najbardziej języki kompilowane, z tym że kompilacja jest dwuetapowa – najpierw kompiluje się do kodu przejściowego, a dopiero potem do kodu maszynowego (w trybie JIT lub AOT). Oczywiście konieczność lokalnej kompilacji to jest pewien narzut zasobów (w tym wykorzystania przestrzeni adresowej, stosu czy pamięci RAM), ale różnice nie są tak duże, jakby się można było tego spodziewać. W skrócie – nie w tym leży problem „wydajności Androida”. Mało tego – kompilacja JIT (just-in-time) daje pewne przewagi, z uwagi na to że lokalny kompilator „zna” obecny stan systemu i jego kontekst, dzięki czemu wynikowy kod maszynowy może być dodatkowo optymalizowany uwzględniając lokalne uwarunkowania w danym momencie.

Ale to jeszcze nie wszystko. Zarówno aplikacje dla Androida jak i Windowsa mogą zawierać biblioteki i kod pisany w C++, czyli języku bezpośrednio kompilowanym do kodu maszynowego. I jest to bardzo częsta praktyka. Gotowe algorytmy do przetwarzania grafiki, wideo, obliczania najkrótszej drogi w nawigacji, gry oraz inne zasobożerne zadania zwykle pisane są właśnie w C++. W teorii nic więc nie stoi na przeszkodzie, żeby programy te działały tak samo szybko, jak na iOS (gdzie Objective-C i Swift są kompilowane od razu do kodu maszynowego). W praktyce nie jest to do końca prawdą, choćby ze względu na dostępne frameworki. Metal dla iOS pozwala na „dobranie się” do niskopoziomowych zasobów procesora i grafiki, co sprawia, że teoretyczne słabsze procesory w urządzeniach Apple’a, osiągają lepsze wyniki w benchmarkach niż ich 8-rdzeniowi rywale. Ale Apple to Apple -mając zaledwie kilka smartfonów w swojej ofercie, na dodatek wyposażonych w taką samą architekturę, można sobie na coś takiego pozwolić. W przypadku Windowsa 10, który rozszerza wsparcie nie tylko dla Snapdragonów, ale też intelowskich Atomów, taka sprzętowa optymalizacja będzie coraz trudniejsza. Nie wspominając o Androidzie, który musi wspierać dziesiątki czy setki rożnych czipów.

Od czego więc zależy szybkość języka programowania? Język sam w sobie nie jest szybki i tak naprawdę ten sam język może być zarówno interpretowany, jak i kompilowany. Powiedzieliśmy już, że zazwyczaj kompilacja działa szybciej niż interpretowanie. Idąc dalej, kompilacja bezpośrednio do kodu maszynowego (co do zasady) działa szybciej niż dwuetapowa kompilacja z pośrednim etapem kodu przejściowego. Pozostałe kwestie „szybkości” języków w dużej mierze zależą od jakości kompilatora czy interpretera. To tutaj powstaje duże pole do popisu dla twórców tych narzędzi. A optymalizacja kompilatora w pewnej mierze zależy też od samej składni i możliwości języka. Okazuje się, że dzięki bardziej rozbudowanym strukturom danym, C++ daje się lepiej „optymalizować” niż zwykły C, bazujący na prostych strukturach i wskaźnikach. Do tego dochodzą kwestie narzutu pamięci związanego z zarządcą pamięci (GC, garbage collector) czy wczytywaniem niepotrzebnych bibliotek. Ale w tym momencie wchodzimy w szczegóły, które tak naprawdę nie mają większego znaczenia dla prawdziwej wydajności większości aplikacji. Bo powiedzmy sobie szczerze – zaledwie mały procent appek rzeczywiście wymaga uzasadnionego użycia „szybkiego” C++.

benchmarksJan2009Final

Analizy kodu i wydajności aplikacji dla Androida pokazały, że największym problemem są… źle napisane aplikacje. Wąskim gardłem okazywał się nie procesor czy pamięć RAM, a zbyt dużo niepotrzebnych odwołań do pamięci, co szczególnie w przypadku słabszych urządzeń z wolniejszymi modułami, może się okazać bardzo niekorzystne. Oczywiście Google i jego Android, ale również Microsoft z Windowsem dalej powinny walczyć nad poprawkami w środowisku uruchomieniowym, zarządzaniu pamięcią czy w końcu kompilatorach, ale to często użytkownik instalując kiepsko napisane, zasobożerne aplikacje i przypinając wiele „niepotrzebnych” widgetów sam utrudnia sobie życie. Osobną kwestią jest to, że takie aplikacje przechodzą pozytywną weryfikację w sklepie, a samo Google ma dość luźną politykę uprawnień i dostępu do funkcji systemu dla appek firm trzecich.

Do tej pory nie wspomniałem o wyjątkowo słabo napisanych nakładkach UI na Androida, które często są głównymi winowajcami, jeśli chodzi o spowolnienie działania urządzenia. Trzeba pamiętać, że są to nakładki producentów sprzętu, czyli firm, które rzadko specjalizują się w pisaniu dobrego, szybkiego kodu i dostrajania go. Firmy te zmagają się z ciągłym wyścigiem z czasem – po premierze nowej wersji Androida mają kilka miesięcy na stworzenie autorskiej nakładki i dystrybucję jej do urządzeń użytkowników. A poszczególnych modeli mają często dziesiątki. Im więcej warstw w systemie, im więcej firm trzecich, które mogą w to ingerować, tym więcej miejsc, gdzie coś może pójść nie tak. I to pewnie dlatego Apple nieprzypadkowo uznawany jest za producenta szybkich i stabilnych urządzeń o tak naprawdę przeciętnej specyfikacji.

Nasz wybór

Jeżeli znalazłeś literówkę w tekście, to daj nam o tym znać zaznaczając kursorem problematyczny wyraz, bądź zdanie i przyciśnij Shift + Enter lub kliknij tutaj. Możesz też zgłosić błąd pisząc na powiadomienia@tabletowo.pl.

Komentarze

  • vasper

    Świetny artykuł.

    • Dzięki :) Wypiłem rano jedną kawę za dużo i jakoś się tak samo napisało

      • stiopan

        Szkoda że to Pan nie jeździ na #Buildy zamiast pana G.

        • Też nad tym ubolewam :(

          • stiopan

            Czas pomyśleć :)

        • Jeśli mi będzie zależeć bardzo to zapiszę się i polecę :) To bardziej towarzyska impreza i okazja do poznania ludzi, bo wszystkie materiały i sesje można pobrać i obejrzeć z channel9, a nawet oglądać na żywo i zadawać pytania podczas paneli.

          • stiopan

            Towarzyska. Tyle że w tym roku była dość istotna a zabrakło tam kogoś kto by ten temat ogarniał.

          • Może to? :)

            Spis treści:
            1. Uniwersalne Aplikacje
            2. Windows 10 dla smartfonów
            3. Pełny Windows 10 i przeglądarka Edge
            4. Aplikacje z Android i iOS na Windowsie
            5. Nowy interfejs użytkownika – geneza
            6. Xbox, gry i HoloLens

            http://www.tabletowo.pl/2015/05/02/build-2015/

          • stiopan

            Znam, ale to podsumowanie. Bardziej chodzi mi o relację na żywo ( w granicach rozsądku)

          • To chyba bez sensu, IMHO. Jeśli jedziesz tam, to nie po to, żeby klepać z kolan relację, którą można na żywo oglądać w necie. Szczególnie na eventach merytorycznych. Przynajmniej ja nie widzę sensu robienia live-blogów z wydarzeń, które są powszechnie dostępne z obrazem i dźwiękiem. Tak naprawdę sercem Buildów są poszczególne panele, gdzie jest interakcja, pytania, itd… A dwa keynote’y? Fajnie, ale poza błyskotkami i głównymi ogłoszeniami – żadnych smaczków tam nie uświadczymy ;)

          • stiopan

            No właśnie, gdzieś tam przewinęło się info o drukowaniu bezpośrednio ze smartfona (b. ważne dla mnie) i tematu prawie nie ma. Umarł?

          • Wg mojej wiedzy, przynajmniej trzy uniwersalne appki Office’a na smartfony będą wspierały wireless printing. Nie wiem czy appki nie-microsoftowe to dostaną. Ale najwyraźniej system to wspiera.

          • stiopan

            Pośmiecę trochę pod dobrym artykułem. Czyli jest szansa na Outlooka z wydrukiem załączników?

          • Wydaje mi się, że tak, ale raczej na zasadzie – otwórz pojedynczy załącznik -> wydrukuj

          • stiopan

            Ok, tyle mi wystarczy. Dziękuję.

      • qba

        Trzeba było nie pić, bo z tą przeciętną specyfikacją iPhone oraz iPad to pojechałeś.

        W każdym benchmark zobaczysz że mają największą wydajność z jednego rdzenia, grafiki oraz pamięci

        • A co ma wspolnego specyfikacja z benchmarkami?

          • qba

            Bardzo dużo bo pokazuje że te podzespoły są z najwyższej półki

          • Dobry wynik w benchmarku pokazuje jedynie że dany system… osiąga dobre wyniki w benchmarkach. Oczywiście istnieje zależność od hardware, ale nie można tego utożsamiać.

          • qba

            System nie ms aż tak dużego wpływu na wydajność procesora, grafiki z pamieci

          • Na wydajnosc procesora nie ma zadnego, ale na wyniki benchmarkow napisanych jako aplikacji danego systemu – jak najbardziej tak

          • qba

            Minimalne

          • False :)

          • qba

            Udowodnij :)

            W sytuacji gdy Android i Windows Phone mają praktycznie tyle samo fps na tym samym modelu procesora

          • DirectX 12 :)

          • system steruje częstotliwością procesora i magistral (governor) więc od tej strony ma wpływ na jego wydajność, na wydajność aplikacji tez ma wpływ (scheduler i tryb w jakim on pracuje oraz scheduler I/O). Z ich ustawień mozna tworzyć profile, które albo oszczędzają baterię albo umożliwiają wydajną pracę zależnie od potrzeb.
            Jedyne na co system pływu nie ma to maksymalna wydajność poszczególnych magistral i rdzenia CPU bo ta wynika z konstukcji

          • qba

            No a mowa o maksymalnej wydajności.

          • System limituje maksymalną wydajność (ze względów termicznych i oszczędzania baterii). Dlatego Samsung i HTC oszukiwali odblokowując w systemie CPU i GPU, gdy wykryto, że aplikacją jest benchmark ;)

          • Do tego dochodzi kwestia wykorzystania rdzeni, czego najlepszym przykładem jest DX11 vs DX12.

          • prawda, zwykle rdzenie można dowolnie wyłączać (a do tego każdy może chodzić na innej częstotliwości)

        • aquarius01

          Zostało to dokładnie wyjaśnione w artykule. Są przeciętne ale ogromną optymalizacja juz na etapie projektu pozwoliła na osiąganie lepszych osiągów.

  • dareczq

    bardzo dobry artykuł

  • Asdh

    Dobry i szczegółowy, żadnego lania wody, super

  • wrox

    Musze przetrawić na spokojnie, ale oby więcej takich tekstów pozwalających zrozumieć urządzenia z których korzystamy

  • mobilnymaniak

    Malutki błąd po ‚CZY JĘZYK PROGRAMOWANIA MOŻE BYĆ SZYBKI?’ w drugim zdaniu ;-)

  • RA

    „Pozorna płynność dawnego Windows Phone wynikała z zamkniętości i ograniczeń tego systemu”

    Skoro piszesz, że MS świadomie postawił na płynność kosztem funkcjonalności, to sami są sobie winni porażki. Jeszcze raz okazuje się, że „kto wyb­rał chwi­lową iluzję, by na niej za­robić, ten prze­minie wraz z iluzją”.

    • Jeśli chcesz wykorzystywać ten wpis do wojenek fanbojów systemów operacyjnych, to zadajesz mi ból psychiczny ;)

      • RA

        Obiecuje, że nie wykorzystam :)

        • Jeśli pytasz bez zaczepki, to odpowiem.

          To nie była świadoma decyzja MS. Tworząc WP7 tworzyli zupełnie nowy system operacyjny, następce Windows Mobile 6.x po prostu nie zdążyli z wszystkimi funkcjami na dzień premiery i dodawali je przez kilka kolejnych lat, aż w 2014 roku zbliżyli się funkcjonalnością do Androida. Dodawali je stopniowo, zachowując płynność systemu. Dla jednych to zaleta, dla innych dyskwalifikacja.

          • Raul

            Ja nadal się zastanawiam po co im był ten WP7. Mieli Windows Mobile 6.5 (i pseudo WinMobile 7, które swoją droga podobało mi się bardziej niż kafle), wiadomo ze to nie byl system ktory mogl walczyc z iOS czy Androidem, ale miał sporo oprogramowania. Mogliby nawet wypuszczac dualboty do czasu aż WP (przyjmijmy ze 8ka) stalby sie pelnoprawnym produktem. Mogliby to zrobic w ciagu 3 lat, doprowadzajac do tego, ze oprogramowanie pisane pod WM 7 działałoby na 8 (lub wymagaloby tylko rekopilacji).

    • vvaz

      Apple bardzo dobrze na tym wychodzi.

    • Adam Ak2K

      ale przecież windows 8.1 jest płynny o_O

      • mozilla007

        System tak ale do czasu jak nic nie uruchomisz, bo później masz często płynne kropki.

        • Adam Ak2K

          no chyba na komputerze z 1992 roku :D

    • Artur Węgliński

      O apple tego napisać nie możesz a jakoś sobie radzą.

  • zzzz

    Brawo , znowu super art, autora.

  • Świetny artykuł Panie Piotrze. Przede wszystkim nie jest płachtą na „fanbojów systemów” :)

  • Konkurent

    Niby super tekst, a nieścisłości jak zwykle są:
    – Android 4.4.4 miał już opcjonalne ART, a nie dopiero od 5.0
    – w przypadku ART kompilacja następuje podczas pierwszego uruchomienia, a nie podczas instalacji !

    To tak na szybko zauważone na szybkim przewijaniu, pewnie znalazłoby się więcej, ale szkoda czasu jeśli to ma być the best of Tabletowo.

    • 1. „Android 5.0 domyślnie zastąpił Dalvika”, sprawdź w słowniku „domyślnie”
      2. nie

      Brak mi słów na takich trolli i mitomanów. Odsyłam do oficjalnych materiałów Google’a.

      „At install time, ART compiles apps using the on-device dex2oat tool.”
      https://source.android.com/devices/tech/dalvik/index.html

      • Andrzej Pszczółka

        Właściwie super wyjaśnione, czemu czytelnik wytykając Ci błędy się mylił. Ale te zdania o trollach, mitomanach i braku umiejętności czytelnika, to mógłbyś sobie darować. Szczególnie, jeśli merytorycznie przedstawiłeś czemu masz rację. Nie lepiej okazać czytelnikowi jakikolwiek szacunek, nawet jeśli on nie potrafi się tym odwzajemnić?

  • Raul

    Czepiłbym się tylko stabilności jeśli chodzi o Apple, to tak różowo nie wygląda, szczególnie jak ktoś aktualizuje nienajnowsze modele do nowych wersji. Nie wiem co Apple robi ale coraz częsciej system nie jest wersja beta dopiero po kilkunastu poprawkach.

    Co do optymalizacji oprogramowania to widać, że nawet takim tuzom jak Samsung się nie chce. Skoro za chwilkę wydadzą procesor szybszy o kolejne 30% od poprzednika. Gdyby pomyśleli, to wyszło by im, że po takiej aktualizacji np. TouchWiza nagle ich sprzęt nie przycina (zawsze mozna wgrac poprawkę z xda, chłopaki robią niezłe cuda).

    • qba

      Przecież pomyśleli bo TouchWiz po aktualizacji systemu do 5.0 stał się lekki i płynny

      • Raul

        To krok w dobrym kierunku ale na takim sprzecie to TW powinien smigac bez zaciec.

    • iPhone 3G chyba pierwszy wprowadził aktualizacje która celowo (według części ludzi) spowalniała system. Później niby wprowadzili poprawkę która wyeliminowała ten „błąd”, ale i tak system lagował. To samo było z iPhone 3GS oraz iPadem 1G. Te trzy urządzenia posiadałem, więc wiem coś o tym, zresztą 3GS niedawno musiałem znów używać, a iPada nadal mi się zdarza. Wywalające się aplikacje na świeżym systemie to norma (nawet systemowe).
      Problem by może nie był tak duży gdyby można było bez problemu wrócić do poprzedniej wersji.

  • trzy_grosze

    Szkoda że w tym artykule nie został wspomniany poprzedni „król smartfonów” czyli s60 od Nokii, ale w sumie to tylko by minimalnie uzupełniło obraz rozwiązań mobilnych.
    Praktycznie ten system występował od pierwszego N-Gage i kilku starszych modeli do N97, później już były Anna, Belle i inne ^3.
    Bodajże w przypadku s60 aplikacje również były kompilowane na sztywno a mimo to przenośne w jakiejś skali. Chyba najmniej przenośnym programem był N-Gage 2.0, którego i tak scena modderska dostarczała na inne urządzenia jak C6-00 czy słabsze N73.

    Jeszcze wypadałoby wspomnieć o Windows Mobile i Windows CE.

    Pewnym jest że firmie Google udało się to, co się nie udało Nokii czyli wydanie naprawdę przenośnego systemu. s60 był domeną Nokii i chyba na palcach jednej ręki można policzyć Motorole, Siemensy czy Samsungi z s60.

    Szkoda że trochę Android zaczął się psuć za sprawą nakładek, które na początku usilnie instalował HTC żeby „ujednolicić” doświadczenia urządzeń WM z Androidem.

  • AndroidDev

    Proponuję zainstalować Androida 5.x na Nexus 7 2012.
    Tyle w temacie lagowania.

    ps. co do samego języka i VM, oczywiście się zgadzam ;)

    • qba

      Laguje i to bardzo

    • ehh

      Idiotyczne porownanie, gdyby nowe rozbudowane systemy nie lagowaly na starym sprzecie, to jaki sens bylby tworzyc nowe bardziej wydajnosciowe procesory i po co postep w informatyce?

  • karolmarks

    Bardzo wartościowy tekst. Dodatkowo duży plus za obiektywizm.
    Miałbym jedną uwagę do dodania:
    Sposób w jaki odpalane są aplikacje w WP8, czyli migające kropeczki. Użytkownikowi wydaje się że system działa mu płynniej bo nie klatkuje mu żadna animacja (co zdarza się czasami w androidzie).
    Nie wiem jak było w WP7, ale WP8 na Nokii 735 nie jest moim zdaniem takim znowu demonem prędkości. Motorola G z podobnymi bebechami wcale mu nie ustępuje.
    Moim zdaniem największym problemem Androida jest zamulanie sprzętu wraz z upływem czasu.
    Ale to samo można powiedzieć o stacjonarnym Windows. Sprzęt, który kilka lat do tyłu stanowiłby superwydajną stację roboczą do renderowania Gwiezdnych Wojen obecnie pobłażliwie określa się mianem „do pracy biurowej” czyli dla sekretarki do sklecenia kilku zdań w Wordzie ;)

    • Podobne zdanie mają niektórzy ludzie o iOS, też twierdzą, że z upływem czasu zaczyna mulić. Choć oni twierdzą, że spowodowane jest to zapełnieniem pamięci na dane użytkownika, a nie Ram, czy też śmieciami w samym systemie (co jak dla mnie nie powinno mieć większego wpływu na wydajność).

  • RDF2

    „Pozorna płynność dawnego Windows Phone wynikała z zamkniętości i ograniczeń tego systemu.”
    Kolega zapewne nie zaliczył logiki, prawda?
    Jeżeli aplikacje były „ograniczone”, aby pracować płynne i efekt osiągnięto, to płynność nie była pozorna, tylko rzeczywista. Prawda? ;)
    Poza tym w WP8.1 wszystko to odblokowano, a aplikacje sa nadal super płynne – bez porównania z tymi androidowymi. Wystarczy uruchomić mapy HERE na WP i androidzie.
    Różnica w kulturze pracy jest szokująca.

    • Plynnosc byla pozorna, bo wystarczylo odpalic zasobozerne zadania i po plynnosci nie bylo sladu.

      • RDF2

        Nadal nie rozumiesz.

        • ehh

          Takiego „geniusza” jak ty to naprawde trudno zrozumiec :(

      • RDF2

        Zaplusowałeś kolegę, który postanowił mnie obrazić tylko dlatego, że nie rozumie tego co czyta. Smutne. Myślałem, że mam do czynienia z kimś poważnym.
        To co napisałem jest naprawdę proste. Powinien to zrozumieć nawet ktoś, kto produkuje się na portalach dla 15-latków..

        • Chyba masz zbyt cienką skórę, żeby przebywać w sekcji komentarzy ;)

          PS: WP8.1 nie jest płynne. „loading…” I „resuming…” to plaga na słabszych modelach.

          • RDF2

            co to ma wspólnego z płynnością aplikacji?

          • Z płynnością nic. Z jej brakiem – bardzo wiele.

          • RDF2

            aplikacje są super płynne. nie spotkałem sie jeszcze z taką, która sprawiałaby problemy.

            mylisz to ze wznawianiem w tańszych modelach (co jest naturalne i występuje również w iOS i androidzie – tak, używam wszystkich systemów).

            powtórzę: „Jeżeli aplikacje były „ograniczone”, aby pracować płynne i efekt osiągnięto, to płynność nie była pozorna, tylko rzeczywista. Prawda? ;)”
            nie potrafię tego prościej napisać – przepraszam/

          • 1. nie są superpłynne, mam w domu 4 telefony z WP (a testowałem pewnie ponad 10) i żaden nie jest superpłynny (najbliżej superpłynności była 1520, ale aparat i nawigacja in minus w kwestii płynności), a dwa z nich są „wystarczająco płynne”
            2. „wznawiane…” to jeden z przejawów braku płynności
            3. „Płynność pozorna”, czyli brak klatkowania animacji, ale długie ich ładowanie, przełączanie czy nawigacja wewnątrz nich

          • RDF2

            „aparat i nawigacja in minus w kwestii płynności), ”
            chyba żartujesz? co tam jest niepłynnego? HERE na androidzie jest sporo wolniejszy. aż specjalnie odpaliłem mojego NOTE i porównałem z 630 i 930.
            ok, możemy się tak jeszcze przerzucać przez dwa dni. cale szczęście, że mam swoje urządzenia i podczas wyboru sprzętu nie sugerowałem sie nigdy cudzymi opiniami. dzięki temu wiem, jak świetny jest windows phone.

          • Nie żartuje ;)

          • RDF2

            moje osobiste doświadczenia są całkowicie odmienne (oparte na codziennym użytkowaniu kilku urządzeń). tylko iOS i WP zapewniają idealną płynność i brak frustracji.
            co do androida, to posiadam NOTE2, galaxy alpha i galaxy TAB S – ich używanie to frustrujące doświadczenie – i nie chodzi o TW – aplikacje pracuja na nich po prostu kiepsko. nawet przeglądarka (szczególnie na TAB) nie pozwala na płynne przewijanie stron (bez szarpania). a to potrafi tablet za 300zł HP7
            ponad rok temu, przed zakupem 930 postanowiłem sprawdzić WP i zaopatrzyłem se w L630 – to było mocne zaskoczenie, ale to urządzenie jest szybsze i przyjemniejsze w użytkowaniu niż androidy z 8 rdzeniami i 3GB RAM. bardzo żałuję, że nie ma urządzeń klasy TAB S z windowsem.
            jestem zadowolonym użytkownikiem iOS/OSX/windowsa. androida nie kupię już nigdy

  • Pawel Zur

    Dlaczego nie ma tak jak na kompie Windows działa ten sam na wszystkich a telefony muszą mieć każdy inny

    • qba

      Nigdy nie słyszałeś o Linuksie, OS X ani Chrome OS?

    • I tak właśnie jest, Android jest ten sam na każdym telefonie, nie licząc oczywiście wersji i „poprawek operatora…”. Problem jest ze sterownikami do sprzętu. W Windowsie bez problemu można je doinstalować z osobna, Uniksie są częścią jądra, dlatego dla każdego modelu telefony trzeba kompilować system z osobna. Choć Unix desktopowy pozwala na instalacje z osobna, ważne aby taki sterownik był dostarczony w przystępnej wersji.
      Jeśli coś pokręciłem, to wdzięczny był bym za poprawę.

  • PanJaBu

    Bardzo ciekawy artykuł.
    Może jeszcze warto wspomnieć o ciekawym projekcie automatycznego portu źródeł androida w javie do .net w postaci XobotOS i wstępnych wynikach porównania wydajności.

  • fred
    • Marcin Wojciechowski

      Hehehehehehehehe ale się ubawiłem:) Dobre:)

  • uru28

    Nie mogę wyjść z podziwu jak można w tak przystępny sposób przedstawić tak skomplikowany temat. I nie jest kwestią Piotrze że masz wiedzę tylko że umiesz ją podać w zrozumiały sposób. Myślę że gdyby nauczyciele i wykładowcy informatyki mieli choć trochę twojego „daru” poziom w tym temacie był by zdecydowanie większy a ilość aplikacji z „zagmatwanym” kodem zdecydowanie mniejsza;)
    Mam porównanie gdyż po rozprawie nowo poznanego informatyka w temacie „maszyna wirtualna, a emulator” dowiedziałem się że to to samo,choć nie to samo a różnice widać zwłaszcza w wydajności :D
    To też z ogromną przyjemnością czytam Twoje teksty i polecam pić więcej kawy przy śniadaniu;)

  • rur6tu

    porownywanie gruszek do ciężarówek ;-)
    śmieszne,
    dziś już nawet nieaktualne bo dalvik odchodzi

  • slou

    W czasach ogólnej tandety – świetny artykuł. „Szacun&pozdro”

  • Dobra lektura. Ale odnośnie płynności – pytanie dotyczące RAMu – mam na tablecie Androida 5.0 i 2GB RAM, podczas przełączania się pomiędzy ostatnio używanymi appkami czasem te się uruchamiają ponownie zamiast grzecznie siedzieć otwartymi w pamięci. Szczególnie irytuje to przy szybkim przełączeniu się pomiędzy przeglądarką a np. notatnikiem. Ja rozumiem, że urządzenie na bieżąco dba o zasoby i zwalnia miejsce, ale czy można jakoś w ten proces ingerować np. dodając najpotrzebniejsze appki do wyjątków „zawsze aktywne w tle”?

    • Bez modowania, na zwykłym niezrootowanym telefonie – raczej nie.

    • avish

      Odpowiedź brzmi MIUI

  • Bartosz Mazur

    Bardzo dobry artykuł !

  • Sebastian Brochocki

    Dawno tak dobrze mi się nie czytało. Genialna umiejętność przekazywania wiedzy w ludzki sposób.

  • jacek

    Ja po prostu widzę co robi mój telefon…a on po prostu jest wolny że się odechciewa. Fakty że żadna rewelacja bo ACE3 ale powinien działac przynajmniej poprawnie. Nie działa.

  • Athame

    Pitolenie o szopenie. Co mnie obchodzi, że iOS ma jedną architekturę do obsłużenia, a Android wiele. Fakt konieczności stosowania kodu pośredniego jest właśnie głównym winowajcą pogorszenia wydajności i nawet ładne teksty nie zmienią tego, że bliźniacze aplikacje na dużo słabszym sprzęcie Apple’a działają wyraźnie płynniej niż na sporo mocniejszych (na papierze) urządzeniach z Androidem.

  • Mikołaj Dreja

    Wszystko pięknie i ładnie, bardzo dobrze napisany artykuł, problem jedynie w tym że nie wszystko co jest w nim napisane jest prawdą z technicznego punktu widzenia.

  • Sławomir

    Ekstra tekst. Proszę o więcej takich.

  • Ale i tak nadal Android potrzebuje więcej rdzeni i zdecydowanie więcej ramu niż konkurencyjne OS by działać w miarę szybko. Twierdzenie, że jest inaczej brzmi nieco śmiesznie jak się porówna parametry iPhone czy Lumii z parametrami flagowców z zielonym robocikiem na pokładzie :D

  • aquarius01

    Bardzo fajny artykuł. Przeczytałem z przyjemnością :)

  • Jakub Konieczny

    Brawo, świetny tekst i proste przedstawienie problemu.
    Co do WP, warto zauważyć, że jest tam jeszcze animacja wyjścia poprzedniej aktywności (nie wiem jak to jest w WP nazwane) przed animacją wejścia następnego, co daje kolejne kilka ms do załadowania aplikacji, w Androidzie od razu mamy animację wejścia nowej aktywności.

  • Damian Chiliński

    Arch ARM dziala na S3 bez wiekszych problemow w chroocie, jedyne czego mi brakuje to ludzkiego kernela bo to Samsungowe badziewie nawet nie wspiera ludzkich filesystemow. Natomiast fakt ze na S3 dziala w chroocie pelne KDE z compizem (sic!) I wodotryskami jeszcze wyswietlane po VNC z dzwiekiem przekierowanym na zdalny sink pulseaudio, a Opera na natywnym Andku wywala sie z braku ramu przy jednej karcie dobreprogramy.pl jest zenujacy I pokazuje jak bardzo Android spieprzyl sprawe. W ogole co za palant stwierdzil ze java to swietny plan na soft telefonow, no genialny tylko na raspie przy 256 mb ramu moze chodzic pelen server www, baza danych I caly linux a Android by chyba ledwo wstal. To jak bardzo kijowy to byl plan widac po typowych aplikacjach serverowych w javie ktore wymagaja chorych I nieuzasadnionych zasobow w porownaniu chocby do odpowiednika w node… Chocby taki pakiet Atlassiana. No sory ale ja nie widze tam nic uzasadniajacego zuzycie ramu na poziomie 4gb. Ja uzywam normalnego Archa w chroocie z KDE I dziala lepiej niz rom Samsunga wiec to jest jakas kompletna porazka, ale ok nie bede narzekal, mam co chcialem I dziala jest ok, dziala server ssh, vnc, kde, dolphin, chromium, apache, node, pulseaudio nawet przyjmuje zdalne requesty I dziala jako remote sink, dziala tyle rzeczy ze Android narobilby w galoty jakby mial pociagnac Androidowe odpowiedniki tego wszystkiego I to jeszcze na 180mb wolnego ramu bo reszte zajmuje… No wlasnie tak w zasadzie to nawet nie wiem co bo nic nie dziala a na idlu mam zawalone ponad 700mb ramu… gratulacje

  • T235

    Dobrze, że ktoś podlinkował na innym portalu, bo by mi taka perełka przepadła. Świetny tekst!

  • BogoMIPS

    Padło dużo stwierdzeń „Świetny tekst” w odniesieniu do artykułu, a nikt nie pochylił czoła nad Twoim „punktującym” wpisem. Swoją drogą… świetny tekst :)

Tabletowo.pl
Logowani/Rejestracja jest chwilowo wyłączona