Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
A análise XAML é uma ferramenta que o notifica sobre problemas de desempenho na sua aplicação. Verifica o código da sua aplicação em relação a um conjunto de diretrizes de desempenho e melhores práticas, e identifica problemas a partir de um conjunto de problemas comuns.
Quando a ferramenta encontra um problema, aponta para as ferramentas de diagnóstico, informações de origem e documentação do Visual Studio para que possa investigar e corrigir o problema.
Tamanho da imagem decodificada maior do que o tamanho de renderização
Imagens captadas em alta resolução podem fazer com que a sua aplicação use mais CPU ao descodificar e mais memória após carregar do disco. Não há vantagem em decodificar uma imagem de alta resolução se a exibir apenas num tamanho menor. Em vez disso, crie uma versão da imagem com o tamanho com que a desenha no ecrã, utilizando as propriedades DecodePixelWidth e DecodePixelHeight.
Impacto
Exibir imagens em tamanhos diferentes do seu tamanho nativo pode afetar negativamente o tempo de CPU (descodificação e download) e a memória.
Causas e soluções
A imagem não é definida de forma assíncrona
A sua aplicação usa SetSource() em vez de SetSourceAsync(). Use sempre o SetSourceAsync ao definir um fluxo para decodificar imagens de forma assíncrona.
A fonte da imagem é definida antes do elemento estar na árvore ativa
O BitmapImage está ligado à árvore XAML ao vivo após definir o conteúdo com SetSourceAsync ou UriSource. Anexe sempre um BitmapImage à árvore ativa antes de definir a fonte. Quando especificas um elemento de imagem ou pincel na marcação, o anexo acontece automaticamente.
Good — fonte especificada em marcação usando BitmapImage:
<Image x:Name="myImage">
<Image.Source>
<BitmapImage UriSource="Assets/cool-image.png"/>
</Image.Source>
</Image>
Correto — ligar a BitmapImage à árvore antes de definir a respetiva UriSource:
Image myImage = new Image();
var bitmapImage = new BitmapImage();
myImage.Source = bitmapImage;
bitmapImage.UriSource = new Uri("ms-appx:///Assets/cool-image.png", UriKind.RelativeOrAbsolute);
Incorreto — definir a propriedade UriSource de BitmapImage antes de o ligar à árvore:
Image myImage = new Image();
var bitmapImage = new BitmapImage();
bitmapImage.UriSource = new Uri("ms-appx:///Assets/cool-image.png", UriKind.RelativeOrAbsolute);
myImage.Source = bitmapImage;
O pincel de imagem não é retangular
Quando usas uma imagem para um pincel não retangular, a imagem usa um caminho de rasterização por software, que não escala imagens. Além disso, o sistema armazena uma cópia da imagem tanto em memória de software como de hardware. Quando usar um pincel não retangular, pré-escale as suas imagens para aproximadamente o tamanho em que as renderiza.
Alternativamente, defina um tamanho explícito de decodificação usando as propriedades DecodePixelWidth e DecodePixelHeight :
<Image>
<Image.Source>
<BitmapImage UriSource="ms-appx:///Assets/highresCar.jpg"
DecodePixelWidth="300" DecodePixelHeight="200"/>
</Image.Source>
</Image>
As unidades de DecodePixelWidth e DecodePixelHeight são pixels físicos por defeito. Defina DecodePixelType para Logical para que o tamanho de decodificação tenha automaticamente em conta o fator de escala atual do sistema, semelhante a outros conteúdos XAML.
Se não conseguir determinar um tamanho de decodificação adequado antecipadamente, confie na decodificação automática do tamanho direito do XAML, que faz o melhor esforço para decodificar a imagem no tamanho adequado.
As imagens usadas dentro do BitmapIcons voltam ao tamanho natural
Defina um tamanho de descodificação explícito usando as propriedades DecodePixelWidth e DecodePixelHeight.
DecodePixelWidth ou DecodePixelHeight são maiores do que o tamanho do ecrã
Se definir explicitamente DecodePixelWidth ou definir DecodePixelHeight com um valor superior ao tamanho de apresentação da imagem no ecrã, a aplicação utiliza memória adicional (até 4 bytes por píxel), o que pode tornar-se dispendioso para imagens grandes.
A imagem está oculta
A imagem fica oculta ao definir Opacity como 0 ou Visibility como Collapsed no elemento da imagem de origem, no pincel ou num elemento pai. Imagens não visíveis no ecrã devido a clipping ou transparência podem voltar a ser decodificadas no tamanho natural.
A imagem utiliza a propriedade NineGrid
Quando usa uma imagem com o NineGrid, a imagem utiliza um caminho de rasterização por software. Pré-escale as suas imagens para aproximadamente o tamanho a que as renderiza.
Elementos colapsados em tempo de carregamento
Um padrão comum é esconder inicialmente elementos da interface e mostrá-los mais tarde. Na maioria dos casos, deve adiar estes elementos utilizando x:Load para evitar suportar o custo de criação do elemento aquando do carregamento.
Impacto
Elementos colapsados carregam juntamente com outros elementos e aumentam o tempo de carga.
Solução
Use o atributo x:Load para atrasar o carregamento da interface. O elemento é carregado quando é necessário, o que reduz o processamento inicial. Também podes usar x:Bind para controlar o estado de carregamento.
O ListView não é virtualizado
A virtualização da interface de utilizador é a melhoria mais importante que pode fazer para o desempenho das coleções. Elementos de interface que representam itens são criados a pedido. Para um controlo limitado a uma coleção de 1000 itens, criar toda a interface de uma vez desperdiça recursos porque não podes mostrar todos os itens simultaneamente.
ListView e GridView tratam da virtualização da interface por si — geram a interface para itens perto da janela de visualização e recuperam memória para itens que estão fora de vista.
Impacto
Uma ItemsControl não virtualizada aumenta o tempo de carregamento e o uso de recursos ao carregar mais itens filhos do que o necessário.
Solução
Defina uma largura e altura em ItemsControl para definir uma janela de visualização. Quando colocas um controlo virtualizado num painel com espaço ilimitado (como ScrollViewer ou com Grid filas de tamanho automático), o controlo ocupa espaço suficiente para todos os itens, o que anula a virtualização.
Thread da interface bloqueada ou inativa durante o carregamento
O bloqueio da thread da IU ocorre quando chamadas síncronas a funções executadas noutro thread bloqueiam a thread da IU. Mantenha a thread da interface responsiva usando APIs assíncronas. Para mais informações, veja Mantenha o tópico da interface responsivo.
Utilize {x:Bind} em vez de {Binding}
{Binding} consome mais tempo e memória do que {x:Bind}. Criar um {Binding} causa uma série de alocações e atualizar um alvo de ligação pode envolver reflexão e boxe. Use {x:Bind}, que compila as associações durante a compilação para melhor desempenho e validação em tempo de compilação.
Note
{x:Bind} não é adequado para todos os casos, como cenários de ligação tardia. Consulte a documentação {x:Bind} para mais detalhes.
Use x:Key em vez de x:Name no ResourceDictionaries
Quando usas x:Name um recurso, a plataforma instancia-o imediatamente porque x:Name cria uma referência de campo. Usa x:Key em vez disso quando não precisares de referenciar o recurso do code-behind.
Utilizar painéis de virtualização para coleções
Se fornecer um modelo personalizado de painel de itens (ver ItemsPanel), use um painel de virtualização como ItemsWrapGrid ou ItemsStackPanel. Usar VariableSizedWrapGrid, WrapGrid, ou StackPanel desativa a virtualização.
Acessibilidade: Fornecer nomes para elementos UIA
Defina AutomationProperties.Name no XAML do seu controlo para uma cadeia localizada adequada. Se um elemento não aparecer na árvore UIA, defina AutomationProperties.AccessibilityView = "Raw".
Evite atribuir a dois elementos UIA com o mesmo elemento principal o mesmo Name e ControlType. Em listas onde nomes duplicados ocorrem comumente, use binding para definir AutomationProperties.Name a partir de uma fonte de dados.
Conteúdo relacionado
Windows developer