Compartir a través de


Planeación del rendimiento

Los usuarios esperan que sus aplicaciones sigan respondiendo, que se sientan naturales y que no desagüen la batería. Técnicamente, el rendimiento es un requisito no funcional, pero el tratamiento del rendimiento como una característica le ayudará a ofrecer las expectativas de los usuarios. Especificar objetivos y medir son factores clave. Determine cuáles son los escenarios críticos para el rendimiento; defina qué buen rendimiento significa. A continuación, mida temprano y a menudo lo suficiente durante el ciclo de vida del proyecto para estar seguro de que alcanzará sus objetivos.

Especificación de objetivos

La experiencia del usuario es una manera básica de definir un buen rendimiento. El tiempo de inicio de una aplicación puede influir en la percepción de un usuario de su rendimiento. Un usuario podría considerar que un tiempo de inicio de la aplicación de menos de un segundo es excelente, menos de 5 segundos para ser bueno y superior a 5 segundos para ser deficiente.

Otras métricas tienen un impacto menos obvio en la experiencia del usuario, por ejemplo, la memoria. Las probabilidades de que una aplicación sea terminada mientras está suspendida o inactiva aumentan con la cantidad de memoria utilizada por la aplicación activa. Es una regla general que el uso elevado de memoria degrada la experiencia de todas las aplicaciones del sistema, por lo que tener un objetivo en el consumo de memoria es razonable. Tenga en cuenta el tamaño aproximado de la aplicación según lo perciben los usuarios: pequeños, medianos o grandes. Las expectativas en torno al rendimiento se correlacionarán con esta percepción. Por ejemplo, es posible que quiera una aplicación pequeña que no use muchos medios para consumir menos de 100 MB de memoria.

Es mejor establecer un objetivo inicial y, a continuación, revisarlo más adelante, que no tener un objetivo en absoluto. Los objetivos de rendimiento de la aplicación deben ser específicos y medibles y deben estar en tres categorías: cuánto tiempo tardan los usuarios o la aplicación en completar tareas (tiempo); velocidad y continuidad con la que la aplicación se vuelve a dibujar en respuesta a la interacción del usuario (fluidez); y la forma en que la aplicación conserva los recursos del sistema, incluida la energía de la batería (eficiencia).

Tiempo

Piense en los rangos aceptables de tiempo transcurrido (clases de interacción) que los usuarios tardan en completar sus tareas en su aplicación. Para cada clase de interacción, asigne una etiqueta, una opinión de usuario percibida y duraciones ideales y máximas. Estas son algunas sugerencias.

Etiqueta de clase de interacción Percepción del usuario Ideal Máxima Ejemplos
Rápido Retraso mínimamente notable 100 milisegundos 200 milisegundos Abra la barra de la aplicación; Presione un botón (primera respuesta)
Típico Rápido, pero no rápido 300 milisegundos 500 milisegundos Redimensionar; zoom semántico
Receptivo No es rápido, pero se siente ágil 500 milisegundos 1 segundo Vaya a otra página; reanudar la aplicación desde un estado suspendido
Lanzar Experiencia competitiva 1 segundo 3 segundos Inicie la aplicación por primera vez o después de que se haya cerrado anteriormente.
Continuo Ya no se siente responsivo 500 milisegundos 5 segundos Descargar un archivo desde Internet
Cautivo Prolongado; el usuario podría cambiar 500 milisegundos 10 segundos Instalar varias aplicaciones desde la Tienda

 

Ahora puede asignar clases de interacción a los escenarios de rendimiento de la aplicación. Puede asignar la referencia a un momento dado de la aplicación, una parte de la experiencia del usuario y una clase de interacción a cada escenario. Estas son algunas sugerencias para una aplicación de comida y comedor de ejemplo.

EscenarioPunto de tiempoExperiencia del usuarioClase de interacción
Vaya a la página de recetas. Primera respuestaAnimación de transición de página iniciadaRápido (100-200 milisegundos)
ReceptivoLista de ingredientes cargada; sin imágenesCapacidad de respuesta (500 milisegundos - 1 segundo)
Visible completoTodo el contenido cargado; imágenes mostradasContinuo (500 milisegundos - 5 segundos)
Buscar recetaPrimera respuestaSe ha hecho clic en el botón de búsquedaRápido (100 - 200 milisegundos)
Visible completoLista de títulos de recetas locales mostradosTípico (300 - 500 milisegundos)

Si va a mostrar contenido en directo, considere también los objetivos de actualización de contenido. ¿El objetivo es actualizar el contenido cada pocos segundos? ¿O es actualizar el contenido cada pocos minutos, cada pocas horas o incluso una vez al día una experiencia de usuario aceptable?

Con los objetivos especificados, ahora puede probar, analizar y optimizar la aplicación.

Fluidez

Los objetivos de fluidez medibles específicos para la aplicación pueden incluir:

  • No hay parones ni interrupciones en el redibujado de la pantalla (fallos).
  • Las animaciones se representan en 60 fotogramas por segundo (FPS).
  • Cuando un usuario desplaza el contenido, la aplicación muestra 3-6 páginas de contenido por segundo.

Eficacia

Los objetivos específicos de eficiencia medible para la aplicación pueden incluir:

  • Para el proceso de la aplicación, el porcentaje de CPU está igual o por debajo de N y el uso de memoria en MB está igual o por debajo de M en todo momento.
  • Cuando la aplicación está inactiva, N y M son cero para el proceso de la aplicación.
  • La aplicación se puede usar activamente durante X horas con energía de la batería; cuando la aplicación está inactiva, el dispositivo conserva su carga por Y horas.

Diseño de la aplicación para el rendimiento

Ahora puede usar los objetivos de rendimiento para influir en el diseño de la aplicación. Con la aplicación de comida y cenas de ejemplo, después de que el usuario navegue a la página de recetas, puede optar por actualizar los elementos de forma incremental para que el nombre de la receta se represente primero, se pospone mostrar los ingredientes y se pospone aún más el mostrar imágenes. Esto mantiene la capacidad de respuesta y una interfaz de usuario fluida tanto al desplazar como al hacer scroll, con la representación de alta fidelidad realizándose cuando la interacción se ralentiza hasta un ritmo que permite al hilo de la interfaz de usuario ponerse al día. Estos son algunos otros aspectos que se deben tener en cuenta.

interfaz de usuario

  • Maximizar el tiempo de análisis y carga y la eficacia de la memoria de cada página de la interfaz de usuario de la aplicación (especialmente la página inicial) mediante optimizar el marcado XAML. En pocas palabras, aplaza la carga de la interfaz de usuario y el código hasta que sea necesario.
  • Para listView y GridView, haga que todos los elementos sean del mismo tamaño y usen tantas técnicas de optimización de ListView y GridView como pueda.
  • Declare la interfaz de usuario en forma de marcado, que el framework puede cargar y reutilizar en partes, en lugar de construirla de forma imperativa en el código.
  • Retrasar la creación de elementos de interfaz de usuario hasta que el usuario los necesite. Consulte el atributo x:Load.
  • Prefiere transiciones de tema y animaciones a animaciones con guion gráfico. Para obtener más información, consulta la sección de información general sobre animaciones en . Recuerde que las animaciones con guion gráfico requieren actualizaciones constantes en la pantalla y mantienen activa la canalización de CPU y gráficos. Para conservar la batería, no tenga animaciones en ejecución si el usuario no interactúa con la aplicación.
  • Las imágenes que cargue se deben cargar con un tamaño adecuado para la vista en la que se presenta, mediante el método GetThumbnailAsync.

CPU, memoria y energía

  • Programe el trabajo de menor prioridad para ejecutarse en hilos o núcleos de menor prioridad. Consulte programación asincrónica , la propiedad Dispatcher , y la clase CoreDispatcher .
  • Minimice la superficie de memoria de la aplicación liberando recursos costosos (como medios) en suspensión.
  • Minimice el conjunto operativo del código.
  • Evite pérdidas de memoria anulando el registro de controladores de eventos y desreferenciando elementos de la interfaz de usuario siempre que sea posible.
  • Por motivos de batería, sea conservador con la frecuencia con la que sondea los datos, consulta un sensor o programa el trabajo en la CPU cuando está inactivo.

acceso a datos

  • Si es posible, captura previa del contenido. Para la captura previa automática, consulte la clase ContentPrefetcher. Para la precarga manual, consulte el espacio de nombres Windows.ApplicationModel.Background y la clase MaintenanceTrigger.
  • Si es posible, almacene en caché el contenido que sea costoso de acceder. Consulte las propiedades LocalFolder y LocalSettings.
  • En el caso de fallos de caché, muestre una interfaz de marcador de posición lo más pronto posible para indicar que la aplicación sigue cargando contenido. Transición del marcador de posición al contenido activo de una manera que no sea brusca para el usuario. Por ejemplo, no cambie la posición del contenido bajo el dedo del usuario o el puntero del mouse a medida que la aplicación carga contenido activo.

inicio y reanudación de la aplicación

Interfaz de usuario adaptable y orientación

  • Usa la clase VisualStateManager.
  • Completar solo el trabajo necesario inmediatamente, aplazar el trabajo intensivo de la aplicación hasta más adelante: la aplicación tiene entre 200 y 800 milisegundos para completar el trabajo antes de que el usuario vea la interfaz de usuario de la aplicación en un estado recortado.

Con los diseños relacionados con el rendimiento implementados, puedes empezar a codificar la aplicación.

Instrumento para el rendimiento

Al codificar, agregue código que registra mensajes y eventos en determinados puntos mientras se ejecuta la aplicación. Más adelante, al probar la aplicación, puedes usar herramientas de generación de perfiles como Windows Performance Recorder y Windows Performance Analyzer (ambas se incluyen en el Windows Performance Toolkit) para crear y ver un informe sobre el rendimiento de la aplicación. En este informe, puede buscar estos mensajes y eventos para ayudarle a analizar más fácilmente los resultados del informe.

La Plataforma Universal de Windows (UWP) proporciona APIs de registro, respaldadas por seguimiento de eventos para Windows (ETW), que juntas ofrecen una solución enriquecida de registro y seguimiento de eventos. Las API, que forman parte del espacio de nombres Windows.Foundation.Diagnostics, incluyen las clasesfileLoggingSession , LoggingActivity, LoggingChannely LoggingSession.

Para registrar un mensaje en el informe en un momento específico mientras se ejecuta la aplicación, cree un objeto LoggingChannel y, a continuación, llame al método LogMessage del objeto, como este.

// using Windows.Foundation.Diagnostics;
// ...

LoggingChannel myLoggingChannel = new LoggingChannel("MyLoggingChannel");

myLoggingChannel.LogMessage(LoggingLevel.Information, "Here' s my logged message.");

// ...

Para registrar eventos de inicio y detención en el informe durante un período de tiempo mientras se ejecuta la aplicación, cree un objeto LoggingActivity y, a continuación, invoque el constructor LoggingActivity del objeto.

// using Windows.Foundation.Diagnostics;
// ...

LoggingActivity myLoggingActivity;

// myLoggingChannel is defined and initialized in the previous code example.
using (myLoggingActivity = new LoggingActivity("MyLoggingActivity"), myLoggingChannel))
{   // After this logging activity starts, a start event is logged.
    
    // Add code here to do something of interest.
    
}   // After this logging activity ends, an end event is logged.

// ...

También vea el ejemplo de registro .

Con la aplicación instrumentada, puedes probar y medir el rendimiento de la aplicación.

Prueba y medición con respecto a los objetivos de rendimiento

Parte de tu plan de rendimiento es definir los puntos durante el desarrollo en los que medirás el rendimiento. Esto sirve para diferentes propósitos en función de si va a medir durante la creación de prototipos, el desarrollo o la implementación. La medición del rendimiento durante las primeras fases de creación de prototipos puede ser tremendamente valiosa, por lo que se recomienda hacerlo tan pronto como tenga código que haga un trabajo significativo. Las primeras medidas te dan una buena idea de dónde se encuentran los costos importantes en tu aplicación e informa a las decisiones de diseño. Esto da como resultado aplicaciones de alto rendimiento y escalado. Por lo general, es rentable cambiar los diseños más adelante que antes. La medición del rendimiento hacia el final del ciclo del producto puede dar lugar a soluciones improvisadas de última hora y un rendimiento deficiente.

Usa estas técnicas y herramientas para probar cómo tu aplicación se compara frente a tus objetivos originales de rendimiento.

  • Prueba con una amplia variedad de configuraciones de hardware, incluidos equipos de escritorio y todo en uno, portátiles, ultrabooks y tabletas y otros dispositivos móviles.
  • Prueba con una amplia variedad de tamaños de pantalla. Aunque los tamaños de pantalla más anchos pueden mostrar mucho más contenido, incorporar todo ese contenido adicional puede afectar negativamente al rendimiento.
  • Elimine tantas variables de prueba como pueda.
    • Desactive las aplicaciones en segundo plano en el dispositivo de prueba. Para ello, en Windows, seleccione Configuración en el menú Inicio >Personalización>Pantalla de bloqueo. Seleccione cada aplicación activa y seleccione Ninguno.
    • Compila tu aplicación a código nativo con la configuración de lanzamiento antes de implementarla en el dispositivo de prueba.
    • Para asegurarse de que el mantenimiento automático no afecta al rendimiento del dispositivo de prueba, desencadene manualmente y espere a que se complete. En Windows, en el menú Inicio, busque Seguridad y Mantenimiento. En el área Mantenimiento, en Mantenimiento Automático, seleccione Iniciar mantenimiento y espere a que el estado cambie de Mantenimiento en curso a.
    • Ejecute la aplicación varias veces para ayudar a eliminar variables de prueba aleatorias y ayudar a garantizar medidas coherentes.
  • Prueba para reducir la disponibilidad de energía. Es posible que el dispositivo de los usuarios tenga una potencia significativamente menor que la máquina de desarrollo. Windows se diseñó con dispositivos de bajo consumo, como dispositivos móviles, en mente. Las aplicaciones que se ejecutan en la plataforma deben asegurarse de que funcionan bien en estos dispositivos. Como heurística, espere que un dispositivo de baja potencia se ejecute a aproximadamente un cuarto de la velocidad de un equipo de escritorio y establezca sus objetivos en consecuencia.
  • Use una combinación de herramientas como Microsoft Visual Studio y Windows Performance Analyzer para medir el rendimiento de la aplicación. Visual Studio está diseñado para proporcionar análisis centrados en la aplicación, como la vinculación de código fuente. El Analizador de rendimiento de Windows está diseñado para proporcionar análisis centrados en el sistema, como proporcionar información del sistema, información sobre eventos de manipulación táctil e información sobre el costo de entrada y salida del disco (E/S) y la unidad de procesamiento de gráficos (GPU). Ambas herramientas proporcionan captura y exportación de rastreo, y pueden volver a abrir rastros compartidos y posmortem.
  • Antes de enviar la aplicación a la Tienda para la certificación, asegúrate de incorporar en los planes de prueba los casos de prueba relacionados con el rendimiento, tal como se describe en la sección "Pruebas de rendimiento" de pruebas del Kit de certificación de aplicaciones de Windows y en la sección "Rendimiento y estabilidad" de casos de prueba de aplicaciones para UWP.

Para obtener más información, consulte estos recursos y herramientas de generación de perfiles.

Respuesta a los resultados de la prueba de rendimiento

Después de analizar los resultados de la prueba de rendimiento, determine si se necesitan cambios, por ejemplo:

  • ¿Debería cambiar cualquiera de las decisiones de diseño de la aplicación o optimizar el código?
  • ¿Debe agregar, quitar o cambiar alguna de las instrumentaciones en el código?
  • ¿Debería revisar alguno de los objetivos de rendimiento?

Si se necesitan cambios, realice estos cambios y vuelva a instrumentar o probar y repetir.

Optimizar

Optimice solo las partes del código críticas para el rendimiento en tu aplicación: donde se pasa más tiempo. El perfilado le indicará cuál. A menudo, existe un equilibrio entre la creación de software que sigue los procedimientos de diseño recomendados y la escritura de código que funciona con la mayor optimización. Por lo general, es mejor priorizar la productividad del desarrollador y un buen diseño de software en áreas en las que el rendimiento no es un problema.