缓存逻辑---Allocations定位内存常驻时不要踩的坑

大家都知道iOS进行内存测试，更多的是依赖Allocations进行排查，很多隐蔽的问题都能通过一次次的Mark Generation来发现。在我们对新APP进行测试时，却遇到了一个Allocations给我们挖掘的坑，下面带大家看看此坑。

一、在测试APP进入某个页面时，发现会有768字节的内存常驻，如下图：

通过调用堆栈，我们可以看到，基本在这个函数里面，申请了一块又一块的内存：

二、持有内存的，都在info这个对象里，在info被正常使用之后，我们可以看到是有正常release的，所以我们便进入到使用info的这个方法里面去定位：

可以看到，info是会作为_dictRequestData的一个键值对的值保存下来，难道问题就在于_dictRequestData木有被release掉？所以我们找到持有_dictRequestData的类定义，发现是个单例，而且，在dealloc函数里， 还是有对_dictRequestData进行release的。

三、由于在这个测试场景里，ProfilerData这个单例会一直存在着，因此我们无法使代码走到dealloc逻辑里，因此把焦点放在_dictRequestData这个对象上，是否会在某些时机进行释放。通过在代码里搜索_dictRequestData这个对象，发现了一点蹊跷,下面的代码，可以大概猜测到，在运行超过某个时间，或者_dictRequestData这个字典里的长度达到一定长度时，会将内容清空。

下面是两个宏定义：

到了这里，就可以判断，Allocations发现的这个问题，不是一个内存常驻bug，而是开发有目的的做了缓存逻辑；缓存逻辑在代码应用上有不少，如果缺少分析一味的使用Allocations去分析内存问题，很容易走到误区，这里抛装引玉，也希望大家能吸取一点经验。

 

最后，如果想验证是不是真的有释放，我们可以把宏定义的值改变，例如MAX_ITEM_COUNT改成5次，或者Clear_Interval_seconds改成5秒，就可以用Allocations快速验证到没有不合理的内存常驻了