标签：
作者导语
年前在对我做的项目做性能优化，虽然在开发中，性能问题是一直关注着的，但是这个东西依然需要在后期做一段时间的优化的，也遇到不少坑，在这里分享下，也记作笔记，另外也欢迎大家有这方面的问题经验在这里讨论。
正文
性能的优化主要亮点是，内存的优化和运行效率的优化。
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()指针指向的部分删除，但是，这种粗暴的方式可能会造成一些内存泄露，需要在前面加入如下代码：
|
1
2
3
4
|
pEngine->getLuaStack()->clean(); lua_State *tolua_s = pEngine->getLuaStack()->getLuaState(); lua_close(tolua_s); tolua_s = NULL; |
也就是说先要把栈中数据删掉。
（3）lua中table可能的内存泄露
一般情况下，直接“table = nil”，在经过垃圾回收器的回收内存（lua这点类似java），就可以释放内存了，但是，在有些特殊情况下，垃圾收集器是无法准确的判断是否应该将当前对象清理。这样就极有可能导致很多垃圾对象无法被释放。这种情况就是交叉引用
|
1
2
3
4
|
local table1 = {} local table2 = {} table2[1] = 1 table1[table2[1]] = 1 |
这种情况下在table2[1]被释放前table1[table2[1]]不会释放。
2.运行效率的优化
运行效率的优化是更加和游戏逻辑紧密相关的，会根据不同的逻辑有不同的优化点，这里也是记录下一些原则：
（1）减少在屏幕上绘制的元素
屏幕绘制的元素多是运行效率低的最主要原因，Cocos2d-x 3.0版本加强了绘制效率的优化，增加了自动裁剪和自动批处理，但是我们仍然要主动地减少在屏幕上绘制元素的方式，同样和之前提到过的是大图还是小图的问题，这是需要平衡的，另外需要注意的是，有时候绘制的元素过多，是由于我们忘记了释放无用的屏幕绘制元素，他们可能已经不再显示（被遮挡），但是没有被删除。
（2）Lua自动内存回收
collectgarbage是lua自动回收的接口
|
1
2
|
collectgarbage("setpause", 100) collectgarbage("setstepmul", 5000） |
Lua 实现了一个增量标记清除的收集器。 它用两个数字来控制垃圾收集周期： garbage-collector pause 和 garbage-collector step multiplier 。garbage-collector pause 控制了收集器在开始一个新的收集周期之前要等待多久。 随着数字的增大就导致收集器工作工作的不那么主动。 小于 1 的值意味着收集器在新的周期开始时不再等待。 当值为 2 的时候意味着在总使用内存数量达到原来的两倍时再开启新的周期。step multiplier 控制了收集器相对内存分配的速度。 更大的数字将导致收集器工作的更主动的同时，也使每步收集的尺寸增加。 小于 1 的值会使收集器工作的非常慢，可能导致收集器永远都结束不了当前周期。 缺省值为 2 ，这意味着收集器将以内存分配器的两倍速运行。
只要设置了这个，你就不用在手动调用这个函数回收内存，手动调用会造成程序效率的降低。
（3）滚动列表的分页处理
滚动列表在游戏中使用的比较频繁，但是有一些是需要注意的，如果数据过多，需要采用分页处理，不然列表里地列表项也会过多，影响程序效率，另外tableview中采用的方法就是限制cell的个数，可以重用之前用过的cell，但是要注意的是，需要把原来cell中的数据清除。
（4）打印
打印是很耗费效率的事情，最好在打包的时候用变量控制，屏蔽所有打印。
（5）分步加载
有时一个界面要处理的东西过多，这时这个页面显示是需要分步处理，先展示一部分，效果会好些。
能想到的就是这些，再发现会在补充到这里，欢迎讨论。
来源网址：http://blog.csdn.net/bill_man/article/details/43884095
标签：
原文地址：http://www.cnblogs.com/eastnwood/p/4301590.html
