5 февраля 2014
Беседка №4: об изменениях в экосистеме Android
Илья Субботин
Очередной выпуск еженедельного обзора зарубежной аналитики в сфере мобильных технологий посвящен пусть и не ближайшим, но, по всей видимости, грядущим перспективам и изменениям в экосистеме Android. Некоторые из них имеют место уже сейчас, попробуем же ненадолго заглянуть в будущее. Добро пожаловать в «Беседку».
С момента выпуска версии 2.3.x (Gingerbread), Android стала главным игроком среди мобильных операционных систем. Скромный «зеленый робот» эволюционировал из небольшой нишевой ОС в мощную экосистему, неотвратимо набирающую силу. В течение всех этих лет разработчики добавили в неё множество полезных функций, таких как JIT и ART. За ближайшее время произошло несколько значимых для ОС событий, а также некоторые очень интересные детали стали появляться и, собственно, были замечены в исходном коде Android. Самое время подумать о будущем.
Начнем с упомянутого ART. Новая рабочая среда, призванная заменить Dalvik, вероятнее всего станет компилятором по умолчанию. Не вдаваясь в технические выкладки, стоит отметить, что это нововведение направлено на повышение производительности системы в целом, оптимизацию энергопотребления ядер, избавления интерфейса системы от лагов. Всё это реализуется путем перекомпиляции приложений из java в нативный для устройства код. Однако, за ART стоит гораздо больше, нежели просто продолжение Project Butter. Google отказывается от JIT+Dalvik в пользу ART еще и потому, что он может автоматически компилировать приложения под новую архитектуру, которая, впоследствии, станет стандартом для ОС и потребует сравнительно больших усилий от разработчиков.
Для тех, кто следит за изменениями в Github (онлайн репозиторий изменений в коде ОС), давно уже не новость, что в Android грядет переход на 64-битную архитектуру. Некоторые изменения в отдельных частях кода показывают, что в Google уже начат процесс трансформации ОС. Эти изменения были внесены сотрудниками компании, так что их можно с большой долей вероятности наградить «официальным» статусом. Такой шаг Google не должен никого удивлять, ведь Apple уже выпустили продукт с набором команд под ARMv8 64-bit. Модель iPhone 5S не полностью поддерживает 64-битную архитектуру, но у Google есть достаточно времени для внесения поправок в программную часть ОС, дабы обеспечить совместимость Android с новейшими ARM-процессорами. Intel уже заявила, что 64-битный Android уже этой весной сможет работать с линейкой процессоров Atom Bay Trail, выход которых запланирован. Однако устройства на процессорах Intel занимают сравнительно небольшую долю рынка, поэтому (для производителей) будет целесообразнее дождаться ARMv8 процессоров. Это случится не через месяц, и не через два, но первые такие процессоры должны увидеть свет во втором квартале текущего года.
Что принесет новая архитектура?
Нельзя сказать, что на данный момент 64-битная архитектура является жизненно необходимым компонентом для вашего смартфона, но аналогичный случай наблюдался при запуске первых процессоров Athlon 64 в 2003 году. Актуальная на тот момент Windows XP спокойно работала на 1 ГБ RAM, а то и меньше, и Athlon 64 стал успешен не столько благодаря своей «64-битности», а больше из-за возможности работы с 32-битным кодом.
Всё же, 64-битное «железо» может привнести некоторые изменения, которые будут иметь практическую значимость для пользователей. На поверхности «лежит» полная поддержка более 4 Гб RAM (ОЗУ), та планка, к которой Android-устройства смогут подобраться в последующие пару лет. Большинство топовых смартфонов сегодня поставляется с 2 Гб оперативной памяти, хотя более новые модели, такие как Galaxy Note 3, начинают подтягиваться к 3 Гб. Некоторые чипы уже частично поддерживают такой размер ОЗУ посредством режима ARM LPAE (Large Physical Address Extension), но для использования расширенной ОЗУ, приложения должны полностью поддерживать 64-битную архитектуру.
Многие из них не извлекут выгоды, да и не нуждаются в таком большом количестве оперативной памяти. Самые «увесистые» из Android-приложений занимают меньше 100 Мб ОЗУ. Память размером в 4 Гб сможет использоваться топовыми играми в будущем, но возможно этот прорыв будет сдерживаться рынком. Есть мнение, что производители должны, прежде всего, сосредоточиться на улучшении показателей времени работы аккумулятора, нежели на интеграции большего числа ядер, увеличении размера ОЗУ и т.п. и участие в этой «гонке характеристик».
Но это еще не всё, что изменится с «приходом» новой архитектуры. Второе значимое изменение заключается в том, что набор команд для ARMv8 существенно более эффективен, нежели заменяемый им ARMv7. Это изменение описал John Poole (Geekbench) в сентябрьском интервью с одним из зарубежных tech-ресурсов:
«ARM «почистили» архитектуру, они убрали из неё большой пласт хлама, наросший на ней за годы. Они пошли дальше и модифицировали её.. (опустил специфическую техническую часть, дабы не наделать глупых ошибок) .., тем самым, вы получаете большой прирост в производительности, в некоторых случаях – до 200%.»
По результатам benchmark-тестов, 64-битный код на процессоре Apple A7 способен обеспечить прирост в 33% по сравнению с работой 32-битного кода на том же процессоре. По мере того, как мобильные SoC начинают «натыкаться» на ограничивающие производительность термографические и энергетические пределы, такой прирост в производительности сложно оставить без внимания.
Возвращаясь к первым процессорам AMD64 (x86-64) для ПК, следует напомнить, что им понадобилось несколько лет, чтобы стать распространенными и привычными, стать «мэйнстримом». Не стоит ожидать отличного сценария для открытой экосистемы Android. На первых порах ARMv8 не будет лучше ARMv7. В своё время, рынок примет нового лидера, но первые устройства (c ARMv8) вовсе не обязательно будут разительно отличаться по производительности. Платформа всё еще нуждается в доработке и оптимизации, прежде, чем получит право называться стабильной.
Даже в экосистеме Apple, в которой уже несколько месяцев существуют «64-битные» устройства, большинство популярных приложений до сих пор работает на 32-битном коде. Это можно определить, подключив iPhone 5S к инструменту Xcode Activity Monitor и запустить несколько подобных приложений: даже сменившие «в угоду» iOS7 дизайн программы всё ещё «32-битные».
В ожидании «железа».
Итак, 64-битное аппаратное обеспечение от ARM добавляет значимую функциональность, хоть эти нововведения и не являются набором «must-have» на сегодняшний день. Должно пройти время, прежде, чем мы увидим 64-битные чипы ARM от кого-либо, кроме Apple.
Подобные чипы в небольшом количестве появятся на рынке во второй половине 2014 года, на которую намечен релиз продуктов на базе ARM Cortex A53 и A57. Однако, в топовых смартфонах и планшетах они не появятся вплоть до 2015 года, на данный момент из полностью поддерживающих новый стандарт известны лишь серверные решения Opteron от AMD и процессор для устройств средней ценовой категории Qualcomm Snapdragon 410.
С большой долей уверенности можно сказать, что первые флагманы Android с поддержкой 64-бит появятся в начале 2015 года, ведь топовый Qualcomm Snapdragon 805 по-прежнему не будет полностью поддерживать 64-битную архитектуру: он хоть и cможет обращаться к большему объему памяти, но в его основе по-прежнему лежит 32-битная архитектура Krait. Тем не менее, первое устройство на базе Snapdragon 805 выйдет на рынок в мае, девайсы на базе данного процессора станут одними из самых быстрых во 2 и 3 квартале текущего года.
(В свете появившихся слухов о начинке грядущего Samsung Galaxy S5 можно делать выводы о более скорой интеграции).
Выход нового продукта с поддержкой 64-бит от Nvidia, Tegra K1, ожидается во второй половине года, но, как показывает практика, чипам Nvidia непросто дотянуться до масштабов Qualcomm.
Считая эти прогнозы близкими к истине, можно полагать, что переход Android на 64-битную архитектуру начнется примерно к тому времени, как этот переход завершит Apple. Следует ожидать, что этот переход для ОС от Google будет происходить по тому же пути, что и аналогичный переход Windows десять лет назад:
- 2003 г. – AMD выпустила первые чипы с 64-битной архитектурой, они же поддерживали «32-битные» команды.
- 2006 г. – к выходу Intel Core 2 Duo большинство новых ПК и ноутбуков поставлялось с чипами, которые могли выполнять 64-битный код.
- 2009 г. – после выхода Windows 7 большинство новых ПК медленно, но верно стали поставляться по умолчанию с 64-битной Windows, нежели с 32-битной. (Microsoft все еще предлагает такую версию ОС, что, возможно, изменится с Windows 9)
Смартфоны и планшеты последуют этому пути, но в более сжатом временном аспекте. Мы можем ожидать первые чипы уже в этом году, первые Android-устройства в середине года и ближе к его концу, превращение «64-бит» в стандарт для топовых устройств — к концу 2015 – началу 2016 года. Внезапные анонсы могут сократить временные рамки, но пройдет еще немало времени, прежде чем такая архитектура станет нормой для Android.
«Железо» подразумевает «софт».
Аппаратное обеспечение с поддержкой 64-бит ничего не стоит без соответствующего программного обеспечения, и неторопливость разработчиков ARM даёт Google достаточно времени для внедрения поддержки 64-бит в Android и свои приложения. Есть отличная возможность вывести в 2015 году топовые смартфоны и планшеты, поддерживающие новый стандарт как на аппаратном, так и на программном уровне.
Даже подразумевая такой сценарий выхода устройств, присущая экосистеме Android фрагментация («софтовая» и аппаратная) означает, что новый стандарт должен будет набрать «критическую массу», что займёт определенное время. Как мы могли наблюдать на примере долгого пути от версий меньше 4.0 до более новых, разработчики приложений всегда придерживаются версий, которыми пользуется большинство пользователей. Даже сейчас, при поиске конкретного приложения в Google Play зачастую выдаётся приложение, чей дизайн больше похож на таковой в Gingerbread, а не на одну из пяти последующих версий.
Говоря о приложениях, нельзя не упомянуть третье возможное изменение в грядущих версиях Android. Всё в том же Github в коде, относящемся к функциональности «супер-пользователя» («SU») были замечены изменения, которые препятствуют обработке файлов из раздела /data, что в свою очередь может нарушить работу ряда программ, предназначенных для устройств с открытым root-доступом. Правда, пока неизвестно, будут ли эти изменения приняты, не обратят ли их разработчики, однако сам прецедент может заставить владельцев «рутованных» устройств задуматься. На данном этапе изменения не критичны, есть несколько обходных маневров, но налицо «изменение в силе».
Как мы видим, в последнее время в Android произошли некоторые перемены, и, несомненно, в ближайшее время стоит ожидать последующих изменений.
Elir: пока еще сложно говорить о точных датах, но будущее Android вырисовывается уже сейчас и примерный сценарий открывает новые горизонты как для пользователя, так и для производителей. На ваш взгляд, есть ли предпосылки для более быстрого перехода на 64-бит?
интересная статья.
Имхо, предпосылок для быстрого перехода на 64 бита нет, существующая производительность мобильных платформ пока достаточна для большинства пользователей и производителей.
основную роль в переходе должен сыграть гугл: если они смогут без потерь перевести приложения на 64-битную архитектуру, сохранив совместимость с 32-битной…
Хотя, устройства с поддержкой 64 бит будут появляться, но пока работать будут лишь на 32-х.
На пк переход тоже всё ещё продолжается, хотя там предпосылок больше.
До сих пор случаются эксцессы: так, выданный мне недавно на работе новый компьютер, i3 с 4 гб оперативки, оснащён предустановленной ос Windows 7 pro, но 32 -битной… Из-за этого я имею доступными 3.2 гб из четырёх… Да лучше бы они Home Basic поставили, но 64 бита. Отличились…
В мобильной сфере переход имеет все шансы быть более быстрым, но для этого важно сочетание воли производителя ос (гугл) и производителей устройств (в т.ч. и самих процессоров), а так же конечной стоимости таких решений. Не исключён вариант, когда 64 бита станут прерогативой только топовых устройств, средний и нижний сегменты будут сидеть на 32-х, что только усилит фрагментацию и поставит всех в трудное положение.
А ещё нужно учитывать, что быстрое развитие технологий сделает более актуальным что-либо другое, что потребуется реализовать (какие-нибудь сети 5g, распознавание голоса на аппаратном уровне или что-то подобное), что ещё больше усложнит ситуацию (ведь, как мы знаем, быстрые технические изменения легче вносить в более старую и проверенную платформу, чем в новую и неопробованную).
Поживём, увидим.
>> Имхо, предпосылок для быстрого перехода на 64 бита нет, существующая производительность мобильных платформ пока достаточна для большинства пользователей и производителей.
Перевод на 64 бита НЕ может повысить производительность (кроме некоторых очень специальных задач). Обычно производительность понижается на ~5-10%.
Поэтому о повышении производительности в новых процессорах можно говорить только за счет смены архитектуры (набора команд). Это несколько утрированно, но общий смысл именно такой.
>Перевод на 64 бита НЕ может повысить производительность<
Ну это если рассматривать исключительно битность, стойко игнорируя сопутствующие изменение что не есть верно.
Те же увеличенные размерыкол-во (у эпла во всяком случае) регистров — довольно хорошо для производительности в т.ч. и 32-bit приложений.
Нет. Это я вам говорю, как программист, заставший 2 смены разрядности на PC. У Apple играет только архитектура (преимущество ARM v8 над ARM v7).
>У Apple играет только архитектура (преимущество ARM v8 над ARM v7).<
Но регистры то как раз и относятся к архитектуре.
А что за язык, на котором пишете, если не секрет? (просто любопытствую)
Простое использование EAX вместо AX никогда не давало прироста. На i386 и AX был быстр. Вот когда для задачи не хватало разрядности — это да, переход давал прибавку. Но таких задач было меньше.
Первый переход я застал на C и ассемблере, второй — на Delphi.
Аааа, я говорил не про замену одних регистров другими, а про увеличение их кол-ва (конкретно: общего назначения и для чисел с плавающей точкой).
выданный мне недавно на работе новый компьютер, i3 с 4 гб оперативки, оснащён предустановленной ос Windows 7 pro, но 32 -битной… Из-за этого я имею доступными 3.2 гб из четырёх…
_____
Как системный администратор могу обосновать: Обычно компы заливаются из одного образа для всех. Это позволяет держать одинаковую конфигурацию ПО везде и это очень полезно при автоматизации каких либо задач. Также не очень свежие устройства могут не иметь 64 бит драйвера (к примеру принтеры или МФУ). К тому же 64 битная ОС будет есть больше памяти. Так что до 4Гб ОЗУ нет необходимости в 64 битной ОС.
Ну да, компы заливаются из одного образа. Но, все компы этой новой партии абсолютно одинаковые и только на них стоит семёрка и только на них 4 гб, на старых по-прежнему стоит xp и никто её не собирается менять (ибо там есть и весьма слабые машины)
Мда, сразу видно автор слабо разбирается в теме и начитавшись «зарубежных tech-ресурсов» не все понял. Особенно повеселило описание github и конечно пассаж про ART, который оказывается нужен Google что бы «автоматически компилировать приложения под новую архитектуру, которая, впоследствии, станет стандартом для ОС и потребует сравнительно больших усилий от разработчиков».
Так же автор видимо не понимает, что 90% всех приложение (не считая игр) глубоко пофиг на архитектуру, т.к. они не привязаны к процессоры и архитектуре и пишутся через Android SDK, без применения NDK.
Диванная аналитика во всей красе
Начнем с того, что автор-не аналитик, а скорее переводчик, не претендующий на лавры эксперта. Попытался передать суть статьи, не получилось-приношу извинения.
Просто в оригинальной статье все написано верно, может стоило ее перевести, не пытаясь додумать?
Спасибо за замечания. Впредь буду избегать узкоспециализированных текстов.
Подсказали бы лучше как поправить. А то диванная критика во всей красе.
Github (онлайн репозиторий изменений в коде ОС)
—
Это не репозиторий изменений в коде ОС, а сервис предоставляющий хостинг проектов на основе системы контроля версий Git. В оригинальной статье даже не упоминается, а просто есть ссылка на копию репозитория с исходным кодом Android, т.к. там более привычный интерфейс для большинства разработчиков, чем у оригинального Гугловского https://android.googlesource.com/ . А по фразе может показаться что Github имеет какое то отношение к Android
Дак вы это переводчику, а не мне то объясняйте, дабы он мог поправить текст как надо.
Вам пишу так как вы возмутились диванной критике
Я всего лишь указал на более рациональный путь, пусть и с чуточкой сарказма, без какого либо требования к отчётности.
Теперь что касается ART. Весь абзац — прям трудности перевода, попутно вводя в заблуждение читателя.
«Начнем с упомянутого ART. Новая рабочая среда, призванная заменить Dalvik, вероятнее всего станет компилятором по умолчанию.»
Нет такого термина «рабочая среда», а по-русски runtime это «среда выполнения».
Ни ART, ни тем более Dalvik не являются компиляторами. Dalvik — виртуальная машина, интерпритирующая код, а ART который хоть и занимается прекомпиляцией кода виртуальной машины в нативный не является компилятором, т.к. не компилирует исходный код в машинный, а преобразует инструкции виртуальной машины в машинные.
«Всё это реализуется путем перекомпиляции приложений из java в нативный для устройства код.»
Нет никакой перекомпиляции из Java, а есть пре-компиляция dex файлов, которые являются инструкциями виртуальной машины. К языку программирования Java напрямую они уже никак не относятся.
«Google отказывается от JIT+Dalvik в пользу ART еще и потому, что он может автоматически компилировать приложения под новую архитектуру, которая, впоследствии, станет стандартом для ОС и потребует сравнительно больших усилий от разработчиков.»
Этот параграф совсем не понятно что хотел пересказать переводчик. Какая авторматическая компиляция под новую архитектуру? Какой новый стандарт? и самое непонятно что за большие усилия от разработчиков потребуются, учитывая что все программы, не используеющие NDK и не проводящие манипулция со своим Dex кодом и так уже запускаются на ART.
Скорее бы для андройд сделали GTA 5. Начало уже положено — https://goo.gl/GRX9RS игра онлайн. Осталось дождаться чего то на андройде.
Докатились, уже на android.m-r спам появился