cocos2dx中的内存管理

cocos2dx中的内存管理,第1张

问题引入

因为cocos2dx底层框架是C++编写,不管业务部分使用的C++还是lua或者js开发,都是需要考虑内存问题的.
常见内存问题有:

  1. 程序运行中使用空指针,导致程序崩溃
  2. 程序中new 出来的指针没有释放(C/C++开发中特有)
  3. 运行内存占用越来越高

要解决这些问题,必须要理解c++的指针与内存.众所周知,C/C++申请的堆内存不会自动释放,需要由开发者主动释放.

1. malloc 和 new创建的内存

malloc 是C的函数,向 *** 作系统申请创建一段堆内存,可能会创建失败.返回void*类型指针,内存不会初始化
new和new[]是C++ 的关键字,向 *** 作系统申请创建一段堆内存,可能会创建失败,返回类型对象,会调用对象的构造函数.

free 是C的函数,向 *** 作系统释放malloc开辟的内存,不会调用对象析构函数
delete 和 detele[] 是C++ 的关键字,向 *** 作系统释放一段堆内存,会调用对象的析构函数.

注意:对于C/C++创建的堆内存,不要忘记写free delete

2. 空指针/野指针

空指针: 指向NULL ,0 ,nullptr的指针
野指针: 指针被free或者delete之后,没有设置为NULL,让人误以为这是一个合法指针,或者越界导致溢出的指针
对于空指针的错误是比较容易排查的,通常在开发阶段都会发现崩溃
野指针就比较隐蔽了,通常做法有:

  1. 在malloc申请内存时,将内存初始化,如memset
  2. 在使用delete和delete[] 后,将指针变量指向NULL
  3. 在使用过程中注意内存是否越界
3. 运行内存占用越来越高

内存占用越来越高通常是new开辟的内存没有得到释放,在cocos中,所有类型继承自Ref,其中定义有
unsigned int _referenceCount; 这个变量是用于计算cocos对象的引用次数,当引用计数为0时会自动释放
问题引入
因为cocos2dx底层框架是C++编写,不管业务部分使用的C++还是lua或者js开发,都是需要考虑内存问题的.
常见内存问题有:

  1. 程序运行中使用空指针,导致程序崩溃
  2. 程序中new 出来的指针没有释放(C/C++开发中特有)
  3. 运行内存占用越来越高

要解决这些问题,必须要理解c++的指针与内存.众所周知,C/C++申请的堆内存不会自动释放,需要由开发者主动释放.

  1. malloc 和 new创建的内存
    malloc 是C的函数,向 *** 作系统申请创建一段堆内存,可能会创建失败.返回void*类型指针,内存不会初始化
    new和new[]是C++ 的关键字,向 *** 作系统申请创建一段堆内存,可能会创建失败,返回类型对象,会调用对象的构造函数.

free 是C的函数,向 *** 作系统释放malloc开辟的内存,不会调用对象析构函数
delete 和 detele[] 是C++ 的关键字,向 *** 作系统释放一段堆内存,会调用对象的析构函数.

注意:对于C/C++创建的堆内存,不要忘记写free delete

  1. 空指针/野指针
    空指针: 指向NULL ,0 ,nullptr的指针
    野指针: 指针被free或者delete之后,没有设置为NULL,让人误以为这是一个合法指针,或者越界导致溢出的指针
    对于空指针的错误是比较容易排查的,通常在开发阶段都会发现崩溃
    野指针就比较隐蔽了,通常做法有:

  2. 在malloc申请内存时,将内存初始化,如memset

  3. 在使用delete和delete[] 后,将指针变量指向NULL

  4. 在使用过程中注意内存是否越界

  5. 运行内存占用越来越高
    内存占用越来越高通常是new开辟的内存没有得到释放,在cocos中,所有类型继承自Ref,其中定义有
    unsigned int _referenceCount; 这个变量是用于计算cocos对象的引用次数,当引用计数为0时会自动释放

什么时候引用计数会增加

  1. addchild的时候,子节点引用计数会+1
  2. 主动调用 retain() 时引用计数+1
  3. 将cocos对象放入cocos定义的容器中时,引用计数+1,例如 CCArray CCVector CCList CCMap等
  4. cocos对象被别的cocos对象使用时引用计数+1,例如: ImageView使用的Texture,Texture对象的引用计数就会+1

什么时候引用计数会减少

  1. removechild /removefromParent时引用计数-1
  2. 主动调用release()时引用计数-1
  3. 将cocos对象移出cocos定义的容器中时,引用计数+1,例如 CCArray CCVector CCList CCMap等
  4. 调用 autorelease() 后,在下一帧引用计数-1

图片资源的管理
在程序运行中,图片资源占用内存是相当高的.
在使用图片时,cocos不是直接使用的Texture,而是使用的SpriteFrame,.
cocos内部会把图片资源加入到TextureCache中缓存起来(_referenceCount+1),下次使用的时候从缓存中查找,如果没有再从文件加载为Texture,然后创建一个SpriteFrame指向这个Texture (_referenceCount+1).

SpriteFrameCache
cocos加载csb/json时,其中的Sprite和ImageView对象会从SpriteFrameCache中获取使用的SpriteFrame.那么SpriteFrame是怎么来的呢,SpriteFrameCache中的SpriteFrame主要有两种来源:

  1. 通过Plist加载的图片
    通过Plist加载的图片是一整张合图,其中有很多小图,我们可以认为每个小图都是一个SpriteFrame,一个合图就是一个Texture,SpriteFrame指向这个Texture,并记录位置,大小和旋转,路径名等.
    假设一个合图有n张小图,那么Texture的_referenceCount为n+1,SpriteFrame的引用计数为1,因为有n个SpriteFrame使用到同一个Texture

  2. 主动创建SpriteFrame添加到SpriteFrameCache中,这一点没什么好说的. 跟上面介绍的流程类似

总结
C/C++创建的内存一定要记得主动去释放
cocos对象需要注意它的引用计数,只要牢记以上规则,就能解决大多数内存问题

什么时候引用计数会增加

  1. addchild的时候,子节点引用计数会+1
  2. 主动调用 retain() 时引用计数+1
  3. 将cocos对象放入cocos定义的容器中时,引用计数+1,例如 CCArray CCVector CCList CCMap等
  4. cocos对象被别的cocos对象使用时引用计数+1,例如: ImageView使用的Texture,Texture对象的引用计数就会+1

什么时候引用计数会减少

  1. removechild /removefromParent时引用计数-1
  2. 主动调用release()时引用计数-1
  3. 将cocos对象移出cocos定义的容器中时,引用计数+1,例如 CCArray CCVector CCList CCMap等
  4. 调用 autorelease() 后,在下一帧引用计数-1
图片资源的管理

在程序运行中,图片资源占用内存是相当高的.
在使用图片时,cocos不是直接使用的Texture,而是使用的SpriteFrame,.
cocos内部会把图片资源加入到TextureCache中缓存起来(_referenceCount+1),下次使用的时候从缓存中查找,如果没有再从文件加载为Texture,然后创建一个SpriteFrame指向这个Texture (_referenceCount+1).

SpriteFrameCache
cocos加载csb/json时,其中的Sprite和ImageView对象会从SpriteFrameCache中获取使用的SpriteFrame.那么SpriteFrame是怎么来的呢,SpriteFrameCache中的SpriteFrame主要有两种来源:

  1. 通过Plist加载的图片
    通过Plist加载的图片是一整张合图,其中有很多小图,我们可以认为每个小图都是一个SpriteFrame,一个合图就是一个Texture,SpriteFrame指向这个Texture,并记录位置,大小和旋转,路径名等.
    假设一个合图有n张小图,那么Texture的_referenceCount为n+1,SpriteFrame的引用计数为1,因为有n个SpriteFrame使用到同一个Texture

  2. 主动创建SpriteFrame添加到SpriteFrameCache中,这一点没什么好说的. 跟上面介绍的流程类似

总结

C/C++创建的内存一定要记得主动去释放
cocos对象需要注意它的引用计数,只要牢记以上规则,就能解决大多数内存问题

欢迎分享,转载请注明来源:内存溢出

原文地址: https://outofmemory.cn/langs/563795.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022-04-03
下一篇 2022-04-03

发表评论

登录后才能评论

评论列表(0条)

保存