Compreender fases de execução do aplicativo de tela, fluxo de chamadas de dados e monitoramento de desempenho

Quando um usuário abre um aplicativo de tela, o aplicativo segue diversas fases de execução antes de mostrar uma interface do usuário. Enquanto o aplicativo carrega, ele se conecta a diferentes fontes de dados— tais como SharePoint,Microsoft Dataverse, SQL Server (local), Banco de dados SQL do Azure (online), Excel e Oracle.

Neste artigo, você aprenderá mais sobre essas fases de execução diferentes e de como um aplicativo se conecta a fontes de dados, além de ferramentas que você pode usar para monitorar o desempenho.

Fases de execução em aplicativos de tela

Um aplicativo de tela passa pelas seguintes fases de execução antes de mostrar a interface a um usuário:

  1. Autenticar o usuário: solicita que o usuário iniciante entre com credenciais para conexões exigidas pelo aplicativo. Se esse usuário reabrir o aplicativo, ele poderá ser solicitado novamente, dependendo das políticas de segurança da organização.

  2. Obter metadados: recupera metadados, como a versão da plataforma Power Apps na qual o aplicativo é executado e as fontes das quais ele precisa recuperar dados.

  3. Inicializar o aplicativo: executa as tarefas especificadas na propriedade OnStart.

  4. Renderizar as telas: renderiza a primeira tela com os controles que o aplicativo popula com dados. Se o usuário abrir outras telas, o aplicativo as renderizará usando o mesmo processo.

Fluxo de chamada de dados em aplicativos de tela

As chamadas de dados em aplicativos de tela enviam dados para fontes de dados tabulares usando conectores por meio do protocolo OData. As solicitações de OData fluem para camadas de back-end a fim de chegar à fonte de dados de destino e recuperar dados do cliente ou confirmar dados da fonte de dados. Conectores baseados em ações que permitem que APIs funcionem da mesma maneira.

O reconhecimento de como solicitações de OData e API percorrem aplicativos de tela podem ajudar você a otimizar o desempenho do aplicativo de tela e das fontes de dados de back-end.

Nesta seção, você aprenderá sobre como a chamada de dados flui em aplicativos de tela com diferentes tipos de fonte de dados.

Fluxo de chamadas de dados com fontes de dados online

O diagrama a seguir mostra como uma solicitação de dados típica em um aplicativo de tela (no lado esquerdo) percorre camadas do servidor, alcança a fonte de dados de destino (no lado direito) e retorna os dados ao cliente.

Fluxo de chamada de dados típico para todos os conectores, exceto o conector para Dataverse.

Cada camada no diagrama anterior pode ser executada rapidamente ou encontrar certa sobrecarga ao processar a solicitação. Em muitos aplicativos, dois pontos específicos costumam apresentar sobrecarga perceptível:

  • Fonte de dados de back-end ao processar a solicitação.

  • Cliente ao enviar a solicitação ou ao manipular os dados recebidos na memória heap e executar as funções JavaScript associadas para processar dados a serem exibidos em telas.

Fluxo de chamada de dados com gateway de dados local

Se um aplicativo de tela se conectar a uma fonte de dados local como o SQL Server, você precisará ter outra camada chamada de gateway de dados local. Este gateway é obrigatório para acessar fontes de dados locais. Ele se encarrega de converter o protocolo de solicitações OData em instruções SQL DML (Data Manipulation Language).

O diagrama a seguir mostra onde e como o gateway de dados local é utilizado para processar solicitações de dados.

Fluxo de chamada de dados para um gateway de dados local.

Se o aplicativo usar uma fonte de dados local, a localização e a especificação do gateway de dados também afetarão o desempenho das chamadas de dados.

Fluxo de chamada de dados com o Microsoft Dataverse

Quando você usa o Microsoft Dataverse como fonte de dados, as solicitações de dados vão diretamente para a instância do ambiente — sem passar pelo Gerenciamento de API do Azure. Por isso, o desempenho das chamadas de dados é muito mais rápido em comparação com o restante das fontes de dados. O aplicativo é, por padrão, conectado ao Microsoft Dataverse quando você cria um novo aplicativo de tela.

Fluxo de chamada de dados com o Microsoft Dataverse.

Ao compreender esse conceito de alto nível do percursos das chamadas de dados, você pode obter detalhes da avaliação de desempenho do seu aplicativo. Em resumo, a sobrecarga de desempenho pode ocorrer em qualquer camada — cliente, Gerenciamento de API, conector, gateway de dados local ou fontes de dados de back-end.

Medição do desempenho

Ferramenta de monitoramento do Power Apps

Embora você possa usar as ferramentas para desenvolvedores do navegador para ver o desempenho, o Power Apps subdivide o conjunto de chamadas na ferramenta Monitoramento apenas àquelas que sejam do Power Apps.

A ferramenta de monitoramento do Power Apps pode ajudar você a rastrear o que realmente é enviado para a fonte de dados e os carimbos de data/hora de quando as solicitações são enviadas e as respostas vêm do servidor.

Você pode saber mais sobre a ferramenta de monitoramento neste artigo: Depuração dos aplicativos de tela com o monitor.

Ferramenta de monitoramento.

Avaliação da pressão da memória sobre o cliente

Para consultar o consumo de memória de maneira gráfica, você pode usar as ferramentas de desenvolvedor do navegador para criar o perfil da memória. Isso ajuda a visualizar o tamanho do heap, documentos, nós e ouvintes. Crie um perfil de desempenho do aplicativo usando um navegador, conforme descrito em Visão geral de Ferramentas de Desenvolvedor do Microsoft Edge (Chromium). Verifique os cenários que excedem o limite de memória do heap do JS. Mais informações: Resolva problemas de memória

Gráfico de uso da memória.

Próximas etapas

Conteúdos de dados pequenos

Confira também

Solução de problemas do Power Apps

Observação

Você pode nos falar mais sobre suas preferências de idioma para documentação? Faça uma pesquisa rápida. (Observe que esta pesquisa está em inglês)

A pesquisa levará cerca de sete minutos. Nenhum dado pessoal é coletado (política de privacidade).