Программирование мобильных устройств на платформе .NET Compact Framework
Шрифт:
Выполняйте тестирование с использованием реальных объемов данных
Одна из распространенных ошибок, допускаемых разработчиками, состоит в том, что при проектировании и тестировании алгоритмов используются меньшие объемы данных по сравнению с теми, с которыми приходится иметь дело в процессе реальной работы. Реальные данные дольше загружаются и сохраняются и, что немаловажно, могут потреблять большие объемы драгоценной памяти и резко замедлять общую производительность мобильного приложения. Типичными примерами, когда разработчики могут допускать подобную ошибку и осуществлять разработку и тестирование приложений с использованием меньших объемов данных, нежели те, с которыми сталкиваются конечные пользователи, могут служить следующие:
■
■ В процессе эксплуатации приложения будет требоваться синтаксический анализ текстового XML-файла. Размер пробного XML-файла составляет 15 Кбайт, в то время как в реальной работе будет использоваться файл размером 300 Кбайт.
■ Проектируется приложение, предназначенное для работы с цифровыми фотографиями. Фотографии загружаются с Web-сервера и сохраняются в локальной кэш-памяти устройства. В процессе разработки приложения используются четыре пробных изображения размером 200 Кбайт каждое, хотя обычный размер фотографий, получаемых при помощи цифрового фотоаппарата, составляет 800 Кбайт (или более).
Легко понять причины, по которым могут совершаться ошибки, проиллюстрированные в приведенных выше примерах. В процессе проектирования приложения форматы данных часто могут меняться, и вам гораздо легче создать файл нужного формата, включив в него 10 записей, а не 200. Кроме того, выполнять и тестировать приложения намного проще, если при их запуске не приходится ожидать загрузки всех данных. К сожалению, конечные пользователи будут лишены этой роскоши, ведь им приходится иметь дело с реальными объемами данных. Поэтому очень важно уже на ранних стадиях процесса проектирования и разработки мобильного приложения перейти к использованию реальных данных или имитирующих их данных сравнимого объема.
Соблазн как можно дольше работать с небольшими объемами тестовых данных настолько велик, что о необходимости тестирования приложения с использованием реальных объемов данных обычно вспоминают слишком поздно, когда процесс разработки уже продвинулся довольно далеко. Часто реальные данные используют только тогда, когда почти завершенное приложение проходит эксплуатационные тесты. К этому моменту между модулями кода уже будут сформированы всевозможные зависимости, а в проекте приложения использованы неявные предположения относительно требуемых объемов памяти. В этих условиях распутывание сложившихся зависимостей и изменение положенных в основу приложения моделей данных и памяти с целью перехода к работе с реальными объемами данных будет весьма болезненным, если вообще осуществимым. Чтобы не забыть о необходимости перехода к тестированию мобильного приложения с использованием реальных данных, включите это условие в число обязательных критериев завершения контрольной точки, перед достижением которой пишется код, обрабатывающий эти данные. В частности, этот критерий должен предусматривать, что объемы данных, используемых в процессе ежедневной разработки и тестирования приложения, должны быть близкими к реальным. Успешное завершение каждой контрольной точки должно предусматривать достижение приемлемой производительности при работе с реальными данными
Тестируйте приложения в предельных режимах
Популярные и особенно полезные приложения часто используются на пределе их возможностей и с выходом за первоначально предполагаемые границы их областей применения. Людям вообще свойственно использовать любые виды оборудования с нарушением установленных норм их эксплуатации. Проектируя приложение, вы должны исходить из того, что то же самое будет происходить и с ним. Рекомендуется часть тестов проводить в режимах, близких к предельным, чтобы увидеть, как ведет себя приложение по мере роста объемов данных до следующих размеров.
■ Размеры файлов/данных на 20% превышают показатели, предусмотренные проектом. Этот уровень соответствует простейшему случаю превышения норм потребления памяти, установленных для вашего приложения.
■ Размеры файлов/данных на 50% превышают показатели, предусмотренные проектом. Этот уровень соответствует наиболее вероятному превышению норм потребления памяти, установленных для вашего приложения. Способно ли приложение корректно разрешить эту ситуацию за счет снижения эффективности выполнения или упомянутая ситуация повлечет за собой неприятные последствия?
■ Размеры файлов/данных на 100% превышают показатели, предусмотренные проектом. Значительное превышение норм потребления памяти.
■ Размеры файлов/данных на 200% превышают показатели, предусмотренные проектом. Действительно жесткие условия тестирования.
В идеальном случае ваше приложение должно быть в состоянии корректно обрабатывать увеличенные объемы данных. При наличии хорошо продуманной модели памяти, гарантирующей хранение лишь необходимого объема информации о состоянии приложения, пользователь может даже не почувствовать, что оно стало работать xyже. В более реалистичных случаях при работе с увеличенными объемами данных производительность приложения может несколько снижаться, в связи с чем возникает вопрос о том, каковы допустимые пределы превышения данными предусмотренных объемов. Важно понять, в каком диапазоне увеличения объемов используемых данных производительность приложения будет снижаться линейным образом и начиная с какой точки это снижение приобретет экспоненциальный характер.
Если ваше приложение начинает "спотыкаться" в любой из перечисленных выше точек перегрузки, вам необходимо предпринять определенные меры, обеспечивающие работоспособность приложения даже при возникновении подобных условий. Например, вы можете включить в код приложения фрагменты, которые осуществляют необходимый контроль и запрещают приложению работать с объемами данных, при водящими к снижению производительности ниже допустимого уровня. Возможен и такой вариант, когда ваше приложение предупреждает пользователя о загрузке чрезмерно большого количества данных, грозящего значительным ухудшением производительности, и предоставляет ему возможность самому оценить последствия продолжения работы с увеличенным объемом данных.
В вашем основном документе проекта должны быть указаны как рекомендуемый максимальный объем используемых данных, так и возможные последствия попыток пользователя работать с превышением пороговых размеров памяти, отведенной для хранения данных.
Своевременно предпринимайте меры по поддержанию высокой производительности приложения (со временем ситуация будет только ухудшаться!)
Я уже говорил об этом раньше и, несомненно, еще неоднократно буду повторять: не откладывайте в долгий ящик работу по поддержанию производительности на высоком уровне! Отложить эту работу — это все равно, что отложить на более поздние сроки устранение трудных ошибок в программе; такая тактика почти никогда не оправдывается. Очень легко убедить себя заняться этой работой позже. Позвольте привести несколько примеров распространенных оправданий, к которым охотно прибегает и автор этих строк:
■ Главное для меня сейчас — это вовремя завершить написание кода. Покончив с этим, я буду иметь более полное представление о том, как работает приложение, и смогу его лучше настроить. Неверно. После того, как вы своевременно закончите написание кода, у вас начнется очень трудный период, на протяжении которого вы будете переделывать отдельные части приложения, поскольку они зависят от всех явных или неявных допущений, принятых вами при разработке алгоритмов. Чем больший объем кода вы напишете, тем сложнее будет вносить в него изменения. Если вы обнаруживаете, что проблемы производительности отрицательно сказываются на пользовательском восприятии приложения, то заниматься их устранением лучше всего тогда, когда код еще остается достаточно податливым.