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

Question

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

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

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

1. Это сбои из-за моих методов кодирования или Adobe Flash 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. Выполнение действий не вызывает проблем, но отмена () их вызывает сбой приложения.

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

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

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

'text' - это строка, которая должна отражать содержимое tf.text (tf - это TextField). Эта строка находится в 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 Flash Debugger, отладчик не должен аварийно завершать работу, но он также признак того, что ваш код может быть не очень стабильным.
2. Лично я считаю, что FlashPlayer имеет более высокую толерантность, я нахожу это здорово, что есть так много не запрограммированных Flash приложений, которые содержат утечки памяти и FP все еще работает, несмотря на всю жестокость.

Answer 3

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

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