Были ли проблемы на проде на прошлом месте работы?

Разбор реальных проблем на production в iOS-разработке

За время моей карьеры iOS-разработчика мне довелось сталкиваться с различными инцидентами на production. Опишу один из наиболее показательных случаев, который произошёл в fintech-приложении с аудиторией около 2 млн активных пользователей.

Инцидент с фоновой геолокацией и утечкой памяти

Суть проблемы: В определённой версии приложения (1.4.3) мы столкнулись с критической утечкой памяти у 15-20% пользователей, которая приводила к падению приложения через 20-30 минут после запуска. Проблема была особенно заметна на устройствах с меньшим объёмом ОЗУ (iPhone 8 и старше).

Технический контекст:

• Приложение активно использовало фоновое обновление геопозиции для фич, связанных с банковскими отделениями и ATM
• Реализация была на основе CLLocationManager с настройкой allowsBackgroundLocationUpdates
• Для обработки и кэширования координат использовался кастомный менеджер на синглтоне

Корневая причина: После тщательного анализа через Instruments и логов Crashlytics выявили две взаимосвязанные проблемы:

1. Retain cycle в синглтоне геосервиса:

// ПРОБЛЕМНЫЙ КОД (упрощённо)
class LocationService {
    static let shared = LocationService()
    private let locationManager = CLLocationManager()
    private var callbacks: [(CLLocation) -> Void] = []
    
    private init() {
        locationManager.delegate = self
        // Проблема: делегат создавал сильную ссылку
    }
    
    func subscribe(callback: @escaping (CLLocation) -> Void) {
        callbacks.append(callback) // Утечка: массив хранил замыкания с self
    }
}

extension LocationService: CLLocationManagerDelegate {
    func locationManager(_ manager: CLLocationManager, 
                        didUpdateLocations locations: [CLLocation]) {
        callbacks.forEach { $0(locations.last!) }
        // Проблема: объекты, передавшие callbacks, не освобождались
    }
}

1. Некорректная обработка фонового режима: При переходе в background мы не уменьшали точность и частоту обновлений, что приводило к excessive battery drain и дополнительной нагрузке на память.

Процесс решения и меры

Немедленные действия:

• Выпустили хотфикс с понижением частоты геообновлений в фоне
• Добавили автоматическое отписывание колбэков через weak references
• Внедрили мониторинг потребления памяти в реальном времени

Долгосрочные улучшения:

1. Рефакторинг архитектуры:

// ИСПРАВЛЕННАЯ РЕАЛИЗАЦИЯ
class SafeLocationService {
    private let locationManager: CLLocationManager
    private var subscribers = NSHashTable<AnyObject>.weakObjects()
    
    func subscribe(_ subscriber: LocationSubscriber) {
        subscribers.add(subscriber)
    }
}

protocol LocationSubscriber: AnyObject {
    func didUpdateLocation(_ location: CLLocation)
}

1. Внедрили многоуровневое логирование:

   • Событийные метрики для геосервиса
   • Профилирование памяти в ключевых точках
   • Фоновую отправку диагностических данных

2. Улучшили процессы:

   • Обязательный memory check в ревью кода для паттернов делегатов и замыканий
   • Стресс-тесты на старых устройствах перед каждым релизом
   • Canary-релизы для 1% пользователей перед полным rollout

Ключевые выводы

Процессуальные уроки:

• Инцидент подчеркнул важность инструментов мониторинга на проде (не только крашей, но и перформанс метрик)
• Проблема обнаружилась не сразу, так как на симуляторах и мощных девайсах разработчиков она не воспроизводилась
• Недооценили важность тестирования на старом железе

Технические инсайты:

1. Синглтоны — опасный антипаттерн для объектов с жизненным циклом
2. Фоновые сервисы требуют агрессивной оптимизации (accuracy reduction, batch processing)
3. Weak reference chains должны быть стандартом для callback-архитектур

Результат: После исправлений количество OOM-крашей (Out Of Memory) уменьшилось на 94%, а жалобы на быстрый разряд батареи — на 70%. Инцидент стал кейсом для внедрения formal post-mortem анализа всех значимых сбоев в команде.

Этот опыт подтвердил, что даже хорошо протестированные фичи могут вызывать проблемы на определённых конфигурациях, и важно иметь robust-инструменты для быстрого обнаружения и диагностики production-инцидентов.