一、总原则：c++对象的生命期不依赖lua gc管理，手动创建的对象要手动销毁

二、引擎层在设计上就是支持脚本概念的（也就是说脚本的使用是“侵入式”的），与lua打交道的代码都封在CCLuaEngine，引擎各处模块都通过它来调用脚本，如CNode::update会调用CCLuaEngine->executeSchedule来调用脚本的update handler，再如CNode::onEnter/onExit/onCleanup等都会调用CCLuaEngine->executeNodeEvent来调用脚本的event handler。

三、lua脚本封装模块：

　　scripting/lua/tolua：

　　　　这是tolua++自己的运行层代码，各种基础函数，用来操作c++数据与lua数据

　　scripting/lua/lua|luajit：

　　　　这是lua和luajit的源码

　　scripting/lua/cocos2dx_support/tolua_fix.h|c：

　　　　这是cocos2d为实现自定义数据类型操作而添加的tolua扩展代码，具体见下

　　scripting/lua/cocos2dx_support/LuaCocos2d.h|cpp：

　　　　由tolua++解析pkg文件生成的粘合代码，几万行，包括了大量要导出的cocos2d逻辑类

　　scripting/lua/cocos2dx_support/CLuaEngine/Value/Stack/Bridge.h|cpp：

　　　　这些都是cocos2d自己处理与lua虚拟机交互的类了

　　scripting/lua/cocos2dx_support/Lua_web_socket/Lua_extensions_CCB/CCBProxy.h|cpp：

　　　　这些看起来像是各种扩展库的粘合代码，与LuaCocos2d.h性质一样，但是是手写的，至于为什么用这种形式，有什么特殊的地方，我还没搞清楚。

四、每个c++对象在lua里以一个userdata表示，这个userdata上绑定了很多重要信息，如对象的类型，所有方法都是挂在类型上的。当多次将同一个c++ obj返回给lua时，为了避免创建多个不同的userdata，用了一个弱表来记录所有已进入过脚本的obj，即 objmap[ptr]=obj-userdata，第二次返回同一对象时查表可得。但由于这是一个弱表，里面的表项不是永久存在的，这极易引发一个经典bug：

local spt = CCSprite:create("ui/green_btn.png")

spt:setPosition(320,100);

base_layer:addChild(spt)

base_layer:registerScriptTouchHandler(function(et,x,y)

　　--gc()

　　--gc()

　　local children = base_layer:getChildren()

　　local cnt = children:count()

　　for i=0,cnt-1 do

　　　　local c = children:objectAtIndex(i)

　　　　print("child ",i,tostring(c))

　　　　local s = c:getContentSize()

　　　　。。。

　　end

end)

　　spt做为局部对象，在外层函数返回后就失去引用了，虽然它代表的c++ obj通过addChild的方式被其parent（也就是base_layer）引用住了，但是在脚本里这个类型为CCSprite的userdata一旦被gc后，在上述事件响应函数里通过children:objectAtIndex(i)再次获取该c++ obj时，因为在弱表里找不到记录，就会重新生成userdata，而这一次userdata的类型为CCObject！在它上面调getContentSize显然是找不到的。通常这种错误会因为gc的非即时性而掩盖一时，等到报错的时候反让人摸不着头脑了。测试的方法很简单，在获取对象之前强制gc一次，那么下面的代码当场就会报错了。

　　解决的办法，要么把spt记在其它对象身上关联起来不被gc，要么在每次获取时，执行强制类型转换（但跟c++层的dynamic_cast一样易出弊端）：

　　c = tolua.cast(c,"CCNode")

……

待续

注：以上结论是错的，纯属未认真读代码就想当然了（主要是以前我自己做封装的时候是这么搞）。关于cocos2dx-lua里对象的生命期，请见我后面更新的文章（那个是认真读过代码后写的了。。。）