Tempo de inicialização do aplicativo
A quantidade de tempo é necessário para iniciar um aplicativo do WPF pode variar muito. Este tópico descreve várias técnicas para reduzir o tempo de inicialização de percepção e real para um aplicativo de Windows Presentation Foundation (WPF).
Noções básicas sobre a inicialização a frio e a inicialização a quente
Inicialização a frio ocorre quando seu aplicativo é iniciado pela primeira vez após a reinicialização do sistema, ou quando você inicia seu aplicativo, fechá-la e, em seguida, iniciá-lo 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 estão presentes na lista de espera do Gerenciador de memória do Windows, ocorrem falhas de página. Acesso ao disco é necessário para colocar as páginas na memória.
Inicialização a quente ocorre quando a maioria das páginas para os componentes principais do common language runtime (CLR) já está carregadas na memória, o que economiza tempo de acesso de disco dispendioso. É por isso que um aplicativo gerenciado é iniciado mais rapidamente quando ele é executado uma segunda vez.
Implementar uma tela de abertura
Em casos onde há uma significativa inevitáveis atraso entre a iniciar um aplicativo e exibindo a primeira interface de usuário, otimizar o tempo de inicialização percebido usando um a tela de splash. Essa abordagem exibe uma imagem quase imediatamente depois que o usuário inicia o aplicativo. Quando o aplicativo está pronto para exibir sua interface do usuário primeiro, surge a tela inicial. A partir de .NET Framework 3.5 SP1, você pode usar o SplashScreen classe para implementar uma tela de abertura. For more information, see Como: Adicionar uma tela de abertura para um aplicativo WPF.
Você também pode implementar sua própria tela de abertura usando gráficos nativos do Win32. Sua implementação antes de exibir o Run método é chamado.
Analisar o código de inicialização
Determine o motivo para uma inicialização a frio lenta. E/S de disco pode ser responsável, mas isso não é sempre o caso. Em geral, você deve minimizar o uso de recursos externos, como, por exemplo, rede, serviços da Web ou disco.
Antes de testar, verifique se não há outros aplicativos ou serviços de execução usem código gerenciado ou código do WPF.
Inicie o aplicativo WPF imediatamente após uma reinicialização e determinar quanto tempo demora para exibir. Se todas as inicializações subseqüentes do seu aplicativo (inicialização a quente) são muito mais rápidas, seu problema de inicialização a frio é provavelmente causado por i/O.
Se seu aplicativo do cold problema de inicialização não está relacionado a i/O, é provável que seu aplicativo executa algumas inicialização longa ou computação, aguarda algum evento concluir, ou requer muita compilação em JIT durante a inicialização. As seções a seguir descrevem algumas dessas situações mais detalhadamente.
Otimizar o carregamento de módulo
Use ferramentas como, por exemplo, o Process Explorer (procexp. exe) e tlist. exe para determinar quais módulos do seu aplicativo é carregado. O comando Tlist <pid> mostra todos os módulos que são carregados por um processo.
Por exemplo, se você não estiver se conectando à Web e você verá que System.Web.dll está carregado e houver um módulo em seu aplicativo que referencia a este assembly. Verifique para certificar-se de que 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 do CLR. Assemblies menos também significam que o CLR mantém menos estado.
Adiar a operações de inicialização
Considere a possibilidade de adiar o código de inicialização até após a janela principal do aplicativo é processada.
Lembre-se 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, ela pode 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 tempo de inicialização estrito, entradas de registro ou um simples arquivo INI pode ser uma alternativa de inicialização mais rápida.
Utilizar o GAC
Se um assembly não estiver instalado no Global Assembly Cache (GAC), há atrasos causados pela verificação de hash de assemblies de nome forte e pela validação de imagem Ngen se uma imagem nativa para o assembly está disponível no computador. A verificação de nome forte é ignorada para todos os assemblies instalados no GAC. For more information, see Gacutil. exe (ferramenta de Cache de Assembly Global).
Usar o NGen. exe
Considere usar o Native Image Generator (NGen. exe) em seu aplicativo. Usar o NGen. exe significa negociar o consumo de CPU para obter acesso ao disco porque a imagem nativa gerada pelo NGen. exe é provável que seja maior do que a imagem MSIL.
Para melhorar o tempo de inicialização a quente, você sempre deve usar NGen. exe em seu aplicativo, porque isso evita o custo de CPU de compilação em JIT o código do aplicativo.
Em alguns cenários de inicialização a frio, usar o NGen. exe também pode ser útil. Isso ocorre porque o compilador JIT (mscorjit. dll) não tem de ser carregado.
Ter módulos Ngen e o JIT pode ter o efeito de pior. Isso ocorre porque mscorjit. dll deve ser carregado e quando o compilador JIT funciona no seu código, muitas páginas nas imagens Ngen devem ser acessadas quando o compilador JIT lê os assemblies metadados.
NGen e ClickOnce
A maneira como você planeja implantar seu aplicativo também pode fazer uma diferença no tempo de carregamento. ClickOnceimplantação de aplicativo não oferece suporte a Ngen. Se você decidir usar NGen. exe para seu aplicativo, você terá que usar outro mecanismo de implantação, como, por exemplo, o Windows Installer.
For more information, see NGen (Native Image Generator).
Rebasing e colisões de endereço DLL
Se você usar o NGen. exe, lembre-se de que a alteração da base pode ocorrer quando as imagens nativas são carregadas na memória. Se uma DLL não estiver carregada em seu endereço base preferido, pois esse intervalo de endereços já está alocado, o carregador do Windows irá carregá-lo em outro endereço, que pode ser uma operação demorada.
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 foi alterado 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 (Native Image Generator).
Otimizar o Authenticode
Verificação Authenticode aumenta o tempo de inicialização. Os assemblies assinados por Authenticode precisam ser verificada com a autoridade de certificação (CA). Essa verificação pode ser demorada, porque requer a se conectar à rede várias vezes para fazer o download de listas de certificados revogados atual. Ele também certifica-se de que há uma cadeia completa de certificados válidos no caminho para uma raiz confiável. Isso pode significar vários segundos de atraso enquanto o assembly está sendo carregado.
Considere a possibilidade de instalar o certificado da CA no computador cliente ou evite usar Authenticode, quando for possível. Se você souber que seu aplicativo não precisa a evidência do publisher, você não precisará 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 de Authenticode ser ignorada. Para fazer isso, adicione a seguinte configuração no arquivo app.exe.config:
<configuration>
<runtime>
<generatePublisherEvidence enabled="false"/>
</runtime>
</configuration>
For more information, see <generatePublisherEvidence> Elemento.
Comparar o 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 tempo para determinar o conteúdo de memória ideal para um usuário específico. Ele trabalha continuamente para manter o conteúdo em todas as ocasiões.
Essa abordagem difere da técnica pre-fetch usada no Windows XP, pré-carrega os dados na memória sem analisar padrões de uso. Ao longo do tempo, se o usuário utiliza o seu aplicativo do WPF com freqüência no Windows Vista, poderá melhorar o tempo de inicialização a frio do seu aplicativo.
Usar com eficiência de AppDomains
Se possível, carrega assemblies em uma área de código de domínio neutro para certificar-se de que a imagem nativa, se houver, é usada em todos os AppDomains criados no aplicativo.
Para melhor desempenho, impor a comunicação eficiente de domínio cruzado, reduzindo as chamadas entre domínios. Quando possível, use chamadas sem argumentos, ou com os argumentos de tipo primitivo.
Use o atributo NeutralResourcesLanguage
Use o NeutralResourcesLanguageAttribute para especificar a cultura neutra para a ResourceManager. Essa abordagem evita a pesquisas de assembly sem êxito.
Usar a classe BinaryFormatter para serialização
Se você deve usar a serialização, use o BinaryFormatter de classe em vez da XmlSerializer classe. O BinaryFormatter classe é implementada na biblioteca BCL (Base Class) no assembly mscorlib. dll. O XmlSerializer é implementado no assembly System.Xml.dll, que pode ser um 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 ClickOnce para verificar se há atualizações após a inicialização
Se seu aplicativo usa ClickOnce, evitar o acesso à rede na inicialização, configurando ClickOnce para verificar o site de implantação para atualizações após o aplicativo é iniciado.
Se você usar o modelo de aplicativo (XBAP) de navegador XAML, tenha em mente que ClickOnce verifica o site de implantação para atualizações, mesmo se XBAP já está na ClickOnce cache. For more information, see <>>Implantação e segurança do ClickOnce.
Configurar o serviço de PresentationFontCache para iniciar automaticamente
O primeiro aplicativo do WPF para executar após uma reinicialização é o serviço de PresentationFontCache. O serviço armazena em cache as fontes do sistema, melhora o acesso de fonte e melhora o desempenho geral. Há uma sobrecarga na inicialização do serviço e, em alguns ambientes controlados, considere a possibilidade de configurar o serviço para iniciar automaticamente quando o sistema for reinicializado.
Definir dados programaticamente de vinculação.
Em vez de usar o XAML para definir o DataContext declarativamente para a janela principal, considere defini-la programaticamente na OnActivated método.
Consulte também
Tarefas
Como: Adicionar uma tela de abertura para um aplicativo WPF