Em aplicações que permitem realizar rastreamento de ativos, ou exibição de muitos marcadores (Markers), dependendo da quantidade exigirá que tenha algumas estratégias para minimizar tanto a carga de dados quanto, a manipulação dos mesmos..
No meu caso tive uma quantidade absurda de ativos para tratar acima de 50k.. Logo tive que aplicar medidas para melhorar o desempenho e de forma e tornar fluída a navegação na aplicação..
Utilizei o angular-google-maps como lib para construção da minha app, bem documentado e com a comunidade bastante ativa, não vou entrar em detalhes de implementação apenas apresentar algumas lições aprendidas.
Estratégias utilizadas:
- Divisão em Layers
- Utilizar zoom para exibir/ocultar Layers
- Criação de Cluster
- Filtrar ao selecionar o Cluster
- Cache da primeira Layer
- Regras de limpeza da Layer
- Eventos em Lazy-load (mouseover, mouseout, click, blclick..)
Vamos aos Problema/Estratégia
Problema 1# - Plotagem dos diversos ativos no mapa, ou seja somente exibir os marcadores.
Estratégia 1# - Criação de diferentes camadas (Layers), criando hierarquia entre os ativos de formar que a exibir inicialmente 1 Camada do mais externo, e medida que o usuário for interagindo com essa camada ir exibindo as demais, sem a necessidade de plotar todos de uma só vez. Na API utilizada para cada layer foi criado uma nova tag <ui-gmap-markers>.
Problema 2# - Após a plotagem dos ativos, como haviam muitos foi possível verificar que conforme o zoom iria diminuindo, ou seja se afastando da cidade.. para níveis de estados, havia muita informação misturada poluindo a tela.
Estratégia 2# - Conforme os níveis de zoom iriam aumentando seriando exibidas novas Layers, e o movimento oposto foi adicionado o comportamento para ocultar as layers. Na API mencionada acima evento utilizado foi o idle do mapa, nesse evento é ideal pois só dispara quando o usuário termina a ação por completo..
Problema 3# - Ainda muita informação com o Zoom em nível de país.. =/
Estratégia 3# - Habilitar o Cluster de uma layer inicial com os "parents", para aplicar é bem fácil a API já implementa por debaixo dos panos, basta na tag de markers preencher os attrs doCluster="true" e clusterOptions="map.clusterOptions", a claro tem mais tags e inclusive esses já estão depreciados na versão nova do framework para mais detalhes acesse.
Problema 4# - Ainda com isso continua lento.
Estratégia 4# - A cada seleção de cluster filtrar somente os resultados ou children vinculados a esse ativo parent, de forma que as camadas sub-sequentes tenham relação com essa seleção. Como fazer? simples na API se tem typeEvents ou clusterEvents, que irá referenciar os eventos do cluster, o evento de click do cluster retornar dois objetos nessa API (cluster, clusterModels) esse segundo é isso mesmo oque vc está pensando os markers inclusos nesse cluster, logo a partir dele nós podemos filtrar e modificar as camadas sub-sequentes com base nesse markers "parent".
Problema 5# - Demora no load inicial dos ativos.
Estratégia 5# - Criar um endpoint específico para a layer parent, e trabalhar com cache de 1 instância, nos browsers atuais vc pode armazenar dados no localStorage ou sessionStorage do cliente.. tem limite fica ligado para não estourar a cota, enfim com consciência! Além de armazenar os dados é interessante armazenar tbm a data de criação e criar regras de expiração do dado.
Problema 6# - Ao manipular as camadas sub-sequentes, é preciso fazer algumas escolhas de como irá se comportar, qual mínimo de parent para exibir os children.. no meu caso escolhi 4, mas se houve mais irá aparecer junto no mapa e o usuário pode querer visualizar childrens de outros parents ali perto.. dessa as camadas sub-sequentes são afetadas e acabam crescendo demasiadamente..
Estratégia 6# - Criar regras de limpeza de layers sub-sequentes, de forma que tenha um limite máximo de childrens a serem exibidos, e quando esse limite for atingido a layers é tratada, nesse caso o evento utilizado já seria do marker parent exibido, no event click podemos adicionar esse comportamento para checar/aplicar essa regra..
Problema 7# - Tamanho das requisições muito grandes..
Estratégia 7# - Enxugar a resposta do endpoint, separar o eventos de exibição detalhes todos em lazy load, para buscar o que for necessário somente quando for necessário. Cada marker tem seus próprios eventos de mouseout e mouseover que pode ser utilizado para realizar essas operações, uma dica seria prevenir o envio de várias requisições, com um temporizador que checa se o usuário está realmente esperando com o mouseout on! cuidado pois o mouseout é chamado a cada passada de mouse ae se não houver esse tratamento de temporização pode acabar criando um overhead no seu endpoint.
Bem é isso aí, com esse esforço consegui melhorar consideravelmente o desempenho da minha aplicação.
Nenhum comentário:
Postar um comentário