Чи швидше програми для iOS швидше, ніж програми для Android, оскільки інтерпретуються додатки для Android?


31

Програми для Android інтерпретуються, а не компілюються. Це робить їх повільніше, ніж додатки для iOS під час виконання?


14
Це не гарне запитання, оскільки додатки для Android не інтерпретуються так, як насправді вказується правильна відповідь.
Aaronaught

2
Зазвичай прийнята відповідь не є найкращою відповіддю - це не надто велика проблема, оскільки мета - допомогти тому, хто задав питання (див. Цей мета-пост). Але це досить крайній випадок @ArmonSafai Відповідь, яку ви вибрали як правильну, сповнена дезінформації, і минула точка, коли можна виправити правки. Подумайте про вибір іншої відповіді.
Selali Adobor

Зауважте, що деякі великі корпорації - включаючи IBM - пишуть основні програми на Java сьогодні. Враховуючи компілятор Just-In-Time (JIT), який є стандартною частиною сучасної Java VM, продуктивність дійсно порівнянна з будь-якою іншою мовою високого рівня. Java вже багато років не є лише "інтерпретованою мовою".
keshlam

Компілятори JIT взагалі не пов'язані з концепцією JVM. Є JVM, які не використовують компілятори JIT, навіть комерційні. Деякі варіанти JVM IBM не включають JIT за замовчуванням, натомість за замовчуванням до компіляції AOT. Крім того, невелика примітка: "основні програми на Java в ці дні", ймовірно, були трохи придатнішими півтора десятиліття тому (IBM додавали в Java до 1997 року)
Selali Adobor

Питання дещо оманливе. "Народний" додаток для iOS пишеться в Objective-C (або Swift) і компілюється, тоді як "стандартний" додаток для Android пишеться на Java та збирається в байт-код. Дивіться відповідь @ DanHulme. Але можна писати програми для будь-якої платформи в HTML та JavaScript, використовуючи, наприклад, PhoneGap / Cordova. Як правило, сприймається додаток HTML, що він працює повільніше, ніж рідний додаток на тій же платформі. Тож якщо подібний додаток для «іншої» платформи здається повільнішим, можливо, це тому, що він був створений за допомогою іншої технології.
Девід

Відповіді:


85

Java не інтерпретується на Android. Програми для Android складаються в байт-код розробником. Байт-код - це компактне представлення програми: менше, ніж вихідний код, написаний програмістом, але все ще не виконується безпосередньо процесором. На цьому етапі можуть бути зроблені деякі оптимізації, такі як видалення мертвого коду.

Коли ви завантажуєте додаток на пристрій, Dalvik JVM компілює байт-код до власного виконуваного коду так само, як він збирається запустити. Це просто своєчасна збірка. Це спричиняє коротке уповільнення, поки програма чекає її складання, але після цього не виникає накладних витрат, тому що код був зібраний у вихідний виконуваний код.

Є деякі переваги в продуктивності, якщо це зробити таким чином, а не складати на комп’ютері розробника. Додаток можна скласти для конкретного процесора на телефоні, скориставшись його апаратними можливостями та використовуючи його експлуатаційні характеристики. Наприклад, він може використовувати апаратні операції з плаваючою комою, якщо ЦП підтримує його. Крім того, розумний компілятор JIT (правда, Далвік не зовсім такий розумний) може стежити за тим, як працює програма, та проводити оптимізацію на основі способу використання програми в реальному використанні. Він може перекомпілювати код із кращим натяком на гілки, як тільки побачить, які варіанти включаються та вимикаються у вашому оточенні, на вашому телефоні. Передній компілятор не використовує цю інформацію.

Dalvik використовує кеш Dalvik та інші методи, щоб зменшити недоліки компіляції JIT. Новий JVM для Android L та новіших версій ART замінює JIT повністю компілятором заздалегідь . Це компілює байт-код до власного виконуваного коду, коли програма встановлена, щоб отримати більшість переваг JIT без затримки завантаження програми.

Не забувайте, що додатки для Android не повністю складаються з Java. Розробники мають NDK писати всі або частину своїх додатків на C або C ++ для критично важливих для роботи частин програми, особливо для ігор. Інтерфейси спеціального призначення, такі як OpenGL та Renderscript, дозволяють програмістам скористатися спеціальним обладнанням, таким як GPU та SIM-копроцесор для деяких видів обчислень.

Тож справді, простої відповіді на ваше запитання немає. Використання JIT замість передової компіляції робить деякі речі швидшими, а інші - повільнішими. Це лише одна частина загальної продуктивності ОС.


1
+1 за велике пояснення. Я насправді чекав такої відповіді.
MANI

5
Не сильно відрізняється від стомленої старої ".NET / Java проти C ++" дискусії на ПК, насправді. Це яблука та апельсини.
Aaronaught

1
@ArmonSafai Це так.
Dan Hulme

2
@MTilsted: Це частково вірно, але він кешируєт майже все, так що ви говорите, швидше за все , тільки в тому випадку найперший раз , коли ви запускаєте додаток.
Aaronaught

1
Головною проблемою тут є те, що Далвік - це "звичайний" СВМ. Між тим, що базується на регістрі, на відміну від стека на основі HotSpot (через природу процесорів ARM проти тих HotSpot, націлених на нього [наприклад, IA32]), це використання Zygote та концепція файлів odex (тобто вся ідея не [більш-менш] переходячи безпосередньо з файлу класу до завантажувача класів), трактування Dalvik як звичайного JVM неодмінно може призвести до деяких помилок. Тим більше, що багато деталей реалізації HotSpot часто помилково асоціюються з JVM (як-от компілятор JIT).
Selali Adobor

2

Оскільки це питання широке, ось широка відповідь.

"Чи швидше програми для iOS швидше, ніж для Android, оскільки інтерпретуються додатки для Android?"

По-перше, додатки для iOS не є швидшими, ніж для Android.

По-друге, щодо проблеми "Програми для Android тлумачать". Це те, що ви б сказали про обчислення, як, наприклад, "15 років тому": як видно з обговорення вище, ситуація сьогодні набагато складніша; абсолютно нові технології вийшли на перший план. Поняття "складено швидше, ніж інтерпретується!" Ви знаєте, порівнявши, знаєте, perl з машинним кодом 20 років тому; все змінилося настільки багато, що питання не може бути дійсно чітко застосовано до "iOS V Android" сьогодні.

По-третє, є інші проблеми в мобільному програмуванні, які повністю заглиблюють такі міркування. Лише один із прикладів, що програмують мобільні програмісти, які працюють над великими прокручуваними списками зображень, ледачим завантаженням тощо. Як обидві ОС, так і різні популярні бібліотеки вирішують ці найважливіші проблеми, часто переповнюють інші проблеми.

По-четверте, ще одна надзвичайна проблема щодо мобільних телефонів - це питання графічного чіпсету та різні складні взаємозв'язки, які стосуються програмного забезпечення, OpenGL тощо. Наприклад, Apple виходить із системою, яку вони називають "Метал" у зв'язку з цими проблемами, а Android виходить із власною "річчю" в цій галузі. Ці проблеми навколо графічного конвеєра надзвичайно важливі для того, як програми "почуваються" у вашій руці.

Дуже коротка відповідь на ваше запитання "складений В. інтерпретований" - це в основному застарілий дискусійний пункт, який ви знаєте?

(Крім того, я особливо не вважаю Note3 "повільнішим", ніж iPhone. Крім того, дещо з цього є чистим артефактом - існують недорогі телефони Android: просто не зроблено iPhone з низькою продуктивністю, тому деякі люди можуть мати неправильні ідеї з цього.)


-3

Оскільки інтерпретовані програми не означають, що вони завжди повільні. Іноді вони більш потужні та динамічні порівняно зі складеним. Оскільки всі коди в компільованому додатку збираються один раз, а вихід зберігається у формі бібліотек або виконуваних файлів, тоді як на інтерпретованій мові можна один раз випадково змінити послідовність виконання. Тож я можу сказати, це залежить від розробника до розробника і є спосіб програмування.

Однак Java (мова програмування Android) не інтерпретується, а компілюється JIT. Це означає, що програми Android збираються безпосередньо перед їх запуском, даючи досить схожі показники з iOS 'Objective C.

З недавніх пір система Android ART заздалегідь збирає програми, тому вони запускаються так само, як програми iOS. Іншими словами, наступна версія Android, мабуть, буде настільки ж швидкою, як iOS.

Оновлення

Мови програмування, як правило, підпадають під одну з двох категорій: Складено або Інтерпретовано. За допомогою компільованої мови код, який ви вводите, зводиться до набору інструкцій, визначених для машини, перед тим як зберігати їх як виконуваний файл. З інтерпретованими мовами код зберігається у тому ж форматі, який ви ввели.Скомпільовані програми зазвичай працюють швидше, ніж інтерпретовані, оскільки інтерпретовані програми повинні бути зведені до машинних інструкцій під час виконання. Однак з інтерпретованою мовою ви можете робити речі, які неможливо зробити на компільованій мові. Наприклад, інтерпретовані програми можуть змінювати себе, додаючи або змінюючи функції під час виконання. Також зазвичай простіше розробляти програми в інтерпретованому середовищі, оскільки вам не доведеться перекомпілювати програму щоразу, коли ви хочете протестувати невеликий розділ.


1
що ти маєш на увазі "раз можна випадковим чином змінити послідовність страти? І як вони більш потужні та динамічні? Також я не кажу, що вони повільні, тільки що вони повільніші, навіть трохи.
Armon Safai

3
Це не зовсім так. Неправильно сказати, що не потрібно перекомпілювати - це перевага, оскільки вам все одно потрібно створити файл APK і розгорнути його на тестовий пристрій. Google не вирішив використовувати Java: Android вже існував на базі Java, перш ніж Google її купила. Файли APK не містять код "у тому ж форматі, що і [програміст], що вводиться."
Дан Хулм

1
Microsoft .NET компілюється до коду IL, який також інтерпретується так само, як java збирається в байт-код.
Есбен Сков Педерсен

12
Багато інформації у цій відповіді насправді не є актуальною або технічно правильною. Я б чесно запропонував цю відповідь повністю переглянути для технічної точності.
Аза

2
Як правило, Java не є інтерпретованою мовою , якщо ви не маєте справу з незвичайною реалізацією JVM. Компіляція JIT - це не те саме, що і інтерпретатор, тому більша частина цієї відповіді є чесно неактуальною в контексті продуктивності Android, оскільки вона використовує JIT.
eldarerathis
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.