Dlaczego Android ma powolne UI?
Kiedy
porównamy sobie płynność animacji interfejsu w sprzęcie Apple z systemem iOS z urządzeniem o porównywalnych parametrach, ale wyposażonym w system Android, zauważymy że w tym drugim możemy zauważyć lagujące animacje interfejsu. Pierwotnie tłumaczono to tym, że proces renderowania UI nie było przyśpieszane sprzętowo. Jednak w Honeycombie się to zmieniło, a lagi zdarzają się nadal. Co więc jest nie tak?
Serwis Cult of Mac dotarł do Andrew Munn'a, który odbywał staż w firmie Google. Twierdzi on, że zna odpowiedź na to pytanie i jeśli ma rację, to niestety naprawienie tego problemu nie jest łatwe. Według Munn'a, wszystkiemu winny jest wadliwy projekt początkowy - pierwotnie Android był robiony z myślą o konkurencji z BlackBerry i miał nie obsługiwać dotykowych ekranów. Później pojawił się iPhone i nastąpił nagły zwrot w rozwoju systemu. Niestety, przy tej okazji nie zmieniono pewnych podstawowych założeń.
Chodzi o to, że w Androidzie, proces renderowania interfejsu uruchamiany jest z normalnym priorytetem, więc musi "walczyć" o zasoby z innymi aplikacjami działającymi w tle, np. agentem pobierającym nam najnowsze podcasty. W iOS natomiast, renderowanie UI ma najwyższy priorytet, co w uproszczeniu oznacza, że gdy wykonywana jest jakaś animacja, wszystko inne tak jakby zostaje zatrzymane. Póki Android miał być konkurencją dla BlackBerry, takie podejście miało rację bytu, gdyż tam płynność animacji interfejsu nie miała tak dużego znaczenia.
Niestety, przy okazji zmiany grupy urządzeń docelowych na te, które wyposażone są w ekrany dotykowe, nie zmieniono tego podejścia i przez to mamy dzisiaj problem z płynnością interfejsu. Dlaczego Google do tej pory tego nie naprawiło? Ponieważ wymagałoby to dużych zmian we frameworku interfejsu, a te z koli wymuszałyby przynajmniej częściowe przepisanie wszystkich aplikacji dla Androida, z czego, jak nietrudno się domyśleć, deweloperzy nie byliby zadowoleni.
Kiedy porównamy sobie płynność animacji interfejsu w sprzęcie Apple z systemem iOS z urządzeniem o porównywalnych parametrach, ale wyposażonym w system Android, zauważymy że w tym drugim możemy zauważyć lagujące animacje interfejsu. Pierwotnie tłumaczono to tym, że proces renderowania UI nie było przyśpieszane sprzętowo. Jednak w Honeycombie się to zmieniło, a lagi zdarzają się nadal. Co więc jest nie tak?
porównamy sobie płynność animacji interfejsu w sprzęcie Apple z systemem iOS z urządzeniem o porównywalnych parametrach, ale wyposażonym w system Android, zauważymy że w tym drugim możemy zauważyć lagujące animacje interfejsu. Pierwotnie tłumaczono to tym, że proces renderowania UI nie było przyśpieszane sprzętowo. Jednak w Honeycombie się to zmieniło, a lagi zdarzają się nadal. Co więc jest nie tak? Serwis Cult of Mac dotarł do Andrew Munn'a, który odbywał staż w firmie Google. Twierdzi on, że zna odpowiedź na to pytanie i jeśli ma rację, to niestety naprawienie tego problemu nie jest łatwe. Według Munn'a, wszystkiemu winny jest wadliwy projekt początkowy - pierwotnie Android był robiony z myślą o konkurencji z BlackBerry i miał nie obsługiwać dotykowych ekranów. Później pojawił się iPhone i nastąpił nagły zwrot w rozwoju systemu. Niestety, przy tej okazji nie zmieniono pewnych podstawowych założeń.
Chodzi o to, że w Androidzie, proces renderowania interfejsu uruchamiany jest z normalnym priorytetem, więc musi "walczyć" o zasoby z innymi aplikacjami działającymi w tle, np. agentem pobierającym nam najnowsze podcasty. W iOS natomiast, renderowanie UI ma najwyższy priorytet, co w uproszczeniu oznacza, że gdy wykonywana jest jakaś animacja, wszystko inne tak jakby zostaje zatrzymane. Póki Android miał być konkurencją dla BlackBerry, takie podejście miało rację bytu, gdyż tam płynność animacji interfejsu nie miała tak dużego znaczenia.
Niestety, przy okazji zmiany grupy urządzeń docelowych na te, które wyposażone są w ekrany dotykowe, nie zmieniono tego podejścia i przez to mamy dzisiaj problem z płynnością interfejsu. Dlaczego Google do tej pory tego nie naprawiło? Ponieważ wymagałoby to dużych zmian we frameworku interfejsu, a te z koli wymuszałyby przynajmniej częściowe przepisanie wszystkich aplikacji dla Androida, z czego, jak nietrudno się domyśleć, deweloperzy nie byliby zadowoleni.