Tiempo de inicio de la aplicación

La cantidad de tiempo necesaria para que se inicie una aplicación WPF puede variar considerablemente. En este tema se describen varias técnicas para reducir el tiempo de inicio percibido y real de una aplicación de Windows Presentation Foundation (WPF).

Descripción del inicio en frío y el inicio en caliente

El inicio en frío se produce cuando la aplicación se inicia por primera vez después de un reinicio del sistema, o al iniciar la aplicación, cerrarla y, a continuación, iniciarla de nuevo después de un largo período de tiempo. Cuando se inicia una aplicación, si las páginas necesarias (código, datos estáticos, registro, etc.) no están presentes en la lista en espera del administrador de memoria de Windows, se producen errores de página. El acceso al disco es necesario para traer las páginas a la memoria.

El inicio cálido se produce cuando la mayoría de las páginas de los componentes principales del Entorno de Ejecución de Lenguaje Común (CLR) ya están cargadas en memoria, lo que ahorra tiempo de acceso costoso al disco. Es por eso que una aplicación administrada se inicia más rápido cuando se ejecuta una segunda vez.

Implementar una pantalla de bienvenida

En los casos en los que hay un retraso significativo e inevitable entre iniciar una aplicación y mostrar la primera interfaz de usuario, optimice el tiempo de inicio percibido mediante una pantalla de presentación. Este enfoque muestra una imagen casi inmediatamente después de que el usuario inicie la aplicación. Cuando la aplicación esté lista para mostrar su primera interfaz de usuario, la pantalla de presentación se atenua. A partir de .NET Framework 3.5 SP1, puede usar la SplashScreen clase para implementar una pantalla de presentación. Para obtener más información, vea Agregar una pantalla de presentación a una aplicación WPF.

También puedes implementar tu propia pantalla de presentación mediante gráficos nativos de Win32. Muestre su implementación antes de que se llame al método Run.

Análisis del código de inicio

Determine la razón de un arranque en frío lento. La E/S de disco puede ser responsable, pero no siempre ocurre así. En general, debe minimizar el uso de recursos externos, como la red, los servicios web o el disco.

Antes de probarlo, compruebe que ninguna otra aplicación o servicio en ejecución use código administrado o código WPF.

Inicie la aplicación WPF inmediatamente después de un reinicio y determine cuánto tiempo se tarda en mostrarse. Si todos los inicios posteriores de tu aplicación (inicio en caliente) son mucho más rápidos, lo más probable es que el problema de inicio en frío se deba a entrada/salida.

Si el problema de inicio en frío de la aplicación no está relacionado con la E/S, es probable que la aplicación realice una larga inicialización o cálculo, espere a que se complete algún evento o requiera una gran cantidad de compilación JIT en el inicio. En las secciones siguientes se describen algunas de estas situaciones con más detalle.

Optimización de la carga de módulos

Use herramientas como el Explorador de procesos (Procexp.exe) y Tlist.exe para determinar qué módulos carga la aplicación. El comando Tlist <pid> muestra todos los módulos cargados por un proceso.

Por ejemplo, si no se conecta a Internet y ve que System.Web.dll está cargado, significa que hay un módulo en su aplicación que hace referencia a este ensamblado. Compruebe que la referencia es necesaria.

Si la aplicación tiene varios módulos, comúltelos en un único módulo. Este enfoque requiere menos sobrecarga al cargar ensamblados CLR. Menos ensamblajes también significan que el CLR mantiene menos información de estado.

Aplazar las operaciones de inicialización

Considere la posibilidad de posponer el código de inicialización hasta que se represente la ventana principal de la aplicación.

Tenga en cuenta que la inicialización se puede realizar dentro de un constructor de clase y, si el código de inicialización hace referencia a otras clases, puede provocar un efecto en cascada en el que se ejecutan muchos constructores de clase.

Evitar la configuración de la aplicación

Considere la posibilidad de evitar la configuración de la aplicación. Por ejemplo, si una aplicación tiene requisitos de configuración simples y tiene objetivos estrictos de tiempo de inicio, las entradas del Registro o un archivo INI simple pueden ser una alternativa de inicio más rápida.

Utilice la GAC

Si un ensamblado no está instalado en la caché global de ensamblados (GAC), hay demoras causadas por la verificación de hash de ensamblados con nombre seguro y por la validación de la imagen Ngen si hay disponible una imagen nativa para ese ensamblado en el equipo. La comprobación de nombres seguros se omite para todos los ensamblados instalados en la GAC. Para obtener más información, consulte Gacutil.exe (Herramienta de caché global de ensamblado).

Uso de Ngen.exe

Considere la posibilidad de usar el generador de imágenes nativas (Ngen.exe) en la aplicación. El uso de Ngen.exe significa intercambiar el consumo de CPU a cambio de más acceso al disco porque es probable que la imagen nativa generada por Ngen.exe sea mayor que la imagen de MSIL.

Para mejorar el tiempo de arranque en caliente, siempre debe usar Ngen.exe en su aplicación, ya que esto evita el costo en términos de CPU de la compilación JIT del código de la aplicación.

En algunos escenarios de inicio en frío, el uso de Ngen.exe también puede resultar útil. Esto se debe a que el compilador JIT (mscorjit.dll) no tiene que cargarse.

Tener los módulos Ngen y JIT puede tener el peor efecto. Esto se debe a que mscorjit.dll debe ser cargado y, cuando el compilador JIT procesa el código, es necesario acceder a muchas páginas de las imágenes Ngen cuando el compilador JIT lee los metadatos de los ensamblados.

Ngen y ClickOnce

La forma en que planea implementar la aplicación también puede marcar la diferencia en el tiempo de carga. La implementación de aplicaciones ClickOnce no admite Ngen. Si decide usar Ngen.exe para la aplicación, tendrá que usar otro mecanismo de implementación, como Windows Installer.

Para obtener más información, vea el artículo sobre Ngen.exe (generador de imágenes nativas).

Rebasing y colisiones de direcciones DLL

Si usa Ngen.exe, tenga en cuenta que la rebasificación puede producirse cuando las imágenes nativas se cargan en la memoria. Si un archivo DLL no se carga en su dirección base preferida porque ese intervalo de direcciones ya está asignado, el cargador de Windows lo cargará en otra dirección, lo que puede ser una operación que consume mucho tiempo.

Puede utilizar la herramienta Volcado de direcciones virtuales (Vadump.exe) para comprobar si existen módulos en los que todas las páginas son privadas. Si este es el caso, es posible que el módulo se haya reubicado a una dirección diferente. Por lo tanto, sus páginas no se pueden compartir.

Para obtener más información sobre cómo establecer la dirección base, consulte Ngen.exe (Generador de imágenes nativas).

Optimizar Authenticode

La comprobación de Authenticode agrega al tiempo de inicio. Los ensamblados firmados por Authenticode deben comprobarse con la entidad de certificación (CA). Esta comprobación puede llevar mucho tiempo, ya que puede requerir conectarse a la red varias veces para descargar las listas de revocación de certificados actuales. También se asegura de que haya una cadena completa de certificados válidos en la ruta de acceso a una raíz de confianza. Esto puede traducirse a varios segundos de retraso mientras se carga el ensamblado.

Considere instalar el certificado CA en el equipo cliente o evite usar Authenticode cuando sea posible. Si sabe que la aplicación no necesita la evidencia del publicador, no tiene que pagar el costo de la verificación de firmas.

A partir de .NET Framework 3.5, hay una opción de configuración que permite omitir la comprobación de Authenticode. Para ello, agregue la siguiente configuración al archivo app.exe.config:

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

Para obtener más información, vea <generatePublisherEvidence> Element.

Comparación del rendimiento en Windows Vista

El administrador de memoria de Windows Vista tiene una tecnología denominada SuperFetch. SuperFetch analiza los patrones de uso de memoria a lo largo del tiempo para determinar el contenido de memoria óptimo para un usuario específico. Funciona continuamente para mantener ese contenido en todo momento.

Este enfoque difiere de la técnica de captura previa que se usa en Windows XP, que precarga datos en memoria sin analizar los patrones de uso. Con el tiempo, si el usuario usa la aplicación WPF con frecuencia en Windows Vista, el tiempo de inicio en frío de la aplicación puede mejorar.

Uso eficaz de AppDomains

Si es posible, cargue ensamblados en un área de código de dominio neutral para garantizar que la imagen nativa, si existe, se utilice en todos los AppDomains creados en la aplicación.

Para obtener el mejor rendimiento, aplique una comunicación entre dominios eficaz mediante la reducción de las llamadas entre dominios. Cuando sea posible, use llamadas sin argumentos o con argumentos de tipo primitivo.

Usar el atributo NeutralResourcesLanguage

Utilice el NeutralResourcesLanguageAttribute para especificar la referencia cultural neutra para el ResourceManager. Este enfoque evita búsquedas de ensamblados incorrectas.

Uso del generador de serializador XML

Si usa la XmlSerializer clase , puede lograr un mejor rendimiento si genera previamente el ensamblado de serialización mediante la herramienta Generador de serializador XML (Sgen.exe)..

Configurar ClickOnce para buscar actualizaciones después del inicio

Si la aplicación usa ClickOnce, evite el acceso a la red al iniciarse mediante la configuración de ClickOnce para comprobar si hay actualizaciones en el sitio de implementación una vez iniciada la aplicación.

Si usas el modelo de aplicación de navegador XAML (XBAP), ten en cuenta que ClickOnce comprueba el sitio de implementación en busca de actualizaciones incluso cuando el XBAP ya está en la caché de ClickOnce. Para obtener más información, vea Seguridad e implementación de ClickOnce.

Configurar el servicio PresentationFontCache para iniciarse automáticamente

La primera aplicación WPF que se ejecutará después de reiniciar es el servicio PresentationFontCache. El servicio almacena en caché las fuentes del sistema, mejora el acceso a fuentes y mejora el rendimiento general. Hay una sobrecarga al iniciar el servicio y, en algunos entornos controlados, considere la posibilidad de configurar el servicio para que se inicie automáticamente cuando se reinicie el sistema.

Establecer el enlace de datos mediante programación

En lugar de usar XAML para establecer DataContext declarativamente para la ventana principal, considere la posibilidad de configurarlo mediante programación en el método OnActivated.

Consulte también

• SplashScreen
• AppDomain
• NeutralResourcesLanguageAttribute
• ResourceManager
• Agregar una pantalla de presentación a una aplicación WPF
• Ngen.exe (Generador de imágenes nativas)
• <Elemento generatePublisherEvidence>