- Dalvik работеше, използвайки JIT компилация, превеждайки кода, докато приложението работеше.
- ART оптимизира системата, като използва AOT компилация, изпълнявайки процеса по време на инсталацията.
- И двете среди използват DEX файловия формат, което осигурява съвместимост между версиите.
- Преходът към ART намали консумацията на батерия и подобри плавността на системата.
Ако някога сте се чудили какво всъщност се случва „под капака“ на телефона ви, когато отворите приложение, отговорът се крие в средата за изпълнение. В екосистемата на Android преминахме от архитектура, базирана на виртуалната машина Dalvik, към много по-стабилна система, наречена Android Runtime, по-известна като ART. По същество ART е отговорна за преобразуването на кода, който програмистите пишат, в инструкции, които хардуерът на вашето устройство може да разбере, без да се сриват.
За да разберете това, е важно да знаете, че Android не работи с Java директно; вместо това използва персонализирана адаптация . Всичко започва с изходния код, който се трансформира в байткод и завършва в специфичен формат, наречен DEX. В зависимост от това дали вашата версия на Android е по-стара или по-нова, пътят, който този код поема, за да се изпълни, се променя драстично, което влияе на ежедневни неща като живота на батерията и скоростта на зареждане на приложенията.
Наследството на Далвик: Ерата на „точно навреме“
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 използва RAM памет, която пагинацията е възможна, оптимизирайки използването на хардуер.
Процесът на опаковане: От код до APK
За да работи която и да е от тези среди, кодът трябва да премине през поточна линия. Първо, компилаторът на Java създава .class файлове, които инструментът dex след това преобразува в един файл classes.dex. Този файл е ядрото на APK и е това, което ART или Dalvik ще обработят.
Инструменти като aapt се използват за пакетиране на ресурси, а zipalign оптимизира подравняването на данните, като гарантира, че процесорът осъществява достъп до паметта възможно най-ефективно. След като APK файлът достигне устройството, се случва магията: ако има ART, се генерира ELF файл ; ако има Dalvik, ODEX файлът започва да се генерира в движение.
Интересни факти за ROM-овете и процеса на декодиране
В света на персонализираните ROM-ове, термините odex и deodex са често използвани . Тъй като ODEX файлът е хардуерно зависим и зависи от точната система, където е създаден, той не може лесно да бъде прехвърлен от един телефон на друг. За да модифицират приложение, без да доведат до срив на системата, разработчиците извършват процес на деодексиране , който включва интегриране на оптимизирания файл в APK файла, за да се улесни манипулирането му.
Екосистемата на Android еволюира от гъвкава, но енергоемка виртуална машина до оптимизирана среда за изпълнение, която дава приоритет на потребителското изживяване. Докато Dalvik се фокусира върху гъвкавостта на преобразуването на код в реално време, ART увеличи максимално използването на хардуера чрез предварителна компилация , гарантирайки, че софтуерът е по-стабилен, по-бърз и по-енергийно ефективен.
Индекс