Partilhar via

Desempenho do ListView

  • Artigo

Ao escrever aplicativos móveis, o desempenho é importante. Os usuários esperam rolagem suave e tempos de carregamento rápidos. Deixar de atender às expectativas de seus usuários custará classificações na loja de aplicativos ou, no caso de um aplicativo de linha de negócios, custará tempo e dinheiro à sua organização.

A Xamarin.FormsListView é uma visualização poderosa para exibir dados, mas tem algumas limitações. O desempenho da rolagem pode ser prejudicado ao usar células personalizadas, especialmente quando elas contêm hierarquias de visualização profundamente aninhadas ou usam determinados layouts que exigem medições complexas. Felizmente, existem técnicas que você pode usar para evitar um desempenho ruim.

Estratégia de cache

ListViews são frequentemente usados para exibir muito mais dados do que cabem na tela. Por exemplo, um aplicativo de música pode ter uma biblioteca de músicas com milhares de entradas. Criar um item para cada entrada desperdiçaria memória valiosa e teria um desempenho insatisfatório. Criar e destruir linhas constantemente exigiria que o aplicativo instanciasse e limpasse objetos constantemente, o que também teria um desempenho ruim.

Para conservar memória, os ListView equivalentes nativos de cada plataforma possuem recursos integrados para reutilização de linhas. Apenas as células visíveis na tela são carregadas na memória e o conteúdo é carregado nas células existentes. Esse padrão impede que o aplicativo instancie milhares de objetos, economizando tempo e memória.

Xamarin.Forms Permite a reutilização de ListView células por meio da ListViewCachingStrategy enumeração, que tem os seguintes valores:

public enum ListViewCachingStrategy
{
    RetainElement,   // the default value
    RecycleElement,
    RecycleElementAndDataTemplate
}

Observação

A Plataforma Universal do Windows (UWP) ignora a RetainElement estratégia de cache, pois sempre usa o cache para melhorar o desempenho. Portanto, por padrão, ele se comporta como se a RecycleElement estratégia de cache fosse aplicada.

Reter

A estratégia de cache RetainElement especifica que ListView gerará uma célula para cada item da lista e é o comportamento ListView padrão. Deve ser usado nas seguintes circunstâncias:

  • Cada célula possui um grande número de ligações (20-30+).
  • O modelo de célula muda frequentemente.
  • Os testes revelam que a estratégia de cache RecycleElement resulta em uma velocidade de execução reduzida.

É importante reconhecer as consequências da RetainElement estratégia de cache ao trabalhar com células customizadas. Qualquer código de inicialização de célula precisará ser executado para cada criação de célula, o que pode ocorrer várias vezes por segundo. Nessa circunstância, as técnicas de layout que eram boas em uma página, como o uso de várias instâncias aninhadas StackLayout , tornam-se gargalos de desempenho quando são configuradas e destruídas em tempo real à medida que o usuário rola.

Elemento Reciclado

A estratégia de cache RecycleElement especifica que o ListView tentará minimizar o consumo de memória e a velocidade de execução reciclando as células da lista. Esse modo nem sempre oferece melhoria de desempenho e testes devem ser realizados para determinar quaisquer melhorias. No entanto, é a escolha preferida e deve ser usada nas seguintes circunstâncias:

  • Cada célula possui um número pequeno a moderado de ligações.
  • O BindingContext de cada célula define todos os dados da célula.
  • Cada célula é bastante semelhante, com o modelo de célula inalterado.

Durante a virtualização, a célula terá seu contexto de associação atualizado e, portanto, se um aplicativo usar esse modo, ele deverá garantir que as atualizações de contexto de associação sejam tratadas adequadamente. Todos os dados sobre a célula devem vir do contexto de ligação ou poderão ocorrer erros de consistência. Esse problema pode ser evitado usando a vinculação de dados para exibir os dados da célula. Como alternativa, os dados da OnBindingContextChanged célula devem ser definidos na substituição, em vez de no construtor da célula personalizada, conforme demonstrado no exemplo de código a seguir:

public class CustomCell : ViewCell
{
    Image image = null;
    
    public CustomCell ()
    {
        image = new Image();
        View = image;
    }
    
    protected override void OnBindingContextChanged ()
    {
        base.OnBindingContextChanged ();
        
        var item = BindingContext as ImageItem;
        if (item != null) {
            image.Source = item.ImageUrl;
        }
    }
}

Para obter mais informações, consulte Alterações de contexto de associação.

No iOS e no Android, se as células usarem renderizadores personalizados, elas deverão garantir que a notificação de alteração de propriedade seja implementada corretamente. Quando as células são reutilizadas, seus valores de propriedade são alterados quando o contexto de associação é atualizado para o de uma célula disponível, com PropertyChanged eventos sendo gerados. Para obter mais informações, consulte Personalizando um ViewCell.

RecycleElement com um DataTemplateSelector

Quando a ListView usa a DataTemplateSelector para selecionar um DataTemplate, a RecycleElement estratégia de cache não armazena em cache DataTemplates. Em vez disso, um DataTemplate é selecionado para cada item de dados da lista.

Observação

A RecycleElement estratégia de cache tem um pré-requisito, introduzido em Xamarin.Forms 2.4, que quando a DataTemplateSelector é solicitado a selecionar a, cada DataTemplate um DataTemplate deve retornar o mesmo ViewCell tipo. Por exemplo, dado um ListView com um DataTemplateSelector que pode retornar MyDataTemplateA (onde MyDataTemplateA retorna um ViewCell do tipo MyViewCellA) ou MyDataTemplateB (onde MyDataTemplateB retorna um ViewCell do tipo MyViewCellB), quando MyDataTemplateA é retornado ele deve retornar MyViewCellA ou uma exceção será lançado.

RecycleElementAndDataTemplate

A RecycleElementAndDataTemplate estratégia de cache se baseia na RecycleElement estratégia de cache, garantindo adicionalmente que, quando a ListView usa a DataTemplateSelector para selecionar um DataTemplate, DataTemplates são armazenados em cache pelo tipo de item na lista. Portanto, DataTemplates são selecionados uma vez por tipo de item, em vez de uma vez por instância de item.

Observação

A RecycleElementAndDataTemplate estratégia de cache tem um pré-requisito de que o DataTemplates retornado pelo DataTemplateSelector deve usar o DataTemplate construtor que usa um Type.

Defina a estratégia de cache

O ListViewCachingStrategy valor de enumeração é especificado com uma sobrecarga de ListView construtor, conforme mostrado no exemplo de código a seguir:

var listView = new ListView(ListViewCachingStrategy.RecycleElement);

Em XAML, defina o CachingStrategy atributo conforme mostrado no XAML abaixo:

<ListView CachingStrategy="RecycleElement">
    <ListView.ItemTemplate>
        <DataTemplate>
            <ViewCell>
              ...
            </ViewCell>
        </DataTemplate>
    </ListView.ItemTemplate>
</ListView>

Esse método tem o mesmo efeito que definir o argumento da estratégia de cache no construtor em C#.

Defina a estratégia de cache em um ListView subclassificado

Definir o atributo CachingStrategy do XAML em uma subclasse ListView não produzirá o comportamento desejado, porque não há propriedade CachingStrategy em ListView. Além disso, se o XAMLC estiver habilitado, a seguinte mensagem de erro será produzida: Nenhuma propriedade, propriedade associável ou evento encontrado para 'CachingStrategy'

A solução para esse problema é especificar um construtor na subclasse ListView que aceite um ListViewCachingStrategy parâmetro e o passe para a classe base:

public class CustomListView : ListView
{
    public CustomListView (ListViewCachingStrategy strategy) : base (strategy)
    {
    }
    ...
}

Em seguida, o ListViewCachingStrategy valor de enumeração pode ser especificado a partir de XAML usando a x:Arguments sintaxe:

<local:CustomListView>
    <x:Arguments>
        <ListViewCachingStrategy>RecycleElement</ListViewCachingStrategy>
    </x:Arguments>
</local:CustomListView>

Sugestões de desempenho do ListView

Existem muitas técnicas para melhorar o desempenho de um ListView. As sugestões a seguir podem melhorar o desempenho do seu ListView

  • Associe a ItemsSource propriedade a uma IList<T> coleção em vez de uma IEnumerable<T> coleção, pois IEnumerable<T> as coleções não dão suporte ao acesso aleatório.
  • Use as células internas (como TextCell / SwitchCell ) em vez de ViewCell sempre que puder.
  • Use menos elementos. Por exemplo, considere usar um único FormattedString rótulo em vez de vários rótulos.
  • Substitua o ListView por a TableView ao exibir dados não homogêneos – ou seja, dados de tipos diferentes.
  • Limite o uso do Cell.ForceUpdateSize método. Se usado em excesso, prejudicará o desempenho.
  • No Android, evite definir a visibilidade ou a cor do separador de linha de um ListViewdepois que ele tiver sido instanciado, pois isso resulta em uma grande penalidade de desempenho.
  • Evite alterar o layout da célula com base no BindingContext. A alteração do layout incorre em grandes custos de medição e inicialização.
  • Evite hierarquias de layout profundamente aninhadas. Use AbsoluteLayout ou Grid para ajudar a reduzir o aninhamento.
  • Evite específico LayoutOptions diferente de Fill (Fill é o mais barato de calcular).
  • Evite colocar um ListView dentro de um ScrollView pelos seguintes motivos:
    • O ListView implementa sua própria rolagem.
    • O ListView não receberá nenhum gesto, pois eles serão tratados pelo pai ScrollView.
    • O ListView pode apresentar um cabeçalho e rodapé personalizados que rolam com os elementos da lista, potencialmente oferecendo a funcionalidade para a qual o ScrollView foi usado. Para obter mais informações, consulte Cabeçalhos e rodapés.
  • Considere um renderizador personalizado se precisar de um design específico e complexo apresentado em suas células.

AbsoluteLayout tem o potencial de executar layouts sem uma única chamada de medida, tornando-o altamente eficiente. Se AbsoluteLayout não puder ser usado, considere RelativeLayout. Se estiver usando RelativeLayout, passar Constraints diretamente será consideravelmente mais rápido do que usar a API de expressão. Esse método é mais rápido porque a API de expressão usa JIT e, no iOS, a árvore precisa ser interpretada, o que é mais lento. A API de expressão é adequada para layouts de página em que é necessária apenas no layout inicial e na rotação, mas em ListView, em que é executada constantemente durante a rolagem, prejudica o desempenho.

A criação de um renderizador personalizado para uma ListView ou suas células é uma abordagem para reduzir o efeito dos cálculos de layout no desempenho de rolagem. Para obter mais informações, consulte Personalizando um ListView e Personalizando um ViewCell.