Как сократить время запуска приложений под iOS. Cоздание мобильных приложений в Алматы
Мобильные процессоры и память все быстрее, а приложения загружаются все так же. В чем соль? Так как мы занимаемся созданием мобильных приложений в Алматы, вопрос времени запуска iOS-приложений часто возникает у наших разработчиков (особенно после перехода на Swift). Мы решили выяснить причины долгой загрузки и варианты решения этой проблемы.
Под временем запуска мы понимаем интервал между нажатием на иконку приложения и моментом, когда у пользователя появляется возможность выполнять действия, ради которых он и запускает приложение. Самое важное — это субъективное восприятие времени пользователем, поэтому можно идти на различные ухищрения, не связанные напрямую с оптимизацией кода. Но и объективные показатели, то есть измеренное время основных этапов запуска, непосредственно влияют на субъективные. Кроме того, они позволяют измерить влияние того или иного изменения на результат.
Все время запуска приложения можно разделить на два больших этапа: первый — от нажатия на иконку до первого вызова пользовательского кода (обычно это методы +load), второй – непосредственно выполнение кода приложения, включая действия, выполняемые системными фреймворками (запуск run loop, загрузка экрана запуска и основного UI) и ваш собственный код.
Частая ошибка разработчиков?
Одна из самых главных проблем — использование подов, написанных на Swift, т.к. в этом случае все таргеты CocoaPods собираются в отдельные динамические библиотеки. Даже если в проекте мало кода в основном таргете, поды на Swift могут увеличить время запуска в несколько раз.
Как разработчики мобильных приложений в Алматы, мы не раз с этим сталкивались и потому рекомендуем воспользоваться нашим советом.
Что нужно сделать сначала?
Первый шаг — включить переменную окружения DYLD_PRINT_STATISTICS и посмотреть, сколько времени уходит на pre-main и after-main — т.е. на части запуска, за которые ответственны система и непосредственно ваше приложение. Это позволит выявить, где именно проблемы — в вашем коде или в работе системного загрузчика, который собирает образ приложения в памяти. Дальнейшие действия зависят от результатов замеров. Есть способы уменьшить время системной части загрузки, а свой код оптимизируется как обычно — тут отлично помогает профилировщик.
Что необходимо использовать?
Основной инструмент — переменная DYLD_PRINT_STATISTICS, которая выводит статистику работы системного загрузчика. Также есть возможность выводить загружаемые динамические библиотеки через переменную DYLD_PRINT_LIBRARIES. Для более продвинутых пользователей существуют консольные утилиты, позволяющие смотреть зависимости отдельных библиотек, таблицы символов, сколько rebase и bind будет проведено при загрузке. Но на эти параметры сложно повлиять вручную, особенно для сторонних библиотек.
Проблема в том, что Swift еще достаточно молод и продолжает активно развиваться, независимо от iOS. Поэтому в каждое приложение на Swift встраиваются используемые Swift Standard Libraries, и поэтому для Swift нет статической линковки. Но в какой-то момент Swift стабилизируется, станет частью операционной системы, для него сделают нормальную линковку. И тогда вся эта проблема с медленным запуском проектов на Swift полностью исчезнет, на первый план выйдет оптимизация after-main, как в Objective-C. Это дело не завтрашнего дня, но ближайшего будущего.
Компания A-Lux уже 10 лет занимается созданием мобильных приложений в Алматы, потому такие проблемы уже не стоят перед нами и мы всегда будем рады Вам помочь с любым проектом!