Псевдослучайные сбои во Flash Debugger - Мой плохой или Обитель?

Question

Я работаю над проектом AS3/Flex с большими размерами (некоторые части являются чистыми AS3, другие части Flex), и я испытываю много сбоев Flash Debugger.

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

я два вопроса (тщательно сформулированы, чтобы удалить свою личную предвзятость :))

1. эти сбои из-за моей практики программирования или проигрывателя Adobe Flash Debugger?

   1a. Если эти сбои связаны с моим кодированием, как мне решить проблемы с фиксацией, которые не повторяются последовательно? : P

2. Когда я развертываю свое приложение на веб-сайте и получаю доступ к нему через Flash Player, должен ли я ожидать, что произойдут те же самые сбои, или Flash Player значительно более устойчив, чем Flash Debugger?

Большое спасибо, все! :)

-Rich

---

UPDATE:

Спасибо за ответы, все! Некоторая более справочная информация:

1. Я использую довольно исправный DeMonster Debugger (http://demonsterdebugger.com/), а также доморощенный класс Profiler для мониторинга напряжения процессора/памяти моего приложения. Я уверенно уверен, что сбои не связаны с нагрузкой на память/процессор, потому что я могу (несколько последовательно) заставить приложение терпеть крах с очень небольшим напряжением в течение 30 секунд после выполнения.

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

3. Теперь некоторые подробности о фактическом коде нарушившего:

отменить механизм для приложения (XMLManager.as) работает путем сохранения изменений в модель (представленной в XML). Чтобы отменить изменение, приложение перезагружает (повторно создает) ключевые компоненты на основе XML, хранящегося в XMLManager.as. Чтобы получить приложение (несколько последовательно), я могу выполнить набор действий, которые все связаны с определенным классом в приложении, классом Line.as. Выполнение действий не вызывает проблем, но Undo() приводит к сбою приложения.

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

xml + = 'text = "' + text + '"'; // не приводит к сбою

xml + = 'text = "' + tf.text + '"'; // приводит к сбою

«текст» - это строка, которая должна отражать содержимое tf.text (tf является текстовым полем). Эта строка находится в методе Line.toXml(), который используется для преобразования строки в соответствующий XML для хранения в XMLManager. Итак, запутанная вещь обо всем этом состоит в том, что использование tf.text в конечном итоге приводит к сбою в механизме отмены, хотя XML, хранящийся в механизме XML, существенно не изменился ...

Чтобы сделать вещи еще более запутанный, я могу вывести полный XML перед началом процесса отмены. Таким образом, когда происходит сбой Flash, у меня есть запись XML, которая вызвала его сбой. Если я возьму тот же самый XML (который при ручном осмотре выглядит нормальным) и вернет его в приложение в качестве его начального состояния, ошибок не произойдет, и Flash не сработает.

Так много путаницы! :)

Извините за подробное объяснение; возможно, вы можете понять, почему я здесь в недоумении!

(Обратите внимание, что я нашел обходное решение - вместо того, чтобы использовать «tf.text» непосредственно в коде toXml(), я могу сохранить «текст» в актуальном состоянии с содержимым «tf.text» во всех случаях. Этот подход, который теоретически приводит к тому же используемому XML, отлично работает без сбоев ...)

Любые мысли?

Answer 1

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

Чтобы очистить ваши проблемы я бы рекомендовал:

1) Профиль приложения. Увидите, что у вас есть утечки памяти или что-то в этом роде. (http://livedocs.adobe.com/flex/3/html/help.html?content=profiler_3.html)

2) Очистка всех слушателей событий, когда вы закончите с ними, используя removeEventListeners

3) объекты Повторное использование, где это возможно

4) Монитор частоту кадров, чтобы увидеть, где вещи замедляются: http://www.gskinner.com/blog/archives/2008/04/simple_componen.html

Без фактического просмотра кода, который работает, хотя трудно дать ничего, кроме неопределенных предложений. Является ли код, который работает при сбоях, особенно тяжелой графикой? Является ли это серьезным хрустом?

Answer 2

1. проигрывателя Adobe Flash Debugger, отладчик не должен врезаться, но это также признак того, что ваш код может быть не очень стабильной.
2. Я лично считаю, что FlashPlayer имеет более высокий уровень допуска, я нахожу его отличным, что есть так много не запрограммированных Flash-приложений, , которые содержат утечки памяти, и FP все еще работает, несмотря на всю жестокость.

Answer 3

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

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