+6Nasi autorzy

Czym jest ART i dlaczego nie musi być to lekarstwo na lagującego Androida

Dlaczego Android laguje? „Bo jest źle zoptymalizowany”. To bardzo ogólna i trochę myląca odpowiedź. Osoby, które miały choć trochę kontaktu z programowaniem, często odpowiadają, że problem leży w maszynie wirtualnej i środowisku uruchomieniowym Dalvik.

Jakiej maszynie?! Tabletowo to nie miejsce na niskopoziomowe rozważania na temat kodu maszynowego, kompilatorów czy środowisk runtime’ów, ale warto zrozumieć podstawy i to jak działa Android i aplikacje w nim uruchamiane. Zacznijmy od podstaw – zielony robot musi chodzić na najróżniejszych procesorach różnych architektur – w tym ARM i x86. Co z tego wynika? Taka uniwersalność warunkuje również uniwersalność skompilowanego kodu aplikacji. Same aplikacje tworzone są w języku Java, jednak po zakończeniu kodowania i testowania są one kompilowane. W przypadku iOS czy Windows Phone, aplikacje kompilowane są do kodu niskopoziomowego – maszynowego, czyli bezpośrednich rozkazów dla procesora. To rozwiązanie optymalne pod względem wydajności i szybkości. Android natomiast ze względu na konieczność zachowania uniwersalności i niezależności od architektur nie może być kompilowany do kodu niskopoziomowego.

Jak jest zatem kompilowany? Dotąd javowy kod aplikacji przekształcany był na wykonywalny kod w plikach .dex (Dalvik Executable Format) podczas instalowania aplikacji na urządzeniu. Jest to kompilacja wstępna, „średniopoziomowa”, uniwersalna dla wszystkich procesorów. Maszyna wirtualna czyli Dalvik VM jest środowiskiem uruchomieniowym dla tego kodu i ma za zadanie przetłumaczyć go na kod maszynowy, zrozumiały dla lokalnego procesora. Skomplikowane? A to dopiero początek. To właśnie ta konstrukcja jest problematyczna – maszyna wirtualna to dodatkowa warstwa systemu operacyjnego, a każda kolejna warstwa to konieczność dodatkowej komunikacji, a co za tym idzie wolniejsze działanie. Co więcej, kompilacja przez tę maszynę wirtualną działa na zasadzie JIT (Just-In-Time), czyli kod maszynowy powstaje za każdym razem gdy uruchamiamy aplikację i z niej korzystamy. Aplikacje zatem w teorii uruchamiać będą się dłużej niż w przypadku rozwiązania natywnego, bez maszyny wirtualnej.

Czy ART rozwiązuje ten problem? Częściowo. Czym jest ART? Skrót oznacza Android Runtime czyli androidowe środowisko uruchomieniowe. Podstawową różnicą w stosunku do Dalvika jest to, że ART używa kompilacji AOT (Ahead-Of-Time) zamiast JIT. A co to oznacza w praktyce? Już podczas instalacji aplikacji, kod z pliku .apk (lub .dex) jest przekształcany na niskopoziomowy kod maszynowy dostosowany do lokalnego procesora. Pozwala to na utworzenie prawdziwych, natywnie działających aplikacji bez konieczności pełnej wirtualizacji. To oczywiście ogromne uproszczenie tego co się dzieje na tych etapach, ale wystarczające by zrozumieć podstawową przewagę ART nad Dalvikiem.

Dalvik jest „zły”? Właściwie tak, ale nie jest to takie oczywiste. Dalvik nie jest wolny z uwagi na kiepską optymalizację kodu samej maszyny. Jest wolny, bo każda maszyna wirtualna jest co najmniej dwa razy wolniejsza niż rozwiązania natywne. Dodatkowo, Android laguje/klatkuje nie ze względu na Dalvika. Problemem jest jego natura, oparta o pełną wielozadaniowość i wieloprocesowość, ciężkie animacje oraz źle napisane, zasobożerne aplikacje (widzę Cię, Facebooku). Kompilacja JIT też nie jest zła sama w sobie i dotyczy jedynie ok. 2% kodu. Te 2% to są jednak najczęściej dość zasobożerne rozkazy, co stwarza pewne problemy wydajnościowe. ART ma być 2x szybszy od Dalvika w wykonywaniu kodu, ale dalej ok. 2x wolniejszy od pełnoprawnego rozwiązania natywnego.

Zmniejszenie roli maszyny wirtualnej, lepsza optymalizacja kodu i lepszy Garbage Collector. Czy wszystko to przełoży się na wzrost płynności systemu? I tak i nie. Odciąży to procesor, więc jeśli to procesor był wąskim gardłem – urządzenie może przyspieszyć. ART to też mniejsza zajętość pamięci RAM i lepsze zarządzanie pamięcią. Kolejny plus. Okazuje się jednak, że większość problemów wynika z zastosowania wolnych podzespołów takich jak pamięć wewnętrzna i korzystaniu z zasobożernych aplikacji, które pożrą zasoby procesora i RAM-u bez względu na ich wydajność i rozmiar. W benchmarkach, realna korzyść z ART nie wygląda już jednak tak różowo.

android-dalvik-art-benchmarks-early

Jestem pozytywnie nastawiony do tego rozwiązania i liczę na realna poprawę płynności systemu. Jednak pamiętamy, że poprawę płynności obiecywały kolejno Androidy 4.0, 4.1, 4.2 i 4.4, a jak było w praktyce – sami dobrze wiemy – różnie. Ogromnym plusem może być jednak poprawa żywotności baterii, która powinna zostać osiągnięta dzięki mniejszemu zaangażowaniu CPU i lepszemu zarządzaniu pamięcią.

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

  • Ale ART było do tej pory w fazie eksperymentalnej i dopiero Android L pokaże pełnoprawną i zoptymalizowaną wersję. Po drugie, benchmarki nigdy nie oddają rzeczywistości. Po trzecie, Android może i laguje, ale na nakładkach producentów, a nie na czystych instalacjach, np. Nexusach.

    • Android nie laguje na Nexusach? Błagam :) Jeśli nie laguje, to po co ART? Zgadzam się, że stock działa płynniej, ale wystarczy zaisntalować więcej aplikacji i poczekać kilka kilkanaście tygodni i muka. Miałem to z Nexusem 7, ojciec ma to z Nexusem 4. Użytkownicy mają to z Nexusem 5 (wystarczy poczytać fora).

      A problemem nie jest obecna wersja ART tylko idea która za nim stoi i realne potencjalne zyski i limitacje. Dalej jest to maszyna wirtualna wolniejsza od rozwiązań natywnych i dalej nie Dalvik czy ART jest główną przyczyną lagów.

      • Tomasz Lenartowski

        Na nexusie 5 jeszczem i nic nie lagowało przez pół roku używania. Ale może o czymś nie wiem. Po co art? Bo lepsze jest wrogiem dobrego. A x64 tak ładnie wygląda na plakatach reklamowych.

        • ART jest potrzebny, bo Dalvik jest rozwiązaniem mocno chybionym. Co nie oznacza, że będzie lekiem na całe zło świata (tak jak sugerują niektóre portale i sam Google), szczególnie w budżetowych urządzeniach z nakładkami producentów i wolną pamięcią wewnętrzną.

          No i ART to nie same plusy. Udręka dla deweloperów przy debugowaniu, appki będą zajmować znacznie więcej miejsca w pamięci, a aktualizacje będą trwały znacznie dłużej, co przy częstych aktualizacjach i dużej ich liczbie – będzie zżerać baterię.

          • Tomasz Lenartowski

            Lekiem na całe zło świata jest zagłada świata. Natomiast to, co napisałeś powyżej jest prawdą, ale przy okazji schodzisz z tematu – nexus + lagi. Ja nie wdziałem.

          • Ja widziałem, ale nasze prywatne doświadczenia nie mają żadnego znaczenia. Ani w jedną ani w drugą stronę.

          • Automatyk

            Lekiem na całe zło jest POZBYCIE się Javy w ogóle :)
            To największa porażka jeśli chodzi o wydajność.
            Nie wymagam pisania w Assemblerze :) ale można połączyć uniwersalny, szybki, wydajny kod z łatwym programowaniem.
            Som Google przyznaje – że należało by „porzucić” obecnego Androida i zacząć od nowa – jak to zrobił MS z Windows Phone 7 i 8. Ale się boją utraty rynku.
            ART nic nie da – prawda jest taka, że producenici dołoża rdzeni, GHz’ów i RAM – więc po co się „męczyć” w optymalizację kodu :)

          • A jakie znaczenie ma java jako jezyk programowania skoro kompilator ART kompiluje appke w momencie instalacji do rozkazow na poziomie jezyka maszynowego?

          • Automatyk

            MA i to duże.

            Napisz program wyświetlające słynne „Hello World!” w Javie – to zobaczysz :)

            Piszę też w języku bazodanowym Clarion – kiedyś dla jaj napisałem taki program :) a kumpel napisał bo w Javie ku naszemu zaskoczeniu okazało sie, ze Java „dała” nam większy i wolniejszy kod niż Clariom – który jest jezykiem Bazodanowym :) przecież.

            Język + Kompilator – i to decyduje o wielkości i szybkości. Java oraz jej Kompilatory, Maszyny Wirtualne są bardzo słabe – jeśli chodzi o optymalizację są nędzne i to bardzo.
            Java miała być uniwersalna, nie zależną od sprzętu – i za to się teraz płaci – ogromną cenę – w postacie kiepskiego działania.
            Jedyne co może uratować Javę to PORZĄDNY kompilator – natywny dla sprzętu.
            Należało by de facto do każdego sprzętu zoptymalizować kompilator :) – żadne Runtime, żadne Maszyny Wirtualne. W momencie instalacji powinniśmy kompilować program.
            Ale to jest nie realne – ART może trochę przyspieszy – ale nadal Android będzie powolnym i ślamazarnym systemem w porównaniu do iOS czy WP.
            Jedyne co obecnie ratuje Androida – to coraz mocniejsze proce i więcej RAM’u.
            Spróbujcie uruchomić Andrutta 4.4 na sprzęvie pokroju Lumi 520 :)

          • Ja doskonale znam wady javy, ale nie czaruj tylko odpowiedz na pytanie.

            Java będzie tylko w .apk, a ART korzysta z maszynowego kodu skompilowanego RAZ przy instalacji. Jaki wpływ ma JAVA jako język programowania na szybkość działania ART wykonującego kod maszynowy?

            PS: „żadne runtime”? To appki będą śmigać w próżni? ;) „W momencie instalacji powinniśmy kompilować program.” Przecież właśnie tak działa ART! Nie przeczytałeś wpisu?

          • Zszywacz

            Chodzi mu chyba o to, że po przełożeniu Javy na kod maszynowy, jest tego kodu maszynowego więcej, niż po przełożeniu programu napisanego w Clarionie, choć funkcjonalność w obu przypadkach jest taka sama. Więcej uzyskanego kodu maszynowego, to wolniejsze wykonanie.

          • janko

            Po kompilacji Javy wychodzi tego kodu dramatycznie i nieporównywalnie więcej, niż gdyby program był napisany w jakimś języku „niższego poziomu”, np. w C. Napisany w asemblerze byłby jeszcze o rząd wielkości mniejszy, niż w C. Różnice są mniej więcej tego rodzaju: okienko „hello world”, napisane w asemblerze, to będzie kilkaset bajtów, w C kilka-kilkanaście kilobajtów, w Javie – setki kilobajtów (i megabajty zajętej pamięci RAM, z uwagi na biblioteki, które zostaną dołączone). Narzut, czy też „skala nieoptymalności” programu, zrobionego w Javie i skompilowanego do postaci binarnej, to kilka rzędów wielkości, w porównaniu z możliwe najbardziej optymalną wersją, czyli umiejętnie napisaną w asemblerze.

            Oczywiście to teoria, nikt nie będzie pisał programów dla Androida w C, a tym bardziej w asemblerze :)

          • Wszystko pięknie w teorii. W praktyce, narzut w stosunku do c# czy objective c jest niewielki. A każdy kto optymalizował appki wie, ze problemy z wydajnością nie wynikają z długości kodu maszynowego tylko ZAWSZE z liczby i szybkości odwołań do danych. Dodatkowo, wiele zależy od kompilatora, a Dalvik czy ART są dużo wydajniejsze niż rozwiązania znane z desktopów.

          • Jacko

            Najwięcej problemów leży między klawiaturą o oparciem fotela. Wiem jak lubię pisać i jak lubią pisać moi koledzy, dług technologiczny jest czymś na porządku dziennym. Pisanie aplikacji na szybko, bez pomysłu, bez modularności – standard.

          • Sony

            ART – nie wiele zmieni – dalej JAVA w APK będzie „interpretowana” – dodać do tego „narzuty” oraz niechlujstwo programistów i będzie jak teraz.

            Jedynym rozwiązaniem jest usuniecie „pośredników” i kompilacja do „natywnego” kodu”.

            inna sprawa to kwestia jaki kod dostajemy – Java niestety ma „słaby” kod – nie wymagam jakości kodu Asemblera czy C – ALE – języki rozbudowane znacznie bardziej niż Java „produkują” lepszy kod – sam „bawię się” trochę Visual Data Flex – czyli klasyczny bazodanowy RAD – coś jak wspomniany tu Clarion – generalnie można „napisać” :) aplikację bez znajomości kodu – składając ją z „klocków” – wynik to aplikacja pod Windows w postaci klasycznego EXE – a mimo to „produkuje” znacznie lepszy i szybszy kod niż Java.

            Zreszta widać to przy iOS czy WP – nie ma Javy – nie ma problemów z prędkością. :)

            Pamiętam czasy gdy programowałem 8051 :) w assemblerze. Nie było Gigabajtów RAM’u :) miałeś małą moc, mało pamięci na program i dane – i musiałeś się zmieścić. uczestniczyłem w pisaniu programów do sterowników przemysłowych SAIA – Ludzie przesiadka z 8051 na 68000 i 125 kilo pamięci na Program i 256 kilo na dane – jaki to był „WYPAS” :) całe 125 kilo WOW. I zmieściło się tam sterowanie oczyszczalnią ścieków :)

            A teraz mamy wielordzeniowe procesory, 2 GB RAM – i niestety upada sztuka pisania szybkich, małych i zoptymalizowanych programów.

          • Coś za coś. Prostota i uniwersalność pisania albo jakość kodu wykonywalnego. Dzięki pierwszemu podejściu appki mogą być pisane niemalże przez laików i app store się rozrastać. A dla Google to jest ważniejsze niż jakość kodu czy płynność działania.

            A swoją drogą, gdy appkę pisze ktoś, kto nie ma pojęcia o architekturze sprzętowej urządzenia, może narobić wiele szkód wydajnościowych. A programiści są leniwi i nie wgłębiają się w dostępne API. „Działa? Działa.” I nic więcej ich nie obchodzi.

            Nie możemy mówić też o tym, że „java produkuje kiepski kod”. Java nic nie produkuje, jest językiem. Kod maszynowy produkują kompilatory i to od nich zależy czy będzie duży narzut zbędnych rozkazów procesora czy nie.

            Ja nie wiem jaki kod maszynowy produkuje Dalvik czy ART więc nie wypowiadam się co do jego „jakości”.

          • Sony

            Wystarczy by kompilator był dobry – i tyle – ale niestety należało by kompilatory „dopasować” do konkretnego SoC’a.
            Dlatego paradoksalnie Android na Intel Atomach tak zasuwa :) mamy de facto jeden SoC i jeden kompilator :) który na dodatek świetnie działa.
            Z dotychczasowych „przecieków” :) wynika, że ART „generuje lepszy” kod niż Dalvik – ale – nie jest to dużo różnica. Raczej kilkanaście procent niż kilkadziesiąt.
            Oczywiście dobre i 15% :) – a jak dodamy coraz wydajniejsze SoC i więcej RAM – będzie to odczuwalne. Ale do płynności iOS czy Wp to nadal będzie sporo brakować.
            Więc na Hi End’ach nie będzie problemu :) ale na tańszym, słabszym budżetowym sprzęcie dalej będzie lagować.

          • Większe znaczenie od jakości kodu maszynowego ma przejście z JIT na AOT :)

          • uru28

            Java tak czy inaczej daje popalić, wystarczy wyłączyć obsługę java script w przeglądarce i prime zamienia się w demona prędkości, z resztą dotyczy to nie tylko prime…Nie mam za wielkiego pojęcia o informatyce (między innymi dla tego bardzo podoba mi się ten artykuł) i mam świadomość iż mowa tu o innych kwestiach, nie mniej java jako środowisko chyba nie przystaje już do obecnych czasów.Potrzeba rozwiązań mniej zasobożernych.

          • Ale Java i JavaScript to zupełnie różne rzeczy. Pierwszy jest językiem obiektowym, który jest kompilowany do rozkazów niskopoziomowych. Drugi to język skryptowy, który jest wykonywany na podstawie gołego tekstu (kodu) just-in-time w przeglądarce :)

          • Tomasz Lenartowski

            Dokładnie. Wielu ludzi nie obeznanych w temacie ta nazwa wprowadza w błąd.

          • John Kofee

            optymalizacja z kodu pośredniego do natywnego jest gorsza niż przy kompilacji z kodu źródłowego do natywnego + zarządzanie pamięcią java i pewnie jeszcze sporo innych rzeczy by się znalazło… innymi słowy trzeba by przygotowywać kod wynikowy ze źródeł java tak jak to sie robi np. w przypadku C/C++ ale tu traci się na uniwersalności.

          • Pisząc o kodzie pośrednim masz na myśli ART czy Dalvika?

          • John Kofee

            mam na myśli pseudokod javy czyli kod pośredni po kompilacji ze źródeł – materiał jaki dostaje Dalvik czy ART

          • John Kofee

            zgadza się – jednak programiści już od dawna dodają biblioteki w natywnym kodzie gdy wymagają większej wydajności – stąd niektóre programy są niekompatybilne ze wszystkimi urządzeniami – jednak ta nieszczęsna java ciągle tam jest…

          • John Kofee

            ja widziałem lagujące urządzenia apple, które słyna z braku tego efektu i co z tego ? android to zarazem dobra jak i niedobra koncepcja osobiście za nim nie przepadam ale nie ma też nic innego na rynku co by się nadawało w zamian czyli łączyło w sobie cechy otwartości androida i wydajnego natywnego systemu – no może kiedyś tizen będzie mógł sie tu pokazaćc z dobrej strony ale to też pewne nie jest bo nie wiadomo co samsung z nim zrobi…

          • O tym piszę – doświadczenia osobiste są bez znaczenia, bo w żaden sposób nie skalują się na całą populację.

          • Mihau

            „Appki będą zajmować znacznie więcej miejsca w pamięci” – tzn. o ile więcej? Z tego co słyszałem, realny wzrost rozmiarów ma sięgać kilkanastu procent – choć przyznaję, że nie podam źródła, bo nie pamiętam, więc to może być wyssane z palca. Ale na pewno nie będzie to ogromny skok, bo aplikacja to nie tylko kod – a tylko objętość tego wzrośnie. No i o ile instalacje będą zajmować więcej miejsca, to zużycie RAMu się chyba nie zwiększy?

            Problem czasu aktualizacji będzie dotyczył głównie dużych aplikacji – gier 3D i innego rozbudowanego softu. Tutaj rzeczywiście koszty w zużyciu baterii i czasie instalacji mogą być zauważalne. W przypadku drobnych appek, które chyba dominują, nie powinno być tak źle. Choć to trochę wróżenie z fusów z mojej strony, bo osobiście ART jeszcze nie testowałem.

          • Z tego co czytałem więcej od 10 do 100% ale tez nie podam źródła. Zużycie RAM powinno nawet się zmniejszyć.

      • Mam około 150 aplikacji na Nexusie 4 (razem z systemowymi) i jedyna sytuacja, w której telefon laguje, to aktualizacje

        • „Dowód z autopsji”. Nie liczy się :)

          • Tomasz Lenartowski

            „Jeśli nie laguje, to po co ART?” <- argument z kosmosu też się nie liczy ;)

          • Ok, następnym razem dam kolejną emotikonkę albo „/s”

      • slv

        „Jeśli nie laguje, to po co ART?”

        bo się Google nie mogło dogadać z Oraclem ?

      • John Kofee

        nie rozumiem skąd pomysł, że ART jest lekiem na „lagowanie” androida ? żeby by było zabawniej z wpisu wynikało, że wiesz po co został stworzony, a tu taki komentarz :) warto też zauważyć, że są urządzenia o słabej specyfikacji, które w zasadzie nie „lagują” i bardzo mocne, które lagują tak, że odechciewa się ich używać, a to wciąż ten sam android z dalvikiem :)

        • Skąd pomysł? Z tytułów polskich i zagranicznych „mediów technologicznych”.

          • John Kofee

            aaa no to tak, parafrazując: każdy haker to przestępca :)
            tak samo jest z ART i lagowaniem, a ludzie potem to czytają i powtarzają :)

      • Artur Węgliński

        „Android nie laguje na Nexusach? Błagam :) Jeśli nie laguje, to po co ART?” A po to by nie lagował na samsungach cała prawda. Powiem Ci tak samo wejdź na fora, poczytaj i zobaczymy czy przeczytasz o lagowaniu N5. Używam go od stycznia tego roku, nie znając telefonu zaryzykowałem przesiadkę z szajsunga i gdyby nie to już dawno bym się rozstał z andkiem. Na tematycznym forum zadałem pytanie czy warto się przesiadać z N5 na SGS5 i wiesz Co mi napisali w + i -? że zaleta to tylko te wodotryski a na – przesiadki płynność TW. Nie pisz o muleniu N5 bo nie wiesz o czym piszesz.

  • Krzysztof Świątek

    Mam nexusa 4 na art i Note 3 na Dalviku. Jedne aplikacje uruchamiają się tak samo szybko, inne szybciej na N4 pamiętając o tym, że N4 to wydajnościowo starszy telefon.

    Co do lagów, zdarzają mi się czasem sporadyczne chrupnięcia, ale nic nagminnego. Mając jedncześnie ipada 2 ios 6 i 7 mogę z czystym sumieniem mitem nazwać brak lagów na tych urządzeniach. Oczywiście nie są one nagminne, są tak samo rzadkie jak na N4, ale podobnie jak w innych systemach ISTNIEJĄ.

    I teraz najciekasze moim zdaniem: skąd u „specjalistów” taka mania mega hiper płynności? Czy jak zgubię te kilka klatek 2 razy dziennie to co się stanie? Strona się nie załaduje? wiadomości nie odczytam? nie napiszę jej?

    Litości, przerabiałem linuxa, mac os, windowsa, ios, androida. Na każdym z nich występują czasem jakieś problemy, na każdym czasem coś chrupnęło. Ogarnijcie się.

    • janko

      W urządzeniach mobilnych, obsługiwanych dotykowo, lagi strasznie uprzykrzają życie i zniechęcają do korzystania z takiego urządzenia. To nie jest komputer na biurku, z myszką i klawiaturą, gdzie jak kliknąłeś myszką czy nacisnąłeś klawisz, to wiesz, że nacisnąłeś i za chwilę będzie efekt, nawet jeśli z opóźnieniem, ale będzie, a przecież i tak nigdzie nie idziesz, tylko siedzisz przed tym komputerem, sekunda wcześniej czy później nie jest taka ważna (chociaż dla niektórych jest, np. dla mnie). A jak stoisz w tramwaju i robisz coś na tablecie, to nie chcesz parę razy smyrać palcem po ekranie, żeby się upewnić, że na pewno dotknąłeś tam gdzie trzeba, i nie wiadomo, tablet właśnie „coś robi” i zareaguje na chwilę, czy może źle smyrasz i trzeba jeszcze raz? Ale jak za dużo posmyrasz, a program jest kiepsko napisany, to za chwilę się „obudzi” i zareaguje na te wszystkie kolejne smyrnięcia i pacnięcia, i w sumie zrobi nie wiadomo co?

      Druga sprawa, że czekanie 2-3 sekundy, aż wyświetli się dialer telefonu, to jakieś totalne nieporozumienie. Procesor z gigahercowym zegarem, gigabajty RAM, a wyświetlenie okienka z dziesięcioma guziczkami trwa kilka sekund…

      • Krzysztof Świątek

        Ja piszę o chrupnięciach, a nie 3 sekundowych przestojach. Wiem, że takie bywają na androidzie, ale to raczej wynika z oszczędzaniu na parametrach telefonów (tych najtańszych) To, że można inaczej udowadnia to moto G. Niestety producenci chcą zarobić jak najwięcej.

        Wstadź ios do bebechów za 1 zł to zobaczysz jak wyglądają prawdziwe lagi.
        Oczywiście pewnym zaprzeczeniem mogłaby być lumia. Ten telefon jednak jest droższy w produkcji i producenci na nim mniej zarabiają, choć w ostatecznym rozrachunku przynajmniej nie rozchodzi się fama, że windows laguje.

        Żeby mnie ktoś źle nie zrozumiał, wiem, że java + wielozadaniowość + nakładki producentów + jak najtańsze podzespoły to nie jest dobre połączenie, szczególnie w wydaniu samsunga na tańszych słuchawkach. Jednak głosujemy portfelami, a te na razie powodują, że android jest najpopularniejszy. Nie można w tym przypadku mówić też o nieświadomości konsumentów, bo system jest już na tyle długo na rynku, że ludzie biorąc go, wiedzą na co się decydują.

        I na koniec. Ludzie bywający tu, to fani nowinek i technologi, zmieniający telefony (tablety) dosyć często. Skoro tak duża ilość tych osób decyduje się na kolejne słuchawki z andoidem, to znaczy, że chyba nie jest tak źle z tymi lagami i trafianiem w przyciski jadąc tramwajem, prawda? ;)

      • slv

        @janko

        „Druga sprawa, że czekanie 2-3 sekundy, aż wyświetli się dialer telefonu”

        Jeżeli u mnie taki efekt jeżeli zaczyna występować, to… czyszczę historię komunikacji (Samsung). Pomaga natychmiast – polecam.

    • vvaz

      Masz rację i nie masz racji. To co nazywa się lagiem w Androidzie to po prostu czekanie aż program się załaduje – nie oznacza że urządzenie nic nie robi. iOS załatwia to sprytniej – w tym czasie uruchamia oczoj* animację. Miałem okazję testować obok siebie równorzędne mniej więcej Galaxy S i iPhone’a i porównywalne aplikacje (web, mail, mapy) od czasu klepnięcia do funkcjonalności uruchamiały się w prawie identycznym czasie. Różnica była taka, że Samsung „nic nie robił” przez np. 2 sekundy a potem była aplikacja a iPhone mrygał. DOSTĘP do tego o co naprawdę chodziło był w praktycznie tym samym czasie. Jeśli różnica była to bardzo mało zauważalna i raz w te, raz we wte.

      Nie masz racji w jednym punkcie – to co zauważył janko – czas dostępu do krytycznych aplikacji takich jak dialer czy kontakty jest skandalicznie długi. 2s na dialer czy 5s na kontakty (u mnie) to koszmar. Wydawałoby się, że przy tylu rdzeniach i pamięci Android umiałby zarezerwować zasoby na podstawy.

      • Krzysztof Świątek

        Właśnie sprawdziłem na N4. Dostęp do dialera gdy nie ma go w pamięci (z tym, że dialer i książka w 4.4.4 to jedna aplikacja w zasadzie) to jakieś 1-2 sekundy faktycznie, gdy jest już w pamięci jest natychmiastowy.

        Zgodzę się, że android powinien prioretytować ważniejsze aplikacje w systemie, tak aby jego podstawy działały sprawnie.

        Niestety albo stety mamy tu pełną wielozadaniowość i na wolniejszych telefonach nie sprawdza się to dobrze. Na nich powinny być większe restrykcje co do aplikacji i sposobu ich obsługi. Microsoft to dobrze rozwiązał, bo po prostu nie dał dostępu do aplikacji które nie wyrabiają się na systemie.

      • mbielak012

        Jak masz samsunga to się nie dziw

  • ja

    ja jestem z Androida bardzo zadowolona. Jak sobie pomyślę jak działa windows to raczej wady androida należy uznać za zalety:)

  • tomek

    G 2 mini na Arcie bateria trzyma dłużej o około pół dnia! Wszystko chodzi szybciej. Android 4.4 :)

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