O Android ou Java consome mais energia, pois está sendo executado em uma máquina virtual?

Como os aplicativos Android são executados em uma JVM (Dalvik VM), que é basicamente um processador virtual, e todas as instruções virtuais precisam ser mapeadas para as instruções nativas do chipset subjacente, esse mapeamento resulta em mais consumo de energia devido à sobrecarga desse mapeamento?

Esta questão pode ser estendida para Java e também formulada como "os aplicativos Java usam mais energia?". É por isso que os telefones Android têm uma duração de bateria tão assustadora em comparação com outras plataformas / telefones?

Edit : Com base nas respostas, esclareço alguns pontos, porque eu tinha falado erroneamente da JVM e Dalvik de forma intercambiável. Neste passo, estou falando sobre Java apenas para perguntar se ele consome mais energia e, se sim, isso também se aplica conceitualmente ao Android e resulta em menor duração da bateria.

Contexto : citado na Wikipedia:

1. O bytecode Java é análogo à linguagem assembly para código C.
2. Do ponto de vista de um compilador, a máquina virtual Java é apenas outro processador com um conjunto de instruções, Java bytecode, para o qual o código pode ser gerado.
3. A JVM possui uma arquitetura de pilha. Dalvik é uma máquina virtual de processo que não é o mesmo tipo de virtualização da JVM e possui uma arquitetura de registro.

Como a linguagem de programação Java é compilada no bytecode (semelhante a um assembly) e é executada em um processador virtual, fornece verdadeira portabilidade de código de software. Além disso, como há uma JVM para Linux e o Linux foi portado para hardware aberto, a combinação pode fornecer verdadeira portabilidade de aplicativo em toda a pilha.

Potência : A questão se resume a isso - para o mesmo conjunto de funcionalidades do código ou aplicativo de software, qual a porcentagem de ciclos de clock da CPU atribuída ao ambiente de tempo de execução. Isso ocorre no ambiente de compilação Just-In-Time das JVMs modernas, onde se o bytecode for compilado com a instrução nativa do chipset subjacente, o tempo de execução deverá estar ativo apenas durante a compilação jit. Portanto, quanto mais ciclos de clock da CPU são usados ​​para ter o ambiente de tempo de execução que deve resultar em uma sobrecarga de consumo de energia. Estou interessado apenas no aspecto do consumo de energia, e não no desempenho relativo comparado com as linguagens estaticamente tipadas e construídas e entendo as vantagens do Java. Sub-perguntas que podem estar relacionadas:

• O Java Run time usa a libc para sua funcionalidade?
• Algum desses pontos relacionados ao consumo de energia se traduz na VM e no Android Dalvik?
• Em vez de generalizar o baixo consumo de bateria do Android sem falar sobre a tela e os chipsets sem fio - vamos falar sobre como o iPhone 5 tem uma bateria de 1440 mAH, que é pequena se comparada aos telefones Nexus modernos. Toda essa linha de pensamento (Java, processador virtual, mapeamento de instruções, Android) surgiu porque um amigo fiel do iPhone alegou que esse poderia ser o motivo provável para o iPhone ter uma vida útil melhor da bateria do que o meu (impressionante) nexo.

De qualquer forma, obrigado pelas respostas abaixo.

Sua pergunta é baseada em muitas suposições falhas. Deixe-me tentar esclarecê-los:

• Você disse "JVM (Dalvik VM)". É como dizer "Avião (bicicleta)". Essas duas coisas não têm absolutamente nada a ver uma com a outra.

• Você disse "... que é basicamente um processador virtual". Simplesmente falso. É não o caso que, cada vez que as palavras "Máquina Virtual" ou sigla "VM" é usado num contexto técnico, que é essencialmente equivalente a VMware Workstation . Isso ocorre porque produtos como o VMware de fato imitam um computador inteiro, não apenas a CPU, e estão executando um sistema operacional em cima de outro sistema operacional. O Dalvik VM não funciona assim. Nem mesmo perto.

• Java é apenas uma linguagem de programação. É sintaxe. Os programas Android / Dalvik usam a mesma sintaxe ou muito semelhante a uma linguagem de programação de desktop / servidor completamente independente, chamada Java, que é executada em uma Java Virtual Machine. Em teoria, você poderia escrever um código Java quase da mesma velocidade que o código C, pois ambas são linguagens de programação de alto nível. O diabo está nos detalhes da implementação das chamadas da biblioteca e na maneira como o tempo de execução é projetado, o que tem muito pouco a ver com a sintaxe da linguagem.

• É uma generalização excessiva afirmar que a Dalvik VM, a Sun Java Hotspot JVM ou a sintaxe da linguagem de programação Java é responsável pelo alto consumo de energia. O motivo é que você precisa comparar o que quer que esteja falando com o desempenho de outra coisa . No caso mais geral, quando você está apenas comparando os recursos "melhores casos" de ambas as plataformas, é possível, em princípio, criar aplicativos Dalvik tão rápidos ou mais rápidos que os programas em qualquer outra plataforma. Além do gerenciamento automático de memória e da compilação JIT - recursos que são padrão em quase todos os ambientes de programação atualmente, inclusive no iOS e no JavaScript / HTML5 - há muito pouco que separa o Dalvik do Objective-C, .NET, Ruby, o Oracle Hotspot JVM, Python e assim por diante.

• A percepção de que "o Java é lento" se deve a um problema com versões antigas do Java, pois eles não tinham um JIT (Just-In-Time Compiler) ou o JIT que tinham era muito limitado em funcionalidade. A JVM possui um compilador Just-In Timepor muito tempo agora. Um compilador JIT faz parte do tempo de execução (por exemplo, a JVM) que utiliza o bytecode independente do processador - por exemplo, Java bytecode - e o compila em instruções nativas para a CPU. Esse processo é realizado quando o programa Java é iniciado e os compiladores JIT avançados podem otimizar funções ou instruções individuais em tempo de execução para melhorar seu desempenho com base nos resultados observados. Por exemplo, se um método retorna true sempre que é chamado, mas não é óbvio pelo código de bytes original que o faria, o compilador JIT pode reconhecer que ele retorna true e substituir a chamada de função por um código valor codificado de "true". isso é apenas um exemplo.

• As técnicas de compilação JIT e análise dinâmica de código em tempo de execução têm feito grandes avanços nos últimos anos. Muitos na comunidade de ciência da computação acreditam que, em mais uma década ou duas, a sofisticada análise disponível em linguagens interpretadas / compiladas dinamicamente, como Java, C # e Ruby, será tão avançada que, na maioria dos casos, essas linguagens serão executadas mais rapidamente em em tempo de execução do que linguagens estaticamente compiladas, como C e C ++. Isso ocorre porque os compiladores estáticos geralmente se limitam à compilação de código no momento da construção e o código não é modificado no tempo de execução. Mas em um ambiente de tempo de execução onde o código do programa pode re-escrever -sedurante a execução para executar com mais eficiência, há uma enorme quantidade de vantagens que podem ser obtidas analisando o desempenho do código e fazendo ajustes para reduzir a complexidade do código ou o número de instruções executadas na CPU. Para o código chamado com frequência, o investimento em tempo necessário para realizar a análise é superado pelos benefícios de desempenho da chamada repetida de código mais rápido.

• Deve-se observar que a VM Dalvik do Android também contém uma JIT e que não usa o mesmo formato de bytecode da JVM Sun / Oracle. O JIT da Dalvik é otimizado para ambientes com pouca memória e é muito avançado no que diz respeito a aprimoramentos de desempenho em tempo de execução. Portanto, é uma coincidência que a JVM e a Dalvik implementem otimizações semelhantes para o respectivo ambiente de tempo de execução baseado em Java, mas, sob o capô, elas são bem diferentes.

• Não esqueça que o próprio Dalvik; o kernel do Linux; processos de sistema de baixo nível; e o núcleo dos navegadores da Web Android (Firefox e Chrome) são escritos em C / C ++ nativo e, portanto, eles não têm nenhuma das preocupações gerais que um programa Dalvik teria. É o mesmo que o iOS. Se você está falando sobre o Android puro e não o inchaço da operadora / terceiros que fica em cima dele, uma proporção muito grande do que compreende o Android central não é escrita usando o Dalvik.

• Os desenvolvedores de aplicativos no Android também podem, a seu critério, escrever código nativo, ignorando o Dalvik. Se um desenvolvedor de aplicativos sentir que Dalvik está agindo como um gargalo no desempenho de seu código, ou fazendo com que ele gaste muita bateria, ele pode simplesmente escrever código C / C ++ ou mesmo assembly, se quiser, sem ter que obter a aprovação do Google para fazer isso e distribuir o aplicativo assim.

Aqui estão algumas razões reais pelas quais um dispositivo alimentado por bateria Android, ou qualquer outro dispositivo, pode ter problemas com a duração da bateria:

• Aplicativos que mantêm a CPU, a tela ou a conexão de dados ativada. Em particular, os chipsets 4G, como o LTE, consomem muita energia quando são ligados; portanto, se você tiver programas em segundo plano que ativem continuamente o chip LTE para transferir alguns kilobytes de dados, isso esgotará sua bateria muito rapidamente. A tela de smartphones e tablets modernos também consome muita energia, a menos que você reduza o brilho ao mínimo.

• "Bloatware" necessário para estar no dispositivo e não pode ser desinstalado. Algumas operadoras sem escrúpulos exigem que você execute bloatware que consome ciclos da CPU e mantém a conexão de dados ativa. Isso pode ser devido à incompetência dos desenvolvedores de software do bloatware ou a um objetivo intencional de monitorar suas atividades em seu smartphone e enviá-las para um servidor remoto para mineração de dados, que consome muita energia da bateria.

Por fim, discordo da sua avaliação de que o Android tem problemas de duração da bateria piores do que em outras plataformas móveis. Certos telefones e dispositivos podem realmente ter problemas de duração da bateria, devido à capacidade da bateria em relação ao consumo de energia do hardware; configurações de energia pouco otimizadas (eleitas pelo usuário, transportadora ou fabricante); ou aplicativos de bloatware que mantêm os chips no telefone acordados o tempo todo. Mas para todos os exemplos de dispositivos com problemas de bateria, posso fornecer um contra-exemplo de dispositivo com excelente duração da bateria. Não existe uma maneira simples de generalizar que "é Dalvik" ou "é Linux" ou "é Java". A otimização de energia é uma complicada mistura de hardware / software de preocupações concorrentes, incluindo desempenho, capacidade de resposta, e as expectativas do usuário quanto à duração da bateria, com prós e contras em cada opção. Para entender completamente o perfil de energia de um dispositivo, você deve examinar atentamente a própria bateria, todo o hardware e todo o software em execução no dispositivo.

Nesta resposta, compararei o desempenho com o Android e o IOS, pois os dois ocupam mais de 80% da participação de mercado.

Aplicativos Java não usam mais energia. ( http://www.javarants.com/2004/05/04/looks-like-apple-should-switch/ ) Java VM da Oracle ou, na realidade, a VM Dalvik do Google é considerada muito mais eficiente do que o Objective-C do IOS. Java é capaz de otimizar o código antes de ser executado no telefone, o que pode resultar em um desempenho muito melhor. As bibliotecas Java são de código aberto e, portanto, foram otimizadas por centenas de desenvolvedores diferentes. Por outro lado, com o IOS, apenas os desenvolvedores da Apple podem alterar o código. Menos revisão = menos desempenho potencial.

Os programas Android também podem executar o código C nativo, que pode ser contestado mais rapidamente do que o Object-C (o único idioma suportado no IOS).

A razão pela qual o Google decidiu usar a Dalvik VM é a portabilidade. Conheço quatro arquiteturas de CPU diferentes nas quais o Android pode executar oficialmente (ARM, MIPS, x86, I.MX). Enquanto todos os outros SOs de telefone podem usar apenas um (ARM). ( http://en.wikipedia.org/wiki/Comparison_of_mobile_operating_systems ) Portanto, comparar diferentes tipos de CPU com, por exemplo, o IPhone é injusto. Se o Android fosse executado no IPhone, o Android teria comparável ao desempenho superior e à duração da bateria.

"os aplicativos Java usam mais energia?" Simplesmente não.
Por que os telefones Android têm uma duração de bateria tão assustadora em comparação com outras plataformas / telefones? Muitos telefones Android são fabricados mais baratos que o iPhone da Apple, mas olhe a diferença de preço. O IPhone custa mais por causa da bateria muito maior (e é, em média, uma CPU mais lenta). Meu telefone Android (Google Galaxy Nexus) tem uma duração de bateria comparável à do IPhone 4G, mas possui especificações de hardware muito mais rápidas (1GHz vs. 1.2GHZ).

EDIT: Java pode otimizar código sem o conhecimento do programador necessário. Perfeito, o código C sempre será executado mais rapidamente que Java / Objective-C / C #; Dito isto, quantos programadores são perfeitos? No nível da JVM, Java e bibliotecas sempre serão "mais perfeitas" por causa de seus princípios de desenvolvimento de código aberto. ( http://www.infoq.com/news/2012/03/Defects-Open-Source-Commercial )

EDIT 2: Pequenos detalhes: o novo telefone Android P780 da Lenovo - 42 horas de conversação contra 12 horas no IPhone.

Sim, está relacionado ao aumento do consumo de energia - camadas de abstração farão isso. Isso também leva a uma diminuição na velocidade (lado oposto da mesma moeda - se algo tiver uma sobrecarga maior, levará mais tempo para executar e, portanto, usar mais CPU). Se bem entendi, essa é uma das vantagens do que o NDK faz - permita acelerações para processadores específicos escrevendo código específico.

Dito isto, para a maioria dos trabalhos, imagino que as despesas gerais "relacionadas à energia" da execução de uma VM sejam diminuídas por outras considerações - para a maioria dos programas, o uso de telas e rádios consumirá a maior parte da energia.

Com relação a todos os outros pôsteres, acredito que o que mais importa aqui não é se existe C / C ++ / Java, mas o que os aplicativos estão fazendo.

Como o consumo de energia mapeia diretamente com o processamento, eu me perguntava o que o processamento faria um programa.

Digamos que você esteja adicionando números. Digamos que você adicione 2 com 2 em um loop infinito até atingir 2.000.000. Duas questões surgem:

1. Como é implementado: É um loop for? É um loop while? (É um hack de Goto / Label?)
2. Como o código está sendo otimizado.

Essas duas perguntas, em última análise, definem quantas operações o processador precisa fazer e, finalmente, quanta energia um dispositivo usa. Dito isto, a "sobrecarga" da execução de um ambiente virtualizado pode ser insignificante devido à otimização anterior feita pelo Java em todo o programa, mas, novamente, tudo depende do que o aplicativo está fazendo.

Sim.

Máquinas virtuais 'fazem tudo duas vezes', e não necessariamente de forma eficiente. Portanto, eles usarão pelo menos duas vezes mais energia para processar as mesmas instruções que uma 'máquina real'. A presença de uma máquina virtual torna as coisas mais lentas e consome mais energia. Basicamente, sistemas operacionais como iOS e Windows farão tudo mais rápido e com menos consumo de energia.

Isso se traduz em diferenças reais em transições de tela, carregamento de página, navegação, coisas assim. Atualmente, estou comparando o Android (VM) e o Windows Phone, e mesmo com um processador mais lento (1 GHz vs 1,6 GHz), o Windows supera significativamente o Android, executando o mesmo tipo de tarefas.

No entanto, o que atrai a atenção da maioria das pessoas é quando instalam um aplicativo e, de repente, a bateria se esgota mais rapidamente. Isso não se deve realmente à máquina virtual, mas a um aplicativo que utiliza recursos avidamente.

Todo o motivo de um SO de máquina virtual, portabilidade, não é um bom motivo para basear um SO. Você vê pessoas comprando telefones com sua arquitetura favorita e usando o Android porque é portátil? Você vê pessoas desistindo de maior desempenho e confiabilidade e colocando o Android em seus telefones não Android? As pessoas compram um telefone Android, Windows Phone ou iPhone, etc. Sacrificar o desempenho pela portabilidade em dispositivos de baixo custo é impraticável. Foi uma boa ideia que se tornou um fracasso.