Подумайте на мгновение, что каждое представление поддерживается CALayer. IIRC, представления имеют размер около 44 байтов (плюс foo), уровни имеют размер около 44 байтов (3 раза, поскольку существует дерево представления и дерево визуализации), а слои, которые выполняют любой рендеринг, поддерживаются растровыми контекстами.
Или, для более простого сравнения: каждый указатель потребляет столько же памяти, сколько один пиксель .
Я использую теги только там, где они облегчают мою жизнь:
- Множество похожих видов в кончике (куча кнопок, каждый из которых выбирает свой цвет). Я мог бы связать несколько точек, но тогда код должен был бы иметь дело с кучей иваров, а не с арифметикой).
- Множество подпредставлений со схожей функциональностью (например, «страницы» в представлении с прокруткой или в виде ячейки в контейнере, похожем на UITableView). Я мог бы отслеживать их в массиве, но сегодня мне лень.
- Всякий раз, когда мне нужно представление для хранения дополнительного целого числа (например, номер страницы). Существует множество других способов (создание подклассов, «связанных объектов», добавление значений в
layer.style ...). Как правило, это относится к первым двум местам.
Также помните, что [v viewWithTag:tag] может возвращать v, любое подпредставление, любое подпредставление подпредставления ... Рассмотрим класс FooView, который имеет «представление контента» с тегом 1 и «представление панели инструментов» с тег 2:
FooView * f1 = ...;
FooView * f2 = ...;
[f1.contentView addSubview:f2];
NSLog(@"%@ %@", f1.toolbarView, f2.toolbarView);
Что это печатает? Ну, они оба могут быть панелью инструментов f2!
Да, Apple могла бы сделать поиск более осмысленным (она могла бы продолжать поиск до тех пор, пока не обнаружит наименее глубокое совпадение или не использовала поиск с глубиной итеративного углубления вначале), но я предполагаю, что она выполняла простой поиск в глубину если в документации не указано иное.