UIView ivar 与标记本地 UIView var

发布于 2024-09-25 04:23:42 字数 747 浏览 8 评论 0原文

场景一：对于 UIViewController，最好 (1) 为我在 loadView 之外的 1 或 2 个函数中再次访问的 UIView 创建一个 ivar？或者，（2）我应该在 loadView 中标记它，然后使用 - (UIView *)viewWithTag:(NSInteger)tag 在其他函数中再次访问它？我猜测选项 1 将内存增加了指针的大小，即 32/64 位，并创建访问器方法（假设我声明 @property & @synthesize），然后需要在dealloc中释放ivar并在viewDidUnload中将其设置为nil...并且选项2可以节省内存，设置代码较少，但需要一些处理时间和一些额外的代码来通过标签查找视图。我对这一切的看法正确吗？

在这种情况下，感觉最好使用 ivar，但我不确定。

场景2：对于具有 5 个子视图的 UIView 自定义子类怎么样？请记住，在给定时间，我将在内存中拥有大约 30 个此自定义子类的实例（它们将是 tableViewCell 的子视图。），我应该为子视图使用 5 个 ivars，还是我应该给它们全部贴上标签吗？

在这种情况下，我认为通过标记它们节省的内存值得使用 - (UIView *)viewWithTag:(NSInteger)tag 搜索它们带来的小性能损失。

想法？

谢谢！

马特

原文

分享到QQ

分享到微博

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

发布评论

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

黑凤梨 2024-10-02 04:23:42

考虑到内存使用量的差异可以忽略不计（除非您将拥有 100 个这样的视图，在这种情况下您可能想研究如何重用其中一些视图），您可能应该考虑什么会让您的代码更有用可读且可维护。我个人认为使用 ivar 会更具可读性，但对于您的特定情况，使用标签也可能更具可读性。

在编写代码时，我总是尝试考虑一两年后将阅读代码的人。这个人可能是我，也可能是其他人，但无论哪种方式，我知道那个人都会欣赏可读的代码。他们不太可能感谢我在至少有 128 MB RAM 的设备上节省了 1k 内存。

回复收藏 0 原文

黑寡妇 2024-10-02 04:23:42

考虑一下，每个视图都由 CALayer 支持。 IIRC，视图大约为 44 字节（加上 foo），图层大约为 44 字节（乘以 3，因为有表示树和渲染树），并且执行任何渲染的图层均由位图上下文支持。

或者，进行更直接的比较：每个指针消耗的内存与单个像素一样多。

我只在标签让我的生活更轻松的地方使用标签：

笔尖中有很多类似的视图（一堆按钮，每个按钮选择不同的颜色）。我可以连接一堆插座，但是代码必须处理一堆 ivars 而不是一些算术）。
许多具有类似功能的子视图（例如滚动视图中的“页面”，或类似 UITableView 的容器中的单元格视图）。我可以在数组中跟踪它们，但今天我感到很懒。
每当我需要一个视图来存储额外的整数（例如页码）时。还有很多其他方法（子类化、“关联对象”、将值粘贴在layer.style...）。这通常与前两个地方相关。

另外，请记住 [v viewWithTag:tag] 可以返回 v、任何子视图、任何子视图的子视图...考虑一个具有“内容视图”的 FooView 类” 带有标签 1，“工具栏视图” 带有标签 2：

FooView * f1 = ...;
FooView * f2 = ...;
[f1.contentView addSubview:f2];
NSLog(@"%@ %@", f1.toolbarView, f2.toolbarView);

它打印什么？好吧，它们都可以成为 f2 的工具栏！

是的，苹果可以使搜索更加合理（它可以继续搜索，直到找到最不深度的匹配，或者使用迭代加深深度优先搜索），但我假设它执行简单的深度优先搜索，除非文档另有说法。

Consider, for a moment, that each view is backed by a CALayer. IIRC, views are about 44 bytes (plus foo), layers are about 44 bytes (times 3, since there's a presentation tree and render tree), and layers which do any rendering are backed by bitmap contexts.

Or, for a more straightforward comparison: Each pointer consumes as much memory as a single pixel.

I use tags only where they make my life easier:

Lots if similar views in a nib (a pile of buttons, each selecting a different colour). I could wire up a bunch of outlets, but then the code would have to deal with a bunch of ivars instead of a bit of arithmetic).
Lots of subviews with similar functionality (e.g. "pages" in a scroll view, or cell-like views in a UITableView-like container). I could keep track of them in an array, but I'm feeling lazy today.
Whenever I need a view to store an extra integer (e.g. a page number). There are plenty of other ways (subclassing, "associated objects", sticking values in layer.style...). This is generally relevant to the first two places.

Also, remember that [v viewWithTag:tag] can return v, any subview, any subview-of-subview... Consider a class FooView which has a "content view" with tag 1, and a "toolbar view" with tag 2:

FooView * f1 = ...;
FooView * f2 = ...;
[f1.contentView addSubview:f2];
NSLog(@"%@ %@", f1.toolbarView, f2.toolbarView);

What does it print? Well, they both could be f2's toolbar!

Yes, Apple could make the search more sensible (it could continue the search until it found the least-deep match, or use iterative-deepening depth first search), but I'd assume that it performed simple depth-first search unless the documentation says otherwise.

回复收藏 0 原文