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

Автор книги: Иво Салмре

сообщить о нарушении

Текущая страница: 18 (всего у книги 69 страниц)

ГЛАВА 7
Шаг 1: начинайте с анализа проблем производительности и никогда не упускайте их из виду

per• form• ance [pr fáwrmns] производительность: эффективность выполнения кем-то или чем-то определенной работы

(Encarta 2004, Dictionary)

Наилучший способ удерживать курс – это не сбиваться с него. Если вы оступились – остановитесь, сделайте шаг назад и продолжите движение в нужном направлении.

Автор данной главы

Введение

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

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

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

Важность планомерного подхода

Томас Эдисон, который сам был человеком не слабым в изобретательстве, как-то сказал: "Гений – это один процент вдохновения и девяносто девять процентов пота". Достижение высокой производительности – это 80 процентов кропотливой работы и 20 процентов творчества. Соблюдение определенной дисциплины в процессе разработки приложения позволит своевременно обнаруживать появление проблем, обусловленных низкой производительностью, и не даст вам возможности игнорировать их или отложить их решение на более поздний период работы. Всегда существует соблазн не обращать на проблемы производительности никакого внимания; само по себе устранение проблем упомянутого рода не обогащает приложение никакими новыми средствами, так что эта работа считается не особенно интересной. Вместе с тем, если вы хотите преуспеть в разработке мобильного приложения, к которой приступаете, то систематическое решение проблем производительности играет в этом ключевую роль. Стиль работы, основанный на планировании, позволит вам не только выявить проблемы производительности на самых ранних стадиях разработки, но и найти соответствующие решения еще до того, как указанные проблемы успеют прочно вплестись в канву вашего проекта. С большинством этих проблем вы сможете справиться путем подходящей адаптации идей, изложенных в этой главе, а также реализации собственных идей, которые появятся у вас в процессе дальнейшей работы над проектом. Если с аналогичными ситуациями вы ранее не сталкивались, случайный проблеск творческого озарения может подсказать вам новое решение, которое до сих пор никому в голову не приходило, что позволит вам вдохнуть в свой проект новую жизнь. Самое главное – это придерживаться определенной самодисциплины, заставляющей вас не закрывать глаза на проблемы производительности, которые неизбежно возникнут, а заниматься ими до тех пор, пока они не будут разрешены. Когда Томас Эдисон испытывал нити накала для изобретенной им лампочки, ему пришлось перепробовать сотни различных материалов, прежде чем он смог остановиться на том, который обеспечивал наилучшее сочетание светимости и срока службы нити. Точно так же обстоит дело и с производительностью: получение нужного результата требует постоянного тестирования приложения и оценки качества его функционирования. Как показывает пример Эдисона, целеустремленность, настойчивость и творческий дух окупают себя сторицей.

Определите обязательные характеристики сценариев рабочих сеансов пользователя

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

■ При любых обстоятельствах пользователь не должен оставаться без визуального подтверждения того, что работа выполняется, на протяжении промежутков времени длительностью более 0,5 секунды.

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

Другие сценарии могут быть более конкретными:

■ На запуск нового сеанса шахматной игры должно уходить не более 1 секунды.

■ Для доступа к информации о заказах клиентов должно требоваться не более 3 секунд.

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

Определите контрольные точки разработки, критерии завершения которых ориентированы на достижение высокой производительности

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

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

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

Несколько слов о прохождении контрольных точек

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

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

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

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

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

Строгое соблюдение критериев завершения контрольных точек в той части, которая касается поддержания высокой производительности приложения, играет чрезвычайно важную роль по той простой причине, что добиться существенного улучшения производительности впоследствии без кардинального пересмотра проекта обычно оказывается невозможным. Типичные оправдания, подобные такому: "Главное сейчас – это завершить разработку готового варианта работоспособного кода к намеченному сроку, а проблемами производительности можно будет заняться и позже, при прохождении последующих контрольных точек", не выдерживают никакой критики. Справляться с проблемами производительности на более поздних стадиях производственного цикла всегда сложнее, поскольку с увеличением объема написанного кода зависимости между его отдельными частями только усиливаются, и это делает внесение необходимых изменений в проект все более затруднительным. Если кто-то говорит: "Проблемами производительности и их устранением мы займемся позже", то истинный смысл этого таков: "Мы не понимаем сути проблем производительности, с которыми столкнулись, и пока не можем сказать, каким образом собираемся устранять их в будущем. To, что мы создаем сейчас, – это прототип, который, как бы то ни было, может быть подготовлен к поставке; чтобы создать действительно завершенную версию приложения, нам, вероятно, придется переписать значительную часть кода".

Устанавливайте для контрольных точек конкретные и реалистические критерии их завершения, включающие в себя аспекты производительности. Гораздо лучше отсрочить завершение контрольной точки, чем перетянуть через финишную линию "хромающее" приложение. Устранение проблем производительности уже в той контрольной точке, при достижении которой был написан недостаточно производительный код, позволит вам использовать для их устранения всю вашу изобретательность и в то же время оставит открытыми просторы для будущего творчества. В части, касающейся аспектов производительности, критериями завершения контрольных точек должны охватываться две области: возможности интерактивного взаимодействия конечных пользователей с приложением и абсолютная производительность критических алгоритмов.

Интерактивное взаимодействие конечных пользователей с приложением

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

■ Можно ли исключить или сократить периоды задержек путем технической доработки проекта?

■ Можно ли обрабатывать задержки, вызывая заставки или отображая курсоры ожидания, уведомляющие пользователя о том, что выполнение приложения продолжается?

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

Абсолютная производительность критических алгоритмов

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

К числу вопросов, на которые необходимо дать ответ, пересматривая критические алгоритмы, относятся следующие:

■ Можно ли ускорить выполнение этих алгоритмов путем их настройки или изменения?

■ Можно ли прогнозировать потребность алгоритмов в тех или данных и заблаговременно загружать нужные данные, прежде чем в них возникнет необходимость, чтобы пользователь мог быстрее получить результат?

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

■ Можно ли произвести некоторые вычисления или подготовить некоторые изображения еще на стадии проектирования, чтобы исключить или уменьшить потребность в проведении соответствующих вычислений на стадии выполнения?

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

Время от времени критически пересматривайте написанный код

Замечательным способом улучшения качества создаваемого вами кода является его периодический критический анализ, направленный на обеспечение высокой производительности приложения. Хотя проектирование по соглашениям – не самая приятная стратегия построения алгоритмов, взаимный анализ кода, написанного разными участниками рабочей группы, является проверенным способом улучшения его качества. Критический анализ кода предоставляет преимущества двоякого рода

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

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

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

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