當使用者開啟畫布應用程式時，應用程式會先經過數個執行階段，然後才會顯示任何使用者介面。 當應用程式載入時，它會連線到不同的 資料來源，例如 SharePoint、Microsoft Dataverse、SQL Server （內部部署）、Azure SQL 資料庫 （線上）、Excel 和 Oracle。
在本文中，您將瞭解這些不同的執行階段，以及應用程式如何連線到資料來源，以及可用來監控效能的工具。
畫布應用程式中的執行階段
畫布應用程式會先經過下列執行階段，才能向使用者顯示介面：
驗證使用者：提示首次使用者使用認證登入應用程式所需的任何連線。 如果該使用者再次開啟應用程式，系統可能會再次提示該人員，視組織的安全性原則而定。
取得中繼資料：擷取中繼資料，例如執行應用程式的 Power Apps 平台版本，以及必須從中擷取資料的來源。
初始化應用程式：執行 OnStart 屬性中指定的任何工作。
轉譯螢幕：轉譯第一個螢幕，其中包含應用程式填入資料的控制項。 如果使用者開啟其他畫面，應用程式會使用相同的程式來轉譯它們。
畫布應用程式中的資料呼叫流程
來自 Canvas 應用程式的資料呼叫會透過 OData 協定使用連接器，將資料傳送至表格資料來源。OData 請求流向後端層，與目標資料來源取得聯繫並擷取用戶端的資料，或將資料提交至資料來源。 啟用 API 的動作型連接器以相同的方式運作。
了解 OData 和 API 的要求如何在畫布應用程式中流動，將有助於您最佳化畫布應用程式效能和後端資料來源。
在本節中，您將瞭解資料呼叫如何在具有不同資料來源類型的畫布應用程式中進行。
使用線上資料來源的資料呼叫流程
下圖顯示畫布應用程式中的一般資料要求 （左側） 如何傳輸伺服器端層、連線到目標資料來源 （右側），然後將資料傳回用戶端。
上圖中的每一層都可以快速執行，或在處理要求時遇到一些額外負荷。 在許多應用程式中，通常有兩個特定位置會出現明顯的系統負擔：
處理要求時的後端資料來源。
用戶端 ，在傳送要求時，或在處理堆積記憶體上接收的資料，並執行相關聯的 JavaScript 函式，以處理要顯示在畫面中的資料。
使用內部部署資料閘道的資料呼叫流程
如果畫布應用程式連線到內部部署資料來源，例如 SQL Server，您必須有另一個層，稱為 內部部署資料閘道。 此閘道是存取內部部署資料來源的必要條件。 它負責將 OData 協定請求轉換為 SQL 資料操作語言 （DML） 語句。
下圖顯示內部部署資料閘道的放置位置及方式，以處理資料要求。
如果應用程式使用內部部署的資料來源，則資料閘道的位置和規格也會影響資料呼叫的效能。
使用 Microsoft Dataverse 的資料呼叫流程
當您使用 Microsoft Dataverse 做為資料來源時，資料要求會直接移至環境執行個體，而不需通過 Azure API 管理。 因此，相較於其他資料來源，資料呼叫的效能更快。 當您建立新的畫布應用程式時，應用程式預設會連線到 Microsoft Dataverse。
瞭解資料呼叫如何傳輸的高階概念後，您就可以詳細瞭解如何檢閱應用程式效能。 總而言之，效能額外負荷可能發生在任何層，從用戶端、API 管理、連接器、內部部署資料閘道或後端資料來源。
測量效能
Power Apps 監控工具
雖然您可以使用瀏覽器的開發人員工具來查看效能，但 Power Apps 會將監視工具中的呼叫集篩選為僅限於 Power Apps 的呼叫。
Power Apps 監視工具可協助您追蹤實際傳送至資料來源的內容，以及傳送要求和伺服器回應的時間戳記。
您可以在本文中進一步瞭解監視工具： 使用 Monitor 偵錯畫布應用程式 。
測量用戶端上的記憶體壓力
若要以圖形方式查看記憶體耗用量，您可以使用瀏覽器的開發人員工具來分析記憶體。 這可幫助您視覺化堆積大小、文件、節點和接聽程式。 使用瀏覽器分析應用程式的效能，如 Microsoft Edge （Chromium） 開發人員工具概觀中所述。 檢查超過JS堆記憶體閾值的場景。 其他資訊： 修正記憶體問題
