Перейти на PRO

Какие проблемы решает RxSwift в iOS-разработке?

Тип вопроса: Реактивное программирование Вероятность: 10% Категория: IOS Разработчик

Ответ

RxSwift — это фреймворк для реактивного программирования, который упрощает работу с асинхронными и событийно-ориентированными потоками данных с помощью наблюдаемых последовательностей (Observables).

Решаемые проблемы:

  1. Управление асинхронностью: Объединяет различные асинхронные паттерны (делегаты, колбэки, уведомления, KVO) в единый, последовательный подход.
  2. Обработка сложных цепочек событий: Позволяет декларативно комбинировать, трансформировать и фильтровать потоки данных (например, поиск с debounce).
  3. Избежание состояния гонки (Race Conditions): Четко определенный поток событий и операторы (например, flatMapLatest) помогают управлять зависимыми асинхронными операциями.
  4. Управление памятью и отписками: DisposeBag автоматически отменяет все подписки при деинициализации объекта, предотвращая утечки памяти.

Практический пример: поиск с debounce и отменой предыдущего запроса:

import RxSwift
import RxCocoa

class SearchViewController: UIViewController {
    @IBOutlet weak var searchBar: UISearchBar!
    @IBOutlet weak var tableView: UITableView!

    private let disposeBag = DisposeBag()
    private let viewModel = SearchViewModel()

    override func viewDidLoad() {
        super.viewDidLoad()

        // Связывание UI с логикой
        searchBar.rx.text.orEmpty
            .debounce(.milliseconds(300), scheduler: MainScheduler.instance) // Ждем завершения ввода
            .distinctUntilChanged() // Игнорируем повторяющиеся значения
            .flatMapLatest { query -> Observable<[Repository]> in
                // Отменяем предыдущий запрос при новом вводе
                return self.viewModel.search(query: query)
                    .catchAndReturn([]) // Обрабатываем ошибки
            }
            .observe(on: MainScheduler.instance)
            .bind(to: tableView.rx.items(cellIdentifier: "Cell")) { index, repo, cell in
                cell.textLabel?.text = repo.name
            }
            .disposed(by: disposeBag)
    }
}

Компромиссы: Высокий порог входа, избыточность для простых задач, возможное снижение читаемости при неправильном использовании. Для новых проектов стоит также рассмотреть нативный фреймворк Combine (требует iOS 13+).

Ответ 18+ 🔞

Смотри, ну вот есть такая штука — RxSwift. Это, блядь, такая библиотека, которая пытается превратить твой обычный, понятный, но иногда ебучно запутанный асинхронный код во что-то последовательное и управляемое. Представь, что у тебя в проекте всё летает: делегаты там, колбэки, уведомления, KVO — пиздец, а не зоопарк. Так вот RxSwift берёт этот зоопарк и говорит: «А давайте, сука, всё через одну трубу!». И эта труба — Observable, наблюдаемая последовательность.

Что она, эта падла, решает на практике:

  1. Асинхронность, ёпта. Вместо того чтобы метаться между completion handler'ом, делегатом и NotificationCenter, ты всё пишешь в одном стиле. Поток данных идёт по трубе, а ты на разных участках ставишь фильтры и преобразователи. Красота.
  2. Сложные цепочки событий. Ну, типа поиска, где надо ждать, пока пользователь допечатает, отменять старый запрос, если он ввёл новую букву — весь этот цирк описывается парой операторов. Без этих плясок с бубном вокруг таймеров и флагов.
  3. Состояние гонки (Race Conditions). Знаешь, когда два запроса улетели, а прилетели в разном порядке и всё ебнулось? Так вот, операторы вроде flatMapLatest позволяют новой задаче просто похерить предыдущую, если она ещё не завершилась. Элегантно, чёрт возьми.
  4. Утечки памяти, отписки. Классика: подписался на уведомление, забыл отписаться — получил креш или просто тихую утечку. В RxSwift есть DisposeBag. Ты просто кидаешь в него свои подписки, а когда твой объект (например, вьюконтроллер) сдохнет, этот мешок автоматом всё отпишет. Вообще всё. Волшебство, блядь.

Вот, смотри, как это выглядит в живую. Допустим, поиск:

import RxSwift
import RxCocoa

class SearchViewController: UIViewController {
    @IBOutlet weak var searchBar: UISearchBar!
    @IBOutlet weak var tableView: UITableView!

    private let disposeBag = DisposeBag() // Мешок для мусора (подписок)
    private let viewModel = SearchViewModel()

    override func viewDidLoad() {
        super.viewDidLoad()

        // Вся магия связывания здесь
        searchBar.rx.text.orEmpty // Берём текст из поисковой строки
            .debounce(.milliseconds(300), scheduler: MainScheduler.instance) // Ждём, пока пользователь перестанет долбить по клавиатуре
            .distinctUntilChanged() // Если ввел то же самое — игнорируем
            .flatMapLatest { query -> Observable<[Repository]> in
                // Ключевой момент! Если пока летел старый запрос, а пользователь уже ввёл новое — старый запрос отменяется нахуй.
                return self.viewModel.search(query: query)
                    .catchAndReturn([]) // Если сетевая ошибка — возвращаем пустой массив, не крешимся
            }
            .observe(on: MainScheduler.instance) // Гарантируем, что дальше работаем в главном потоке
            .bind(to: tableView.rx.items(cellIdentifier: "Cell")) { index, repo, cell in
                cell.textLabel?.text = repo.name // Наполняем ячейку
            }
            .disposed(by: disposeBag) // Кидаем подписку в мешок, чтобы потом не искать, где её отменять
    }
}

Но, конечно, не всё так радужно, ёпта. Компромиссы есть:

  • Порог входа — овердохуищный. Пока вьебешься в эту реактивную парадигму, полголовы поседеет.
  • Избыточность для простых задач. Если тебе надо просто показать алерт по тапу на кнопку — нехуй тут городить Observable.
  • Можно сделать ещё хуже. Если начать бездумно цеплять операторы, получится такая лапша, что сам чёрт ногу сломит. Читаемость на нуле.

И да, если проект новый и таргет на iOS 13+, есть смысл глянуть на нативный Combine от Apple. Но это, как говорится, уже совсем другая история, блядь.

© ХакСобесов, 2026
support@hacksobesov.com