为什么在实现 NSCopying 时 zone 总是为零？

发布于 2024-12-13 00:53:05 字数 325 浏览 0 评论 0原文

这可能是一个简单的问题，但为什么在我的类中实现 NSCopying 协议，我得到 zone == nil

- (id)copyWithZone:(NSZone *)zone
{
    if (zone == nil)
        NSLog(@"why this is allways nil");

    (...)
}

这被称为使用此方法复制带有对象的数组。

[[NSArray alloc] initWithArray:myArray copyItems:YES]];

原文

It may be simple question, but why implementing NSCopying protocol in my class, I get zone == nil

- (id)copyWithZone:(NSZone *)zone
{
    if (zone == nil)
        NSLog(@"why this is allways nil");

    (...)
}

This is called using this method for copy array with objects.

[[NSArray alloc] initWithArray:myArray copyItems:YES]];

分享到QQ

分享到微博

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

发布评论

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

属性 2024-12-20 00:53:05

凯文和罗宾的回答是最准确的。奥斯卡的回答非常接近正确。但无论是 Gnustep 文档还是 logancautrell 关于区域存在的理由都不太正确。

最初创建区域（首先是 NXZone，然后是 NSZone）是为了确保从单个区域分配的对象在内存中相对连续，这是事实。事实证明，这并没有减少应用程序使用的内存量；而是减少了应用程序使用的内存量。在大多数情况下，它最终会稍微增加。

更大的目的是能够大规模摧毁一组物体。

例如，如果要将复杂的文档加载到基于文档的应用程序中，则在关闭文档时拆除对象图实际上可能会非常昂贵。

因此，如果文档的所有对象都是从单个区域分配的，并且该区域的分配元数据也在该区域中，那么与该区域相关的所有对象都会被销毁。文档将像简单地破坏该区域一样便宜（这真的很便宜 - “这里，系统，让这些页面回来” - 一个函数调用）。

事实证明这是行不通的。如果对区域中某个对象的单个引用泄漏到区域之外，那么一旦文档关闭，您的应用程序就会BOOM，并且该对象无法分辨所引用的内容它停止。其次，这个模型也遇到了 GC 系统中经常遇到的“稀缺资源”问题。也就是说，如果文档的对象图占用非内存资源，则无法在区域破坏之前有效地清理所述资源。

最后，性能提升不够（您真正关闭复杂文档的频率）与所有增加的脆弱性相结合，使区域成为一个坏主意。然而，改变 API 已经太晚了，我们留下了痕迹。