我对一个对象进行了五次分配,而同一函数中只有一次分配

发布于 2024-10-04 08:37:13 字数 1236 浏览 0 评论 0 原文

我正在编写一个仅在弹出窗口中显示菜单(由 tableView 组成)的函数。

这是源代码:

-(void)pushSearch:(NSString *)option type:(int)optionType
{
    searchNav = [[iNavigation alloc] initWithNibName:@"iNavigation" bundle:nil] ;
    //This is the UIViewController with the tableView

    [searchNav setSearchMode:optionType];

    searchNav.view.frame =CGRectMake(0,0,300,600);

    NSLog(@"Retain Count: %d",[searchNav retainCount]);

//At this point keep count is 1

    if ([pop isPopoverVisible])
    {
        [pop dismissPopoverAnimated:YES];
        [pop release];
    }

    pop = [[UIPopoverController alloc] initWithContentViewController:searchNav];

    NSLog(@"Retain Count: %d",[searchNav retainCount]);
    //At this point retain count is 2



    [pop presentPopoverFromRect:btnMenu.frame inView:self.view permittedArrowDirections:UIPopoverArrowDirectionAny animated:YES];
    [pop setPopoverContentSize:CGSizeMake(350,600)];

    NSLog(@"Retain Count: %d",[searchNav retainCount]);
    //At this point retain count is 5!!!

    [searchNav release];

}

我遇到的问题是加载表视图所使用的内存永远不会被释放。我的应用程序在内存中不断增长,直到崩溃。

为什么如果我只为 searchNav 分配一次,在将其分配给 popOver 后,reatin 计数为 5?

请问有什么帮助吗?

I'm writing a function that only displays a menu (composed by a tableView) in a popOver.

This is the source code:

-(void)pushSearch:(NSString *)option type:(int)optionType
{
    searchNav = [[iNavigation alloc] initWithNibName:@"iNavigation" bundle:nil] ;
    //This is the UIViewController with the tableView

    [searchNav setSearchMode:optionType];

    searchNav.view.frame =CGRectMake(0,0,300,600);

    NSLog(@"Retain Count: %d",[searchNav retainCount]);

//At this point retain count is 1

    if ([pop isPopoverVisible])
    {
        [pop dismissPopoverAnimated:YES];
        [pop release];
    }

    pop = [[UIPopoverController alloc] initWithContentViewController:searchNav];

    NSLog(@"Retain Count: %d",[searchNav retainCount]);
    //At this point retain count is 2



    [pop presentPopoverFromRect:btnMenu.frame inView:self.view permittedArrowDirections:UIPopoverArrowDirectionAny animated:YES];
    [pop setPopoverContentSize:CGSizeMake(350,600)];

    NSLog(@"Retain Count: %d",[searchNav retainCount]);
    //At this point retain count is 5!!!

    [searchNav release];

}

The problem that I'm having is that the used memory to load the tableview is never released. My app grows and grows in memory until crashes.

Why if only i'm making one allocation for searchNav, after assign it to the popOver the reatin count is 5?

Please any help?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

紫南 2024-10-11 08:37:13

不要使用-retainCount。

对象的绝对保留计数是没有意义的。

您应该调用 release 的次数与导致对象被保留的次数完全相同。不能少(除非你喜欢泄漏),当然也不能多(除非你喜欢崩溃)。

请参阅内存管理指南了解完整详细信息。


保留计数为 5 是无关紧要的,而且很可能是因为各个框架的内部实现细节。

该代码中 searchNav 的内存管理是正确的;您分配了该对象(+1 保留),然后最终释放了它(-1 保留)。因此,内存泄漏是在其他地方。

尝试在您的源上使用“构建和分析”。然后使用分配工具来查看随着应用程序随着时间的推移而增长而悬挂的对象。某处存在过度保留;您尚未将其与释放进行平衡的保留。

Do not use -retainCount.

The absolute retain count of an object is meaningless.

You should call release exactly same number of times that you caused the object to be retained. No less (unless you like leaks) and, certainly, no more (unless you like crashes).

See the Memory Management Guidelines for full details.


That the retain count is 5 is irrelevant and quite likely because of internal implementation details of the various frameworks.

The memory management of searchNav in that code is correct; you allocated the object (+1 retain) and then you eventually released it (-1 retain). Therefore, the memory leak is somewhere else.

Try using "build and analyze" on your source. Then use the Allocations instrument to have a look at the objects that are hanging about as your app grows over time. There is an over-retain somewhere; a retain for which you haven't balanced it with a release.

橪书 2024-10-11 08:37:13

你释放了UIPopoverController吗?也许该对象仍然保留表视图。

Do you release the UIPopoverController ? Perhaps that object is still retaining the table view.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文