- Dalvik працював за допомогою JIT-компіляції, перетворюючи код під час роботи програми.
- ART оптимізує систему за допомогою компіляції AOT, виконуючи цей процес під час встановлення.
- Обидва середовища використовують формат файлу DEX, що забезпечує сумісність між версіями.
- Перехід на ART зменшив споживання енергії батареї та покращив плавність роботи системи.
Якщо ви коли-небудь замислювалися, що насправді відбувається «під капотом» вашого телефону, коли ви відкриваєте програму, відповідь криється в середовищі виконання. В екосистемі Android ми перейшли від архітектури, заснованої на віртуальній машині Dalvik, до набагато надійнішої системи під назвою Android Runtime, більш відомої як ART. По суті, ART відповідає за перетворення коду, який пишуть програмісти, в інструкції, які апаратне забезпечення вашого пристрою може зрозуміти без збоїв.
Щоб зрозуміти це, важливо знати, що Android не запускає Java власноруч; натомість він використовує власну адаптацію . Все починається з вихідного коду, який перетворюється на байт-код і закінчується у певному форматі під назвою DEX. Залежно від того, чи є ваша версія Android старішою чи новішою, шлях виконання цього коду кардинально змінюється, впливаючи на повсякденні речі, такі як час роботи від батареї та швидкість завантаження програм.
Спадщина Dalvik: ера «точно вчасно»
Dalvik був фундаментальним стовпом з самого початку розвитку Android. Його мета була чіткою: дозволити програмам, написаним на Java, запускатися на пристроях з дуже обмеженими ресурсами . На відміну від стандартної віртуальної машини Java, Dalvik був оптимізований для використання менше пам'яті та одночасного запуску кількох екземплярів, делегуючи управління потоками ядру Linux.
Ключовою особливістю Dalvik була компіляція Just-In-Time (JIT) . Це означало, що код перекладався на машинну мову саме тоді, коли користувач взаємодіяв із додатком. Щоб уникнути повторення цього виснажливого завдання щоразу, Dalvik створив файли під назвою ODEX (Оптимізований DEX) , які зберігали вже перекладені частини в кеші. Проблема полягала в тому, що цей постійний процес компіляції споживав цикли процесора і, отже, використовував більше енергії.
Android Runtime (ART): Стрибок до випередження часу
Починаючи з Android 5.0 Lollipop, ART повністю взяв на себе ініціативу. Велика різниця полягає в тому, що ART реалізує компіляцію Ahead-Of-Time (AOT) . Замість того, щоб чекати на відкриття програми, ART виконує важку роботу під час встановлення. Він використовує інструмент під назвою dex2oat для перетворення DEX-файлів у виконувані файли ELF (Executable and Linkable Format), які є рідними для Linux.
Завдяки такому підходу, коли ви торкаєтеся значка програми, системі не потрібно нічого компілювати; вона просто зчитує ELF-файл і виконує його. Це означає, що процесор працює менше, акумулятор працює довше , а програми працюють набагато плавніше. Однак є невеликий компроміс: встановлення програм займає трохи більше часу і вони займають більше місця, ніж у випадку з Dalvik.
Технічне порівняння та ключові покращення
Хоча обидва середовища сумісні та використовують один і той самий байт-код DEX, ART впровадила покращення, які роблять систему неймовірно швидкою. Одним із найважливіших є збирання сміття (GC) . У Dalvik збирач сміття раніше спричиняв ці надокучливі паузи або «заїкання» в інтерфейсі (сумнозвісне затримування). ART переробила це з переважно паралельною системою , зробивши паузи незалежними від обсягу використаної пам'яті.
- Розширене налагодження: ART дозволяє розробникам бачити, які блокування утримуються потоками, та відстежувати екземпляри класів з набагато більшою точністю.
- Точні діагнози: Тепер, коли програма виходить з ладу, звіти про помилки набагато детальніші, особливо у випадках NullPointerException.
- Керування пам'яттю: На відміну від Dalvik, який використовував несторінковий кеш, ART використовує оперативну пам'ять, яка можлива пагінація, оптимізуючи використання апаратного забезпечення.
Процес пакування: від коду до APK
Щоб будь-яке з цих середовищ працювало, код має пройти конвеєр. Спочатку компілятор Java створює файли .class, які потім інструмент dex перетворює в один файл classes.dex. Цей файл є ядром APK, і саме його оброблятимуть ART або Dalvik.
Такі інструменти, як aapt, використовуються для пакування ресурсів, а zipalign оптимізує вирівнювання даних, забезпечуючи максимально ефективний доступ процесора до пам'яті. Щойно APK досягає пристрою, відбувається диво: якщо є ART, генерується файл ELF ; якщо є Dalvik, файл ODEX починає генеруватися на льоту.
Цікаві факти про ПЗП та процес декодування
У світі користувацьких ПЗУ зазвичай використовуються терміни odex та deodex . Оскільки файл ODEX залежить від апаратного забезпечення та точної системи, на якій він був створений, його не можна легко перенести з одного телефону на інший. Щоб змінити програму без збою системи, розробники виконують процес деодексування , який передбачає інтеграцію оптимізованого файлу в APK для полегшення його маніпуляцій.
Екосистема Android еволюціонувала від гнучкої, але енергоємної віртуальної машини до оптимізованого середовища виконання, яке надає пріоритет користувацькому досвіду. У той час як Dalvik зосереджувався на універсальності перетворення коду в режимі реального часу, ART максимізував використання апаратного забезпечення за допомогою попередньої компіляції , забезпечуючи стабільнішу, швидшу та енергоефективнішу роботу програмного забезпечення.