了解畫布應用程式執行階段、資料呼叫流程和效能監視
當使用者開啟畫布應用程式時，應用程式會在顯示任何使用者介面之前，先經歷以下幾個執行階段。 載入應用程式時，它會連線到不同的資料來源—例如 SharePoint、Microsoft Dataverse、SQL 伺服器 (內部部署)、SQL Database 伺服器 (內部部署)、Excel 和 Oracle。
在本文中，您將了解這些不同的執行階段，以及應用程式如何連線至資料來源和您可以用來監視效能的工具。
畫布應用程式中的執行階段
畫布應用程式會在向使用者顯示介面之前，會先經歷以下幾個執行階段：
驗證使用者：系統會提示首次使用者用認證登入應用程式需要的任何連線。 如果該位使用者再次開啟應用程式，系統可能會根據組織的安全性原則再度提示該人員。
取得中繼資料：擷取中繼資料，例如執行應用程式的 Power Apps 平台和必須從中擷取資料的來源。
初始化應用程式：執行 OnStart 屬性中指定的任何工作。
呈現畫面：呈現第一個畫面，其中控制項具有應用程式填入的資料。 如果使用者開啟其他畫面，應用程式會使用相同的程序來呈現它們。
畫布應用程式中的資料呼叫流程
來自畫布應用程式的資料呼叫透過使用 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 監控工具可以幫助您追蹤實際發送到資料來源的內容，以及請求發送和來自伺服器回應的時間戳記。
您可以在本文中了解有關監控工具的更多資訊： 使用監視器偵錯畫布應用程式 。
用戶端上的測量記憶體壓力
若要以圖形方式查看記憶體消耗情況，您可以使用瀏覽器的開發人員工具來分析記憶體。 這可幫助您視覺化堆積大小、文件、節點和接聽程式。 如 Microsoft Edge (Chromium) 開發人員工具概觀中所述，透過使用瀏覽器來分析應用程式的效能。 檢查超出 JS 堆積記憶體閾值的案例。 詳細資訊：修正記憶體問題
