Почему Android начинает тормозить со временем, а iPhone — нет
Если вы вдруг обнаружили, что ваш Android-смартфон со временем начал тормозить, знайте, что вы такой не один. Практика показывает, что эта проблема преследует многих пользователей, которые безуспешно пытаются найти ответ на вопрос, почему старые телефоны начинают работать медленнее. Ведь поверить в то, что причиной всему – естественный износ или изменение личностного восприятия быстродействия, довольно сложно. В конце концов, физика учит нас, что это время может течь по-разному в зависимости от скорости, но не наоборот. Тем интереснее бывает разобраться, в чём же тут дело на самом деле.
Ваш старый Android-смартфон начал работать медленнее? Он просто состарился
Начать предлагаю с развенчания мифа о том, что это производители замедляют быстродействие своих смартфонов специально. Есть мнение, что они делают это через обновления (а как же ещё?), встраивая туда специальные механизмы, которые влияют на скорость работы. В принципе, звучит логично, учитывая, что производители в первую очередь заинтересованы в том, чтобы продать как можно больше смартфонов и продавать их как мощно чаще. Но это мало похоже на правду по нескольким причинам.
Замедляют ли производители старые смартфоны
Хотите быстрый смартфон? Покупайте флагманы хотя бы раз в пару лет
- Во-первых, за производительность смартфона отвечает сочетание центрального процессора и графического ускорителя. Именно их потенциал оценивают бенчмарки. Если производитель попытается их замедлить, это будет видно в синтетических тестах.
- Во-вторых, это довольно накладно с точки зрения трудозатрат. Ведь разработчикам нужно замедлить смартфон таким образом, чтобы он продолжал работать и тянул хотя бы штатные функции, которые изначально создавались под конкретное железо с конкретной мощностью.
- В-третьих, замедление, если о нём станет известно, мгновенно поставит крест на репутации производителя, которому пришло в голову поступить таким образом со своими клиентами. А в долгосрочной перспективе это невыгодно.
- В-четвёртых, замедлять смартфон принудительно – это решение довольно опрометчивое, за которое можно схлопотать групповой судебный иск. Если помните, с Apple в одной только Франции содрали около полумиллиарда долларов за замедление iPhone с изношенной батареей.
Почему замедляются старые смартфоны
Apple показала, что оптимизация решает больше, чем железо
Почему, в таком случае, со временем фактическое быстродействие смартфонов на Android падает? На самом деле причин у этого немногим больше, чем у довода о том, что эта практика очень порочна. Смотрите сами:
В WhatsApp для Android появится разблокировка по лицу как на iOS
- Если смартфон начал зависать, это не значит, что он потерял в производительности. Высока вероятность, что какое-то приложение, которое вы скачали, оказывает повышенную нагрузку на железо. Пройдитесь по списку установленного ПО и поудаляйте последние приложения, тем более если скачали их не из Google Play.
- Приложения начали запускаться медленнее из-за расширения функциональных возможностей и оптимизации под более новые смартфоны. Если вашему аппарату уже 2-3 года, не удивляйтесь, что его железо начинает с трудом тянуть привычные программы.
- Практика показывает, что Google Play может тормозить из-за того, что какое-то из обновлений оказывает на систему повышенную нагрузку. Google выпускает апдейты для своего каталога примерно каждую неделю, поэтому нет ничего удивительного в том, что где-то происходит сбой. Для исправления удалите в «Настройках» все обновления Google Play.
- При прямом сравнении с более современными смартфонами производительность вашего аппарата скорее всего тоже будет выглядеть не ахти. Просто более современное железо делает своё дело и закономерно обгоняет устаревший процессор и графику, невзирая на то, что они когда-то считались флагманскими.
Можно ли разогнать старый Android? В большинстве случаев практически нет, хотя бы потому, что зачастую быстродействие является оценочной категорией. Проще говоря, вам кажется, что производительность вашего смартфона упала, поскольку в начале он работал быстрее, чем сейчас. Но это не так. Просто задачи, которые вы возлагаете на свой аппарат, стали требовать больше ресурсов, а сам он не стал от этого мощнее. Вспомните, как ещё лет 15-20 назад мы пользовались интернетом на скорости 1 Мбит/с и не знали горя, а теперь негодуем, когда она снижается ниже 100 Мбит.
Чем iPhone лучше Android
С другой стороны, оптимизация — это вещь, которая способна творить чудеса, именно она отвечает на вопрос, почему iPhone работают быстрее Android. Отличной лакмусовой бумажкой того, что такой подход работает, стала iOS 14. С выходом последней версии ОС от Apple оказалось, что даже старые iPhone 6s и iPhone SE могут не просто не тормозить, но и работать значительно быстрее, чем они работали на старте. Мало того, что компании удалось удержать быстродействие системы на высоком уровне, она ещё и заставила разработчиков оптимизировать свой софт так, чтобы он вдруг бы не затормозил на её аппаратах. Жаль только, что производителям Android-смартфонов это в большинстве случаев не надо. А бездействие, как известно, порой бывает даже хуже действия.
Источник
Почему iPhone хватает 4 ГБ ОЗУ, а Android — нет?
Из года в год Android-производители форсируют железную часть смартфонов: 108 МП, 8к-видеосъемка 12гб оперативной памяти… Но подождите, у iPhone всего 4 ГБ ОЗУ. И это не мешает ему работать на уровне или даже быстрее своих конкурентов! И как же удалось компании Apple добиться такого результата? Обо всём этом в сегодняшнем ролике.
Для начала немного теории. Что такое оперативная память и для чего она нужна в смартфоне? Если говорить простым языком, то это память, в которой хранятся все запущенные приложения, их данные, и сама операционная система!
Естественно, чем больше у вашего девайса оперативной памяти, тем комфортнее и приятнее с ним взаимодействовать.
Большинство пользователей iPhone даже не знают сколько оперативной памяти у них в смартфоне. Это обусловлено тем, что пользователей устраивает работа многозадачности в их смартфонах, они просто пользуются и получают удовольствие от плавности и скорости работы. Так как же Apple все же удается хорошо работать с 4 ГБ оперативной памяти?
Может быть дело в системе? На самом деле чудес не бывает, Android и iOS требуется примерно одинаково-большое количество ОЗУ. К примеру, пару лет назад, один зарубежный канал Android Authority провёл детальное сравнение. Автор взял два смартфона на iOS — это iPhone 7 и на Android — Nexus 5х, с одинаковым количеством оперативки – 2 ГБ. iPhone 7 c момента запуска имеет МЕНЬШЕ свободной оперативной памяти чем смартфон на Android: около 750 МБ против 1,2 ГБ у Nexus. Но это до того момента пока вы не запустите какое-либо из ваших приложений.
Мы повторили тест на iPhone 11 и Pixel 3 с Pixel 4. Теперь получается, что цифры сопоставимы: в iPhone задействовано около 2 ГБ оперативки, а Pixel использует около 2,4 ГБ.
Окей, может быть дело в том, что приложения на Android занимают больше места в оперативке? Ведь Apple любит разработчиков, а они отвечают им взаимностью. Но тоже нет: во многих случаях размер занимаемого места в оперативной памяти на iOS и Android примерно равны, но в некоторых случаях приложения на iOS занимают почти в 1.5-2 раза меньше оперативной памяти! Скорее всего это связано с более оптимизированным исполняемым кодом приложения, ведь языки написания приложений очень разные.
При подсчетах, Android-приложения в совокупности занимают всего на 6% больше места в оперативной памяти.
Но это только начало, как говорят многие пользователи яблочной продукции «Оптимизация Решает!», как оказалось, в этом есть доля правды!
Оба аппарата работают с приложениями молниеносно, с андроидом все понятно, у него все хранится в ОЗУ, но как справляется iPhone с его жалкими 4 гигабайтами? Вся магия кроется как раз в работе iOS с оперативной памятью. Базово и iPhone, и Android имеют примерно одинаковый планировщик работы с памятью. Если в момент запуска нового приложения, у смартфона попросту нет свободной оперативной памяти, он выкинет одно из ранее запущенных и откроет то, которое тебе нужно в данный момент!
В мире компьютеров операционная система Windows имеет файл подкачки (pagefile.sys), еще его называют СВОП (термин пишется по-английски — swap). Это такое пространство на вашем жестком диске, куда система переносит неиспользуемые данные из оперативной памяти. Чтобы не хранить их в ОЗУ, давно запущенные приложения попросту переносятся на жесткий диск, тем самым освобождая место для еще одной вкладки Chrome. ПК-бояре понимают о чем я.
На смартфонах все немного сложнее, многие смартфоны до сих пор имеют не самые быстрые флеш-накопители в постоянной памяти. К этому прибавляем то, что флеш-память имеет сравнительно небольшой ресурс чтения и записи, поэтому производители смартфонов прибегли к иной реализации!
Представим такую ситуацию, у нас 4Гб оперативной памяти, открыто 5 приложений, память вся уже заполнена, как же запустить еще одно приложение и при этом не закрывать одно из пяти, то есть те которые уже открыты. Всё дело в том что и у iOS, и у Android тоже есть так называемый Сжатый СВАП – с помощью сжатия, которое похоже на то, что делает архиватор. Приложение сжимается внутри оперативной памяти, система выбирает самые массивные приложения, будь то одна большая или две мелких игры, происходит сжатие, тем самым освобождается до 50% больше места, и теперь можно запустить еще одно приложение.
Такая схема работает и на iPhone, и на Android, но Apple пошли куда дальше. Они придумали, как делить пространство на отдельные страницы — блоки размером 16 КБ, которые вмещают в себя любую информацию. Такую страницу можно пометить как грязную (dirty) или чистую (clean). Чистая — память, которая больше не используется (то есть никакие объекты больше не ссылаются на неё, и её можно спокойно выгрузить). В дальнейшем она может быть загружена с диска («page out»), такая память содержит фреймворки, исполняемый код и файлы только для чтения.
К примеру, в таких страницах могут быть данные текстур игры, которые не используются приложением даже после повторного запуска из фонового режима, также в иных приложениях это могут быть разные AR-тикеры, маски и прочие блоки кода, которые не использует приложение пока пользователь повторно не запустит программу из фона.
Грязная — память, которая ещё используется в приложении, выгрузить её невозможно, поэтому при переходе приложения в фон чистая просто выгружается, а грязная сжимается по двум методам сжатия:
- Сжатие буфера — использует одношаговый метод сжатия файлов, этот метод используется для сжатия мелких файлов до 8 МБ.
- Сжатие потока — использует несколько шагов для сжатия файлов, в том числе и повторное сжатие ранее сжатых файлов, что делает его идеальным для сжатия больших файлов.
Допустим у нас есть приложение Instagram, оно занимает 300 МБ в оперативной памяти, первым этапом будет очистка чистой памяти, которая была в запасе у приложения и больше не понадобится. Размер в ОЗУ уменьшается примерно до 170 МБ. Далее операционная система прибегнет к одному из двух методов сжатия грязной памяти. Благодаря продуманному алгоритму сжатия, грязная память из 170 мегабайт сжимается до внушительно маленького размера — менее 10 МБ!
В свою очередь, производители смартфонов на базе Android вышли из ситуации более простым решением, увеличить размер оперативной памяти чтобы меньше использовать сжатый свап.
Итак, время теста. Мы взяли устройства разных поколений — iPhone 11 и Pixel 3 — зато оба с 4 Гб. Посмотрим, что произойдет.
Pixel держит в памяти три игры. Начал выгружать их из памяти при запуске четвёртой.
iPhone полноценно держит шесть игр. Начал потихоньку выгружать на седьмой, но не все. Все начали вылетать только на восьмой игре.
И здесь мы подходим к кульминации вопроса, нужно понять, за счет чего iPhone так быстро производит сжатие данных в оперативной памяти? А дело все вот в чем. Чтобы быстро провернуть данную операцию, потребуется мощный процессор с высокой производительностью Больших Ядер!
Если мы посмотрим на скриншоты из бенчмарка GeekBench 5, то увидим превосходство А13 Bionic перед Snapdragon 865 в 1.5 раза, а ведь А14 Bionic еще даже не вышел! Именно производительность на один поток данных всегда было главным козырем процессоров от компании Apple! Большой проблемой Android-смартфонов является то, что они все построены на очень разном железе, производители вынуждены оптимизировать систему для более слабых девайсов, у которых попросту нету столь внушительной мощности процессора или быстрой памяти. Хотя подвижки со стороны компании Qualcomm уже есть.
Так еще с презентации Snapdragon 855 было замечено, что компания сделала упор на одно высокопроизводительное ядро (prime core), которое имеет повышенную частоту и размер кэш-памяти, но этого все равно пока мало, чтобы догнать чипы Apple.
Думаю, теперь многим стало понятно, почему iPhone не нужно столь большое количество оперативной памяти. Размер — не главное, лучше вложить больше денег в софтверную часть, и правильно распределять ресурсы своего железа за счет умных алгоритмов сжатия файлов в оперативке.
Источник
По следам разрушителей мифов или Почему Android тормозит, а %мобильная ОС% нет?
Добрый день, Хабр!
Мой предыдущий перевод статьи про аппаратное ускорение в Android вызвал бурное обсуждение в комментариях, основным мотивом которого был вопрос «так почему же тормозит Android?». Аналогичная ситуация наблюдается по всему интернету, и потому я привожу ниже еще один очень интересный и свежий перевод (снова из Google+), где автор Andrew Munn (о нем ниже) анализирует настоящие причины тормозов Android. С удовольствием прочитал этот пост сам и горд возможностью первым поделится им с хабрасообществом.
Почему Android тормозит, в то время как iOS, Windows Phone 7, QNX и WebOS столь плавны в работе?
Этот пост призван ответить на этот вопрос.
Однако, прежде чем перейти к сути, несколько оговорок. Во-первых, я студент третьего курса специальности «software engineering». Я интернирован в команде Android, и Romain Guy который был ответственен за большую часть работы аппаратного ускорения в Honeycomb, рассмотрел некоторые участки и моего кода, но я не был в команде разрабатывающей сам framework, и я никогда не читал исходники кода отрисовки в Android. У меня нет какого-либо серьёзного авторитета на знание Android и я не могу гарантировать, что я говорю здесь, обязательно на 100% точно, но я сделал все возможное, чтобы аргументировать свои слова.
Во-вторых, я на стажировке в команде Windows Phone, начиная с января, так что вполне возможно, что эта должность могла бы подсознательно настроить меня против Android, но если вы спросите любого из моих друзей, это действительно трудно, попросить меня не болтать об Android. У меня больше Android футболок, чем дней в неделю, и я предпочел бы отдать мой Macbook, чем мой Nexus S. Googlplex это как второй дом. Во всяком случае, мои интересы, пожалуй, смещены в пользу Android.
Итак приступим к анализу предыдущей статьи о мифах (речь идет о полной версии поста Дианы Hackborn).
Диана начинает свой пост удивительным откровением:
«Глядя на рендеринг внутри окна, мы не обязательно должны использовать аппаратное ускорение для достижения полных 60FPS. Это во многом зависит от количества пикселей в дисплее и скорости вашего процессора. Например, у Nexus S нет проблем с 60 кадрами в секунду для всех нормальных вещей которые вы видите в Android UI, как например прокрутка списков на своем 800×480 экране.»
Да ну? Как такое может быть? Любой, кто использовал Nexus S знает, что он замедляется при всем, кроме разве что простого ListViews. И забудьте про любое подобие достойной производительности, если в фоновом режиме, что-то происходит, например установка приложения или обновления пользовательского интерфейса с внутреннего накопителя. С другой стороны, іOS работает на 100% гладко даже при установке приложений. Но мы знаем, Диана не врет о потенциальной производительности центрального процессора, так что же происходит?
Основная причина
Это не паузы из-за сборщика мусора. Это не потому, что Android работает через байт-код, а іOS работает на нативном коде. Это потому, что в iOS рендеринг всего интерфейса происходит в отдельном потоке пользовательского интерфейса в режиме приоритета реального времени. С другой стороны, Android следует традиционной для ПК модели, в которой основной рендеринг происходит с нормальным приоритетом.
Это не абстрактная или академическая разницы. Вы можете увидеть это самостоятельно. Хватайте ближайший iPad или iPhone и открывайте Safari. Начните загрузку сложной веб-страницы, такой как Facebook. На середине загрузки, приложите палец к экрану и подвигайте им вокруг. Вся отрисовка мгновенно останавливается. Сайт просто не будет загружаться, пока вы не уберете палец. Это потому, что поток пользовательского интерфейса перехватывает все события и рендеринг пользовательского интерфейса осуществляется в режиме реального времени.
Если вы повторите это упражнение на Android, вы заметите, что браузер будет пытаться как отрисовать страницу, так и отобразить HTML, т.е. сделать «на отлично» как одно так и другое. Для Android, это тот случай, когда эффективный двухъядерный процессор действительно помогает, поэтому Galaxy S II и славится своей плавностью.
На iOS, когда приложение устанавливается из App Store, а вы приложите палец к экрану, установка мгновенно поставится на паузу, пока рендеринг не будет завершен. Android старается сделать и то и то с одинаковым приоритетом, поэтому частота кадров страдает. Как только вы заметите как это происходит, вы увидите что это повсюду на телефоне Android. Почему прокрутка в приложении «Фильмы» медленная? Поскольку эскизы фильмов динамически добавляются к списку фильмов, когда вы прокручиваете вниз, а вот на iOS они спокойно добавляются только в момент остановки прокрутки.
Несколько людей взялись объяснить ошибки, допущенные мною в упрощенном описании процесса отрисовки в iOS. В частности:
1) Композитинг и пред-настройка анимации — все что включает в себя Core Animation и рендеринг сопутствующих слоев действительно происходит в фоновом потоке.
2) Отрисовка нового контента в слое Core Animation и настройка их анимации происходит в основном потоке. Это то же поток в котором происходит отрисовка пользовательского интерфейса.
3) В нативном коде, весь создаваемый разработчиком код будет происходить в основном потоке. Тем не менее, Apple предлагает очень простой API (Grand Central Dispatch и NSOperation), чтобы переместить эти вещи в управляемые системой фоновые потоки. В iOS 5 можно даже заявить что Core Data (объектно-реляционные базы данных) контекст не может быть использован непосредственно в основном потоке.
Что же мы замечаем? Изображение не отрисовывается пока вы не закончите прокрутку списка, рендеринг страницы в WebKit останавливается, когда система отслеживает прикосновение к экрану, это изначально встроенный механизм, который ставит на паузу весь мир, пока палец на экране.
(На самом деле это не совсем верно: главный поток помещается в специальный режим во время слежения за сенсором, и по умолчанию, определенные обратные вызовы задерживаются в этом режиме. Тем не менее, многие другие вещи, например, загрузка с диска или сетевая активность хранятся полностью в фоновом потоке, не останавливаясь, ничто из этого автоматически не приостанавливается в момент прокрутки. Разработчик должен указать явно задержки для этих вещей). Это преднамеренное поведение тщательно реализовано разработчиком каждого отдельного приложения.
Это не техническое различие, это культурные различия. Хорошие разработчики под iOS не выпускают программное обеспечение, пока не работает на что-то около 60 кадров в секунду при прокрутке и отслеживает прикосновения практически идеально, как впрочем это делают и хорошие разработчики под Android.
Другие причины
Основная причина по которой Android тормозит это структура потоков UI и их приоритетность, но это не единственная причина. Во-первых, аппаратное ускорение, несмотря на оговорки Дианы, все-таки помогает. Мой Nexus S прежде никогда не работал так плавно с момента обновления до ICS [прим.перевод: Мой тоже! :)]. Аппаратное ускорение дает огромную разницу в приложениях, таких как домашний экран и Android Market. Помощь оказанная GPU также увеличивает время автономной работы, потому что графические процессоры — это оборудование с фиксированными функциями, так что они работают с меньшим энергопотреблением.
Во-вторых, вопреки тому что я утверждал ранее, сбор мусора по-прежнему проблема, даже при работе по совместительству с GC в Dalvik. Например, если вы когда-либо использовали приложение фотогалерея в Honeycomb или ICS вы можете удивиться, почему частота кадров такая низкая. Оказывается, частота кадров ограничена числом 30 кадров в секунду, а прокрутка фотографий возможна и при 60 FPS в большинстве случаев, но иногда паузы сборщика мусора приводят к заметному «заиканию». Ограничение частоты кадров до 30 исправляет «заикание» и обеспечивает плавную анимацию все время.
В-третьих, есть проблемы с оборудованием, что также упоминается Дианой. Tegra 2, несмотря на грандиозные претензии от отдела маркетинга Nvidia, наносит ущерб низкой пропускной способности памяти и не имеет поддержки набора инструкций NEON (NEON инструкции в ARM это эквивалент SSE от компании Intel, которые позволяют быстрее рассчитывать матрицы на CPU). Honeycomb таблетки были бы лучше с различными GPU, даже если они были бы теоретически менее мощные в некоторых отношениях, нежели Tegra 2. Например, Samsung Hummingbird в Nexus S или Apple A4. Это говорит нам, что самый быстрый выпущенная Honeycomb планшет, Tab Galaxy 7.7, работает под управлением процессора Exynos с Galaxy S II.
В-четвертых, Android имеет способ перейти на более эффективный композитинг пользовательского интерфейса. в iOS, каждый вид пользовательского интерфейса отображается отдельно и хранится в памяти, так для многих анимаций требуется только GPU для просмотра рекомпозиции пользовательского интерфейса. Графические процессоры очень хороши в этом. К сожалению, на Android, иерархия пользовательского интерфейса уплощена до рендеринга, поэтому анимация требует перерисовки каждого сектора экрана в которой она происходит.
В-пятых, Dalvik VM не так развита, как десктопная JVM. Java печально известна ужасной производительностью GUI на десктопах. Тем не менее, многие вопросы, не переносятся на реализацию Dalvik. Swing был ужасен, потому что являлся кросс-платформенным слоем на вершине родной API. Интересно отметить, что Windows Phone 7 в основной пользовательский интерфейс построен на нативном коде, хотя первоначальный план был — базироваться полностью на Silverlight. В Microsoft в конце концов решили, что для придания интерфейсу необходимой производительности, код должен быть родным. Это легко увидеть разницу между родным и байт-кодом на Windows Phone 7, поскольку сторонние приложения написанных на Silverlight уступает в производительности (Nodo и Mango смягчили эту проблему и Silverlight интерфейсы, как правило, сейчас очень плавные).
К счастью, каждый из пяти вопросов, перечисленных выше, разрешим без радикальных изменений в Android. Аппаратное ускорение будет на всех телефонах под управлением Android ICS, Dalvik продолжает совершенствовать эффективность своего сборщик мусора, Tegra 2, наконец, устареет, есть обходные пути для существующих проблем композиции интерфейса, и Dalvik VM становится быстрее с каждым выпуском. Недавно я спросил Джейсона Кинкейда с TechCrunch, насколько плавной была работа Galaxy Nexus и он ответил:
«В целом я счел ICS по Galaxy Nexus достаточно плавным в работе. Есть случайные заикания — одно место, где я могу получить последовательно испуг на Galaxy Nexus, это когда я нажимаю кнопку многозадачности, где он часто будет приостанавливается на четверть секунды. Тем не менее, я считаю, что iPhone 4S также подтормаживал больше, чем я ожидал, особенно, когда я переходил на доступ к общему поиску приложений (где вы проводите пальцем влево от главного экрана).»
Итак, поехали, проблема тормозов Android в основном решена, не так ли? Не так быстро.
Вперед в будущее
Android UI никогда не будет совершенно плавным из-за конструктивных ограничений, которые мы обсуждали в самом начале:
— Рендеринг интерфейса происходит на главном потоке приложения;
— Рендеринг интерфейса происходит с нормальным приоритетом;
Даже с Galaxy Nexus, или четырехъядерным процессором EeePad Transformer Prime, нет никакого способа, чтобы гарантировать гладкость и приемлемую частоту кадров, если эти два конструктивных ограничения остаются в силе. Это говорит, что мощности Galaxy Nexus хватит чтобы сравнится по плавности работы с первым iPhone трехлетней давности. Так почему же команда Android использовала именно такую структуру рендеринга?
Работа над Android началась еще до выхода iPhone, и на тот момент система Android была разработана, чтобы быть конкурентом Blackberry. В оригинальном прототип Android не было сенсорного экрана. Компромиссы Android имеют смысл устройств с аппаратной клавиатурой и трекболом. И когда вышел iPhone, команда Android бросилась к выпуску конкурента этому продукту, но, к сожалению, было уже слишком поздно, чтобы переписать весь пользовательский интерфейс системы.
Это же самая причина, почему Windows Mobile 6.5, Blackberry OS, Symbian имеют ужасную производительность сенсорного экрана. Как и Android, они не были предназначены для «приоретиризации» рендеринга пользовательского интерфейса. После выпуска iPhone, в RIM, Microsoft, и Nokia отказались от своих мобильных ОС и начали разработку с нуля. Android является единственной мобильной ОС, которая существовала до «эры iPhone».
Так почему же команда Android не изменила существующее положение дел? Я позволю Romain Guy объяснить:
«… Много работы, которую мы должны сделать сегодня, существует из-за определенного выбора, сделанного много лет назад…… С анимацией пользовательского интерфейса самая большая проблема. Мы работаем над другими решениями, чтобы попытаться улучшить её (возможность использования отдельный поток рендеринга, и т.д.). Простое решение, конечно, это создание нового графического инструментария но есть много минусов в этом подходе. «
Ромен не уточняет какие минусы и недостатки в этом решении, но это не сложно предположить:
— Все приложения должны быть переписаны для поддержки новой структуры;
— Android должен будет обеспечить режим поддержки для старых приложений;
— Работа на другие особенностями Android будет приостановлена, до то времени как новая система будет разработана;
Однако я считаю, что написание «с нуля» должно произойти, несмотря на эти минусы и недостатки. Как начинающий менеджер, я считаю, медлительность Android абсолютно неприемлемой. Следует сделать этот вопрос приоритетом №1 для команды Android.
Когда тема Android поднимается как технически подкованными, так и не-технически образованными друзьями, я слышу снова и снова, что Android тормозит и работает медленно. Реальность такова, что Android может открывать приложения и отображать веб-страницы так же быстро или даже быстрее, чем iOS, но восприятие — это всё. Исправление тормозящего UI это будет начало долгого пути, чтобы восстановить репутацию и образ Android.
Восприятие проблемы, тормоза — это нарушение философии компании Google. Google считает, что все должно быть быстрым. Вот ведущая философия Google Search, Gmail, и Chrome. Именно поэтому Google создал SPDY — для улучшения HTTP. Именно поэтому Google создает инструменты, помогающие оптимизировать ваш сайт. Именно поэтому Google запускает свой собственный CDN. Именно поэтому Google Maps отображается при помощи WebGL. Именно поэтому буферизации на Youtube что-то то что большинство из нас хорошо помнит, но видят все реже.
Но, пожалуй, одна наиболее важных причин отставания в интерфейсе Android неприемлемо исходит из области человеко-машинного взаимодействия (HCI). Современные сенсорные экраны предполагают соответствие «один к одному» между пальцем и анимацией на экране. Именно поэтому эффект перепрокрутки в iOS (эластичная резинка) это так здорово, весело, и интуитивно понятно. И именно поэтому сенсорные экраны авиакомпании Virgin America Flights так расстраивают: они невероятно тормозят и очень неточно срабатывают.
Тормоза пользовательского интерфейса прерывают связь человека и сенсорного экрана. Общение с устройством перестает быть естественным. Оно теряет магию. Пользователь исключается из взаимодействия с ними и должен безоговорочно признать, что они используют несовершенное компьютерное моделирование. Я часто «теряюсь» в іPad, но меня аж передергивает, когда Xoom заикается между экранами. 200 миллионов пользователей Android заслуживают лучшего.
И я знаю, они получат это в конечном счете. Команда Android является одной из самых преданных и талантливых команд разработчиков в мире. При таких звезд, как Диана Hackborn и Romain Guy Android находится в хороших руках.
Я надеюсь, что эта публикация сократит путаницу вокруг тормозов Android.
Немного удачи, и Android 5.0 принесет нам плавный Android, о котором мы все мечтали, с момента выхода HTC G1. В то же время, я буду в Редмонде работать над красивой и плавной мобильной ОС, и пытаться дать ей некоторое признание, которого она заслуживает.
Источник
