Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 108
Интересно, будет ли это чистый Ahead-Of-Time или таки горячие места будут перекомпилироваться с использованием доступной только в рантайме информации.
Это принципиально не может быть чистый AOT. Как известно, Java поддерживает рефлексию. Причем многие фреймворки (например, Spring) не только ее активно используют для получения метаданных, но и занимаются кодогенерацией на JVM.
Единственное, что может позволить себе виртуальная машина — это сгенерировать код для классов, входящик в APK. Если выкинуть кодогенерацию JIT совсем, это поломает Java.
Единственное, что может позволить себе виртуальная машина — это сгенерировать код для классов, входящик в APK. Если выкинуть кодогенерацию JIT совсем, это поломает Java.
Очень сомневаюсь, что кто-то генерирует код на андроиде.
Зря сомневаетесь. Я не зря привёл в пример Spring. Он очень популярен.
projects.spring.io/spring-android/
projects.spring.io/spring-android/
У Гугла все же есть небольшая информация:
source.android.com/devices/tech/dalvik/art.html
Доступность этой опции будет на совести производителя устройства. Сейчас это экспериментальная функция: требуется на этапе сборки ПО для устройства указать, какой runtime включить в прошивку — только Далвик или оба.
source.android.com/devices/tech/dalvik/art.html
Доступность этой опции будет на совести производителя устройства. Сейчас это экспериментальная функция: требуется на этапе сборки ПО для устройства указать, какой runtime включить в прошивку — только Далвик или оба.
Если вы, вдруг, как я, поставили ранний образ Android 4..4 от Nexus 5 на свой Nexus 4, то не стоит переключать далвик на арт.
Крашатся все гуглапс.
Крашатся все гуглапс.
Вот тут прошивка есть рабочая, что бы посмотреть на art.
forum.xda-developers.com/showthread.php?t=2508185
forum.xda-developers.com/showthread.php?t=2508185
Я уже решил ОТА/Factory Images дождаться, там и посмотрим.
Я себе позавчера поставил вот этот порт с пятого. Понадобилось долить библиотеки для хрома из этого же поста.
Провёл конвертацию в ART, заняло полчаса примерно. Переживал, что телефон перегреется и вырубится — такой он был горячий.
Полёт совершенно нормальный, не считая того что перестал запускаться Whatsapp.
Работает как минимум так же быстро, как Pure Speed Experiment для v4.3.
Не могу пока сказать с уверенностью, что батарею жрёт меньше, но в общем верю, потому что всё действительно стало очень плавно и быстро работать.
Провёл конвертацию в ART, заняло полчаса примерно. Переживал, что телефон перегреется и вырубится — такой он был горячий.
Полёт совершенно нормальный, не считая того что перестал запускаться Whatsapp.
Работает как минимум так же быстро, как Pure Speed Experiment для v4.3.
Не могу пока сказать с уверенностью, что батарею жрёт меньше, но в общем верю, потому что всё действительно стало очень плавно и быстро работать.
Хорошая новость, как для пользователей, так и для разработчиков.
Интересно больше узнать о «неработоспособности некоторых функций».
Из минусов — большее время установки, больший занимаемый размер, возможно неработоспособность некоторых функций.Установка один раз происходит (ну, обновления ещё иногда), так что, не критично. Увеличение размера тоже не критично, учитывая, что это не касается медиа ресурсов.
Интересно больше узнать о «неработоспособности некоторых функций».
Возможно, кстати, они-таки отпилили весь JIT и возможности динамической кодогенерации в приложениях сломаны.
В этом случае рискну предсказать, что в итоге две системы подружатся — просто ART будет компилить заранее всё, что сможет, а Dalvik будет включаться в дело когда без динамической компиляции не обойтись.
В этом случае рискну предсказать, что в итоге две системы подружатся — просто ART будет компилить заранее всё, что сможет, а Dalvik будет включаться в дело когда без динамической компиляции не обойтись.
Шикарная новость! Надеюсь, в следующей версии уже будет изкоробки, и к тому моменту не забьют хотя бы на Nexus 4, а то не хочется его менять совсем. Это ведь по сути одним махом излечит Android от всех основных недостатков! Скорее бы :)
Действительно, когда в первый раз узнал об этом, очень обрадовался. Но на данный момент достоверно известно, что некоторые приложения, даже приложения Гугла, работают некорректно в новом runtime. Таким образом, для того чтобы технология сменила Далвик окончательно и бесповоротно, ART надо еще допиливать до состояния, когда в нем корректно будут работать почти все приложения. Реальнее будет гарантировать это для всех приложений для Андроид 4.0 и выше, 2.3 к тому времени может и потерять актуальность. Да и разработчиков сподвигнет обновить свои приложения.
Возможно, как раз переход на ART и даст нам новую первую цифру в версии Андроида (я про Андроид 5.х).
Возможно, как раз переход на ART и даст нам новую первую цифру в версии Андроида (я про Андроид 5.х).
Включил на nexus 5. На глаз трудно сказать, потому что и так тормозов не было заметно. Но многие программы стали запускаться намного быстрее. Мелкие — вообще моментально.
При этом в Antutu количество попугает сократилось с 24 тысяч до 17.
При этом в Antutu количество попугает сократилось с 24 тысяч до 17.
Не очень понятно, зачем компилировать один и тот же код по многу раз на маломощных устройствах, если можно распространять нативные сборки сразу через Google Play. Возможно, так оно в итоге и окажется, но в статье упоминается только компиляция на устройстве.
Всё равно каждая модель смартфона продаётся сотнями тысяч штук, а у Гугла достаточно места и процессорных мощностей, чтобы компилировать приложения под все (или 80%) сочетаний <версия ARM, число ядер, объем ОЗУ>.
Имелось в виду, почему бы при установке не про'odex'ировать программку и в /data/app залить уже .odex вместо .apk?
Это типа как на AS/400 будет? Хи-хи :)
(удалено — выше уже озвучили)
Вот тут приводятся результаты тестирования на примере сортировки массивов Integer
На графике виден двойной прирост в скорости, и забавный баг при попытке отсортировать массив из ~62k элементов
На графике виден двойной прирост в скорости, и забавный баг при попытке отсортировать массив из ~62k элементов
Ничего, оттестируют, выловят, исправят и будет всё хорошо. Dalvik тоже не сразу стал шустрым.
Не стал ), но JVM все таки за 10 лет допили, и теперь это эталон, может и тут, со временем. все бы изменилось
Стал в версии 2.2. До этого JIT в Дальвике не было.
Помню, как мне подарили HTC Wildfire на новый год, и он шел с 2.1. И как прилетел апдейт на 2.2 где-то в феврале-марте. Ускорение было заметно невооруженным глазом.
Помню, как мне подарили HTC Wildfire на новый год, и он шел с 2.1. И как прилетел апдейт на 2.2 где-то в феврале-марте. Ускорение было заметно невооруженным глазом.
Даже по ссылке непонятно, что они сортировали,
Integer[] или int[]. А разница принципиальная.
До скорости jni (c++) всё равно ещё в 2 раза ускорение нужно.
Интересно, а как там сборка мусора будет работать? Нативный код для этих целей будет дергать функции dalvik?
Ладно сборка. Что с рефлекшеном будет?
С рефлекшеном ничего не будет.
А вот с динамической подгрузкой кода — не ясно.
А вот с динамической подгрузкой кода — не ясно.
А что именно Вас беспокоит?
Собственно как это будет реализованно: весь подгруженный код будет исполнятся в Dalvik или так же перед исполнением будет подвергаться AOT?
Опасаюсь, что это и есть те «некоторые неработоспособные функции», о которых говорилось в статье…
В теории сама виртуальная машина и заметить не должна, что код уже нагенерирован, это как будто если из цепочки
Обращение к методу — Генерация кода — Исполнение кода
Взять и убрать середину, оставив только обращение и исполнение.
К сожалению, я не могу говорить про Java так же уверенно, как про C# (особенно Mono), но тот общий принцип, который я написал выше, наверняка должен выполняться!
Обращение к методу — Генерация кода — Исполнение кода
Взять и убрать середину, оставив только обращение и исполнение.
К сожалению, я не могу говорить про Java так же уверенно, как про C# (особенно Mono), но тот общий принцип, который я написал выше, наверняка должен выполняться!
Так программа может NDK использовать и нативные либы, которые не работают на этом процессоре
Если в приложении есть нативный компонент, то оно должно поставляться с бинарниками для разных версий ARM.
Во-первых, многие разработчики банально не думают о поддержке старых инструкций — ведь у каждого пользователя будет телефон 3-хмесячной давности с 4-7дюймовым экраном и тремя-четырьмя ядрами в процессоре, правда?
А во-вторых, лишний бинарник увеличивает размер приложения — и не каждый хочет жертвовать размером скачиваемого кода. Андроид не дает возможности определить архитектуру процессора и «докачать» нужные версии бинарников из соображения безопасности. В свое время за это ругали Opera Mobile: my.opera.com/mobile/blog/the-components-of-opera-mobile-11-on-android
Во-первых, многие разработчики банально не думают о поддержке старых инструкций — ведь у каждого пользователя будет телефон 3-хмесячной давности с 4-7дюймовым экраном и тремя-четырьмя ядрами в процессоре, правда?
А во-вторых, лишний бинарник увеличивает размер приложения — и не каждый хочет жертвовать размером скачиваемого кода. Андроид не дает возможности определить архитектуру процессора и «докачать» нужные версии бинарников из соображения безопасности. В свое время за это ругали Opera Mobile: my.opera.com/mobile/blog/the-components-of-opera-mobile-11-on-android
Андроид не дает возможности определить архитектуру процессора и «докачать» нужные версии бинарников из соображения безопасности.
Но зато имеется отличная возможность опубликовать в Google Play несколько apk с различными билдами библиотек, скажем, отдельно apk с библиотекой под armv5, отдельно с билдом под armv7 и отдельно — х86. И при установке приложения из Google Play пользователю установится нужная версия с библиотеками под архитектуру его устройства.
Идея хороша, но в процентном соотношении людей которые будут знать свою архитектуру в своём телефоне гораздо меньше чем тех кто не знает.
Я об этом не знал. Думаю, многие разработчики тоже не знают. Для большинства проблема звучит так: есть код на Java и C++ и на выходе нужно получить .apk для загрузки в Google Play. Если бы инструменты по умолчанию собирали пачку .apk-файлов для разных платформ, то проблема не стояла бы так остро.
Думаю, многие разработчики тоже не знают.
И это странно, ведь этому посвящена целая глава в документации.
Для большинства проблема звучит так: есть код на Java и C++ и на выходе нужно получить .apk для загрузки в Google Play. Если бы инструменты по умолчанию собирали пачку .apk-файлов для разных платформ, то проблема не стояла бы так остро.
Согласен, было бы удобнее. Но отсутствие таковой функциональности не такая уж и проблема, поскольку не слишком сложная задача написать соответствующие билд-скрипты самому.
Вы переоцениваете уровень людей, занимающихся разработкой. Да, есть ассы своего дела, есть люди с инженерным подходом к делу, которые подумают и про билд, и про разные версии нативных компонентов. Но есть и те, кто открыл Гугл, накопипастил текста с разных блогов и форумов, кое-как добился того, что приложение работает на его телефоне и отправил это все в Google Play.
Я тут недавно ради интереса решил попробовать покодить под iOS. И вот что я вам скажу: 90% ответов гугла на запросы по теме — это посты многостаночников-самоучек. Т.е. парень берется за любую работу: нужно визитку сверстать? — пожалуйста, нужен сайтик на Джумле — вот вам, нужен макет в фотошопе сделать? — тоже могу, и SEO, и рекламу, и в твиттере пиарить он умеет. И вот такой дизайнер-верстальщик решил, что PHP и Ruby on Rails — вчерашний день, а сегодня он будет делать приложения для Айфона или для Гэлэкси. У него что-то получилось, и он сразу себе это в блог. И качуют эти посты по всему инету.
Есть документация от Apple — глубокая, но неудобная. Есть StackOverflow с ответами 2хгодичной давности, большинство из которых уже неактуальны. Ну и куча мусора в интернете.
Такие люди не станут ее читать, пока сами не столкнутся с такой проблемой.
Для них это сложно. Вот если бы это делал инструмент, они перестали бы быть источником такой проблемы.
Я тут недавно ради интереса решил попробовать покодить под iOS. И вот что я вам скажу: 90% ответов гугла на запросы по теме — это посты многостаночников-самоучек. Т.е. парень берется за любую работу: нужно визитку сверстать? — пожалуйста, нужен сайтик на Джумле — вот вам, нужен макет в фотошопе сделать? — тоже могу, и SEO, и рекламу, и в твиттере пиарить он умеет. И вот такой дизайнер-верстальщик решил, что PHP и Ruby on Rails — вчерашний день, а сегодня он будет делать приложения для Айфона или для Гэлэкси. У него что-то получилось, и он сразу себе это в блог. И качуют эти посты по всему инету.
Есть документация от Apple — глубокая, но неудобная. Есть StackOverflow с ответами 2хгодичной давности, большинство из которых уже неактуальны. Ну и куча мусора в интернете.
И это странно, ведь этому посвящена целая глава в документации.
Такие люди не станут ее читать, пока сами не столкнутся с такой проблемой.
не слишком сложная задача написать соответствующие билд-скрипты самому.
Для них это сложно. Вот если бы это делал инструмент, они перестали бы быть источником такой проблемы.
Но есть и те, кто открыл Гугл, накопипастил текста с разных блогов и форумов, кое-как добился того, что приложение работает на его телефоне и отправил это все в Google Play.То, что вы описали — это социальная проблема. Она техническому решению не поддаётся.
Для них это сложно. Вот если бы это делал инструмент, они перестали бы быть источником такой проблемы.И стали бы источником какой-нибудь другой проблемы. Вы не поверите, но можно вышеописанный подход порождает нечто, что перестаёт работать на следующей версии ОС независимо от того, что делают разработчики оной ОС — будь то Android, iOS или Windows. Если документацию не читать и писать программы вышеописанным способом, то добиться того, чтобы программа не смогла работать после минимального изменения в системе можно всегда.
Есть буквально тысячи методов такое получить и ликвидация одного из них погоды, я вас уверяю, не сделает. В конце-концов в разных телефонах не только CPU отличаются. Ещё и GPU есть. И разные разрешения экранов. И наличие/отсутствие разных датчиков. Да, в конце-концов, всегда можно получить список каких-нибудь кодеков и проверить в нём первые три элемента. Или вообще обратиться сразу к третьему элементу, так как «там всегда MPEG3, я три раза проверил».
Это не значит, что не стоит облегчать жизнь разработчиков. Стоит. Но надеяться, что вы таким образом «спасёте» вышеописанного Васю Пупкина не стоит: его поделка так или иначе сгинет со временем без следа. Ну, в лучшем случае, какие-то идеи из его поделий почерпнут нормальные разработчики и используют в своих проектах.
Так лучше под каждую платформу свой .apk или в одном .apk разные варианты скомпилированной библиотеки под каждую платформу?
Держать билды библиотек под различные архитектуры в одном apk — конечно же, удобнее в сопровождении и тестировании. Но если для вас важен размер итогового apk-файла, то можно и разнести версии библиотек по разным apk.
Надо понимать, что у этого механизма куда более широкая область применения, потому и решать, как именно будет лучше, нужно исходя из конкретной задачи и сопутствующих условий. Автоматический выбор apk с библиотекой под нужную архитектуру — лишь одно из возможных применений.
Первое, что ещё приходит в голову — игры. Разные apk содержат в себе разные графические ресурсы, с меньшими или большими размерами и детализацией, в зависимости от размера дисплея пользовательского устройства, плотности экрана и так далее. Раньше это решалось, как правило, созданием нескольких приложений в Google Play, да и сейчас всё ещё можно встретить немало игр, имеющих отдельную HD-версию.
Надо понимать, что у этого механизма куда более широкая область применения, потому и решать, как именно будет лучше, нужно исходя из конкретной задачи и сопутствующих условий. Автоматический выбор apk с библиотекой под нужную архитектуру — лишь одно из возможных применений.
Первое, что ещё приходит в голову — игры. Разные apk содержат в себе разные графические ресурсы, с меньшими или большими размерами и детализацией, в зависимости от размера дисплея пользовательского устройства, плотности экрана и так далее. Раньше это решалось, как правило, созданием нескольких приложений в Google Play, да и сейчас всё ещё можно встретить немало игр, имеющих отдельную HD-версию.
Насколько я помню, лаги в интрефейсе еще связаны с самой архитектурой GUI на Android. Дело в низком приоритете графики и обработки пользовательского ввода. И это не изменить заменой VM, хотя, возможно, в ART что-то сделано и по этому поводу.
Не буду спорить о приоритетах, потоках и подобном. Глазами видно, на андроиде отрисовка интерфейса практически всегда идет одновременно с другими задачами: подгрузкой данных, построением новых элементов интерфейса и подобное. На iOS после прикосновения пальца к экрану все прочее замирает, устройство только рисует интерфейс, скроллирует его. В этом и разница в плавности. Сделать плавным один потом со стандартизированной структурой проще и практически реализуемо, а вот пару десятков разной степени сложности — (пока) нереально.
да, история громкая, помню бурление, как понял из статьи и ее комментов 2 версии почему так.
По одной версии гугол сделал обычный приоритет для ui потока, т.к. андройд задумывался как конкурент blackberry, т.е. с клавой а не как тач-скрин и лишь только потом вышел айфон, который поменял тренд, но было уже поздно для гугла изменить ui. А теперь не фиксят т.к. потребует переписывания большинства приложений.
По второй — это все trade-off между гладким ui и многопроцессорностью, который по задумке инженеров гугла должен постепенно нивелироваться мощным железом и разными gpu оптимизациями. И прерывание многих процессов ради отрисовки гуя будет уже необязательно.
За каким подходом будущее? ведь на дворе уже 4-ядерные процессоры смартфонов.
По одной версии гугол сделал обычный приоритет для ui потока, т.к. андройд задумывался как конкурент blackberry, т.е. с клавой а не как тач-скрин и лишь только потом вышел айфон, который поменял тренд, но было уже поздно для гугла изменить ui. А теперь не фиксят т.к. потребует переписывания большинства приложений.
По второй — это все trade-off между гладким ui и многопроцессорностью, который по задумке инженеров гугла должен постепенно нивелироваться мощным железом и разными gpu оптимизациями. И прерывание многих процессов ради отрисовки гуя будет уже необязательно.
За каким подходом будущее? ведь на дворе уже 4-ядерные процессоры смартфонов.
Любопытный факт, может не все знали — в .NET от MS такая вещь реализуется с помощью ngen.exe. Эта замечательная утилита может скушать вашу managed сборку и заранее сгенерировать в ней весь код (а не при первом обращении к методу или классу). Все сборки, идущие в составе .NET Framework в базовом наборе (System.dll, System.Xml и т.д.), уже про-ngen-ены :)
А в моно такая замечательная вещь называется одноименно, AOT.
А в моно такая замечательная вещь называется одноименно, AOT.
Тогда какого чёрта известная утилита Samsung MagicTune для управления яркостью монитора не пользуется этой возможностью и грузится по 5-10 секунд?
Правильно ли я понял в Windows Phone это уже используется автоматически?
Хм, помнится, если приглядеться к запускаемым процессам во время установке .NET-а, они как раз ngen-ятся непосредственно при установке. Может, и ошибаюсь.
Хотелось бы знать, смогу ли я использовать эту новую вирт. машину на своём Samsung Galaxy Tab с Android 2.3 на борту.
Тормоза в данный момент это самая серьёзная проблема при работе, в остальном же этого «устаревшего» планшета мне вполне хватает.
Тормоза в данный момент это самая серьёзная проблема при работе, в остальном же этого «устаревшего» планшета мне вполне хватает.
Ну только если найдёте на свой планшет Android 4.4. :)
Да какой 4.4, Samsung нас прокатила даже с обновлением до 4.0, «дескать» 512 памяти для него мало.
Нужен backport на 2.3.
Нужен backport на 2.3.
не знаю, мне кажется проблема торможения андроид устройств уже устарела.
У меня нексус 4, ничего не тормозит.
У меня нексус 4, ничего не тормозит.
У меня не просто есть опыт с яблочными девайсами — у меня есть яблочный девайс. И после выхода IOS7 он (Ipad 3) стал визуально отрмознее моего смартфона нексус 4
Нет уж, давайте сравнивать девайсы одной стоимости!!!
Я сказал — нет проблем с тормозами, точка. А вы дальше тему развивать начали. Предлагаете сравнивать что-то с чем-то, говорите что я неправильно все понимаю, что мой опыт неполноценен, что я нищеброд…
Кто там на ком зарабатывает, мне пофигу в контексте заявления «у меня на нексусе нет проблем с тормозами».
Кто там на ком зарабатывает, мне пофигу в контексте заявления «у меня на нексусе нет проблем с тормозами».
Тормоза? Хммм. У меня вот HTC One и его sense 5 ну просто очень реактивный. В то же время другие приложения отлично подтормаживают.
Ньюансов я не знаю, может Sense как-то уж сильно заточен на EGL а остальные нет?
Кто-то в курсе?
Ньюансов я не знаю, может Sense как-то уж сильно заточен на EGL а остальные нет?
Кто-то в курсе?
HTC One имеет «под капотом» 4 эффективных ядра на 2.7 ГГц и 2 Гб оперативной памяти — на таком железе стыдно тормозить. Более того, Лаунчер (по моим наблюдениям) со всеми фирменными приложениями работает как одно целое, как одно приложение. Следовательно, меньше потери времени на загрузку стороннего виджета или программы, их фирменных элементов интерфейса. А загрузка из постоянной памяти как раз и есть основной тормоз в работе.
Конечно, оптимизации под оборудование тоже имеют быть. Для сравнения, на двухяжерной HTC Sensation в почтовом клиенте работало одно ядро. При скроллинге большого письма система хотела включить второе ядро, но почему-то это происходило с видимой задержкой — вместо плавного пролистывания я получал одну-две паузы в скроллинге, что не радовало.
Конечно, оптимизации под оборудование тоже имеют быть. Для сравнения, на двухяжерной HTC Sensation в почтовом клиенте работало одно ядро. При скроллинге большого письма система хотела включить второе ядро, но почему-то это происходило с видимой задержкой — вместо плавного пролистывания я получал одну-две паузы в скроллинге, что не радовало.
Однако приложения тормозят (не берусь судить стыдно-ли их авторам).
Речь была про скролл и UI вообще. Поэтому оцениваем мы именно это, а не загрузку из постоянной памяти (ваши слова о едином целом Сенса как раз минимизируют этот фактор).
Открываем контакты и скролим — замечательно.
Открываем, например, RssDemon и скроллим — не очень.
Текст в 2гис это вообще АД. А они утрверждают, что «используют ускорение».
Не могу привести осцилограмму, но при использовании Сенса другие ядра скорее всего вообще не подключаются.
Говернор dancedance именно он мне по минимизации задержек в подымании частоты нравится более других. Частота у меня зарезана до 2х ГГц. Так что правильная отрисовка таки у Сенса сделана правильнее других правильных.
Речь была про скролл и UI вообще. Поэтому оцениваем мы именно это, а не загрузку из постоянной памяти (ваши слова о едином целом Сенса как раз минимизируют этот фактор).
Открываем контакты и скролим — замечательно.
Открываем, например, RssDemon и скроллим — не очень.
Текст в 2гис это вообще АД. А они утрверждают, что «используют ускорение».
Не могу привести осцилограмму, но при использовании Сенса другие ядра скорее всего вообще не подключаются.
Говернор dancedance именно он мне по минимизации задержек в подымании частоты нравится более других. Частота у меня зарезана до 2х ГГц. Так что правильная отрисовка таки у Сенса сделана правильнее других правильных.
Получается, что разогнан :)
Во многом тормоза происходят из-за архитектуры Андроид — делать все и сразу, параллельно с отрисовкой интерфейса. Все эти прокручивающиеся области — потенциальный источник тормозов. Особенно если в коне много данных, загружаемых с диска.
В 2ГИС в предыдущих версиях во время скроллинга карты система, по моим наблюдениям, параллельно из базы загружала номера домов на экране. Сейчас при скроллинге такого нет — скорость возросла.
Другой пример — моя компания разрабатывает приложение. Там есть окно со списком контактов с их картинками. Ранее при открытии этого окна одним поток и список хитрый отрисовывался, и данные с картинками подгружались. Были тормоза. Сейчас подкгрузку перенесли в отдельный поток — стало намного быстрее.
Возвращаясь к основной теме — ART вряд ли поможет совсем убрать тормоза вот в таких ситуациях, разве что уменьшить их.
В 2ГИС в предыдущих версиях во время скроллинга карты система, по моим наблюдениям, параллельно из базы загружала номера домов на экране. Сейчас при скроллинге такого нет — скорость возросла.
Другой пример — моя компания разрабатывает приложение. Там есть окно со списком контактов с их картинками. Ранее при открытии этого окна одним поток и список хитрый отрисовывался, и данные с картинками подгружались. Были тормоза. Сейчас подкгрузку перенесли в отдельный поток — стало намного быстрее.
Возвращаясь к основной теме — ART вряд ли поможет совсем убрать тормоза вот в таких ситуациях, разве что уменьшить их.
Буквально сейчас накатал на Nexus 7 2013 kitkat, переключился на среду исполнения Art. Да, у меня нет опыта в использовании устройств Apple, но субъективно скорость интерфейса стала выше, отклик при запуске приложений меньше и оперативная память освободилась где-то на 15%-20%. Общими словами стало гораздо комфортнее работать, хотя и раньше никаких раздражающих факторов не было — все же новый Nexus 7 довольно мощный компьютер. И да, никаких проблем в работе сервисов Google нет (разве что виртуальный принтер что-то не завелся, но это уже другое).
Кстати, теперь и в .NET появилась AOT компиляция dlang.ru/205-csharp-poluchit-aot-kompilyator
Интересно будет посмотреть на сравнение производительности решения из Java и .NET
Интересно будет посмотреть на сравнение производительности решения из Java и .NET
А её там не было? А ngen тогда что?
ART в действии.
Сейчас есть на руках трехгодичной давности аппарат HTC Sensation (2 ядра Coretx-A8 на 1.5 ГГц, 768 ОЗУб 1Гб ПЗУ). Стоит кастом с 4.4.2
Установлено приличное число приложений.
На Далвик приложения занимают 480 МБайт.
На ART приложения разрастаются до 785 МБайт. При этом визуально заметно сокращение времени загрузки приложений, они работаю более плавно (скролл экранов с большим числом элементов).
В Целом, ART — очень хорошее решение, особенно для маломощных аппаратов. Просто на топовых девайсах и на Далвик все летает. А вот когда насчтеу каждый мегафлоп системы, каждое увеличении скорости очевидно. Минус — требуется в полтора-два раза больше места во внутренней памяти, что как раз для бюджетных и старых аппаратов может доставить сложности.
Сейчас есть на руках трехгодичной давности аппарат HTC Sensation (2 ядра Coretx-A8 на 1.5 ГГц, 768 ОЗУб 1Гб ПЗУ). Стоит кастом с 4.4.2
Установлено приличное число приложений.
На Далвик приложения занимают 480 МБайт.
На ART приложения разрастаются до 785 МБайт. При этом визуально заметно сокращение времени загрузки приложений, они работаю более плавно (скролл экранов с большим числом элементов).
В Целом, ART — очень хорошее решение, особенно для маломощных аппаратов. Просто на топовых девайсах и на Далвик все летает. А вот когда насчтеу каждый мегафлоп системы, каждое увеличении скорости очевидно. Минус — требуется в полтора-два раза больше места во внутренней памяти, что как раз для бюджетных и старых аппаратов может доставить сложности.
Интерфейс — это прекрасно. И здорово, что Google этим занимается.
Печалит то, что они забивают на решение проблем с real-time применением их устройств. Например, вы не сможете подключить гитару через подобие iRig к Android-смартфону, запустить приложение-примочку и получить задержку ввода/вывода на уровне
Печалит то, что они забивают на решение проблем с real-time применением их устройств. Например, вы не сможете подключить гитару через подобие iRig к Android-смартфону, запустить приложение-примочку и получить задержку ввода/вывода на уровне
Сегодня была новость, что следующая версия Андроид уже окончательно перейдет на рантайм ART. Я пока не встречал приложений, который под ним бы не работали.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
ART идет на смену Dalvik