5、始终在处理复杂绘图时直接准备贴图而非由程序绘制。

我们都知道Java绘图事实上是GDI实现，因此其绘制复杂画面的效率也就可想而知。通常强况下，除非当前的效果非编程不能实现，或者其所造成的资源损耗确实微小到可以忽略不计，否则最好的方法就是用空间换效率，准备好图片直接贴上去吧，宁可增加些程序体积，也不要让玩家因等待的愤怒而问候你祖宗八辈。

Java游戏开发中应始终坚持的10项基本原则(2)

6、始终保证repaint仅刷新需要部分，避免无谓的全局重绘。

每repaint一次，事实上就是将paint中的图形打印到窗体上一次，窗体越大，处理的图像越复杂，repaint所造成的资源损耗也势必越多，运行效率也势必越低。但反过来说，由于Java允许我们限定repaint的范围，因而我们可以将刷新限定在某一特定区域内，更准确地说我们可以仅在需要变更画面的位置上才进行刷新，以此将损耗降低到最低限度，总体上说，即使我们会因为计算刷新区域额外花费些许时间，总体上讲也比全局repaint要快得多。

7、始终双缓冲游戏图像避免闪烁现象发生。

对于Java绘图而言，每次调用repaint方法时都会清除整个屏幕，然后paint才显示画面。而万一系统速度不够，在清除背景和绘制图像间的短暂间隔内被用户看见，就出现了所谓的闪烁现象；简单来讲闪烁的成因就是运算效率不足，使得repaint与paint不连贯造成的。

针对这种情况，我们需要利用双缓冲技术加以解决。

双缓冲实现其实简单至极，主要过程就是先创建一个等大小于希望绘制图形的Image，而后取得其Graphics，每当paint绘图时我们不直接将图像绘制于paint函数的Graphics上，而是绘制于我们创建的缓冲图像的Graphics上，当绘制完成后再调用paint函数提供的 drawImage方法，将整个后台图像一次画到屏幕上去。这种方法的优点在于大部分绘制是在后台进行的。将后台绘制的图像一次绘制到屏幕上。

这时只要系统速度正常，我们所看到的绘图将不再有闪烁现象发生。

8、始终在自绘组件的桌面游戏中应用AWT或SWT而非Swing。

众所周知，Swing(JFC)的GUI是以AWT为基础在本地窗体绘制而成，相较AWT虽然提供了更为丰富的组件，但也意味着它占用了更多的资源。而事实上，大多数Java桌面游戏组件是由开发者所针对性绘制，并非Swing库提供，也不需要Swing库支持，我们完全可以放弃Swing而选择AWT或 SWT（SWT绘图与AWT/Swing绘图在方法上略有区别，但本质一样）这种直接Native而来的界面，实在不需劳动Swing他老人家，平白的耗费掉那些本就因使用Java应用而稀缺的系统资源。

9、始终别忘了在Graphics处理完毕后dispose。

Graphics的dispose与数据库Connection的close可谓异曲同工。为此我特意做了一个实验，在死循环中无间隔无优化的反复 repaint一幅2000X2000的大图，应用dispose时虽然刷新很慢并伴随闪烁但总体讲正常，而去掉dispose运行大约一分钟后万恶的溢出大神降临……

当然，就像Connection应在全部操作完成后才close一样，Graphics也仅在全部绘图完毕后才需要dispose，也就是当最后一个paint最后一次draw后，别忘了留个dispose关门，除非你很想看见溢出大神……

10、始终以运算效率为第一优先，可适当放弃代码可读性，可适当违背OO原则。

以Java进行游戏开发，最大的问

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!