Android でパフォーマンスが低下する可能性がある、最も犯しやすい間違いは何ですか?
ドキュメントには、「一部の浮動小数点演算」は「ミリ秒単位」である可能性があると記載されています-誰かがこれをテストしましたか?
議論のために、G1/同様のデバイスで実行されていると仮定しましょう。
Android でパフォーマンスが低下する可能性がある、最も犯しやすい間違いは何ですか?
ドキュメントには、「一部の浮動小数点演算」は「ミリ秒単位」である可能性があると記載されています-誰かがこれをテストしましたか?
議論のために、G1/同様のデバイスで実行されていると仮定しましょう。
wrt浮動小数点:
G1では、2つのフロートを追加するのに約400nsかかります。2つのintを追加すると、約250nsかかります。
エクレアを実行しているネクサス1(JIT以前)では、両方の操作に約120nsかかります。(intは少し高速ですが、気付くにはマイクロベンチマークが必要です。)intとlong、floatとdoubleの間にはわずかなパーセンテージの違いがありますが、基本的に一方を買う余裕があれば、もう一方を買う余裕があります。
他の現在のデバイスは、これらの両極端の間のどこかにあります。(他の演算も異なります。乗算は加算/減算よりも高価であり、除算はさらに高価です。現在のデバイスにはハードウェア整数除算がありません。)
しかし、問題が発生するまで、これに執着しないでください。おそらく、パフォーマンスの問題は、すべての人のパフォーマンスの問題が常にそうであるように、アルゴリズムまたはデータ構造の不適切な選択に帰着します。
現在の(eclair)パフォーマンスドキュメントのほとんどは正しくありません。気になるデバイスで、自分でベンチマークを行います。
しかし、もしあなたが本当に「デスクトップ/サーバーのJavaプログラマーは何に気をつけるべきか」と尋ねているのなら、私は提案するでしょう:不必要な割り当て。デスクトップ/サーバーのようにGCを実行するための予備のコアがなく、デスクトップ/サーバーのようにギガバイトのヒープもありません。GCを実行している場合、実際の作業は実行されておらず、ヒープは現在のデバイスで最大24MiBになります。したがって、内部ループでの不要な割り当てを避けたい場合があります。
レンダリング固有のパフォーマンスに関するヒントについては、Google I/O 2009 の講演を参照してください。
Androidの人々によると、コレクションにインターフェイス名を使用することは避けてください。たとえば、標準Javaの標準的なベストプラクティスは次のようになります。
List<String> strings = new ArrayList<String>();
Androidでは、ランタイムタイプで宣言する方が良いと言われています。
ArrayList<String> strings = new ArrayList<String>();
float の使用を避けてほしい理由は、電話の CPU (おそらく腕) に実装されることはめったになく、遅いソフトウェアに実装する必要があるためです。ただし、固定小数点は通常ハードウェアでサポートされています。
一部の電話はハードウェアに浮動小数点を実装していますが、アプリが展開される可能性のある電話がないため、リスクはありません。
多くの人は、オブジェクトの使用を避けるとも言います。非常に遅い電話や Java の時代には、静的関数を使用してプロシージャルに Java を記述していました。今はお勧めしませんが。
2014 i3/4Gb マシンでも、AppInventor エミュレータの浮動小数点演算が非常に遅いことがわかりました。エミュレーターのベンチマークを行うためにフラクタル ジェネレーターを作成したところ、1 つのピクセルを計算するのに 10 回の反復に 2 秒強 (そう、2,000 ミリ秒) かかることがわかりました。どの特定の操作が非常に遅いかを見つけるために完全に選択を解除したわけではありませんが、すぐにそれを行う予定です。
各反復には、4 つの乗算、2 つの加算、1 つの減算、5 つの変数が含まれます。各反復後のテストには、2 つの乗算、1 つの加算、および 2 つの比較 (約 30 フロップ) が含まれます。次の繰り返しのために結果を保存してコードを最適化していません。
明らかに、固定小数点を強制する方法や整数のみを使用する方法があれば、それは役に立ちますが、この小さなプロジェクトで私が直面した問題の大きさは、良い兆しではありません。
コードに重大な問題があることがわかるまでは、パフォーマンスについて心配する必要はありません。小さな調整 (float の代わりに int、明示的な配列列挙の代わりにイテレータを使用) は非常にマイナーな傾向があり、アプリがダウンしているときにそれらを確認することをお勧めします。アプリ全体を作成するのではなく、遅いコードの 5% をより複雑にします。