AndroidまたはJavaは仮想マシンで実行されるため、より多くの電力を使用しますか？

Androidアプリケーションは、基本的に仮想プロセッサであるJVM（Dalvik VM）で実行され、すべての仮想命令は基盤となるチップセットのネイティブ命令にマッピングする必要があるため、このマッピングのオーバーヘッドにより、このマッピングにより消費電力が増加しますか？

この質問はJavaに拡張でき、「Javaアプリケーションはより多くの電力を使用しますか？」と表現することもできます。これが、Androidスマートフォンが他のプラットフォーム/携帯電話と比較してひどいバッテリー寿命を持っている理由ですか？

編集：私が誤ってJVMとDalvikについて交換可能に話したので、私はいくつかのポイントを明らかにした回答に基づいて。このビットでは、Javaについてより多くの電力を使用するかどうかを尋ねるだけですが、そうであれば、概念的にAndroidにも適用され、バッテリー寿命が短くなります。

コンテキスト：ウィキペディアからの引用：

1. Javaバイトコードは、Cコードのアセンブリ言語に似ています。
2. コンパイラの観点から見ると、Java仮想マシンは、コードを生成できる命令セットであるJavaバイトコードを備えた単なるプロセッサです。
3. JVMにはスタックアーキテクチャがあります。Dalvikは、JVMと同じタイプの仮想化ではないプロセス仮想マシンであり、レジスタアーキテクチャを備えています。

Javaプログラミング言語は（アセンブリのような）バイトコードにコンパイルされ、仮想プロセッサで実行されるため、真のソフトウェアコードの移植性を提供します。また、Linux用のJVMがあり、Linuxはオープンハードウェアに移植されているため、この組み合わせにより、スタック全体でアプリケーションの真の移植性を実現できます。

パワー：質問は本質的にこれに要約されます-ソフトウェアコードまたはアプリケーションの同じ機能セットに対して、CPUクロックサイクルの何パーセントがランタイム環境に起因するのか。これは、バイトコードが基礎となるチップセットのネイティブ命令にコンパイルされる場合、ランタイムはjitコンパイル中にのみアクティブになります。したがって、電力消費のオーバーヘッドが発生すると予想されるランタイム環境を使用する際に、CPUクロックサイクルがどれだけ多く使用されるのか。静的に型付けされ、構築された言語と比較した相対的なパフォーマンスではなく、電力消費の側面にのみ興味があり、Javaの利点を理解しています。関連する可能性のあるサブ質問：

• Javaランタイムはその機能のためにlibcを使用しますか？
• これらの消費電力関連のポイントは、Dalvik VMおよびAndroidに変換されますか？
• 画面やワイヤレスチップセットについて話すことなく、Androidの貧弱なバッテリー消費を一般化する代わりに、iPhone 5が現代のNexus携帯電話と比べて小さい1440 mAHバッテリーを持っていることについて話しましょう。この一連の思考（Java、仮想プロセッサ、命令マッピング、Android）が生まれたのは、iPhoneの愛好家の友人が、これが自分のiPhoneが私の（素晴らしい）ネクサスよりもバッテリー寿命が長い理由だと主張したからです。

いずれにせよ、以下の回答をありがとう。

あなたの質問は多くの欠陥のある仮定に基づいています。それらを片付けようとします：

• あなたは「JVM（Dalvik VM）」と言った。それは「飛行機（自転車）」と言っているようなものです。これらの2つのことは、互いにまったく関係ありません。

• あなたは「...これは基本的に仮想プロセッサです」と言いました。単に偽。技術的な文脈で「仮想マシン」または「VM」という頭字語が使用されるたびに、VMware Workstationと本質的に同等になるわけではありません。これは、VMwareなどの製品が実際にはCPUだけでなくコンピューター全体をエミュレートし、別のオペレーティングシステム上でオペレーティングシステムを実行しているためです。Dalvik VMはそのようには機能しません。程遠い。

• Javaは単なるプログラミング言語です。構文です。Android / Dalvikプログラムは、Java仮想マシン上で実行されるJavaと呼ばれるまったく関係のないデスクトップ/サーバープログラミング言語と同じまたは非常に類似した構文を使用します。理論的には、どちらも高レベルのプログラミング言語であるため、Cコードとほぼ同じ速度のJavaコードを記述できます。ライブラリー呼び出しの実装の詳細とランタイムの設計方法には悪魔がいます。これは、言語の構文とはほとんど関係ありません。

• Dalvik VM、Sun Java Hotspot JVM、またはJavaプログラミング言語の構文が高電力消費の原因であると言っても過言ではありません。理由は、あなたが話していることを他のもののパフォーマンスと比較しなければならないからです。最も一般的なケースでは、両方のプラットフォームの「ベストケース」機能を比較するだけで、原則として、他のプラットフォームのプログラムと同じかそれよりも速いDalvikアプリを作成できます。自動メモリ管理とJITコンパイル（iOSやJavaScript / HTML5を含む最近のほぼすべてのプログラミング環境で標準となっている機能）以外に、DalvikをObjective-C、.NET、Ruby、 Oracle Hotspot JVM、Pythonなど。

• 「Javaが遅い」という認識は、ジャストインタイムコンパイラ（JIT）がないか、JITの機能が非常に限られていたという点で、古いバージョンのJavaの問題によるものです。JVMにはJust-In Timeコンパイラがありましたとても長い間です JITコンパイラは、プロセッサに依存しないバイトコード（Javaバイトコードなど）を取得し、それをCPUのネイティブ命令にコンパイルするランタイム（JVMなど）の一部です。このプロセスはJavaプログラムの起動時に行われ、高度なJITコンパイラーは実行時に個々の関数または命令を最適化して、観察結果に基づいてパフォーマンスを向上させることができます。たとえば、メソッドが呼び出されるたびにtrueを返しますが、元のバイトコードからそうすることが明らかでない場合、JITコンパイラーはそれがtrueを返すだけであることを認識し、関数呼び出しをhard- 「true」のコード値。これはほんの一例です。

• JITコンパイルとランタイムの動的コード分析技術は、近年大きな進歩を遂げています。コンピュータサイエンスのコミュニティの多くは、別の10年か20年には、Java（登録商標）、C＃やRubyなどの動的に解釈/コンパイル言語で利用できる洗練された分析は、そう、ほとんどの場合、これらの言語が実行されることを進めることになることを信じて高速化でCやC ++などの静的にコンパイルされた言語よりも実行時間が長い。これは、通常、静的コンパイラはビルド時のコードのコンパイルに限定されており、実行時にコードが変更されないためです。しかし、プログラムのコードがそれ自体を書き換えることができるランタイム環境では実行中により効率的に実行するために、コードのパフォーマンスを分析し、コードの複雑さまたはCPUで実行される命令の数を減らすために調整を行うことで達成できる膨大な量の利点があります。頻繁に呼び出されるコードの場合、分析を実行するために必要な時間投資は、より高速なコードを繰り返し呼び出すことによるパフォーマンス上の利点をはるかに上回ります。

• Android Dalvik VMにはJITも含まれており、Sun / Oracle JVMと同じバイトコード形式を使用しないことに注意してください。DalvikのJITは、低メモリ環境向けに最適化されており、ランタイムパフォーマンスの強化に関しては非常に高度です。そのため、JVMとDalvik がそれぞれのJavaベースのランタイム環境に対して同様の最適化を実装しているのは偶然ですが、内部ではまったく異なります。

• Dalvik自体を忘れないでください。Linuxカーネル。低レベルのシステムプロセス。Android Webブラウザーのコア（FirefoxとChromeの両方）はネイティブC / C ++で記述されているため、Dalvikプログラムのようなオーバーヘッドの心配はありません。これはiOSと同じです。純粋なAndroidについてであり、その上にあるキャリア/サードパーティの肥大化についてではない場合、コアAndroidを構成するものの大部分はDalvikを使用して記述されていません。

• Androidのアプリケーション開発者は、オプションで、Dalvikをバイパスしてネイティブコードを記述することもできます。アプリケーション開発者が、Dalvikがコードのパフォーマンスのボトルネックとして機能している、またはバッテリーを大量に消費させていると感じた場合、C / C ++または必要に応じてアセンブリコードを記述することもできます。そのようにして、アプリをそのように配布します。

ここではいくつかあり、実際の理由Androidのバッテリ駆動デバイス、または任意のデバイスは、バッテリの寿命に問題がある可能性があります。

• CPU、画面、またはデータ接続を起動状態に保つアプリケーション。特に、LTEなどの4Gチップセットは、電源を入れると大量のエネルギーを消費するため、LTEチップを継続的に起動して数キロバイトのデータを転送するバックグラウンドプログラムがある場合、バッテリーが非常に速く消耗します。最新のスマートフォンやタブレットの画面も、明るさを最小限に抑えない限り、非常にエネルギーを消費します。

• デバイス上にあることが必要で、アンインストールできない「ブロートウェア」。悪意のある通信事業者の中には、CPUサイクルを消費してデータ接続を維持するブロートウェアを実行する必要があるものがあります。これは、ブロートウェアのソフトウェア開発者の能力不足、またはスマートフォンでのアクティビティを監視し、データマイニングのためにリモートサーバーに送信するという意図的な目標が原因である可能性があります。

最後に、Androidのバッテリー寿命の問題は他のモバイルプラットフォームよりも悪いというあなたの評価に同意しません。特定の電話やデバイスは、ハードウェアのエネルギー消費に対するバッテリーの容量に起因するバッテリー寿命の問題を実際に抱えている場合があります。最適化されていない電力設定（ユーザー、通信事業者、または製造元によって選出された）。または、携帯電話のチップを常に起動状態に保つブロートウェアアプリ。しかし、バッテリーに問題があるデバイスのすべての例について、優れたバッテリー寿命を備えたデバイスの反例を挙げることができます。「それはDalvikだ」、「Linuxだ」、「Javaだ」ということを一般化する簡単な方法はありません。消費電力の最適化は、パフォーマンス、応答性などの競合する懸念事項の複雑なハードウェア/ソフトウェアです。バッテリー寿命に対するユーザーの期待、それぞれの長所と短所。デバイスの電力プロファイルを完全に理解するには、バッテリー自体、すべてのハードウェア、およびデバイスで実行されているすべてのソフトウェアをよく見る必要があります。

この回答では、AndroidとIOSのパフォーマンスを比較します。2つは市場シェアの80％以上を占めています。

Javaアプリはそれ以上の電力を使用しません。（http://www.javarants.com/2004/05/04/looks-like-apple-should-switch/のJava VMまたは実際にはGoogleのDalvik VMは、IOSのObjective-Cよりもはるかに効率的であると考えられています。Javaは、電話で実行される前にコードを最適化できるため、パフォーマンスが大幅に向上する可能性があります。Javaライブラリはオープンソースであるため、数百の異なる開発者によって最適化されています。一方、IOSでは、Apple開発者のみがコードを変更できます。レビューの減少=潜在的なパフォーマンスの低下。

Androidプログラムは、ネイティブCコードを実行することもできます。ネイティブCコードは、Object-C（IOSでサポートされている唯一の言語）よりも高速で議論される可能性があります。

GoogleがDalvik VMの使用を決定した理由は、移植性のためです。Androidが公式に実行できる4つの異なるCPUアーキテクチャ（ARM、MIPS、x86、I.MX）を知っています。他のすべての電話OSは1つしか使用できません（ARM）。（ http://en.wikipedia.org/wiki/Comparison_of_mobile_operating_systems）したがって、さまざまなCPUタイプをたとえばIPhoneと比較することは不公平です。IPhoneでAndroidを実行した場合、Androidは優れたパフォーマンスとバッテリー寿命に匹敵します。

「Javaアプリケーションはより多くの電力を使用しますか？」単にいいえ。
他のプラットフォーム/携帯電話と比較して、Android携帯電話のバッテリー寿命がこんなにひどいのはなぜですか？ 多くのAndroidスマートフォンはAppleのIPhoneよりも安価に製造されていますが、価格の違いに注目してください。IPhoneは、バッテリーが非常に大きいためにコストが高くなります（平均的にCPUが遅くなります）。私のアンドロイド携帯電話（Google Galaxy Nexus）のバッテリー寿命はIPhone 4Gに匹敵しますが、ハードウェア仕様ははるかに高速です（1GHz対1.2GHZ）。

編集：Javaは、プログラマーの知識がなくてもコードを最適化できます。完璧な、Cコードは常にJava / Objective-C / C＃よりも高速に実行されます。そうは言っても、完璧なプログラマーは何人いますか？JVMレベルでは、Javaとライブラリは、そのオープンソース開発の原則により、常に「より完璧」になります。（http://www.infoq.com/news/2012/03/Defects-Open-Source-Commercial）

編集2：ちょっとした情報：Lenovoの新しいP780 Android携帯電話-IPhoneでの12時間対42時間の会話。

はい、それは電力消費の増加に関連しています-抽象化の層がそれを行います。また、速度が低下します（同じコインの反対側-オーバーヘッドが大きい場合、実行に時間がかかり、CPUが多く使用されます）。これがNDKの利点の1つであることが正しく理解できれば、特定のコードを記述して特定のプロセッサの速度を向上させることができます。

とはいえ、ほとんどのジョブでは、VMを実行する「電力関連」のオーバーヘッドは他の考慮事項によってd小化されると想像します。ほとんどのプログラムでは、画面とラジオの使用が電力の大部分を消費します。

他のすべてのポスターに関して、ここで最も重要なのは、C / C ++ / Javaが存在するかどうかではなく、アプリケーションが何をしているのかだと思います。

消費電力は処理と直接マッピングされるため、プログラムがどのような処理を行うのかを自問します。

数字を追加するとします。2.000.000に達するまで、無限ループで2と2を追加するとします。2つの質問が発生します。

1. 実装方法：forループですか？whileループですか？（それはGoto / Labelハックですか？）
2. コードはどのように最適化されていますか。

これらの2つの質問は、最終的にプロセッサが実行する必要がある操作の数と、最終的にはデバイスが使用する電力量を定義します。つまり、仮想化環境を実行する「オーバーヘッド」は、プログラム全体でJavaによって行われた以前の最適化のために無視できるかもしれませんが、それでもアプリケーションの動作に依存します。

はい。

仮想マシンは「すべてを2回実行」しますが、必ずしも効率的ではありません。したがって、彼らは「実機」と同じ命令を処理するために少なくとも2倍の電力を使用します。仮想マシンが存在すると、速度が低下し、より多くの電力が使用されます。基本的に、iOSやWindowsのようなOSは、すべてをより速く、より少ない電力消費で行います。

これは、画面遷移、ページの読み込み、ナビゲーションなどの実際の違いに変換されます。現在、Android（VM）とWindows Phoneを比較し、遅いプロセッサー（1 GHz対1.6 GHz）でさえ、WindowsはAndroidが同じ種類のタスクを実行するよりもはるかに優れています。

ただし、ほとんどの人が注意を引くのは、アプリをインストールすると突然バッテリーがすぐに使い果たされることです。それは実際には仮想マシンによるものではなく、リソースを貪欲に使用するアプリです。

仮想マシンOSの全体的な理由である移植性は、OSの基盤となる正当な理由ではありません。お気に入りのアーキテクチャで携帯電話を購入し、Androidを使用している人はいますか？より高いパフォーマンスと信頼性をあきらめ、Android以外の携帯電話にAndroidを搭載している人を見ていますか？人々はAndroid Phone、Windows Phone、またはIPhoneなどを購入します。低コストのデバイスでの移植性のためにパフォーマンスを犠牲にすることは実用的ではありません。失敗に終わったのは良い考えでした。