0,0
рейтинг
8 ноября 2013 в 10:59

Разработка → ART идет на смену Dalvik

Хочу поделиться интересной новостью про новую функцию, появившуюся в Android 4.4, о которой на презентации и в появившихся после обзорах не было сказано — о новой среде выполнения приложений на мобильной ОС — ART, которая приходит на смену почтенному Dalvik. Потенциально это может сильно повысить производительность приложений, без необходимости в их перекомпиляции. Из минусов — большее время установки, больший занимаемый размер, возможно неработоспособность некоторых функций. Цель поста — донести до уважаемого сообщества доступные сведения и узнать про технологии больше.




Пока удалось найти такую информацию на сайте Youhtc.ru
"
Последние несколько лет важной частью работы создателей Android стала борьба с главной врожденной «болезнью» системы — лагами в анимации интерфейса. Первым серьезным шагом в эту сторону стал Project Butter, анонсированный вместе с Android 4.1 Jelly Bean и действительно «ускоривший» систему, но не решивший проблему в корне. В Google это осознают, поэтому готовят ART — замену виртуальной машине Dalvik.

Даже сейчас, в век многоядерных производительных процессоров, при определенном стечении обстоятельств можно заметить, что анимация в Android отрисовывается не идеально, а между некоторыми действиями есть видимые заминки. Проблема комплексная, потому для ее решения нужно было предпринять много шагов — в качестве одного из них решили сменить Dalvik на прекомпилятор ART.

Сейчас Android-код выполняется в Java-машине, созданной Google специально для мобильных устройств, при этом он «на ходу» преобразуется в аппаратный (Just-In-Time Compilation). Такой механизм позволяет разработчику приложения практически не привязываться к конкретной архитектуре или «железу», но наносит серьезный урон производительности, нагружая процессор во время компиляции. Конечно, после первого самого «тормозного» запуска программы часть полученного «нативного» кода сохраняется в кеше, однако полностью проблему лагов это не решает.

ART же представляет из себя AOT-компилятор (Ahead-Of-Time), который преобразует Java-код в «нативный» в процессе установки приложения. То есть пользователь запускает программу уже скомпилированной, что существенно ускоряет ее открытие и выполнение. Вдвойне интересно, что ART уже встроен в Android 4.4 KitKat и активировать его можно в меню разработчика. После переключения на libart.so (библиотека компилятора) устройство перезагружается и компилирует все уже установленные приложения. Ребята из Android Police, внимательно изучившие ART, утверждают, что на кастомных прошивках из AOSP этого делать пока не стоит — могут возникнуть проблемы с пакетом программ от Google.

Даже учитывая неокончательное состояние ART, переход на него существенно влияет на скорость выполнения ресурсоемких задач и плавность работы интерфейса, а также позволяет многоядерным процессорам чаще отключать неиспользуемые ядра, что дает выигрыш во времени автономной работы устройства. Существуют у новой системы компиляции минусы, хотя их сложно назвать значительными: более продолжительное время установки и увеличение финального размера программы на 10-20%. Правда, растет размер лишь кодовой части, которая часто занимает менее половины приложения — мультимедиа (картинки, звук, видео) и другие данные своего размера не меняют.

Оказывается, Google уже не первый год работают над ART и включение его в KitKat — абсолютно обдуманное решение, позволяющее создателям системы провести серьезное тестирование, а разработчикам приложений — подготовиться к грядущему «уходу» Dalvik. Пока не ясно, насколько на новый компилятор повлияли разработчики из FlexyCore, которых Google купили в октябре текущего года, но начинался проект внутри самого поискового гиганта.

В Google пока не говорят, как скоро ART заменит Dalvik, однако ничего не мешает корпорации сделать это уже в следующей версии системы. Интересно, что как и Project Butter, компилятор не требует трудозатрат от разработчиков приложений — они все так же будут писать код на хорошо знакомом языке, используя отработанные практики.
"

У меня нет устройства на Android 4.4 чтобы самому попробовать новую технологию, но уже доступен образ системы от Google, который можно «пощупать» в эмуляторе.

У меня остаются вопросы, будет ли эта функция доступна на других устройствах с Android 4.4 не от Google: Samsung, HTC и т.д. Все ли функции приложения будут корректно работать после перевода на новую платформу?

Информации крайне мало, пишите, пожалуйста, в комментариях, где ее можно почерпнуть в бОльшем размере.
Мирошниченко Михаил @HeavyRazzer
карма
16,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (108)

  • +1
    Интересно, будет ли это чистый Ahead-Of-Time или таки горячие места будут перекомпилироваться с использованием доступной только в рантайме информации.
    • +1
      Это принципиально не может быть чистый AOT. Как известно, Java поддерживает рефлексию. Причем многие фреймворки (например, Spring) не только ее активно используют для получения метаданных, но и занимаются кодогенерацией на JVM.

      Единственное, что может позволить себе виртуальная машина — это сгенерировать код для классов, входящик в APK. Если выкинуть кодогенерацию JIT совсем, это поломает Java.
      • 0
        Очень сомневаюсь, что кто-то генерирует код на андроиде.
        • –3
          Зря сомневаетесь. Я не зря привёл в пример Spring. Он очень популярен.
          projects.spring.io/spring-android/
          • +2
            Поправьте меня, пожалуйста, если я не прав. Но кодогенерация на Android не используется. Причина: все тот же Dalvik. Дело в том, что Java Byte Code уже перелопачен в Dalvik Code в момент, когда приложение работает. Там есть JIT из Dalvik в native, но никакой кодогенерации Java Byte Code нет. Я где-то читал, что именно это было поначалу причиной отсутствия поддержки Groovy на Android. Там есть Dexmaker — но это не совсем Dalvik или его неотъемлемая часть…

            Сам по себе Reflection не подразумевает наличие генерации Java Byte Code и это тема вообще независимая. Reflection очень даже возможен и на AOT и вообще на C++ (Qt со своим moc это доказали).

            Тот факт, что Spring есть под Android не подразумевает, что там есть генерация кода по умолчанию. В конце концов это не совсем тот Spring — артифакты для обычной Java и Android сильно разные.
            • 0
              Тогда, наверное, вы правы. Я про перекомпиляцию в dex, честно говоря, позабыл. Тогда действительно всё в порядке.
  • 0
    У Гугла все же есть небольшая информация:
    source.android.com/devices/tech/dalvik/art.html
    Доступность этой опции будет на совести производителя устройства. Сейчас это экспериментальная функция: требуется на этапе сборки ПО для устройства указать, какой runtime включить в прошивку — только Далвик или оба.
  • +2
    Если вы, вдруг, как я, поставили ранний образ Android 4..4 от Nexus 5 на свой Nexus 4, то не стоит переключать далвик на арт.
    Крашатся все гуглапс.
    • 0
      Вот тут прошивка есть рабочая, что бы посмотреть на art.
      forum.xda-developers.com/showthread.php?t=2508185
      • 0
        Я уже решил ОТА/Factory Images дождаться, там и посмотрим.
        • 0
          Я себе позавчера поставил вот этот порт с пятого. Понадобилось долить библиотеки для хрома из этого же поста.
          Провёл конвертацию в ART, заняло полчаса примерно. Переживал, что телефон перегреется и вырубится — такой он был горячий.

          Полёт совершенно нормальный, не считая того что перестал запускаться Whatsapp.

          Работает как минимум так же быстро, как Pure Speed Experiment для v4.3.
          Не могу пока сказать с уверенностью, что батарею жрёт меньше, но в общем верю, потому что всё действительно стало очень плавно и быстро работать.
  • +4
    Хорошая новость, как для пользователей, так и для разработчиков.
    Из минусов — большее время установки, больший занимаемый размер, возможно неработоспособность некоторых функций.
    Установка один раз происходит (ну, обновления ещё иногда), так что, не критично. Увеличение размера тоже не критично, учитывая, что это не касается медиа ресурсов.

    Интересно больше узнать о «неработоспособности некоторых функций».
    • 0
      Возможно, кстати, они-таки отпилили весь JIT и возможности динамической кодогенерации в приложениях сломаны.

      В этом случае рискну предсказать, что в итоге две системы подружатся — просто ART будет компилить заранее всё, что сможет, а Dalvik будет включаться в дело когда без динамической компиляции не обойтись.
  • +1
    Шикарная новость! Надеюсь, в следующей версии уже будет изкоробки, и к тому моменту не забьют хотя бы на Nexus 4, а то не хочется его менять совсем. Это ведь по сути одним махом излечит Android от всех основных недостатков! Скорее бы :)
    • НЛО прилетело и опубликовало эту надпись здесь
      • НЛО прилетело и опубликовало эту надпись здесь
  • +1
    Действительно, когда в первый раз узнал об этом, очень обрадовался. Но на данный момент достоверно известно, что некоторые приложения, даже приложения Гугла, работают некорректно в новом runtime. Таким образом, для того чтобы технология сменила Далвик окончательно и бесповоротно, ART надо еще допиливать до состояния, когда в нем корректно будут работать почти все приложения. Реальнее будет гарантировать это для всех приложений для Андроид 4.0 и выше, 2.3 к тому времени может и потерять актуальность. Да и разработчиков сподвигнет обновить свои приложения.
    Возможно, как раз переход на ART и даст нам новую первую цифру в версии Андроида (я про Андроид 5.х).
    • 0
      некоторые приложения, даже приложения Гугла, работают некорректно в новом runtime

      А можно пруф? Просто насколько я знаю в данный момент наблюдаются проблемы с Google Apps, но только в старой версии, до KitKat
  • +1
    Включил на nexus 5. На глаз трудно сказать, потому что и так тормозов не было заметно. Но многие программы стали запускаться намного быстрее. Мелкие — вообще моментально.
    При этом в Antutu количество попугает сократилось с 24 тысяч до 17.
  • 0
    Не очень понятно, зачем компилировать один и тот же код по многу раз на маломощных устройствах, если можно распространять нативные сборки сразу через Google Play. Возможно, так оно в итоге и окажется, но в статье упоминается только компиляция на устройстве.
    • +6
      Одна из преищмуществ виртуальных машин — возможность оптимизировать код в зависимости от железа, а не только независимость от архитектуры. К примеру, на процессоре с одноядерным и двухядерным процессором оно будет компилироваться немного по разному, или даже под каждый конкретный процессор компилятор будет немного «дотюнингован». С учетом оперативки могут быть изменены настройки сборки мусора и т. п.

      Финал — для любителей открытых систем — можно будет самому подтюнинговать компилятор в настройках системы :)

      Так что потенциала у компиляции на конкретном девайсе много.
      • –2
        Всё равно каждая модель смартфона продаётся сотнями тысяч штук, а у Гугла достаточно места и процессорных мощностей, чтобы компилировать приложения под все (или 80%) сочетаний <версия ARM, число ядер, объем ОЗУ>.
        • +1
          А как поступать с ноунейм-девайсами? Что делать с кастомными сборками систем? Это такой улей, что проще сделать все на стороне клиента, чем ввязываться в такое болото.
          • +6
            Gentoo с человеческим лицом
          • 0
            тем более, оно итак делается каждодневно по сотне раз у всех на девайсах.
          • –2
            Процессоров совсем не много. Достаточно поддержать популярные модели. Проблемы обделённого 1 процента юзеров — это их проблемы
      • 0
        Имелось в виду, почему бы при установке не про'odex'ировать программку и в /data/app залить уже .odex вместо .apk?
        • 0
          Вот они это и делают. Только компилировать будет ваше собственное устройство. И вам не в убыток, и им не нужно содержать мегаферму по пересборке всего на свете подо всё, что попало.
  • +3
    Это типа как на AS/400 будет? Хи-хи :)
  • +1
    (удалено — выше уже озвучили)
  • +3
    Вот тут приводятся результаты тестирования на примере сортировки массивов Integer
    image
    На графике виден двойной прирост в скорости, и забавный баг при попытке отсортировать массив из ~62k элементов
    • 0
      Ничего, оттестируют, выловят, исправят и будет всё хорошо. Dalvik тоже не сразу стал шустрым.
      • –2
        Он разве стал шустрым? 0_0
        • 0
          Не стал ), но JVM все таки за 10 лет допили, и теперь это эталон, может и тут, со временем. все бы изменилось
        • +4
          Стал в версии 2.2. До этого JIT в Дальвике не было.

          Помню, как мне подарили HTC Wildfire на новый год, и он шел с 2.1. И как прилетел апдейт на 2.2 где-то в феврале-марте. Ускорение было заметно невооруженным глазом.
    • 0
      Даже по ссылке непонятно, что они сортировали, Integer[] или int[]. А разница принципиальная.
      • 0
        Наверняка второе, тестировалась производительность просто сортировки, а не сортировки и взаимодействия с Java одновременно.
    • +1
      До скорости jni (c++) всё равно ещё в 2 раза ускорение нужно.
  • +1
    Интересно, а как там сборка мусора будет работать? Нативный код для этих целей будет дергать функции dalvik?
    • +3
      Ладно сборка. Что с рефлекшеном будет?
      • 0
        С рефлекшеном ничего не будет.
        А вот с динамической подгрузкой кода — не ясно.
        • 0
          А что именно Вас беспокоит?
          • 0
            Собственно как это будет реализованно: весь подгруженный код будет исполнятся в Dalvik или так же перед исполнением будет подвергаться AOT?
            • 0
              Опасаюсь, что это и есть те «некоторые неработоспособные функции», о которых говорилось в статье…
            • 0
              В теории сама виртуальная машина и заметить не должна, что код уже нагенерирован, это как будто если из цепочки
              Обращение к методу — Генерация кода — Исполнение кода
              Взять и убрать середину, оставив только обращение и исполнение.

              К сожалению, я не могу говорить про Java так же уверенно, как про C# (особенно Mono), но тот общий принцип, который я написал выше, наверняка должен выполняться!
  • НЛО прилетело и опубликовало эту надпись здесь
    • +1
      Так программа может NDK использовать и нативные либы, которые не работают на этом процессоре
    • +2
      Если в приложении есть нативный компонент, то оно должно поставляться с бинарниками для разных версий ARM.

      Во-первых, многие разработчики банально не думают о поддержке старых инструкций — ведь у каждого пользователя будет телефон 3-хмесячной давности с 4-7дюймовым экраном и тремя-четырьмя ядрами в процессоре, правда?

      А во-вторых, лишний бинарник увеличивает размер приложения — и не каждый хочет жертвовать размером скачиваемого кода. Андроид не дает возможности определить архитектуру процессора и «докачать» нужные версии бинарников из соображения безопасности. В свое время за это ругали Opera Mobile: my.opera.com/mobile/blog/the-components-of-opera-mobile-11-on-android
      • +1
        Андроид не дает возможности определить архитектуру процессора и «докачать» нужные версии бинарников из соображения безопасности.

        Но зато имеется отличная возможность опубликовать в Google Play несколько apk с различными билдами библиотек, скажем, отдельно apk с библиотекой под armv5, отдельно с билдом под armv7 и отдельно — х86. И при установке приложения из Google Play пользователю установится нужная версия с библиотеками под архитектуру его устройства.
        • 0
          Идея хороша, но в процентном соотношении людей которые будут знать свою архитектуру в своём телефоне гораздо меньше чем тех кто не знает.
          • 0
            Не-не, вы немного не правильно поняли. Пользователю вовсе не нужно знать архитектуру своего устройства, нужная версия ему установится автоматически. Он даже не узнает, что их там несколько.
          • 0
            Play умеет выдавать apk с либой под нужную архитектуру.
        • –2
          Я об этом не знал. Думаю, многие разработчики тоже не знают. Для большинства проблема звучит так: есть код на Java и C++ и на выходе нужно получить .apk для загрузки в Google Play. Если бы инструменты по умолчанию собирали пачку .apk-файлов для разных платформ, то проблема не стояла бы так остро.
          • +2
            Думаю, многие разработчики тоже не знают.

            И это странно, ведь этому посвящена целая глава в документации.

            Для большинства проблема звучит так: есть код на Java и C++ и на выходе нужно получить .apk для загрузки в Google Play. Если бы инструменты по умолчанию собирали пачку .apk-файлов для разных платформ, то проблема не стояла бы так остро.

            Согласен, было бы удобнее. Но отсутствие таковой функциональности не такая уж и проблема, поскольку не слишком сложная задача написать соответствующие билд-скрипты самому.
            • +3
              Вы переоцениваете уровень людей, занимающихся разработкой. Да, есть ассы своего дела, есть люди с инженерным подходом к делу, которые подумают и про билд, и про разные версии нативных компонентов. Но есть и те, кто открыл Гугл, накопипастил текста с разных блогов и форумов, кое-как добился того, что приложение работает на его телефоне и отправил это все в Google Play.

              Я тут недавно ради интереса решил попробовать покодить под iOS. И вот что я вам скажу: 90% ответов гугла на запросы по теме — это посты многостаночников-самоучек. Т.е. парень берется за любую работу: нужно визитку сверстать? — пожалуйста, нужен сайтик на Джумле — вот вам, нужен макет в фотошопе сделать? — тоже могу, и SEO, и рекламу, и в твиттере пиарить он умеет. И вот такой дизайнер-верстальщик решил, что PHP и Ruby on Rails — вчерашний день, а сегодня он будет делать приложения для Айфона или для Гэлэкси. У него что-то получилось, и он сразу себе это в блог. И качуют эти посты по всему инету.

              Есть документация от Apple — глубокая, но неудобная. Есть StackOverflow с ответами 2хгодичной давности, большинство из которых уже неактуальны. Ну и куча мусора в интернете.

              И это странно, ведь этому посвящена целая глава в документации.

              Такие люди не станут ее читать, пока сами не столкнутся с такой проблемой.

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

              Для них это сложно. Вот если бы это делал инструмент, они перестали бы быть источником такой проблемы.
              • 0
                Но есть и те, кто открыл Гугл, накопипастил текста с разных блогов и форумов, кое-как добился того, что приложение работает на его телефоне и отправил это все в Google Play.
                То, что вы описали — это социальная проблема. Она техническому решению не поддаётся.

                Для них это сложно. Вот если бы это делал инструмент, они перестали бы быть источником такой проблемы.
                И стали бы источником какой-нибудь другой проблемы. Вы не поверите, но можно вышеописанный подход порождает нечто, что перестаёт работать на следующей версии ОС независимо от того, что делают разработчики оной ОС — будь то Android, iOS или Windows. Если документацию не читать и писать программы вышеописанным способом, то добиться того, чтобы программа не смогла работать после минимального изменения в системе можно всегда.

                Есть буквально тысячи методов такое получить и ликвидация одного из них погоды, я вас уверяю, не сделает. В конце-концов в разных телефонах не только CPU отличаются. Ещё и GPU есть. И разные разрешения экранов. И наличие/отсутствие разных датчиков. Да, в конце-концов, всегда можно получить список каких-нибудь кодеков и проверить в нём первые три элемента. Или вообще обратиться сразу к третьему элементу, так как «там всегда MPEG3, я три раза проверил».

                Это не значит, что не стоит облегчать жизнь разработчиков. Стоит. Но надеяться, что вы таким образом «спасёте» вышеописанного Васю Пупкина не стоит: его поделка так или иначе сгинет со временем без следа. Ну, в лучшем случае, какие-то идеи из его поделий почерпнут нормальные разработчики и используют в своих проектах.
            • 0
              Так лучше под каждую платформу свой .apk или в одном .apk разные варианты скомпилированной библиотеки под каждую платформу?
              • 0
                Держать билды библиотек под различные архитектуры в одном apk — конечно же, удобнее в сопровождении и тестировании. Но если для вас важен размер итогового apk-файла, то можно и разнести версии библиотек по разным apk.

                Надо понимать, что у этого механизма куда более широкая область применения, потому и решать, как именно будет лучше, нужно исходя из конкретной задачи и сопутствующих условий. Автоматический выбор apk с библиотекой под нужную архитектуру — лишь одно из возможных применений.

                Первое, что ещё приходит в голову — игры. Разные apk содержат в себе разные графические ресурсы, с меньшими или большими размерами и детализацией, в зависимости от размера дисплея пользовательского устройства, плотности экрана и так далее. Раньше это решалось, как правило, созданием нескольких приложений в Google Play, да и сейчас всё ещё можно встретить немало игр, имеющих отдельную HD-версию.
  • +2
    Насколько я помню, лаги в интрефейсе еще связаны с самой архитектурой GUI на Android. Дело в низком приоритете графики и обработки пользовательского ввода. И это не изменить заменой VM, хотя, возможно, в ART что-то сделано и по этому поводу.
    • +1
      Эх, вот был такой интерн из Google, он именно так и утверждал про потоки и все такое. И я тоже повёлся. Но его доводы разбили в пух и прах.
      Вроде бы все GUI потоки не являются особенно приоритетными ни на какой из платформ (включая iOS, Android, Windows, Mac OS и различные Linux).
      Пост Эндрю Манна который даже немного раскаялся как видно из его «Follow up».
      А здесь немного опровержения.

      Кстати, говоря, Марк Шатворт когда рекламировал производительность Ubuntu Phone тоже заявлял: no Java and no Dalvik, so performance is really smooth. Реклама, конечно, но Java помянул в тему…
      • 0
        интерн из Google

        Andrew Munn said…

        Come on, I was a Software Engineer in Test. Not a testing intern :(
        • 0
          • 0
            Да ну интерн же он! 3rd year undergraduate student. Тем более, что в Америкосии если говорят интернет, то обычно это и есть интерн — система найма другая, и они там делают вид во время работы, что изучают что-то для науки, пишут какие-то «исследования» к работе прямое отношение не имеющие. Ну и зарплата существенно меньше.
            • 0
              Источник? Сам он, как видите, говорит, что не был интерном.
              • +1
                Да ну прочитайте его пост наконец-то уже! Я там наверху специально дал ссылку на пост Эндрю Манна. Вот цитирую:
                «First, I am a 3rd year undergraduate software engineering student. I interned on the Android team ...»
                «Second, I’m interning with the Windows Phone team starting in January ...»
                Это все он говорит сам про себя в своем собственном оригинальном посте, который вы не читали!

                Он не был «testing intern», что он и говорит Бобу Лии. Вообще Боб, несомненно, хотел его обидеть: «testing intern» это звучит очень уничижительно, на что Эндрю и говорит что «testing intern» он не был — был кем-то больше (как он думает).

                Источники, видите ли, подавай! Вам что угодно дай — вы ведь все равно не читаете…
                • 0
                  оригинальном посте, который вы не читали
                  Ванга, вы? Можно же было просто культурно сказать «в оригинальном посте вот тут» и привести цитату. Вначале в том посте идёт ссылка, по которой он первым же комментарием пишет, что не был интерном стажёром.
                  • 0
                    Не обижайтесь, пожалуйста. Я хоть и не Ванга, но все же тут считается неприличным не читать, не гуглить самому и задавать вопросы и требовать доказательства — это неуважение к собеседнику. Такое поведение — легальная причина для гнева.

                    И если я — хам, что указал вам на тот факт, что вы не прочитали; то школьные учителя тогда просто сплошь подонки! И хотя мы вовсе не в школе и у нас тут собрались профессионалы, но все же (когда читать лень) хотя бы Ctrl+F по интересующему вас слову никогда не помешает.
    • 0
      Вообще история то с этим Манном была довольно громкая. Неужели ничего не слышали? Мне было тогда так стыдно, что меня ввели в заблуждение, что я перечитал все что мог про главный поток (main thread) в котором живет цикл UI событий и вот нет никаких свидетельств о его высоком приоритете ни на какой из платформ. Болле того, почти везде этот поток вовсе не обязан быть главным потоком процесса.

      Как же после таких историй можно бросать такие комментарии про низкие приоритеты?!
      • +1
        Не буду спорить о приоритетах, потоках и подобном. Глазами видно, на андроиде отрисовка интерфейса практически всегда идет одновременно с другими задачами: подгрузкой данных, построением новых элементов интерфейса и подобное. На iOS после прикосновения пальца к экрану все прочее замирает, устройство только рисует интерфейс, скроллирует его. В этом и разница в плавности. Сделать плавным один потом со стандартизированной структурой проще и практически реализуемо, а вот пару десятков разной степени сложности — (пока) нереально.
        • 0
          Я согласен с вамт на счет плавности. Я очень часто сравниваю. Теперь вот у жены последний iPhone, а у меня последний Nexus. Разница в плавности и подгрузке экрана есть и весьма ощутимая. То, что iPhone останавливает другие задачи — нууу, не факт что это имеет решающий фактор. Узнаем когда они запустят этот ART в космос…
      • –1
        да, история громкая, помню бурление, как понял из статьи и ее комментов 2 версии почему так.

        По одной версии гугол сделал обычный приоритет для ui потока, т.к. андройд задумывался как конкурент blackberry, т.е. с клавой а не как тач-скрин и лишь только потом вышел айфон, который поменял тренд, но было уже поздно для гугла изменить ui. А теперь не фиксят т.к. потребует переписывания большинства приложений.

        По второй — это все trade-off между гладким ui и многопроцессорностью, который по задумке инженеров гугла должен постепенно нивелироваться мощным железом и разными gpu оптимизациями. И прерывание многих процессов ради отрисовки гуя будет уже необязательно.

        За каким подходом будущее? ведь на дворе уже 4-ядерные процессоры смартфонов.
  • +2
    Любопытный факт, может не все знали — в .NET от MS такая вещь реализуется с помощью ngen.exe. Эта замечательная утилита может скушать вашу managed сборку и заранее сгенерировать в ней весь код (а не при первом обращении к методу или классу). Все сборки, идущие в составе .NET Framework в базовом наборе (System.dll, System.Xml и т.д.), уже про-ngen-ены :)
    А в моно такая замечательная вещь называется одноименно, AOT.
    • 0
      Тогда какого чёрта известная утилита Samsung MagicTune для управления яркостью монитора не пользуется этой возможностью и грузится по 5-10 секунд?
    • 0
      Правильно ли я понял в Windows Phone это уже используется автоматически?
      • 0
        Вряд ли бы они упустили такую возможность выиграть в производительности!
        P.S. забавны файт — в Windows Phone 7.5 основное меню, опции и т.д. были написаны не на Silverlight, а с помощью старого доброго WinAPI.
    • 0
      Хм, помнится, если приглядеться к запускаемым процессам во время установке .NET-а, они как раз ngen-ятся непосредственно при установке. Может, и ошибаюсь.
      • 0
        Да да, ведь установка происходит на конкретный тип процессора ;)
  • 0
    Хотелось бы знать, смогу ли я использовать эту новую вирт. машину на своём Samsung Galaxy Tab с Android 2.3 на борту.

    Тормоза в данный момент это самая серьёзная проблема при работе, в остальном же этого «устаревшего» планшета мне вполне хватает.
    • +1
      Ну только если найдёте на свой планшет Android 4.4. :)
      • 0
        Да какой 4.4, Samsung нас прокатила даже с обновлением до 4.0, «дескать» 512 памяти для него мало.

        Нужен backport на 2.3.
        • 0
          Кстати на перый таб есть андроид 4.3, вчера шил.
          • 0
            Циаген? Когда я последний раз пробовал четвёрку от циагена, там был выставлено некорректный масштаб, в общем весь интерфейс был очень мелким. И тривиально это не фиксилось.

            Так или иначе, ссылочку пожалуйста.
  • –3
    не знаю, мне кажется проблема торможения андроид устройств уже устарела.
    У меня нексус 4, ничего не тормозит.
    • +1
      Это значит, что у вас нет опыта на яблочных девайсах. У меня был Nexus 4 и только что появился Nexus 5. Я сравнивал Nexus 4 с iPhone 4s и Nexus 5 с iPhone 5s (у жены). Привожу конкретные сценарии:
      Откройте PDF книгу объемом 300 страниц, полистайте вперед-назад. На яблоках все заметно быстрее и плавнее (при том, что проц там слабее).
      Откройте любую web-страницу не помещающуюся в высоту экрана и поскрольте ее вниз с пристрастием. На яблоках плавнее, контент просто как будто прилип к пальцу и там значительно труднее добиться белого экрана.
      PDF любой (эта проблема видна много где, не только в PDF) зумаем двумя пальцами, на нексусах успеваем увидеть нечто размытое, на айфонах такого вообще нет.

      Не поймите меня неправильно — я сам фанат нексусов на чистом андроиде. Просто вот нельзя же отрицать очевидное. Без признания проблем они обычно никак не решаются…
      • –3
        У меня не просто есть опыт с яблочными девайсами — у меня есть яблочный девайс. И после выхода IOS7 он (Ipad 3) стал визуально отрмознее моего смартфона нексус 4
        • +1
          Ну вы сравнивайте девайсы одного класса, хотя бы! Вот Nexus 5 против iPhone 5s это топовые девайсы в одном классе вышедшие почти одновременно и работают на последней версии оси. А вы сравниваете 10 inch таблет который вышел в марте 2012 с 4 inch смартфоном вышедшим в ноябре 2012 (на 8 месяцев позже). Я даже не знаю, как бы вам намекнуть на нечистоту вашего опыта.

          Какие-то опровержения по моим сценариям в моем объективном сравнении будут?
          • –2
            Нет уж, давайте сравнивать девайсы одной стоимости!!!
            • +2
              Подождите! У вас нет проблем с тормозами Андроида или есть проблемы с отсутствием денег?
              Вы заявляете, что у вас нет проблем с тормозами, когда я вам говорю, что есть девайсы с худшим железом и работющее более плавно вы переводите тему. Моя принципиальная позиция: на железе Nexus должны быть лучше чем iPhone, а они хуже. Деньги не при чем.

              Что касается цен. Тут вы вообще не в теме. Всем широко известно, что Nexus — субсидируемые Google телефоны. Это демпинг. Они на Nexus'ах не зарабатывают и LG тоже! Базовые модели от производителей, на которых делают Nexus'ы стоят и стоили очень близко к топовым iPhone, иногда даже ровно столько же. Это лишний раз показывает, что ценообразование, в случае смартфонов не связяно с производтельностью и качествои программного обеспечения. Поэтому сравнение одинаковых девайсов по цене ни о чем не говорит вообще и не влияет на утверждения относительно наличия или отсутствия ториозов тут или там.
              • –3
                Я сказал — нет проблем с тормозами, точка. А вы дальше тему развивать начали. Предлагаете сравнивать что-то с чем-то, говорите что я неправильно все понимаю, что мой опыт неполноценен, что я нищеброд…

                Кто там на ком зарабатывает, мне пофигу в контексте заявления «у меня на нексусе нет проблем с тормозами».
                • 0
                  Аминь! Играйте дальше в крестики-нолики — они действительно нигде не тормозят. Для них даже телефон не нужен.
    • 0
      А камера то это вообще на нексусах тихий ужас! На айфонах как-то они добились что ей нужно очень мало времени, чтобы сделать снимок. На нексус 4 вообще мрак, на нексус 5 получше, но все равно значительно медленнее, чем на айфоне. Гугл говорит, что причина в софте, что будут улучшать в апдейтах, но ничего о сроках…
  • 0
    Тормоза? Хммм. У меня вот HTC One и его sense 5 ну просто очень реактивный. В то же время другие приложения отлично подтормаживают.

    Ньюансов я не знаю, может Sense как-то уж сильно заточен на EGL а остальные нет?
    Кто-то в курсе?
    • 0
      HTC One имеет «под капотом» 4 эффективных ядра на 2.7 ГГц и 2 Гб оперативной памяти — на таком железе стыдно тормозить. Более того, Лаунчер (по моим наблюдениям) со всеми фирменными приложениями работает как одно целое, как одно приложение. Следовательно, меньше потери времени на загрузку стороннего виджета или программы, их фирменных элементов интерфейса. А загрузка из постоянной памяти как раз и есть основной тормоз в работе.
      Конечно, оптимизации под оборудование тоже имеют быть. Для сравнения, на двухяжерной HTC Sensation в почтовом клиенте работало одно ядро. При скроллинге большого письма система хотела включить второе ядро, но почему-то это происходило с видимой задержкой — вместо плавного пролистывания я получал одну-две паузы в скроллинге, что не радовало.
      • 0
        Однако приложения тормозят (не берусь судить стыдно-ли их авторам).
        Речь была про скролл и UI вообще. Поэтому оцениваем мы именно это, а не загрузку из постоянной памяти (ваши слова о едином целом Сенса как раз минимизируют этот фактор).

        Открываем контакты и скролим — замечательно.
        Открываем, например, RssDemon и скроллим — не очень.
        Текст в 2гис это вообще АД. А они утрверждают, что «используют ускорение».

        Не могу привести осцилограмму, но при использовании Сенса другие ядра скорее всего вообще не подключаются.

        Говернор dancedance именно он мне по минимизации задержек в подымании частоты нравится более других. Частота у меня зарезана до 2х ГГц. Так что правильная отрисовка таки у Сенса сделана правильнее других правильных.
        • 0
          Получается, что разогнан :)
        • 0
          Во многом тормоза происходят из-за архитектуры Андроид — делать все и сразу, параллельно с отрисовкой интерфейса. Все эти прокручивающиеся области — потенциальный источник тормозов. Особенно если в коне много данных, загружаемых с диска.
          В 2ГИС в предыдущих версиях во время скроллинга карты система, по моим наблюдениям, параллельно из базы загружала номера домов на экране. Сейчас при скроллинге такого нет — скорость возросла.
          Другой пример — моя компания разрабатывает приложение. Там есть окно со списком контактов с их картинками. Ранее при открытии этого окна одним поток и список хитрый отрисовывался, и данные с картинками подгружались. Были тормоза. Сейчас подкгрузку перенесли в отдельный поток — стало намного быстрее.
          Возвращаясь к основной теме — ART вряд ли поможет совсем убрать тормоза вот в таких ситуациях, разве что уменьшить их.
  • 0
    Буквально сейчас накатал на Nexus 7 2013 kitkat, переключился на среду исполнения Art. Да, у меня нет опыта в использовании устройств Apple, но субъективно скорость интерфейса стала выше, отклик при запуске приложений меньше и оперативная память освободилась где-то на 15%-20%. Общими словами стало гораздо комфортнее работать, хотя и раньше никаких раздражающих факторов не было — все же новый Nexus 7 довольно мощный компьютер. И да, никаких проблем в работе сервисов Google нет (разве что виртуальный принтер что-то не завелся, но это уже другое).
    • 0
      А как работают другие приложения из Маркета, сделанные не Гуглом? Какая-нибудь игрушка со сложной графикой — они чувствительны ко всем косякам в софте.
      • 0
        Асфальт 8, Worms2 — полёт отличный, других последних игр не ставил еще, с приложениями тоже никаких проблем. Инстаграм стал открываться и показывать фотки гораздо шустрее, Ютуб тоже работает с приятной скоростью.
  • 0
    Кстати, теперь и в .NET появилась AOT компиляция dlang.ru/205-csharp-poluchit-aot-kompilyator
    Интересно будет посмотреть на сравнение производительности решения из Java и .NET
    • +1
      А её там не было? А ngen тогда что?
      • 0
        Обогреватель.exe </irony>
  • 0
    ART в действии.
    Сейчас есть на руках трехгодичной давности аппарат HTC Sensation (2 ядра Coretx-A8 на 1.5 ГГц, 768 ОЗУб 1Гб ПЗУ). Стоит кастом с 4.4.2
    Установлено приличное число приложений.
    На Далвик приложения занимают 480 МБайт.
    На ART приложения разрастаются до 785 МБайт. При этом визуально заметно сокращение времени загрузки приложений, они работаю более плавно (скролл экранов с большим числом элементов).
    В Целом, ART — очень хорошее решение, особенно для маломощных аппаратов. Просто на топовых девайсах и на Далвик все летает. А вот когда насчтеу каждый мегафлоп системы, каждое увеличении скорости очевидно. Минус — требуется в полтора-два раза больше места во внутренней памяти, что как раз для бюджетных и старых аппаратов может доставить сложности.
    • 0
      Было бы круто, если бы они позволили настраивать, какая ВМ предпочтительнее для данного приложения и чтобы настройка была как для разработчика, так и для юзеров.
  • 0
    Интерфейс — это прекрасно. И здорово, что Google этим занимается.

    Печалит то, что они забивают на решение проблем с real-time применением их устройств. Например, вы не сможете подключить гитару через подобие iRig к Android-смартфону, запустить приложение-примочку и получить задержку ввода/вывода на уровне
    • 0
      а айфон так сможет?
  • 0
    Сегодня была новость, что следующая версия Андроид уже окончательно перейдет на рантайм ART. Я пока не встречал приложений, который под ним бы не работали.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.