Android上常见的性能陷阱？

Question

最简单的错误是哪些可以成为Android上的性能接收器？

文档中提到“某些浮点运算”可能是“毫秒级” - 有人测试了吗？

为了便于讨论，让我们假设它在G1 /类似设备上运行。

Answer 1

wrt浮点：

在G1上，添加两个花车需要大约400ns。添加两个整数大约需要250ns。

在运行eclair（pre-JIT）的nexus上，两个操作大约需要120ns。 （整数稍快一点，但你必须要注意微基准标记。）int和long之间有一小部分差异，浮动和双重，但基本上如果你买得起，你可能买得起另一个。

其他当前设备将介于这两个极端之间。 （其他操作也会有所不同。乘法比加法/减法更昂贵，而且除法更加昂贵。没有当前设备有硬件整数除法。）

但在遇到问题之前不要对此有任何困惑。可能性，你的性能问题将归结为算法或数据结构的糟糕选择，就像每个人的性能问题一样。

大多数当前（eclair）性能文档都不正确。在你关心的设备上自己做基准测试。

---

但是如果你真的在问“桌面/服务器java程序员应该注意什么？”，我建议：不必要的分配。你没有像在桌面/服务器上那样使用备用核心来执行GC，并且你没有像在桌面/服务器上那样拥有数十亿字节的堆。如果你正在做GC，你就没有做真正的工作，你的堆在当前设备上最多只能是24MiB。所以你可能想避免在内部循环中进行不必要的分配。

Answer 2

有关特定于渲染的性能提示，请参阅以下Google I / O 2009演讲：

• Make your Android UI Fast and Efficient
• Writing Real-Time Games for Android

Answer 3

他们希望你避免使用float的原因是因为它很少在手机cpu（Probbly arm）上实现，并且必须用很慢的软件实现。虽然固定点通常用硬件支持。

有些手机确实在硬件中实现了浮点运算，但由于你没有将你的应用程序部署到哪个手机，他们不会冒险。

很多人也说避免使用对象，回到真正慢的手机和java的时代我曾经习惯用静态函数编写java程序。我现在不建议这样做。

Answer 4

在您知道代码存在重大问题之前，请不要担心性能问题。小的调整（整数而不是浮点数，使用迭代器而不是explict数组枚举）往往很小，当你的应用程序关闭时你最好不要看它们。使5％的代码变得更加复杂而不是制作整个应用程序。

Answer 5

根据Android人员的说法，您应该避免使用集合的接口名称。例如，标准Java的标准最佳实践是

List<String> strings = new ArrayList<String>();

在Android中，他们说最好用运行时类型

来声明它

ArrayList<String> strings = new ArrayList<String>();

Answer 6

我发现即使在2014 i3 / 4Gb机器上，AppInventor仿真器的浮点运算速度也非常慢。我写了一个分形生成器来对模拟器进行基准测试，发现要计算一个像素，10次迭代只花了两秒钟 - 是的，2,000ms。我没有完全解开它，发现哪些特定的操作是如此缓慢，但我很快就会这样做。

每次迭代包括四次乘法，两次加法和一次减法，五次变量。每次迭代后的测试包括两次乘法，一次加法和两次比较 - 大约30次触发。我还没有通过存储下一次迭代的结果来优化代码。

显然，如果有办法强制定点或仅使用整数，那将有所帮助，但我面对这个小项目的问题的严重程度并不是一个好兆头。