常见的画布应用性能问题和解决方法
您可以使用各种不同的数据源构建画布应用。 根据设计应用时要满足的业务需要和场景选择数据源和连接器。 对于企业应用，Microsoft Dataverse 是推荐的数据源，因为它提供多项性能优势。 对于具有少量事务的应用，您可以使用环境中的任何其他可用数据源。
对于应用性能方面的考虑，请考虑应用发布后将使用应用的用户数量；创建、检索、更新和删除 (CRUD) 事务的数量；数据交互的类型；地理区域访问；以及用户拥有的设备类型。
在本文中，您将了解一些最常见的性能问题（这些问题可能会使画布应用运行缓慢），以及如何解决这些问题。 这些信息将在考虑了您的业务计划和增长的基础上帮助您提高应用性能。
我们将从一些常见的性能问题开始，不考虑您使用的是哪种连接器。 在后面的部分中，您将了解特定于各种连接器的性能问题和解决方法。
在开始之前，请确保您了解画布应用执行阶段和数据调用流。 此外，阅读画布应用性能降低的常见原因，以了解在设计或更新画布应用时可以避免的常见陷阱。
大型数据集在不同的平台上加载速度缓慢
在 iOS 或 Android 等不同平台上加载大型数据集时，应用的性能可能会有所不同。 发生这种变化是因为每个平台上的网络请求限制不同。 例如，平台允许的并发网络请求数可能会有所不同。 这种差异可能会对大型数据集的数据加载时间产生很大影响。
我们建议您仅加载需要在屏幕上立即显示的数据。 对于其他数据，对数据进行分页和缓存。 详细信息：改进画布应用性能的提示和最佳做法
检索到太多列
我们建议您仅选择应用必需的列。 从数据源添加更多（或所有）列将下载列中的所有数据。 此操作会导致大量的网络开销调用，因此会导致客户端设备中的内存使用情况很高。 如果网络带宽有限，或者设备内存有限或使用旧处理器，此问题对移动设备用户的影响会更大。
例如，如果您使用 Dataverse 作为应用的数据源，请确保已启用显式列选择功能。 此功能让 Power Apps 可以限制仅对应用中使用的列进行数据检索。
若要在画布应用上打开显式列选择功能，请转到设置>即将发布的功能>预览，然后打开显式列选择切换开关。
不支持或旧版浏览器
使用不受支持或旧版浏览器的用户可能会遇到性能问题。 请确保用户仅使用受支持的浏览器来运行画布应用。
由于地理距离而降低性能
环境的地理位置以及数据源与用户的距离可能会影响性能。
我们建议您让环境靠近用户。 虽然 Power Apps 使用 Azure 内容传送网络存储内容，但数据调用仍然从数据源获取数据。 位于另一个地理位置的数据源可能会对应用的性能产生不利影响。
较远的地理位置距离会以不同方式影响性能，例如延迟、降低吞吐量、降低带宽或数据包丢失。
未配置允许列表
确保所需的服务 URL 未被阻止或已添加到防火墙的允许列表中。 有关 Power Apps 必须允许的所有服务 URL 的完整列表，请转到必需服务。
对不可委派查询使用不可委派函数和不适当的数据行限制
可委派函数将数据处理委派给数据源，从而最大程度地减少客户端的开销。 如果无法进行委派，您可以限制不可委派查询的数据行限制，以便从基于服务器的连接返回的行数保持最合适数量。
使用不可委派函数和不合适的不可委派查询的数据行限制会增加数据传输的额外开销。 此开销会导致在客户端将接收到的数据处理到 JS 堆。 请确保在可用的情况下尽可能为应用使用可委派函数，并为不可委派查询使用合适的数据行限制。
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 数据库。 此部分介绍将此连接器用于画布应用时的与性能相关的常见问题和解决方法。
备注
虽然此部分针对性能问题和解决方法引用了 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 条记录并按 ID 的降序排列。
Items? \$filter=Column eq 'Value' & Orderby = ID desc & top 500
这可以帮助了解索引要求以满足类似请求条件。 在此示例中，如果 ID 列具有降序索引，将更快地执行查询。
检查缓慢查询的执行计划，查看是否存在任何表或索引扫描。 监视执行计划中键查找的所有过多成本。
详细信息：
数据库资源争用
确保数据源（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 数据库特定注意事项
画布应用可以使用 SQL Server 连接器连接到 Azure SQL 数据库。 使用 Azure SQL 数据库时出现性能问题的一个常见原因是为您的业务需求选择了错误层。
Azure SQL 数据库在不同的服务层中可用，具有满足不同业务要求的不同功能。 有关层的详细信息，请转到 Azure SQL 数据库文档。
对于大量数据请求，您选择的层上的资源在达到阈值后可能会立即受到限制。 此类限制会降低下一组查询的性能。
检查 Azure SQL 数据库的服务层。 较低层将有一些限制和约束。 从性能角度来看，CPU、I/O 吞吐量和延迟很重要。 因此，我们建议您定期检查 SQL 数据库的性能，并检查资源使用情况是否超过阈值。 例如，本地 SQL Server 通常将 CPU 使用情况的阈值设置为 75% 左右。
SharePoint 连接器的性能注意事项
您可以使用 SharePoint 连接器使用 Microsoft Lists 中的数据来创建应用。 您也可以直接从列表视图创建画布应用。 我们来看一下将 SharePoint 数据源用于画布应用时常见的性能问题和解决方法。
动态查找列过多
SharePoint 支持各种数据类型，包括人员、组和计算等动态查找。 如果列表定义的动态列过多，在将数据返回到运行画布应用的客户端之前，需要花费更多时间在 SharePoint 中操作这些动态列。
不要在 SharePoint 中过度使用动态查找列。 这种过度使用可能会导致 SharePoint 上本可以避免的额外的数据操作开销。 例如，您可以改为使用静态列来保留电子邮件别名或人员姓名。
图片列和附件
在检索客户端时，图像和附加文件的大小可能会导致响应缓慢。
请查看您的列表，确保仅定义了必要的列。 列表中的列数会影响数据请求的性能。 这是由于匹配的记录数，或者是由于检索了达到所定义数据行限制的记录数，然后将其与列表中定义的所有列一起传回客户端所致，即使应用不使用所有这些内容。
若要仅查询应用使用的列，启用显式列选择功能，如本文前面所述。
大型列表
如果您有一个包含成百上千条记录的大型列表，请考虑对列表进行分区，或根据类别或日期和时间等参数将其拆分为几个列表。
例如，您的数据可以按年或按月存储在不同的列表中。 在这种情况下，您可以设计应用，让用户选择时间范围并检索该范围内的数据。
在受控环境中，性能基准已经证明针对 Microsoft Lists 或 SharePoint 的 OData 请求的性能与列表中的列数和正在检索的行数高度相关（受不可委派查询的数据行限制的限制）。 具有较少的列和较低的数据行限制设置可以让画布应用更好地执行。
但是，在现实世界中，应用设计用于满足某些业务需求。 减少数据行限制或列表中的列数可能不是一项快速或简单的工作。 但是，我们建议您在客户端监视 OData 请求，并调整不可委派查询的数据行限制和列表中的列数。
使用 Dataverse 作为数据源时的性能注意事项
使用 Microsoft Dataverse 作为数据源时，数据请求将直接进入环境实例，不经过 Azure API 管理。 详细信息：连接到 Microsoft Dataverse 时的数据调用流
小费
在 Dataverse 中使用自定义表时，用户可能需要额外的安全配置才能使用画布应用查看记录。 详细信息：Dataverse 中的安全概念、在环境中将用户安全配置到资源和安全角色和特权
如果连接到 Dataverse 的画布应用在客户端而不是服务器端运行客户端繁重脚本（如筛选依据或联接），其执行速度可能会缓慢。
如果可能请使用 Dataverse 视图。 具有必需的联接或筛选条件的视图有助于减少使用整个表的开销。 例如，如果您需要联接表和筛选表的数据，您可以通过联接这些表定义一个视图，然后仅定义您需要的列。 然后，您可以在您的应用中使用此视图，它在服务器端而不是客户端为联接/筛选操作创建此开销。 此方法不仅能够减少额外的操作，还能够减少数据传输。 有关编辑筛选器和排序条件的信息，请转到编辑筛选条件。
Excel 连接器的性能注意事项
Excel 连接器提供从画布应用到 Excel 文件内表中数据的连接。 与其他数据源相比，此连接器有一些限制（例如，有限的可委派函数），将限制画布仅从最多 2,000 条记录的表中加载数据。 要加载 2,000 条以上记录，请将不同数据表中的数据分区为其他数据源。
我们来看一下使用 Excel 作为画布应用的数据源时常见的性能问题，以及如何解决这些问题。
数据表过多，数据很大
当应用使用数据表过多的 Excel 文件，或者数据表中包含几个列的大量数据时，应用执行速度会缓慢。 Excel 文件不是关系数据库，也不是提供可委派函数的数据源。 Power Apps 必须先从定义的数据表加载数据，然后使用 Filter、Sort、JOIN、Group By 和 Search 等函数。
具有包含许多行和列的过多数据表，这会影响应用性能和客户端开销，因为每个数据表都需要在 JS 堆中操作。 此影响还会导致应用消耗更多的客户端内存。
若要确保您的应用不会受此问题影响，请仅在 Excel 文件中的数据表上定义所需的列。
繁重事务
Excel 不是关系数据库系统。 应用中的任何更改都由 Excel 管理，方式与用户在 Excel 文件中更改数据一样。 如果应用的读取次数很多，但 CRUD 操作较少，其性能可能会很好。 但是，如果应用执行大量事务，则可能会对应用的性能产生不利影响。
事务数量没有特定的阈值，因为它还依赖于要操作的数据。 其他几个方面也会影响应用的性能，例如网络开销或用户设备。
如果您有只读数据，可以将此类数据本地导入到应用中，而不必从数据源中加载。 对于企业应用，请改为使用 Dataverse、SQL Server 或 SharePoint 等数据源。
文件大小
您可以从各种云存储选项中进行选择，它们针对 Excel 文件有不同（或可配置）的存储容量。 但是，在下载文件和读取数据以在客户端加载时，具有在该文件中定义了所有表的单个大型 Excel 文件会增加应用的额外开销。
因此，不要使用一个大文件，而应将数据拆分到具有最少数据表的多个 Excel 文件中。 然后，仅当您需要时连接到每个文件。 这样，从数据表中加载数据是分段进行的，从而减少了具有许多表或大型数据集的开销。
文件位置
数据源的地理位置以及与客户端位置的距离可能会导致应用出现性能瓶颈，并引发网络延迟。 当移动客户端具有有限带宽的连接时，此影响会被放大。
最好将文件放在您的用户（或大多数用户，如果具有全球访问群体）附近，以便文件可以快速下载。
后续步骤
另请参阅
了解画布应用执行阶段和数据调用流
画布应用性能降低的常见原因
Power Apps 的常见问题和解决方法
解决 Power Apps 启动问题