一般畫布應用程式的效能問題與解決辦法
您可以使用各種資料來源來建置畫布應用程式。 根據業務需求和要設計應用程式的案例，選擇資料來源和連接器。 對於企業應用程式，推薦使用 Microsoft Dataverse 資料來源，因為具有多項效能優勢。 對於具有少量交易的應用程式，您可以使用環境中的任何其他可用資料來源。
對於應用程式的效能考量，請思考應用程式發佈後將使用的使用者數目；建立、擷取、更新和刪除 (CRUD) 交易的數目；資料互動的類型；地理存取；以及使用者擁有的裝置類型。
在本文中，您將了解導致畫布應用程式執行速度降低的常見效能問題，以及如何解決這些問題。 此資訊將幫助您根據業務方案和發展來提高應用程式效能。
我們會先探討無論使用哪種連接器，都可能發生的常見效能問題。 在稍後的章節中，您將了解各種連接器特有的效能問題和解決方案。
在開始之前，請確保您了解畫布應用程式執行階段和資料呼叫流程。 另外，請參閱畫布應用程式低效能的常見來源，以了解在設計或更新畫布應用程式時可避免的常見陷阱。
大型資料集在不同平台上載入緩慢
在不同的平台 (例如 iOS 或 Android) 上載入大量資料時，應用程式的效能可能會有所不同。 這種變化是因為每個平台的網路要求限制不同。 例如，不同平台允許的同時網路要求數目可能不同。 這種差異可能會對大型資料集的資料載入時間產生重大影響。
建議您僅載入需要立即在換面上顯示的資料。 如需其他資料，請分頁並快取您的資料。 詳細資訊：改善畫布應用程式效能的提示和最佳做法
擷取的資料行太多
建議您僅選擇該應用程式必要的資料行。 從資料來源新增更多 (或全部) 資料行將下載資料行中的所有資料。 此動作會造成大量網路額外負荷的呼叫，因此用戶端裝置中會有很高的記憶體使用量。 如果網路頻寬受到限制、裝置記憶體有限或裝置使用舊版處理器，則此問題對行動裝置使用者的影響甚至更大。
例如，如果您使用 Dataverse 做為應用程式的資料來源，請確定您已啟用明確資料行選取範圍功能。 此功能可讓 Power Apps 將資料擷取範圍限制為僅在應用程式中使用的資料行。
若要在畫布應用程式上開啟 [明確資料行選取] 功能，請移至設定 > 即將推出的功能 > 預覽，然後開啟明確資料行選取開關。
舊版或不支援的瀏覽器
使用不支援或舊版瀏覽器的使用者可能會發生效能問題。 確定使用者僅使用支持的瀏覽器來執行畫布應用程式。
地理距離導致的效能緩慢
環境的地理位置以及資料來源與使用者之間的距離可能會影響效能。
建議您的環境靠近使用者。 儘管 Power Apps 使用 Azure 內容傳遞網路來取得內容，但資料呼叫仍從資料來源取得資料。 位於另一個地理位置的資料來源可能會對應用程式的效能產生負面影響。
過度的地理距離會以不同的方式影響效能，例如延遲、降低輸送量、頻寬較低或封包遺失。
允許清單未設定
確定所需的服務 URL 未被封鎖或已新增至防火牆的允許清單中。 有關 Power Apps 必須允許的所有服務 URL 完整清單，請移至 必要的服務。
對不可委派查詢使用不可委派函數和不適當的資料列限制
可委派函數將資料處理委派給資料來源，以最小化用戶端的負荷。 如果無法進行委派，則可以限制不可委派查詢的資料列限制，以使從伺服器架構連線傳回的資料列數保持最佳數量。
對不可委派查詢使用不可委派函數和不適當的資料列限制會增加資料傳輸的額外負荷。 這種負荷導致操作接收資料到用戶端的 JS heap。 確定在可行的情況下為應用程式使用可委派函數，並對不可委派的查詢使用最佳資料列限制。
OnStart 事件需要調整
在載入應用程式時，會執行 OnStart 事件。 使用應用程式 OnStart 屬性中的函數呼叫大量資料將導致應用程式載入速度變慢。 高度相依於其他畫面定義的控制項和值的畫面，將受緩慢畫面瀏覽影響。
以下各節描述了在這些情況下遇到的常見問題。
OnStart 事件中的大量呼叫導致應用程式啟動變慢
在企業中，對中央資料來源的資料呼叫量可能會導致伺服器瓶頸或資源爭用。
使用快取機制最佳化資料呼叫。 單一應用程式可能由多位使用者使用，導致每位使用者到達伺服器端點的多個資料呼叫。 這些資料呼叫可能會出現瓶頸或節流。
由於大量指令碼而在 OnStart 事件發生延遲
OnStart 事件中的大量指令碼是設計畫布應用程式時最常見的錯誤之一。 您應只取得啟動應用程式所需的資料。
在 OnStart 事件中最佳化公式。 例如，您可以將一些函數移到 OnVisible 屬性中。 如此，您即可讓應用程式快速啟動，並在應用程式開啟時繼續執行其他步驟。
詳細資訊：最佳化 OnStart 屬性
提示
建議使用 App.StartScreen 屬性，因為它可以簡化應用程式啟動並提高應用程式的效能。
用戶端的記憶體壓力
檢查畫布應用程式的記憶體使用量很重要，因為在大多數情況下，該應用程式都是在行動裝置上執行。 堆積的記憶體異常，是畫布應用程式在特定裝置上發生當機或凍結 (「停止回應」) 最有可能的原因。
JavaScript (JS) 堆積可能會達到限制，這是因為在用戶端執行了用於新增、加入、篩選、排序或分組資料行的大量指令碼。 在大多數情況下，用戶端堆積中的記憶體不足異常會觸發應用程式崩潰或停止回應。
使用資料來源 (例如 Dataverse 或 SQL Server) 中的資料時，可使用檢視對象來確保加入、篩選、分組或排序發生在伺服器端而不是用戶端。 此方法減少了此類動作的用戶端指令碼負荷。
如果大量用戶端作業 (如加入或分組依據) 發生在具有 2,000 筆或更多記錄之資料集的用戶端，堆積中的物件將增加，導致超出記憶體限制。
大部分瀏覽器的開發人員工具可讓您描繪記憶體。 這可幫助您視覺化堆積大小、文件、節點和接聽程式。 如 Microsoft Edge (Chromium) 開發人員工具概觀中所述，透過使用瀏覽器來分析應用程式的效能。 檢查超出 JS 堆積記憶體閾值的案例。 詳細資訊：修正記憶體問題
SQL Server 連接器的效能考量
您可以使用 Power Apps 中的 SQL Server連接器 連線至 SQL Server 內部部署或 Azure SQL 資料庫。 本節介紹使用此連接器之畫布應用程式的效能相關常見問題和解決方案。 詳細資訊：從 Power Apps 連線至 SQL Server、從 Azure SQL 資料庫建立畫布應用程式
注意
儘管本節參考的 SQL Server 連接器是針對效能問題和解決方案，但大多數建議也適用於使用任何資料庫類型—(如 MySQL 或 PostgreSQL)—做為資料來源的案例。
讓我們看看將 SQL Server 連接器用於畫布應用程式的常見效能問題和解決方案。
N+1 查詢
向伺服器產生太多要求的資源庫會造成 N+1 查詢問題。 N+1 查詢問題是使用資源庫控制項時最常遇到的問題之一。
為避免此問題，請在 SQL 後端中使用檢視物件或變更使用者界面案例。
表格掃描而不是索引搜尋
如果應用程式使用的函數在資料庫中執行查詢而造成表格掃描而不是索引搜尋，則該應用程式可能會變慢。 其他資訊：提示、表格掃描及索引搜尋
要解決此類問題，請在函數中使用 StartsWith 而不是 IN。 對於 SQL 資料來源，StartsWith 運算子將造成索引搜尋，而 IN 運算子將造成索引或表格掃描。
查詢速度緩慢
您可以在 SQL 資料庫上分析和調整緩慢查詢和索引。 例如，如果某個公式在特定資料行上以遞減 (DESC) 順序取得資料，則該排序資料行應具有遞減排序索引。 根據預設，索引鍵建立遞增 (ASC) 排序。
您也可以檢查資料要求的 URL 位址。 例如，以下資料要求程式碼片段 (部分 OData 叫用) 要求 SQL 傳回與該資料列值相符的 500 筆記錄，且按識別碼遞減排序。
Items? \$filter=Column eq 'Value' & Orderby = ID desc & top 500
這有助於理解涵蓋相似要求條件的索引要求。 在此範例中，如果識別碼資料行具有按遞減排列的索引，則查詢將更快地執行。
檢查緩慢查詢的執行方案，以查看是否存在任何表格或索引掃描。 監視執行方案中任何成本過高的關鍵查閱。
其他資訊：
資料庫資源爭用
確保資料來源—SQL 資料庫—沒有資源爭用，例如處理器瓶頸、I/O爭用、記憶體壓力或 tempDB 爭用。 還要檢查鎖定、等待、鎖死和查詢逾時。
提示
使用自動調整，深入探索潛在的查詢效能問題、建議的解決方案，以及自動修正已識別的問題。
胖用戶端或過量要求
在用戶端執行分組依據、篩選依據或加入作業的應用程式，使用來自用戶端裝置的處理器和記憶體資源。 根據資料大小，這些作業可能會在用戶端花費更多的指令碼處理時間，從而增加用戶端上的 JS 推積大小。 對於內部部署資料來源，此問題更加嚴重，因為每個查閱資料呼叫都透過資料閘道傳輸到資料來源。
在這種情況下，請將 SQL 資料庫中的檢視物件用於分組依據、篩選依據，或加入作業。 檢視可以使用選擇性資料行，並移除巨量資料類型的不必要資料行，如：NVARCHAR(MAX)、VARCHAR(MAX) 和 VARBINARY(MAX)。
提示
這種方法也有助於解決 N+1 查詢問題。
傳輸至用戶端的資料大小
根據預設，畫布應用程式透過使用可用資料庫物件中的表格或檢視表來顯示資料。 從表格中擷取所有資料行可能導致回應變慢，尤其是在使用巨量資料 (如 NVARCHAR(MAX)) 時。
將大量資料傳送到用戶端需要時間。 當用戶端的 JS 堆積中有大量資料時，此傳輸還會導致指令碼處理時間延長，如本文稍早所述。
為減少傳輸到用戶端的資料大小，請使用具有應用程式所需的特定資料行檢視，並確保已啟用明確資料行選取範圍，如本文稍早所述。
SQL Server 內部部署的特別考量
將 SQL Server 連接器與內部部署資料閘道一起使用的畫布用程式，其效能可能會受到各種影響。 本節列出針對使用內部部署資料庫來源的一般效能問題和解決方案。
狀況不良的內部部署的資料閘道
組織可以為內部部署的資料閘道定義多個節點。 如果其中一個節點無法連線，則對狀況不良的節點資料要求也無法在可接受的時間範圍內傳回結果，否則在等待一段時間後，它們可能會造成「無法連線」錯誤訊息。
確定所有內部部署的資料閘道狀況良好，並設定為在節點和 SQL 執行個體之間具有最小網絡延遲。
內部部署資料閘道的位置
資料閘道要求對內部部署資料來源進行網路呼叫以解釋 OData 要求。 例如，資料閘道必須理解表格結構描述，才能將 OData 要求翻譯為 SQL 資料操作語言 (DML) 陳述式。 在資料閘道設定在不同位置且資料閘道和 SQL 執行個體之間的網路延遲較長時，會增加額外的系統額外負荷。
在企業環境中，如果預計有大量的資料要求，則建議使用可調整的資料閘道叢集。 檢查在資料閘道節點與 SQL 執行個體間建立的連接數目。
透過檢查內部部署資料閘道或 SQL 執行個體中的同時連線，您的組織可以確定需要擴充的資料閘道節點以及有多少個節點。
資料閘道的可擴縮性
如果您希望從內部部署資料閘道存取大量資料，則僅有單一節點的內部部署資料閘道可能會成為處理大量要求的瓶頸。
內部部署資料閘道的單一節點可能足以處理 200 個或更少的同時連線。 但是，如果所有同時連線都在主動執行查詢，則其他要求將需等待可用的連線。
有關確保內部部署資料閘道根據資料量和要求量進行增減的資訊，請移至監視並最佳化內部部署資料閘道效能。
對 Azure SQL Database 的特別考慮事項
畫布應用程式可以使用 SQL Server 連接器連線至 Azure SQL 資料庫。 使用 Azure SQL 資料庫時出現常見的效能問題之一，是您為業務要求選擇了錯誤的階層。
Azure SQL 資料庫有不同的服務階層可以使用，具備各種功能符合不同的業務需求。 如需更多有關階層的資訊，請移至 Azure SQL 資料庫文件。
對於大量資料要求，一旦達到閾值，您所選階層的資源可能會節流。 這種限制會降低下一組查詢的效能。
檢查 Azure SQL 資料庫的服務階層。 較低階層將有一些限制和約束。 從效能的角度來看，CPU、I/O 輸送量和延遲很重要。 因此，建議您定期檢查 SQL 資料庫的效能，並檢查資源使用率是否超過閾值。 例如，內部部署 SQL Server 通常將 CPU 使用率的閾值設為百分之 75 左右。
SharePoint 連接器的效能考量
您可以使用 SharePoint 連接器，透過使用 Microsoft 清單中的資料來建立應用程式。 您也可以直接從清單檢視表中建立畫布應用程式。 讓我們看看將 SharePoint 資料來源與畫布應用程式一起使用的常見效能問題和解決方案。
太多的動態查閱資料行
SharePoint 支援各種資料類型，包括動態查閱，例如人員、群組和計算。 如果清單定義太多動態資料行，SharePoint 在將資料回傳至執行畫布應用程式的用戶端之前，需要花費更多的時間來操作這些動態資料行。
請勿過度使用中的 SharePoint 動態查閱資料行。 這種過度使用可能會導致可避免的 SharePoint 端額外負荷，造成無法操作資料。 舉例來說，您可以改使用靜態資料行來保留電子郵件別名或人員的名稱。
圖片資料行和附件
影像和附件的大小可能會導致擷取至用戶端時回應速度變慢。
檢閱您的清單，並確保僅定義必要的資料行。 清單中的資料行數目會影響資料要求的效能。 這是因為將擷取相符的記錄或達到定義資料列限制的記錄，並將其與清單中定義的所有資料行一起傳回用戶端—(即使應用程式未使用全部資料行)。
若只要查詢應用程式使用的資料行，請啟用明確資料行選取範圍功能，如本文稍早所述。
大型清單
如果您有包含數十萬條記錄的大型清單，請考慮根據參數 (如類別或日期和時間) 對清單進行資料分割，或將其分割為多個清單。
例如，您的資料可能每年或每月儲存在不同的清單中。 在這種情況下，您可以將應用程式設計為讓使用者選取時間範圍，並擷取該範圍內的資料。
在受控環境中，效能基準已證明針對 Microsoft 清單或 SharePoint 的 OData 要求的效能，與清單中的行數和要取出的列數 (受限於不可委派查詢的資料列限制) 密切相關。 較少的資料行和較低的資料列限制設定，可使畫布應用程式擁有更好的效能。
然而在現實中，應用程式的設計是為了達到特定的業務需求。 減少資料列限制或清單中的資料行數目可能並不簡單或迅速。 但是，建議您監視用戶端 OData 要求，並調整不可委派查詢的資料列限制和清單中的資料列數目。
使用 Dataverse 做為資料來源的效能考量
當您使用 Microsoft Dataverse 做為資料來源時，資料要求直接移至環境執行個體，不需經過 Azure API 管理。 其他資訊：連線至 Microsoft Dataverse 的資料呼叫流程
提示
在 Dataverse 中使用自訂表格時，使用者可能需要其他安全性設定，才能使用畫布應用程式來查看記錄。 詳細資訊：Dataverse 中的安全性概念、為環境中的資源設定使用者安全性和安全性角色和權限
如果連線至 Dataverse 的畫布應用程式在用戶端而不是伺服器端執行大量用戶端指令碼 (如篩選依據或加入)，則其效能可能會降低。
如果可能，使用 Dataverse 檢視。 具有必要 Join 或 Filter 準則的檢視，可協助減少使用整個表格的額外負荷。 例如，如果您需要聯結表格並篩選資料，您可以透過聯結表格並僅定義您需要的資料行來定義檢視。 然後，您可以在應用程式中使用此檢視，如此進行加入/刪除作業時，負荷將施加於伺服器端而不是用戶端。 此方法不僅能減少額外作業，還能減少資料傳輸。 如需編輯篩選和排序準則的詳細資訊，請移至編輯篩選準則。
Excel 連接接器的效能考量
Excel 連接器可從畫布應用程式連線至 Excel 檔案表格中的資料。 與其他資料來源相比，此連接器具有限制—例如，受限委派函數—限制畫布應用程式只能從表格中載入最多 2,000 筆記錄資料。 若要載入超過 2000 個記錄，請將不同資料表格中的資料分割為其他資料來源。
讓我們看看使用 Excel 做為畫布應用程式資料來源的常見效能問題，和解決這些問題的方法。
太多表格和太大的資料
如果應用程式使用的 Excel 檔案包含太多表格，或者表格包含多個資料行的大量資料，則該應用程式的執行速度可能會變慢。 Excel 檔案不是提供可委派函數的關聯式資料庫或資料來源。 Power Apps 必須先從定義的資料表格載入資料，然後使用篩選、排序、加入、分組依據和搜尋等函數。
包含大量資料列和資料行的表格過多會影響應用程式效能和用戶端的負荷，因為每個表格都需要在 JS 推積中進行操作。 這種影響也會導致應用程式使用更多用戶端記憶體。
為確保您的應用程式不受此問題影響，請在 Excel 檔案的表格中僅定義所需的資料行。
大量交易
Excel 不是關聯式資料庫系統。 應用程式中的所有變更均由 Excel 以與使用者變更 Excel 檔案資料相同的方式進行管理。 如果該應用程式包含大量讀取，但 CRUD 作業較少，則其可能具備良好的效能。 但是，如果應用程式進行大量交易，則可能會對應用程式的效能產生負面影響。
交易數量沒有特定的閾值，因為這也取決於要操作的資料。 還有其他方面也會影響應用程式的效能，例如網路負荷或使用者裝置。
如果您有唯讀資料，則可以將此類資料匯入至應用程式，而非從資料來源載入。 如果是企業應用程式，請改為使用如 Dataverse、SQL Server、 SharePoint 等資料來源。
檔案大小
您可以為 Excel 檔案選擇各種不同且具備多變—或可設定—的儲存容量的 雲端儲存空間。 但是，若所有表格都定義於單一大型 Excel 檔案中，則在下載檔案並讀取要載入用戶端的資料時會增加應用程式的額外負荷。
不要使用單一大型檔案，而是將資料分割為包含最少表格的多個 Excel 檔案。 然後僅在需要時連線至各個檔案。 如此一來，就會片段地從表格中載入資料，以此減少包含多個表格或大型資料集的負荷。
檔案位置
資料來源的地理位置及其與用戶端位置的距離可能會導致應用程式出現效能瓶頸，並導致網路延遲。 當行動裝置用戶端的連線頻寬有限時，這種影響會變得更大。
最好把檔案放在您的使用者 (或有全球對象時，大多數使用者) 附近，以便快速下載檔案。
後續步驟
請參閱
了解畫布應用程式的執行階段和資料呼叫流程
畫布應用程式效能下降的常見原因
Power Apps 的常見問題和解決方案
Power Apps 啟動問題疑難排解
意見反應
即將登場：在 2024 年，我們將逐步淘汰 GitHub 問題作為內容的意見反應機制，並將它取代為新的意見反應系統。 如需詳細資訊，請參閱：https://aka.ms/ContentUserFeedback。
提交並檢視相關的意見反應