От: | Serginio1 | https://habrahabr.ru/users/serginio1/topics/ | |
Дата: | 10.09.21 07:23 | ||
Оценка: | 3 (2) |
Вместо того, чтобы запускать AOT-компиляцию каждого приложения на этапе установки, он запускает приложение под управлением виртуальной машины, используя JIT-компилятор (почти так же, как в Android < 5.0), но следит за тем, какие участки кода приложения выполняются чаще всего. Затем эта информация используется для AOT-компиляции данных участков кода. Последняя операция выполняется только во время бездействия смартфона, находящегося на зарядке.
Говоря простыми словами, теперь два совершенно разных подхода работают сообща, что дает свои плюсы:
более эффективная компиляция — при запуске приложения в реальном времени компилятор имеет возможность узнать о его работе гораздо больше, чем выполняя статический анализ, и, как следствие, применяются более подходящие методы оптимизации для каждой ситуации;
сохранение оперативной и постоянной памяти — байт-код компактнее машинного кода, а если выполнять AOT-компиляцию только отдельных участков приложения и не выполнять компиляцию приложений, которыми юзер не пользуется, можно существенно сэкономить пространство NAND-памяти;
резкое увеличение скорости установки и первой загрузки после обновления системы — нет AOT-компиляции, нет задержки.
В статье не говорится, почему вернулись к схеме Interpreter+JIT+AOT. Основная проблема с AOT была, что при любом изменении системы приходилось перекомпилировать все библиотеки и приложения, что могло занимать много времени. При переходе на Interpreter+JIT+AOT одним из критериев был не ухудшение времени запуска. После перехода выяснилось, что не весь код приложений нужно компилировать.
Ключевой характеристикой формата файла является устойчивость к версиям. Это означает, что обновление зависимости совместимым способом не приведет к аннулированию скомпилированного кода AOT. Это позволяет ему вести себя аналогично формату файла IL (ECMA-335) при составлении и обслуживании приложений, который является очень гибким и простым для понимания. Предыдущие версии .Форматы файлов NET AOT, такие как формат файла, используемый NGen в .NET Framework, не обладали этим свойством.
Существует также преимущество по сравнению с наиболее оптимальным скомпилированным кодом на C++ – возможность улучшать сгенерированный код во время выполнения с помощью JIT, например, путем оптимизации для конкретной архитектуры процессора или встроенного кода из других сборок, которые не были известны во время компиляции.