Compartilhar via

Hora de inicialização do aplicativo

A quantidade de tempo necessária para o início de um aplicativo WPF pode variar bastante. Este tópico descreve várias técnicas para reduzir o tempo de inicialização percebido e real para um aplicativo WPF (Windows Presentation Foundation).

Noções básicas sobre inicialização a frio e inicialização morna

A inicialização a frio ocorre quando seu aplicativo é iniciado pela primeira vez após uma reinicialização do sistema ou quando você inicia o aplicativo, fecha-o e, em seguida, inicia-o novamente após um longo período de tempo. Quando um aplicativo é iniciado, se as páginas necessárias (código, dados estáticos, registro etc) não estiverem presentes na lista de espera do gerenciador de memória do Windows, ocorrerão falhas de página. O acesso ao disco é necessário para colocar as páginas na memória.

A inicialização morna ocorre quando a maioria das páginas dos principais componentes do CLR (Common Language Runtime) já está carregada na memória, o que economiza tempo de acesso em disco caro. É por isso que um aplicativo gerenciado começa mais rápido quando é executado uma segunda vez.

Implementar uma tela inicial

Nos casos em que houver um atraso significativo e inevitável entre iniciar um aplicativo e exibir a primeira interface do usuário, otimize o tempo de inicialização percebido usando uma tela inicial. Essa abordagem exibe uma imagem quase imediatamente após o usuário iniciar o aplicativo. Quando o aplicativo estiver pronto para exibir sua primeira interface do usuário, a tela inicial desaparecerá. A partir do .NET Framework 3.5 SP1, você pode usar a SplashScreen classe para implementar uma tela inicial. Para obter mais informações, consulte Adicionar uma tela inicial a um aplicativo WPF.

Você também pode implementar sua própria tela inicial usando elementos gráficos nativos do Win32. Exiba sua implementação antes que o Run método seja chamado.

Analisar o código de inicialização

Determine o motivo de uma inicialização lenta e fria. A E/S do disco pode ser responsável, mas nem sempre é o caso. Em geral, você deve minimizar o uso de recursos externos, como rede, serviços Web ou disco.

Antes de testar, verifique se nenhum outro aplicativo ou serviço em execução usa código gerenciado ou código WPF.

Inicie seu aplicativo WPF imediatamente após uma reinicialização e determine quanto tempo leva para ser exibido. Se todos os lançamentos subsequentes do aplicativo (inicialização morna) forem muito mais rápidos, o problema de inicialização a frio provavelmente será causado por E/S.

Se o problema de inicialização a frio do aplicativo não estiver relacionado à E/S, é provável que seu aplicativo execute alguma inicialização ou computação demorada, aguarde a conclusão de algum evento ou exija muita compilação JIT na inicialização. As seções a seguir descrevem algumas dessas situações com mais detalhes.

Otimizar o carregamento do módulo

Use ferramentas como o Gerenciador de Processos (Procexp.exe) e Tlist.exe para determinar quais módulos seu aplicativo carrega. O comando Tlist <pid> mostra todos os módulos carregados por um processo.

Por exemplo, se você não estiver se conectando à Web e perceber que System.Web.dll está carregado, há um módulo em seu aplicativo que faz referência a esse conjunto de componentes. Verifique se a referência é necessária.

Se o aplicativo tiver vários módulos, mescle-os em um único módulo. Essa abordagem requer menos sobrecarga no carregamento de assembly CLR. Menos assemblies também significam que o CLR mantém menos estado.

Adiar operações de inicialização

Considere adiar o código de inicialização até que a janela principal do aplicativo seja renderizada.

Lembre-se de que a inicialização pode ser executada dentro de um construtor de classe e, se o código de inicialização fizer referência a outras classes, poderá causar um efeito em cascata no qual muitos construtores de classe são executados.

Evitar a configuração do aplicativo

Considere evitar a configuração do aplicativo. Por exemplo, se um aplicativo tiver requisitos de configuração simples e tiver metas de tempo de inicialização estritas, as entradas do Registro ou um arquivo INI simples poderão ser uma alternativa de inicialização mais rápida.

Utilizar o GAC

Se um assembly não estiver instalado no Cache de Assemblies Globais (GAC), haverá atrasos causados pela verificação do hash dos assemblies com nome forte e pela validação da imagem Ngen, caso uma imagem nativa desse assembly esteja disponível no computador. A verificação de nome forte é ignorada para todos os assemblies instalados no GAC. Para obter mais informações, consulte Gacutil.exe (ferramenta Global Assembly Cache).

Usar Ngen.exe

Considere usar o Gerador de Imagem Nativa (Ngen.exe) em seu aplicativo. Usar Ngen.exe significa negociar o consumo de CPU para obter mais acesso ao disco porque a imagem nativa gerada pelo Ngen.exe provavelmente será maior que a imagem MSIL.

Para melhorar o tempo de inicialização morno, você sempre deve usar Ngen.exe em seu aplicativo, pois isso evita o custo da CPU da compilação JIT do código do aplicativo.

Em alguns cenários de inicialização a frio, usar Ngen.exe também pode ser útil. Isso ocorre porque o compilador JIT (mscorjit.dll) não precisa ser carregado.

Ter módulos Ngen e JIT pode ter o pior efeito. Isso ocorre porque mscorjit.dll precisa ser carregado, e, quando o compilador JIT atua sobre seu código, muitas páginas nas imagens Ngen devem ser acessadas quando o compilador JIT lê os metadados dos conjuntos.

Ngen e ClickOnce

A maneira como você planeja implantar seu aplicativo também pode fazer a diferença no tempo de carga. A implantação do aplicativo ClickOnce não dá suporte ao Ngen. Se você decidir usar Ngen.exe para seu aplicativo, precisará usar outro mecanismo de implantação, como o Windows Installer.

Para obter mais informações, consulte Ngen.exe (Gerador de Imagens Nativas).

Rebasing e colisões de endereços de memória DLL

Se você usar Ngen.exe, lembre-se de que a rebasing pode ocorrer quando as imagens nativas são carregadas na memória. Se uma DLL não for carregada em seu endereço base preferencial porque esse intervalo de endereços já está alocado, o carregador do Windows o carregará em outro endereço, o que pode ser uma operação demorada.

Você pode usar a ferramenta Despejo de Endereço Virtual (Vadump.exe) para verificar se há módulos em que todas as páginas são privadas. Se esse for o caso, o módulo pode ter sido realocado para um endereço diferente. Portanto, suas páginas não podem ser compartilhadas.

Para obter mais informações sobre como definir o endereço base, consulte Ngen.exe (Gerador de Imagem Nativa).

Otimizar Authenticode

A verificação de Authenticode aumenta o tempo de inicialização. Assemblies assinados por Authenticode precisam ser verificados com a autoridade de certificação (CA). Essa verificação pode ser demorada, pois pode exigir a conexão com a rede várias vezes para baixar as listas de revogação de certificados atuais. Ele também garante que haja uma cadeia completa de certificados válidos em direção a uma raiz confiável. Isso pode se traduzir em vários segundos de atraso enquanto o assembly está sendo carregado.

Considere instalar o certificado de autoridade de certificação no computador cliente ou evitar o uso do Authenticode quando for possível. Se você souber que seu aplicativo não precisa da evidência do editor, você não precisa pagar o custo da verificação de assinatura.

A partir do .NET Framework 3.5, há uma opção de configuração que permite que a verificação do Authenticode seja ignorada. Para fazer isso, adicione a seguinte configuração ao arquivo app.exe.config:

<configuration>
    <runtime>
        <generatePublisherEvidence enabled="false"/>
    </runtime>
</configuration>

Para obter mais informações, consulte <o elemento generatePublisherEvidence>.

Comparar desempenho no Windows Vista

O gerenciador de memória no Windows Vista tem uma tecnologia chamada SuperFetch. O SuperFetch analisa padrões de uso de memória ao longo do tempo para determinar o conteúdo de memória ideal para um usuário específico. Ele opera continuamente para manter esse conteúdo em todos os momentos.

Essa abordagem difere da técnica de pré-busca usada no Windows XP, que pré-carrega dados na memória sem analisar padrões de uso. Com o tempo, se o usuário usar seu aplicativo WPF com frequência no Windows Vista, o tempo de inicialização frio do aplicativo poderá melhorar.

Usar AppDomains com eficiência

Se possível, carregue assemblies em uma área de código neutra de domínio para garantir que a imagem nativa, se existir, seja usada em todos os domínios de aplicativo criados no aplicativo.

Para obter o melhor desempenho, imponha uma comunicação entre domínios eficiente reduzindo as chamadas entre domínios. Quando possível, use chamadas sem argumentos ou com argumentos de tipo primitivo.

Usar o atributo NeutralResourcesLanguage

Use a NeutralResourcesLanguageAttribute para especificar a cultura neutra para o ResourceManager. Essa abordagem evita consultas de montagem malsucedidas.

Usar gerador de serializador XML

Se você usar a XmlSerializer classe, poderá obter melhor desempenho se pré-gerar o assembly de serialização usando a ferramenta Gerador de Serializador XML (Sgen.exe).

Configurar o ClickOnce para verificar se há atualizações após a inicialização

Se o aplicativo usar o ClickOnce, evite o acesso à rede na inicialização configurando o ClickOnce para verificar se o site de implantação busca atualizações após o início do aplicativo.

Se você usar o modelo XBAP (aplicativo do navegador XAML), tenha em mente que o ClickOnce verifica o site de implantação para obter atualizações mesmo se o XBAP já estiver no cache ClickOnce. Para obter mais informações, consulte Segurança e Implantação do ClickOnce.

Aviso

Os XBAPs exigem que navegadores herdados operem, como o Internet Explorer e versões antigas do Firefox. Esses navegadores mais antigos geralmente não têm suporte no Windows 10 e no Windows 11. Os navegadores modernos não dão mais suporte à tecnologia necessária para aplicativos XBAP devido a riscos de segurança. Plug-ins que habilitam XBAPs não têm mais suporte. Para obter mais informações, consulte Perguntas frequentes sobre oXBAP (aplicativos hospedados por navegador) do WPF.

Configurar o Serviço PresentationFontCache para iniciar automaticamente

O primeiro aplicativo WPF a ser executado após uma reinicialização é o serviço PresentationFontCache. O serviço armazena em cache as fontes do sistema, melhora o acesso à fonte e melhora o desempenho geral. Há uma sobrecarga ao iniciar o serviço e, em alguns ambientes controlados, considere configurar o serviço para iniciar automaticamente quando o sistema for reinicializado.

Definir a vinculação de dados de forma programática

Em vez de usar XAML para definir a DataContext declarativamente para a janela principal, considere defini-la programaticamente no OnActivated método.

Consulte também

  • Last updated on