解除分配 UIApplicationDelegate 拥有的对象有什么好处吗？
除了最佳实践之外，如果我创建一个由 UIApplicationDelegate 类拥有的对象，并且在应用程序运行的整个过程中都保持不变，那么在 UIApplicationDelegate 的 dealloc 方法中添加 [object release] 语句是否有任何真正的优势？
唯一被调用的时间是当用户关闭应用程序时，我假设该应用程序使用的整个内存空间随后被释放。
当然，从最佳实践的角度来看，在整个应用程序中一致地添加内存管理代码是有意义的，但我很好奇从执行的角度来看它是否真的重要？
注意：我是从 iPhone 开发者的角度问这个问题的。我不确定从 Mac OSX 的角度来看这是否会有所不同？
Best practices aside, if I create an object that is owned by my UIApplicationDelegate class, and stays around the entire time the application runs, is there any real advantage to adding an [object release] statement in the UIApplicationDelegate's dealloc method?
The only time that would be called is when the user is shutting down the application, and I assume the entire memory space used by that application is then freed.
From a best-practices standpoint, sure, it makes sense to add memory-management code consistently throughout the entire application, but I'm curious from an execution perspective if it actually matters?
Note: I'm asking this from an iPhone developer's perspective. I'm not sure if it would be different from a Mac OSX perspective?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
应用程序委托的
-dealloc几乎肯定永远不会被调用（如果是，则几乎肯定有错误），因此从这个意义上来说这并不重要。也就是说，在 Cocoa 开发中，最佳实践永远不会被忽视，内存管理中的仔细一致性是避免一些最难发现的错误的最有效方法。因此，一些额外的代码是值得的。但在这种情况下（还有很多其他类似这种情况的情况），在实践中这并不重要。The
-deallocfor the app delegate will almost certainly never be called (if it is, you almost certainly have a bug), so it doesn't matter in that sense. That said, in Cocoa development best practices are never aside, and careful consistency in your memory management is the single most effective way to avoid some of the hardest to find bugs. So a little extra code is well worth the trouble. But in this case (and there are many other cases like this case), it won't matter in practice.