Pull to refresh

Comments 14

Довольно странный они применили подход: сократили что-то на однократном действии (установке), но зато ухудшили на многократном действии (запуск). Да еще и от запуска пользователь ждет оперативность и экономный расход батареи, а вот от установки такого не ждут — все равно, дольше ли она на минуту или нет.
Я бы сказал, это пример, как не надо делать :)
В статье не говорится, почему вернулись к схеме Interpreter+JIT+AOT. Основная проблема с AOT была, что при любом изменении системы приходилось перекомпилировать все библиотеки и приложения, что могло занимать много времени. При переходе на Interpreter+JIT+AOT одним из критериев был не ухудшение времени запуска. После перехода выяснилось, что не весь код приложений нужно компилировать.

В ART применяется многократная AOT перекомпиляция кода в зависимости от изменения профиля исполнения. Кроме того Google Play может предоставлять некий профиль исполнения приложения, который учитывается при установке приложения.

В Android 10 и 11 случился APEX. Теперь ART может обновлять через Google Play, если производитель телефона поддерживает эту функцию.
А какое например изменение системы требовало перекомпиляции всех библиотек и приложений? Этот момент не понятен.
 Например исправили security bug в Java core или framework библиотеках. Насколько я помню любое изменение в системных компонентах требовало перекомпиляции всех приложений, но могу и ошибаться.
Не ошибаетесь. Изменение любого jar-файла в директории /system/framework, и при следующей загрузке жди минут 10 окошко «Android is optimizing» (актуально во времена Android 5/6, сейчас уже быстрее проходит)
Кстати, в ART JIT-компилятор и AOT-компилятор — это один и тот же компилятор, который запускают либо в режиме JIT или AOT. AOT-компилятор можно запустить через утилиту dex2oat.
А почему нельзя компилировать прям на сервере и просто отдавать нужный бинарник под нужную архитектуру? Ведь AOT как раз всё равно собирал бинарник во время установки приложения. Ведь Apple так и делает, в стор заливается fat binary и потом просто раздают нужную архитектуру в зависимости от клиента, а на клиенте уже подтягиваются системные зависимости во время запуска приложения.
Это затруднительно сделать в силу большого разнообразия версий Android и производителей телефонов.
В андроиде сейчас так же. В Google Play заливается .aab вместо .apk, Google Play из него собирает .apk под разные архитектуры. (Еще не все разработчики уже перешли на .aab, но большинство уже перешли) Таким образом размер скачиваемого файла при установке существенно уменшается. А потом .oat файлы скомпилированые на устройстве отправляются на сервер и следующий смарфон (с такой же архитектурой, языком смартфона, размером экрана и т.д.) уже скачивает готовые .oat файлы, только они уже занимают буквально несколько МБ
Интересно, а что с подписью? Раньше разработчик подписывал apk, и гугл передавал клиентам файл без изменений. Теперь надо свои ключи отдавать гуглу на переподпись, или подпись разработчика заменяется на подпись маркета?
Да, ключ надо отдать гуглу. Но каждый .aab все равно надо подписывать, гугл так проверяет подлинность. Но теперь появилась возможность заменить ключ, например если потеряли/удалили или если хочется перейти на криптографически более надежный ключ.
При замене ключа, старый ключ будет использоватся для пользователей у которых уже установлено приложение, а для новых установок и их обновлений будет использоваться новый ключ.
Но замена ключа доступна только один раз для каждого приложения.
Спасибо, очень классная статья. Буду советовать ее студентам :)
Спасибо, рад, что материал оказался полезным.
Желающим также можно порекомендовать почитать embedded android by karim yaghmour. В публичных источниках её много. Книга небольшая, но весьма понятная. На английском, ну да специалистам не привыкать. В книге используется менеджерский подход к рассмотрению принципов построения. Читал сам, нашёл полезным, счёл нужным поделиться.
Only those users with full accounts are able to leave comments. Log in, please.