本文档介绍了可用来提高应用性能的方法和技巧。在某些情况下，我们会采用其他 API 或通用 API 中的示例来阐释所介绍的概念，不过，相同的概念也适用于 Android Over The Air API。
使用 gzip 进行压缩
如需减少每个请求所需的带宽，您可以选择启用 gzip 压缩，这是一种既方便又简单的方法。虽然这种方法需要一些额外的 CPU 时间来对结果进行解压缩，但考虑到节约的网络费用，通常还是很值得的。
为了接收 gzip 编码的响应，您必须执行以下两项操作：设置 Accept-Encoding 标头，以及修改您的用户代理，使其包含字符串 gzip。下面提供了一个用于启用 gzip 压缩的格式正确的 HTTP 标头示例：
Accept-Encoding: gzip User-Agent: my program (gzip)
使用部分资源
提高 API 调用性能的另一方法是仅发送和接收您感兴趣的那部分数据。这样可以避免应用传输、解析和存储不需要的字段，使应用可以更高效地利用网络、CPU 和内存等资源。
部分请求有以下两种类型：
如需详细了解如何发出部分请求，请参阅以下各部分内容。
部分响应
默认情况下，处理完请求之后，服务器会发回资源的完整表示形式。为了提高性能，您可以要求服务器仅发送您真正需要的字段，从而只接收部分响应。
如需请求部分响应，请使用 fields 请求参数来指定您希望返回的字段。对于返回响应数据的任何请求，您都可以使用此参数。
注意，fields 参数仅影响响应数据；并不会影响您需要发送的数据（如有）。如需减少您在修改资源时发送的数据量，请使用修补请求。
示例
补丁（部分更新）
在修改资源时，您也可以避免发送不必要的数据。如果您只想为您要更改的特定字段发送更新数据，请使用 HTTP PATCH 动词。本文所述的修补语义不同于采用 GData 实现的旧版部分更新方案，并且更简单。
下面的简短示例显示了如何使用修补最大限度地减少进行小的更新时需要发送的数据。
示例
处理修补请求的响应
处理有效修补请求之后，API 会返回 200 OK HTTP 响应代码以及修改后的资源的完整表示形式。如果 API 使用了 ETag，则服务器会在成功处理修补请求后更新 ETag 值，正如使用 PUT 时那样。
修补请求的响应会返回资源的完整表示形式，除非您使用 fields 参数减少其返回的数据量。
如果修补请求导致的新资源状态在语法或语义上是无效的，则服务器会返回 400 Bad Request 或 422 Unprocessable Entity HTTP 状态代码，并且资源状态会保持不变。例如，如果您尝试删除必填字段的值，服务器就会返回错误。
不支持 PATCH HTTP 动词时的备用表示法
如果您的防火墙不允许 HTTP PATCH 请求，则可使用 HTTP POST 请求，并将替换标头设为 PATCH，如下所示：
POST https://www.googleapis.com/... X-HTTP-Method-Override: PATCH ...
修补与更新之间的区别
在实际操作中，当为使用了 HTTP PUT 动词的更新请求发送数据时，您只需发送那些必需或可选字段；如果您发送服务器所设置的字段值，这些值将会被忽略。尽管这看起来好像是另一种执行部分更新的方法，但该方法有一些局限性。对于使用 HTTP PUT 动词的更新，如果您没有提供必需参数，则请求会失败；如果您没有提供可选参数，则请求会清除之前设置的数据。
出于以上原因，使用补丁程序是一个安全得多的选择。您只需为自己想要修改的字段提供数据；系统不会清除您省略的字段。此规则的唯一例外情况是存在重复的元素或数组之时：如果您省略所有重复的元素或数组，它们将会保持原样；如果您提供其中任何元素或数组，系统会将所有元素或数组替换为您提供的元素或数组。