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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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