UIView ivar versus tagging local UIView var

Question

Scenario 1: Is it better for the UIViewController to (1) create an ivar for the UIView so that I can again access 1 or 2 functions outside the loadView ? Or, (2) should you just tag it in loadView and then use the - (UIView *)viewWithTag:(NSInteger)tag to access it again in other functions? I assume that option 1 increases the memory by the size of the pointer, so it is 32/64-bit and creates access methods (assuming I declare @property and @synthesize ), and then requires freeing ivar in dealloc and setting it to nil in viewDidUnload ... and that option 2 saves memory, has less setup code, but it takes some processing time and a bit of extra code to find the view by its tag. Am I right about all this?

In this scenario, ivar is best used, but I'm not sure.

Scenario 2: What about a custom subclass of UIView that has 5 subclauses? Whereas I will have about 30 instances of this custom subclass in memory at this point in time (they will be covered in tableViewCell s.), Should I use 5 ivars for subviews, or should I mark them all

In this scenario, I think that the memory saved by tagging them all would cost a little performance improvement when searching with the - (UIView *)viewWithTag:(NSInteger)tag .

Thoughts?

Thanks!

Matt

Answer 1

Given that the difference in memory usage is not significant (unless you have 100 of these views, in which case you might need to learn how you can reuse some of these views), you should probably think about what will make your code more readable and maintainable. I personally believe that using ivar will be more readable, but it is also possible that for your specific case, using tags will be more readable.

When writing code, I always try to think about the person who is going to read the code in a year or two years. This person can be me, or it can be someone else, but in any case, I know that this person will appreciate the read code. They are less likely to thank me for saving 1 thousand. Memory on a device with a memory capacity of at least 128 MB.

Answer 2

Consider for a moment that each look is supported by CALayer. IIRC, views are about 44 bytes (plus foo), levels are about 44 bytes (3 times, since there is a view tree and a render tree), and layers that perform any rendering are supported by raster contexts.

Or for a simpler comparison: each pointer consumes as much memory as one pixel.

I only use tags where they make my life easier:

• A lot if there are similar representations at the tip (a bunch of buttons, each of which selects a different color). I could connect a bunch of outlets, but then the code would have to deal with a bunch of Ivars, not some arithmetic).
• Many subzones with similar functionality (for example, “pages” in a scroll view or cell views in a container like a UITableView). I could track them in an array, but today I feel lazy.
• Whenever I need a view to store an extra integer (like page number). There are many other ways (subclasses, "related objects", sticking values ​​in layer.style ...). This usually refers to the first two places.

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

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

What is he typing? Well, both of them can be f2 toolbar!

Yes, Apple can make the search more reasonable (it can continue the search until it finds the least deep match or starts searching by the depth of iterations), but I would suggest that it would perform a simple search by depth unless otherwise specified in the documentation .

Answer 3

I think you are asking the wrong question.

It seems to me that either the memory needed to store 5 pointers or the time needed to search 5 views using viewWithTag: will be insignificant in the grand scheme of things.

Choose whichever solution you choose makes your code the easiest to write, understand and maintain.

In the unlikely event that the actual time / memory usage profiling indicates that the solution you have chosen is a problem, consider another option. Everything else is premature optimization.