Aktualność
Mieszko Krzykowski, Środa, 25 czerwca 2014, 23:54

Z kolejnymi edycjami konferencji Google I/O nierozerwalnie łączą się prezentacji najnowszych wersji Androida. Nie inaczej było tym razem i na konferencji przeprowadzonej przez wyszukiwarkowego giganta można było podejrzeć co przyniesie przyszłość posiadaczom najpopularniejszego mobilnego systemu operacyjnego.

Na początek małe wyjaśnienie dotyczące nazwy Android L. Jak zapewne zauważyliście, kolejne wersje tego systemu mają nazwy rozpoczynające się od kolejnych liter alfabetu. Teraz mamy KitKata, więc to naturalne, że czas na coś z „L” z przodu. W internecie można znaleźć informację, że imię kolejnego „robocika” to Lollipop, lecz nie zostało to jeszcze oficjalnie potwierdzone, bo na trwającej właśnie konferencji Google I/O pokazano jedynie zapowiedź i bardzo wczesną odmianę „elki”, przygotowaną głównie dla programistów (i to oni dostaną dostęp do niej już jutro, o ile mają Nexusa 5, albo Nexusa 7). Jej ostateczna wersja i pełna nazwa zostaną opublikowana dopiero jesienią tego roku i wtedy będzie można na poważnie zacząć się zastanawiać kiedy dany telefon otrzyma odpowiednią paczkę aktualizacji i dlaczego tak późno.

Najwięcej zmian w Android L ma nastąpić „pod maską”. Prawdopodobnie największą z nich jest całkowite przejście ze środowiska uruchomieniowego Dalvik, na środowisko uruchomieniowe ART. Pierwszy raz zaprezentowano je już w Androidzie 4.4, gdzie można je było włączyć w menu z opcjami dla programistów, bo było ono jeszcze we wczesnej i nie w pełni sprawnej fazie. Dlaczego to taka ważna zmiana? Po pierwsze, programiści będą musieli sprawdzić, czy ich aplikacje są w pełni kompatybilne z nowością i ewentualnie je zaktualizować, zanim Android L zacznie trafiać „na poważnie” do kolejnych telefonów. Po drugie, ma to przynieść wzrost wydajności i szybkości uruchamiania programów. Program kompilowany przez dewelopera jest „przerabiany” na tak zwany kod bajtowy. Kod ten w trakcie instalacji aplikacji trafia do smartfona/tabletu i musi on tam zostać „przetłumaczony” na kod maszynowy. Jeśli system urządzenia ma aktywne stare środowisko uruchomieniowe Dalvik, to operacja ta jest wykonywana zawsze w trakcie uruchamiania programu i jej wynik ląduje w pamięci operacyjnej. Natomiast w przypadku środowiska ART, „tłumaczenie” przebiega już w trakcie instalacji danego programu i jej wynik jest zachowywany na przyszłość na standardowym nośniku danych. Teoretycznie ma to przynieść zmniejszenie obciążenia procesora, zużycia pamięci operacyjnej itp. Pierwsze testy, wykonane jeszcze na Androidzie 4.4 pokazują, że cudów to nie przynosi, ale każda odrobina wydajności i lepszej optymalizacji jest przez nas mile widziana. Po trzecie, nowe środowisko jest w pełni kompatybilne z 64-bitowymi procesorami różnego typu, czyli ARMv8, x86-64 i MIPS64.

Ale to nie koniec optymalizacji różnego typu. Sporo uwagi przywiązano ponoć do zachowania „odśmiecarki” pamięci operacyjnej. Chyba każdy użytkownik smartfonów z Androidem zauważył pewne specyficzne zachowanie systemu. Gdy RAM urządzenia się zapełni po uruchomieniu kilku programów i chce się skorzystać z kolejnego, który się w wolnym RAM-ie już nie mieści, to wtedy można zauważyć, że wszystko spowalnia i może zacząć „chrupać”. Wynika to z założenia „robocika”, że pamięć niewykorzystana, to pamięć zmarnowana (w czym jest trochę prawdy), przez co stara się on trzymać w niej aplikacje i narzędzia tak długo jak to możliwe i ma sens (a czasami nawet dłużej ;)). Z tego powodu czasem, gdy chce się uruchomić nowy program, to najpierw należy poczekać na „śmieciarkę”, która zwolni niezbędną ilość pamięci, a jej działanie wywołuje chwilową „przycinkę” systemu. W Android L ma to się dziać szybciej i mniej zauważalnie dla użytkownika, co jest szczególnie dobrą wiadomością dla osób ze smartfonami wyposażonymi w 0,5-1 GB pamięci RAM (czyli posiadacze Motoroli Moto G i Moto E znowu się ucieszą, że ich telefony działają jeszcze lepiej i sprawniej ;)).

Nie pominięto też tematu czasu pracy na akumulatorze. Wcześniej mieliśmy Project Butter, mający na celu poprawienie płynności działania Androida, a teraz mamy Project Volta, który ma pozwolić znaleźć sposoby na poprawnie czasu pracy na akumulatorze. Optymalizacje te będą głównie związane z tym jak często urządzenie jest wybudzane ze stanu głębokiego uśpienia przez modem i procesy korzystające z internetu i usług lokalizacyjnych, gdy ekran jest wyłączony. Teraz ma się to dziać rzadziej. Wpływ tego rozwiązania na efekt końcowy w dużej mierze będzie zależał od tego w jaki sposób korzystasz ze swojego telefonu. Jeśli Twój smartfon ma przez większość czasu włączony ekran i ciągle coś na nim robisz, to Volta niewiele zmieni. A jeśli używasz go mniej intensywnie, ale jednak ciągle sprawdza on coś w tle i informuje o nowych wydarzeniach, to różnica może być spora. Zastanawia nas tylko, czy twórcy popularnych nakładek systemowych czegoś tu tradycyjnie nie popsują, przez co ewentualne korzyści z poprawek Androida L nie będą zarezerwowane jedynie dla posiadaczy Nexusów, tak jak to ma często miejsce w przypadku wszelkiego rodzaju optymalizacji płynności interfejsu i użycia pamięci operacyjnej.

Kolejna wewnętrzna zmiana dotyczy głównie programowania gier, jest bardzo specyficzna i wywołuje u nas mieszane uczucia. Chodzi o Android Extension Pack. Gry są niesamowicie istotną częścią aplikacji mobilnych i wyglądają one coraz lepiej. Tegoroczne układy graficzne, takie jak GPU Tegry K1, czy Adreno 420 Snapdragona 805, będą już w pełni sprzętowo kompatybilne z DirectX 11 i najnowszymi wersjami OpenGL. A to oznacza obsługę takich funkcji jak teselacja, compute shader i geometry shader. Lecz żeby było można z tego skorzystać, potrzebna jest obsługa przez system i sterowniki odpowiedniej wersji API, która rozpoznaje te funkcje. W Androidzie L można już korzystać z dobrodziejstw OpenGL ES 3.1, ale to mobilne API nie wie co to jest teselacja, czy geometry shadery, więc spory kawałek logiki najnowszych smartfonowych układów graficznych leżałby odłogiem.

Tutaj do gry wchodzi właśnie Android Extension Pack, który ma umożliwić programistom w miarę łatwe wykorzystanie tych nowych technik. Jest to więc forma łatania dziury powstałej przez to, że OpenGL ES nie nadąża za rozwojem sprzętu, a w smartfonach i tabletach z Androidem nadal brakuje wsparcia dla pełnego OpenGL. Zastanawiające jest to, że na slajdzie mówiącym o AEP wymieniono również compute shadery i kompresję tekstur ASTC, które są częścią OpenGL ES 3.1 i związanych z tym API rozszerzeń, więc albo to jest pomyłka w prezentacji (Computer shaders?), albo Extension Pack będzie robił coś po swojemu. 

Ze zmian mniej technicznych i bardziej widocznych warto wymienić:

  • znacznie lepszy system powiadomień wyświetlanych na ekranie blokady systemu (podobne rozwiązania widzieliśmy na przykład w Nokii X, czy nowszych wersjach iOS)
  • nowy rodzaj powiadomień wyświetlanych w dymkach „nad” aktualną aplikacją (czyli połączenie przychodzące nie będzie teraz zatrzymywało wszystkiego i na przykład przerywało gry, bo informacja o nim pojawi się w małym „pływającym” okienku)
  • nowy wygląd ekranu przełączania między aplikacjami, na który jeden program może teraz wysyłać kilka kart, a nie tylko jedną (na przykład każda karta otwarta w przeglądarce internetowej może być teraz oddzielnym „bytem” 
  • zmieniony wygląd interfejsu użytkownika i nowy zestaw animacji znane pod wspólnym imieniem Material Design
  • tryb ekstremalnego oszczędzania energii (podobny do tego zaimplementowanego w nowym HTC One, Samsungu Galaxy S5 i Huawei Ascend P7), który będzie potrafił spowalniać częstotliwość odświeżania ekranu, wyłączać rdzenie procesora itp.

 

 

Nowości te będą jednak zapewne docenione głównie przez „Nexusowców”, ponieważ różnego rodzaju nakładki systemowe niekoniecznie muszą je zaimplementować, albo już można w nich znaleźć podobne rozwiązania.

Oczywiście lista zmian jest znacznie dłuższa i zapewne jeszcze będzie się wydłużała w ciągu kolejnych miesięcy. Wiele z nich jest przygotowana z myślą o programistach i tym, że Android ma teraz trafiać także na zegarki, okulary, telewizory i nawet do samochodów, a to trzeba jakoś sensownie spiąć ze sobą. Zobaczymy co z tego wyjdzie, ale Android L wyraźnie pokazuje, że Google wie jakie problemy ma ten system operacyjny, przygląda się temu co robią różni partnerzy i skupia się na dopracowywaniu tego co jest, zamiast przysłowiowego koła na nowo. A jak to wyszło w praktyce zobaczymy pod koniec roku.

Źródło: Google
Ocena aktualności:
Ocen: 9
Zaloguj się, by móc oceniać
mozilla007 (2014.06.26, 00:24)
Ocena: 12

0%
Ciekawe czy w tej wersji wreszcie Google zmusi producentów do aktualizacji systemu, bo jak wiadomo producentom musi się kasa w kieszeni zgadzać.
skoti48 (2014.06.26, 00:37)
Ocena: 8

0%
Jest to więc forma łatania dziury powstałej przez to, że mobilna wersja OpenGL nie nadąża za rozwojem sprzętu. Zastanawiające jest to, że na slajdzie mówiącym o AEP wymieniono również compute shadery i kompresję tekstur ASTC, które są częścią OpenGL ES 3.1 i związanych z tym API rozszerzeń, więc albo to jest pomyłka w prezentacji (Computer shaders?), albo Extension Pack będzie robił coś po swojemu.

OpenGL nadąża jak nikt. To OpenGL ES jest trochę opóźniony.
Co do reszty to ASTC nie jest częścią OpenGL ES 3.1, a jest sugerowanym rozszerzeniem na przyszłość, na jakąś kolejną wersję.
To, że Compute Shadery podano to nie jest błąd - Android wspiera tylko OpenGL ES 3.0, a CS są dopiero w 3.1.
Ten Extension Pack to taki trick, że będzie można w manifeście napisać, że wymaga się go, więc będzie pokazywany na urządzeniach z rozszerzeniami zawieranymi przez tą paczkę rozszerzeń. Uważam to za wielki błąd, bo powinno się już zupełnie olać Mali czy PowerVR, a Google powinno udostępnić pełny OpenGL, a tak to mamy powolnego, wykastrowanego ES (czyli to co chciał Qualcomm, bo ma sterowniki GLES i te rozszerzenia, a nie napisali sterowników obsługujących pełne OpenGL).
LeacH (2014.06.26, 00:38)
Ocena: 4

0%
Volta to pierwsza nazwa kodowa Pascal'a - więc tutaj gUgle zwaliło od nVidii :E
a tak poważniej to dobrze - rozwój dobrze im zrobi - tylko niech wymusza na producentach minimalny czas wspierania - coś co zrobił MS z WP7 i 8, bo tutaj leży i kwiczy. Niech teraz odmulą androida to może kiedyś rozważę zakup produktu z tym systemem
miekrzy (2014.06.26, 00:43)

0%
skoti48 @ 2014.06.26 00:37  Post: 761612
OpenGL nadąża jak nikt. To OpenGL ES jest trochę opóźniony.

Przecież wyraźnie piszę o mobilnej wersji Open GL, a nie 'pełnej'. Wiem, że OpenGL 4.4 ma wszystko co trzeba.
Edit: wywaliłem tę wstawkę o mobilnym OpenGL bo jeszcze ktoś zarzuci, że przecież OpenGL ES to nie tylko smartfony i tablety ;)
Co do reszty to ASTC nie jest częścią OpenGL ES 3.1, a jest sugerowanym rozszerzeniem na przyszłość, na jakąś kolejną wersję.

Tak, to tylko rozszerzenie (nawet piszę w tekście o 'związanych z API rozszerzeniach";), ale skoro ono istnieje, to po co kombinować z AEP?
To, że Compute Shadery podano to nie jest błąd - Android wspiera tylko OpenGL ES 3.0, a CS są dopiero w 3.1.

Android L obsługuje ES 3.1, a więc i CS.
pełny OpenGL, a tak to mamy powolnego, wykastrowanego ES (czyli to co chciał Qualcomm, bo ma sterowniki GLES i te rozszerzenia, a nie napisali sterowników obsługujących pełne OpenGL).

Też uważam, że to rozwiązywanie problemu, który nie powinien istnieć, bo już dawno powinniśmy mieć pełny OpenGL.
skoti48 (2014.06.26, 01:07)
Ocena: 0

0%
miekrzy @ 2014.06.26 00:43  Post: 761615

Przecież wyraźnie piszę o mobilnej wersji Open GL, a nie 'pełnej'.

OpenGL ES nie tyle jest mobilna co przeznaczona do urządzeń wbudowanych, a nie jest to i tak 'mobilna wersja OpenGL', a osobny projekt jedynie oparty o OpenGL, więc o ES nie należy zapominać.

miekrzy @ 2014.06.26 00:43  Post: 761615
Tak, to tylko rozszerzenie, ale skoro ono istnieje, to po co kombinować z AEP?

Bo niektórzy rozszerzeń nie lubią, bo nie są wymagane. Przykładowo MRT było w Tegra 3, ale wykorzystywane jest dopiero teraz od GLES3. AEP to tak jak z kompresją ETC1 - jako rozszerzenie do GLES nie jest wymagane i jest jednym z wielu. Jednak Google w Androidzie od GLES2 wymaga wsparcia ETC1 i stał się standardem kompresji na Androidzie, bo jest pewne, że wszędzie jest. Z GLES3 weszło ETC2, ale widocznie Google zdecydowało, że chce wymusić rozszerzenie kompresji znacznie lepsze (też bardziej wymagające od sprzętu) i dodało go jako wymagane, aby wspierać AEP.

miekrzy @ 2014.06.26 00:43  Post: 761615
Android L obsługuje ES 3.1, a więc i CS.

W takim razie może to być dwie opcje:
- do AEP potrzeba tylko GLES3.0, ale w rozszerzeniach trzeba mieć CS (czyli nie musi obsługiwać indirect draw czy separate shader objects do tego, aby wspierać AEP).
- było miejsce i dział marketingu kazał wpisać, aby było więcej ;p
KazH (2014.06.26, 06:14)
Ocena: 1

0%
skoti48 @ 2014.06.26 00:37  Post: 761612
Jest to więc forma łatania dziury powstałej przez to, że mobilna wersja OpenGL nie nadąża za rozwojem sprzętu

OpenGL nadąża jak nikt. To OpenGL ES jest trochę opóźniony.


Apple z OpenGL ES zrezygnowało w iOS 8.0 i promuje szybsze biblioteki niskopoziomowe Metal. To coś jak AMD Mantle ale dużo lepiej zoptymalizowane bo Apple samodzielnie zaprojektowało nie tylko GPU ale także CPU, system operacyjny oraz resztę hardware. Wszystko jest ich własnego autorstwa więc projektując Metal jednocześnie z projektowaniem hardware i software umożliwiło im poziom optymalizacji nieosiągalny dla AMD Mantle bo AMD nie produkuje własnego systemu operacyjnego oraz musi obsługiwać kilka typów CPU.

Najlepiej Metal podsumował szef EPIC (Unreal Engine) który nazwał OpenGL ES produktem poprzedniej ery.

'Metal is a low-level rendering API, which means it provides the absolute minimum layer of software needed to support multiple versions of different graphics chips. It shields developers from the very low-level implementation details. It replaces OpenGL ES, which is an ancient relic of the Silicon Graphics era

There’s just a huge amount of overhead introduced by OpenGL into the graphics pipeline. It has a very high-level view of the scene. It doesn’t let developers to the low-level management of resources that they need to achieve efficiency. Metal achieves about a tenfold decrease in driver overhead. It’s an order of magnitude improvement.

The great thing is, developers using a game engine, they’re writing very high-level code for their game logic anyway. The game engine is doing all the work of translating it to a graphics API. We’ll see an immediate, significant improvement in the number of objects and the complexity of the scenes they can build without having to do constant work themselves'

Tak samo zareagowało EA pokazując silnik Frostbite na iOS 8.0 razem z grą 'Garden Warfare' w której udało im się na Apple A7 uruchomić scenę z 1.3 milionem trójkątów na ekranie oraz liczonym w czasie rzeczywistym efektem głębi obrazu. Szef studia odpowiedzialnego za tą grę stwierdził że w OpenGL ES mogliby użyć co najwyżej 130 tysięcy trójkątów na tym procesorze.

http://venturebeat.com/2014/06/03/graphics...re-efficiently/
Kiciuk (2014.06.26, 08:29)
Ocena: 4

0%
znacznie lepszy system powiadomień wyświetlanych na ekranie blokady systemu (gdzieś już widzieliśmy podobne rozwiązanie ;))

Nokia X -_-
*Konto usunięte* (2014.06.26, 08:34)
Ocena: 11
Tyle propagandy i bzdetów aż dupa piszczy.
Think (2014.06.26, 08:48)
Ocena: 0

0%
Wygląda na to, że warto zainwestować w Nexus 5 bo po wyjściu nowej wersji androida wydajność wzrośnie i nie trzeba będzie wymieniać słuchawki przez dłuższy czas...
miekrzy (2014.06.26, 09:06)

0%
skoti48 @ 2014.06.26 01:07  Post: 761617
Bo niektórzy rozszerzeń nie lubią, bo nie są wymagane. Przykładowo MRT było w Tegra 3, ale wykorzystywane jest dopiero teraz od GLES3. AEP to tak jak z kompresją ETC1 - jako rozszerzenie do GLES nie jest wymagane i jest jednym z wielu. Jednak Google w Androidzie od GLES2 wymaga wsparcia ETC1 i stał się standardem kompresji na Androidzie, bo jest pewne, że wszędzie jest. Z GLES3 weszło ETC2, ale widocznie Google zdecydowało, że chce wymusić rozszerzenie kompresji znacznie lepsze (też bardziej wymagające od sprzętu) i dodało go jako wymagane, aby wspierać AEP.

Niby wszystko fajnie, ale to i tak jest wyważanie otwartych drzwi, bo wszystkie nowe GPU z teselacją itp. (a więc te, o które w tym wszystkim chodzi) obsługują też ASTC (nawet te od Qualcomma, bo Mali i NV to wiadomo). Od dwóch lat leżą odpowiednie rozszerzenia do GL ES, a oni robią to na nowo i jakoś nie wierzę, że dodanie tego do AEP w jakiś magiczny sposób spowoduje, że ludzie zaczną z tego korzystać częściej. Ale może się mylę.
Zaloguj się, by móc komentować
Aktualności
Akcja wsparcia w związku z pożarem katedry Notre-Dame de Paris. 29
To chyba nie będzie zabójca Fortnite. 29
Gorzej niż wcześniej, ale i tak świetnie. 28
Lepsza, ale niestety też droższa niż poprzedniczka. 10
Edycja specjalna. AMD zamierza hucznie obchodzić swoje 50. 15
Od zapowiedzi do sklepowej dostępności minie kilka tygodni. 18
Dla wielu osób wyniki badań mogą być zaskakujące.  22
Spodziewajcie się wzrostu wydajności. 19
Gorzej niż wcześniej, ale i tak świetnie. 28
Spodziewajcie się wzrostu wydajności. 19
Edycja specjalna. AMD zamierza hucznie obchodzić swoje 50. 15
Nintendo Switch traci tytuł na wyłączność. 0
Akcja wsparcia w związku z pożarem katedry Notre-Dame de Paris. 29
APU z 2 rdzeniami, 4 wątkami, układem graficznym Vega 3 i dwoma kontrolerami LAN 10 Gb/s. 5
Artykuły spokrewnione
Facebook
Ostatnio komentowane