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

НА ЗАМЕТКУ

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

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

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

■ Дальнейшее повышение производительности просто невозможно. Я выжал из приложения все, что можно, и если его производительность низка, то с этим надо просто смириться. Глубочайшее заблуждение. Резервы повышения производительности существуют всегда, но для того, чтобы использовать их, может потребоваться радикальное переосмысление проекта. Возможно, для этого надо будет изменить организацию работы приложения. Возможно, потребуется перенести код с устройства на сервер (или использовать другие обходные пути). Возможно, потребуется предварительное вычисление некоторых данных на стадии проектирования, составить оптимизированные таблицы поиска и поместить их в код. Возможно, потребуется разделить ваше приложение на три меньших. Имеется бесчисленное множество способов "обмануть время" и найти пути повышения производительности приложения. Хотя тот факт, что для выполнения любой отдельной задачи часто существуют алгоритмы, обеспечивающие максимально возможное быстродействие, является сущей правдой, ваше приложение почти никогда не будет сводиться только к какому-то одному алгоритму или задаче. Ваше приложение таково, каким его воспринимает пользователь. Если вам никак не удается добиться приемлемой производительности, и вы убеждены в том, что используемым для ее оценки количественным показателям можно доверять, значит наступил момент, когда вы должны активизировать свое творческое воображение. Вспомните старую истину: "Необходимость — мать изобретательности". Величайшие открытия совершаются именно тогда, когда возникают, казалось бы, непреодолимые трудности, поскольку они заставляют вас задуматься об истинной природе проблемы, которую вы пытаетесь решить. Если производительность приложения остается низкой, то причиной этого, как правило, является недостаток творческого воображения, мешающий взглянуть на проблему с новой стороны. Станьте на голову и постойте в таком положении некоторое время или сделайте еще что-нибудь, что способно активизировать ваше творческое мышление. Решение обязательно появится.

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

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

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

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

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

Ha всем, что связано с оценкой производительности, лежит печать субъективности

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

Немедленная ответная реакция приложения

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

Ответная реакция устройства и пульты дистанционного управления домашней электронной техникой

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

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

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