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

Выполняйте тестирование с использованием реальных объемов данных

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

■ Приложение, использующее базу данных, тестируется с использованием 20 записей выбранных данных, тогда как в реальной работе будут использоваться от 200 до 2000 записей.

■ В процессе эксплуатации приложения будет требоваться синтаксический анализ текстового XML-файла. Размер пробного XML-файла составляет 15 Кбайт, в то время как в реальной работе будет использоваться файл размером 300 Кбайт.

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

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

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

Тестируйте приложения в предельных режимах

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

■ Размеры файлов/данных на 20% превышают показатели, предусмотренные проектом. Этот уровень соответствует простейшему случаю превышения норм потребления памяти, установленных для вашего приложения. С проблемами такого рода приложение должно быть в состоянии справляться без особого труда. 

■ Размеры файлов/данных на 50% превышают показатели, предусмотренные проектом. Этот уровень соответствует наиболее вероятному превышению норм потребления памяти, установленных для вашего приложения. Способно ли приложение корректно разрешить эту ситуацию за счет снижения эффективности выполнения или упомянутая ситуация повлечет за собой неприятные последствия? 

■ Размеры файлов/данных на 100% превышают показатели, предусмотренные проектом. Значительное превышение норм потребления памяти.

■ Размеры файлов/данных на 200% превышают показатели, предусмотренные проектом. Действительно жесткие условия тестирования.

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

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

В вашем основном документе проекта должны быть указаны как рекомендуемый максимальный объем используемых данных, так и возможные последствия попыток пользователя работать с превышением пороговых размеров памяти, отведенной для хранения данных.

Своевременно предпринимайте меры по поддержанию высокой производительности приложения (со временем ситуация будет только ухудшаться!)

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

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

■ Об эффективности кода пока беспокоиться нечего; сейчас я просто воспользуюсь теми приемами программирования, с которыми больше всего знаком, и на скорую руку сделаю основную работу. Позже я выясню, какие алгоритмы тормозят работу приложения, и подумаю над тем, каким образом их следует переписать. И вновь неверно. Если вы напишете заведомо неэффективный код, то прежде, чем вы приметесь за написание своих более эффективных алгоритмов, вам придется его исправлять. Это особенно касается кода, в котором выполняется множество операций со строками, и алгоритмам, которые предполагают распределение памяти для объектов в циклах. Часто не составляет никакого труда уже с самого начала использовать эффективные методики обработки строк или размещения объектов в памяти (далее об этом будет сказано более подробно); для этого надо всего лишь провести небольшое предварительное исследование с целью выяснения того, какие из существующих методик являются наиболее эффективными в используемой вами системе программирования. Можно дать два важных совета, следуя которым вы сможете создавать эффективно выполняющийся код: 1) выберите подходящий алгоритм, который в наибольшей степени соответствует вашим запросам, и 2) программируйте алгоритм с использованием доступных вам эффективных методик. Написание бесполезного кода низкого качества с мыслью о том, что впоследствии он будет исправлен, — это все равно, что пытаться покрасить дом, расплескивая краску по всей стене: вы можете быстро закрасить 80 процентов поверхности стен, но для полного завершения работы вам придется вновь заняться покраской всех стен.