最近的一些总结

1。解决了box2d ContactListener相关的一个bug（实际上算不上解决，只能说是用一些手段逃避了一个bug）

我想做一个一个物体碰撞另一个物体后就消失的功能，我在要销毁的物体上调用DestroyBody方法，

结果竟然引发 b2World m_bodyList 成员的紊乱！m_bodyList是一个双链表的结构，

双链表插入删除操作都比线性表要高效，不难理解erin的良苦用心，

但是对于我等菜鸟，刚开始接触 box2d 的时候，那可是吃了大亏！

本人是极度钟爱以 for 循环来遍历容器的，于是那次便跌了一大跤，

以for(int i = 0; i < m_bodyListCount; ++ i)的方式来遍历 m_bodyList，

可想而知，不爆出 EXEC_BAD_ACCESS的错误那才是奇迹，

事实上，后来我找了好久，直到翻到 Erin写的那片 box2d pdf入门材料我才觉悟过来

m_bodyList是一个 b2Body 对象数组，b2Body 有两个成员，m_prev,m_next，

而且，m_bodyListCount 也不是用来让人以我那种方式来遍历 m_bodyList 的，

m_bodyListCount 本来就没有提供setter getter，我当时还觉得不方便，特意在box2d源码里面加了一组~

当然，跨过了sb的错误认识，我却是向高手的境界多迈进了一步

正确的遍历方式如下

for (b2Body* b = bodyList; b; b = b->GetNext()) {

b2Body 对象里面 m_fixtureList 的遍历也一样：

for (b2Fixture* f = body->GetFixtureList(); f; f = f->GetNext()) {

以上是我几个月前所解决的一个bug，这次碰撞效果所引发的bug与此并无多少关系，

这次，我发现我竟然是再一次栽倒在 b2World 的 DestroyBody 方法上面，

DestroyBody这个方法我都快翻烂了，很难理解 里面那个 proxy的概念，不知道是用来干什么的，

还有那个 DynamicTree，也不知道起什么作用，到时候技术稍微好点了以后，一点吧box2d搞个通透！

上次栽倒是在销毁越界 b2Body 的时候，这次栽倒是在碰撞后销毁一个碰撞相关body的时候，

如此的相似！于是我使劲的想解决这个bug，虽然我没有找到解决bug的办法，

但是收获还是不少：

bug是由于 b2World m_bodyList链表里面的某b2Body元素所引起的，

很可能是因为某个已销毁的 b2Body 吧链表的结果给搞乱了，以至于

遍历 m_bodyList 的时候收不住蹶子了。有图为证：

由图可以发现，m_bodyList 的元素个数竟然由 10个直接跳到 n多个！不难想见到底是由什么原因所引发~

如上所述，虽然bug的原因找到了，但是我依然没能解决这个bug！

无法解决的时候我选择逃避bug，我像上次一样，将销毁body的操作改为：

将要销毁的body设置到一个很偏僻的位置，然后将 bodyType设置为 b2_staticBody，

这么做虽然多了一些额外的开销，本该被销毁的body一直牢牢的霸占这有限的内存，

但是不得不说，程序的效果还是非常能让人接受的，反而给人一种感觉：

如果我非要花费大量的时间来解决这个bug的话，反而不及我这么做来的高效~

实际上，一大批 body 对象所占据的硬件资源（cpu，内存）相较于一张图片而言，

是相当之微不足道的，所以，这也是我这么做的一个理由

这次就这样了吧，如果有时间有精力，我还是会试图把这个bug从根源上给刨掉的！

相关代码：

+ (void) DestroyBodyExt:(b2Body*)body {

CCSprite *actor = (CCSprite*)body->GetUserData();

[actorremoveFromParentAndCleanup:YES];

body->SetUserData(NULL);

body->SetTransform(b2Vec2(7.5f,20.0f),0.0f);

body->SetType(b2_staticBody);

}

2。couldn't register com.yourcompany.GoldMine0-6 with the bootstrap server.Error: unknown error code.

This generally means that another instance of this process was already running or is hung in the debugger.(gdb)

第二次遇到这个错误了，这次我惊奇的发现过了一段时间之后竟然不用引导重启ios设备就能再次真机调试了

但是我后来又试了一下，发现还是不怎么稳定，因为这个期限可能很长也可能很短，

如果很长的话那就蛋疼了~

我以前都是用 windows 版的红雪，于是每次真机测试出现这种bug的时候，难免就是打开我的另一台xp，

用红雪引导重启完之后关掉xp，再把设备转移到我的mac上面来，相当之麻烦

听说ios5完美越狱的红雪发布了，特意去试了下，而且还找了一个mac os版的红雪，这个倒是让我感到很振奋，

今后再也不用单门打开xp就为引导设备重启了，直接在mac上面完成该操作~

ios5完美越狱红雪个人感觉还是很不完美，因为经过我的实践发现关机之后重启，

设备依然还是一直卡在白苹果那个画面，一直没有要进入到正常操作系统的意思

不管了，有得mac版的红雪用其实我就已经很满足了，没有太多的奢望了~

3.好几次发现再做真机测试的时候程序卡住不动了，但是xcode却没有爆出错误来

一个很有可能的原因就是，程序陷入到了某个死循环里面出不来了，

可以用xcode 的调试功能来定位到导致该问题的代码片段，

具体做法相当简单，“pause”一下程序即可！

4.dashCode的位置（不在常用的apliication文件夹里面）

5。mac上以程序执行的方式竟然生成不了文件，这是一个不正确的认知！

不知道是因为我程序的原因，还是其他原因，

上次我竟然发现这样一个问题，后来一次偶然间发现，我想要生成的文件

原来给生成出来了，只不过生成出来的文件所在的位置，那我就真不敢恭维了，

和我最初设定的生成位置相距了十万八千里。。难道是mac的安全机制在作祟？

上面是我所预期的文件生成目录，可以看到并没有我想生成出来的文件

竟然生成到这里来了，- -、，还有比这更坑爹的事情么？！

6.搜索资源下载的一些心得：

首先，如果能确定要找到的东西的作者是外国人，那么搜索的关键词里面最好就不要带中文了

除非是使用特别广泛的大众软件，例如 photoshop。。

此外，请用google搜索！

第三，关键词的填写要精确、简洁，关键词之间请用空格符进行分隔

例如，“PhysicsEditor 1.0.5 mac download”这就是一个很好的搜索语句

资源名称，版本号，适用平台，你有什么想法，都很好的体现在了搜索语句里面

因为没有给带上中文，因此能抓出一大批国外的网页出来，找到你想要的东西出来几率更大~

想一些稍微冷门一点儿的软件，想在太平洋，华军，多特等下载站上面找到，几率还是比较小的

只有直击源头，从第一手国外网站上面扒，才是最合适的选择！

另外一个要注意的地方就是，某些资源的原作者站点所提供的下载速度，是非常之让人难以接受的

就如前文所提及的 physicsEditor，主页的速度直让人想吐，用safari下载，

下载到中途速度竟然变得才每秒不到10kb，

20多M的东西预计下载完成的时间更由2~3个小时多次过渡到n个小时，直让人抓狂~

慢就算了，能下下来我就满足了，多次很了蛮久时间下载到一小半的时候竟然还给我丢失连接。。

后来转变了一下思路，不再原作者网站上面下载了，跑到国外其他下载站点去下载，

三下五除二，很快就以每秒100kb以上的速度给搞下来了，毫无疑问，这就是差距！

也再次让我发出感慨：

穷则要变，变自然会通，通了也才能久！！