blocks|key|1299104|text|对于不需要太多有效数字(如屏幕偏移量)的指标，使用doubles而不是floats将是内存低效的。在移动设备上，最大限度地提高内存消耗效率至关重要，因为在移动设备上，几乎所有资源都非常宝贵。而且，在处理像Rect这样的对象时--这些对象可能会被数千人分配--减少多余的位数显然是至关重要的。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1299105|我相信还有其他原因:-)|1299106|entityMap^0|P|6|Z|5|2U|4|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@$9|K|A|L|B|C]|$9|M|A|N|B|C]|$9|O|A|P|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|Q|8|@]|D|@]|E|$]]|$1|H|3|-4|5|6|7|R|8|@]|D|@]|E|$]]]|I|$]]

For metrics that don't need too many significant digits (such as screen offsets), it would be memory-inefficient to use <code>double</code>s instead of <code>float</code>s. Maximizing efficiency with regards to memory consumption is vitally important on mobile devices, where pretty much every resource is at a premium. And, when dealing with objects such as <code>Rect</code>s&mdash;that could potentially be allocated by the thousands&mdash;it is clearly crucial to cut down on excess bits.

I'm sure there are other reasons too :-)

blocks|key|1299165|text|真奇怪。指南中的性能设计似乎是在说：“桌面系统上的常见做法是使用浮点freely......so所有对"....The”和"double“的操作都是在软件中执行的……”在http://developer.android.com/guide/practices/design/performance.html#avoidfloat|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1299166|这可能有一定的道理："....Instructions并不是无缘无故地局限于特定类型的。例如，移动32位寄存器值而不进行解释的指令不必指定它们是移动整数还是浮点数……“在http://www.netmite.com/android/mydroid/dalvik/docs/dalvik-bytecode.html|1299167|entityMap|0|LINK|mutability|MUTABLE|url|http://developer.android.com/guide/practices/design/performance.html#avoidfloat|1|http://www.netmite.com/android/mydroid/dalvik/docs/dalvik-bytecode.html^0|2D|27|0|0|2D|1Z|1|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@$A|Q|B|R|1|S]]|C|$]]|$1|D|3|E|5|6|7|T|8|@]|9|@$A|U|B|V|1|W]]|C|$]]|$1|F|3|-4|5|6|7|X|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]|N|$5|I|J|K|C|$L|O]]]]

Weird. Designing for Performance in the guide seems to say "....The common practice on desktop systems is to use floating point freely......so all operations on "float" and "double" are performed in software...." at <a href="http://developer.android.com/guide/practices/design/performance.html#avoidfloat" rel="nofollow noreferrer">http://developer.android.com/guide/practices/design/performance.html#avoidfloat</a>

This may make some sense:
"....Instructions aren't gratuitously limited to a particular type. For example, instructions that move 32-bit register values without interpretation don't have to specify whether they are moving ints or floats....."
at <a href="http://www.netmite.com/android/mydroid/dalvik/docs/dalvik-bytecode.html" rel="nofollow noreferrer">http://www.netmite.com/android/mydroid/dalvik/docs/dalvik-bytecode.html</a>

blocks|key|1299215|text|根据CPU的不同，将没有浮点单元(FPU)。因此，它必须在软件中模拟FPU。这对于浮点型比双精度型更快。或者，如果设备有FPU，那么使用浮点数可能也会更快。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1299216|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Depending on the CPU there will be no Floating Point Unit (FPU). So it has to emulate the FPU in Software. this is faster for a Float than for a Double. Or if the Device has a FPU it will be probably also be faster with Floats.

blocks|key|1084213|text|我认为Roman是正确的，原因可能主要是为了减少内存使用。考虑一下，当最终精度不是很重要时，你会将数值变量所需的内存减半。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1084214|但是请记住，使用强制转换并不是必需的。只需在文字后面附加一个F(因此2.5变成2.5f)。我不知道编译器是否足够智能来为您做以下替换，但如果不是，这将使您的代码稍微更有效率。|1084215|考虑一下|1084216|float+x+=+(float)+2.5;|code-block|syntax|javascript|1084217|和|1084218|float+x+=+2.5f;|1084219|在第一种情况下，在运行时，程序存储双精度值，然后执行强制转换操作，然后存储结果浮点值。在第二种情况下，编译器会将值识别为浮点型，因此在运行时，您既避免了存储双精度值(尽管这可能是暂时的)，也避免了强制转换操作(因为它已经存储为浮点型)。|1084220|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|T|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|U|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|V|8|@]|9|@]|A|$I|J]]|$1|K|3|L|5|6|7|W|8|@]|9|@]|A|$]]|$1|M|3|N|5|H|7|X|8|@]|9|@]|A|$I|J]]|$1|O|3|P|5|6|7|Y|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|R|$]]

I think Roman is correct, that the reason is likely mostly intended to reduce memory usage. Consider that when ultimate precision isn't important you will halve the memory needed for numeric variables.

Remember though that it isn't necessary to use casting. Simply append an F to your literal (so 2.5 becomes 2.5f). I don't know if the compiler is smart enough to do the following substitution for you, but if not, this will make your code slightly more efficient as well.

Consider

<pre><code>float x = (float) 2.5;
</code></pre>

and 

<pre><code>float x = 2.5f;
</code></pre>

In the first case, at run time, the program stores a double, then carries out a cast operation, before storing the resulting float value. In the second case the compiler will recognize the value as a float, so at run time you avoid both the storing of a double (however temporarily that might be) and also avoiding the cast operation (since it is already stored as a float).

blocks|key|1084277|text|在没有FPU的设备上，单精度浮点运算比双精度浮点运算要快得多。正因为如此，Android框架提供了一个FloatMath类，它复制了一些java.lang.Math函数，但使用了浮点参数而不是双精度。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1084278|在最新的带有FPU的Android设备上，单精度和双精度操作所需的时间大致相同，并且比软件实现快得多。(“为性能而设计”页面是为G1编写的，需要更新以反映各种更改。)|1084279|顺便说一句，写"2.5f“或”(浮点数)+2.5“并不重要。无论哪种方式，javac都知道您需要一个单精度的浮点数常量，这就是它生成的结果。您可以通过编写示例程序并检查生成的字节码来验证这一点。|1084280|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

On devices without an FPU, the single-precision floating point ops are much faster than the double-precision equivalents. Because of this, the Android framework provides a FloatMath class that replicates some java.lang.Math functions, but with float arguments instead of double.

On recent Android devices with an FPU, the time required for single- and double-precision operations is about the same, and is significantly faster than the software implementation. (The "Designing for Performance" page was written for the G1, and needs to be updated to reflect various changes.)

Incidentally, writing "2.5f" or "(float) 2.5" doesn't matter. Either way, javac knows you want a single-precision float constant, and that's what it generates. You can verify this by writing a sample program and examining the bytecode generated.

The default floating point type in Java is the double. If you hard code a constant like <code>2.5</code> into your program, Java makes it a double automatically. When you do an operation on floats or ints that could potentially benefit from more precision, the type is 'promoted' to a double.

But in the Android API, everything seems to be a float from sound volumes to rectangle coordinates. There's a structure called <code>RectF</code> used in most drawing; the F is for float. It's really a pain for programmers who are casting promoted doubles back to <code>(float)</code> pretty often. Don't we all agree that Java code is messy and verbose enough as it is?

Usually math coprocessors and accelerators prefer double in Java because it corresponds to one of the internal types. Is there something about Android's Dalvik VM that prefers floats for some reason? Or are all the floats just a result of perversion in API design?

Why are there so many floats in the Android API?

编译器

Android

Java

Java中默认的浮点类型是double。如果您将像2.5这样的常量硬编码到您的程序中，Java会自动将其设置为双精度。当你在浮点数或整型数上进行可能从更高精度中受益的操作时，该类型被‘提升’为双精度型。但在Android API中，从音量到矩形坐标，一切似乎都是浮动的。在大多数绘图中有一个叫做RectF的结构；F代表浮...

问为什么Android API中有这么多浮点数？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么Android API中有这么多浮点数？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么Android API中有这么多浮点数？
EN