Este artigo é uma tradução do artigo http://blog.marcocantu.com/blog/2018-october-Delphi-ARC-directions.html
Alguns anos atrás, quando a Embarcadero começou a construir novos compiladores Delphi para plataformas diferentes do Windows, houve muita discussão sobre como o novo Delphi deveria ser compatível com a linguagem atual, em termos de recursos básicos da linguagem e percepção geral da linguagem. Por fim, a decisão que surgiu foi manter um grau extremamente alto de compatibilidade, com alguns passos significativos e ousados em direção a uma linguagem mais capaz de atrair uma nova geração de desenvolvedores.
O que é a contagem automática de referência?
Uma das mudanças neste espaço foi a decisão de adotar um novo modelo de gerenciamento de memória para as plataformas móveis, seguindo o que a Apple já estava adotando como o modelo de memória do iOS: Automatic Reference Counting ou ARC . Em um dispositivo com restrição de memória, como um telefone celular usando coleta de lixo, isso é considerado um problema (pois você acaba consumindo muito mais memória do que estritamente necessário e isso também afeta a vida útil da bateria) e o ARC oferece um modelo simplificado de gerenciamento de memória, mais fácil de usar em cenários simples, totalmente determinísticos e robustos.
É por isso que o Delphi escolheu o mesmo modelo, estendendo o modelo de contagem de referência de objetos que já estava disponível para interfaces por um longo tempo, tornando-o mais poderoso com referências fracas e inseguras e expandindo-o para variáveis de objetos simples. Esse modelo oferece algumas vantagens significativas, e uma das ideias originais era expandi-lo para a linguagem Delphi em todas as plataformas.
Desvantagens do ARC
Alguns anos depois que o planejado foi implementado, ainda vemos suas vantagens e benefícios, mas temos uma visão muito mais clara das desvantagens do modelo ARC e qual será seu efeito em torná-lo padrão também em aplicativos Windows e VCL .
Há muito tempo consideramos o gerenciamento de memória ARC uma melhoria em relação ao modelo Delphi tradicional, pois ele remove e simplifica parte do gerenciamento de memória. No entanto, aprendemos quando construímos e mantínhamos nossas grandes bibliotecas e conversamos com os clientes em bases de código complexas, que embora o ARC pareça ótimo no papel e para variáveis locais e cenários mais simples, muitas vezes causa muitos problemas em cenários complexos. Além disso, o modelo de propriedade TComponent em que todas as nossas bibliotecas estão centralizadas está em desacordo com o ARC, tornando-o complexo para bibliotecas de componentes existentes habilitadas para ARC.
Poderíamos ter decidido usar o “ARC completo” também no Windows, mas isso teria causado uma quebra significativa de aplicativos e componentes existentes, causando muito mais problemas do que a migração Unicode que fizemos no passado – que foi devido à pressão externa de oferecendo um bom suporte internacional e o fato de que os sistemas operacionais subjacentes (a partir do Windows) também eram Unicode.
Tivemos muitos pedidos para tornar o ARC opcional, mas um objeto habilitado para ARC não coexistirá facilmente com um não habilitado para ARC, e precisaríamos de contêineres para os dois tipos de objetos e tornaria impossível misturá-los. Isso acabaria como um cenário extremamente complexo. Misturar ARC e não-ARC não é uma solução viável, mas também manter diferentes modelos de memória em diferentes plataformas acaba por derrotar toda a ideia de “fonte única, multi-plataforma”, que é um princípio central do foco Delphi tanto do lado do servidor (Windows e Linux) e site do cliente em todas as plataformas para as quais você pode criar aplicativos FireMonkey.
Outro ângulo significativo é que o ARC tem um custo de execução. Embora as coisas possam ser otimizadas e aprimoradas, no final, o gerenciamento automático não é totalmente gratuito. Enquanto a Coleta de Lixo tem um custo (muito alto) quando entra em ação, o ARC tem um custo na vida útil dos objetos e interação com objetos (a menos que você use cautelosamente const para passar todos os parâmetros). Um efeito positivo da desativação do ARC é uma melhoria de desempenho mensurável. Finalmente, o ARC no Delphi é um pouco diferente do lado C ++ do produto, que é parte integrante do RAD Studio.
O novo plano: eliminação progressiva do ARC
... var intf : iInterface; [weak] walkintf : iWalker; begin intf := TAthlete.Create; ...
(usando interfaces no Delphi)
Com todas essas considerações em mente, e após extensas discussões internas, envolvendo também parceiros e desenvolvedores externos, chegamos à conclusão de que o melhor caminho é sair do modelo ARC como uma solução padrão de gerenciamento de memória e compensar sua perda. com outras alternativas.
Em termos práticos, o compilador Linux de 64 bits da versão 10.3 Rio vai oferecer o tradicional gerenciamento de memória Delphi das plataformas Windows, tornando o seu código de servidor Windows e Linux totalmente equivalente – pelo menos em termos de linguagem e gestão de memória Delphi.
O plano de avanço é não abraçar o ARC para a próxima plataforma macOS de 64 bits (portanto, todas as plataformas de desktop são e permanecerão no modelo não-ARC) e desativar o ARC também para plataformas móveis no futuro(provavelmente em torno do próximo lançamento após 10.3). Observe que no 10.3 Rio os compiladores móveis permanecem com o ARC ativado, exatamente como no 10.2.
O que tem a mais para gerenciamento de memória moderna?
Ainda acreditamos que o gerenciamento de memória de contagem de referência é relevante, mas, em vez de introduzir um novo mecanismo para ele, preferimos alavancar e aumentar o modelo de contador de referência existente que é usado por interfaces e cadeias de caracteres no Delphi. Este tem sido o caso por um longo tempo. Referências de interface e referências a objetos para o mesmo objeto podem causar problemas se não forem tratadas corretamente, mas isso é algo que a maioria dos desenvolvedores Delphi já sabe como lidar e há muita documentação sobre o assunto.
Referências de interface foram recentemente estendidas com referências weak e até referências unsafe. Essas opções adicionais aumentam em grande parte o poder e a flexibilidade do “ARC para interfaces”. Em outras palavras, enquanto vamos remover o ARC para referências de objeto, o ARC para referências de interface é um recurso de linguagem que foi e continuará disponível.
Além disso, queremos melhorar e simplificar o gerenciamento do tempo de vida (e do gerenciamento de memória) de objetos locais de curta duração com referências de pilha. Esse não é um recurso que vamos introduzir no 10.3, mas algo que estamos investigando ativamente e pode ser implementado parcialmente por desenvolvedores que aproveitam registros gerenciados (um novo recurso da linguagem em 10.3).
Empacotando
... initialization ReportMemoryLeaksOnShutdown := true; ...
(Memória vazamentos de rastreamento simplificado)
Embora entendamos que essa mudança nos planos feitos há alguns anos possa surpreender e afetar o código existente, desenvolvedores que estavam insatisfeitos com o modelo ARC, suportando vários modelos em diferentes plataformas e sua perda de desempenho em comparação com o gerenciamento de memória nativa , provavelmente irão apreciar a decisão.
Oferecer formas alternativas para simplificar ainda mais o gerenciamento de memória Delphi está no roteiro do RAD Studio, mas o conjunto atual de recursos (interfaces com contagem de referência e suporte para referências fracas e inseguras, o modelo de propriedade de componente e as práticas comuns padrão) já fornece uma boa estrutura para reduzir a preocupação de gerenciamento de memória manual para desenvolvedores Delphi.
Em última análise, não há solução perfeita para o gerenciamento de memória em linguagens de programação, pois as automáticas têm suas desvantagens e as manuais são (bem) manuais. A Delphi teve um equilíbrio muito bom no passado, que continua até hoje e só vai melhorar no futuro.
No nosso treinamento POO Avançado e Programação Funcional você aprenderá não só a gerenciar memórias, irá aprender de forma prática, técnicas que irão te ajudar a ter um código bem estruturado, organizado e preparado para as mudanças repentinas, afinal sabemos que a todo o momento seja por força do governo ou por solicitações de clientes, precisamos realizar alterações em nossos projetos, então porque não ter um código já preparado para essas mudanças? No treinamento, eu desenvolvi um método que alinha exemplos reais de aplicação das técnicas para resolver problemas do dia a dia, Como:
* Reutilização de código
* Fácil adaptação a novas tecnologias / componentes
* Fácil implementação de novas features
* Até 70% de redução no tempo de manutenção do código
* Redução de Bugs na entrega de novas implementações
SAIBA MAIS SOBRE O CURSO POO AVANÇADO E PROGRAMAÇÃO FUNCIONAL CLICANDO AQUI
