为何3.x重新增加新的数据容器Vector<T>和Map<K,V>时要偏离原本的Ref内存管理机制

其实是Vector<Ref*>和Map<K,Ref*>吧,所有的资料一摆在那全这么写还真容易让人以为它们什么类型都能容纳。这里主要想说的是它们的签名:

template class Vector
template <class K, class V> class Map

它们作为容器本身却不是Ref的后代,而它们的legacy版__Array和__Dictionary:

class CC_DLL __Array : public Ref, public Clonable
class CC_DLL __Dictionary : public Ref, public Clonable

则仍然贯彻了cocos2d-x原本一开始就提倡的万物皆CCObject/Ref的特性。既然一开始就不停地各种指出Ref在内存管理机制的优点,为何还要自己去违反它?

引擎机制自己的混淆会给引擎的使用者们本身很大的混淆和困扰,引擎的代码本来就是代码风格和设计思想的典范,你们都这么乱了,我们还该怎么follow?

一会用Ref机制一会又不用Ref机制的情况会很让人纠结,哪些对象实例化出来之后要纳入Ref的那套retain/release进AutoReleasePool,哪些又要跳出来自己去CC_SAFE_DELETE呢。为何__Array和__Dictionary创建出来应该要retain,而新的Vector和Map又不用了呢。如果不按照原本严格依据的Ref为一切根源的思想,谁能记得住和遵守这一作为内存管理体制的原则。产生了混淆之后,要Ref管的和不要Ref管的对象满天飞,谁也搞不清楚哪个要用哪种方式去管理,内存泄漏隐患加大不说,从代码角度来看这怎么又可能是一个统一严谨的风格呢。

Ref以及原本的CCObject不像Java那样可以直接从语言层级直接限制住所有的类皆是Object的子类来推行它统一的内存模型和机制,想将cocos2d-x的整个世界也用Ref一根绳子串起来也只能从类库的层级去保证这一点,能否请引擎的维护者们留意一下这个设计原则一致性的问题。

Map 放不了Vector,确实很奇怪