先编码，然后考虑性能的提高
首先，在设计和开发游戏的时候，首要得规则是不要考虑任何性能方面的因素
只专心的编码。最初编码的时候，需要将注意力集中在保持代码整洁、可运行且易
懂上。然后才谈得上性能评价和修正该修正的地方。否则，你所能得到的也许仅仅
是时间的浪费，甚至由于不必要的性能扩展阻碍了游戏的开发。通过剖析程序代码
也能发现最经常被执行到的部分，增加仅仅会有 10%的几率执行到的那部分代码
的执行效率是没有什么意思的，这常常被称为二八原理、或一九原理，所以要尽量
增加最经常被执行到的部分的执行效率。提高效率的好的方法是，测试被更改代码
确定的分支的，通过比较于更改前效率的差别来确定更改后是否对效率的提高有帮
助，还是仅仅提高了一点点效率却给代码带来了很大的混乱，这样就得不偿失了。
当对代码的更改对效率的提高不明显时，建议还是维持代码的抽象性、复用性和易
维护性比较好。
减少面向对象的代码
通常，面向对象的语言往往趋向于更多的类、更多的使用帧、设计模式被用于
几乎每一个设计中。这种情况通常是好的，但是在移动领域，由于内存的限制，面
向过程的程序设计方法有时候是更受欢迎的。虽然不太容易让人接受，你需要避免
使用 MVC(Model-View-Controller)模式，因为这种设计模式会让你的代码量呈指数
性增长。话虽这样说，也不要完全按照面向过程的方式编码，只要有这样的想法就
好了，当面对性能或内存的问题时，你也许需要用面向过程的方法代替面向对象的
编程方式来解决。
减少第三方库的使用
上面已经讲过了尽量减少类的使用，当然也要避免使用第三方的 API 来存储空
间和运行空间的使用。例如，在网络通讯时使用自己定义的数据解析可能会提高游
戏的运行效率，要避免使用一个更加抽象的工业化定义的通讯方法如 SOAP 网络协
议。因为这个协议不仅会增加程序的大小，也会带来解析和建立 XML 数据传递的
额外过程。
最少的通讯
为了提高网络通讯的性能，需要避免不断地从服务器取回数据。例如，Web 开
发中，大的图像被分成很多小的部分然后分别取回，但是在移动设备的程序中，为
了避免延迟出现几率的增加，一次取回所有要用到的资源是明智的
组合图像
每个游戏都会有的资源是图片，通过将游戏用到的各个图像组合到一个大的图
像中，不但可以减少网络游戏中的延迟，也可以减少游戏的大小。因为每个图片的
开头都包含预定义的信息，如果有 10 个图片那么就有 10 个相同的这种信息。当然
需要从组合图像中析取单个的图像的算法，后面会详细讲述。
游戏中的图像要尽量最优化并且压缩。但是要注意，并不是所有的图形图像优
化工具的默认选项都是完全符合要求的。
垃圾回收
作为一名 JAVA 程序员，虽然我们不能不使用 JVM 的垃圾自动回收机制，但是
我们可以通过一些措施来促进垃圾回收，如将不再使用的对象赋值为 NULL，又如
使用对象池重新利用对象从而避免建立新的对象。也可以通过调用 System.gc()或者
Runtie.getRuntime().gc()来强制执行垃圾回收，顺便提一下，有一些人相信这种方法
是可行的，而另一些人则不这么认为。为了防止陷入另一个永无止境的争论，建议
读者还是按照自己的喜好处理内存，并且自己决定采取何种方式。但是要注意在不
同的移动设备上相同的代码可能会有完全不同的执行结果。
短小的名称 及 混淆机制
同减少类的总量相比，通过减少变量名、类名、方法名的长度来压缩应用程序
的大小，不失为一个更好的办法。如果可能的话，只使用默认的包，而不要创建不
需要的包结构。
如果将所有的变量、方法、类的名称都用一个或两个字母代替，那程序代码的
可读性就会大大降低，这里介绍一下混淆器的概念。使用混淆器来处理代码后，它
会将代码中长的名称都替换成简短的名称，从而使代码更短小。同时也带来了另一
个好处，就是通过混淆器编译后的代码，就算再被反编译也很难读懂。如下是一些
可用的混淆器：
ProGuard – http://proguard.sourceforge.net/
SourceGuard – http://www.javalobby.com/
RetroGuard – http://www.retrologic.com/
CodeShield – http://www.codingart.com/codeshield.html
yGurad – http://www.yworks.de/en/products_yguard_about.htm
IBM JAX – http://www.alphaworks.ibm.com/tech/JAX
JShrink – http://www.e-t.com/jshrink.html
相关文章
