Привет! Меня зовут Александр Денисов, я из команды мобильного Яндекс.Браузера в Санкт-Петербурге. В этом посте расскажу вам, как мы справляемся с циклическими крешами на старте.
Каждый разработчик знает, насколько важна для пользователя надёжность продукта. В работе над стабильностью приложения могут помочь выстроенные процессы разработки и тестирования, продвинутые средства диагностики. Однако всё предусмотреть невозможно, особенно если ваш проект большой и сложный. И рано или поздно вы, скорее всего, столкнётесь с проблемой циклического креша на старте. Сейчас разберёмся, как можно обработать этот сценарий.
В качестве примера будет выступать приложение Яндекс.Браузер для iOS: более 100 тысяч исходных файлов, тысячи коммитов в год и около тысячи модулей без учёта ядра (Swift + Objective-C). Кстати, не так давно мы рассказывали, как помогли команде Swift ускорить отладчик.
Циклический креш на старте
Представьте, что в вашем приложении есть баг, приводящий к крешу. Несложно, правда? Причём возникает баг из-за редкого сочетания факторов, и происходит это на старте. С некоторой вероятностью баг останется незамеченным во время тестирования и попадёт в версию для App Store. А дальше пострадавшие пользователи столкнутся с приложением, которое крешится прямо на старте, и перезапуск уже не помогает — только переустановка.
Как бороться