1. import Image
2. import sys
3. import os.path
4. from  datetime  import  *
5. import random
6. import time
7. IMAGE_PATH = "map.png"
8. xIndex = 0
9. yIndex = 0
10. cropSize = 256
11. xNum = 0
12. yNum = 0
13. im = Image.open(IMAGE_PATH) #打开图片句柄
14. pSize = im.size
15. xNum = pSize[0]/cropSize
16. yNum = pSize[1]/cropSize
17. print "size  " ,xNum,'  ',yNum
18. for yIndex in range(yNum):
19. for xIndex in range(xNum):
20. print "pic : " , xIndex , "_" , yIndex
21. box = (xIndex*cropSize,yIndex*cropSize,(xIndex+1)*cropSize,(yIndex+1)*cropSize) #设定裁剪区域
22. region = im.crop(box)  #裁剪图片，并获取句柄region
23. name = "/Users/apple/Desktop/result/map%s_%s.png" % (xIndex,yNum-1-yIndex)
24. region.save(name) #保存图片
25. # xIndex = xIndex+1
26. # yIndex = yIndex+1
27. print int(time.time());

1. xTileNum = winSize.width/tileSize;
2. yTileNum = winSize.height/tileSize;
3. xTileNum+=1;
4. yTileNum+=1;

1. Vec2 offset = view->getContentOffset();
2. offset.x = fabsf(offset.x);
3. offset.y = fabsf(offset.y);
4. int xStartIdx = offset.x/tileSize;
5. int yStartIdx = offset.y/tileSize;

1. for (int i = 0 ; i<xTileNum ; i++)
2. {
3. for (int j=0; j<yTileNum; j++)
4. {
5. int xIdx = xStartIdx+i;
6. int yIdx = yStartIdx+j;
7. char name[128];
8. sprintf(name, "result/map%d_%d.png",xIdx,yIdx);
9. Sprite* tile = Sprite::create(name);
10. tile->ignoreAnchorPointForPosition(true);
11. int posX = tileSize*xIdx;
12. int posY = tileSize*yIdx;
13. tile->setPosition(posX,posY);
14. contentLayer->addChild(tile);
15. }
16. }

上图很清楚，要补充的是绿色区域，要去掉的是左上的那2条，中间的是不用动的。这个地方能想出一万种算法来做。我用的是一种简单直接的，但是绝对不是效率最高的。因为最后你会发现这点效率完全没有什么卵用。。。。

首先需要这么几个东西

其实想法和简单，就是把每次加入的图块sprite，放入一个map，然后把移动过后，需要加入的图块，是全部的，不是新增的那一部分，放入一个map，然后对2个map取差集，就可以得出需要添加的部分，和需要删除的部分。

但是为毛我只写了一个map确用了2个set。。。因为我没试过map能不能用stl的set_difference这个函数。。。大概就是这样

然后还有最重要的一步

再说效果。代码这就写完了，然后上甄姬测试吧。

然后跑起来之后，你就会发现，妈蛋，怎么还是这么卡的不要不要的。还不如全部加载了流畅。

看几个性能参数，内存，效果很明显，GLVerts，效果也很明显。那为毛还这么卡，一定是我的替换算法写的太渣了。然后在算法的起始和结尾输出时间。发现基本可以说是秒过，完全没有性能瓶颈。

控制变量法，其他不变，把图块sprite的纹理全部换成一个图，再一跑，发现流畅无比，各项参数都是很牛B的。

综上可知，应该是可推测。如果是绘制的问题，那么每次都需要绘制新的图库，都应该一样的卡才对。

在2次测试中，唯一的区别，就是把每次都去读取新的图片纹理，换成了用缓存中已经存在的纹理。那么推测应该就是在用新纹理创建新的sprite这个地方卡住了。

从这里看，在创建新纹理的时候，用到了fileUtil，也就是说读了文件，也就是说这个地方有IO，然而IO是很容易卡的。

下面是输出时间：

1是开始计算新图块的地方，2是开始添加新图库的地方。3是整个完成。a是创建图库sprite前，b是创建图库sprite之后。

整个过程耗时132ms，也就是说此时FPS只有10不到。其中最慢的几个地方，都是在ab之间，差不多30ms左右。再次说明和之前那个效率不算太高的替换算法关系不大。。。

本文标题之所以跟了一个“初”，是我觉得这种方式如果优化一下是可行的，虽然我不知道怎么弄，有知道的麻烦通知我：dinko@126.com