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

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

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

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

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

Нередко разработчики рассуждают таким, на первый взгляд вполне разумным, но на самом деле глубоко ошибочным образом: "Понять, какие части приложения нуждаются в улучшении, можно лишь только после того, как будет написан весь код". Такая позиция весьма порочна, поскольку в ней содержится предположение о том, что отдельные части вашего приложения каким-то удивительным образом не зависят друг от друга. Вместе с тем, когда вы напишете весь код, в него будет введено множество явных и неявных зависимостей между различными системами, и вы, вероятнее всего, будете в состоянии внести в код лишь некоторые изменения количественного, но не качественного характера. Вам не уйти от этого даже в том случае, если вы приложите максимум усилий к инкапсуляции кода приложения. Чем больше объем кода, тем больше в нем существует зависимостей между отдельными частями; пытайтесь бороться с этим, тщательно продумывая структуру приложения, но знайте, что таковы реалии жизни. Браться за решение проблем производительности следует тогда, когда базовый код еще обладает достаточной гибкостью и остается открытым для реструктуризации. Лучше всего заниматься этим сразу же по ходу написания кода.

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

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

(если производительность низка, выполнение последующих шагов вам ничего не даст)

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

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

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

Как ActiveSync, так и Internet Explorer для Pocket PC и интеллектуальных телефонов предлагают элементы пользовательского интерфейса, назначение которых состоит в том, чтобы информировать пользователей о состоянии выполнения инициированных ими асинхронных запросов. Благодаря этому пользовательский интерфейс сохраняет свою интерактивность, и у пользователя не возникает чувства потери контакта с приложением.