blocks|key|1606281|text|public+class+MySprite+extends+Sprite+{

++++public+function+MySprite()+{
++++++++if(stage)+{
++++++++++++init();
++++++++}+else+{
++++++++++++addEventListener(Event.ADDED_TO_STAGE,init);
++++++++}
++++}+

++++private+function+init(e:Event+=+null):void+{
++++++++stage.addEventListener(Event.RESIZE,handleStageResize);
++++}

++++private+function+handleStageResize(e:Event):void+{
++++++++//++do+some+processing+here.
++++}

}|type|code-block|depth|inlineStyleRanges|entityRanges|data|syntax|javascript|1606282|其他地方：|unstyled|1606283|var+mySprite:MySprite+=+new+MySprite();
someHolder.addChild(mySprite);|1606284|现在，如果稍后删除了mySprite，它仍然会挂在内存中，因为它已经在init()方法中将自身(或对自身的引用)添加到了stage中。|1606285|在这种情况下，避免这种情况的最佳方法是在从显示列表中删除mySprite时删除添加到舞台的侦听器。|1606286|++++private+function+init(e:Event+=+null):void+{
++++++++addEventListener(Event.REMOVED_FROM_STAGE,cleanUp);
++++++++stage.addEventListener(Event.RESIZE,handleStageResize);

++++}

++++private+function+cleanUp(e:Event):void+{
+++++++stage.removeEventListener(Event.RESIZE,handleStageResize);+
++++}|1606287|我相信其他人会告诉你在将监听器添加到舞台时使用弱引用，但无论如何你都应该删除你的监听器。如果不这样做，当您从显示列表中删除mySprite并且没有对它的其他引用时，将有资格进行GC，并且最终将从内存中清除。但在此之前，handleStageResize()中的代码将继续执行。|1606288|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$B|C]]|$1|D|3|E|5|F|7|T|8|@]|9|@]|A|$]]|$1|G|3|H|5|6|7|U|8|@]|9|@]|A|$B|C]]|$1|I|3|J|5|F|7|V|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|W|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|X|8|@]|9|@]|A|$B|C]]|$1|O|3|P|5|F|7|Y|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|F|7|Z|8|@]|9|@]|A|$]]]|R|$]]

<pre><code>public class MySprite extends Sprite {

 public function MySprite() {
 if(stage) {
 init();
 } else {
 addEventListener(Event.ADDED_TO_STAGE,init);
 }
 } 

 private function init(e:Event = null):void {
 stage.addEventListener(Event.RESIZE,handleStageResize);
 }

 private function handleStageResize(e:Event):void {
 // do some processing here.
 }

}
</code></pre>

Somewhere else:

<pre><code>var mySprite:MySprite = new MySprite();
someHolder.addChild(mySprite);
</code></pre>

Now, if at some later point you remove mySprite, it'll still hang around in memory, because it has added itself (or a reference to itself) to the stage in the init() method.

In this scenario, the best way to avoid this could be removing the listener added to the stage when mySprite is removed from the display list.

<pre><code> private function init(e:Event = null):void {
 addEventListener(Event.REMOVED_FROM_STAGE,cleanUp);
 stage.addEventListener(Event.RESIZE,handleStageResize);

 }

 private function cleanUp(e:Event):void {
 stage.removeEventListener(Event.RESIZE,handleStageResize); 
 }
</code></pre>

I'm sure other people will tell you to use weak references when adding the listener to the stage, but you should remove your listeners anyway. If you don't, when you remove mySprite from the display list and have no other refs to it, will be eligible for GC and will eventually be wiped away from memory. But until that happens, the code in handleStageResize() will continue to execute.

blocks|key|3014975|text|我不打算发布一个这样的例子，但我会解释一下。您在这里描述了两种情况。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3014976|3014977|memory+leaks|ordered-list-item|3014978|processor+overflows|3014979|3014980|AS3以不同的方式处理内存和处理器操作。|3014981|当有许多对象被创建和销毁时，就会发生内存泄漏。当对象有引用时会泄漏内存，并且对象在没有销毁引用的情况下被销毁-因此，留下一个未使用的对象的内存块=+leak。|3014982|当你有许多方法相互引用而没有“闭合循环”时，就会发生处理器溢出。|3014983|entityMap^0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|R|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|S|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|T|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|U|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|V|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|W|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|X|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]]|P|$]]

I'm not going to post an example of this but I'll explain it a bit. There are 2 situations you are describing here.

<ol>
<li>memory leaks</li>
<li>processor overflows</li>
</ol>

AS3 handles memory and processor operations differently. 

Memory Leaks happen when there are many objects created and destroyed. The objects leak memory when they have references and the object is destroyed with out destroying the references - therefor leaving a memory block of an unused object = leak.

Processor Overflows happen when you have many methods referencing each other with out 'closing the loop'.

blocks|key|3015014|text|我将跟进@Juan的回答--+GC需要作为应用程序设计的一个关键方面从头开始考虑。如果你创建了一个对象，你必须知道对它的每个引用，并移除每个引用并将其置为空，以便正确地标记为@。如果您在数组中引用该对象，则计数；如果您在侦听器中引用该对象，则计数；如果您通过局部变量引用该对象，则计数也算数(尽管仅在函数生命周期内)；如果它只是在显示列表中，则绝对计数，等等。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3015015|我甚至在添加它们之前编写了我的删除侦听器语句，以确保它们。|3015016|我几乎总是会为任何对象编写一个公共销毁()方法来处理内部对象层次结构(父级调用子级的销毁，子级调用销毁，以此类推)。只是移除/清空一个父级而不对每个子级执行此操作，这是糟糕的GC管理。|3015017|如果你真的担心mem泄露的出现，那就追踪System.totalMemory来确认一下：|3015018|var+mem:String+=+Number(+System.totalMemory+/+1024+/+1024+).toFixed(+2+)+%2B+‘Mb’;
trace(+mem+);+//+eg+traces+“24.94Mb”|code-block|syntax|javascript|3015019|大多数情况下--只是要有条不紊--这不是火箭科学，但你必须小心。|3015020|干杯-|3015021|@即使你这样做了，flash也会自己决定何时进行扫描。我们所能做的最好的事情就是确保一个对象被正确地标记，并相信它会得到有效的处理。|3015022|entityMap^0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|V|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|W|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|X|8|@]|9|@]|A|$]]|$1|H|3|I|5|J|7|Y|8|@]|9|@]|A|$K|L]]|$1|M|3|N|5|6|7|Z|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|10|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|11|8|@]|9|@]|A|$]]|$1|S|3|-4|5|6|7|12|8|@]|9|@]|A|$]]]|T|$]]

I'll just follow up @Juan's answer - GC needs to be considered from the ground up as a critical aspect of application design. If you create an object, you must be aware of each reference to it, and remove each reference and nullify it to flag properly@. If you reference that object in array, that counts, if you reference it in a listener, that counts, if you reference it via a local variable, that counts too (though only during the life of the function), if its simply in the display list, that definitely counts, and on and on.

I go so far as to write my remove listener statements prior to adding them just to make sure. 

I will almost always write a public destroy() method for any object to handle inner object hierarchies (parent calls destroy on child, which, in turn calls destroy on any children etc etc). Just removing / nulling a parent without doing so to each child is poor GC management.

And if you actually have any concerns that mem leak has sprung, trace out System.totalMemory just to make sure:

<pre><code>var mem:String = Number( System.totalMemory / 1024 / 1024 ).toFixed( 2 ) + ‘Mb’;
trace( mem ); // eg traces “24.94Mb”
</code></pre>

Mostly - just be methodical about it - its not rocket science, but you have to be careful. 

Cheers -

@ and even if you do, flash makes up its own mind about when to actually do a sweep. The best we can to is ensure an object is properly flagged and trust that it will be dealt with efficiently.

Can someone post an example of as3 code (specifically event listener included) that would be a simple example of something that could leak memory... also hopefully could you post a solution to the problem shown?

The question is: What is a simple example of leaking memory in an AS3 event listener and how can you solve it?

AS3 Memory Leak Example

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

是否有人可以发布一个as3代码示例(特别是事件侦听器)，这将是一个可能泄漏内存的简单示例……同样希望你能发布一个问题的解决方案？问题是: AS3事件侦听器中内存泄漏的简单示例是什么?您如何解决它？

问AS3内存泄漏示例
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问AS3内存泄漏示例EN