就严格的限制而言，您已指定最重要的商店（在给定的时间最多开设4家商店）。 还有其他一些严格的限制（ http://dcx.sap.com/sa160 /en/uladmin/fo-intro-s-5236376.html ），但您不太可能碰到任何一个。 话虽这么说，但是在任何使用大量数据的应用程序和任何移动应用程序中，性能仍然是一个极其重要的考虑因素。

我们可以将性能问题分为三个高级领域 ：后端，客户端以及介于两者之间的所有内容，包括中间层（用于云的SAP Cloud Platform，用于内部部署的SAP Mobile Platform服务器），所有各种网络层，负载均衡器等。

< p>首先要分析的是后端要花多长时间来响应发送的请求。 找出此问题的最佳方法是隔离一个到后端的唯一请求的时间，然后在启用网络跟踪的情况下运行性能测试并检查网络跟踪。 您正在寻找需要花费较长时间才能处理的请求，还正在寻找所有请求的累积影响。

缓解后端的性能问题通常分为两类：优化性能 请求并减少请求数量和有效负载需求。 使您的后端更好地运行将完全取决于实现，因此很难在此提出任何具体建议。 减少发出的请求的数量可以通过以下方式实现：将应用程序设计为减少发出请求的次数，通过剥离将这些请求上传到后端的时间，以及通过合并后端或客户端上的请求来实现。 客户端请求合并可以由应用程序本身完成，也可以由脱机OData客户端引入的新功能（如果有）进行。 但是，减少那些请求的有效负载需求通常是提高后端性能的最直接的方法。 您需要对下拉到客户端的数据量非常有策略，只应下拉用户需要的数据，仅此而已。 同样，如果初始下载已经发生，并且您有非平凡的有效负载，那么您*真正**只希望从那以后开始进行更改，而不是整个数据集，因此您应该确定是否已实现增量支持 如果您的后端运行正常（或者失败，请配置脱机OData为您完成），

要简短地简要介绍一下"介于两者之间"类别，这也是最大的因素 ，是数据量。 如果要提取1Gb的数据，则无论下载文件还是脱机OData客户端存储，都要花大约一个小时才能将其下载到手机中。 有效负载越小，下载速度就越快。

一旦数据在移动设备上，问题就变成了脱机OData客户端能够多快将数据导入到您的应用程序中。 这里的第一个建议是确保您具有适当的客户端索引设置。 使用索引的定义可能是反直觉的，在中间层的管理控制台中指定。 重要的是要注意，默认情况下不会创建客户端索引，即使是主键也不会创建，因此您几乎肯定会创建某种类型的索引。 与任何数据库一样，确定应该仔细考虑要在其上创建索引的列，最好是通过测试来备份所做出的决策。 第二个建议，就像我们在后端和网络中看到的那样，涉及限制有效负载的大小。 现代移动设备功能非常强大，但是用户对响应性的要求也同样很高，因此仅将所需的数据提取到内存中，而不是将来某个时候可能需要的数据。 如果显示的是10行，则仅检索那10行（或者可能是30行，以便给自己一个滚动缓冲区），而不是所有行。 作为一般的经验法则，如果您一次将50行以上的内存拉入内存，则可能是在做错什么。