年前在对我做的项目做性能优化，虽然在开发中，性能问题是一直关注着的，但是这个东西依然需要在后期做一段时间的优化的，也遇到不少坑，在这里分享下，也记作笔记，另外也欢迎大家有这方面的问题经验在这里讨论。

性能的优化主要是亮点，内存的优化和运行效率的优化

1.内存的优化

说内存的优化，首先要知道有什么东西会占据程序的内存，可优化的主要是两部分：数据和资源，先说数据，做短连接的游戏客户端有两种处理数据的方式：一种是傻瓜式客户端，另一种是缓存式客户端，傻瓜客户端几乎可以做到0数据，因为他每个界面只是负责展示，当然，这个界面需要的数据是会存在客户端的，但是他对内存的占据是可以忽略的，基本也是不可优化的，除非你有内存泄露。另一种是客户端会负责一些逻辑，它不仅有缓存的用户数据，还有配置数据（策划配置的游戏数据），这些数据的大小有时甚至要超出你的想象（不会比图少多少）；再说资源，主要是图和声音，这两种资源的优化处理只要掌握好如下原则就可以（同样适用于数据）

（1）不要对内存的释放置之不理

在j2me时代，由于没有通用的引擎和框架，程序员实现界面切换时常会自觉地做无用资源的释放，但是在智能机时代，这种“好习惯”由于系统的“强大”常常被人忽略；我见过不止一个项目的程序在使用cocos2d-x时是不考虑资源释放的，因为系统的自动回收机制，这点甚至有些线上项目都不会考虑；关于这点，你要知道的是，系统的内存回收机制是这样的，他会有一个安全“临界值”，注意这个值会小于系统的极限，每当到这个临界值时系统会帮你清理你没有泄露的内存，但是请不要过于相信这种方式，虽然临界值小于最大值，假设临界值是180m，最大值是200m，如果你进了一个场景，进场景之前是175，未到临界值，但是这个界面加载了30m的东西，还没等回收起作用，内存已经超过了最大的200m上限，这时肯定会崩溃，因此，保持主动地做无用资源的删除是个好习惯。这个原则包括数据和资源

(2) 随用随加载vs缓存

既然要随时删除无用资源，那么我们就不要任何缓存了吧？貌似这两种方式就是对立的，也有人会说，随用随加载很浪费效率，没错，如果想处理好程序性能，这两种方式真的不能对立来看，而是要结合起来用；对于图片资源，我是这么做的，每个界面都会用到的公用图片我会放在一张图片拼板中（或者是几张），这些图片会“常驻”内存，这个拼板会包括，常用的按钮，背景，小图标等等，这些图片是缓存的，对于其他的图片，一定要把这个界面用到的除公用图片外的图片打在一起，这样，当进入这个界面的时候，只需要加载这些就可以，当离开界面时，需要把他们删除，这些是随用随加载的，这个原则同样用于数据当中，把常用的数据（加载时间会比较长的）读入内存中，其他数据随用随加载，注意不用时要删除，我也见过一些项目，数据是从来不清的，因此他们根本没有最大内存的这个概念，内存会像雪球一样，越滚越大，直到所有数据都在内存里，这种做法和把所有数据都读进来无异。

（3）大图片vs小碎图？内存上限

其实关于内存的大小，最不能突击解决的就是“大图片还是小碎图”，这涉及到美术和程序的配合，程序的责任心等等，用大图片，程序拼界面会比较省事，也会提高程序运行效率，但是小图片会节约内存，当然这也有个度的问题，这就涉及到内存上限的问题，根据目前的设备，一般把内存控制到120左右是比较安全的，确定可执行的实际的内存上限目标也是比较重要的。

除了这些原则，你还要直到cocos2d-x关于内存处理的一些“坑”

（1）plist删了，你的图片真的删了吗？

CCSpriteFrameCache中的removeSpriteFramesFromFile函数中传入plist的名字就会删除这个图片的数据文件，具体的就是读入plist文件时生成的字典，它只是解除了图片的引用，但是删除具体的图片，需要调用CCTextureCache的removeUnusedTextures，注意，先调用前面的函数，后调用这个函数才会起作用，需要注意的是，使用ccb是会帮你调用removeSpriteFramesFromFile的，另外removeSpriteFramesFromFile传递的plist的名字如果不存在，也会出问题，最好的办法是改一下removeSpriteFramesFromFile，做一下容错，另外最好是前一帧调用removeSpriteFramesFromFile，后一帧调用removeUnusedTextures和dumpCachedTextureInfo，这样才会起作用，因为引用删除后，才会删除他们引用的图片

（2）lua的内存泄露

有时在游戏中需要重新登录，这时比较常用的处理方式是把CCLuaEngine::defaultEngine()指针指向的部分删除，但是，这种粗暴的方式可能会造成一些内存泄露，需要在前面加入如下代码

（3）lua中table可能的内存泄露

一般情况下，直接“table = nil”，在经过垃圾回收器的回收内存（lua这点类似java），就可以释放内存了，但是，在有些特殊情况下，垃圾收集器是无法准确的判断是否应该将当前对象清理。这样就极有可能导致很多垃圾对象无法被释放。这种情况就是交叉引用