Android drawBitmap 对于大量位图的性能？
我正在编写 Android 游戏，但在画布上绘制时似乎遇到了性能问题。我的游戏有多个关卡，每个关卡中（显然）有不同数量的对象。
奇怪的是，在一个包含 45 个图像的关卡中，运行完美（几乎 60 fps）。然而，另一个包含 81 个图像的关卡几乎根本无法运行（11 fps）；它几乎无法播放。除了我之外，这对任何人来说都显得很奇怪吗？
我使用的所有图像都是 .png，上述级别之间的唯一区别是图像数量。
这是怎么回事？ Canvas 不能在每个游戏循环中绘制这么多图像吗？你们会如何建议我改进这种性能？
提前致谢。
I'm in the process of writing an Android game and I seem to be having performance issues with drawing to the Canvas. My game has multiple levels, and each has (obviously) a different number of objects in it.
The strange thing is that in one level, which contains 45 images, runs flawlessly (almost 60 fps). However, another level, which contains 81 images, barely runs at all (11 fps); it is pretty much unplayable. Does this seem odd to anybody besides me?
All of the images that I use are .png's and the only difference between the aforementioned levels is the number of images.
What's going on here? Can the Canvas simply not draw this many images each game loop? How would you guys recommend that I improve this performance?
Thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我也觉得很奇怪。我也在开发一个游戏，关卡很多，我可以轻松地在屏幕上显示100个游戏对象，还没有看到类似的问题。
使用得当，drawbitmap 确实应该非常快；它只不过是一个复制命令。我什至不会画圆；我天生就不会画圆。我有预渲染圆圈的位图。
然而，Android 中位图的性能对您的操作方式非常敏感。创建位图可能非常昂贵，因为 Android 默认情况下可以自动缩放 png，这是 CPU 密集型的。所有这些事情都需要在渲染循环之外完成一次。
我怀疑你找错地方了。如果您以相同的方式创建和使用相同类型的图像，那么将屏幕图像数量加倍不会使性能降低超过 4 倍。最多应该是线性的（2 倍）。
我的第一个怀疑是你的大部分 CPU 时间都花在了碰撞检测上。与绘制位图不同，这通常会随着交互对象数量的平方而增加，因为必须测试每个对象是否与其他对象发生碰撞。您将游戏对象的数量增加了一倍，但您的性能却下降到四分之一，即根据对象数量的平方。如果是这种情况，请不要绝望；有多种进行碰撞检测的方法，这些方法不会随着对象数量的平方而增长。
同时，我会进行基本测试。如果您实际上没有绘制一半的对象，会发生什么？游戏运行得更快吗？如果不是的话，那就和画画无关了。
Seems strange to me as well. I am also developing a game, lots of levels, I can easily have a 100 game objects on screen, have not seen a similar problem.
Used properly, drawbitmap should be very fast indeed; it is little more than a copy command. I don't even draw circles natively; I have Bitmaps of pre-rendered circles.
However, the performance of Bitmaps in Android is very sensitive to how you do it. Creating Bitmaps can be very expensive, as Android can by default auto-scale the pngs which is CPU intensive. All this stuff needs to be done exactly once, outside of your rendering loop.
I suspect that you are looking in the wrong place. If you create and use the same sorts of images in the same sorts of ways, then doubling the number of screen images should not reduce performance by a a factor of over 4. At most it should be linear (a factor of 2).
My first suspicion would be that most of your CPU time is spent in collision detection. Unlike drawing bitmaps, this usually goes up as the square of the number of interacting objects, because every object has to be tested for collision against every other object. You doubled the number of game objects but your performance went down to a quarter, ie according to the square of the number of objects. If this is the case, don't despair; there are ways of doing collision detection which do not grow as the square of the number of objects.
In the mean time, I would do basic testing. What happens if you don't actually draw half the objects? Does the game run much faster? If not, its nothing to do with drawing.
我认为本讲座会对您有所帮助。转到45分钟。有一张图比较了Canvas方法和OpenGl方法。我想这就是答案。
I think this lecture will help you. Go to the 45 minute . There is a graph comparing the Canvas method and the OpenGl method. I think it is the answer.
我遇到了类似的性能问题 - 即，级别 1 运行得很好，而级别 2 却没有
，这不是渲染错误（至少不是具体错误）。这是造成瓶颈的关卡逻辑的其他特定因素。
重点是...Traceview 是您最好的朋友。
方法分析显示了 CPU 的时间花费在哪里以及帧速率发生故障的原因。 （顺便说一下，第 2 级的渲染成本也较高，但不是瓶颈）
I encountered a similar problem with performance - ie, level 1 ran great and level 2 didn't
Turned it wasn't the rendering that was a fault (at least not specifically). It was something else specific to the level logic that was causing a bottleneck.
Point is ... Traceview is your best friend.
The method profiling showed where the CPU was spending its time and why the glitch in the framerate was happening. (incidentally, the rendering cost was also higher in Level 2 but wasn't the bottleneck)