14

Поскольку приложения Android работают на JVM (Dalvik VM), которая в основном является виртуальным процессором, и каждая виртуальная инструкция должна быть сопоставлена с собственной инструкцией базового набора микросхем, приводит ли это отображение к большему энергопотреблению из-за издержек этого отображения?

Этот вопрос можно распространить на Java, а также сформулировать так: «Используют ли приложения Java больше возможностей?». Вот почему телефоны Android имеют такой ужасный срок службы батареи по сравнению с другими платформами / телефонами?

Изменить: Основываясь на ответах, я разъяснил несколько моментов, потому что я ошибочно говорил о JVM и Dalvik взаимозаменяемо. В этом бите я говорю о Java только для того, чтобы спросить, использует ли она больше энергии, и если да, относится ли это концептуально и к Android, и приводит ли это к сокращению времени автономной работы.

Контекст: цитата из Википедии:

  1. Java-байт-код аналогичен языку ассемблера для C-кода.
  2. С точки зрения компилятора виртуальная машина Java - это просто еще один процессор с набором инструкций, байт-кодом Java, для которого может быть сгенерирован код.
  3. JVM имеет стековую архитектуру. Dalvik - это виртуальная машина процесса, которая не относится к типу виртуализации, аналогичному JVM, и имеет архитектуру регистра.

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

Мощность: вопрос сводится, по сути, к следующему - для того же набора функций программного кода или приложения, какой процент тактовых циклов вашего процессора относится к среде выполнения. Это происходит в среде компиляции Just-In-Time современных JVM, где, если байт-код компилируется с собственной инструкцией базового набора микросхем, тогда время выполнения должно быть активным только во время Jit-компиляции. Итак, насколько больше тактов ЦП используется в среде выполнения, которая, как ожидается, приведет к увеличению энергопотребления. Меня интересует только аспект энергопотребления, а не относительная производительность по сравнению со статически типизированными и встроенными языками, и я понимаю преимущества Java. Подвопросы, которые могут быть связаны:

  • Использует ли среда выполнения Java libc для своей функциональности?
  • Какие-либо из этих точек, связанных с энергопотреблением, соответствуют Dalvik VM и Android?
  • Вместо того, чтобы обобщать плохое потребление батареи Android, не говоря об экране и беспроводных чипсетах, давайте поговорим о том, что у iPhone 5 есть батарея емкостью 1440 мАч, которая крошечна по сравнению с современными телефонами Nexus. Весь этот ход мыслей (Java, Виртуальный процессор, отображение инструкций, Android) возник, потому что друг-лоялист iphone утверждал, что это может быть вероятной причиной того, что его iphone имеет более длительное время автономной работы, чем мой (удивительный) нексус.

В любом случае, спасибо за ответы ниже.

5 ответов5

25

Ваш вопрос основан на многих ошибочных предположениях. Позвольте мне попытаться прояснить их:

  • Вы сказали "JVM (Dalvik VM)". Это все равно что сказать "Самолет (Велосипед)". Эти две вещи не имеют абсолютно никакого отношения друг к другу.

  • Вы сказали "... который в основном виртуальный процессор". Просто ложь. Это не тот случай, когда каждый раз, когда слова "Виртуальная машина" или аббревиатура "ВМ" используются в техническом контексте, они по существу эквивалентны VMware Workstation. Это связано с тем, что такие продукты, как VMware , фактически эмулируют весь компьютер, а не только процессор, и работают под управлением операционной системы поверх другой операционной системы. Далвик В.М. так не работает. Даже не близко.

  • Java это просто язык программирования. Это синтаксис. Программы Android/Dalvik используют тот же или очень похожий синтаксис для совершенно не связанного языка программирования для настольных компьютеров и серверов, называемого Java, который работает на виртуальной машине Java. Теоретически, вы могли бы написать код Java, который почти такой же скорости, как и код C, так как они оба являются языками программирования высокого уровня. Дьявол кроется в деталях реализации библиотечных вызовов и в том, как спроектирована среда выполнения, что очень мало связано с синтаксисом языка.

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

  • Восприятие, что "Java медленен", происходит из-за проблемы со старыми версиями Java в том, что у них либо не было компилятора Just-In-Time (JIT), либо JIT, который у них был, был очень ограничен в функциональности. JVM уже давно использует компилятор Just-In Time. JIT-компилятор является частью среды выполнения (например, JVM), которая принимает независимый от процессора байт-код - например, байт-код Java - и компилирует его в собственные инструкции для ЦП. Этот процесс выполняется, когда запускается Java-программа, и продвинутые JIT-компиляторы могут оптимизировать отдельные функции или инструкции во время выполнения для повышения их производительности на основе наблюдаемых результатов. Например, если метод возвращает true каждый раз, когда он вызывается, но из исходного байт-кода не очевидно, что он это сделает, компилятор JIT может распознать, что он просто возвращает true, и заменить вызов функции жестким закодированное значение "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. Если разработчик приложения чувствовал, что Dalvik выступал в качестве узкого места в производительности их кода или заставлял его расходовать слишком много батареи, он мог просто написать C / C++ или даже ассемблерный код, если захотел, без необходимости одобрения Google. сделать это и распространять свое приложение таким образом.

Вот несколько фактических причин, по которым у устройства с питанием от батареи Android или любого другого устройства могут быть проблемы с временем автономной работы:

  • Приложения, которые поддерживают связь между процессором, экраном или данными. В частности, чипсеты 4G, такие как LTE, потребляют много энергии при включении, поэтому, если у вас есть фоновые программы, которые постоянно активируют микросхему LTE для передачи нескольких килобайт данных, это очень быстро разряжает батарею. Экран на современных смартфонах и планшетах также очень энергоемкий, если только вы не уменьшите яркость до минимума.

  • "Bloatware", который должен быть на устройстве и не может быть удален. Некоторые недобросовестные операторы требуют, чтобы вы запускали вредоносные программы, которые загружают циклы ЦП и поддерживают соединение для передачи данных без сна. Это может быть связано либо с некомпетентностью разработчиков программного обеспечения, либо с намеренной целью отслеживать ваши действия на смартфоне и отправлять их на удаленный сервер для интеллектуального анализа данных, который очень энергоемкий для вашей батареи.

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

5

В этом ответе я буду сравнивать производительность с Android и IOS, поскольку они занимают более 80% рынка.

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

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

Причина, по которой Google решил использовать виртуальную машину Dalvik, заключается в мобильности. Я знаю о четырех разных архитектурах ЦП, на которых может официально работать Android (ARM, MIPS, x86, I.MX). В то время как любая другая операционная система телефона может использовать только одну (ARM). (http://en.wikipedia.org/wiki/Comparison_of_mobile_operating_systems) Поэтому сравнивать разные типы процессоров, например, с iPhone, несправедливо. Если бы Android работал на IPhone, он имел бы сравнимую производительность и время автономной работы.

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

РЕДАКТИРОВАТЬ: Java может оптимизировать код без знания программиста. Отлично, код на C всегда будет работать быстрее, чем Java / Objective-C / C #; Тем не менее, сколько программистов там идеально? На уровне JVM Java и библиотеки всегда будут "более совершенными" благодаря принципам разработки с открытым исходным кодом. (http://www.infoq.com/news/2012/03/Defects-Open-Source-Commercial)

РЕДАКТИРОВАТЬ 2: Небольшая информация: новый Android-телефон Lenovo P780 - 42 часа разговоров против 12 часов на iPhone.

3

Да, это относится к увеличению энергопотребления - это сделают слои абстракции. Это также приводит к снижению скорости (противоположная сторона той же самой монеты - если что-то имеет большие накладные расходы, это займет больше времени для выполнения и, следовательно, будет использовать больше ЦП). Если я правильно понимаю, это одно из преимуществ того, что делает NDK - разрешить ускорение для определенных процессоров путем написания определенного кода.

Тем не менее, для большинства работ я бы предположил, что "связанные с питанием" накладные расходы на работу виртуальной машины затмеваются другими соображениями - для большинства программ использование экрана и радио потребляет большую часть энергии.

3

Что касается всех других постеров, я считаю, что здесь важнее не то, существует ли C/C++/Java, а то, что делают приложения.

Поскольку энергопотребление сопоставляется непосредственно с обработкой, я спрашиваю себя, какую обработку будет выполнять программа.

Скажем, вы добавляете числа. Скажем, вы добавляете 2 с 2 на бесконечный цикл, пока не достигнете 2.000.000. Возникают два вопроса:

  1. Как это реализовано: это цикл for? Это цикл времени? (Это взломать Goto/Label?)
  2. Как оптимизируется код.

Эти два вопроса в конечном итоге определяют, сколько операций требуется процессору и, в конечном итоге, сколько энергии потребляет устройство. При этом "накладные расходы" на запуск виртуализированной среды могут быть незначительными из-за предыдущей оптимизации, выполненной Java для всей программы, но опять же, все зависит от того, что делает приложение.

0

Да.

Виртуальные машины «делают все дважды», и не обязательно эффективно. Таким образом, они будут использовать как минимум вдвое больше энергии для обработки тех же инструкций, что и «реальная машина». Наличие виртуальной машины замедляет работу и потребляет больше энергии. По сути, операционные системы, такие как iOS и Windows, будут делать все быстрее и с меньшим энергопотреблением.

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

Однако, что привлекает внимание большинства людей, так это когда они устанавливают приложение, и внезапно их батарея быстрее разряжается. Это на самом деле не благодаря виртуальной машине, а приложению, которое жадно использует ресурсы.

Вся причина для ОС виртуальной машины, портативность, не является хорошей причиной для основания ОС. Видите ли вы людей, покупающих телефоны с их любимой архитектурой и использующих Android, потому что он портативный? Видите ли вы людей, которые отказываются от более высокой производительности и надежности и ставят Android на свои телефоны без Android? Люди покупают телефоны Android, Windows Phone, IPhone и т.д. Жертвой производительности ради переносимости в недорогие устройства нецелесообразно. Это была хорошая идея, которая потерпела неудачу.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .