Compreender as fases de execução, o fluxo de chamada de dados e a monitorização do desempenho da aplicação de tela

Quando um utilizador abre uma aplicação de tela, a aplicação passa por diversas fases de execução antes de mostrar a interface de utilizador. Enquanto a aplicação carrega, liga-se a diferentes origens de dados—, tais como o SharePoint, Microsoft Dataverse, SQL Server (no local), Azure SQL Database (online), Excel e Oracle.

Neste artigo, vai conhecer estas diferentes fases de execução e como um aplicação se liga às origens de dados e sobre as ferramentas que pode usar para monitorizar o desempenho.

Fases de execução em aplicações de tela

Uma aplicação de tela passa pelas seguintes fases de execução antes de mostrar a interface a um utilizador:

1. Autenticar o utilizador: solicita ao utilizador pela primeira vez que inicia sessão com credenciais para quaisquer ligações que a aplicação precise. Se esse utilizador voltar a abrir a aplicação, poderá ter de iniciar sessão novamente com essas credenciais, dependendo das políticas de segurança da organização.

2. Obter metadados: obtém metadados, tais como a versão da plataforma Power Apps em que a aplicação é executada e as origens a partir das quais tem de obter os dados.

3. Inicializar a aplicação: realiza todas as tarefas especificadas na propriedade OnStart.

4. Compor os ecrãs: compõe o primeiro ecrã com controlos que a aplicação preenche com dados. Se o utilizador abrir outros ecrãs, a aplicação irá compô-los recorrendo ao mesmo processo.

Fluxo de chamada de dados em aplicações de tela

As chamadas de dados de aplicações de tela enviam dados para origens de dados tabulares usando conectores através do protocolo OData. Os pedidos de OData fluem para as camadas de back-end para contactar a origem de dados de destino e obter dados para o cliente ou consolidar dados para a origem de dados. Conectores baseados em ações que permitem às APIs funcionar da mesma maneira.

A compreensão de como os pedidos OData e de API viajam em aplicações de tela pode ajudá-lo a otimizar o desempenho da sua aplicação de tela e as suas origens de dados de back-end.

Nesta secção, vai aprender sobre como a chamada de dados flui em aplicações de tela com diferentes tipos de origem de dados.

Fluxo de chamada de dados com origens de dados online

O diagrama seguinte mostra como um pedido típico de dados numa aplicação de tela (no lado esquerdo) percorre camadas do lado do servidor e contacta a origem de dados de destino (no lado direito) e, em seguida, obtém os dados do cliente.

Cada camada no diagrama anterior pode realizar-se rapidamente, ou deparar-se com alguma sobrecarga durante o processamento do pedido. Em muitas aplicações, dois pontos particulares podem geralmente apresentar sobrecarga visível:

• Origem de dados de back-end: enquanto processa o pedido.

• Cliente: ao enviar o pedido—ou manipulando os dados recebidos na memória de área de dados dinâmica, e executando as funções JavaScript associadas para processar dados para mostrar em ecrãs.

Fluxo de chamada de dados com gateway de dados no local

Se uma aplicação de tela se ligar a uma origem de dados no local, como o SQL Server, precisa de ter outra camada, chamada de um gateway de dados no local. Este gateway é obrigatório para aceder a origens de dados no local. Encarrega-se de converter pedidos do protocolo OData para instruções Idioma de Manipulação de Dados (DML) do SQL.

O diagrama seguinte mostra onde e como o gateway de dados no local é colocado para processar os pedidos de dados.

Se a aplicação utilizar uma origem de dados no local, a localização e a especificação do gateway de dados também afeta o desempenho das chamadas de dados.

Fluxo de chamada de dados com Microsoft Dataverse

Quando utiliza Microsoft Dataverse como origem de dados, os pedidos de dados vão diretamente para o ambiente—sem passar por Azure API Management. Como tal, o desempenho das chamadas de dados é mais rápido em comparação com as restantes origens de dados. A aplicação está ligada por predefinição a Microsoft Dataverse quando cria uma nova aplicação de tela.

Com a compreensão deste conceito de alto nível de como os dados chamam viajam, pode entrar nos detalhes da revisão de desempenho da sua aplicação. Em resumo, a sobrecarga de desempenho pode acontecer em qualquer uma das camadas—do cliente, Gestão de API, conector, gateway de dados no local ou origens de dados de back-end.

Medir desempenho

Ferramenta de monitorização do Power Apps

Embora possa usar as ferramentas de programação do browser para ver o desempenho, o Power Apps subdivide o conjunto de chamadas na ferramenta Monitorização apenas para as do Power Apps.

A ferramenta de monitorização do Power Apps pode ajudá-lo a rastrear o que realmente é enviado à origem de dados e os carimbos de data/hora de quando os pedidos são enviados e as respostas vêm do servidor.

Pode obter mais informações sobre a ferramenta de monitorização neste artigo: Depurar aplicações de tela com o Monitor.

Medir a pressão da memória no lado do cliente

Para ver o consumo de memória de forma gráfica, pode usar as ferramentas de programação do seu browser para criar o perfil da memória. Ajuda-o a visualizar o tamanho da pilha, documentos, nós e ouvintes. Perfile o desempenho da aplicação utilizando um browser, conforme descrito na Descrição geral das Ferramentas de Programação do Microsoft Edge (Chromium). Verifique os cenários que excedem o limiar de memória da pilha JS. Mais informações: Corrigir problemas de memória

Próximos passos

Payloads de dados pequenos

Consulte também

Resolver problemas para o Power Apps

Nota

Pode indicar-nos as suas preferências no que se refere ao idioma da documentação? Responda a um breve inquérito. (tenha em atenção que o inquérito está em inglês)

O inquérito irá demorar cerca de sete minutos. Não são recolhidos dados pessoais (declaração de privacidade).