Чи використовує Android або Java більше енергії, оскільки вона працює на віртуальній машині?

Оскільки програми Android працюють на JVM (Dalvik VM), який в основному є віртуальним процесором, і кожна віртуальна інструкція повинна бути віднесена до основної інструкції чіпсета, чи це відображення призводить до більшого споживання енергії за рахунок витрат на це відображення?

Це питання можна поширити на Java, а також викласти так, як «додатки Java використовують більше енергії?». Ось чому телефони Android мають такий жахливий час роботи акумулятора порівняно з іншими платформами / телефонами?

Редагувати : На підставі відповідей я уточнив кілька моментів, тому що помилково говорив про JVM та Дальвік взаємозамінно. У цьому біті я говорю лише про Java, щоб запитати, чи використовує вона більше енергії, і якщо так, чи це концептуально стосується і Android, і чи призводить це до скорочення часу автономної роботи.

Контекст : цитується з Вікіпедії:

1. Байт-код Java є аналогом мови складання для коду С.
2. З точки зору компілятора, віртуальна машина Java - це ще один процесор з набором інструкцій, байт-код Java, для якого можна сформувати код.
3. JVM має архітектуру стека. Dalvik - це віртуальна машина процесу, яка не є типом віртуалізації, як JVM і має архітектуру реєстру.

Оскільки мова програмування Java збирається у байт-код (схожий на збірку) і працює на віртуальному процесорі, вона забезпечує справжню мобільність програмного коду. Крім того, оскільки існує JVM для Linux, а Linux переноситься на відкрите обладнання, комбінація може забезпечити справжню мобільність додатків у всьому стеку.

Харчування : Питання по суті зводиться до цього - для того ж набору функціональних можливостей вашого програмного коду чи програми, який відсоток ваших тактових циклів процесора віднесено до середовища часу запуску. Це пов'язано з середовищем компіляції Just-In-Time сучасних JVM, де якщо байтовий код компілюється в основну інструкцію чіпсету, то час виконання повинен бути активним лише під час компіляції jit. Отже, скільки більше тактових процесорних процесорів використовується в умовах виконання робочого часу, який, як очікується, призведе до надмірних витрат енергії. Мене цікавить лише аспект споживання енергії, а не відносна продуктивність порівняно зі статично набраними та вбудованими мовами та розумію переваги Java. Підпитання, які можуть бути пов'язані:

• Чи використовує час запуску Java функцію libc для своєї функціональності?
• Чи перераховано будь-який із цих споживаних енергоспоживачів DalM VM та Android?
• Замість того, щоб узагальнювати низьке споживання батареї Android, не кажучи про екран і бездротові чіпсети - давайте поговоримо про те, як iPhone 5 має 1440 мАг акумулятор, який є мінімальним порівняно з сучасними телефонами Nexus. Весь цей потяг думок (Java, віртуальний процесор, відображення інструкцій, Android) виник, тому що друг-лояліст iphone стверджував, що це може бути причиною того, що його iphone має кращий ресурс акумулятора, ніж мій (дивовижний) зв’язок.

У будь-якому випадку, дякую за відповіді нижче.

Ваше запитання ґрунтується на багатьох хибних припущеннях. Дозвольте спробувати їх очистити:

• Ви сказали "JVM (Далвік В.М.)". Це як сказати "Літак (велосипед)". Ці дві речі абсолютно не мають нічого спільного.

• Ви сказали, "... що в основному є віртуальним процесором". Просто неправдиво. Це не так, що кожен раз, коли слова "віртуальна машина" або абревіатура "VM" вживаються в технічному контексті, це по суті еквівалентно робочій станції VMware . Це відбувається тому, що такі продукти, як VMware , насправді емулюють цілий комп'ютер, а не лише процесор, а операційна система працює над іншою операційною системою. Далвік В.М. не працює так. Навіть близько не.

• Java - це просто мова програмування. Це синтаксис. Програми Android / Dalvik використовують той самий або дуже подібний синтаксис до абсолютно незв'язаної мови програмування робочого столу / сервера під назвою Java, яка працює на віртуальній машині Java. Теоретично, ви можете написати код Java, який має майже таку ж швидкість, як і код C, оскільки вони обидва мови програмування високого рівня. Чорт у деталях реалізації бібліотеки називає і те, як розроблено час виконання, що має дуже мало спільного з синтаксисом мови.

• Можна сказати, що Dalvik VM, JVM Sun Java Hotspot JVM або синтаксис мови програмування Java є надмірним узагальненням. Причина в тому, що вам доведеться порівнювати все, про що ви говорите, з виконанням чогось іншого . У найзагальнішому випадку, коли ви просто порівнюєте можливості "найкращого випадку" обох платформ, в принципі можна зробити додатки Dalvik, які є настільки ж швидкими або швидшими, ніж програми на будь-якій іншій платформі. Крім автоматичного управління пам'яттю та компіляції JIT - функцій, які є стандартними майже у всіх програмуючих середовищах в наші дні, в тому числі на iOS та JavaScript / HTML5 - є дуже мало, що відокремлює Dalvik від Objective-C, .NET, Ruby, Oracle Hotspot JVM, Python тощо.

• Сприйняття того, що "Java повільна", пов'язане з проблемою зі старими версіями Java, оскільки вони або не мали компілятора Just-in-Time (JIT), або JIT у них були дуже обмежені у функціональності. У JVM був компілятор часу, що склавсявже дуже давно. Компілятор JIT - це частина часу виконання (наприклад, JVM), яка приймає незалежний від процесора байт-код - наприклад, байт-код Java - і компілює його в рідні інструкції для процесора. Цей процес виконується під час запуску програми Java, а передові компілятори JIT можуть оптимізувати окремі функції чи інструкції під час виконання для покращення їх роботи на основі спостережуваних результатів. Наприклад, якщо метод повертає істину кожен раз, коли він викликається, але з оригінального байт-коду не очевидно, що це буде зроблено, компілятор JIT може визнати, що він просто повертає істинний, і замінити виклик функції на жорсткий- кодоване значення "true". Це лише один приклад.

• Компіляція JIT та методи динамічного аналізу коду виконання протягом останніх років досягли величезних успіхів. Багато хто з спільноти інформатики вважають, що ще через десятиліття-два складний аналіз, доступний у динамічно інтерпретованих / компільованих мовах, таких як Java, C # та Ruby, буде настільки вдосконаленим, що в більшості випадків ці мови будуть виконуватись швидше при час виконання, ніж статично складені мови, такі як C і C ++. Це тому, що статичні компілятори, як правило, обмежуються компіляцією коду під час збирання, і код не змінюється під час виконання. Але в середовищі виконання, де код програми може переписати себепід час виконання для ефективнішого виконання існує величезна кількість перевертень, що може бути досягнуто за рахунок аналізу продуктивності коду та внесення коректив для зменшення складності коду або кількості інструкцій, які виконуються на процесорі. Для часто називаного коду час інвестицій, необхідний для проведення аналізу, значно перевищує переваги продуктивності багаторазового виклику швидшого коду.

• Слід зазначити, що Android Dalvik VM також містить JIT, і що він не використовує той же формат байт-коду, що і JVM Sun / Oracle. JIT Dalvik оптимізовано для низького середовища пам’яті, і він дуже вдосконалений щодо покращення продуктивності роботи. Тож деяким збігом обставин є те, що JVM та Dalvik впроваджують подібні оптимізації для відповідних середовищ виконання Java-програм, але під кришкою вони зовсім інші.

• Не забувайте того самого Дальвіка; ядро Linux; системні процеси низького рівня; і основні веб-браузери Android (як Firefox, так і Chrome) написані на рідному C / C ++, і тому вони не мають жодних проблем, що стосуються програми Dalvik. Це те саме, що iOS. Якщо ви говорите про чистий Android, а не про оператора / стороннього роздуття, який сидить поверх нього, дуже велика частка того, що складається з основного Android, не пишеться за допомогою Dalvik.

• Розробники додатків на Android також можуть за своїм бажанням писати нативний код, минаючи Dalvik. Якщо розробник програми відчував, що Далвік виступає вузьким місцем у виконанні свого коду або змушує його виснажувати занадто багато акумулятора, він може просто написати C / C ++ або навіть збірний код, якщо захоче, не отримуючи дозволу Google зробити це та поширити їх додаток так.

Ось декілька фактичних причин, через які у пристрою на базі Android або будь-якого пристрою можуть виникнути проблеми з тривалістю роботи акумулятора:

• Програми, які підтримують процесор, екран або з'єднання для передачі даних. Зокрема, 4G-набори мікросхем, такі як LTE, витрачають велику кількість енергії, коли вони включаються, тому якщо у вас є фонові програми, які постійно пробуджують LTE-чіп для передачі кількох кілобайт даних, це дуже швидко розрядить акумулятор. Екран на сучасних смартфонах та планшетах також дуже енергоємний, якщо не зменшити яскравість до мінімуму.

• "Програмне забезпечення", яке повинно бути на пристрої, і його неможливо видалити. Деякі недобросовісні носії вимагають запускати програмне забезпечення, яке займає цикли процесора та підтримує безперервне з'єднання даних. Це може бути або через некомпетентність розробників програмного забезпечення програмного забезпечення, або навмисну ​​мету відстежувати вашу діяльність на вашому смартфоні та відправляти їх на віддалений сервер для обміну даними, що дуже енергоємне для вашого акумулятора.

Нарешті, я не погоджуюся з вашою оцінкою, що Android має гірші проблеми з акумулятором, ніж на інших мобільних платформах. Деякі телефони та пристрої дійсно можуть мати проблеми з акумулятором, або через ємність акумулятора відносно споживання енергії обладнання; погано оптимізовані настройки живлення (обрані користувачем, оператором або виробником); або додатки з програмним забезпеченням, які постійно підтримують чіпи в телефоні. Але для кожного прикладу пристрою, який має проблеми з акумулятором, я можу навести вам контрприклад пристрою з чудовим часом автономної роботи. Не існує простого способу узагальнити те, що "це Далвік" або "це Linux" або "це Java". Оптимізація потужності - це складний апаратний / програмний механізм, що конкурує, включаючи продуктивність, чуйність, і очікування користувачів на час автономної роботи, з плюсами і мінусами кожного вибору. Щоб повністю зрозуміти профіль живлення пристрою, вам слід уважно ознайомитися з самим акумулятором, усім обладнанням та всім програмним забезпеченням, яке працює на пристрої.

У цій відповіді я порівнюю продуктивність з Android та IOS, оскільки вони займають понад 80% частки ринку.

Програми Java не використовують більше енергії. ( http://www.javarants.com/2004/05/04/looks-like-apple-should-switch/ ) Java VM Oracle або насправді Dalvik VM Google вважається набагато ефективнішим, ніж IOS Objective-C. Java здатна оптимізувати код до його виконання на телефоні, що може призвести до набагато кращої продуктивності. Бібліотеки Java є відкритим кодом, тому їх оптимізували сотні різних розробників. З іншого боку, з IOS лише розробники Apple можуть змінити код. Менше огляду = менша потенційна ефективність.

Програми Android також можуть запускати рідний код C, який може бути оскаржений як швидше, ніж знову Object-C (єдиний підтримуваний на IOS мову).

Причина, через яку Google вирішив використовувати Dalvik VM, полягає в мобільності. Я знаю чотири різних архітектури процесора, на яких Android може офіційно працювати (ARM, MIPS, x86, I.MX). У той час як кожна інша ОС телефону може використовувати лише одну (ARM). ( http://en.wikipedia.org/wiki/Comppare_of_mobile_operating_systems ) Тому порівнювати різні типи процесора з, наприклад, IPhone, несправедливо. Якби Android працював на IPhone, Android мав би порівняти з найкращою продуктивністю та ресурсом акумулятора.

"чи додатки Java використовують більше енергії?" Просто ні.
Чому телефони Android мають такий жахливий час роботи акумулятора порівняно з іншими платформами / телефонами? Багато телефонів Android побудовано дешевше, ніж IPhone Apple, але подивіться на різницю в ціні. IPhone коштував дорожче через набагато більший заряд батареї в ньому (і це в середньому повільніший процесор). Мій андроїд телефон (Google Galaxy Nexus) має порівнянний час автономної роботи з IPhone 4G, але має набагато швидші технічні характеристики (1 ГГц проти 1,2 ГГц).

EDIT: Java може оптимізувати код без необхідних знань програміста. Ідеально, код C завжди працюватиме швидше, ніж Java / Objective-C / C #; Це сказав, скільки програмістів ідеально? На рівні JVM Java та бібліотеки завжди будуть "досконалішими" через принципи розробки відкритого коду. ( http://www.infoq.com/news/2012/03/Defects-Open-Source-Com Commercial )

EDIT 2: Невеликий інформаційний елемент: новий Android-телефон P780 від Lenovo - 42 години розмови проти 12 годин на iPhone.

Так, це стосується збільшення енергоспоживання - це роблять шари абстракції. Це також призводить до зниження швидкості (протилежний бік тієї ж монети - якщо щось має більший накладний витрата, це займе більше часу, а отже, використовувати більше процесора). Якщо я правильно розумію, це одна з переваг того, що робить NDK , - дозволяти прискорення для конкретних процесорів, написавши конкретний код.

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

Що стосується всіх інших плакатів, я вважаю, що тут найбільше важливим є не те, чи існує C / C ++ / Java, а те, що роблять програми.

Оскільки споживання електроенергії відображається безпосередньо з обробкою, я б запитав себе, якою обробкою займається програма.

Скажіть, ви додаєте числа. Скажіть, ви додаєте 2 з 2 у нескінченному циклі, поки не досягнете 2.000.000. Виникає два питання:

1. Як це реалізується: чи це цикл for? Це цикл часу? (Це злом Goto / Label?)
2. Як оптимізується код.

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

Так.

Віртуальні машини "роблять все двічі", і це не обов'язково ефективно. Отже, вони використовуватимуть щонайменше вдвічі більше енергії для обробки тих же інструкцій, що і "справжня машина". Наявність віртуальної машини сповільнює справи і використовує більше енергії. В основному, такі ОС, як iOS та WIndows, робитимуть все швидше та з меншим споживанням енергії.

Це означає реальні відмінності переходів на екрані, завантаження сторінок, навігацію тощо. В даний час я порівнюючи Android (VM) і Windows Phone, і навіть з більш повільним процесором (1 ГГц проти 1,6 ГГц), Windows значно перевершує Android, виконуючи такі ж завдання.

Однак, більшість людей привертає увагу, коли вони встановлюють додаток і раптом їх акумулятор швидше звикає. Це насправді не через віртуальну машину, але додаток, який голосно використовує ресурси.

Вся причина ОС віртуальної машини, портативність, не є вагомою причиною базувати ОС. Чи бачите ви, що люди купують телефони зі своєю улюбленою архітектурою та користуються Android через її портативний? Чи бачите ви людей, які відмовляються від більш високої продуктивності та надійності та розміщують Android на своїх не андроїд телефонах? Люди купують телефон Android, або телефон Windows, або IPhone тощо. Пожертвувати продуктивністю заради переносності пристроїв з низькою вартістю недоцільно. Це була гарна ідея, яка стала невдалою.