П'ять стовпів Android. Технології, що лежать в основі найпопулярнішою ОС

1. Зміст статті Існує як мінімум п'ять технологій, які роблять Android саме тим, чим ми звикли його...
2. Варіант 2. Відкрий один матеріал

Зміст статті

Існує як мінімум п'ять технологій, які роблять Android саме тим, чим ми звикли його бачити: віртуальна машина, система багатозадачності, сервіси Google, IPC-механізм Binder і ядро ​​Linux. Кожна з цих підсистем має свою історію розвитку, свої причини появи і наділяє Android властивими йому широкими можливостями. Ми в подробицях поговоримо про кожну з них і покажемо, чому Android - це щось набагато більше, ніж мобільна ОС.

Прийнято вважати, що в основі Android лежить Java. Мовляв, саме тому ОС така вимоглива до процесора і оперативної пам'яті. Насправді все набагато складніше. Java (а тепер і Kotlin) - це дійсно офіційна мова Android. Але Java - це не тільки мова, але і середовище виконання.

У випадку звичайної Java, розробленої компанією Sun (тепер уже Oracle), додатки компілюються в спеціальний проміжний байт-код, який потім виконує віртуальна машина. Найбільш ранні версії віртуальної машини робили це шляхом інтерпретації: ВМ читала байт-код, аналізувала записані в ньому інструкції і виконувала їх.

Це повільний метод виконання (на кожну інструкцію ВМ могли йти десятки і сотні машинних інструкцій), тому пізніше з'явився так званий JIT-компілятор (Just In Time compiler). З його допомогою віртуальна машина могла на льоту переганяти байт-код в машинні інструкції, що істотно підняло швидкість його виконання, але підвищило витрата оперативної пам'яті: в пам'яті тепер необхідно зберігати не тільки байт-код, а й отримані з нього машинні інструкції плюс метадані, що дозволяють виконувати оптимізації.

Крім того, при розробці віртуальної машини Джеймс Гослінг вирішив використовувати стековий дизайн віртуальної машини, як простий і універсальний. Але існує більш ефективний в швидкості виконання байт-коду і споживання оперативної пам'яті дизайн віртуальної машини - регістровий.

Саме така реєстрова віртуальна машина (під назвою Dalvik) використовувалася в перших версіях Android. Завдяки відсутності JIT-компілятора вона була дуже невибагливої ​​до оперативної пам'яті, а реєстровий дизайн дозволяв виконувати додатки досить швидко навіть в режимі інтерпретації.

Середовище розробки Android компілює код Java в байт-код JVM, але потім конвертує його в байт-код Dalvik

Однак в Android 2.2 Google все-таки реалізувала JIT-компілятор і довго хвалилася графіками багаторазового приросту продуктивності. На ділі ж швидкість зросла незначно, все самі вимогливі до ресурсів API Android і так були реалізовані на C ++, який виконувався безпосередньо на процесорі. Майже всі великовагові гри також використовували код на C / C ++ та інших компільованих в машинні інструкції мовами.

В Android 5.0 Google пішла ще далі і замінила Dalvik на AOT-компілятор (Ahead Of Time compiler) під назвою ART. В теорії такий компілятор дозволяє позбутися від віртуальної машини як сутності і переводити додаток в машинні інструкції ще на етапі установки. На ділі ж виходило так, що не весь байт-код можна було одним махом конвертувати в інструкції процесора, і результуючий код міг містити як машинні інструкції, так і байт-код старого доброго Dalvik. І з усією цією мішаниною продовжувала розбиратися віртуальна машина.

AOT-компілятор також програвав JIT-компілятор в можливостях оптимізації машинного коду. У нього просто не було достатньо інформації про поведінку програми та особливості його роботи; її можна було отримати, тільки запустивши додаток. І він істотно уповільнював установку додатків і перший запуск операційної системи.

Щоб це виправити, в Android 7 Google вирішила використовувати гібридний JIT / AOT-компілятор. Відразу після установки додаток виповнюється з використанням JIT-компілятора, але під час роботи від зарядки смартфон переганяє додаток в машинні інструкції з допомогою AOT-компілятора, який може враховувати інформацію, накопичену в процес виконання програми.

А тепер питання: навіщо Google потрібні були всі ці заморочки з Java і віртуальними машинами, коли можна було піти по шляху Apple і використовувати звичайний, компільований в машинні інструкції мову, який не страждає від проблем з жором оперативки і продуктивності?

Відповідей на це питання як мінімум два.

1. Портабельная. Пам'ятаєш слоган Java: «Написано один раз - працює скрізь»? Але ж це не маркетинговий булшіт, це чиста правда. Ти можеш завантажити будь-коли-небудь написане на Java програма і запустити його на будь-який повноцінної віртуальної машині Java незалежно від операційної системи, архітектури процесора і фази місяця. Воно просто працює.

   Тим же принципом керувалися розробники Android. Неважливо, на якому процесорі заснований смартфон, неважливо, смартфон це чи телевізор. Додаток, написаний для Android, буде на ньому працювати без всяких Перекомпіляція і модифікацій (якщо, звичайно, воно не використовує машинний код на C / C ++).

   Мало того - розробнику навіть не потрібно замислюватися про підтримку більш ефективних інструкцій, що з'явилися в нових процесорах, за нього це зробить віртуальна машина.

2. Надійність. Java - це високорівнева мова зі складальником сміття, що не дозволяє адресувати пам'ять безпосередньо і не вимагає самостійного звільнення виділеної пам'яті. Це означає, що багато типів атак, включаючи buffer overflow і use after free, проти додатків на Java не можуть бути реалізовані. В крайньому випадку віртуальна машина просто вб'є додаток (як це нерідко відбувається при виході за межі масиву, наприклад). Саме тому в Android в цілому знаходять менше вразливостей, ніж в iOS, повністю написаною на небезпечних мовах C, C ++ і Objective-C. І це одна з причин, чому Apple знадобився мову Swift, на якому вона почала переписувати компоненти ОС і стокові додатки.

3. Популярність. Java - один з найпопулярніших мов у світі, тому у Android-розробників спочатку був доступ до величезної кількості Java-бібліотек і сніпетів, коду, які можна задіяти в додатку.

Підводячи підсумок: Java і віртуальна машина були правильним вибором. І хоча зараз набирає обертів мову Kotlin, він повністю сумісний з Java на рівні байт-коду. А це означає, що для його підтримки на стороні ОС не потрібно робити нічого. Додатки просто працюють.

Продовження доступно тільки учасникам

Варіант 1. Приєднайся до товариства «Xakep.ru», щоб читати всі матеріали на сайті

Членство в співтоваристві протягом зазначеного терміну відкриє тобі доступ до ВСІХ матеріалами «Хакера», збільшить особисту накопичувальну знижку і дозволить накопичувати професійний рейтинг Xakep Score! Детальніше

Варіант 2. Відкрий один матеріал

Зацікавила стаття, але немає можливості стати членом клубу «Xakep.ru»? Тоді цей варіант для тебе! Зверни увагу: цей спосіб підходить тільки для статей, опублікованих більше двох місяців тому.