Код Telegram iOS — лучший в индустрии. Почему же он так лагает на флагманах?

TL;DR из-за ООП

Я программирую под iOS с 2010 года. Начинал в геймдеве, хорошо прокачался в C/C++, пытался развивать iOS-направление в тогдашнем Мэйл.ру — в 2011-м там была всего одна команда под iOS это ICQ.

Сегодня работаю кросс-функциональным архитектором, пишу больше на Go, но Swift люблю, понимаю Swift Runtime/LLVM + эти знания помогают понимать Rust. Я с 2015 года регулярно участвовал в проектировании мессенджеров — бэкенд и мобайл, даже делали аналог мессенджера запрещенной соцсети на MQTT + Thrift с кодогенерацией. И хорошо понимаю проблемы масштаба крупных мобильных проектов.

В быту Telegram использую по максимуму — Premium, 1000 чатов под завязку, баги ловлю каждый день на iPhone 17 Air и iPad Pro 12.9 с M2. По выходным собираю архитектурные стат-анализаторы кода. Swift-овый отлаживаю прямо на кодовой базе Telegram для iOS.

Что происходит?

Telegram — технически самый сложных мессенджер в мире. В iOS приложении 2.1M+ строк, 700+ модулей, 86% Swift, 13 лет кодовой базы, и мало ObjC — это колоссальный труд.

Но при этом приложение лагает на флагманах, AsyncDisplayKit открывает по 10 дублей окон разом(а это явно тормозит ARC), крэши на редактировании изображений стабильны годами.

Почему?

Потому что 86% кода написаны на Swift, но разработчики мыслят все еще в парадигме ООП.

ООП в Swift — это не просто устаревший стиль, это потерянная производительность.

Swift — не Java и не Kotlin. Это язык, архитектура которого буквально заточена под Protocol Oriented Programming. При компиляции SIL (Swift Intermediate Language) умеет убирать косвенную диспетчеризацию, инлайнит вызовы, специализирует дженерики. И лучше всего это работает если вы пишите в парадигме Protocol Oriented Programming.

На небольших проектах POP или ООП не особо незаметно, когда как на гигантских это треть производительности приложения.

Насколько бы лучше работал телеграм с 80%+ POP:

• от 10 до 25% лишнего CPU-оверхеда из-за медленной диспетчеризации через Virtual Table там, где мог быть Direct Dispatch

• +20–30% к памяти из-за ненужных аллокаций в куче вместо value-типов

• Фреймрейт в горячих User-флоу вырос бы минимум на треть при переходе на POP

• Крэшей стало бы меньше — просто потому что исчезла бы часть неожиданных мутаций shared-состояния

Проблемы производительности идущие от ООП в Swift:

1. Virtual table когда этого можно избежать. Каждый вызов метода через иерархию классов — это в 3-4 раза дороже по времени CPU чем Direct-диспатчеризация. POP + дженерики позволяют компилятору больше использовать Direct.

2. Ссылочный хаос и shared состояния. Классы передаются по ссылке. Два модуля держат один объект и тихо меняют его состояние. POP со структурами даёт явную семантику копирования — без магии, без неожиданных сайдэффектов.

3. SOLID способствует появлению God-классов. ООП это стимулирует архитектурно. ChatControllerImpl на 11К строк, loadDisplayNodeImpl() на 4.2К строк — закономерный исход, когда парадигма ООП поощряет концентрацию логики.
Я понимаю, что про просто декомпозировать ChatController нельзя, это усложнит разработку, но здесь можно реализовать через «протоколы-способности» из POP.

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

5. Автоматизация тестирования становится адом. Чтобы замокать один класс в середине иерархии, нужно поднять всю цепочку. В POP каждый протокол мокается отдельно.

Отдельно про …Impl

Постфикс Impl — это окаменелость из мира Java 90-2000-x: один интерфейс = одна реализация. В Swift это не только бессмысленно, но и вредно.

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

Очень поверхностный план рефакторинга

При таком масштабе кода (2,15 млн строк) рефакторинг даст заметный выигрыш на айфонах: даже увеличится автономность на 10–20% за счёт снижения активности ARC.

1. Перепроектировать UI-компоненты — заменить крупные иерархии (ChatControllerImpl, PresentationGroupCallImpl) на протоколы с ассоциированными типами и структуры. Компилятор сможет специализировать код и убрать лишние диспетчеризации.

2. some Protocol вместо классов-обёрток — some фиксирует конкретный тип на этапе компиляции, полностью статическая диспетчеризация, как у структур.

3. enum с ассоциированными значениями — там, где сейчас полиморфные классы с двумя-тремя вариантами (ChatLocationInfoData и подобные), enum справится лучше и дешевле.

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

5. Зачищать …Impl — каждый найденный …Impl должен стать либо структурой с несколькими мелкими протоколами, либо исчезнуть, если протокол создавался только ради него.

   

Swift уже умеет давать почти C-образную производительность с использованием POP. Telegram, при всём уважении к масштабу работы, теряет около 25% производительности — просто потому что команда проектирует на Swift как на Java: из-за превычек и образа мышления которому учат у нас в каждом университете.