缓存逻辑---Allocations定位内存常驻时不要踩的坑
2014-10-30 18:50
120 查看
大家都知道iOS进行内存测试,更多的是依赖Allocations进行排查,很多隐蔽的问题都能通过一次次的Mark Generation来发现。在我们对新APP进行测试时,却遇到了一个Allocations给我们挖掘的坑,下面带大家看看此坑。
一、在测试APP进入某个页面时,发现会有768字节的内存常驻,如下图:
![](http://km.oa.com/files/post_photo/237/211237/ed3cd92213a97a3364b82e04537fc748.jpg)
通过调用堆栈,我们可以看到,基本在这个函数里面,申请了一块又一块的内存:
![](http://km.oa.com/files/photos/captures/201408/1408971677_23.jpg)
二、持有内存的,都在info这个对象里,在info被正常使用之后,我们可以看到是有正常release的,所以我们便进入到使用info的这个方法里面去定位:
![](http://km.oa.com/files/photos/captures/201408/1408971689_37.jpg)
可以看到,info是会作为_dictRequestData的一个键值对的值保存下来,难道问题就在于_dictRequestData木有被release掉?所以我们找到持有_dictRequestData的类定义,发现是个单例,而且,在dealloc函数里, 还是有对_dictRequestData进行release的。
![](http://km.oa.com/files/photos/captures/201408/1408971739_3.jpg)
三、由于在这个测试场景里,ProfilerData这个单例会一直存在着,因此我们无法使代码走到dealloc逻辑里,因此把焦点放在_dictRequestData这个对象上,是否会在某些时机进行释放。通过在代码里搜索_dictRequestData这个对象,发现了一点蹊跷,下面的代码,可以大概猜测到,在运行超过某个时间,或者_dictRequestData这个字典里的长度达到一定长度时,会将内容清空。
![](http://km.oa.com/files/photos/captures/201408/1408971747_20.jpg)
下面是两个宏定义:
![](http://km.oa.com/files/photos/captures/201408/1408971751_41.jpg)
到了这里,就可以判断,Allocations发现的这个问题,不是一个内存常驻bug,而是开发有目的的做了缓存逻辑;缓存逻辑在代码应用上有不少,如果缺少分析一味的使用Allocations去分析内存问题,很容易走到误区,这里抛装引玉,也希望大家能吸取一点经验。
最后,如果想验证是不是真的有释放,我们可以把宏定义的值改变,例如MAX_ITEM_COUNT改成5次,或者Clear_Interval_seconds改成5秒,就可以用Allocations快速验证到没有不合理的内存常驻了
一、在测试APP进入某个页面时,发现会有768字节的内存常驻,如下图:
![](http://km.oa.com/files/post_photo/237/211237/ed3cd92213a97a3364b82e04537fc748.jpg)
通过调用堆栈,我们可以看到,基本在这个函数里面,申请了一块又一块的内存:
![](http://km.oa.com/files/photos/captures/201408/1408971677_23.jpg)
二、持有内存的,都在info这个对象里,在info被正常使用之后,我们可以看到是有正常release的,所以我们便进入到使用info的这个方法里面去定位:
![](http://km.oa.com/files/photos/captures/201408/1408971689_37.jpg)
可以看到,info是会作为_dictRequestData的一个键值对的值保存下来,难道问题就在于_dictRequestData木有被release掉?所以我们找到持有_dictRequestData的类定义,发现是个单例,而且,在dealloc函数里, 还是有对_dictRequestData进行release的。
![](http://km.oa.com/files/photos/captures/201408/1408971739_3.jpg)
三、由于在这个测试场景里,ProfilerData这个单例会一直存在着,因此我们无法使代码走到dealloc逻辑里,因此把焦点放在_dictRequestData这个对象上,是否会在某些时机进行释放。通过在代码里搜索_dictRequestData这个对象,发现了一点蹊跷,下面的代码,可以大概猜测到,在运行超过某个时间,或者_dictRequestData这个字典里的长度达到一定长度时,会将内容清空。
![](http://km.oa.com/files/photos/captures/201408/1408971747_20.jpg)
下面是两个宏定义:
![](http://km.oa.com/files/photos/captures/201408/1408971751_41.jpg)
到了这里,就可以判断,Allocations发现的这个问题,不是一个内存常驻bug,而是开发有目的的做了缓存逻辑;缓存逻辑在代码应用上有不少,如果缺少分析一味的使用Allocations去分析内存问题,很容易走到误区,这里抛装引玉,也希望大家能吸取一点经验。
最后,如果想验证是不是真的有释放,我们可以把宏定义的值改变,例如MAX_ITEM_COUNT改成5次,或者Clear_Interval_seconds改成5秒,就可以用Allocations快速验证到没有不合理的内存常驻了
相关文章推荐
- IOS 区分缓存 内存 物理存储 逻辑存储
- Android中实现帐号密码登录及进行内存缓存逻辑(仿QQ)
- 基于超出内存可加载范围的数据集的逻辑回归分类器LR分类器
- 手游内存占用过高?如何快速定位手游内存问题
- 对象创建,内存布局,对象的访问定位
- 请问JVM参数_定位检查内存溢出问题
- 手机内存、闪存和缓存
- 关于手机定位轨迹的算法逻辑
- Android App定位和规避内存泄露方法研究
- linux下内存的统计和内存泄露类问题的定位
- Linux 上的 DB2 内存和文件缓存性能调优
- 内存缓存的一些思考
- iOS开发之缓存(一):内存缓存
- Android异步加载图片并缓存到内存和SD卡上
- NSURLCache内存缓存 (
- memcached——分布式内存对象缓存系统
- iOS开发之缓存(一):内存缓存
- 不要在Android的Application对象中缓存数据!
- centos 6.5 清除内存中的系统缓存
- 【感悟】——逻辑的重要性-循环里不要套IO操作