Partilhar via

Melhore a capacidade de resposta da sua aplicação Windows

Este guia irá ajudá-lo a melhorar a capacidade de resposta da sua aplicação Windows, otimizando a latência para o lançamento e as interações com chaves. Interações rápidas e responsivas (também conhecidas como interações de baixa latência) criam uma melhor experiência para o utilizador. Compreender as expectativas de interação, medir as durações atuais e definir objetivos de melhoria consoante a classe de interação pode levar a melhorias significativas na experiência e satisfação dos seus utilizadores.

Guia passo a passo para otimizar interações para um comportamento responsivo

Os clientes podem sentir quando o lançamento de uma aplicação, a navegação por menus ou o carregamento de páginas/conteúdos é lento. Eles já esperam uma experiência rápida e fluida e partilhámos alguns passos e orientações para compreender melhor essas expectativas abaixo.

Os passos básicos para impulsionar a otimização da latência são:

  1. Defina o cenário e adicione eventos TraceLoging.

    Faça uma lista das interações-chave que um utilizador terá ao usar a sua aplicação, como lançar, abrir um menu, navegar para uma nova página e renderizar conteúdo, etc. Para cada uma destas interações, adicione um evento de início e um evento de paragem para serem usados na medição e análise. Saiba mais sobre como adicionar o TraceLogging, um formato para autodescrição do Event Tracing para Windows (ETW).

  2. Defina objetivos com base na aula de interação.

    Os utilizadores têm expectativas diferentes quanto ao desempenho e à capacidade de resposta de uma aplicação, dependendo do tipo de interação. Por exemplo, a rapidez com que uma aplicação é lançada versus a rapidez com que a página carrega. Pense no intervalo aceitável de tempo decorrido que os utilizadores demoram a completar as interações-chave na sua aplicação. Isto pode variar entre 200 milissegundos (ms) e 5 segundos (seg). Depois, atribui a cada tarefa um rótulo de classe de interação com um objetivo associado. Abaixo estão algumas orientações básicas, juntamente com sugestões sobre como pode incluir uma interface de utilizador (UI) para melhorar a perceção de responsividade:

Rótulo de classe de interação Perceção do utilizador Intervalo de atraso Exemplos UI sugerida
Rápido Atraso minimamente perceptível 100 - 200 milissegundos Abrir a barra da aplicação, clicar com o botão direito no menu
Interativo Rápido, mas não rápido 300 - 500 ms Sair de uma aplicação, mostrar resultados de pesquisa em cache
Pausa Não é rápido, mas parece responsivo 500 ms - 1 seg Navegar para outra página, retomar a aplicação a partir de um estado suspenso, mostrar resultados de pesquisa web Uma animação de entrada (por exemplo, voar para novo conteúdo) pode ser usada para mascarar o tempo necessário neste cenário.
Wait Não se procede rapidamente devido à carga de trabalho necessária para o cenário. 1 - 3 seg Lançamento da aplicação Pode ser usado um cursor giratório ou à espera para anotar o progresso. Tanto animações de saída como de entrada (por exemplo, deslocar a página antiga para fora, deslocar a página nova para dentro) podem ser usadas para mascarar o tempo necessário neste cenário.
Longa espera Já não parece responsivo 2 - 5 seg Os lançamentos de grandes aplicações (utilizam ecrã de arranque prolongado), iniciando uma transmissão de vídeo HD. É exibida uma "interface de carregamento" – sempre que possível, inclua uma opção de "cancelar" para o utilizador. A interface de carregamento deve aparecer dentro da classe de interação rápida. A interface de carregamento não precisa de mostrar uma percentagem ou tempo restante.
Cativo Uma longa espera – reservada para cenários inevitavelmente longos/complexos 5 - 10 seg Login do sistema É exibido um "interface de carregamento" ou diálogo – sempre que possível, inclua uma opção de "cancelar" para o utilizador. O diálogo deve aparecer dentro da classe Interação Rápida. O diálogo deve mostrar uma percentagem ou tempo restante se isso fornecer contexto útil ao utilizador.
Longa duração Operações longas – os utilizadores provavelmente irão realizar multitarefas (desviar-se durante a operação) 10 - 30+ seg Instalação de novas funcionalidades ou atualizações, downloads de ficheiros grandes A interface deve ser desenhada para refletir a possibilidade de multitarefa. Deve ser apresentado um diálogo de progresso, incluindo uma estimativa de conclusão (percentagem, tempo restante, etc.). Alternativamente, a interface pode minimizar completamente e só notificar o utilizador quando o cenário terminar, usando uma notificação de toast.

  1. Para verificar as durações exatas de interações específicas, pode capturar e analisar um rastreio usando o Windows Performance Analyzer (WPA).

    • Antes de capturar o seu rastreio, faça com que o seu dispositivo de teste fique inativo abrindo o Gestor de Tarefas e certificando-se de que a utilização da CPU é inferior a 5%. Fazer isso minimizará a interferência na medição e fornecerá registos de tamanho razoável. Isto vai ajudá-lo a isolar melhor a interação que pretende medir.

    • Para capturar um rastreio, abra uma linha de comandos (PowerShell ou Prompt de Comandos) em modo administrador.

    • Entra o comando: wpr -start GeneralProfile -filemode

    • Executa o cenário de interação na tua aplicação.

    • Entra o comando: wpr -stop Trace.etl

  2. Analise o rastreio e encontre oportunidades de melhoria.

    Analise a duração de cada interação chave suportada pelo seu app abrindo o rastreio que acabou de capturar no Windows Performance Analyzer (WPA).

    • Para abrir o rastreio no WPA, na sua linha de comandos, introduza: wpa.exe Trace.etl
    • Expanda a lista suspensa de Atividade do Sistema e clique duas vezes em "Eventos Genéricos" para abrir a visão de análise.
    • Escolha a série de eventos relacionada com a sua aplicação e expanda o menu suspenso "Nome do Fornecedor" até conseguir encontrar o Processo, o Nome da Tarefa e o Nome do Evento associados à interação chave que procura. A duração do evento de interação será listada na coluna de Tempo , bem como no gráfico, mostrando a Duração, a Hora de Início e a Hora de Fim.

    Se a duração do teu rastreio não cumprir os objetivos da classe de interação (ex: 500ms), identifica os threads-chave para a tua App (provavelmente o thread da interface) e vê as pilhas principais para uso da CPU e esperas. *Lembre-se que, ao realizar a análise, alguns problemas podem não ser específicos do código da sua própria aplicação.

    Análise da duração do evento de rastreio

Recursos adicionais

  • Last updated on