Flash调试器中的伪随机崩溃 - 我的坏,还是Abode?

时间:2010-05-21 00:05:50

标签: flex actionscript-3 flash

我正在开发一个大型的双AS3 / Flex项目(有些部分是纯AS3,其他部分是Flex),而且我遇到了很多Flash Debugger崩溃。

这些崩溃并非完全随机 - 当我在我的应用程序中执行某些操作时,似乎可以让它们以更高的一致性发生。但是,与此同时,它们并不是一直可重复的 - 有时一组操作会导致我的应用程序崩溃,而有时,相同的步骤会在没有崩溃的情况下执行得很好。

我有两个问题(谨慎措辞以消除我的个人偏见:))

  1. 这些崩溃是由于我的编码实践还是Adobe的Flash调试器?

    1a上。如果这些崩溃是由于我的编码,我该如何解决不一致可重复的问题? :P

  2. 当我在网站上部署我的应用程序并通过Flash Player访问它时,我是否应该发生相同的崩溃,或者Flash Player比Flash Debugger更具弹性?

  3. 非常感谢,全部! :)


    更新:

    感谢所有回复!更多背景信息:

    1. 我正在使用非常好的DeMonster调试器(http://demonsterdebugger.com/)以及一个自行开发的Profiler类来监控我的应用程序的内存/处理器压力。我有理由相信崩溃与内存/处理器负担无关,因为我可以(有点一致地)让应用程序在执行后的30秒内以极小的压力崩溃。

    2. 由于我的应用程序的体系结构,内存泄漏变得非常容易。因此,我已经/被迫至少消除了大部分内存泄漏。虽然我承认存在可能仍然存在内存泄漏的情况,但是在我可以让应用程序崩溃的时候,内存使用量非常低,因此似乎不太可能存在相关性。

    3. 现在了解实际违规代码的一些细节:

    4. 应用程序的撤消机制(XMLManager.as)通过存储对模型的更改(以XML表示)来工作。要撤消更改,应用程序将根据存储在XMLManager.as中的XML重新加载(重新实例化)关键组件。为了让应用程序(有点一致地)崩溃,我可以执行一组与应用程序中的某个类Line.as类相关的操作。执行操作不会导致任何问题,但撤消它们会导致应用程序崩溃。

      最令人困惑的部分是,XMLManager类存储的XML在崩溃场景和无崩溃场景中实际上是相同的。另一个令人困惑的方面是崩溃场景仅由一行引入:

      xml + ='text =“'+ text +'”'; //不会导致崩溃

      xml + ='text =“'+ tf.text +'”'; //导致崩溃

      'text'是一个字符串,它应该反映tf.text的内容(tf是一个TextField)。此行位于Line.toXml()中,该方法用于将Line转换为其各自的XML以便在XMLManager中存储。所以,关于所有这一切的令人困惑的事情是使用tf.text最终导致撤销机制崩溃,即使存储在XML机制中的XML没有实质性改变......

      为了让事情更加混乱,我可以在开始撤销过程之前输出完整的XML。这样,当Flash崩溃时,我有一个导致它崩溃的XML记录。如果我采用完全相同的XML(在手动检查时显示正常)并将其作为初始状态反馈给应用程序,则不会发生错误,Flash也不会崩溃。

      太混乱了! :)

      很抱歉很长的解释;也许你可以看到为什么我在这里不知所措!

      (请注意,我找到了一种解决方法 - 而不是直接在代码toXml()代码中使用'tf.text',我可以将'text'与'tf.text'的内容保持同步这种方法理论上导致使用相同的XML,在没有崩溃的情况下表现良好......)

      有什么想法吗?

3 个答案:

答案 0 :(得分:2)

  1. Adob​​e的Flash调试器,调试器不应该崩溃,但它是 也表明您的代码可能不太稳定。
  2. 我个人发现FlashPlayer具有更高的容忍度,我发现它 太棒了,有这么多未精心编程的Flash应用程序, 其中包含内存泄漏和FP仍然在运行,尽管这是残酷的。

答案 1 :(得分:2)

我认为闪存调试器实际上可能不像常规播放器那样容易崩溃,因为它的运行速度比普通版本略慢。我已经构建了一些非常大的flash应用程序,并且我没有遇到过你所描述的那种不稳定性,而我的代码没有出错。

为了清理你的问题,我建议:

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

如果没有真正看到正在运行的代码,除了模糊的建议之外,很难提供任何其他内容。当崩溃发生特别是图形沉重时,代码是否正在运行?它正在做一些严重的数字运算吗?

答案 2 :(得分:1)

对于大型项目,其性能是不可取的,具体取决于机器配置。 Flex调试器可能会崩溃,但更多时候,当调试器和调试Flash播放器无法正常通信时,Flash播放器会冻结。

当系统资源变紧时,它会更容易崩溃。可能是您的代码无法很好地管理资源。可能是您的机器不够强大,无法完成任务。您可能需要不时检查内存占用。您可能需要重新编写算法或数据结构以满足严格的配置。