Иво Салмре - Программирование мобильных устройств на платформе .NET Compact Framework

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

■ Вы должны определить общие показатели, характеризующие способность вашего приложения реагировать на действия пользователя. Например: "На появление диалога не должно уходить более 0,5 секунды", "Визуально определяемая реакция на нажатие клавиши должна следовать немедленно" или "Раскрытие узлов дерева не должно занимать более 0,15 секунды". Здесь были приведены в качестве примера неплохие значения показателей, к достижению которых следует стремиться.

■ Вы должны определить конкретные числовые показатели для ключевых сценариев. Например: "Загрузка данных инвентаризационной ведомости ни при каких обстоятельствах не должна останавливать работу пользовательского интерфейса на более чем 0,2 секунды без появления курсора ожидания" или "Дли тельность загрузки данных инвентаризационной ведомости ни в коем случае не должна превышать 3 секунд".

Тестируйте свои допущения в реальных условиях эксплуатации сценариев. Даже если в вашем распоряжении еще не имеются все необходимые реальные данные или код, легко тестировать эффекты задержек при выполнении пользователем часто встречающихся задач, имитируя их путем вставки состояний ожидания в скелет кода пользовательского интерфейса приложения. Очень важно хорошо себе представлять, какие периоды ожидания приемлемы, а какие — нет. Следует стремиться к тому, чтобы приложение всегда предоставляло немедленное подтверждение того, что та или иная операция находится в состоянии выполнения, если она не может быть завершена очень быстро. Кроме того, если работа должна выполняться в течение длительного или неопределенного времени, ее выполнение может быть поручено фоновому потоку.

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

Блок-схема организации процесса разработки мобильного приложения представлена на рис. 4.1. Если вы столкнулись с проблемами производительности — остановитесь! Можно сформулировать это и по-другому: если в процессе проектирования и разработки приложения вы столкнулись с проблемами производительности — немедленно прекратите дальнейшее написание кода ! Слишком уж часто разработчики с головой погружаются в это занятие, стремясь поскорее получить "завершенный код" и давая себе слово, что к решению возникших проблем производительности они после этого обязательно вернутся. В лучшем случае такая стратегия является рискованной! Она редко приводит к успеху при разработке приложений для настольных компьютеров и серверов и обычно дает довольно-таки плачевные результаты; в случае же мобильных устройств результаты ее применения будут еще худшими. Причина этого заключается в том, что проблемы производительности часто коренятся не в недостатках какого-то отдельного алгоритма, который можно просто доработать или оптимизировать, не влияя на остальные части системы. До тех пор пока вы детально не выясните природу проблемы и не убедитесь в том, что альтернативное решение способно ее устранить, вы не можете сказать фактически ничего определенного о том объеме переработки проекта, который для этого может потребоваться. Вам может повезти, однако везение довольно быстро покидает тех программистов, которые слишком сильно полагаются на это.

Рис. 4.1. Методология, подчиненная требованиям производительности

Во многих случаях проблемы производительности носят систематический характер и касаются всего приложения в целом. Систематическое снижение производительности может быть, в частности, обусловлено способом обмена данными с памятью, количество одновременно удерживаемых в памяти ресурсов, а также способом перерисовки и обновления информации на экране, который используется пользовательским интерфейсом. Проблемы производительности подобного рода обычно появляются из-за неудачного выбора основных проектных решений, и, чтобы избежать их, необходимо позаботиться об этом уже на самых ранних стадиях процесса проектирования и разработки приложения. Потери от чрезмерно быстрого продвижения вперед для получения "завершенного кода" и последующего возврата к пересмотру стратегии доступа к данным, повторному проектированию модели использования памяти и организации выполнения определенной работы в фоновом режиме для улучшения интерактивности пользовательского интерфейса могут быть поистине огромными. Даже если в результате внесения запоздалых проектных изменений вы и получите работающий код, он будет плохо организован. Реальные основы высокой производительности приложения должны закладываться еще в его фундаменте.