cocos2d-x与ISO内存管理


备注:图片纹理加载所占用的内存 = 长*宽*4,  图片使用 RGBA 模式, 一个像素点,占 4个字节

IOS设备的内存限制情况

设备                                              建议内存                   最大内存

iPad2/iPhone4s/iphone4                170-180mb                 512mb

iPad/iPod touch3,4/iphone3gs          40-80mb                  256mb

iPod touch1,2/iPhone3g/iPhone1         25mb                    128mb




1.慎用大图片 
图片占用内存大小的算法为一张 1024*1024的图片,加载成纹理后,占用1024*1024*4(4m)内存。渲染成精灵后,又会占用和纹理一样的内存,所以这种图片占用的总内存是8m 。(绘制精灵的时候,以精灵的绘制这种图片的大小计算内存,例如只绘画这张图片的 某个 28*28大小的 区域, 那么只需要一个 32 * 32 *4 = 4K的内存大小) 

2.图片尺寸很重要 
图片尺寸里有大陷阱,1024*1024和1025*1025的图片看似差不多,其实内存占用有天壤之别,因为cocos2d对图片的尺寸是按2的N次方自适应的,所以1025*1025的图片加载后实际纹理大小为2048*2048,纹理将占用8m内存!是1024*1024那张图片的2倍。所以遇到类似尺寸图片,最好先用PS调整下大小。 
  
3.使用工具查看内存占用 
用xcode自带的Leaks工具可以很方便的查看程序占用的情况和寻找内存泄露的堆栈。 
  
4.检查对象有没被释放 
当代码越来越复杂的时候,你就要担心某些对象可能在其他你没注意的地方给保留了引用计数,导致你在对这个对象使用release方法时,实际对象并没有被dealloc掉。所以你得通过在每个对象的dealloc方法中打上断点调试或者输出日志,来确认该对象是否真的被释放了。 
  
5.使用真机测试 
一般在模拟器中,因为电脑内存本身较大,所以在这种情况下,即使你的程序占用内存很高,也不会收到任何警告和异常。但是如果在iphone或者ipad上进行真机测试,因为设备可用内存较少,所以大多数的内存问题就会暴露出来。所以提早进行真机测试是很有必要的。 
(在真机上,程序运行效率也会大大提升,在模拟器上游戏帧数10帧不到,放到真机上居然是60帧满的,mac mini的性能真是菜啊!) 
  
6.内存警告。 
当机器内存吃紧的时候,会给程序一个内存警告消息。这个消息分为1和2两种等级,等级1的时候基本上问题不大。等级2的时候就要注意了,通常这时离崩溃不远了(程序内存占用在350M左右一般会收到等级2的警告。)。如果程序的内存占用超过400M,基本上这时程序就会直接被操作系统杀死,表现在ipad上就是程序直接退出。而这时候程序不会打印任何有助于你检查的log! 


----------------------------------------------------------------------------

之前项目一直在IPAD2上测试,一直很流畅。后来拿到ITOUCH上的时候,瞬间就崩了。用XCODE的内存分析工具分析,内存都快飙到200M了。。。。经过一番折腾以后,终于控制在80M以内。下边就写写折腾过程中遇到的问题。


一,IOS与图片内存--资源加载消耗

在IOS上,图片会被自动缩放到2的N次方大小。比如一张1024*1025的图片,占用的内存与一张1024*2048的图片是一致的。图片占用内存大小的计算的公式是;长*宽*4。这样一张512*512 占用的内存就是 512*512*4 = 1M。其他尺寸以此类推。(ps:IOS上支持的最大尺寸为2048*2048)。


二,cocos2d-x 的图片缓存

Cocos2d-x 在构造一个精灵的时候会使用spriteWithFile或者spriteWithSpriteFrameName等 无论用哪种方式,cocos2d-x都会将这张图片加载到缓存中。如果是第一次加载这个图片,那就会先将这张图片加载到缓存,然后从缓存读取。如果缓存中已经存在,则直接从缓存中提取,免除了加载过程。

图片的缓存主要由以下两个类来处理:CCSpriteFrameCache, CCTextureCache

CCSpriteFrameCache加载的是一张拼接过的大图,每一个小图只是大图中的一个区域,这些区域信息都在plist文件中保存。用的时候只需要根据小图的名称就可以加载到这个区域。

CCTextureCache 是普通的图片缓存,我们所有直接加载的图片都会默认放到这个缓存中,以提高调用效率。

因此,每次加载一张图片,或者通过plist加载一张拼接图时,都会将整张图片加载到内存中。如果不去释放,那就会一直占用着。


三,渲染内存。

不要以为,计算内存时,只计算加载到缓存中的内存就可以了。以一张1024*1024的图片为例。

CCSprite *pSprite = CCSprite::spriteWithFile("a.png");

调用上边这行代码以后,可以在LEAKS工具中看到,增加了大约4M的内存。然后接着调用

addChild(pSprite);

这时,内存又增加了4M。也就是,一张图片,如果需要渲染的话,那它所占用的内存将要X2。


再看看通过plist加载的图片,比如这张大图尺寸为2048*2048。想要加载其中的一张32*32的小图片

CCSpriteFrameCache::sharedSpriteFrameCache()->addSpriteFramesWithFile("b.plist");

此时内存增加16M (汗)

CCSprite *pSpriteFrame = CCSprite::spriteWithSpriteFrameName("b1.png");

b.png 大小为32*32 ,想着也就是增加一点点内存,可实际情况是增加16M内存。也就是只要渲染了其中的一部分,那么整张图片都要一起被加载。

但是情况不是那么的糟糕,这些已经渲染的图片,如果再次加载的话,内存是不会再继续升高的,比如又增加了100个b.plist的另一个区域,图片内存还是共增加16+16 = 32M,而不会继续上升。


四,缓存释放

如果游戏有很多场景,在切换场景的时候可以把前一个场景的内存全部释放,防止总内存过高.

CCTextureCache::sharedTextureCache()->removeAllTextures(); 释放到目前为止所有加载的图片

CCTextureCache::sharedTextureCache()->removeUnusedTextures(); 将引用计数为1的图片释放掉CCTextureCache::sharedTextureCache()->removeTexture(); 单独释放某个图片

CCSpriteFrameCache 与 CCTextureCache 释放的方法差不多。

值得注意的是释放的时机,一般在切换场景的时候释放资源,如果从A场景切换到B场景,调用的函数顺序为B::init()---->A::exit()---->B::onEnter() 可如果使用了切换效果,比如CTransitionJumpZoom::transitionWithDuration这样的函数,则函数的调用顺序变为B::init()---->B::onEnter()---->A::exit() 而且第二种方式会有一瞬间将两个场景的资源叠加在一起,如果不采取过度,很可能会因为内存吃紧而崩溃。

有时强制释放全部资源时,会使某个正在执行的动画失去引用而弹出异常,可以调用CCActionManager::sharedManager()->removeAllActions();来解决。


五,内存优化

优化的心得就是尽量去拼接图片,使图片边长尽可能的保持2的N次方并且装的很满。但要注意,有逻辑关系的图片尽量打包在一张大图里,另外一点就是打包的时候要考虑到层的分布。因为为了渲染效率可能会用到CCSpriteBatchNode;同一个BatchNode里的图片都是位于一个层级的,因此必须根据各个图片的层级关系,打包到不同的plist里。有时内存和效率不可以兼得,只能尽量平衡了。

六,其他

最后附一个各代IOS设备的内存限制情况

设备                                              建议内存                   最大内存

iPad2/iPhone4s/iphone4                170-180mb                 512mb

iPad/iPod touch3,4/iphone3gs          40-80mb                  256mb

iPod touch1,2/iPhone3g/iPhone1         25mb                    128mb


上述建议内存只是一些人自己测试的结果,可用的RAM不大于最大内存的一半,如果程序超过最大内存的一半,则可能会挂掉。

另外在LEAKS里查看模拟器中和真机总的内存,会有较大出入。在模拟器中的结果与实际更接近一些。


本文转载于:http://blog.chinaunix.net/uid-20622737-id-3269694.html

内容概要:本文详细介绍了如何利用Simulink进行自动代码生成,在STM32平台上实现带57次谐波抑制功能的霍尔场定向控制(FOC)。首先,文章讲解了所需的软件环境准备,包括MATLAB/Simulink及其硬件支持包的安装。接着,阐述了构建永磁同步电机(PMSM)霍尔FOC控制模型的具体步骤,涵盖电机模型、坐标变换模块(如Clark和Park变换)、PI调节器、SVPWM模块以及用于抑制特定谐波的陷波器的设计。随后,描述了硬件目标配置、代码生成过程中的注意事项,以及生成后的C代码结构。此外,还讨论了霍尔传感器的位置估算、谐波补偿器的实现细节、ADC配置技巧、PWM死区时间和换相逻辑的优化。最后,分享了一些实用的工程集成经验,并推荐了几篇有助于深入了解相关技术和优化控制效果的研究论文。 适合人群:从事电机控制系统开发的技术人员,尤其是那些希望掌握基于Simulink的自动代码生成技术,以提高开发效率和控制精度的专业人士。 使用场景及目标:适用于需要精确控制永磁同步电机的应用场合,特别是在面对高次谐波干扰导致的电流波形失真问题时。通过采用文中提供的解决方案,可以显著改善系统的稳定性和性能,降低噪声水平,提升用户体验。 其他说明:文中不仅提供了详细的理论解释和技术指导,还包括了许多实践经验教训,如霍尔传感器处理、谐波抑制策略的选择、代码生成配置等方面的实际案例。这对于初学者来说是非常宝贵的参考资料。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值