time de inicialização do aplicativo

Artigo
08/25/2010

A quantidade de time é necessário para iniciar um aplicativo do WPF pode variar muito. Este tópico descreve diversas técnicas para reduzir o time de inicialização perceptível e real de um aplicativo Windows Presentation Foundation (WPF).

Noções básicas sobre inicialização COLD e inicialização quente

Inicialização a frio ocorre quando seu aplicativo é iniciado pela primeira vez após a reinicialização do sistema ou ao iniciar seu aplicativo, fechar-a e, em seguida, iniciá-lo novamente após um longo período de time. Quando um aplicativo for iniciado, se as páginas necessárias (código, dados estático, registro, etc.) não estão presentes na lista de em espera do Gerenciador de memória do Windows, ocorrem falhas de página. É necessário o acesso de disco para que as páginas de memória.

Inicialização a quente ocorre quando a maioria das páginas dos componentes principais do common linguagem tempo de execução (CLR) já é carregada na memória, o que economiza time de acesso ao disco dispendioso. É por isso que um aplicativo gerenciado é iniciado mais rapidamente quando ele é executado uma segunda vez.

Implementar uma tela inicial de abertura

Nos casos em que há significativa, inevitáveis atraso entre a iniciar um aplicativo e a exibição da interface do usuário primeiro, otimizar o time de inicialização percebida por meio de um tela inicial de abertura. Essa abordagem exibe uma imagem quase que imediatamente depois que o usuário inicia o aplicativo. Quando o aplicativo está pronto para exibir sua interface do usuário primeiro, surge tela inicial de abertura. A partir de .NET Framework 3.5 SP1, você pode usar o SplashScreen classe para implementar uma tela inicial de abertura. Para obter mais informações, consulte Como: Adicionar uma tela inicial de abertura para um aplicativo do WPF.

Você também pode implementar sua própria tela inicial de abertura usando elementos gráficos Win32 nativo. Exibir sua implementação antes do Run método é chamado.

Analisar o código de inicialização

Determine o motivo de uma inicialização a frio lenta. E/s de disco podem ser responsável, mas isso não é sempre o caso. Em geral, você deve minimizar o uso de recursos externos, sistema autônomo rede, serviços da Web ou disco.

Antes de testar, verifique se não há outros aplicativos ou serviços de execução usar código gerenciado ou código do WPF.

Inicie o seu aplicativo WPF imediatamente após uma reinicialização e determinar quanto tempo demora para exibir. Se todos os lançamentos subseqüentes do seu aplicativo (inicialização a quente) são muito mais rápidos, seu problema de inicialização a frio provavelmente causado por E/S.

Se seu aplicativo do frio problema de inicialização não está relacionado a E/S, é provável que seu aplicativo executa algumas inicialização longa ou computação, aguarda algum evento concluir, ou requer muita compilação JIT na inicialização. As seções a seguir descrevem algumas dessas situações mais detalhadamente.

Otimizar o carregamento de módulo

Use ferramentas sistema autônomo processo Explorer (procexp.exe) e tlist.exe para determinar quais módulos do seu aplicativo é carregado. O comando Tlist <pid> mostra todos os módulos carregados por um processo.

Por exemplo, se você não estiver se conectando a Web e ver que sistema.Web.dll é carregada e, em seguida, há um módulo em seu aplicativo que faz referência neste assembly. Verifique se a referência é necessária.

Se seu aplicativo tiver vários módulos, mesclá-las em um único módulo. Essa abordagem requer menos sobrecarga de carregamento de assembly CLR. Assemblies menos também significam que o CLR mantém o estado da menor.

Adiar a operações de inicialização

Considere a possibilidade de adiar o código de inicialização até que depois é processada na janela principal do aplicativo.

Esteja ciente de que a inicialização pode ser executada dentro de um construtor de classe e se o código de inicialização faz referência a outras classes, ele poderá causar um efeito em cascata no qual vários construtores de classe são executados.

Evitar a configuração de aplicativo

Considere a possibilidade de evitar a configuração do aplicativo. Por exemplo, se um aplicativo tem requisitos de configuração simples e tem objetivos de time de inicialização estrito, entradas do registro ou um arquivo INI simples pode ser uma alternativa de inicialização mais rápida.

Utilizar o GAC

Se um assembly não estiver instalado no GAC (cache de assemblies global), há atrasos causados pela verificação de hash de assemblies de nome forte e pela validação de imagem NGen se um nativo de imagem para esse assembly está disponível no computador. Verificação de nome forte de todos os assemblies instalados no GAC é ignorada. Para obter mais informações, consulte Global ferramenta cache assembly (Gacutil.exe) .

Use NGen.exe

Considere a possibilidade de usar o nativo imagem gerador (NGen.exe) em seu aplicativo. Usar NGen.exe significa negociar o consumo da CPU para obter acesso ao disco porque o nativo imagem gerada pelo NGen.exe provavelmente será maior do que a imagem da MSIL.

Para melhorar o time de inicialização a quente, você sempre deve usar NGen.exe em seu aplicativo, pois isso evita o custo de CPU de compilação JIT o código do aplicativo.

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

Ter módulos NGen e JIT pode ter o efeito pior. Isso ocorre porque mscorjit.dll deve ser carregado e quando o compilador JIT funciona em seu código, número de páginas nas imagens NGen deve ser acessado quando o compilador JIT lê metadados os assemblies.

NGen e do ClickOnce

A maneira como você planeja implantar seu aplicativo também pode fazer uma diferença no time de carregamento. ClickOnce implantação do aplicativo não oferece suporte a NGen. Se você decidir usar NGen.exe para seu aplicativo, você precisará usar outro mecanismo de implantação, sistema autônomo o Windows Installer.

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

Rebasing e colisões de endereço DLL

Se você usar NGen.exe, esteja ciente de que a alteração da base pode ocorrer quando o nativo imagens forem carregadas na memória. Se uma DLL não é carregada em seu endereço básico preferido porque esse intervalo de endereços já está alocado, o carregador do Windows será carregada em outro endereço, que pode ser um time-consumo de operação.

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

Para obter mais informações sobre como conjunto o endereço básico, consulte Nativo Gerador de Imagem (Ngen.exe).

Otimizar o Authenticode

Verificação Authenticode aumenta o time de inicialização. Assemblies assinados por Authenticode precisa ser verificada com a autoridade de certificação (CA). Essa verificação pode ser demorada, porque pode exigir conectando à rede várias vezes para fazer o baixar de listas de certificados revogados corrente. Ela também torna-se de que existe uma cadeia completa de certificados válido no caminho para uma raiz confiável. Isso pode converter vários segundos de atraso enquanto o assembly está sendo carregado.

Experimente instalar Certificado de Autoridade de Certificação de Autoridade de Certificação de Autoridade de Certificação da autoridade de certificação no computador cliente ou evitar o uso de Authenticode quando for possível. Se você souber que seu aplicativo não precisa a evidência do publicador, não é necessário pagar o custo de verificação de assinatura.

A partir de .NET Framework 3,5, há uma opção de configuração que permite a verificação do Authenticode a ser 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 < generatePublisherEvidence > Elemento.

Comparar desempenho no Windows Vista

O Gerenciador de memória no Windows Vista tem uma tecnologia chamada SuperFetch. SuperFetch analisa os padrões de uso de memória ao longo do time para determinar o conteúdo de memória ideal para um usuário específico. Ele funciona continuamente para manter esse conteúdo em todas as ocasiões.

Essa abordagem é diferente de pre-fetch técnica usada no Windows XP pré-carrega dados na memória sem analisar padrões de uso. Com o passar do time, se o usuário utiliza seu aplicativo do WPF com freqüência no Windows Vista, o time de inicialização a frio do seu aplicativo poderá melhorar.

Use com eficiência AppDomains

Se possível, carregar assemblies em uma área código de domínio neutro para certificar-se de que a imagem nativa, se houver um, é usada em todos os AppDomains criados no aplicativo.

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

Use o atributo NeutralResourcesLanguage

Use o NeutralResourcesLanguageAttribute Para especificar a cultura neutra para a ResourceManager. Essa abordagem evita pesquisas assembly sem êxito.

Usar a classe BinaryFormatter para serialização

Se você deve usar a serialização, use o BinaryFormatter classe em vez da XmlSerializer classe. The BinaryFormatter classe é implementada na BCL (Base biblioteca de classes) no conjunto de módulos (assembly) mscorlib.dll. The XmlSerializer é implementada no assembly sistema.XML.dll, que pode ser uma DLL adicional para carregar.

Se você precisar usar o XmlSerializer classe, você pode obter um melhor desempenho se você gerar previamente o assembly de serialização.

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

Se o seu aplicativo utiliza ClickOnce, para evitar o acesso à rede na inicialização, configurando ClickOnce Para verificar o site de implantação para atualizações depois que o aplicativo for iniciado.

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

Configurar o serviço PresentationFontCache para iniciar automaticamente

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

conjunto por programação vinculação de dados

Em vez de usar XAML para conjunto o DataContext declarativamente para a janela principal, considere configuração programaticamente em que o OnActivated método.