Android 上的 OpenGL 是电池杀手吗？
我目前正在实现一个软件键盘（使用一些复杂的预测），并且使用画布绘制它在性能方面是不够的。我的帧绘制时间远高于 100 毫秒，这显然是不可接受的。
键盘本身由大约 33 个键组成，每个键都使用 drawRoundRect 和上面的简单 Text 绘制。没有使用任何小部件，因此它的性能很简单。此外，几乎所有谷歌的性能技巧都在使用，所以这也不是速度的原因。
我现在已经达到了切换到 opengl 实际上有意义的地步，但考虑到基于 opengl 的键盘可能对电池寿命的影响，我仍然持怀疑态度。
由于我没有找到关于该主题的足够文档，我希望这里有人能给我指出正确的方向。
I'm currently implementing a software keyboard ( using some sophisticated prediction ), and drawing it using canvas is insufficient in terms of perfomance. I'm getting frame drawing times well above 100ms, which is clearly unacceptable.
The keyboard itself consists of about 33 keys, each of them drawn using drawRoundRect and a simple Text above that. No widgets whatsoever are used, so it's the plain perfomance. Also, almost all of Googles perfomance tips are in use, so thats not the reason for the speed either.
I've now reached a point where switching to opengl actually would make sense, but I'm still sceptical considering the impact an opengl-based keyboard might have on battery life.
As I've found no sufficient documentation on that topic, I hope someone here can point me to the right direction.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
无论它消耗多少电池，您可能都不想这样做，因为大多数现有设备不同时支持多个 OpenGL 上下文，因此您的软键盘将与任何使用 OpenGL 的应用程序不兼容。自己画的。在这些设备上，OpenGL 上下文仅由前台应用程序拥有；它不能用于 UI 的次要部分（如软键盘）。
另外，正如上一张海报所说，您可能最好看看如何优化您的常规绘图。绘制矢量非常慢，因此将它们预渲染为位图以仅执行位图位图传输会很有帮助。另请注意，仅绘制窗口中已更改的部分。 100 毫秒是绘制 UI 所需的相当疯狂的时间，因此几乎可以肯定您可以进行重大优化。您可能想查看平台中的 KeyboardView 代码（由标准软键盘和示例 IME 使用）；这已经包含许多类似的绘图优化。
Regardless of how much it drains the battery, you probably don't want to do this because most existing devices don't support multiple OpenGL contexts at the same time, so your soft keyboard would be incompatible with any application that is using OpenGL for its own drawing. On these devices the OpenGL context is owned only by the foreground application; it can not be used in secondary parts of the UI like the soft keyboard.
Also as the previous poster said, you would probably be best off looking how to optimize your regular drawing. Drawing vectors is quite slow, so pre-rendering them into a bitmap to just do bitmap blits would help a lot. Also be careful to only draw the parts of the window that have changed. 100ms is a pretty insane amount of time to take to draw the UI, so there are almost certainly significant optimizations you can make. You might want to look at the KeyboardView code in the platform (which is used by the standard soft keyboard and sample IME); this already contains many similar drawing optimizations.
旁白：您是否考虑过渲染一次按键，然后将它们作为精灵抓取并进行位块传送？它应该比渲染矢量图形要优越得多。
我无法给你确切的数字（正如 apphacker 指出的，这是特定于设备的），但即使 OpenGL 是硬件加速的，因此可能使用更多的电池，操作应该更快地完成，因此总共使用更少的电量。
如果它不是硬件加速的，那么只有在完成操作需要更长的时间时才应该使用更多的电量，这似乎是合乎逻辑的，因为您只需将一个绘图 API 替换为另一个绘图 API。
总而言之，由于您只需要在外部事件发生时进行绘制，从长远来看，这应该没有多大关系，因为人们可能每分钟只提示几个键。
您可能只需要实现它（也许在简化的测试用例中）并进行测量。
An aside: Have you considered rendering the keys once and then grabbing them as sprites and blitting these? It should be vastly superior to rendering vector graphics.
I cannot give you hard numbers (and as apphacker pointed out, this is device-specific), but even if OpenGL is hardware-accelerated and hence might use more battery, the operation should complete much faster and so use less power in total.
If it is not hardware-accelerated, it seems logical that it should only use more power if it takes longer to complete the operation, as you are only exchanging one drawing API for another.
All in all, as you only have to draw when external events happen it shouldn't matter much in the long run, as people are probably tiping only a few keys per minute.
You'll probably just have to implement it (maybe in a simplified test case) and make measurements.