`

СПЕЦИАЛЬНЫЕ
ПАРТНЕРЫ
ПРОЕКТА

Архив номеров

Как изменилось финансирование ИТ-направления в вашей организации?

Best CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Андрей Зубинский

Тихая революция в Android, сплошной позитив и даже благодарности

+2022
голоса

Версия Android 4.4, мило названная для уха украинца (котик-палач, Kit-Kat) ещё вроде как не добралась до наших широт стандартными механизмами обновлений Google, но я не удержался и буквально в первый день появления полной заводской "прошивки" обновил Nexus 7 "с чистого листа", очень уж хотелось посмотреть и попробовать кой-какие спрятанные от пользователя вещи. Потому как тихо-тихо, а разработчики Google готовят весьма серьёзные системные изменения, и вынуждены делать это фактически в тех же условиях, в которых сравнительно медленно развивалось системное ПО "пользовательского класса", вот только сроки теперь совершенно несопоставимые, они сжаты до предела, что превращает историю развития Android в крайне интересное действо, мы как будто смотрим всё то же самое, только на ускоренной перемотке. И тут надо бы кое-что  объяснить даже самому себе.

Давайте попробуем вспомнить за сколько лет потребительский персональный компьютер доводился промышленностью до уровня массово доступной многопроцессорной машины с тактовой частотой процессорных ядер в диапазоне от 1 GHz до 2 GHz и с объёмами памяти порядка нескольких гигабайтов?

Всё началось в августе 1981 года, когда был запущен первый IBM PC, с забавным процессором i8088 (восьмибитовым "снаружи", 16-битовым внутри, микросхемы тогда были дорогим удовольствием, производство печатных плат - тоже, и в IBM и приняли правильное архитектурное решение для снижения цены массового производства) с тактовой частотой чуть большей 4MHz. В 1984 году появился i80286, не сделавший погоды в смысле архитектуры, но ставший лет на 10 "рабочей лошадкой", ввозившей то, что мы сегодня называем Wintel, в явление планетарного масштаба. Через год, в 1985ом, в Intel создали 80386, первый полноценный 32-битовый процессор, но первые потребительского класса машины с ним появились почти через год, в 1986-ом. До первой половины 1990-х ничего существенного не происходило (появился последний промежуточный i486), и вот в 1993 году в Intel довели до потребительской пригодности первый Pentium c тактовой частотой 66 MHz. И так оно тянулось до 1999 года, когда первый коммерческий Intel Pentium III Coppermine взял планку тактовой частоты 1 GHz. До массовой доступности таких по тем временам рекордсменов было ещё далеко, и опять наступило затишье, до 2005 года, когда сразу и AMD, и Intel выдали на рынок коммерческие двухъядерные процессоры. То есть, где-то к 2006 году в мире "немобильных потребительских вычислений" за 25 лет наступил период "доступных гигагерц и многопроцессорности". Доступные гигабайты памяти "подтянулись" чуть позже, добавим ещё годик-два для убедительности. Итого, вся история длилась примерно лет 27, а то и все 30.

А теперь давайте посмотрим, что происходит в ARM-центрическом мире. И увидим, что, по сути, происходит всё то же самое, только в крайне сжатые сроки. Примерно раз в шесть. Системы на чипе, лежащие в основе всякого мобильного, за это время буквально прыгнули в многоядерность и надгигагерцевые тактовые частоты.

С одной стороны, такая скорость развития позволила какое-то время вообще не говорить о системном ПО, и его развитие было больше "потребительским причёсыванием", быстрое появление доступных более мощных вычислителей компенсировало многое на невидимом потребителю системном уровне. И тут случилось нечто. ARM-мир, кажется, достиг точки насыщения, примерно той же, которой в своё время достиг мир x86, уткнувшись в Pentium IV. Типовая 4-ядерная система на чипе, часто - с дополнительным пятым вычислительным ядром DSP (цифрового сигнального процессора) и с тактовой частотой порядка 1,5 GHz. Это норма сегодняшнего дня, и... и прыжков никаких явно не ожидается. Увеличение числа ядер особой погоды явно не сделает (потому и никому особо не нужно, разве что для маркетинговых штучек), тактовую частоту особо не поднять, потому что всё мобильное - с батарейным питанием, а источники питания развиваются по своим законам и очень-очень медленно. И, кажется, наступает переломный момент, когда пора всерьёз браться за системное ПО. Как на это явное реагируют разработчики Apple - то неизвестно, но, судя по степенному развитию iOS от версии к версии в основном на пользовательском уровне, вполне может быть, что или никак вообще, или готовят что-то очень секретное, чтобы не спугнуть восторженную публику, все восторженные очень пугливые. Потому даже слухов не бродит. Разработчики Google тоже не особо афишируют системные изменения, но и тайны из них не делают. Что уже не может не радовать.

И на пути системных изменений Android 4.4 Kit-Kat, кажется, является первым серьёзным шагом. Потому что в этой версии системы впервые "подтянута" до актуального уровня совместимость основного технологического инструмента - Java, - до актуального состояния "большой Java", то есть, до совместимости с Java 7, и впервые мало что введена в состав пользовательской ОС "новая" версия Java-машины, но и дана возможность её использовать. Часть Java 7 совместимости мы отбросим (программисты разберутся сами), а вот что касается потенциального заменителя машины Dalvik, - это уже очень интересно. И даже в каком-то смысле показательно. Не так часто мы можем "подсмотреть" что-то красивое и одновременно более-менее понятное даже неспециалистам, что происходит на системном уровне привычного повседневного ПО. 

Итак, в своё время создатели ОС Android приняли исключительно смелое, даже дерзкое, решение. Логика, подчинённая сиюминутности, как бы убеждала, что на основе ОС Linux и моря кода пользовательского уровня для неё можно быстро "слепить" пользовательскую систему и - profit! По этому пути пытались (и пытаются) идти уже не одна компания самых разных масштабов, и где этот поезд до сих пор, мы все знаем без лишних слов. Кто мог поверить, что полная виртуализация пользовательского уровня для систем ограниченной производительности с батарейным питанием, ещё и разделяемым с "прожорливыми" по своей сути каналами беспроводной связи, окажется стратегически правильным решением? Мало кто. А практика показала, что всё было правильно. И даже оказалось ещё правильнее, потому что в том числе и являющийся основой системы нетрадиционный для Java регистровый (а не стековый) интерпретатор и JIT-компилятор Dalvik обеспечил Android то положение, которое система занимает сейчас. Да, нервные граждане бились и будут биться в истериках, высматривая в Android дефекты "плавности прокрутки" и прочих "блошек", пользователям же как бы это безразлично. Система делает что должна делать, приложения для неё есть, и они хороши - всё. Остальное - продукт "оттачивания" и "вылизывания", и этого неизбежно добиваются независимо от системной архитектуры. Вот только не я один вижу, что в ARM-мире наступает затишье, былых скоростей развития уже не будет, и на экстенсивный рост показателей "железа" уже рассчитывать нельзя. И вот в этот переломный момент как раз и можно оценить красоту изначально заложенного в Android "нелогичного" архитектурного решения.

Kit-Kat предлагает пока в "скрытом" от пользователей меню разработчика выбор между двумя вариантами ключевого системного компонента - виртуальной машины Java, которой и "крутится" весь пользовательский уровень. К привычной невидимой Dalvik теперь добавился ART - Android RunTime. И это уже не виртуальная машина с JIT. Это "компилятор перед исполнением", ahead-on-time, полностью исключающий возможность сосуществования во время исполнения программ промежуточного байт-кода виртуальной машины и "родного" кода платформы, что характерно для JIT-систем (в них исполняется и то, и другое). ART транслирует приложения в машинный код физического вычислителя фактически при их инсталляции. И делает это один раз за всё время жизненного цикла  приложения на конкретном вычислителе. Дальше, после трансляции, приложение существует в бинарном виде и представлено "родной" системой команд конкретного целевого процессора.

У появления и начала становления ART в Android есть несколько косвенных особенностей. Во-первых, что очевидно, исполнение полноценного бинарного приложения всегда быстрее, чем виртуализированного. Во-вторых, ускорение не бывает "за  бесплатно", и полноценный машинный код не менее очевидно занимает больший объём, чем компактное его промежуточное представление для высокоуровневого виртуального вычислителя. То есть, это стратегическая игра. С одной стороны, всё будет быстрее, с другой - на это "быстрее" потребуется одновременно больше долговременной памяти, но на фоне снижения требований к объёмам оперативной памяти. Последнее не менее очевидно, чем и всё предыдущее - виртуализация неизбежно увеличивает требования к объёму оперативной памяти. Забавная стратегическая игра получается, особенно при учёте требований рынка, постоянно снижающих верхнее положение ценовой планки, выше которой готовы прыгать только совсем уж "восторженные поклонники гаджетов", популяция которых почему-то не растёт. А снижение верхней планки цены никак не может не сказаться на технических требованиях к устройствам. Но, если подумать, в этой стратегической игре ART формирует весьма привлекательный путь. Увеличение объёмов машинного кода трудно назвать "взрывным" (максимум на 30% по сравнению с кодом виртуальной машины), что при стоимости  флеш-памяти и реальной переоцененной востребованности её больших объёмов (а вот это реально - мало кто "забивает под завязку" свои телефоны и планшеты, разве что совсем уж странные личности) погоды не делает. А вот уменьшенный расход оперативной  памяти при увеличении скорости исполнения кода - это очень хорошо. Потому что выгодно всем. И производителям, и потребителям.

Я попробовал ART "на себе". Следует сразу предупредить любителей побегать перед паровозом - не спешите. ART пока находится в стадии "опытной эксплуатации", так что всяких "весёлостей" вам будет, не сомневайтесь. Но, между тем, даже такие монстроидальные по меркам Android приложения, как клиент Google+, довольно приемлемы в своих ART-версиях (куда хуже обстоит дело со всякими вычурными системными утилитами) и действительно очень быстрые. Ну и самое существенное "но" - если в режим ART переводить устройство, "напичканное" прикладными программами, вынужденная "компиляция всего" будет долгой. Такие существенные изменения системного уровня безболезненными не бывают. В обычном режиме установки приложений ART особо не проявляется, ну да, большие программы устанавливаются дольше, чем привычно, но это совершенно не смертельно. А компиляция - процесс хорошо изученный и, думаю, в Google разработчики знают своё дело, так что скорость ahead-on-time компиляции неизбежно будет доведена до почти теоретического предела.

Ну и, пожалуй, самое важное в ART с точки зрения пользователя мобильного терминала - снижение энергопотребления. "Родной" код после оптимизирующего компилятора (а ART им и является, причём уровень оптимизации в нём довольно высок) однозначно снижает энергопотребление. И это действительно заметно. В моём опыте эксплуатации планшета в течение суток с лишним трудно оценить реальный выигрыш, но по моим оценкам ART "подарила" где-то час дополнительного времени. А это цифра.

У системных изменений Android есть ещё одна, совершенно латентная, сторона. Об этом пока никто ничего не говорил. А зря. И очень жаль. Если считать ОС Android одной из представительниц неисчислимых дистрибутивов Linux (что возможно в той же мере, в какой возможно так не считать), ART показывает ещё один путь развития дистрибьюции ПО, который Linux-миру опять не доступен. Распространение ПО (хоть бы open source) в промежуточном представлении, с локальной "докомпиляцией" пользователями - это теперь, оказывается, ещё один способ, и он фактически "обкатывается" таким гигантом дистрибьюции ПО, как Google. Это очень интересная "система", с подобными мы ещё не сталкивались. Если добавить к ней новые модные и крайне разумные "контейнерные" способы поставки ПО (а они набирают популярность из-за необходимости развёртывания, например, ПО датацентров), получаем феномен. "Докомпиляция" одновременно расширяет кросс-платформенность и снижает сложность необходимых "докомпиляторов" (извините за выдумывание новояза на ходу, надеюсь, он понятен) - всё-таки, байт-код виртуальной машины много проще синтаксически и чище семантически, чем высокоуровневый язык программирования, следовательно, можно меньшей кровью разработчиков системного ПО добиться лучшего качества скомпилированного кода. "Контейнерная" поставка ПО или вообще поставка самодостаточного ПО (пример - языковая среда Go из мира той же Google) значительно снижает сложность отслеживания зависимостей или вообще исключает "ад динамических библиотек" (dll hell), потому что никаких динамических библиотек может вообще не быть, и программы поставляются в завершенном, пригодном к исполнению без зависимостей, виде.

Так что, если говорить о процедурах, которые принято называть software deployment, мы, кажется, становимся свидетелями маленькой такой тихой революции. Которая на деле исключительно значима. До появления централизованных "рынков программ" и "товарного изобилия" на них, эта область не была слишком уж значимой и потому никаких взрывных событий в ней и не ожидалось. И модель Google по небольшому рассуждению кажется очень привлекательной - хотя бы потому, что она не требует необходимости поддержания нескольких бинарных представлений, для каждой целевой платформы - своих. И такая модель сейчас возможна только для Google, изначально грамотно выбравшей "неправильную" архитектуру пользовательской ОС. Так что Android-мир всерьёз готовится главным идеологом системы к совершенствованию кросс-платформенности, которая в нём и так присутствует - как минимум ARM, x86 и MIPS.

Что же касается Kit-Kat на пользовательском уровне... Для чистоты эксперимента я дополнил систему "родной" пользовательской оболочкой (лончером), которая пока официально доступна только владельцам смартфонов Nexus 5.

Из заметных и радующих изменений могу сразу сказать о штатной утилите Downloads, которая раньше была единственным  файл-ориентированным штатным средством системы. И наконец она стала практически тем, чем должна быть - почти файл-менеджером, с возможностью выбора удобного режима просмотра загруженных файлов, в том числе и большими пиктограммами (тамбнейлами). Также существенно улучшилась штатная клавиатура. Настолько, что кроме необходимой для удобной работы в удалённом терминальном режиме Hackers Keyboard, мне сторонних клавиатур не понадобилось. И мгновенно переключаться между языками ввода наконец стало удобно. Ну и, конечно, очень приятным стал штатный редактор фотографий. И пользоваться им удобно, и теперь он, как "взрослые" пакеты обработки гарантирует неизменность оригинала.

Это так, навскидку. В остальном Kit-Kat никаких взрывов на пользовательском уровне не творит (разве что кому-то революция и прозрачный status-bar, доступный пока только в "родном" лончере и в бета-версии альтернативной Nova Louncher). Радует, что злополучная (но замеченная не так чтобы многими) ошибка системного буфера  обмена (Issue 58043) устранена.

Незначительным косметическим изменениям в системе я вообще не уделю внимания, и вместо многословного описания окрасивленных иконок и большей визуальной целостности интерфейса скажу вот что куда более интересное. При каждом обновлении Android я предпочитаю установку "с нуля", то есть, после полного "заводского сброса" и из заводского же полного "образа" системы. Предварительно, естественно, сохраняю список установленных ранее программ утилитой My App List, позволяющей отправить самому себе электронной почтой перечень установленного, ещё и со ссылками на Google Play, чтобы потом не мучить себя воспоминаниями. И списки программ перед каждым обновлением системы у меня хранятся в почте. Вчера я решил на них посмотреть, на все эти "накопления". И вот что получилось в итоге - с каждым обновлением системы (а эта история длится с Android 2.3, по-моему) я использую всё меньше сторонних программ. Я не игроман, больше того, антиигроман (ну скучно мне, я не виноват). Что же касается прикладных программ, то картина складывается точно такая же, какая наблюдалась с развитием ОС Windows после достижения ею пристойного уровня (это Windows 2000, конечно же) - с каждой новой версией ОС потребность в десятках всяких мелких утилит, устраняющих те или иные недостатки системы, непрерывно снижалась. Только в  Android-мире всё это происходит очень быстро. И очень заметно - чуть ли не каждый значимый релиз системы делает лишними какие-то утилиты, ранее бывшие не то, чтобы необходимыми, но полезными. Это может означать что угодно (потому что это очень субъективно, я не пытаюсь говорить за всю "Android публику"), в том числе и то, что система незаметно активно совершенствуется. Что я лично, как потребитель, категорически приветствую.

Вместо завершения хочу сделать реверанс нашим киевским разработчикам из Obreey Products. И сказать спасибо за PocketBook Reader. Наконец-то в деле построения "читалок" видно движение в направлении здравого смысла. Особенно в понимании и поддержке очевидного - при чтении с быстрого планшета хорошо видимая (то есть, сравнительно большая, чтобы можно было прочитать название) обложка книги куда информативнее, чем страшная и не очень понятная пользователю "метаинформация", в которой ещё и надо копошиться. PocketBook Reader - первая на моей памяти "читалка", в которой обложки книг после сканирования файловой системы наконец-то отображаются в "журнальном стиле", а не микроскопическими иконками с именами файлов. Казалось бы, такая мелочь. А наколько с ней приятнее, особенно если таскаешь с собой библиотеку в несколько сотен книг. И очень приятно, что разработчики читают форумы, где им пишут пользователи, и реагируют. Так что молодцы, спасибо им.

Откланиваюсь, извините, что не мучил вас снимками экранов, их без меня наснимали полный интернет.

+2022
голоса

Напечатать Отправить другу

Читайте также

На мобильном устройстве, питающемся от батарей, правильно всю работу, которую можно сделать за рамками устройства, сделать именно за рамками. Чтобы не тратить на это драгоценный заряд.

В этом смысле использование Java - вещь не эффективная. И в Google идут путем постепенного перевода все на машинный код. Было бы эффективнее сразу загружать на устройство скомпилированный машинный код.

Учитывая, что 99% кода грузится из Google Play, легко можно было бы реализовать компиляцию по загрузке еще на серверах Google и кэшировать ее там для разных архитектур.

когда речь идёт о масштабах инфраструктуры Google и звучит слово "легко" - ...

когда Андроид проберется на рс и ноутбуки? по моему пора уже

зачем?
это же система, доведенная до "однорукого" специфического использования. она на своём месте.

вот другой есть вопрос, например. когда появится дистрибутив Linux, столь же качественный, как Android?
одновременно лёгкий, "чистый", удобный в использовании, без монстроидальных пользовательских оболочек, без дикого бардака с версиями библиотек, относительно простой в сопровождении, с человеческим администрированием, без непредсказуемых всплесков в развитии, без системного уровня сервисов, пытающихся "реализовать всё", без бантиков и рюшиков, существующих сугубо из принципа "ну потому что это возможно".
но этот вопрос задавать в 2013 году как-то и неудобно.

Не стесняйтесь, 2014г. на носу.
И я об этом. Не хватает свежей оптимальной, лаконичной, операционки для РС сделанной "с нуля" трезвым взглядом. В Линуксе бардак, Мак другая платформа, Уиндовс уже чистый гротеск, порядком поднадоел своей вечной недоделанностью и неспособностью слушать пользователя. Что сметет всю эту паутину и нагромождения. Аппаратная часть давно созрела.

>>> В Линуксе бардак,
Да, может, и напилят через некоторое время что-то логичное. Естественный отбор покажет...
http://blogs.gnome.org/alexl/2011/09/30/rethinking-the-linux-distibution...
http://nixos.org
http://chakra-project.org/bundles.html

>>> Мак другая платформа
А что там нелогично и нетрезво?

P.S. Забыли разгромить BSD, Haiku и колибри )))

nixos и прочее - да, это наконец-то разумное, но оно пока играет роль костылей, потому что исключительно лечит унаследованную увечность.

прятать в контейнеры ад autotools и свистопляску с различием версий библиотек, нужных разным приложениям - симптоматическое лекарство, увы.

но лучше уж с симптоматическим лечением, чем без какого-либо вообще.

ах, да, "она будет в следующем году".

это уже мем.
лет так надцать как.

Так уже пробираеться...

И, кажется, наступает переломный момент, когда пора всерьёз браться за системное ПО. Как на это явное реагируют разработчики Apple - ..... вполне может быть, что или никак вообще

А нужно ли?
-----

И это уже не виртуальная машина с JIT

В iOS это изначально native code. Плюс, mach-O позволяет засунуть в один бинарник символы для всех необходимых архитектур, обеспечивая тем самым переносимость.
-----

или вообще исключает "ад динамических библиотек" (dll hell), потому что никаких динамических библиотек может вообще не быть, и программы поставляются в завершенном, пригодном к исполнению без зависимостей, виде.

Аналогично : application bundle автономен и без зависимостей.
-----

P.S. Спасибо большое за статью. Здорово, что перечисленные features, наконец, появились и в android.

даже затрудняюсь что-то ответить
но было смешно
и вам спасибо

а что смешного-то?

Андрей, уточните, пожалуйста, на какой версии 7-го Нексуса вы активировали АРТ? В первой версии (2012) переключатель runtime'ов, судя по всему, отсутствует, также, как и в 10-м Нексусе.

Разве первым представленным процом на 1Ггц был не Атлон от АМД?

Разве первым представленным процом на 1Ггц был не Атлон от АМД?

"Это не важно." (С) ;-)

>>i80286, не сделавший погоды в смысле архитектуры

rly?

первый x86 процессор, в котором был реализован «защищённый режим»

*ahead OF time, for the love of god

Я, возможно, с чем-то путаю, но ведь и до ART что-то при установке приложения компилировалось (Optimized DEX в Dalvik cache)? Если этот кеш почистить - при следующем запуске приходится довольно долго любоваться счетчиком "обработки" (что бы там ни происходило) приложений. Что же это тогда такое?

Замедление прогресса у "больших" и наращивание у "маленьких", на мой взгляд, объясним: квантовый предел для кремния никто не отменял. Большие ищут способы прорыва дальше, а "в это время в замке у шЭфа..." :) использовать наработанные полупроводниковые технологии производства чипов для быстрого развития ARM вполне логично. Думаю, что и это и есть причина очень быстрой эволюции маленьких, по сравнению с большими.

И присоединюсь к вопросу заданному выше - как увидеть, что ART активирован?

 
 
IDC
Реклама

  •  Home  •  Рынок  •  ИТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Сети  •  Безопасность  •  Наука  •  IoT