Javaのデフォルトの浮動小数点型はdoubleです。プログラムのように定数をハードコーディングする2.5と、Javaは自動的にそれをdoubleにします。より高い精度の恩恵を受ける可能性のあるfloatまたはintに対して操作を行うと、型はdoubleに「昇格」されます。
しかし、Android APIでは、音量から長方形の座標まで、すべてがフロートのように見えます。RectFほとんどの描画で使用されると呼ばれる構造があります。Fはフロート用です。(float)昇格したダブルをかなり頻繁にキャストしているプログラマーにとって、それは本当に苦痛です。私たちは皆、Javaコードがそのまま乱雑で冗長であることに同意しませんか？
通常、数学コプロセッサーとアクセラレーターは、内部型の1つに対応するため、Javaではdoubleを好みます。何らかの理由でフロートを好むAndroidのDalvikVMについて何かありますか？それとも、すべてのフロートはAPI設計の転覆の結果にすぎませんか？
FPUのないデバイスでは、単精度浮動小数点演算は倍精度の同等の演算よりもはるかに高速です。このため、Androidフレームワークは、一部のjava.lang.Math関数を複製するFloatMathクラスを提供しますが、doubleではなくfloat引数を使用します。
FPUを搭載した最近のAndroidデバイスでは、単精度と倍精度の操作に必要な時間はほぼ同じであり、ソフトウェアの実装よりも大幅に高速です。（「パフォーマンスの設計」ページはG1用に作成されており、さまざまな変更を反映するように更新する必要があります。）
ちなみに、「2.5f」や「（float）2.5」と書いても構いません。いずれにせよ、javacは単精度浮動小数点定数が必要であることを認識しており、それが生成されます。これは、サンプルプログラムを作成し、生成されたバイトコードを調べることで確認できます。
CPUによっては、浮動小数点ユニット（FPU）はありません。したがって、ソフトウェアでFPUをエミュレートする必要があります。これは、ダブルよりもフロートの方が高速です。または、デバイスにFPUがある場合は、Floatを使用した方がおそらく高速になります。
有効数字をあまり必要としないメトリック（画面オフセットなど）の場合、doublesの代わりにfloatsを使用するとメモリ効率が悪くなります。ほとんどすべてのリソースが貴重なモバイルデバイスでは、メモリ消費に関する効率を最大化することが非常に重要です。また、数千人が割り当てる可能性のあるsなどのオブジェクトを処理する場合Rectは、余分なビットを削減することが明らかに重要です。
他にも理由があると思います:-)
変。ガイドのパフォーマンスの設計では、「....デスクトップシステムでの一般的な方法は、浮動小数点を自由に使用することです......したがって、「float」と「double」のすべての操作はソフトウェアで実行されます... 。" http://developer.android.com/guide/practices/design/performance.html#avoidfloat
これは理にかなっているかもしれません： "....命令は特定のタイプに無償で制限されていません。たとえば、解釈なしで32ビットレジスタ値を移動する命令は、intまたはfloatのどちらを移動するかを指定する必要はありません。 ...」http://www.netmite.com/android/mydroid/dalvik/docs/dalvik-bytecode.html
ローマ人は正しいと思います。その理由は主にメモリ使用量を減らすことを目的としているからです。究極の精度が重要でない場合は、数値変数に必要なメモリを半分にすることを考慮してください。
ただし、キャストを使用する必要はないことを忘れないでください。リテラルにFを追加するだけです（2.5は2.5fになります）。コンパイラが次の置換を実行できるほど賢いかどうかはわかりませんが、そうでない場合は、コードの効率も少し向上します。
検討
float x = (float) 2.5;
と
float x = 2.5f;
最初のケースでは、実行時に、プログラムはdoubleを格納し、次にキャスト操作を実行してから、結果のfloat値を格納します。2番目のケースでは、コンパイラは値をfloatとして認識するため、実行時にdoubleの格納（一時的に可能性があります）とキャスト操作（すでにfloatとして格納されているため）の両方を回避します。