【问题标题】:Solving memory leak in Xcode解决 Xcode 中的内存泄漏
【发布时间】:2013-08-02 09:19:02
【问题描述】:

我正在尝试使用通讯录在联系人 APP 上做一个程序,它工作正常,但是当我分析有几个内存泄漏时,我已经设法将内存泄漏降到最低,现在我只有 2 个主要的内存泄漏警告,一个在我的地址簿重新加载功能中,我包含了 cmets 以显示我尝试过的所有内容

-(void)reloadAddressBook
{
   //if(self.addressBook)
      //CFRelease(self.addressBook);
    self.addressBook = (__bridge ABAddressBookRef) CFBridgingRelease(ABAddressBookCreate());

    if(ABAddressBookHasUnsavedChanges(self.addressBook))
    {

        ABAddressBookSave(self.addressBook,NULL);


    }


    //if(self.contactAdd)
        //CFRelease(self.contactAdd);
    self.contactAdd= ABAddressBookCopyArrayOfAllPeople(self.addressBook);


**//Memory warning here and says: call to function ABAddressBookCopyArrayOfAllPeople returns a core foundation object with a +1 retain count**     
        //self.contactAdd= (__bridge ABAddressBookRef) CFBridgingRelease(ABAddressBookCopyArrayOfAllPeople(self.addressBook));
        **// If I use this format my memory leak issue solves here but I get error in my program**
    }

- (void)viewDidLoad
{**//Memory warning here and says :object leaked :allocated object is not retained lated in this execution path and has retain count +1**
    [super viewDidLoad];

    self.contactSearchBar.delegate=self;
    self.contactTableView.delegate=self;
    self.contactTableView.dataSource=self;

    UIBarButtonItem *addContactButton=[[UIBarButtonItem alloc]initWithTitle:@"Add" style:UIBarButtonItemStyleBordered target:self action:@selector(newContact:)];
    self.navigationItem.rightBarButtonItem=addContactButton;
    self.navigationItem.title=@"My Contacts";


}

另一个内存泄漏是在这个搜索栏函数中

-(void)searchBar:(UISearchBar *)searchBar textDidChange:(NSString *)searchText
{

    if(searchText.length==0)
    {
        isFiltered=NO;

    }
    else
    {
        isFiltered=YES;

        int j=0,i=0;
        self.filteredData= CFArrayCreateMutable(kCFAllocatorDefault, 0,&kCFTypeArrayCallBacks);**// Memory warning here and says: call to function CFArrayCreateMutable returns a core foundation object with a +1 retain count**

       for(i=0;i<CFArrayGetCount(self.contactAdd);i++)**//Memory warning here and says :object leaked :allocated object is not retained lated in this execution path and has retain count +1**
        {
            self.person=CFArrayGetValueAtIndex(self.contactAdd,i);
            NSString *str=[[NSString stringWithFormat:@"%@", (__bridge_transfer NSString *)ABRecordCopyValue(self.person, kABPersonFirstNameProperty)] stringByTrimmingCharactersInSet:[NSCharacterSet whitespaceCharacterSet]];
            NSRange contactRange= [str rangeOfString: searchText options:NSCaseInsensitiveSearch];

            NSLog(@"i=%d, j=%d",i,j);

            if(contactRange.location!=NSNotFound)
            {
                CFArrayInsertValueAtIndex(self.filteredData,j++,self.person);
               CFArrayGetValueAtIndex(self.filteredData,j-1);
            }

        }
         //CFRelease(self.contactAdd);
    //CFRelease(self.filteredData);
    }    

for 循环语句上显示内存泄漏,它说:

【问题讨论】:

  • 与这个问题极其相似:stackoverflow.com/questions/18010276/…
  • 当您说“分配的对象未在此执行路径中保留 late [原文如此]”时,您的意思是“引用”还是“释放”?如果您已经 +1,它没有理由建议保留它。 (更一般地,请从问题导航器中复制并粘贴警告,而不是尝试重新输入它们。)
  • “如果我使用这种格式,我的内存泄漏问题在这里解决了,但我的程序出错了”什么错误?

标签: ios objective-c xcode memory-leaks core-foundation


【解决方案1】:

就像我在my answer on your other questionin Core Foundation, Create and Copy functions return an ownership reference.中提到的那样

保存对象的属性通常也拥有引用,除非您另外声明它们(通常使用weak)。这意味着,在这样的声明中:

self.filteredData= CFArrayCreateMutable(…);

您现在拥有该对象两次:一次是因为您创建了它,一次是因为您的财产保留了它。

您通常应该只对每个属性、ivar 或其他强引用(例如局部变量)拥有每个对象一次。任何额外的所有权(例如来自 Create 和 Copy 函数)都是您需要清理的东西,这就是为什么最好在 CF-land 中做的事情越少越好:ARC 会为您清理东西,但不会触及 CF除非你告诉它。

谈到属性和局部变量,您不需要将所有内容都设为属性。搜索代码中的person 应该是该方法中的局部变量,因为这是该搜索状态的一部分,而不是您的对象需要无限期保留的东西。您已经将 str 作为局部变量,所以我不确定您为什么使用 person 的属性。

您告诉 ARC 通过桥接演员与 CF 世界互动:

  • __bridge_transfer(或 CFBridgingRelease)告诉 ARC “当我完成此所有权时,请为我清理它”。
  • __bridge_retained(或CFBridgingRetain)告诉ARC“我要把这个物体扔进CF-land;除非我另有说明,否则不要放手”(然后您必须在某个时候通过转移或立即发送 CFRelease 来做到这一点)。

同样,您通常希望将事情从 CF 世界中剔除,并让 ARC 尽可能多地处理它们。

因此,我建议将self.filteredData 设为 NSMutableArray,而不是 CFMutableArray。使用 Foundation 创建数组意味着它已经在 ARC 的控制之下,无需桥接。

对于self.contactAdd,您可以在检索它时将其桥接到 NSArray,然后从那时起将其视为 NSArray。这包括使用快速枚举而不是索引来遍历它,或者更好的是,使用谓词搜索而不是自己遍历它。 (我不会指望内置的比较谓词能够与 ABPersons 一起使用,但这就是 predicateWithBlock: 的用途。)

您的搜索代码的基于谓词的版本看起来像这样(未经测试):

self.filteredData = [self.contactAdd filteredArrayUsingPredicate:[NSPredicate predicateWithBlock:^BOOL(id evaluatedObject, NSDictionary *bindings){
    ABPersonRef person = (__bridge ABPersonRef)evaluatedObject;
    NSString *firstName = [[NSString stringWithFormat:@"%@", (__bridge_transfer NSString *)ABRecordCopyValue(self.person, kABPersonFirstNameProperty)] stringByTrimmingCharactersInSet:[NSCharacterSet whitespaceCharacterSet]];

    NSRange contactRange = [str rangeOfString:searchText options:NSCaseInsensitiveSearch];
    return (contactRange.location != NSNotFound);
}];

(块和基于它的谓词返回每个对象是否匹配。filteredArrayUsingPredicate: 创建一个数组,其中包含谓词评估为true 的每个对象。)

还有一件事:您是否考虑过使用 ABPeoplePickerNavigationController?

【讨论】:

  • 我能够通过使用 _addressbook 而不是 self.addressBook 来解​​决问题。所有问题在 xcode 4.6 中都消失了,但 _addressbook 似乎不适用于 4.2,但桥接版本似乎适用于该版本。对于您的另一个问题,是的,我已经使用 ABPeoplePickerNavigationController 完成了相同的操作,并且效果很好,我只是想在另一种使用 CFArray 的方法中尝试一下。感谢您的支持:)
【解决方案2】:

显然您在viewDidLoad 的末尾缺少[addContactButton release]。另外,为什么CFRelease 调用被注释掉了?他们应该平衡CFArrayCreateMutable

关于 self.contactAdd - 如果它被定义为“保留”属性,请不要直接为其分配 ABAddressBookCopyArrayOfAllPeople 的返回值。相反,实例化一个局部变量,将其分配给属性,然后使用CFRelease 释放它

【讨论】:

  • [addContactButton release] 不是必需的,因为它的 ARC 并且即使我尝试添加它,ARC 也会禁止它。如果添加了 CFRelease,我会收到消息,该属性返回具有 +0 保留计数的核心基础对象。我尝试将 ABAddressBookCopyArrayOfAllPeople 的值分配给另一个变量,警告消失了,但出现运行时错误:(
  • 对不起,你没有提到 ARC
  • self.contactAdd=(__bridge_retained CFArrayRef) CFBridgingRelease(contactAddtemp);我能够在另一个变量以及这个 bridgerelease 函数的帮助下解决第一个警告,但第二个警告仍然没有消失。
  • @Gamerlegend:这两件事相互抵消了。完全等同于说self.contactAdd = contactAddTemp;
猜你喜欢
  • 2019-01-01
  • 2013-09-02
  • 2015-06-28
  • 2012-08-19
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多