Какие знаешь нюансы хранения строки?

Нюансы хранения строк в iOS/macOS (Foundation)

Хранение строк в iOS-экосистеме — сложная тема, затрагивающая абстракции Foundation/Swift, кодировки, внутреннее устройство памяти и производительность. Вот ключевые аспекты.

1. Кодировка символов (Character Encoding)

Строки по умолчанию используют UTF-16 внутри NSString (и String в Swift, как обёртка над ним). Это исторический выбор из-за Objective-C и совместимости с Cocoa. Однако Swift String с версии 5 скрывает это, работая с Unicode Scalar (UTF-32) для правильной обработки графем.

let string = "Привет! 🚀"
// Внутри NSString хранит UTF-16 код-поинты
// String работает с коллекцией Character (расширенные графем-кластеры)
print(string.count) // 8 символов, а не байтов

Нюанс: NSString может хранить данные в различных кодировках (UTF-8, UTF-16, ASCII), но при обращении к методам возвращает UTF-16. Конвертации между кодировками требуют времени.

2. Внутреннее устройство памяти

Swift String использует оптимизацию малых строк (Small String Optimization, SSO). Строки до 15 UTF-8 код-поинтов (в 64-битной системе) хранятся прямо в буфере самого объекта, без выделения динамической памяти.

let small = "abc" // Хранится в стеке (или внутри структуры String)
let large = "Очень длинная строка..." // Выделяет память в куче

Нюанс: NSString является class (ссылочный тип), а Swift String — struct (значимый тип). Копирование Swift String дешёвое благодаря Copy-on-Write (CoW).

var a = "Original"
var b = a // Нет реального копирования, общий буфер
b.append("!") // Тут происходит копирование

3. Графем-кластеры и индексы

Наиболее коварный нюанс — индексация. Из-за Unicode (эмодзи, акценты) доступ по целочисленному индексу невозможен за O(1). Требуется использовать String.Index.

let str = "Café🎯"
// str[3] // Ошибка
let index = str.index(str.startIndex, offsetBy: 3)
print(str[index]) // "é"

Нюанс: count — O(n) операция, так как нужно подсчитать все графем-кластеры. Для производительности в циклах лучше создавать индекс и двигать его.

4. Хранение и передача между мостами

При переходе между Swift String и NSString (например, в API Objective-C) мост (bridging) может вызывать копирование данных. Но toll-free bridging позволяет иногда обойтись без копий.

let swiftString: String = "Hello"
let nsString: NSString = swiftString as NSString // Может создать копию

Нюанс: Если строка содержит нестандартные символы (например, символы за пределами Basic Multilingual Plane), мост гарантированно вызывает копию.

5. Строковые литералы и пулы

Строковые литералы компилируются в строковые константы в бинарнике (секция __TEXT,__cstring). Повторяющиеся литералы объединяются.

let a = "Hello" // Оба указывают на одну область
let b = "Hello"

Нюанс: Строки, созданные динамически (например, через String(format:)), не попадают в пул.

6. Производительность и рекомендации

• Конкатенация: Избегайте построения строк в циклах через +. Используйте StringBuilder-подобные подходы:

var result = ""
for i in 0..<1000 {
    result.append("\(i) ")
}
// Или используйте JoinedSequence

• Извлечение подстрок (Substring): Substring ссылается на оригинальную строку, не копируя. Это эффективно, но может невольно удерживать память.

let original = "Большая строка..."
let substring = original.prefix(5) // Не копирует данные
let newString = String(substring) // Копирует при необходимости

7. Специфичные для iOS нюансы

• attributedString: Хранение атрибутов (шрифты, цвета) отдельно от текста, но связанно. Изменение строки требует пересчёта атрибутов.
• Локализация: Строки в Localizable.strings хранятся в UTF-16. Динамическое изменение языка может требовать пересчёта layout.
• Key-Value Observing (KVO): NSString поддерживает KVO для изменений, но Swift String (struct) — нет.

Заключение

Понимание внутренностей хранения строк критично для производительности (избегание неявных копий, правильная работа с индексами) и корректности (обработка Unicode). Всегда учитывайте контекст: работаете ли вы с Swift String для UI, NSString для старых API, или Substring для временных операций. Современный подход — использовать нативные Swift методы, которые абстрагируют сложности, но не забывать про стоимость операций.