As questões sobre o garbage collector (GC) têm vindo a assombrar-me desde o início da minha curta experiência com Flex. Após a leitura de inúmeros artigos (ver links abaixo) e um contacto directo com um developer da Adobe, concluí que o GC actual tem alguns bugs que impedem uma libertação total da memória para o sistema operativo. O actual GC foi criado ainda na altura em que as aplicações flash eram ainda programas que seriam utilizados durante um curto período de tempo e num browser. Deste modo, passado um bocado acabaríamos por navegar para fora da página da aplicação ou fecharíamos o browser, libertando assim a memória. Acontece que agora, e cada vez mais, temos muitas aplicações flash/flex/air que são supostas ficar em execução durante longos períodos de tempo e é agora que nos apercebemos realmente da falta que nos faria um GC mais robusto.
Muito resumidamente, o GC funciona da seguinte maneira: - Apenas os objectos que não tenham qualquer referência é que poderão ser libertados. Isto significa que mesmo que tenhamos colocado um objecto a null, se este tiver, por exemplo, um listener pendurado (que não tenha sido removido) o GC não vai apagar esse objecto. Daí a importância de removermos todas as referências a um objecto quando queremos que ele seja apagado. - O GC só irá libertar memória numa altura indeterminada. Ou seja, todos os objectos que tenhamos "apagado" (removido as referências) só vão ser realmente apagados quando o GC passar e, infelizmente, não sabemos quando é que isso acontece exactamente. Nota-se que nas alturas em que é necessário criar novos objectos o GC parece passar mas o algoritmo é muito incerto. Existem vários artigos que mostram um "truque" para obrigar o GC a passar (fazendo duas chamadas seguidas a uma localConnection). Este truque pode ser usado quando ainda estamos em fase de desenvolvimento para detectar fugas de memória mas nunca deve usado em versões release do programa. Pela conversa que tive com o developer da adobe o GC será melhorado numa futura versão do AIR (talvez já na próxima, esperemos). Por enquanto a única coisa que podemos fazer é continuar a seguir as boas práticas de programação (libertando todos os objectos quando já não precisamos deles, parando todos os sons, videos, timers, removendo todos os listeners, etc) e esperar que tudo funcione bem. Para quem esteja interessado neste assunto aconselho a leitura dos seguintes artigos: http://www.gskinner.com/blog/archives/2006/06/as3_resource_ma.html http://www.gskinner.com/blog/archives/2006/07/as3_resource_ma_1.html http://www.gskinner.com/blog/archives/2006/08/as3_resource_ma_2.html http://www.gskinner.com/blog/archives/2006/09/garbage_collect.html http://gskinner.com/talks/resource-management/ http://www.adobe.com/devnet/flashplayer/articles/garbage_collection.html# http://blogs.adobe.com/aharui/2007/03/garbage_collection_and_memory.html Boas libertações de memória ;) CT On 15 Maio, 17:18, Miguel Vaz <[email protected]> wrote: > Boa tarde, > > Tenho umas questões sobre bons procedimentos nos seguintes aspectos: > > - Garbage collector - Pelo que fui lendo sobre este estranho personagem, o > garbage collector funciona sobre itens (componentes, etc) que não estejam > ligados a nenhum processo de..bem, processamento. Situações como a da > existência de um modelo poderão afectar esta situação? Ou seja, imaginem um > componente criado dinamicamente, com ligações a variáveis de modelo, como é > suposto acontecer, a remoção desse componente poderá entrar para a lista de > uma posterior garbage collection? Tenho dúvida visto que, apesar do > componente ser removido, fica a existir uma ligação intrínseca entre este e > as variáveis do modelo? É uma ligação efectiva que poderá impedir a garbage > collection? > > - Num ambiente MVC existindo um componente/popup A sempre presente, que cria > outros componentes/popups (B, C...), poderá ser considerado mau procedimento > se, de um desses componentes (B,C..), eu fizer uma chamada directa para o > componente A sempre presente (criado inicialmente e nunca mais removido, > mantendo uma var no modelo com a sua referÊncia para poder endereçar de > outros lados)? Fico com dúvida por não se tratar propriamente de andar a > navegar em referências dinâmicas, mas sim em endereçar directamente algo > estático (uma função public no componente A) e sempre presente. Isto > contraposto a gerar um evento de um desses componentes secundários que será > apanhado pelo tal componente estático, e então devidamente processado. > > Perdoem o email longo, mas são questões que me perseguem (solvo seja). > > MV --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
