Медленный запуск на iPhone

Question

Я отлаживаю медленный запуск приложения iPhone (Xcode, Objective C ++). Это приложение на основе вкладок с тремя вкладками. Все три вкладки загружаются в один NIB - всего около 20 объектов.

Первый раунд существенной инициализации происходит в обработчике viewDidLoad контроллера представления первой вкладки. Однако между main () и временем запуска этого метода проходит около 1 секунды - около 2/3 от общего времени загрузки. Вопрос - что происходит за это время, и как мне это расследовать (если не считать пошаговую разборку)? Насколько я знаю, между этими двумя моментами нет моего кода - задержка происходит полностью в системном коде.

Может быть, какой-нибудь инструмент, который может дать мне профиль времени для каждой функции?

Объем пакета составляет ~ 4 МБ, но позже я загружаю самый большой файл (~ 3,5 МБ) в обработчик applicationDidFinishLaunching. Удаление этого файла из пакета и комментирование соответствующего кода ничего не делает для этой 1-секундной задержки.

ОБНОВЛЕНИЕ: в конце концов, было вмешательство отладки. Если я запускаю его на устройстве, наблюдая за консолью, время запуска у нас значительно сокращается, и доля задержки (системный код в моем коде) также искажается. Но, тем не менее, между main и viewDidLoad есть заметная задержка, и она составляет около 50% от общего времени загрузки.

Кстати, из всех способов полной загрузки большого файла из пакета в память самым быстрым было прямое отображение памяти (с использованием POSIX mmap ()).

Answer 1

Если вам действительно интересно, что выполняется во время запуска, и относительное время, необходимое каждому методу для запуска, вы можете создать собственный сценарий DTrace для отслеживания этого. Я опишу, как это сделать к концу этой статьи . Этот сценарий покажет вам каждый метод, выполняемый вашим приложением в порядке от запуска до конца -applicationDidFinishLaunching:, а также время, потраченное на этот метод. Вы можете запустить этот скрипт как пользовательский инструмент в Инструментах или как отдельный скрипт (автономный скрипт имеет тенденцию быть более точным в загруженной системе).

Основным предостережением этого подхода является то, что он будет работать только в симуляторе, учитывая отсутствие поддержки DTrace в самой iPhone OS. Однако вы должны быть в состоянии извлечь порядок, в котором выполняются вещи при запуске вашего приложения, а также относительное время, которое ваше приложение тратит на каждый метод. Это даже покажет закулисные частные вызовы API, выполняемые при запуске приложения, что может дать некоторые дополнительные подсказки о том, что происходит.

Для получения дополнительных рекомендаций по настройке автозагрузки я рекомендую прочитать статью Джеймса Томсона "Как сделать так, чтобы приложение для iPhone запускалось быстрее" .

Answer 2

Здесь могут происходить две вещи. Если вы отлаживаете свое приложение из XCode, есть большая вероятность, что приложение при запуске ожидает подключения к отладчику GDB. По моему опыту, это занимает около секунды. Попробуйте запустить свое приложение, не произнося «Build and Go» в XCode, и посмотрите, отличаются ли результаты. (Просто щелкните по нему на главном экране)

Ваш файл NIB также может быть проблемой. 20 объектов не так уж много, но вы можете разбить каждую вкладку на отдельный файл NIB, если все остальное не даст результатов. Содержимое файлов NIB, на которые ссылается ваш основной файл NIB, загружается лениво, поэтому приложение не будет загружать представления для двух невидимых вкладок, пока они не выбраны. Это может дать вам прирост производительности при запуске, хотя я не думаю, что это может занять целую секунду.

У Apple есть несколько отличных инструментов для анализа производительности в iPhone SDK, но их немного сложно найти. В меню «Выполнить» выберите «Запустить с помощью Performance Tool» -> «CPU Sampler». Это запустит отдельное приложение под названием Instruments, которое позволит вам проводить всевозможные анализы во время выполнения. Когда вы выбрали инструмент ЦП, нижняя половина окна «Инструменты» отображает то, что занимало время ЦП в вашем приложении. Вы можете дважды щелкнуть по функциям, чтобы погрузиться в них и получить построчную разбивку% используемых циклов. Это должно дать вам больше информации о том, что конкретно вызывает вашу проблему.

Answer 3

Я бы рекомендовал разделить ваше приложение на три NIBS; панель вкладок и контроллер панели вкладок отображаются при запуске в первую очередь, затем лениво загружают две другие, когда пользователь переключается на них.

Я полагаю, что вы можете использовать функцию File >> Decompose Interface в Interface Builder для достижения этой цели.

Answer 4

Если вы обнаружили, что ваши xib-файлы слишком велики, я советую вам создать свой интерфейс с чистым кодом. большие xib-файлы наверняка замедляют время запуска, а также замедляют работу приложения при первом использовании объекта в xib.

Я не использую xib в своих проектах, потому что когда кто-то изменил xib в svn, вы вряд ли найдете то, что изменилось. То есть Xib не очень хорошо работает с SVN.