Ora aqui esta um assunto que tenho explorado...
A primeira coisa a entender ou relembrar e como a RAM funciona...
Há que manter presente que a RAM nunca é propriamente limpa, em vez
disso o que acontece e remover-se os apontadores para informação nela
guardada, assim sendo quando há um pedido de registo na RAM esta é
validade de acordo com os apontadores existentes... assim sendo basta
que uma qqer variável continue a apontar para um bloco de informação
dentro da RAM para que esse espaço continue reservado e indisponível
para alocação de novos dados.
Os famosos "Memorie Leeks" surgem quando se perde noção da quantidade de
informação que está presa na RAM por simplesmente existirem apontadores
que já não deviam existir. Um bom exemplo e esta nova mania que continuo
a não entender de não se distinguir variáveis locais de propriedades de
objecto, refiro-me a omissão da palavra chave "this" quando referente a
propriedades do próprio objecto, isto na minha experiência pode resultar
em apontadores para a memoria que não são apanhados pelo "Garbage
Collector" quando a instância do método onde foi utilizado é terminada.
Concelhos:
- Utilizem sempre, _Sempre,_ o this para distinguir propriedades de
variáveis locais e usem nomenclaturas claramente destinas de variaveis
locais das ditas propriedades...(neste caso utilizo 'o' minúsculo na
variável local para a identificar como um "Object" mas não na sua
vertente propriedade...) ex:
pakage{
private var someVar:Sprite = null
private function SomeFunction():void {
var oSomeVar:Sprite = null
}
}
- Removam sempre eventos do tipo LOAD ou outros do género cuja
utilização não e recursiva, de facto listeners são de longe uma das
formas mais habituais de manter objectos presos na memoria sem que
notemos, basta que um qqer objecto tenha 1 ENTER_FRAME event e nem mesmo
quando fazem removeChild a este objecto ele desaparece.... aconselho
alias o recurso a classes que consigam de alguma forma fazer 1
"RemoveAllListeners" ou mesmo fazerem-no vocês mesmos...
- Igualar variáveis/propriedades a "null" não significa
necessariamente que o objecto tenha desaparecido, isto limpa apenas esse
apontador especifico para o bloco de memoria onde ele se encontra. O
ideal será que cada objecto tenha um método universal tipo "Kill,
Delete... whatever" que seja responsável por remover quaisquer
apontadores próprios ou de despontar "Kill, Delete... etc" em outros
objectos dentro dele mesmo...
rui wrote:
> LOOOL desculpa miguel, não resisti :D
>
> O que eu fiz, embora não saiba se é o metodo mais correcto foi percorrer
> o childs do objecto e no ciclo for each item in objecto.childs eu fiz
> objecto.removeChild(item); item=null;
>
> e se tiveres listeneres ou outro tipo de variaveis mais chatas como
> bitmapdatas podes fazer o que quiseres com elas dentro do ciclo.
>
> Eu ainda fiz pior, como eu tenho vários tipos de objectos dentro do
> canvas, eu dentro do ciclo for each fiz: if(item is Tasko)
> item.fecha_torneiras(); e dentro do teu objecto tasko tens lá a função
> fecha_torneiras() que limpa o que tiveres a limpar, tambem podes chamar
> esta funçao no listener FlexEvent.removedFromStage esse que definiste no
> creationComplete do Tasko
>
>
> Abraço,
> Rui
>
>
>
> Miguel Vaz wrote:
>
>> ok, rui, obrigadinho pelo atestado de lerdice. :-P
>>
>> Referia-me a objecto no sentido lato. Um canvas é um objecto, o tasco
>> da esquina é um objecto, child de alguma coisa, fazer removeChild não
>> é suficiente, daí fazer o null?
>>
>> tenho váris criações de components, cujo remove não é suficiente,
>> ficando para trás - utilizando o profiling vejo esse facto.
>>
>> Mas ok, lembra-me para, da próxima que colocares uma dúvida, eu
>> responder da mesma forma, talvez até com uma imagem. ;-) (j/k)
>>
>>
>> MV
>>
>>
>>
>> 2009/3/9 rui <[email protected] <mailto:[email protected]>>
>>
>>
>> Miguel Vaz wrote:
>> >
>> >
>> > Desculpa, João, podias dar um exemplo sobre como definir um objecto
>> > como null?
>> >
>> > Obrigado.
>> >
>> >
>> > MV
>> >
>> >
>> >
>> >
>> >
>> > 2009/3/9 João Fernandes <[email protected]
>> <mailto:[email protected]>
>> > <mailto:[email protected]
>> <mailto:[email protected]>>>
>> >
>> >
>> > Miguel,
>> >
>> > existem várias formas de limitar ao máximo as memory leaks,
>> tais como
>> > remover os eventListeners ou adiciona-los como weakReferences
>> > (remover é
>> > sempre uma excelente aposta), definir os teus objectos como
>> nulls para
>> > não ficarem agarrados. Usando o profiler consegues facilmente
>> > encontrar
>> > os objectos que supostamente deveriam ter sido eliminados mas no
>> > entanto
>> > permanecem lá, aliás, o uso do profiler a meu ver é um requesito
>> > mínimo
>> > e não facultativo.
>> >
>> >
>> > --
>> >
>> > João Fernandes
>> >
>> > Adobe Certified Expert
>> > Adobe Community Expert
>> > http://www.onflexwithcf.org
>> > http://www.riapt.org
>> > Portugal Adobe User Group (http://aug.riapt.org)
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > >
>> objecto = null?
>>
>>
>>
>>
>>
>
>
> >
>
>
--~--~---------~--~----~------------~-------~--~----~
Recebeu esta mensagem porque está inscrito em Grupo "Mailing List da Comunidade
Portuguesa de Rich Internet Applications - www.riapt.org" do Grupos Google.
Para enviar mensagens para este grupo, envie um email para
[email protected]
Para anular a inscrição neste grupo, envie um email para
[email protected]
Para mais opções, visite este grupo em
http://groups.google.com/group/riapt?hl=pt-PT
-~----------~----~----~----~------~----~------~--~---
