Мы склонны считать лейблы легкими с точки зрения использования памяти. В конце концов, они просто отображают текст.
UILabels на самом деле хранятся в виде растровых изображений, которые легко могут потреблять мегабайты памяти. К счастью, реализация UILabel умна и потребляет только то, что ей нужно:
🔘 Если ваш лейбл монохромен,
UILabel выберет CALayerContentsFormat из kCAContentsFormatGray8Uint (1 байт на пиксель). Но на немонохромные лейблы, например, для отображения «😰пожалуйста, попытайтесь сохранить душевное спокойствие, насколько можете» или многоцветные
NSAttributedString, потребуется использовать kCAContentsFormatRGBA8Uint (4 байта на пиксель).Монохромный лейбл потребляет не более
width * height * contentsScale ^2 * (1 byte per pixel), а немонохромный — в 4 раза больше: width * height * contentsScale ^2 * (4 byte per pixel).🔘 Например, на iPhone 11 Pro Max лейбл размером
414 * 100 точек может потреблять до: 414 * 100 * 3 ^ 2 * 1 = 372,6 КБ, а немонохромный 414 * 100 * 3 ^ 2 * 4 = ~ 1,49 МБ.Убедитесь, что вы всегда сначала измеряете, и рассматривайте возможность оптимизаций только в том случае, если ваша проблема с производительностью действительно связана с нехваткой памяти, вызванной лейблми.
В распространенном анти-паттерне лейблы ячеек
UITableView/UICollectionView остаются заполненными их текстовым содержимым, когда эти ячейки попадают в reuse queue. Весьма вероятно, что после повторного использования ячеек текстовое значение меток будет другим, поэтому их хранение расточительно.
✅️ Несложные советы, которые помогут освободить потенциально мегабайты памяти:
1️⃣ Обнуляйте текст лейблов, если вы сделаете их скрытыми и будете отображать только изредка.
2️⃣ Обнуляйте текст лейблов, если они отображаются в ячейках
UITableView/UICollectionView, в didEndDisplaying:forItemAt:📖 В этом материале есть ещё несколько советов, которые помогут вам улучшить производительность.
📖 А вот тут можно прочесть про изображения и пути оптимизации.
@iOS Dev