Для многих пользователей «зеленого робота», даже для тех, кто прилично разбирается в тонкостях системы, не понятен один и тот же вопрос, ставший для них предметом насмешек и основным критерием, почему не стоит брать аппарат на Android, а для других головной болью, с которой приходиться мириться в угоду функциональности системы, почему же всё-таки ОН тормозит? На всех устройствах. Без исключений.
Обратимся к короткой статье и попытаемся разобраться во всех тонкостях и процессах. Текст перенасыщен техническими терминами, но статья будет понятна тем, кто уже не первый год имеет опыт работы с Android. Данная сатья является переводом оригинальной поста Эндрю Манна на его странице в Google+.
Предварительные замечания
Прежде чем приступить, мне нужно сделать пару замечаний. Во-первых, обо мне: третий год я учусь на инженера по программному обеспечению. Я проходил практику в команде Android, и, хотя Romain Guy, который занимался аппаратным ускорением в Honeycomb, отзывался о моей работе, тем не менее, я никогда не был штатным сотрудником Android, и я не видел исходного кода, который отвечает в устройствах Android за визуализацию. У меня нет точных сведений о том, как устроен Android, и я не могу гарантировать того, что все, что я скажу, на сто процентов соответствует истине, хотя я постарался сделать свою домашнюю работу на отлично.
Во-вторых, с января я планирую начать стажировку в команде Windows Phone, поэтому может показаться, что тон моей статьи бессознательно направлен против Android, хотя, если вы спросите моих друзей, меня сложно заткнуть, когда я начинаю говорить про Android. У меня больше футболок с логотипом Android, чем дней в неделе, и я скорее избавлюсь от своего Macbook, чем от Nexus S.
Штаб-квартира Google – Googleplex – для меня как второй дом, я часто бывал там и часто засыпал там – к ужасу испуганных уборщиков (если когда-нибудь у вас будет возможность побывать там, попробуйте французские гренки с бананом в “Большом столе”, они великолепны). В любом случае, я скорее склоняюсь в сторону Android.
Наконец, нужно отметить, что мнения, высказанные в этой статье, не отражают точку зрения моих прошлых или будущих работодателей, а принадлежат исключительно мне самому. Давайте приступим.
В чем проблема
Диана Хэкборн (Dianne Hackborn) – член команды Android – начинает свою статью о причинах притормаживания интерфейса Anrdoid следующими словами:
Если рассматривать прорисовку интерфейса внутри окна, то вам необязательно прибегать к аппаратному ускорению, чтобы достичь полных шестидесяти кадров в секунду (60 fps) в процессе рендеринга. Это во многом зависит от числа пикселей на дисплее и от производительности центрального процессора. Например, Nexus S не испытывает никаких проблем с прорисовкой интерфейса на скорости 60 fps, если речь идет о стандартных задачах вроде листания списков на его дисплее с разрешением 800×480.
А? Как же так? Каждый, кто держал в руках Nexus S, знает, что он тормозит почти всегда, если только речь не идет о скроллинге простейшего списка. И забудьте о сколько-нибудь приличной производительности, если в фоновом режиме что-то происходит, например, устанавливается приложение или происходит обновление интерфейса.
Напротив, iOS работает плавно даже в том случае, когда в фоновом режиме происходит инсталляция приложений. Диана, конечно, не может врать насчет потенциальной производительности процессора, мы знаем это, но тогда в чем же дело?
Первопричина
Она состоит вовсе не в том, что т.н. “сборщик мусора” [процесс, который управляет очисткой памяти и является одной из форм автоматического управления памятью устройства] тормозит систему. И дело не в том, что Android написан на псевдокоде в отличие от iOS, которая реализована на машинном коде.
Причина состоит в том, что прорисовка интерфейса на устройствах iOS происходит в рамках выделенного потока пользовательского интерфейса с наивысшим приоритетом. В то время как Android следует стандартной PC модели, где интерфейс рендерится в рамках основного потока с обычным приоритетом.
Что это значит для пользователя?
Это – не какое-то абстрактное различие. Вы можете убедиться в этом лично. Возьмите iPad или iPhone и откройте Safari. Попробуйте загрузить сайт со сложной версткой, что-то вроде Facebook. Пока происходит загрузка страницы, приложите палец к экрану и подвигайте им. Процесс загрузки немедленно остановится. Сайт не будет загружаться до тех пор, пока вы не уберете палец с экрана. Это происходит потому, что поток пользовательского интерфейса прерывает все остальные события и прорисовка интерфейса происходит с наивысшим приоритетом.
Если вы повторите этот опыт на Android, вы обратите внимание, что браузер попытается наилучшим образом выполнять сразу две задачи: загружать страницу и прорисовывать интерфейс, следя за движением вашего пальца. Это – как раз тот случай, когда двухъядерный процессор может пригодиться Android; вот поэтому, кстати, Galaxy S II знаменит плавностью своей работы.
Когда вы касаетесь экрана в момент установки приложения из App Store на устройстве iOS, инсталляция мгновенно приостанавливается, чтобы прорисовать интерфейс в зависимости от ваших действий. Android же пытается сделать обе вещи одновременно и с одинаковым приоритетом, что существенным образом сказывается на частоте кадров.
Как только вы обратите внимание на эту особенность Android, вы будете замечать ее постоянно. Почему, например, в приложении Movies такая заторможенная прокрутка? Потому что эскизы фильмов добавляются динамически, пока вы скроллите вниз, в то время как на устройстве iOS эти эскизы будут добавлены после того, как прокрутка остановится.
Исправление
Несколько человек (Chi-Ho Kwok и особенно Brent Royal-Gordon) указали мне на ошибки, которые я допустил выше в описании работы iOS. Фундаментальные различия между поведением Android и iOS остаются в силе, однако я весьма упростил поведение iOS, потому что я не знаком с его принципами. Давайте дадим слово Brent Royal-Gordon.
Описание поведения iOS – не совсем точное. Тут несколько вещей происходит одновременно:
— Компоновка изображения и его анимация на основе текущих настроек – все то, что входит в слой основной графической модели, – действительно происходят в фоновом потоке.
— Прорисовка нового контента в рамках основной графической модели и обеспечение его анимации происходит в главном потоке. Это – тот же самый поток, в котором обрабатываются действия пользовательского интерфейса.
Весь код приложения, который был написан разработчиком без учета указанных хитростей, будет исполняться в главном потоке. Однако Apple предоставляет разработчику весьма удобные API (например, Grand Central Dispatch и NSOperation), для того чтобы переложить многие вещи на фоновые потоки, которые управляются системой. Например, в iOS 5 вы можете сделать так, чтобы вообще не было возможности исполнять в основном потоке тот код приложения, который относится к основным данным программы и содержится в объектно-реляционной базе данных.
Все то, что вы заметили выше – то, что изображения подгружаются не во время, а после прокрутки, а также что WebKit останавливает прорисовку интерфейса, когда система отслеживает касание к экрану, – все это вовсе не было изначально задумано, как некий специальный механизм, который останавливает время, пока пока палец находится на экране.
Это все же не совсем верно: главный поток переходит в особый режим, когда происходит касание экрана, и по умолчанию некоторые функции фонового режима приостанавливают работу. Тем не менее, масса других вещей вроде загрузки с диска или взаимодействия с сетью исполняются целиком и полностью в фоновом режиме и не приостанавливаются; в том числе ничего специально не останавливается в момент прокрутки.
Разработчик должен специально позаботиться о том, чтобы приостанавливать определенные процессы, пока выполняется прорисовка пользовательского интерфейса. Это – преднамеренное поведение каждого конкретного приложения, о котором тщательно позаботился разработчик.
Это – не техническое различие между Android и iOS; это – культурное различие между разработчиками. Хороший разработчик iOS не станет продавать приложение, пока оно не будет идеально работать на 60 fps при прокрутке или в момент касания экрана пользователем; а вот хороший Android разработчик станет.
Другие причины
Основная причина, по которой у Android притормаживает интерфейс, заключается в низком приоритете, с которым исполняется прорисовка пользовательского интерфейса, однако это – не единственная причина.
Аппаратное ускорение
Во-первых, аппаратное ускорение, несмотря на рассуждения Дианы, – часто весьма необходимо. Мой Nexus S не был таким уж быстрым, пока я не обновился до ICS. Аппаратное ускорение реально улучшает такие приложения, как домашний экран и Android Market. Перекладывание задач по прорисовке интерфейса на графический процессор также увеличивает время жизни аккумулятора, поскольку графический процессор имеет дело с фиксированным набором функций, которые тратят меньше энергии на исполнение.
Сборщик мусора
Во-вторых, вопреки тому, что я сказал ранее, “сборщик мусора” все же остается проблемой. Например, если вы пользовались фотогалереей в Honeycomb или в ICS, вам наверняка было интересно, почему в этом приложении такая низкая частота кадров.
Оказывается, частота кадров искусственно ограничена на уровне 30 fps, потому что, хотя листание фотографий в большинстве случаев может осуществляться на скорости 60 fps, тем не менее, часто “сборщик мусора” тормозит этот процесс и приводит с заметному “заиканию”. Чтобы решить проблему этого “заикания”, разработчики искусственно ограничили частоту кадров на уровне 30 fps, т.е. сделали листание фотографий медленным, но стабильным.
Проблема железа
В-третьих, существуют аппаратные проблемы, которые обсуждает Диана. Процессор Tegra 2, несмотря на богатое воображение отдела продаж Nvidia, – ущербен, поскольку имеет низкую пропускную способность памяти и не поддерживает набор инструкций NEON (эквивалент инструкций SSE у процессоров Intel; этот набор инструкций позволяет процессору использовать более быструю математическую модель).
Планшеты Honeycomb были бы лучше с другим GPU, даже если в других отношениях гипотетически они работали бы медленнее, чем с Tegra 2. Например, с процессором Hummingbird от Samsung, который стоит в Nexus S, или с Apple A4. Это значит, что самый быстрый из планшетов Honeycomb – Galaxy Tab 7.7 – работает на процессоре Exynos, который стоит в Galaxy S II.
Компоновка изображения
В-четвертых, у Android есть масса вариантов, чтобы улучшить процесс компоновки изображения. В iOS каждый экран прорисован индивидуально и в таком виде хранится в памяти. Так что от графического процессора требуется лишь анимировать процесс совмещения этих слоев изображений, т.е. осуществить перекомпоновку.
Графические процессоры делают это превосходно. К сожалению, в Android иерархия слоев пользовательского интерфейса разрушается перед рендерингом, поэтому каждая часть экрана, требующая анимации, каждый раз перерисовывается заново.
Псевдокод
В-пятых, Davlik VM – не такой мощный, как JVM. Java печально известна ужасной производительностью пользовательского интерфейса на настольных компьютерах. Однако Davlik не наследует автоматически все эти проблемы. Swing был ужасен, потому что он был только кросс-платформенным слоем поверх родного API. Интересно отметить, что графическая модель Windows Phone 7 основана на машинном коде, хотя изначально предполагалось реализовать ее целиком на Silverlight.
Microsoft в конечном счете решила, что для достижения необходимого уровня интерфейса он должен быть реализован в машинном коде. На Windows Phone 7 легко можно заметить разницу между приложениями, реализованными на псевдокоде и на машинном коде, потому что приложения сторонних производителей написаны на Silverlight и поэтому уступают в производительности оригинальным. (NoDo и Mango сгладили эту проблему, так что сегодня интерфейсы, реализованные на Silverlight, выглядят в целом очень плавными.)
К счастью, каждая из описанных выше пяти проблем может быть решена без существенных изменений в Android. Аппаратное ускорение будет на всех аппаратах с ICS, Davlik продолжает улучшать работу “сборщика мусора”, Tegra 2 наконец устарел, нашлись обходные пути для проблем с компоновкой изображения, а Davlik VM становится быстрее с каждым релизом. Недавно я спросил Джейсона Кинкейда из TechCrunch, обладал ли его Galaxy Nexus плавным интерфейсом, и вот что он мне ответил.
В целом я считаю работу интерфейса ICS на Galaxy Nexus весьма плавной. Иногда появляются заикания, например, есть одно место, где я постоянно сталкиваюсь с притормаживанием интерфейса Galaxy Nexus, – это кнопка многозадачности, которая подвисает на четверть секунды. Однако я считаю, что и iPhone 4S подвисает больше, чем ожидалось, например, когда пользуешься общим поиском (когда смахиваешь основной экран вправо).
Итак, с проблемами Android все ясно, они практически решены, так? Не совсем.
Что дальше?
Интерфейс Android никогда не будет полностью плавным из-за тех конструктивных ограничений, с которых мы начали:
- Прорисовка пользовательского интерфейса происходит в основном потоке приложения;
- Прорисовка пользовательского интерфейса имеет обычный приоритет.
До тех пор, пока эти ограничения не будут сняты, нет никакой гарантии, что интерфейс будет плавным даже на Galaxy Nexus и на четырехъядерном EeePad Transformer Prime. Это значит, что в рамках действующих ограничений производительность Galaxy Nexus приближается к производительности трехлетнего iPhone. Так почему же команда Android создала такую ущербную графическую модель?
Последствия далекого выбора
Работа над Android началась до того, как вышел первый iPhone, и Android задумывался в качестве конкурента Blackberry. Оригинальный прототип Android не имел сенсорного экрана [как и Blackberry]. Компромиссы пользовательского интерфейса Android имеют смысл лишь в рамках модели, имеющей клавиатуру и трекбол. Когда вышел iPhone, команда Android кинулась на создание конкурирующей модели, однако, к сожалению, было слишком поздно переосмысливать графическую парадигму и переписывать программный каркас.
Windows Mobile 6.5, Blackberry OS и Symbian имели жуткую производительность сенсорного экрана по той же причине: как и Android, они не были разработаны для того, чтобы иметь графический интерфейс в качестве главного приоритета. После выхода iPhone компании RIM [Blackberry], Microsoft и Nokia остановили разработку своих мобильных операционных систем, чтобы начать все с нуля. Android – это единственная мобильная операционная система, которая существует со времен первого iPhone.
Но почему же команда Android не перепишет графическую модель? Пусть об этом скажет Romain Guy:
…много работы, которую мы вынуждены делать сегодня, преподносит нам выбор, сделанный нами много лет назад. …основная проблема – это поток, в котором происходит анимация пользовательского интерфейса. Мы ищем другие решения, чтобы улучшить производительность интерфейса (планирование прорисовки силами вертикальной синхронизации, вместо того чтобы останавливать вертикальную синхронизацию после прорисовки, использование отдельного потока для прорисовки интерфейса и т.д.). Разумеется, самое легкое решение – переписать графическую модель и ее инструментарий, однако у этого решения есть также существенные недостатки.
Romain не указывает, о каких именно недостатках он говорит, однако нетрудно сделать предположения:
- Все приложения должны быть переписаны для того, чтобы они могли работать в рамках новой графической модели;
- Android все равно будет вынужден обеспечить обратную совместимость для старых приложений;
- Работа над остальными функциями Android будет остановлена до тех пор, пока не будет разработана новая графическая модель.
Тем не менее, я полагаю, что им все же придется переписать графическую модель заново, несмотря на недостатки такого решения. Скажу как начинающий менеджер по продукту, притормаживание интерфейса Android просто неприемлемо. Решение этой проблемы должно стать для команды Android приоритетом номер один.
Когда речь с друзьями-специалистами и обычными пользователями – заходит об Android, я всё чаще слышу, что Android притормаживает и вообще работает медленно. В действительности, Android может открывать приложения и показывать веб-сайты также быстро, как и iPhone, или даже быстрее, однако с восприятием не поспоришь. Команде разработчиков Android предстоит пройти ещё долгий путь по улучшению работы интерфейса, прежде чем образ ОС от Google будет восстановлен в глазах пользователей.
