por Ashita Prasad ( LinkedIn , Twitter ), fluttergems.dev

Este é o quarto artigo da série “Dominando Dart & Flutter DevTools” de artigos detalhados. Neste artigo, você aprenderá sobre a ferramenta Network View do DevTools usando um exemplo da vida real. Caso você queira conferir algum outro artigo desta série, basta clicar no link abaixo:

• Parte 1: Introdução e Instalação
• Parte 2: Inspetor Flutter
• Parte 3: Ferramenta de tamanho do aplicativo
• Parte 4: Exibição de rede [Você está aqui]
• Parte 5: Exibição de registro
• Parte 6: Visualização do Perfilador de CPU
• Parte 7: Visão de Memória
• Parte 8: Visão de Desempenho

Os aplicativos frequentemente usam a Internet para autenticar usuários, acessar recursos de rede, fazer chamadas de API e conectar-se a servidores ou serviços de back-end. Essa atividade de rede tem um impacto direto na experiência do usuário, pois uma latência menor leva a uma melhor capacidade de resposta do aplicativo e faz com que o usuário acredite que o aplicativo é mais rápido.

Monitorar o tráfego de rede pode nos ajudar a:

• Identifique gargalos e outros problemas de desempenho na comunicação de rede de um aplicativo.
• Inspecione as interações da API cliente-servidor entre o aplicativo e o back-end.
• Identifique se alguma solicitação de rede não identificada/maliciosa está sendo feita por algum pacote de terceiros.
• Identifique se há algum aumento na atividade da rede devido à redundância nas solicitações de API que estão sendo feitas.
• Analise e reduza o uso de dados móveis do aplicativo, pois é caro.

Exibição de Rede

A ferramenta Network View nos ajuda a monitorar e inspecionar qualquer tráfego HTTP, HTTPS ou web socket de um aplicativo Dart ou Flutter.

Para entender melhor a utilidade da ferramenta Network View, vamos realizar um exercício de estudo de caso.

Etapa 1: obtendo o código-fonte

Abra o repositório abaixo mencionado .

Abra o repositório no GitHub conforme mostrado abaixo.

Clique no botão verde <> Code, visite a Localguia e clique Download ZIPpara baixar o código-fonte deste exercício.

Extraia o arquivo usando qualquer ferramenta de descompactação.

Agora temos uma cópia local da fonte na pasta network_view_demo-master.

Etapa 2: abrindo o projeto no código VS

Inicie o VS Code, abra a pasta do projeto no VS Code e vá para pubspec.yamlo arquivo.

Clique em Get Packagespara buscar todos os pacotes necessários para este projeto.

Etapa 3: iniciando a exibição de rede no código VS

Antes de iniciarmos a ferramenta Network View, devemos executar o aplicativo.

Clique em No Devicena barra de status e selecione um dispositivo de destino. Se um dispositivo padrão já estiver selecionado, você pode clicar nele e alterar o dispositivo de destino.

Iremos em frente e selecionaremos um emulador Android como o dispositivo de destino.

Agora, clique Runpara executar o aplicativo (função principal) conforme a imagem abaixo.

Agora, o Network View pode ser iniciado usando as seguintes instruções:

Click Dart DevTools in status bar > 
Click Open DevTools in Web Browser > Click Network tab

      
                

                    
                    
                
            

Você pode pausar o monitoramento do tráfego de rede clicando no botão Pausar no canto superior esquerdo da página.

Da mesma forma, você pode retomar o monitoramento clicando em Resume e limpar o log de tráfego de rede existente usando o botão Clear .

Etapa 4: Monitorando o Tráfego de Rede

Depois de executar o aplicativo, você verá a tela principal contendo dois botões para iniciar os dois cenários a seguir:

• Cenário #1 — Neste cenário, fazemos solicitações de API buscando diferentes tipos de respostas e monitoramos o tráfego de rede usando o Network View.
• Cenário nº 2 — Depois de investigar o tráfego de rede no Cenário nº 1, fazemos as alterações necessárias para otimizar a atividade da rede, resultando em melhor desempenho do aplicativo.

Cenário 1

Mantenha a guia RedeLaunch Scenario #1 aberta e clique no botão.

Ele carrega a primeira página do cenário (conforme mostrado abaixo), que contém um Scaffold, com um único cartão no corpo. O cartão contém uma miniatura e um texto. Há também um botão de ação flutuante na parte inferior.

Se dermos uma olhada no tráfego de rede, duas GETsolicitações foram feitas para URLs externas - jsonplaceholder.typicode.come via.placeholder.com.

Agora vamos dar uma olhada no código para entender porque essas requisições estão sendo feitas.

@override
Widget build(BuildContext context) {
...
body: FutureBuilder(
future: getData(),
builder: (context, AsyncSnapshot<dynamic> snapshot) {
...

Future<dynamic> getData() async {
var response = await http.get(
Uri.parse("https://jsonplaceholder.typicode.com/photos"),
);
if (response.statusCode == 200) {
return jsonDecode(response.body);
} else {
throw Exception('Failed to load photos');
}
}

A próxima solicitação GET é enviada pelo Image.networkwidget (veja o código abaixo) que carrega uma miniatura de imagem do recurso de URL fornecido —https://via.placeholder.com/150/92c952

return Card(
child: ListTile(
leading: Image.network(cardData['thumbnailUrl']),
title: Text(cardData['title']),
),
);

Vamos selecionar o https://jsonplaceholder.typicode.com/photospedido.

Conforme mostrado abaixo, podemos inspecionar informações gerais, informações de tempo, cabeçalhos de solicitação e resposta e o conteúdo da resposta que, neste caso, é uma lista de 5.000 itens, onde cada item representa os dados correspondentes a uma foto com um albumId, id, titlee .urlthumbnailUrl

Podemos verificar os detalhes (título e URL da miniatura) do item do cartão visível, conforme mostrado abaixo.

Os detalhes são os mesmos do primeiro item do mapa mostrado nos dados de resposta abaixo.

Agora, vamos clicar na segunda solicitação GET que foi feita https://via.placeholder.com/150/92c952para buscar a miniatura.

Conforme mostrado abaixo, além dos outros detalhes, desta vez a guia de resposta também exibe a imagem buscada junto com os metadados da imagem. Assim, podemos visualizar facilmente uma grande variedade de dados de resposta usando esta ferramenta, seja texto, json ou imagem.

Quando iniciamos a página Cenário nº 1 pela primeira vez, apenas um único cartão é visível, pois o valor de _counteré inicializado como 1o que representa o número de itens que o construtor de exibição de lista pode criar.

Ao clicar no botão de ação flutuante podemos incrementar o valor de _counterpara exibir mais cartas usando o _incrementCounter()método.

void _incrementCounter() {
setState(() {
_counter++;
});
}

Ao inspecionar o tráfego de rede conforme mostrado abaixo, podemos observar que a solicitação da API de dados https://jsonplaceholder.typicode.com/photosestá sendo feita repetidamente.

Isso ocorre porque o FutureBuilderestá conectado à função de computação assíncrona getData(). Como esse futuro é criado ao mesmo tempo que o FutureBuilder, toda vez que o widget é reconstruído devido a qualquer alteração no estado, a tarefa assíncrona é reiniciada. Assim, getData()o método é executado repetidamente e uma nova solicitação API GET de dados de foto é feita toda vez que o botão de ação flutuante é clicado. Isso não apenas faz com que os mesmos dados sejam buscados repetidamente, mas também devido a essa maior atividade de rede, a resposta do aplicativo é lenta, pois podemos ver um indicador de progresso circular após cada clique.

Nesse cenário, podemos ver como o tráfego de rede pode fazer com que o aplicativo pareça ter menos desempenho devido ao tráfego de rede desnecessário.

A melhor prática para evitar essas chamadas repetidas à API é evitar criar e chamar um futuro no build()método, ou seja, o futuro associado a FutureBuilderdeve ser calculado fora do build()método.

Vamos dar uma olhada no Cenário nº 2 que aborda esse problema.

Cenário #2

O código-fonte e as instruções de configuração para este cenário são os mesmos do Cenário nº 1.

Execute o aplicativo e clique no Launch Scenario #2botão.

Quando a tela é carregada pela primeira vez, as solicitações feitas são as mesmas do Cenário #1.

Mas, agora, quando pressionamos o botão de ação flutuante para adicionar mais cartões, não há mais solicitações sendo feitas para buscar os dados da foto e apenas as solicitações de imagem de espaço reservado são feitas.

Vamos agora dar uma olhada mais de perto no código do Cenário #2.

O problema de solicitação de API repetida foi resolvido chamando getData()o initState()método que é chamado apenas uma vez antes do primeiro build. Neste caso, o resultado do futuro getData()é armazenado na variável de estado _data.

class _Scenario2PageState extends State<Scenario2Page> {
     ...
late Future<dynamic> _data;
...
@override
void initState() {
super.initState();
_data = getData();
}
...

@override
Widget build(BuildContext context) {
...
body: FutureBuilder(
future: _data,
...

Agora, toda vez que pressionamos o botão de ação flutuante, o build()método é acionado. Mas, como o valor de future _dataagora está disponível no estado atual, as solicitações de API de dados não estão mais sendo feitas e apenas as solicitações de imagem de espaço reservado estão sendo enviadas.

Assim, no Cenário #2, conseguimos detectar e resolver o tráfego de rede redundante observado no Cenário #1. Como o futuro agora está sendo calculado fora do método de construção, não estamos mais fazendo solicitações de API redundantes.

Alguns Recursos Adicionais — Pesquisar, Filtrar e Copiar

O Network View também fornece alguns recursos adicionais, como Search & Filter, para navegar pelos resultados do tráfego de rede.

Na guia Exibição de rede do Cenário nº 2, vamos inserir uma string de pesquisa que pode ocorrer na coluna URI. Neste caso, vamos inserir o termo via.

Todo o URI de tráfego de rede que contém o termo viaé destacado conforme mostrado abaixo. Agora, você pode facilmente clicar no pedido e ver mais detalhes.

Outro recurso avançado localizado ao lado da ferramenta de pesquisa é a ferramenta de filtro .

Ao clicar no botão, uma caixa de diálogo aparece com as instruções para construir uma consulta de filtro conforme mostrado abaixo.

Seguindo as instruções, podemos criar uma consulta de filtro type:pngcomo mostrado na imagem abaixo para visualizar todas as solicitações de imagem png que fizemos.

Viola! Todas as solicitações com tipo de resposta pngsão exibidas (imagem abaixo) e o tráfego de qualquer outro tipo é ocultado.

Para cada solicitação, também temos a opção de copiá-la como cURL.

A solicitação cURL acima copiada acima é a seguinte:

curl --location --request GET 'https://jsonplaceholder.typicode.com/photos' \
--header 'user-agent: Dart/2.18 (dart:io)' \
--header 'accept-encoding: gzip' \
--header 'content-length: 0' \
--header 'host: jsonplaceholder.typicode.com'

Neste artigo, testemunhamos como a ferramenta Network View do DevTools pode ser usada para monitorar e analisar o tráfego de rede de um aplicativo Flutter usando dois cenários:

• No Cenário 1, realizamos uma análise detalhada do tráfego da API gerado pelo aplicativo.
• No Cenário #2, retificamos as solicitações de API redundantes que estavam sendo feitas no Cenário #1, levando a uma melhoria na capacidade de resposta do aplicativo.

Nos artigos restantes desta série, discutimos outras ferramentas disponíveis no pacote DevTools que podem ajudá-lo a criar aplicativos Flutter de alto desempenho. Não se esqueça de conferir os links abaixo para navegar até a ferramenta que deseja aprender a seguir:

• Parte 1: Introdução e Instalação
• Parte 2: Inspetor Flutter
• Parte 3: Ferramenta de tamanho do aplicativo
• Parte 5: Exibição de registro
• Parte 6: Visualização do Perfilador de CPU
• Parte 7: Visão de Memória
• Parte 8: Visão de Desempenho

Agradecimentos especiais a Kamal Shree (GDE — Dart & Flutter) pela revisão deste artigo.