1. 去掉libxml2
改用rapidxml来解析xml文件。 rapidxml简直是一个大杀器，解析xml的速度甚至比纯文本解析和json格式还要快。其解析速度比libxml2快5倍，即便cocos2d-x中使用的是sax模型，而rapidxml是dom模型，使用rapidxml依然要快非常多。我们的游戏是所有配置文件都用xml来描述，其实大可不必，但是为了跟网页版本配置统一，方便今后的维护，暂时没有对配置格式进行修改。而cocos2d-x底层对xml使用最频繁的地方就是Plist文件的解析了。ios平台下还好，NSDictionary速度也很快（但是依然比rapidxml慢一倍），但是android下效果就非常明显了。游戏启动时间大大缩短。 所以，为什么cocos2d-x还要用libxml2呢？
2、游戏资源打包。
这个虽然是可以自己扩展的，但是却是需要引擎提供支持的。因为所有的图片读取都是属于引擎的内部代码。 当然不是所有的游戏都需要资源打包，但是一个实用（mmo向）的游戏引擎这个是必然要考虑的。 这一块儿牵扯到很多东西，比如游戏资源更新，资源读取规则，读取失败后的异常处理，多线程加载时的同步机制等等。
3、修改CCAssert，增加日志记录功能。
作为一个游戏引擎，cocos2d-x内部代码很不健壮，很多资源不存在或者是不小心的误用都会让程序挂掉。 这个对一个mmo来说是不可接受的。 CCAssert原来是一个简单的assert，这个在ios和android下就直接挂掉了，后面虽然修改为CCMessageBox的提示，但是依然不够方便，因为这些弹出框都很卡很慢。接触过mmo客户端开发的应该都有体会资源不存在是经常发生的事情，尤其是大家一起开发功能的时候，资源总是最后才正确且完整。 这个时候记录个log不就完了。而cocos2d-x却并没有提供任何Log记录功能（实际文件Log而不是开发时用的CCLog）。 而引擎内部有大量的Assert，断定文件一定是存在的，断定某个配置一定是正确的，断定某个Frame一定是存在的，这个造成的问题就是一旦有配置错误，那么程序很可能就崩溃掉了。而作为一个mmo，尤其是已经对外发布的情况下，这个时候出现表现异常(比如图片不显示)而不是崩溃会更加合理。
4、资源异步加载。
虽然cocos2d-x有提供Texture的资源异步加载，但是这并不够用。 我们修改为这样的形式，CCSpriteCache缓存图片的时候异步加载图片，这个时候可以获取到正确的CCSprite,只不过里面的CCTexture并没有附上一个正确的纹理id，当图片加载完毕，这个id就正确了，那么CCSprite在下一次Draw的时候自然就会渲染出正确的图片（这里要做下判断，如果纹理id不正确那么就不进行渲染操作）。 还有需要注意的就是只有一个线程加载图片是不够用的，根据需要可能要开3~5个线程来加载图片，才会起到异步加载图片的最佳体验。 当然，如果仅仅是怕加载图片卡主主线程而不关心加载速度，那么就不需要这么麻烦了。
5、添加一个快速渲染的CCFont
无论是哪个平台生成字形纹理的过程都是非常慢的。如果一个mmo中有大量的文本、聊天等等，光生成字形的时间可能就要500~600ms，那这个游戏给人的感觉就是时不时一卡一卡的。 这个新的CCFont思路非常简单，生成字形的时候一个文字一个文字的进行生成，把生成的字形保存到一个512*512的纹理上，然后渲染的时候取这个生成好的字形进行绘制。
Tools
hotspots
IOS: Time profiler
andriod
其他
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。