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

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

Жанр:

Программирование

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

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

Назад к карточке книги

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примеры, иллюстрирующие различные варианты организации обратной связи с пользователем

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

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

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

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

Предполагается, что представленный в листинге 7.3 текст вы поместите в класс Form в проекте для Pocket PC. Для создания и выполнения примера необходимо выполнить следующие действия:

1. В Visual Studio .NET (2003 или более поздней версии) начните новый проект для Pocket PC с использованием языка C#.

2. Разместите в окне конструктора формы для Pocket PC текстовую метку и три кнопки (как показано на рис. 7.1).

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

4. Дважды щелкните на кнопке Button1 формы; в результате этого будет создан и присоединен к форме обработчик событий button1_Click, представленный ниже. Включите в эту процедуру приведенный ниже код.

5. Проделайте то же самое для кнопок Button2 и Button3 и включите их коды в соответствующие процедуры.

6. Нажмите клавишу для запуска приложения на эмуляторе или физическом устройстве Pocket PC. (Если вы хотите запустить приложение без отладчика, нажмите комбинацию клавиш .)