Me di cuenta de que el inicio de la aplicación WPF a veces es bastante lento. ¿Alguien sabe si la causa es la inicialización de elementos o la carga de archivos DLL o algo más?¿Qué hace que el inicio de la aplicación WPF sea lento?
El siguiente texto fue extraído de this MSDN article on Improving WPF applications startup time (Edit: ahora fusionado en WPF Application Startup Time)
La cantidad de tiempo que se requiere para una aplicación WPF empezar puede variar en gran medida. Este tema describe varias técnicas para reducir el tiempo de inicio de sesión percibido y real para una aplicación Windows Presentation Foundation (WPF).
La comprensión de frío Inicio y WarmStartup
arranque en frío se produce cuando la aplicación se inicia por primera vez después de un reinicio del sistema, o cuando se inicia la aplicación, ciérrela y, a continuación, empezar de nuevo después de un largo periodo de tiempo. Cuando se inicia una aplicación, si las páginas requeridas (código, datos estáticos, registro, etc.) no están presentes en la lista de espera del administrador de memoria de Windows, se producen fallas en la página. Se requiere acceso al disco para traer las páginas a la memoria.
El inicio en caliente se produce cuando la mayoría de las páginas de los principales componentes de tiempo de ejecución del lenguaje común (CLR) ya están cargados en la memoria, lo que ahorra costosos tiempos de acceso al disco. Es por eso que una aplicación administrada se inicia más rápido cuando se ejecuta por segunda vez.
Implementar una pantalla de bienvenida
En los casos en que existe un significativo retraso, inevitable entre el inicio de una aplicación y mostrar la primera interfaz de usuario, optimizar el tiempo de inicio percibida mediante el uso de una pantalla de bienvenida . Este enfoque muestra una imagen casi inmediatamente después de que el usuario inicia la aplicación. Cuando la aplicación está lista para mostrar su primera interfaz de usuario, la pantalla de bienvenida se desvanece. Comenzando en .NET Framework 3.5 SP1, puede usar la clase SplashScreen para implementar una pantalla de bienvenida. Para obtener más información, consulte How to: Add a Splash Screen to a WPF Application.
También puede implementar su propia pantalla de bienvenida mediante el uso de gráficos Win32 nativos. Muestre su implementación antes de llamar al método Run.
analizar el código de inicio
Determinar la razón de un arranque en frío lento. La E/S de disco puede ser responsable, pero este no es siempre el caso. En general, debe minimizar el uso de recursos externos, como red, servicios web o disco.
Antes de la prueba, verifique que ninguna otra aplicación o servicio en ejecución use código administrado o código WPF.
Inicie su aplicación WPF inmediatamente después de un reinicio, y determine cuánto tiempo demora en visualizarse. Si todos los lanzamientos posteriores de su aplicación (inicio en caliente) son mucho más rápidos, es probable que su problema de arranque en frío sea causado por E/S.
Si el problema de inicio en frío de su aplicación no está relacionado con E/S, es probable que su aplicación realice una inicialización o cálculo largos, espere algún evento para completarse o requiera mucha compilación JIT al inicio. Las siguientes secciones describen algunas de estas situaciones con más detalle.
Módulo optimizar la carga
utilizar herramientas como Process Explorer (Procexp.exe) y Tlist.exe para determinar qué módulos sus cargas de aplicaciones. El comando Tlist <pid> muestra todos los módulos cargados por un proceso.
Por ejemplo, si no se está conectando a la Web y ve que System.Web.dll está cargado, entonces hay un módulo en su aplicación que hace referencia a este conjunto. Verifique para asegurarse de que la referencia sea necesaria.
Si su aplicación tiene múltiples módulos, combínelos en un único módulo. Este enfoque requiere menos sobrecarga de carga de montaje CLR. Menos conjuntos también significan que el CLR mantiene menos estado.
operaciones de inicialización Defer
considerar posponer el código de inicialización hasta después de que se pronuncie la ventana principal de la aplicación.
Tenga en cuenta que la inicialización puede realizarse dentro de un constructor de clase, y si el código de inicialización hace referencia a otras clases, puede causar un efecto de cascada en el que se ejecutan muchos constructores de clase.
configuración evitar la aplicación
considerar evitar configuración de la aplicación. Por ejemplo, si una aplicación tiene requisitos de configuración simples y tiene objetivos estrictos de inicio, las entradas de registro o un archivo INI simple pueden ser una alternativa de inicio más rápida.
Utilizar el GAC
Si una asamblea no está instalado en el caché de ensamblados global (GAC), hay retrasos causados por la verificación de hash de los ensamblados con nombre y por la validación imagen Ngen si una imagen de nativo para ese ensamblaje está disponible en la computadora. La verificación de nombre seguro se omite para todos los ensamblados instalados en el GAC. Para obtener más información, consulte Gacutil.exe (Global Assembly Cache Tool).
Uso Ngen.exe
Considere usar el Generador de imágenes nativas (Ngen.exe) en su aplicación. Usar Ngen.exe significa intercambiar el consumo de CPU por más acceso al disco porque es probable que la imagen nativa generada por Ngen.exe sea más grande que la imagen MSIL.
Para mejorar el tiempo de inicio en caliente, siempre debe usar Ngen.exe en su aplicación, ya que esto evita el costo de CPU de la compilación JIT del código de la aplicación.
En algunas situaciones de arranque en frío, el uso de Ngen.exe también puede ser útil. Esto se debe a que el compilador JIT (mscorjit.dll) no tiene que cargarse.
Tener ambos módulos Ngen y JIT puede tener el peor efecto. Esto se debe a que debe cargarse mscorjit.dll, y cuando el compilador JIT funciona en su código, se debe acceder a muchas páginas en las imágenes de Ngen cuando el compilador JIT lee los metadatos de los ensamblajes.
Ngen y ClickOnce
La forma en que va a implementar la aplicación también puede hacer una diferencia en el tiempo de carga. La implementación de la aplicación ClickOnce no es compatible con Ngen. Si decide usar Ngen.exe para su aplicación, deberá usar otro mecanismo de implementación, como Windows Installer.
Para obtener más información, consulte Ngen.exe (Native Image Generator).
cambio de base y la DLL de dirección colisiones
Si utiliza Ngen.exe, tenga en cuenta que rebase puede ocurrir cuando las imágenes nativas se cargan en la memoria. Si no se carga una DLL en su dirección base preferida porque ese rango 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 Virtual Address Dump (Vadump.exe) para comprobar si hay módulos en los que todas las páginas son privadas. Si este es el caso, el módulo puede haber sido rediseñado a una dirección diferente. Por lo tanto, sus páginas no pueden ser compartidas.
Para obtener más información acerca de cómo establecer la dirección base, consulte Ngen.exe (Native Image Generator).
Optimizar Authenticode
verificación Authenticode se suma al tiempo de inicio. Los ensambles firmados con Authenticode deben verificarse con la autoridad de certificación (CA). Esta verificació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 a una raíz de confianza. Esto puede traducirse en varios segundos de retraso mientras se carga el ensamblaje.
Considere instalar el certificado de CA en la computadora del cliente, o evite usar Authenticode cuando sea posible. Si sabe que su aplicación no necesita la evidencia del editor, no tiene que pagar el costo de la verificación de la firma.
Comenzando en .NET Framework 3.5, existe una opción de configuración que permite eludir la verificación de Authenticode. Para ello, agregue el siguiente valor al archivo app.exe.config:
<configuration>
<runtime>
<generatePublisherEvidence enabled="false"/>
</runtime>
</configuration>
comparar el rendimiento en Windows Vista
El gestor de memoria en Windows Vista tiene una tecnología llamada 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. Trabaja continuamente para mantener ese contenido en todo momento.
Este enfoque difiere de la técnica de búsqueda previa utilizada en Windows XP, que precarga los datos en la memoria sin analizar los patrones de uso. Con el tiempo, si el usuario usa su aplicación WPF frecuentemente en Windows Vista, el tiempo de inicio en frío de su aplicación puede mejorar.
Use AppDomains eficientemente
Si es posible, las asambleas de carga en un área de código de dominio neutral para asegurarse de que la imagen nativa, si es que existe, se utiliza en todos los dominios de aplicación creados en la aplicación.
Para obtener el mejor rendimiento, aplique una comunicación eficaz entre dominios mediante la reducción de llamadas entre dominios. Cuando sea posible, use llamadas sin argumentos o con argumentos de tipo primitivo.
uso del atributo NeutralResourcesLanguage
Uso del NeutralResourcesLanguageAttribute para especificar la referencia cultural neutra para el ResourceManager. Este enfoque evita las búsquedas de ensamblaje fallidas.
Utilizar la clase BinaryFormatter para la serialización
Si tiene que usar la serialización, utilice la clase BinaryFormatter lugar de la clase XmlSerializer. La clase BinaryFormatter se implementa en la Base Class Library (BCL) en el ensamblado mscorlib.dll. El XmlSerializer se implementa en el ensamblado System.Xml.dll, que podría ser una DLL adicional para cargar.
Si debe utilizar la clase XmlSerializer, puede lograr un mejor rendimiento si pregenera el ensamblaje de serialización.
Configurar ClickOnce para comprobar las actualizaciones después de inicio
Si la aplicación utiliza ClickOnce, evitar el acceso a la red en el arranque mediante la configuración de ClickOnce para comprobar el sitio de implementación de las actualizaciones después se inicia la aplicación.
Si utiliza el modelo de aplicación de navegador XAML (XBAP), tenga en cuenta que ClickOnce comprueba si el sitio de implementación tiene actualizaciones incluso si el XBAP ya está en la memoria caché de ClickOnce. Para obtener más información, consulte ClickOnce Security and Deployment.
configurar el servicio para iniciarse automáticamente PresentationFontCache
La primera aplicación de WPF para funcionar después de un reinicio es el servicio PresentationFontCache. El servicio almacena en caché las fuentes del sistema, mejora el acceso a la fuente y mejora el rendimiento general. Hay una sobrecarga al comenzar el servicio, y en algunos entornos controlados, considere configurar el servicio para que se inicie automáticamente cuando el sistema se reinicie.
Conjunto de enlace de datos mediante programación
En lugar de utilizar XAML para establecer el DataContext declarativa de la ventana principal, se recomienda establecer mediante programación en el método OnActivated.
El tiempo de inicio de una aplicación WPF puede ser mucho más rápido si usa Framework 3.51 y no 3.5 o 3.0. El 3.51 es realmente una mejora.
Lo que más me ayudó del excelente artículo al que Stuart se vincula es el truco de XmlSerializer. Eso realmente se afeitó bastantes segundos.Además, no subestime la desfragmentación de su HD :-)
El consejo más útil sobre la fijación del rendimiento de inicio de WPF que he visto en mi vida fue in this other question: ejecute "ngen actualización" en todas las carpetas de marcos.
Parece que Microsoft no puede mantener su caché ngen actualizada, lo que hace que su aplicación recompile casi la mitad del .NET Framework en cada inicio.
Es difícil de creer, pero parece ser cierto.
Este es un hilo antiguo, pero he terminado aquí varias veces al intentar solucionar un problema de rendimiento de inicio con aplicaciones WPF en mi sistema Win10, así que pensé en dar una respuesta que podría ayudar a otros - un respuesta que lleva un horrible tiempo de inicio de 5 segundos para todas las aplicaciones de WPF en este sistema a solo unos pocos milisegundos. Elimine el controlador nVidia "3d Vision". Tengo una tarjeta GeForce GTX 650, y el controlador "3D Vision" no parece ofrecer nada útil, por lo que eliminarlo no es un problema para mí. La herramienta de análisis de rendimiento VisualStudio2015 finalmente ayudó a mostrar que casi todo el tiempo de inicio de 5 segundos se gastó IDLE después de una llamada a través de nvapi64.dll, el controlador nVidia. Guau.
Este artículo se ha fusionado en la documentación oficial de WPF MSDN - http://msdn.microsoft.com/en-us/library/cc656914.aspx – splintor