Cada aplicativo criado com o aplicativo para desktop do WebCatalog costumava ocupar cerca de 320 MB de espaço em disco no macOS. Isso não é incomum para um aplicativo baseado em Electron, mas o WebCatalog foi projetado para quem usa muitos aplicativos web como aplicativos para desktop. Ao instalar dez deles, o consumo podia passar de 3 GB, embora a maior parte dos dados desses aplicativos fosse exatamente igual.
Recentemente, mudamos a forma como o aplicativo para desktop do WebCatalog cria aplicativos no macOS. O primeiro aplicativo agora usa cerca de 340 MB de espaço físico em disco, incluindo uma cópia preparada do mecanismo do aplicativo, mantida localmente. Depois disso, cada aplicativo adicional normalmente acrescenta apenas 1–2 MB ao uso real do disco. Em nossos testes, dez aplicativos passaram de mais de 3 GB para cerca de 360 MB.
Fizemos isso usando um recurso já integrado ao macOS: os clones APFS. O ponto interessante não foi simplesmente clonar arquivos, mas fazer a clonagem funcionar mantendo cada aplicativo independente, com uma assinatura de código válida e funcionalmente equivalente a um aplicativo criado pelo processo antigo.
Por que cada aplicativo ocupava mais 320 MB
O aplicativo para desktop do WebCatalog transforma sites em aplicativos independentes para desktop. Cada aplicativo criado roda no Photon, nosso mecanismo de aplicativos baseado em Electron. No macOS, cada um é um pacote .app normal que contém Electron (Chromium e Node.js), Photon e os arquivos específicos daquele aplicativo.
Considere, por exemplo, dois aplicativos: Slack e Discord. Seus nomes, ícones, identificadores de pacote e configurações são diferentes, mas o grande framework do Electron e a maior parte do Photon são idênticos.
Até agora, cada aplicativo era criado como uma cópia totalmente separada.
Slack.app
Electron
Photon
Arquivos específicos do Slack
Discord.app
Electron
Photon
Arquivos específicos do Discord
O framework do Electron e o Photon podiam ser idênticos byte a byte nos dois aplicativos, mas o macOS ainda armazenava outra cópia física para cada um. Dez aplicativos, portanto, significavam aproximadamente dez cópias de um pacote de aplicativo de 320 MB praticamente igual.
Essa arquitetura tinha uma característica que queríamos preservar: cada aplicativo era totalmente independente. Excluir um não afetava os outros, e os aplicativos instalados não dependiam da permanência do aplicativo para desktop do WebCatalog no sistema.
O que queríamos eliminar era a duplicação desnecessária por trás deles.
O APFS já tinha o recurso básico de que precisávamos
Os Macs modernos usam o sistema de arquivos APFS da Apple. O APFS oferece suporte à clonagem, um mecanismo de cópia na gravação que permite que dois arquivos independentes compartilhem os mesmos dados físicos até que um deles seja alterado.
Imagine copiar um arquivo de 300 MB. Com uma cópia normal, o macOS grava outros 300 MB no disco, de modo que os dois arquivos consomem cerca de 600 MB no total.
Com um clone APFS, o novo arquivo ainda parece e funciona como um arquivo completo de 300 MB, mas inicialmente aponta para os mesmos blocos físicos do original.
Arquivo A ──┐
├── blocos físicos compartilhados
Arquivo B ──┘
Se parte do Arquivo B mudar depois, o APFS gravará novos blocos apenas para os dados alterados. Tudo o que continuar idêntico poderá continuar compartilhando os blocos originais.
Arquivo A ───────── blocos compartilhados
Arquivo B ───────── blocos compartilhados
└──────── blocos alterados
Do ponto de vista do aplicativo, o Arquivo A e o Arquivo B são arquivos separados. Do ponto de vista do SSD, os dados idênticos só precisam ser armazenados uma vez.
Era quase exatamente o comportamento de que precisávamos.
Criando aplicativos a partir de uma base comum
O aplicativo para desktop do WebCatalog agora prepara uma base para cada combinação de versões do Electron e do Photon. O aplicativo-base do Photon contém as partes idênticas entre os aplicativos, incluindo o Electron, o Photon, a estrutura do framework e as assinaturas comuns.
Quando o aplicativo para desktop cria outro aplicativo usando as mesmas versões, ele não extrai nem monta mais outra cópia completa do zero. Em vez disso, cria um clone APFS do aplicativo-base do Photon e personaliza apenas as partes que precisam ser diferentes.
Entre elas estão o nome e o ícone do aplicativo, o identificador de pacote, as configurações, os nomes dos executáveis, o identificador da compilação e outros metadados específicos do aplicativo.
Como a maior parte do pacote permanece inalterada, o APFS continua compartilhando os blocos físicos que contêm o Electron e o Photon. Apenas a quantidade relativamente pequena de dados específicos do aplicativo consome espaço adicional.
Por que não compartilhar apenas o Electron?
Uma abordagem mais óbvia seria instalar o Electron uma vez e fazer todos os aplicativos apontarem para ele.
Consideramos essa possibilidade, mas ela mudaria fundamentalmente o modelo de confiabilidade. Se a instalação compartilhada do Electron desaparecesse, todos os aplicativos dependentes dela poderiam parar de funcionar. Um programa de limpeza de cache poderia removê-la, a desinstalação do aplicativo para desktop do WebCatalog poderia apagá-la, e mover ou restaurar um aplicativo individual ficaria mais complicado.
Também seria necessário acompanhar quais aplicativos instalados dependem de quais versões do ambiente de execução, para que as versões antigas pudessem ser removidas com segurança.
A assinatura de código do macOS traz outro problema. A verificação rigorosa de assinaturas rejeita links simbólicos que apontam para fora do pacote do aplicativo.
Os clones APFS nos dão a parte útil do compartilhamento sem introduzir essa dependência. Os aplicativos instalados podem compartilhar blocos físicos do disco e, ao mesmo tempo, continuar sendo pacotes completos e independentes.
Excluir o aplicativo-base do Photon não compromete os aplicativos criados a partir dele. Excluir um aplicativo instalado não afeta outro. O sistema de arquivos cuida do compartilhamento enquanto a arquitetura dos aplicativos permanece independente.
A assinatura de código quase anulou a economia
Clonar o aplicativo era apenas parte do problema. Os aplicativos macOS também precisam ter uma assinatura de código.
Nosso processo antigo de criação assinava novamente, de forma abrangente, cada pacote de aplicativo após a personalização. Para uma cópia normal, isso não é um problema. Com o armazenamento por cópia na gravação, porém, modificar um binário grande pode fazer o APFS alocar novos blocos físicos para ele.
Durante o desenvolvimento, medimos que assinar novamente o framework do Electron acrescentava cerca de 194 MB de armazenamento físico por aplicativo. Conseguimos evitar a cópia do Electron durante a criação do aplicativo, mas acabávamos duplicando boa parte dele de novo durante a assinatura.
Por isso, o processo de assinatura também teve que mudar.
O grande framework comum agora é assinado como parte do aplicativo-base do Photon. Quando o aplicativo para desktop clona essa base, evitamos modificar esses grandes binários compartilhados e assinamos novamente apenas as partes menores que realmente precisam ser diferentes entre os aplicativos.
Quando o aplicativo está pronto, executamos uma verificação rigorosa da assinatura no pacote finalizado para garantir que tudo continue válido.
Assim, preservamos tanto as garantias da assinatura de código do macOS quanto a economia de espaço proporcionada pelo APFS.
Quando pedir ao Node.js para clonar não resultou em uma clonagem
Houve outro problema inesperado: realizar a clonagem em si.
O Node.js disponibiliza opções de cópia destinadas a solicitar o comportamento de cópia na gravação, entre elas COPYFILE_FICLONE e COPYFILE_FICLONE_FORCE. Em teoria, pareciam ser exatamente as APIs de que precisávamos.
Em nossos testes com o Node.js 24, copiamos o mesmo aplicativo Electron de 288 MB usando vários métodos e medimos quanto espaço físico adicional em disco cada operação consumiu:
fs.cpSync +288 MB
fs.cpSync + COPYFILE_FICLONE +288 MB
fs.cpSync + COPYFILE_FICLONE_FORCE +288 MB
/bin/cp -c -R ~0 MB
Nos testes, os dois modos de clonagem do Node.js ainda produziram uma cópia física completa, e nem mesmo a variante FORCE informou um erro quando a clonagem esperada não aconteceu.
A operação nativa cp -c do macOS funcionou como esperado. Por isso, o aplicativo para desktop do WebCatalog usa esse mecanismo diretamente.
Isso também nos lembrou de que otimizações do sistema de arquivos devem ser verificadas por meio de medições no próprio sistema de arquivos. Chamar uma API que solicita cópia na gravação não significa necessariamente que os arquivos resultantes compartilhem armazenamento físico.
Garantindo que uma falha na otimização não impeça a instalação
Economizar espaço em disco é uma otimização. Instalar um aplicativo com sucesso é essencial.
Projetamos o novo processo para que uma falha na clonagem não impeça a instalação do aplicativo. Se a preparação do aplicativo-base do Photon falhar, se a base em cache estiver danificada, se a clonagem falhar ou se a verificação da assinatura não passar, o aplicativo para desktop recorrerá ao processo anterior, com extração e assinatura completas.
Na pior hipótese, portanto, o uso do disco será o mesmo de antes, e não haverá uma falha na instalação.
Também tivemos que levar em conta a simultaneidade. Um aplicativo-base do Photon é preparado primeiro em um diretório temporário e só é movido para o local definitivo quando está completo. Assim, duas criações de aplicativos realizadas ao mesmo tempo não correm o risco de encontrar uma base parcialmente pronta.
As bases antigas também podem ser removidas com segurança. Um clone APFS instalado não depende da existência contínua da base original. Se a base for excluída, o clone manterá os blocos físicos que ainda utiliza.
Isso funciona no APFS, o sistema de arquivos padrão de todos os Macs modernos. Se seus aplicativos estiverem em um disco que não oferece suporte à clonagem, como uma unidade externa HFS+ ou exFAT, o aplicativo para desktop do WebCatalog recorrerá a uma cópia normal. Assim, os aplicativos continuarão funcionando como antes, mas sem economizar espaço. Por enquanto, nada muda no Windows e no Linux.
Tamanho lógico e tamanho físico não são a mesma coisa
Um efeito colateral que pode causar alguma confusão é que o Finder talvez ainda indique que cada aplicativo ocupa cerca de 320 MB.
Esse número representa o tamanho lógico do aplicativo. Ele realmente contém cerca de 320 MB em arquivos e, se esses arquivos fossem copiados para outro lugar sem clonagem, essa seria aproximadamente a quantidade de dados que precisaria ser gravada.
O que mudou foi o tamanho físico, ou seja, quantos blocos exclusivos esses arquivos realmente ocupam no disco.
Se dois aplicativos contiverem o mesmo framework de 300 MB e o APFS permitir que compartilhem os mesmos blocos subjacentes, cada aplicativo poderá conter logicamente 300 MB, enquanto o segundo acrescentará pouquíssimos dados físicos.
A janela Obter Informações do Finder e ferramentas como du não mostram necessariamente esse compartilhamento. A economia fica mais evidente na quantidade de espaço livre que realmente resta no disco.
Verificamos isso com sete aplicativos reais: Discord, Facebook, Instagram, Messenger, TikTok e dois aplicativos personalizados. Criados dessa forma, eles economizaram cerca de 1,9 GB de espaço em disco em comparação com o processo antigo.
Também verificamos os deslocamentos físicos subjacentes no disco e confirmamos que os aplicativos compartilhavam seus dados comuns do Electron e do Photon no nível dos blocos. Um aplicativo criado pelo processo antigo não compartilhava nenhum desses blocos, o que nos deu uma comparação útil.
O resultado
Para quem cria apenas um aplicativo com o aplicativo para desktop do WebCatalog, a diferença é pequena. Na verdade, o primeiro aplicativo usa um pouco mais de espaço em disco do que antes, porque o aplicativo para desktop também mantém o aplicativo-base do Photon usado para criar os clones seguintes.
Depois disso, o benefício cresce rapidamente.
Antes
1 aplicativo ~320 MB
10 aplicativos >3 GB
Com a clonagem APFS:
Depois
1 aplicativo ~340 MB
10 aplicativos ~360 MB
Depois que a base inicial é criada, cada aplicativo adicional normalmente acrescenta apenas 1–2 MB ao uso físico do disco.
O importante é que conseguimos isso sem introduzir uma dependência de um ambiente de execução compartilhado. Cada aplicativo continua sendo um aplicativo macOS normal e autocontido, enquanto o APFS armazena os dados idênticos do Electron e do Photon apenas uma vez. Com cerca de dez aplicativos instalados, isso pode reduzir o uso real do disco em mais de oito vezes.
Esse recurso está disponível na versão mais recente do aplicativo para desktop do WebCatalog no macOS. Não é preciso ativar nada: os novos aplicativos o utilizam automaticamente, e os aplicativos já instalados passam a ocupar menos espaço na próxima atualização.