释放子视图

发布于 2024-10-05 22:57:02 字数 183 浏览 0 评论 0原文

我对 iOS 编程相当陌生,并且我正在开发的 iPad 应用程序遇到问题。 每次点击 splitview 根视图中的单元格时,我都使用 splitview 控制器将子视图添加到 splitview 的详细视图中。这很好,直到堆栈变得太高并且内存不足为止。新视图添加到堆栈后如何释放之前的子视图? 或者有更好的方法来解决这个问题吗?

谢谢

I'm fairly new at programming for iOS, and I am experiencing a problem with an iPad app I'm developing.
I am using a splitview controller to add a subview to the splitview's detailview every time a cell in the splitview's rootview is tapped. This is fine until the stack gets too high and I run out of memory. How can I release the previous subview after the new view is added to the stack?
Or is there a better way of solving this problem?

Thanks

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

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

发布评论

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

评论(1

眼眸里的那抹悲凉 2024-10-12 22:57:02

从其超级视图中删除视图:

[view removeFromSuperview];

超级视图将在此时释放该视图。因此,如果超级视图是唯一拥有引用的参与者,那么该视图将被释放。换句话说,这:

[superview addSubview:view];

导致超级视图保留视图。因此,您经常会看到如下代码块:

view = [[ViewClass alloc] initWithFrame:frame]; // I own view

[superview addSubview:view];                    // superview and I both own view

[view release];                                 // now only superview owns view;
                                                // it'll be deallocated if
                                                // superview ever relinquishes
                                                // ownership

现在您有了一个指向视图的指针,只要该视图保留在超级视图中,该指针就有效。因此,随后将 removeFromSuperview 发布给它是安全的,但之后使用视图显然是不安全的。视图对象仅存在于alloc/init 和removeFromSuperview 之间。删除后它将被释放。

根据正常的 Cocoa 引用计数规则,以下内容与 alloc/init 和后续版本的直接替换几乎相同:

view = [ViewClass viewWithFrame:frame];  // view is an autoreleased object; 
                                         // the autorelease pool owns it

[superview addSubview:view];             // superview now owns view also

// the autorelease pool will relinquish ownership automatically, in the future...

如果您没有手动执行任何操作来影响行为,只是在正常的运行循环中,那么自动释放池中的内容在当前调用堆栈的生命周期内是安全的。在这种情况下,您将像在手动 alloc/init 示例中一样对待视图,可能只是为了保存一行代码并隐式保留内存管理而进行更改。

To remove a view from its superview:

[view removeFromSuperview];

The superview will release the view at that point. So if the superview is the only actor with an owning reference then the view will be deallocated. To put it another way, this:

[superview addSubview:view];

causes superview to retain view. So you often see blocks of code like:

view = [[ViewClass alloc] initWithFrame:frame]; // I own view

[superview addSubview:view];                    // superview and I both own view

[view release];                                 // now only superview owns view;
                                                // it'll be deallocated if
                                                // superview ever relinquishes
                                                // ownership

So you now have a pointer to view that is valid for as long as the view remains in the superview. So it's subsequently safe to post removeFromSuperview to it, but after that use of view is explicitly unsafe. The view object will live only between the alloc/init and the removeFromSuperview. It'll be deallocated upon being removed.

Per normal Cocoa reference counting rules, the following is pretty much the same as a drop-in replacement for an alloc/init and a subsequent release:

view = [ViewClass viewWithFrame:frame];  // view is an autoreleased object; 
                                         // the autorelease pool owns it

[superview addSubview:view];             // superview now owns view also

// the autorelease pool will relinquish ownership automatically, in the future...

If you haven't done anything manually to affect behaviour, being just in the normal runloop, then things in the autorelease pool are safe for the life of the current call stack. In this case you'd treat view exactly as you did in the manual alloc/init example, possibly having made the change just to save a line of code and leave memory management implicit.

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