ГЛАВА 12
Производительность: подведение итогов
Итоговые замечания по поводу производительности
Примите поздравления! Наконец-то вы добрались до конца части книги, которая посвящена вопросам производительности. Если вы внимательно читали весь предыдущий материал, то у вас сейчас должны быть все основания, чтобы чувствовать себя уверенно в отношении большинства аспектов программирования мобильных приложений, знание которых обеспечивает создание высокопроизводительного кода. Вы будете в состоянии самостоятельно исследовать возможные пути использования тех необычайных возможностей, которые предлагают мобильные устройства.
Поскольку тема производительности — многоплановая, она рассматривалась в предыдущих главах с самых различных сторон и с углублением в детали тех отдельных областей и уровней проектирования, которые оказывают на производительность мобильных приложений наиболее заметное влияние. Начало этому обсуждению было положено общим обзором аспектов производительности с точки зрения философии и практических методов проектирования.
Далее мы перешли к рассмотрению того, насколько выбор проектного решения может влиять на удачность или неудачность реализации обычных видов функциональности мобильных приложений, и познакомились с конкретными стратегиями, обеспечивающими достижение высокой производительности в этих областях. Теперь настало время подытожить все ранее сказанное о производительности, сведя все нити рассуждений в один пучок завершающих мыслей и практических рекомендаций, следование которым позволит вам действовать наилучшим образом.
Производительность и управление памятью
Ваши успехи в разработке мобильных приложений будут в огромной степени зависеть от того, каким образом вы организуете управление памятью как на микроскопическом, так и на макроскопическом уровнях. При проектировании модели использования памяти мобильного приложения и написании алгоритмов очень важно отдавать себе отчет в том, к каким действиям будет вынужден прибегать сборщик мусора в соответствии с теми или иными проектными решениями, которые вы примете. Хотя работу сборщика мусора вы непосредственно контролировать не можете, она заметно влияет на общую производительность приложений на основе управляемого кода.
С аналогичными трудностями сталкиваются и разработчики приложений на основе собственных кодов, однако они должны управлять памятью самостоятельно. Полная сборка мусора обходится недешево; чтобы восстановить память, занимаемую ненужными объектами, среда времени выполнения должна просмотреть все объекты высшего уровня, спускаясь вниз по деревьям подобъектов для отыскания всех объектов, которые по-прежнему используются приложением. Выполнение каждой операции по очистке памяти от "мусора" требует некоторых минимальных накладных расходов, объем которых зависит от количества объектов, которые необходимо просмотреть; многократное выполнение этой операции во многих случаях приводит к ощутимому замедлению работы приложений.
Частота выполнения сборки мусора напрямую зависит от того, насколько быстро ваш код расходует память приложения. Дефицит памяти в приложениях может быть обусловлен двумя факторами: 1) суммарным объемом поддерживаемого состояния приложения, включая всевозможные формы, глобальные объекты, пользовательские данные и любые другие объекты, содержащиеся внутри глобальных родительских объектов, и 2) временными объектами, которые создаются и разрушаются в процессе выполнения ваших алгоритмов. Если посмотреть на график изменения объема памяти, расходуемой приложением в процессе своего выполнения, то он будет иметь пилообразную форму. Высота зубьев этой пилы определяется тем, какой объем памяти вы оставляете для использования вашими алгоритмами, где имеется в виду память, не входящая в состав постоянно распределенной памяти приложения. Наклон же зубьев зависит от того, насколько эффективны процедуры распределения памяти для объектов, используемые в ваших алгоритмах. Чем более экономичны алгоритмы в отношении размещения новых объектов, тем более пологий наклон имеют зубья. В конечном счете, объем занимаемой приложением памяти начинает превышать некоторое пороговое значение, что приводит к запуску механизма сборки мусора, осуществляющего освобождение памяти от неиспользуемых объектов.
Читать дальше