Pull to refresh

Comments 34

Продолжение ждал с нетерпением, уже думал что не выйдет! Спасибо, и пишите чаще :-)
ART использует AOT компиляцию

И HotSpot, и Dalvik, и ART дополнительно оптимизируют выполняемый код. Все три используют just-in-time compilation (JIT), то есть во время выполнения компилируют байткод в куски полностью нативного кода, который выполняется напрямую.

Да, я про это написал дальше:


Кроме того, ART может компилировать байткод в нативный код заранее, а не во время выполнения (ahead-of-time compilation)

До 7.0 Nougat ART не поддерживала JIT, только AOT (в отличие от Dalvik, который поддерживал только JIT), поэтому во многих статьях переход с Dalvik на ART описывали как переход с JIT на AOT. На самом деле это полностью новый рантайм с гораздо более продвинутой инфраструктурой для оптимизации; просто начали с реализации AOT, а потом реализовали и JIT, и, как они сами это называют, all-the-time.

В самых ранних версиях андроида (до 2.2) отсутствовал даже JIT, а его появление было большим событием.

Спасибо за статью. Хоть я и обладаю некоторым опытом в практической разработке под Андроид, но многое из написанного узнаю впервые.

Наконец то вторая часть, очень интересно. Будут ли подобные статьи про ios?

Спасибо!


Нет — к сожалению планов писать про iOS пока нет, но если вы интересуетесь, могу порекомендовать книгу Mac OS X and iOS Internals: To the Apple's Core, автор Jonathan Levin.

Спасибо большое.
Ну тогда ждем еще много статей про android

Кратко, структурированно, интересно. Буду с нетерпением ждать третью часть.
Круто! Ждал вторую статью, теперь подожду и третью.
На сколько статей рассчитан цикл?

Спасибо! У меня есть идеи для пяти статей (то есть ещё трёх), но может получиться и больше.

Действительно очень хорошая статья. Спасибо, жду продолжения! :)

Спасибо, очень интересно всё написано (хотя я и не разработчик). А как пользователя (ещё с ANdroid 1.6) меня крайне интересует, почему практически убрали в андроиде возможность устанавливать/переносить приложения на карту памяти.
С точки зрения безопасности данных приложений не вижу в этом смысла, ведь можно данные шифровать на случай кражи карты памяти.
С точки зрения возможного замедления работы приложений тоже проблем не вижу — загрузка приложения на 1 секунду дольше меня не напрягла бы, в отличие от того, что у меня в телефоне есть карточка на 32 Гб, а смартфон ругается, что ему не хватает памяти и нет возможности установить ещё хотя бы одно маленькое приложение.
Как вариант, остаётся только маркетинг (покупайте более дорогие телефоны с большим количеством встроенной памяти), но для самого Гугла и разработчиков это плохая практика — я не могу себе позволить купить некоторые платные приложения и игры не потому, что не хочу или у меня нет денег, а потому что понимаю, что мне их просто не установить наряду с теми, которые мне нужны постоянно.

Возможность устанавливать приложения на SD-карту никуда не убрали, но это opt-in со стороны приложения — по умолчанию installLocation="internalOnly". Да, при этом данные приложения помещаются в специальный зашифрованный asec-контейнер на карточке. Как написано в документации, это в основном актуально для больших игр.

Ну насколько я понял, это не только от разработчика зависит. Некоторые приложения на одних устройствах и прошивках переносятся на карту (но только частично), а на другом устройстве или с другой прошивкой уже не переносятся.
У меня на старом HTC Desire на Android 2.3.3 была прошивка, на которой приложения переносились на карту памяти полностью. В итоге было одновременно установлено под полторы сотни приложений и игр. Сейчас на Samsung J3 2016 я никак не могу найти прошивку, которая позволила бы делать то же самое. С приложениями типа Data2SD и с рутованными прошивками, через некоторое время карты памяти умирают или возникают постоянные ошибки — разделы карты внезапно теряются, приложения отваливаются и т.п. Пользоваться в нормальном режиме не получается.
через некоторое время карты памяти умирают или возникают постоянные ошибки — разделы карты внезапно теряются, приложения отваливаются и т.п. Пользоваться в нормальном режиме не получается.

Вот именно поэтому это и opt-in. Да, кастомные сборки могут насильно переносить приложение, даже если оно не рассчитано на то, что его части начнут внезапно отваливаться.

Вот в том то и дело. А на HTC в той прошивке всё работало абсолютно стабильно. И на x-pda постоянные вопросы в темах про прошивки именно про переносимость приложений. Т.е., людям это нужно. Почему по умолчанию в стандартной поставке андроида не сделать это включённым и нормально работающим?

Вроде несколько лет назад озвучивалась позиция отказа от sd, основная идея насколько помню защита от взлома приложений (в принципе та же причина что и отсутствие root по умолчанию), да при этом обычно говорят о защите пользователей но что-то подсказывает что дело в другом.

над ним работали такие люди, как Ken Thompson, Rob Pike, Dennis Ritchie, Brian Kernighan, Tom Duff, Doug McIlroy, Bjarne Stroustrup, Bruce Ellis и другие.

Не переводить спец. термины и названия — норма. Не переводить имена — моветон. В остальном, цикл статей великолепен. С нетерпением жду продолжения. Спасибо.

Я специально в этой серии статей почти везде пишу имена в оригинале — на мой взгляд, так получается лучше. Другими словами, не баг, а фича :)

Хм… вот какая мысль. Технологиий JIT и AOT известны достаточно давно. Почему никто до сих пор не реализовал идею: компилировать байт-код в нативный на этапе инсталляции приложения в систему и затем по требованию запускать уже скомпилённый код. Это же сэкономит кучу машинного времени за такую дорогостоящую операцию как запуск приложения.
Да, но тот обязательный AOT при установке аукнулся долгой установкой приложений (и их обновлений), и очень долгим процессом «оптимизации» всех установленных приложений при обновлении прошивки. Сейчас же (Android 7.0 и выше) получился универсальный вариант.
Погодите, в случает AOT — приложение компилируется в нативный код перед запуском, точнее перед передачей управления, например при старте системы. Если приложение выгружено из памяти, при повторном старте оно либо будет заново компилироваться, либо будет взято из некоего кеша (кеш тоже может протухнуть и быть почищен). Я же говорю о том, что приложения, включая системные, компилировать именно на этапе установки. Один раз скомпильнули и далее пользуемся только нативными бинарями.

AOT означает, что приложение компилируется до (ahead of) выполнения. Это можно делать сразу же при установке (и именно так это работало в Lollipop и Marshmallow) или в какое-то другое время между установкой и запуском (не обязательно прямо перед запуском; так это работает, начиная с Nougat). Новый способ заметно лучше старого — в том числе и потому, что позволяет потом перекомпилировать приложение с учётом данных профилирования.

Некоторые из разрешений существуют в виде GID, в которые приложение добавляется, когда получает это разрешение — например, получение разрешения ACCESS_FM_RADIO помещает приложение в группу media, что позволяет ему получить доступ к файлу /dev/fm. Остальные существуют только на более высоком уровне (в виде записей в файле packages.xml)


Подскажите пожалуйста, с чем связан такой зоопарк и есть ли планы в roadmap по сведению всего в единую систему? Или там что-то системное, что дает именно такое решение ситуации?

Почему зоопарк? С точки зрения разработчика приложений все разрешения выглядят и работают одинаково.


С точки зрения низкоуровневой реализации часть разрешений проверяется ядром (разрешение на доступ к сети, на доступ к файлам устройств, на доступ к файлам пользователя...), поэтому они должны быть экспортированы на уровень ядра в виде GID (в packages.xml они тоже записаны, конечно). Для остальных разрешений это не нужно и неудобно (при изменении GID приложение нужно перезапустить, что делается прозрачно для пользователя, но всё-таки лучше делать это реже).

Огромное СПАСИБО за статьи про внутреннюю кухню Андроида. Очень познавательно и жду, как и многие здесь, продолжения.
UFO landed and left these words here
Only those users with full accounts are able to leave comments. Log in, please.

Information

Founded
2015
Location
Россия
Website
rt-solar.ru
Employees
201–500 employees
Registered

Habr blog