声明：
一不小心使用了QQ的图标，希望不会惹到什么麻烦!
当然，绝不会使用qq图标作为具有商业用途的素材图片，这里仅用于讨论学术!!
在纠结一个问题，某之游戏应该采用怎样一个方案才能进一步提升效率
关卡文件是我自定义的xml文件，之前我想过将该文件持久化以提升效率(读取的时候直接将文件内容读成对象)
不过鉴于objective-c持久化的自动程度完全不能与java相比，于是我便放弃了，其实也提升不了多少效率
我也意识到这是我的一个缺陷，这本是微不足道的，但是我却吹毛求疵，不可谓不能称之捡了芝麻丢了西瓜
但是，人总是有一个目标，比如说，我就喜欢追求完美，虽然不能做到极致，但我一直向着这么目标而努力，不断的项目标靠近
这不，我又发现了一个可以挖掘的点，如下：
游戏地图背景是一张很大的图片，这张图片是我依据自制的地图编辑器描点而成
编辑完毕之后，会生成一个xml文件，这个文件保存了所有的描点数据
然后我再在游戏里面通过一个特定的关卡解析模块来完成对xml文件的解读
读取完毕之后，能够使用这些数据来生成游戏中的地图背景图片，以及相应的box2d body，游戏效果如下
岩石的纹理表示了静止不可动的山体，是具有box2d 静态物体碰撞骨骼的
看到岩石外围那一圈黑边了吗？这圈黑边耗费了我很多的精力
这些复杂的多边形本来是由简单的凸多边形拼接合成的
如果不处理而希望整个复杂多变形外围添加上一圈黑边的话，这是不可能的！
因为由简单凸多边形组成的复杂多变性内部会出现黑线，这样严重影响到了游戏ui的美观
但是如果去掉了复杂多变形的外部黑边，游戏的界面效果也会大打折扣(锯齿效果严重，切割间隙不突出)~
源自冰块可被切割的特性以及抗锯齿的表现不力，就因为抗锯齿这块我不知道如何处理，导致只能舍弃3代的市场
所以说，我既想保留外部黑边又想去除内部黑线，这是一个让我非常蛋疼的问题
想了好几天，得出一套方案，能够大部分的解决内部黑线的问题，但是还是有不完美的地方，偶尔内部黑线还是会冒出来~
说到这里，还没有走入正题，这是我的老毛病了，不过我打紧，我主要还是写给我自己看~
山体图片是由xml数据+CCRenderTexture即时渲染出来的，消除内部黑线这个方法个人认为效率还是比较低的
我并不想玩家每次在进行游戏的开始，都要做一个这样的耗费
所以我想，由于每个关卡刚开始的时候画面都是 一致的，我何不将山体纹理导出为图片保存起来呢？
倒时候直接拿来使用就是了，这不很方便么？
天从人愿，我找到了解决方案，CCRenderTexture本身就提供一个这样的方法谓之saveBuffer
说实话我开心了两天，因为我确实能将即时渲染出来的山体纹理保存成图片了，这样无疑降低了cpu的负荷
但是，经过我的仔细观察和深入思考，发现有不妥的地方：
1。生成出来的山体图片必须是png格式的，但是png格式的图片和jpg格式的图片体积相差太大了！！
换句话说，我如果用增大游戏体积的方法来降低游戏对cpu的耗费，如果游戏关卡为40关，
那么40张山体png图片的大小合计下来就是12M
(每张300kB肯定是少算了的，因为我有意将最大地图的分辨率提升到1920*1280，也就retina所支持的极限)
12M，整整12M，可有可无的12M!!! 据我的伙计说，app的大小一旦超过20MB，就无法实现无线下载安装
当然我也仅仅只是听说，不过本着宁可信其有的心态，这不是一件好事情!!
况且山体图片如此做了之后，我肯定会尝试将 每关1-6张的冰块图片亦如法炮制
有言opengl从硬盘里读取一张大图片的效率要比读取多张小图片的效率高很多
因此，我又要将1-6张小图片拼凑到一张大图片上面（Zwoptex，CCSpriteBatchNode，你懂的），这些都是要手工来完成的
这样就太麻烦了，而且又要再一次增大游戏安装包的体积，实乃得不偿失！！
不过提升性能的方案还是存在的，可以修改描点工具，在生成关卡文件的过程中就完成消除内部黑边的步骤
这样在游戏过程中就可以将这一步给节省掉了，ok，这就是我接下来要完成的工作了！！