cocos2dx之tolua++全面分析(二):类注册

tolua被作为库使用时,首先会做大量内部初始化工作:

 

一、tolua_open是入口点,它创建很多用于管理的内部变量,以下用_G指代全局表,_R指定registry table:

1、_R.TOLUA_VALUE_ROOT={}, 这个表是cocos2dx自己加的,它把所有传入lua的cppobj/userdata都塞到这个表里,而且这还不是一个弱表,也就意味着cocos2dx创建的cpp obj,永远都不会被gc!只有在c++层面被delete时,才会去这个表里删除自己。因此,每一个cocos2dx cpp obj,是不可能依赖lua gc来释放的,必须纯手动管理(retain/release)。当然,根据cocos2dx自身的设计,每个obj在new出来refcount为1,并且会添加autorelease pool里去,因此只要它不在场景树上,下一帧就会被自动删除掉。通常情况下,lua代码是不会干涉其生命期的。但是有些时候我们会把某些节点从场景树上摘下,过一段时间又挂上去,这时就必须先调一下它的retain,如果之后忘记调release,那么它就永远不会销毁了。

2、_R.tolua_peers={},这是个弱表,用来缓存所有cppobj的ptr->peer table,所谓peer table,就是给每个cpp obj userdata关联的一个lua table,用来提供lua层面的额外的kv存储。tolua++把每个userdata的peer table设成该userdata的env,目的当然是为了方便找到它。因为在lua实现里,userdata的env是没有内定用途的,于是tolua++就拿来存peer table了。

3、_R.tolua_ubox={},也是个弱表,用来缓存所有cppobj的ptr->userdata映射,userdata里面存放的值其实就是ptr。这个表的用途是记录所有已经push到lua里的cppobj,每个cppobj第一次进入lua时,会去做创建userdata、关联metatable、设置peertable(env)等等一大堆操作,然后把ptr->userdata的映射关系记到这个表里,下次再被返回进lua时,就从这表里去查找,查到的话就直接拿已创建好的userdata用了。但是有一种特殊情况,就是第二次push时的类型是上一次的子类,也就是一个“特化类型”,那么需要改设metatable,以使子类的新函数能被访问到。

4、_R.tolua_super={},用来记录每个类型的所有基类,key是子类的mt,value则是个map,其中每个kv都是一个pair<基类名,1>。通过这个表可以快速知道两个类之间有无继承关系。

5、_R.tolua_gc={}

6、_R.tolua_gc_event = closure{ func:class_gc_event, upvalue:上述两个表格 }, 这是挂在每个类对应的metatable上的__gc方法。

7、_G.tolua={},里面存放tolua自己的一些工具函数

 

二、类的注册。

1、对每个用户类,首先要用tolua_usertype声明这是个用户类型:

tolua_usertype(tolua_S, "WebSocket")

它里面的做事情很简单,就是分别为type和const type“两个类”建表(这个表也就是其实例userdata的元表),然后设置type继承const type,从数据的角度来看也就是:

//先用tolua_newmetatable分别创建创建两个元表,其内又调用tolua_classevents挂上各种属性

_R["WebSocket"]={

  __index = cfunc:class_index_event,

  __newindex = cfunc:class_newindex_event,

  __gc=_R.tolua_gc_event //上面之<一.6>

  //其它各种add/sub/lt/eq等方法……

}

_R["const WebSocket"]= ……同上

 

//再用mapsuper(L,type,ctype) 设置两者的继承关系

_R.tolua_super[_R["WebSocket"]] ={ "const WebSocket" = 1,} //上面之<一.4>

//这个过程会递归执行,即把基类的所有基类都添到子类里

for k,v in pairs(_R.tolua_super[_R["const WebSocket"]]) do

  _R.tolua_super[_R["WebSocket"]][k] = v

end

 //在这一步里,mapsuper只是设置type->const type,但是在后续步骤里会添加大量type->base type,因此递归下来,每个type的_R.tolua_super[type]表还是有很多内容的。

2、然后用tolua_cclass来注册类。tolua_cclass主要做两件事,一是把基类和父类(以及各const变种)之间的关系建立起来,二是注册类的析构函数(构造函数由普通的create静态函数替代了)。

关于继承关系,总共四对:

mapinheritance(L,name,base);

mapinheritance(L,cname,name);

mapsuper(L,cname,cbase);

mapsuper(L,name,base);

其中c指const。除了上面提到的mapsuper,又来了个mapinheritance, 再次对比说明下:

mapsuper是:在_R.tolua_super记录每个类(k)有哪些父类(v),所有父类以v[类名]=1的形式记录着。

mapinheritance是:把父类表设成基类表的元表,同时给基类表上挂一个用以记录该类objptr->userdata映射的弱表,大致是:

setmetatable( _R.type, _R.base_type ),

_R.type.tolua_ubox = _R.base_type.tolua_ubox or weak({})

其中第二句与前述之<一.3>有点相似,只是那是放在_R上的一个总表,而这里是为每个类单独建表,但子类与基类是共用的,也就是每次调用tolua_cclass注册一个类,就有“3个类”的表中的tolua_ubox字段指向了同一个表,这3个类从上到下是:base type -> type -> const type,至于const base type,那是在之前注册基类时处理的了。不过我觉得这个设定很无用,一个tolua_ubox总表就足够了,为每个类分别再建一个有什么特殊作用?从读代码结果来看,没有!所有使用到它的地方,都是先去_R.type.tolua_ubox上找,如果找不到再找_R.tolua_ubox,而在哪里找到对后续操作并没有差别。接着我试了下修改代码,把所有针对_R.type.tolua_ubox的语句都删掉,直接使用总表里。结果,程序一样跑起来了,反复进场出场导致大量对象创建销毁,也没发现什么问题!

不过这里还有个另外的问题!注意和第2条里的对比:

mapinheritance(L,cname,name) //tolua_cclass里

mapsuper(L,type,ctype) //tolua_usertype里

到底type和const type谁是“基类”呢?这主要看不同场合里“基类”这个概念是用于解决什么问题了:

对mapsuper而言:在c++里一个声明为const的参数,实际是对函数本身的约束而不是对实参的约束:它只是强调函数内部不会去修改这个参数,至于传进来的实参本身是不是const的根本不重要,因为反正函数已经承诺不会去修改它了。所以要把一个类型为type的obj传给某个带有const type参数的函数,是没有问题的,但反过来,一个const type对象要传给接受type参数的函数是不行的,因为不知道它到底会不会修改(没有承诺不修改就意味着会修改)。再加上tolua++在生成胶水代码时,对每个参数都要做类型匹配检测(也就是在生成代码中大量的lua_isusertype调用),一个usertype变量是否合格,就是检查它所在位置的参数类型,是否是它可以“扮演”的角色,这些角色一是它的所有父类,二就是它以及所有父类的const变种了,而这些可以扮演的类型,恰好就是mapsuper所建立的_R.tolua_super体系中记录的内容了。

对mapinheritance而言:它将基类表设成子类表的元表,这是为了在子类表里可以找到基类的函数(在class_index_event函数里,有一个while循环,通过这里建立的链条不断向上级查找)。就这个目的而言,type和const type谁做基类是一样的。但是,type还有真正的基类base,按照base->type->const type的继承顺序是恰好满足的:

classA -> const classA

          -> classB -> const classB

                         -> classC -> const classC
                                       -> classD -> const classD

也就是说const类型在当前层次的链上是一个叶,下一层次不是从它继承,而是与它并级。

而如果按照base->const type->type->const subtype->sub type,那么问题就麻烦了,因为在注册函数时,所有函数都是挂在不带const的类表上的,如CCNode的函数都在_R["CCNode"]里,这也符合脚本里创建类实例时的习惯:直接以“纯粹的”(不带const的)类名来操作,比如CCNode:create,而不会写作const_CCNode:create()。那么在后者的继承链上,每一个const type实际成了断点,没有得到这个type自身的函数!

 

 

 

你可能感兴趣的:(cocos2dx)