这是我的代码,我重新加载_collectionView的特定部分。当我使用Xcode 6.3 Instruments中的Leaks模板检查内存泄漏时,它显示在线泄漏
[_collectionView reloadSections:indexToLoad];
和_NSCFNumber作为泄漏对象。 这是我的代码:
NSMutableIndexSet* indexToLoad = [NSMutableIndexSet new];
for (NSInteger index in array) {
if (index != NSNotFound) {
[indexToLoad addIndex:index];
}
}
if (indexToLoad.count > 0) {
[_collectionView reloadSections:indexToLoad];
}
当我在某处读到时,"泄漏工具会显示泄漏分配的位置,但没有显示导致泄漏的代码行" ,如何我能找到泄漏的原因吗?另外如何解决这个漏洞?
注意:对于运行此代码的类启用ARC(整个项目启用了ARC)。此代码也在主线程上运行。
提前感谢您的回答:)
答案 0 :(得分:1)
我注意到你正在迭代一个数组并将其内容包装到NSInteger
。由于你无法将NSInteger
添加到Objective-C数组中,我将假设这是一个NSNumber
的数组,恰好是泄漏的类。
当您将对象(例如NSNumber
)添加到集合(即NSArray
,NSSet
等)时,该集合会创建对该对象的 STRONG 引用。这意味着当NSNumber
超出范围ARC或垃圾收集器不会出现并释放它时。这可能会导致一些问题,其中一个问题是retain cycles。
我怀疑正在发生的事情(我无法确定没有实际测试您的完整代码)是当NSMutableIndexSet
超出范围时ARC出现并尝试释放所有它包含的NSNumber
个对象但发现它不能,因为它们仍然被数组保留。如果没有,则代码中的某个位置会挂起到一个或多个NSNumber
个实例,ARC不喜欢它。
解决方案:
ARC在内存管理方面并不是灵丹妙药。它使内存管理更加友好,因为人们倾向于认为他们可以编写他们喜欢的任何代码,ARC将负责其余的工作。您仍需要了解自己的引用(strong
vs weak
)以及何时使用每个引用。还要确保知道默认状态是什么;例如@property NSNumber *num;
相当于@property (nonatomic, strong) NSNumber *num;