webdevqa.jp.net

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

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

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

編集:JVMとDalvikを同じ意味で誤って話していたため、回答に基づいていくつかの点を明確にしました。このビットでは、Javaは、より多くの電力を使用するかどうかを尋ねるだけです。使用する場合は、概念的にAndroidにも適用され、実行されます。その結果、バッテリーの寿命が短くなります。

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

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

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

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

  • Javaランタイムはその機能のためにlibcを使用しますか?
  • これらの電力消費に関連するポイントのいずれかがDalvik VMおよびAndroidに変換されますか?
  • 画面やワイヤレスチップセットについて話さずにAndroidのバッテリー消費量が少ないことを一般化する代わりに、iPhone5に最新のNexus電話と比較して小さい1440mAHバッテリーがあることについて話しましょう。この全体一連の思考(Java、仮想プロセッサ、命令マッピング、Android)が生まれたのは、iphoneを愛する友人が、これが彼のiphoneのバッテリー寿命が私の(素晴らしい)ネクサスよりも優れている理由である可能性があると主張したためです。

とにかく、以下の回答に感謝します。

14
PKM

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

  • 「JVM(DalvikVM)」とおっしゃいました。それは「飛行機(自転車)」と言っているようなものです。これら2つのことは互いにまったく関係がありません。

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

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

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

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

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

  • Androidのアプリケーション開発者は、オプションで、Dalvikをバイパスしてネイティブコードを作成することもできます。アプリケーション開発者が、Dalvikがコードのパフォーマンスのボトルネックとして機能している、またはバッテリーの消耗を引き起こしていると感じた場合、Googleの承認を得ることなく、必要に応じてC/C++またはアセンブリコードを記述できます。そうするために、そしてそのように彼らのアプリを配布します。

Androidバッテリー駆動デバイスまたは任意のデバイスで問題が発生する可能性がある実際の理由は次のとおりです。バッテリー寿命あり:

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

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

最後に、Androidのバッテリー寿命の問題は他のモバイルプラットフォームよりも悪いというあなたの評価に同意しません。特定の電話やデバイスは、ハードウェアのエネルギー消費に対するバッテリーの容量が原因で、実際にバッテリー寿命の問題を抱えている可能性があります。最適化が不十分な電源設定(ユーザー、通信事業者、または製造元によって選択されたもの)。または、電話のチップを常に目覚めさせておくブロートウェアアプリ。しかし、バッテリーに問題があるデバイスのすべての例について、優れたバッテリー寿命を持つデバイスの反例を紹介します。 「それはDalvik」または「それはLinux」または「それはJava」を一般化する簡単な方法はありません。電力の最適化は、パフォーマンス、応答性、バッテリー寿命に対するユーザーの期待など、競合する懸念事項の複雑なハードウェア/ソフトウェアのミッシュモッシュであり、それぞれに長所と短所があります。デバイスの電力プロファイルを完全に理解するには、バッテリー自体、すべてのハードウェア、およびデバイスで実行されているすべてのソフトウェアを詳しく調べる必要があります。

25
allquixotic

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

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

Androidプログラムは、ネイティブ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は不公平です。AndroidがIPhoneで実行された場合、Androidは優れたパフォーマンスとバッテリー寿命に匹敵します。

"do Javaアプリケーションはより多くの電力を使用しますか?"単にいいえ。
なぜAndroid電話は他のプラットフォーム/電話と比較してそのような恐ろしいバッテリー寿命を持っていますか?多くのAndroid電話はAppleのIPhoneよりも安価に作られていますが、価格の違いを見てください。IPhoneにはバッテリーがはるかに大きいため、コストが高くなります(そして、平均してCPUが遅くなります)。MyAndroid phone( 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電話-42時間の会話vs12時間のiPhone。

5
Mark Lopez

はい、それは電力消費の増加に関連しています-抽象化レイヤーがそれを行います。また、速度が低下します(同じコインの反対側-オーバーヘッドが大きい場合、実行に時間がかかり、CPUの使用量が増えます)。私が正しく理解していれば、それが [〜#〜] ndk [〜#〜] の利点の1つであり、特定のコードを記述することで特定のプロセッサの高速化が可能になります。

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

3
davidgo

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

消費電力は処理に直接関係するので、プログラムはどのような処理をするのか自問します。

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

  1. それはどのように実装されますか:それはforループですか? whileループですか? (それは後藤/ラベルハックですか?)
  2. コードはどのように最適化されていますか。

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

3

はい。

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

これは、画面の遷移、ページの読み込み、ナビゲーションなどの実際の違いに変換されます。現在、Android(VM)とWindows Phoneを比較しており、プロセッサが遅い(1GHzと1.6GHz)場合でも、WindowsはAndroid同じ種類の処理を大幅に上回っています。タスクの。

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

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

0
user310981