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