Performance Analytics
Аналитика перфоманса — сложное дело. Обычно здесь много переменных. Нельзя взять 1-2 айфона и на глаз протестировать на пару экранов с секундомером.
1️⃣ нужно реальное устройство
В симуляторах ресурсы шарятся с маком. Не то железо
А ту же скорость интернета даже проксименом нормально не отдебажишь.
2️⃣ правильные данные
Влияет множество сайдэффектов от прод сборки и состояния батареи до качества сети. Не то окружение.
3️⃣ чистота данных
Не все данные полезные и важны. Число и скорость в вакууме часто ни о чем не говорит.
Крупные компании создают сложную систему анализа перфоманса. Каждая метрика от скорости загрузки экрана до вызова ручки — отправляется на бэк. Там дашбордами можно составить график деградаций.
Автор статьи как раз рассказывает как писал такую систему.
Аналитика перфоманса — сложное дело. Обычно здесь много переменных. Нельзя взять 1-2 айфона и на глаз протестировать на пару экранов с секундомером.
1️⃣ нужно реальное устройство
В симуляторах ресурсы шарятся с маком. Не то железо
А ту же скорость интернета даже проксименом нормально не отдебажишь.
2️⃣ правильные данные
Влияет множество сайдэффектов от прод сборки и состояния батареи до качества сети. Не то окружение.
3️⃣ чистота данных
Не все данные полезные и важны. Число и скорость в вакууме часто ни о чем не говорит.
Крупные компании создают сложную систему анализа перфоманса. Каждая метрика от скорости загрузки экрана до вызова ручки — отправляется на бэк. Там дашбордами можно составить график деградаций.
Автор статьи как раз рассказывает как писал такую систему.
Forwarded from iPhone:~ root# (Хозяйн)
Reverse-engineering клиентской детекции VPN / proxy в iOS-приложениях + универсальный bypass-твик на fishhook. Разобрано 16 российских приложений (банкинг, стриминг, доставка, госуслуги, телеком, навигация).
https://github.com/Leeksov/ios-vpndetect-research
https://github.com/Leeksov/ios-vpndetect-research
GitHub
GitHub - Leeksov/ios-vpndetect-research
Contribute to Leeksov/ios-vpndetect-research development by creating an account on GitHub.
Большинство разработчиков пишут на Auto Layout. Но не все знают, что есть альтернатива и не всегда Auto Layout подходит. В редких кейсах это просто необходимо
Frame-Based Development — это ручной layout через frame/layoutSubviews/layoutSublayers, в противоположность Auto Layout.
Вы скажите что так никто не делает и это уже не нужно. А я скажу что немаленькое кол-во компаний пишут лайаут вручную.
Тот же auto layout работает через constraints и систему уравнений. При большом кол-ви view'шек это все перерассчитывается на главном потоке.
На картинках свежие бенчмарки iPhone 16. В процентных сравнениях даже на новых устройствах auto layout сильно медленее.
Нужно ли это в 2026к? Вы недооцениваете глубину вложенных вьюшек в том же бдуи. Я сделал небольшой эксперимент, о котором напишу в следующем посту.
Полезные ссылки:
• Layout Framework Benchmark
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Сразу скажу быстро. Было очень круто. Мощные задачи крутых масштабов. Глубокие погружения в оптимизации. Архитектурные вызов. BDUI погружение...
Спойлер. На днях меня спросили "А почему ты пришел в яндекс с авито? Обычно всё наоборот...". Не знаю как воспринимать слова. Но я пока наоборот не жалею и рад, что дают кучу возможностей.
Я — Моб.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Как влияет вложенность вьюх на перфоманс?
В прошлом посте мы поговорили про Frame Based верстку. Судя по анализу и комментам — это не такой уж и непопулярный способ верстать. Где мы отказываемся от Auto Layout'а в сложных коллекциях.
Почему же это снова становится актуальным в 2к26?
На мой взгляд есть две причины:
• SwiftUI/Compose лайк верстки, которые требуют много хостингов
• Всякие BDUI, которые создают огромную вложенность
Все помнят что такое хитчи и ханги? Если не помните, то это микрофризы и зависания, когда движок отрисовки не успевает обработать кадр.
Если у вас глубокая вложенность с кучей тяжелых данных, блюром, тенями, то даже на мощных устройствах мы можете столкнуться с фризами.
Вчера в нашем чате даже поделились кейсом, когда отказ от UIStackView привел к улучшению производительности на 30%.
Полезные ссылки:
• Optimizing Auto Layout Performance
• Auto Layout vs Frame Sizes
• Mastering Performance Management in Swift: Best Practices for Optimising Your App’s Speed and Efficiency
В прошлом посте мы поговорили про Frame Based верстку. Судя по анализу и комментам — это не такой уж и непопулярный способ верстать. Где мы отказываемся от Auto Layout'а в сложных коллекциях.
Почему же это снова становится актуальным в 2к26?
На мой взгляд есть две причины:
• SwiftUI/Compose лайк верстки, которые требуют много хостингов
• Всякие BDUI, которые создают огромную вложенность
Все помнят что такое хитчи и ханги? Если не помните, то это микрофризы и зависания, когда движок отрисовки не успевает обработать кадр.
Если у вас глубокая вложенность с кучей тяжелых данных, блюром, тенями, то даже на мощных устройствах мы можете столкнуться с фризами.
Вчера в нашем чате даже поделились кейсом, когда отказ от UIStackView привел к улучшению производительности на 30%.
Полезные ссылки:
• Optimizing Auto Layout Performance
• Auto Layout vs Frame Sizes
• Mastering Performance Management in Swift: Best Practices for Optimising Your App’s Speed and Efficiency
Раньше мы все мечтали работать в Apple. А теперь в Anthropic
https://h.careers/job/801bba8a-4c25-4426-8d93-73bc1d0037a7
https://h.careers/job/801bba8a-4c25-4426-8d93-73bc1d0037a7