Android上的OpenGL是电池杀手吗?

时间:2009-12-25 18:53:04

标签: android opengl-es surfaceview battery

我目前正在实施一个软件键盘(使用一些复杂的预测),并且使用画布绘制它在性能方面是不够的。我的画框绘制时间远远超过100毫秒,这显然是不可接受的。

键盘本身由大约33个键组成,每个键都使用drawRoundRect和上面的简单文本绘制。没有使用任何小部件,所以这是简单的性能。此外,几乎所有的谷歌性能技巧都在使用中,所以这也不是速度的原因。

我现在已经达到了切换到opengl实际上有意义的程度,但考虑到基于opengl的键盘可能对电池寿命产生的影响,我仍然持怀疑态度。

由于我没有找到关于该主题的充分文件,我希望有人能指出我正确的方向。

2 个答案:

答案 0 :(得分:25)

无论耗尽多少电池,您可能都不希望这样做,因为大多数现有设备不同时支持多个OpenGL上下文,因此您的软键盘将与使用的任何应用程序不兼容OpenGL用于自己的绘图。在这些设备上,OpenGL上下文仅由前台应用程序拥有;它不能像软键盘一样用在UI的次要部分。

正如之前的海报所说,你可能最好看看如何优化你的常规绘图。绘制向量非常慢,因此将它们预先渲染到位图中以进行位图blits会有很大帮助。另外要小心,只绘制已更改的窗口部分。 100ms是绘制UI时非常疯狂的时间,因此几乎可以肯定你可以进行重大的优化。您可能希望查看平台中的KeyboardView代码(标准软键盘和示例IME使用);这已包含许多类似的绘图优化。

答案 1 :(得分:4)

抛开:您是否曾考虑过将这些键渲染一次,然后将它们作为精灵抓住并将它们搞砸?它应该远远优于渲染矢量图形。

我不能给你硬数字(正如apphacker指出的那样,这是特定于设备的),但即使OpenGL是硬件加速的,因此可能会使用更多的电池,操作应该更快完成,因此使用更少的功率总。 如果它不是硬件加速的,那么如果完成操作需要更长的时间它应该只使用更多的功率似乎是合乎逻辑的,因为你只是为另一个绘图API交换一个绘图API。 总而言之,因为你只需要在外部事件发生时绘制它,从长远来看它应该没什么关系,因为人们可能每分钟只需要几个键。

您可能只需要实现它(可能在简化的测试用例中)并进行测量。