Adote os recursos de concorrência do Swift

Olá! Sou Doug, da equipe do Swift. Vou mostrar como fazer o melhor uso da concorrência do Swift no seu app. Com a concorrência, o código pode executar várias tarefas ao mesmo tempo. Você pode usá-la no app para deixá-lo mais responsivo ao aguardar dados, como ler arquivos do disco ou fazer uma solicitação de rede. Também é possível mover tarefas pesadas para segundo plano, como processar imagens grandes. O modelo de concorrência do Swift foi criado para facilitar a escrita correta de código concorrente. Ele torna explícita a introdução da concorrência e identifica quais dados são compartilhados entre tarefas concorrentes. Ele usa essas informações para identificar possíveis corridas de dados em tempo de compilação para você introduzir a concorrência conforme necessário, sem medo de criar corridas de dados difíceis de corrigir.

Muitos apps só precisam usar a concorrência com moderação, e alguns não precisam. O código concorrente é mais complexo do que o código de thread única, e só deve ser usado quando necessário.

Seus apps devem começar executando todo o código na thread principal, e você pode ir longe com o código de thread única. A thread principal é onde o app recebe eventos relacionados à interface e pode atualizá-la em resposta. Se você não está fazendo muita computação no seu app, pode manter tudo na thread principal! É provável que você precise introduzir um código assíncrono, talvez para buscar conteúdo pela rede. Seu código pode esperar que o conteúdo entre na rede sem fazer com que a interface trave. Se essas tarefas levarem muito tempo para serem executadas, poderemos movê-las para uma thread em segundo plano executada concorrentemente com a principal.

À medida que o app cresce, manter todos os dados na thread principal pode prejudicar o desempenho. Aqui, podemos introduzir tipos de dados para fins específicos que sempre são executados em segundo plano.

A concorrência do Swift fornece ferramentas como agentes e tarefas para expressar esses tipos de operações concorrentes. É provável que um grande app tenha uma arquitetura um pouco parecida com esta. Mas você não começa por aí, e nem todo app precisa acabar aqui. Nesta sessão, vamos falar sobre as etapas de um app nessa jornada para passar de thread única para concorrente. Vamos ajudar você a entender quando dar cada passo, quais recursos de linguagem do Swift usar, como usá-los de forma eficaz e por que eles funcionam assim. Primeiro, descreveremos como o código de thread única funciona com a concorrência do Swift. Depois, apresentaremos tarefas assíncronas para ajudar em operações de alta latência, como acesso à rede. Depois, mostraremos como mover tarefas para segundo plano e compartilhar dados entre threads com segurança. Por fim, vamos retirar os dados do tópico principal com os agentes. Vamos começar com o código de thread única. Quando você executa um programa, o código começa a ser executado na thread principal. Qualquer código adicionado permanece na thread principal até você introduzir explicitamente a concorrência para executar o código em outro lugar. O código de thread única é mais fácil de escrever e manter porque faz apenas uma coisa de cada vez. Se você introduzir concorrência depois, o Swift protegerá o código na thread principal.

A thread principal e todos os seus dados são representados pelo agente principal. Não há concorrência no agente principal porque há apenas uma thread principal que pode executá-lo. Podemos especificar que os dados ou o código estão no agente principal usando a notação @MainActor. O Swift garantirá que o código do agente principal seja executado somente na thread principal e que os dados sejam acessados somente a partir dele. Dizemos que tal código é isolado do agente principal. O Swift protege seu código de thread principal usando o agente principal por padrão. Isso é como o compilador do Swift escrevendo @MainActor para você em tudo naquele módulo. Assim, podemos acessar variáveis estáticas compartilhadas de qualquer lugar no código. No modo de agente principal, não precisamos nos preocupar com o acesso concorrente até começarmos a introduzir a concorrência. A proteção do código com o agente principal por padrão é orientada por um ajuste de compilação. Use isso principalmente para seu módulo de app principal e módulos focados em interações da interface. Esse modo é ativado por padrão em novos apps criados com o Xcode 26. Neste vídeo, assumiremos que o modo de agente principal está ativado em todos os exemplos de código.

Vamos adicionar um método no nosso modelo de imagem para buscar e exibir uma imagem de um URL. Queremos carregar uma imagem de um arquivo local. Depois, vamos decodificar e exibir essa imagem na interface. Nosso app não tem nenhuma concorrência. Há apenas uma única thread principal fazendo todo o trabalho. Essa função roda inteira na thread principal de uma vez só. Se todas as operações aqui forem rápidas o suficiente, tudo bem.

No momento, só podemos ler arquivos localmente. Se quisermos permitir que nosso app busque uma imagem pela rede, precisaremos usar outra API.

Essa API URLSession nos permite buscar dados pela rede com um URL. No entanto, a execução desse método na thread principal congela a interface até que os dados sejam baixados da rede. Como desenvolvedor, é importante manter seu app responsivo. Ou seja, tome cuidado para não amarrar a thread principal por tanto tempo a ponto de a interface falhar ou travar. A concorrência do Swift fornece ferramentas para ajudar: Tarefas assíncronas podem ser usadas ao aguardar dados, como uma solicitação de rede, sem bloquear a thread principal.

Para evitar travamentos como esse, o acesso à rede é assíncrono. Podemos alterar fetchAndDisplayImage para que lide com chamadas assíncronas tornando a função async e chamando o URL da sessão da API com await. A espera indica onde a função pode ser suspensa, ou seja, ela deixa de ser executada na thread atual até que o evento que está aguardando aconteça. Em seguida, ela pode retomar a execução.

Podemos pensar nisso como quebrar a função em duas partes: a parte que corre até começarmos a buscar a imagem e a que corre depois que a imagem foi buscada. Ao dividir a função dessa forma, permitimos que outros trabalhos sejam executados entre as duas partes, mantendo a interface responsiva.

Na prática, muitas APIs de biblioteca, como a URLSession, descarregam o trabalho em segundo plano para você. Ainda não introduzimos a concorrência no nosso próprio código porque não precisávamos! Melhoramos a capacidade de resposta do app com código assíncrono e APIs de biblioteca que já descarregam o trabalho em nosso nome. Tudo o que precisávamos fazer em nosso código era adotar async/await.

Até agora, nosso código está executando apenas uma função async. Uma função async é executada em uma tarefa. Uma tarefa é executada independentemente de outro código e deve ser criada para executar uma operação específica de ponta a ponta. É comum criar uma tarefa em resposta a um evento, como pressionar um botão. Aqui, a tarefa executa a operação completa de busca e exibição de imagens. Pode haver muitas tarefas assíncronas em um determinado app. Além da tarefa de buscar e exibir imagens de que estamos falando, adicionei uma segunda tarefa que busca as notícias, as exibe e aguarda uma atualização. Cada tarefa concluirá suas operações em ordem do início ao fim. A busca acontece em segundo plano, mas as outras operações em cada tarefa serão executadas na thread principal, e apenas uma operação poderá ser executada por vez. As tarefas são independentes umas das outras, portanto, cada tarefa pode se revezar na thread principal. A thread principal executará as partes de cada tarefa à medida que elas ficarem prontas para serem executadas. Uma única thread alternando entre várias tarefas é chamada de interleaving. Isso melhora o desempenho geral, fazendo o uso mais eficiente dos recursos do sistema. Uma thread pode começar a progredir em uma tarefa o mais rápido possível, em vez de ficar ociosa enquanto espera uma única operação. Se a busca da imagem for concluída antes de buscar a notícia, a thread principal começará a decodificar e exibir a imagem antes de exibir a notícia. Mas se a busca da notícia terminar primeiro, a thread principal poderá começar a exibir a notícia antes de decodificar a imagem.

Várias tarefas assíncronas são ótimas quando seu app precisa executar várias operações independentes ao mesmo tempo. Quando você precisa executar o trabalho em uma ordem específica, deve fazer isso em uma única tarefa.

Para tornar seu app responsivo quando houver operações de alta latência, como uma solicitação de rede, use uma tarefa assíncrona para ocultar essa latência. As bibliotecas podem ajudar aqui fornecendo APIs assíncronas que podem criar concorrência por você, enquanto seu próprio código permanece na thread principal. A API URLSession já introduziu concorrência para nós porque está gerenciando o acesso à rede em uma thread em segundo plano. Nossa própria operação de imagem de busca e exibição está sendo executada na thread principal. Podemos achar que a operação de decodificação está demorando muito. Isso pode acontecer quando a interface trava ao decodificar uma imagem grande.

Assíncrono e de thread única geralmente é suficiente para um app. Mas se você notar que seu app não está respondendo, é um indício de que muita coisa está acontecendo na thread principal. Uma ferramenta de criação de perfil, como Instruments, pode ajudar você a determinar onde está gastando muito tempo. Se o trabalho puder ser feito mais rapidamente sem concorrência, faça isso primeiro. Se não for possível fazê-lo mais rápido, talvez seja necessário introduzir a concorrência. É ela que permite que partes do seu código sejam executadas em segundo plano junto à thread principal, sem travar a interface. Ela também pode ser usada para fazer o trabalho mais rápido usando mais núcleos da CPU no sistema. Nosso objetivo é tirar a decodificação da thread principal para que o trabalho possa acontecer na thread em segundo plano. Como estamos no modo de agente principal por padrão, fetchAndDisplaylmage e decodelmage são isoladas para o agente principal. O código do agente principal pode acessar livremente todos os dados e códigos acessíveis apenas para a thread principal. Isso é seguro porque não há concorrência na thread principal.

Queremos descarregar a chamada para decodeImage. Para isso, aplicamos o atributo @concurrent à função decodeImage. @concurrent diz ao Swift para executar a função em segundo plano. Alterar onde decodeImage é executada também altera nossas suposições sobre qual estado a decodeImage pode acessar. Vamos dar uma olhada na implementação. A implementação está verificando um dicionário de dados de imagem em cache armazenados no agente principal, o que só pode ser feito com segurança na thread principal. O compilador do Swift mostra onde a função tenta acessar dados sobre o agente principal. É isso que precisamos saber para ter certeza de que não estamos introduzindo falhas ao adicionar concorrência. Você pode usar algumas estratégias ao romper relações com o agente principal para introduzir a concorrência com segurança. Em alguns casos, você pode mover o código do agente principal para um chamador que sempre é executado no agente principal. Essa será uma boa estratégia se você quiser garantir que o trabalho aconteça de forma síncrona. Ou você pode usar await para acessar o agente principal no código concorrente de forma assíncrona.

Se o código não precisar estar no agente principal, adicione a palavra-chave não isolada para separá-lo de qualquer agente. Vamos explorar a primeira estratégia agora e falar sobre as outras mais tarde. Vou mover o cache de imagens para fetchAndDisplayImage, que é executada no agente principal. Verificar o cache antes de fazer qualquer chamada assíncrona é bom para eliminar a latência. Se a imagem estiver no cache, fetchAndDisplayImage será concluída de forma síncrona sem suspensão. Portanto, os resultados serão entregues à interface imediatamente, e ela só será suspensa se a imagem ainda não estiver disponível.

E podemos remover o parâmetro de URL de decodeImage porque não precisamos mais dele. Agora, só precisamos aguardar o resultado da decodeImage.

Uma função @concurrent sempre se desligará de um agente para ser executada. Se quiser que a função permaneça em qualquer agente em que foi chamada, use a palavra-chave não isolada. O Swift tem outras maneiras de introduzir mais concorrência. Saiba mais em “Beyond the basics of structured concurrency”.

Se estivermos fornecendo APIs de decodificação como parte de uma biblioteca para muitos clientes usarem, usar @concurrent nem sempre é a melhor escolha de API. O tempo para decodificar dados depende do tamanho, e pequenas quantidades podem ser processadas na thread principal. Para bibliotecas, é melhor fornecer uma API não isolada e permitir que os clientes decidam se querem descarregar o trabalho.

O código não isolado é muito flexível porque você pode chamá-lo de qualquer lugar: se você o chamar do agente principal, ele ficará no agente principal. Se você o chamar de uma thread em segundo plano, ele permanecerá em uma thread em segundo plano. Isso o torna um ótimo padrão para bibliotecas de uso geral. Ao descarregar o trabalho para o segundo plano, o sistema gerencia o agendamento do trabalho a ser executado em segundo plano. O pool de threads concorrentes contém as threads em segundo plano do sistema, que podem envolver qualquer número de threads. Para dispositivos menores, como um relógio, pode haver apenas uma ou duas threads no pool. Sistemas grandes com mais núcleos terão mais threads em segundo plano no pool. Não importa em qual thread em segundo plano uma tarefa é executada, e você pode confiar no sistema para fazer o melhor uso dos recursos. Por exemplo, quando uma tarefa é suspensa, a thread original começa a executar outras tarefas que estão prontas. Quando a tarefa é retomada, ela pode começar a ser executada em qualquer thread disponível no pool concorrente, que pode ser diferente da thread em segundo plano no qual foi iniciada.

Agora que temos concorrência, vamos compartilhar dados entre várias threads. O compartilhamento de estado mutável em um código concorrente é propenso a erros que causam falhas de tempo de execução difíceis de corrigir. O Swift ajuda a detectar esses erros em tempo de compilação para que você possa escrever códigos de concorrência com confiança. Cada vez que alternamos entre o agente principal e o pool concorrente, compartilhamos dados entre threads diferentes. Quando obtemos o URL da interface, ele é passado do agente principal para fora da thread de segundo plano para buscar a imagem. A busca da imagem retorna dados, que são passados para a decodificação da imagem. Depois de decodificarmos a imagem, ela é passada de volta para o agente principal, junto com self. O Swift garante acesso seguro a todos esses valores no código concorrente. Vamos ver o que acontecerá se a atualização da interface criar tarefas adicionais que envolvem o URL. Felizmente, o URL é um tipo de valor. Isso significa que, quando copiamos o URL para a thread em segundo plano, ele tem uma cópia separada daquela que está na thread principal. Se o usuário inserir um novo URL pela interface, o código na thread principal estará livre para usar ou modificar seu texto, e as alterações não terão efeito sobre o valor usado na thread em segundo plano. Portanto, é seguro compartilhar tipos de valor, como o URL, porque ele não está realmente compartilhando: cada cópia é independente das outras.

Os tipos de valor são uma grande parte do Swift desde o início. Todos os tipos básicos, como strings, inteiros e datas, são tipos de valor.

Coleções de tipos de valor, como dicionários e matrizes, também são tipos de valor. E também são structs e enums que armazenam tipos de valor, como este Post struct. Chamamos tipos cujo compartilhamento é sempre seguro concorrentemente de tipos Sendable. O Sendable é um protocolo, e qualquer tipo que esteja em conformidade com ele é seguro para compartilhar. Coleções como Array definem conformidades condicionais para Sendable, portanto, elas são Sendable quando seus elementos são. Structs e enums podem ser marcados como Sendable quando todos os seus dados de instância são Sendable. E os tipos de agentes principais são implicitamente Sendable, então você não precisa dizer isso explicitamente. Agentes como o principal protegem o estado não Sendable, garantindo que só seja acessado por uma tarefa por vez. Os agentes podem armazenar valores passados para seus métodos, e o agente pode retornar uma referência ao estado protegido a partir dos métodos. Sempre que um valor é enviado para dentro ou para fora de um agente, o compilador do Swift verifica se o valor é seguro para enviar ao código concorrente. Vamos nos concentrar na chamada assíncrona para decodeImage.

Decodificar imagem é um método de instância, então estamos passando um autoargumento implícito.

Aqui, vemos dois valores sendo enviados para fora do agente principal e um valor de resultado sendo enviado de volta para o agente principal. self é minha classe de modelo de imagem, que é o agente principal isolado. O agente principal protege o estado mutável, portanto, é seguro passar uma referência à classe para a thread em segundo plano. E Dados são um tipo de valor, portanto são Sendable.

Isso deixa o tipo de imagem. Poderia ser um tipo de valor, como Dados, caso em que seria Sendable. Em vez disso, vamos falar sobre tipos que não são Sendable, como classes. As classes são tipos de referência, ou seja, ao atribuir uma variável a outra, elas apontam para o mesmo objeto na memória. Se você alterar algo no objeto por meio de uma variável, como dimensionar a imagem, essas alterações serão imediatamente visíveis por meio das outras variáveis que apontam para o mesmo objeto. fetchAndDisplayImage não usa o valor de imagem concorrentemente. decodeImage é executada em segundo plano, portanto, não pode acessar nenhum estado protegido por um agente. Ela cria uma nova instância de uma imagem a partir dos dados fornecidos. Essa imagem não pode ser referenciada por nenhum código concorrente, portanto, é seguro enviá-la ao agente principal e exibi-la na interface. Vamos ver o que acontece quando introduzimos alguma concorrência. Primeiro, esse método scaleAndDisplay carrega uma nova imagem na thread principal. A variável image aponta para esse objeto image, que contém a imagem do gato. Em seguida, a função cria uma tarefa em execução no pool concorrente e que obtém uma cópia da imagem. Por fim, a thread principal passa a exibir a imagem. Agora, temos um problema. A thread em segundo plano está alterando a imagem: mudando a largura e a altura e substituindo os pixels pelos de uma versão dimensionada. Ao mesmo tempo, a thread principal está iterando sobre os pixels com base na largura e altura antigas. Isso é uma corrida de dados. Você pode acabar com um erro na interface ou, provavelmente, acabará com uma falha quando o programa tentar acessar fora dos limites da matriz de pixels. A concorrência do Swift evitará corridas de dados com erros do compilador se o código tentar compartilhar um tipo não Sendable. Aqui, o compilador indica que a tarefa concorrente está capturando a imagem, que também é usada pelo agente principal para exibir a imagem. Para corrigir isso, precisamos evitar compartilhar o mesmo objeto concorrentemente. Se quisermos que o efeito de imagem seja mostrado na interface, o correto é aguardar a conclusão do dimensionamento antes de exibir a imagem. Podemos mover todas essas três operações para a tarefa para garantir que elas aconteçam em ordem. displayImage tem que ser executada no agente principal, então usamos await para chamá-la de uma tarefa concorrente. Se pudermos tornar scaleAndDisplay assíncrona diretamente, poderemos simplificar o código para não criar uma nova tarefa e executar as três operações em ordem na tarefa que chamar scaleAndDisplay. Depois de enviar a imagem para o agente principal para exibição na interface, ele é livre para armazenar uma referência à imagem, por exemplo, armazenando em cache o objeto de imagem. Se alterarmos a imagem após exibi-la na interface, o compilador mostrará erro de acesso concorrente inseguro. Podemos resolver o problema fazendo alterações na imagem antes de enviá-la ao agente principal. Se você estiver usando classes para seu modelo de dados, elas provavelmente começarão no agente principal para que você possa apresentar partes delas na interface. Se você decidir que precisa trabalhar com elas em uma thread em segundo plano, torne-as não isoladas. Mas elas provavelmente não devem ser Sendable. Evite situações em que parte do modelo está sendo atualizada na thread principal e outras estão sendo atualizadas na thread em segundo plano. Manter as classes de modelo não Sendable impede que esse tipo de modificação concorrente ocorra. Também é mais simples porque tornar uma classe Sendable geralmente exige mecanismos de sincronização de baixo nível, como cadeado. Assim como as classes, os fechamentos podem criar um estado compartilhado. Confira esta função semelhante a outra que vimos que dimensiona e exibe uma imagem. Ela cria um objeto de imagem. Depois, ela chama perform(afterDelay:) com um fechamento que redimensiona a imagem. Esse fechamento contém outra referência à mesma imagem. Chamamos isso de captura da variável de imagem. Assim como as classes não Sendable, um fechamento com estado compartilhado ainda é seguro, desde que não seja chamado de maneira concorrente. Só torne um tipo de função Sendable se precisar compartilhá-la concorrentemente.

A verificação Sendable ocorre sempre que dados passam entre agentes e tarefas. Ela está lá para garantir que não haja corridas de dados que possam causar falhas no seu app. Muitos tipos comuns podem ser Sendable e compartilhados livremente em tarefas concorrentes. Classes e fechamentos podem envolver um estado mutável que não é seguro compartilhar concorrentemente, portanto, use-os de uma tarefa por vez.

Você ainda pode enviar um objeto de uma tarefa para outra, mas faça todas as modificações nele antes de enviá-lo. Mover tarefas assíncronas para threads em segundo plano pode liberar a thread principal para manter seu app responsivo. Se você achar que tem muitos dados no agente principal que estão fazendo com que essas tarefas assíncronas façam verificações na thread principal com frequência, convém introduzir agentes.

À medida que seu app cresce com o tempo, você pode descobrir que a quantidade de estado no agente principal também cresce. Você introduzirá novos subsistemas para lidar com coisas como o gerenciamento do acesso à rede. Isso pode causar muito estado vivendo no agente principal, por exemplo, o conjunto de conexões abertas manipuladas pelo gerenciador de rede, que acessaríamos sempre que precisássemos buscar dados pela rede. Quando começamos a usar esses subsistemas extras, a tarefa de buscar e exibir imagens anteriores ficou mais complicada: ela está tentando ser executada na thread em segundo plano, mas precisa pular para a thread principal porque é onde estão os dados do gerenciador de rede. Isso pode levar a uma contenção, em que muitas tarefas estão tentando executar códigos no agente principal ao mesmo tempo. As operações individuais podem ser rápidas, mas muitas tarefas fazendo isso podem travar a interface. Antes, retiramos o código da thread principal colocando-o em uma função @concurrent. Aqui, todo o trabalho está no acesso aos dados do gerenciador de rede. Para mudar isso, podemos introduzir nosso próprio agente gerente de rede. Assim como o agente principal, os agentes isolam os dados de modo que você só pode acessá-los quando está em execução nele. Junto com o agente principal, você pode definir seus próprios tipos de agente. Um tipo de agente é semelhante a uma classe de agente principal. Como uma classe de agente principal, ele isolará os dados para que apenas uma thread possa acessar os dados por vez. Um tipo de agente também é Sendable para que você possa compartilhar livremente objetos de agente. Ao contrário do agente principal, pode haver muitos objetos de agente em um programa, e todos são independentes. Além disso, os objetos do agente não estão ligados a uma única thread como o agente principal. Portanto, mover parte do estado do agente principal para um objeto de agente permite que mais código rode em segundo plano, mantendo a thread principal livre para a interface.

Use agentes quando achar que armazenar dados no agente principal está fazendo com que muito código seja executado na thread principal. Nesse ponto, separe os dados de uma parte não interface do seu código, como o código de gerenciamento de rede, em um novo agente.

Esteja ciente de que a maioria das classes no seu app provavelmente não devem ser agentes: As classes voltadas para a interface devem permanecer no agente principal para interagir diretamente com o estado da interface. As classes de modelo geralmente devem estar no agente principal com a interface ou mantidas como não Sendable para você não incentivar muitos acessos concorrentes ao seu modelo.

Nesta sessão, começamos com o código de thread única. À medida que nossas necessidades aumentavam, introduzimos tarefas assíncronas para ocultar a latência, código concorrente para ser executado em uma thread em segundo plano e agentes para retirar o acesso aos dados da thread principal. Com o tempo, muitos apps seguirão esse mesmo caminho.

Use ferramentas de criação de perfil para identificar quando e qual código retirar da thread principal. A concorrência do Swift ajudará você a separar o código da thread principal, melhorando o desempenho e a capacidade de resposta do seu app.

Temos alguns ajustes de compilação recomendados para seu app para ajudar na introdução da concorrência. O ajuste Approachable Concurrency ativa um pacote de recursos futuros que facilitam o trabalho com concorrência. Recomendamos que todos os projetos adotem esse ajuste. Para módulos do Swift que interagem principalmente com a interface, como o módulo principal do app, também recomendamos definir Default Actor Isolation como MainActor. Isso coloca o código no agente principal, a menos que você tenha dito o contrário. Esses ajustes funcionam juntos para facilitar a criação de apps em thread única e proporcionam um caminho mais acessível para introduzir a concorrência quando você precisar. A concorrência do Swift é uma ferramenta criada para ajudar a melhorar seu app. Use-a para introduzir código assíncrono ou concorrente quando encontrar problemas de desempenho no seu app. O guia de migração do Swift 6 responde a mais perguntas sobre concorrência e o caminho para a segurança na corrida de dados. E para ver como os conceitos desta sessão se aplicam em um exemplo de app, assista à nossa sessão prática complementar. Obrigado.