Синее смещение: оптимизация запуска на платформе iOS

В докладе пойдет речь о практических подходах к оптимизации времени запуска приложения на примере Яндекс.Браузера для iOS. Рассматриваются такие вопросы, как выбор проектных и продуктовых метрик для проверки эффективности оптимизации, технические и архитектурные подходы к уменьшению времени старта, а также идеи, как можно заставить ваше приложение казаться быстрее, чем оно есть на самом деле.

Transcript

2. Оптимизация запуска на платформе iOS Синее смещение
3. Пользовательские сценарии требуют моментального старта приложения. Добавление новых функций увеличивает время старта. Работа в условиях высокококонкурентного рынка. Необходимо уменьшать время старта приложения при Постановка проблемы 3
4. Наивный подход к оптимизации Синее смещение: оптимизация запуска на платформе iOS
5. — Чёта тормозит — Давай глянем Реальный диалог разработчиков с менеджером проекта
6. 1. Разработчик вносит изменения; 2. снимается два видео старта — до и после изменений; 3. покадровое сравнение показывает наличие улучшений. Наивный подход с видео 6
7. 1. оптимизации локальны и конфликтуют друг с другом, 2. деградируют со временем, 3. никто не гарантирует наличие эффекта для пользователя. Проблема наивного подхода: 7
8. 1. Выбор метрик для оценки качества 2. Анализ чужого опыта 3. Fake UI: интерфейс, доступный сразу же 4. Устранение «горячих точек» 5. Распрямление ленивых сервисов 6. Оценка полученных оптимизаций Содержание 8
9. Метрики Синее смещение: оптимизация запуска на платформе iOS
10. Метрика — это важно
11. Критерии: 1. В мире пользователя 2. Количественные 3. Объективные Используются для оценки общего эффекта оптимизаций. Основные метрики 11
12. Критерии: 1. В мире разработчика 2. Количественные 3. Объективные Используется для локализации проблем разработчиком. Вспомогательные метрики 12
13. Выбор метрик для Яндекс.Браузера 13
14. Main Эффект от добавления внешних библиотек — в мире разработчика ViewWillAppear Затраты на конфигурацию приложения — в мире разработчика ViewDidAppear Момент показа интерфейса — в мире пользователя UI Ready (ViewDidAppear + dispatch_async) Выбор метрик для Яндекс.Браузера 14
15. Основная метрика уменьшается — пользователь видит улучшение. Пользователь видит улучшение — растут продуктовые метрики. Рабочая гипотеза 15
16. Выделенная машина, которая по таймеру запускает самую свежую девелоперскую версию Яндекс.Браузера и замеряет время старта множество раз. Такой подход 1. исключает вероятностные факторы (погоду на Марсе), 2. контролирует деградацию выполненных опимизаций, 3. контролирует улучшение от вносимых правок. Сбор метрик у разработчика 16
17. Метрики пользователя должны коррелировать с метриками разработчика. Сбор метрик у пользователя 17
18. Метрика — это важно
19. Чужой опыт Синее смещение: оптимизация запуска на платформе iOS
20. 1. Статическая линковка библиотек 2. Динамическое связывание и отложенная загрузка 3. Использование xcassets 4. Отказ от Swift (более не актуален) Николай Лихогруд — Оптимизация времени запуска iOS-приложений https://www.youtube.com/watch?v=REaGfwq3Q5Y Чужой опыт 20
21. Оптимизации Синее смещение: оптимизация запуска на платформе iOS
22. Яндекс.Браузер основан на ядре Chromium. Старт ядра занимает продолжительное время. До старта ядра часть функциональности недоступна. Ядро 22
23. — Может его выпилить? Уволенный впоследствии разработчик* * на самом деле нет
24. Минимальное время старта Интерактивность Поддержка базовых сценариев Прозрачное переключение Fake UI 24
25. Fake UI: реализация Источник всей мощи Ядра: https://brughela.deviantart.com/art/Complex-mechanism-265556164 25
26. Fake UI: реализация 26
27. Fake UI: реализация 27
28. Fake UI: реализация 28
29. — И тут они как ломанулись! Сервисы
30. Множество сервисов требуют для работы Ядра. Их запуск отложен до момента старта Ядра. Сразу после старта они запускаются одновременно. Конкурентность 30
31. // File1.swift Chromium.performAfterStartup { /* Initiate first Chromium-depended heavy service */ } // File2.swift Chromium.performAfterStartup { /* Initiate another Chromium-depended heavy service */ } // And so one and so forth Конкурентность: история проблемы 31
32. class Chromium { func performAfterStartup(_ block: @escaping () -> Void) { pendingBlocks.append(block) } private var pendingBlocks: [ () -> Void ] = [] private func startupFinished() { pendingBlocks.forEach { $0() } } } Конкурентность: история проблемы 32
33. Откладываем запуск наименее важных пользователю сервисов. Отказываемся от единомоментного запуска сервисов. Кооперация 33
34. class Chromium { func performAfterStartup(_ block: @escaping () -> Void) { pendingBlocks.enqueue(block) } private var pendingBlocks = Queue<() -> Void>() private func startupFinished() { func runNextPendingBlock() { if let block = pendingBlocks.dequeue() { block() DispatchQueue.main.async(execute: runNextPendingBlock) } } runNextPendingBlock() } } Кооперация 34
35. — А вот и я! Ленивый сервис
36. Стартуют по первому обращению, т.е. время старта может быть недетерминированным. Могут быть достаточно тяжелыми. class LazyService { static var instance = LazyService() init() { // I ABSOLUTELY HAVE TO READ THIS 60-MB ZIP PACKAGE AND // UNZIP IT ON MAIN QUEUE THATS WHY I'M LAZY } } Ленивые сервисы 36
37. class LazyService { static var instance: LazyService! = nil static func prepare() { instance = LazyService() } init() { // I STILL ABSOLUTELY HAVE TO READ THIS 60-MB ZIP PACKAGE AND // UNZIP IT ON MAIN QUEUE but now I have a place to do it } } Отказ от ленивости 37
38. class LazyService { static var instance: LazyService! = nil static func prepare() { unzip60mb { data in instance = LazyService(data: data) } } static func unzip60mb(then callback: (NSData) -> Void) { // Some background work with callback on main queue } init(data: NSData) { // Just retaining data, nothing more } } Создание графа объектов 38
39. Результаты Синее смещение: оптимизация запуска на платформе iOS
40. Уменьшение времени старта приложения 40
41. Упрощение поиска внесенных проблем 41
42. Упрощение поиска внесенных проблем 42
43. Если планируется внести изменения, которые потенциально могут повлиять на время старта, то: 1. разработчик вносит изменения, делает pull request, 2. с ветки делается сборка, проверяются метрики, 3. pull request вливается в мастер. Если разработчик случайно делает такие изменения — узнаем постфактум. Внесение изменений 43
44. Заключение Синее смещение: оптимизация запуска на платформе iOS
45. Метрики → оптимизации Заключение 45
46. Брыксин Виктор iOS разработчик iPhone X (на самом деле нет) doberman@yandex-team.ru Спасибо за внимание!