Код Telegram считают эталоном, но почему он лагает на топовых устройствах?

Telegram для iOS - это технически сложный продукт. В кодовой базе 2.1 миллиона строк, 700+ модулей, 86% написано на Swift. Проекту больше 13 лет. Но при этом приложение регулярно лагает на флагманских устройствах, открывает по несколько дублей окон и годами крешится при редактировании изображений.

Почему так происходит, если код считается одним из лучших в индустрии?

Ответ звучит неожиданно: разработчики пишут на Swift, но мыслят в парадигме объектно-ориентированного программирования, как будто работают с Java. А Swift для этого не предназначен.

В чем проблема ООП в Swift:

Swift - это язык, архитектура которого заточена под Protocol Oriented Programming. Компилятор умеет оптимизировать код, написанный в этой парадигме: убирать лишние вызовы, встраивать функции, специализировать дженерики. Все это дает производительность, близкую к C.

Но когда разработчики используют классы и иерархии наследования так, как это делают в Java, компилятор не может применить эти оптимизации. Каждый вызов метода идет через виртуальную таблицу, а это в 3-4 раза медленнее прямого вызова.

Цена ООП-подхода в Swift:

На небольших проектах разница незаметна. Но на масштабах Telegram она становится критичной. По оценкам, из-за ООП-подхода приложение теряет от 10% до 25% производительности CPU. Лишние 20-30% памяти уходят на аллокации в куче там, где можно было использовать структуры.

Фреймрейт в ключевых пользовательских сценариях мог бы быть выше на треть. А количество крашей сократилось бы просто потому, что исчезла бы часть неожиданных мутаций общего состояния, которые неизбежны при работе с классами.

Типичные симптомы ООП-мышления в коде Telegram:

В кодовой базе есть классы на 11 тысяч строк. Например, ChatControllerImpl. Это прямой результат парадигмы, которая поощряет концентрацию логики в одном месте.

Постфикс Impl - еще один характерный признак. Это наследие Java 90-х, где один интерфейс равнялся одной реализации. В Swift протокол - это описание способности, а не место в иерархии. Когда у протокола есть ровно одна реализация с суффиксом Impl, это почти всегда симптом: протокол создан по привычке, а не осознанно.

Ссылочный хаос - еще одна проблема. Классы передаются по ссылке и два модуля могут держать один объект, незаметно меняя его состояние. В POP со структурами семантика копирования явная, без неожиданных сайд-эффектов.

Что можно было бы сделать:

Переход на Protocol Oriented Programming не требует полной переписки приложения. Но точечные изменения могли бы дать заметный эффект.

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

Там, где сейчас используются полиморфные классы с двумя-тремя вариантами, лучше подошли бы enum с ассоциированными значениями.

Протоколы с ассоциированными типами и расширениями по умолчанию позволили бы переиспользовать код без дублирования, а компилятор получил бы полную информацию для оптимизации.

И главное - избавиться от бессмысленных Impl. Каждый такой класс должен стать либо структурой с несколькими мелкими протоколами, либо исчезнуть, если протокол создавался только ради него.

Вывод:

Telegram - это огромный и сложный проект. Его разработчики проделали колоссальную работу. Но архитектурный подход, выбранный много лет назад, сегодня тормозит приложение. ООП в Swift - это не просто устаревший стиль. Это потерянная производительность.

Swift дает возможность писать почти так же быстро, как на C, но только если использовать его правильно. Protocol Oriented Programming - это не просто модный термин, а путь к реальной оптимизации. И чем крупнее проект, тем заметнее разница.

Telegram мог бы работать быстрее, потреблять меньше памяти и реже падать. Для этого не нужно переписывать все с нуля. Достаточно начать мыслить в парадигме языка, а не тащить за собой привычки из прошлого.