Compose是什么

接口性能优化对于客户端的同学来讲涉及可能不是很多，但是接口的性能对于客户端的体验影响是巨大的；请求失败、loading、无数据这几个关键词跟客户端的同学一提，想必接口优化的意义就不用多说了吧。

一个快速而又稳定的接口，对于客户端的用户体验来说是大有裨益的。本文从客户端的视角，分享客户端如何协同服务端进行接口时间的优化。

分析

简析

客户端的一次完整的接口请求主要包括：

1. 业务发起请求
2. 网络传输
3. 服务端处理
4. 数据响应后解析
5. 图层布局与渲染

那么我们来看一下通常客户端发起一次接口请求，耗时都发生在哪些阶段：

1. Prepare：主要包括请求前的参数拼装以及发送请求处理的线程切换；
2. Network Request：主要包括，鉴权、网络传输、服务端处理、Network SDK的数据处理等。
3. Data Parse：业务上的数据解析，如json解析等的操作，以及线程间的切换等耗时。
4. UI Refresh：主要是视图布局，渲染的操作。
5. First Item Render：第一张卡片的渲染时间。

从上面数据上来看，客户端的耗时主要是：

1. 请求前的参数绑定过程
2. 请求后数据解析
3. 数据上屏的图层布局以及渲染
4. 异步请求过程中的线程不断切换造成切换耗时

客户端上这些操作往往在整个链路上占比较小，且过程优化空间较小；

然而大头往往在这两个方面：网络传输和服务端处理。

方案

降低ServerRT（服务端处理耗时）

通常降低服务端处理耗时，是由服务端小伙伴来优化，当然优化过程中需要端上一起协助完成，大致了解一下服务端耗时的几种处理方案；

主要有这几种方式：

1. 接口加缓存：合理设计临时缓存、持久缓存可以提高接口性能
2. 内部接口并发请求：通常一个复杂的接口需要调用下游几个业务的接口，如果合理的进行并发请求，将会收到很好的效果
3. 异步化：如写日志，更新缓存等不会影响接口准确性的非核心流程，可以采用异步方式进行处理，不阻塞主计算逻辑处理
4. 数据批量处理：接口存在较大量计算，可以通过批量分批次(分而治之)方式来解决大量数据计算耗时问题
5. sql加索引：数据库SQL是最常见的性能瓶颈，如SQL子查询、不合理索引设计、全表扫描、大量数据返回、大SQL等，通过监控平台查看慢查询SQL可立即找出影响接口性能瓶颈关键点。

降低网络传输时间

虽然现有阶段大多数用户网络已经很不错了，但是还是有很多场景下，网络耗时占比还是非常高，尤其长尾数据中，网络耗时往往是最大的占比，所以网络耗时的优化依然是非常重要；当然端上的小伙伴在这个阶段可参与的空间也更多。

主要有哪些方式呢？

接口多段返回

通常一个接口承载了较多的内容的话，其内容就会无限的进行膨胀，如果将埋点，日志，反馈等非主线的数据进行多段返回的话将会有很大的收益，此方案主要结合接口组成进行分析；当然，此方案改动量也比较大，成本也比较高。

更换协议

大多数我们接口使用的是TCP协议，相比来说如果更换UDP协议，接口返回速度会快不少，详细原因可以翻一下资料学习一下，这里不再多说。

目前也已经有成熟的方案，比如阿里的XQUIC，有感兴趣的可以了解一下，具体的收益我这里也还在测试中。

缩小网络包

为何缩小网络包会降低网络传输时间呢？

客户端和服务端网络通信时数据传输过程如下图所示：

数据包越大，则在光纤传输时所需的时间就会越久，因此接收方等待数据包的时间也会更长，最终会导致应用层等待数据时间变长。

还有，由于TCP采用的滑动窗口机制来提升传输性能，窗口的大小受接收端处理速率和网络拥塞情况影响，因此如果传输的包越小，则可以在尽量少的窗口周期完成数据的传输，减少响应的等待时间，反之，响应等待更长。

从上面几个方式来看，业务客户端能够做的一部分其实是缩小网络包的大小，那么我们下面介绍一下缩小网络包研究。

收益

缩小接口网络数据包方案与收益

缩小网络包，是否真的会对网络的传输有效果呢？

我们对数据包的大小与网络传输时长做了一个线下的实验，以下是实验的数据：

其他条件不变，我们将一页返回数据改变后的数据；

可以看出网络传输时间与数据包的大小是有着正相关的关系的。

减少网络包大小有哪些措施呢？

更优的压缩算法

不同的压缩算法，压缩算法是不一样的：

图片来源于网上大佬的图片

但是，压缩算法的调整需要考虑方面很多，如果仅仅是网络时间的收益在很多场景下可能成本较高，暂未考虑。

减少返回数据个数

减少返回数据个数，服务端的同学已经在投入，但是遇到了一个问题，数据个数的减少就需要增加请求的次数，机器资源的成本就会升高，需要申请机器的资源；那就比较尴尬了，本身是优化，却让成本来买单。

精简返回字段

在原有的请求数据上通过精简字段，减少数据包的大小。这样既能降低数据包，成本又不增高。如何做呢？下面来研究一下。

精简数据报文

做一个实验

一个接口的分页接口数据包大小在1.5M左右，Server使用的是gzip（best模式）的压缩方式，我进行压缩后的大小为106KB左右。通常其他接口数据包大小压缩后普遍在10KB以下，所以可以看出分页接口横向对比来看，数据包大小是非常严重的。这也是为什么会选择精简数据报文作为优化手段一大原因。

分析

精简数据报文需要根据业务的场景来看，我这里来举一个我这边实践的例子：

从数据包上分析，业务A的数据占比59.8%，而且该业务数据元素字段重复率非常高，来看一下去除该业务后的数据包大小：

从数据比对来看，不同的卡片有大约18处的不同，其占比：

占比 = 1 - (5350 / 17439) ≈ 0.693

那么，此时就有一个问题了，重复的数据，经过压缩后还会占包大小吗？

所以我就用服务端的压缩方式对数据做了个压缩：

数据表明，针对重复字段的精简，压缩后依然是有效的。

压缩后降低率依然有46.9%。

拿到这个结果后，如何做呢？

数据查找表

将重复的业务数据在第一页的数据中建立字段的查找表，然后通过端上进行合并操作，具体方式：

但是，与服务端的同学对方案时，发现请求的第一页数据放置查找表，服务端不容易实现，因为数据在下游。

调整方案，将数据查找表改放置在每一页数据中，这样服务端更改就非常少了，实现也比较简单。

但是数据放在每一页，压缩后还会有收益吗？来看一下实验的结果：

采用压缩方式：gzip的压缩方式

压缩比：best模式（系统缺省值6）

方案1：

将负反馈数据查找表放在第一页数据中：

优化前后：降低45KB

降低率 ：1 - 61 / 106 ≈ 42.2%

方案2：

将负反馈数据查找表放置于每一页数据的头部：

优化前后：降低43KB

降低率 ：1 - 63 / 106 ≈ 40.5%

实验发现，查找表的数据仅仅占用2KB，优化依然有效。

优化效果

精简报文

在原有的数据包下，线下实验，精简字段会将数据包从106KB降低至63KB；线下的实验可以得到接近90ms的优化；

缩小返回数据个数

缩小接口返回数据的个数，从50个降低至20个，数据大小大约降低63KB，网络传输耗时减低107ms；

结论

1. 数据包的大小对于接口的性能、响应以及失败率都有影响
2. 在一定场景下，数据中的重复字段对压缩后数据包依然有较大的影响。

注：

1. 网络传输使用的是服务端的压缩包，所以大小要看压缩后的包大小
2. 精简报文有很多同学可能都试过，实现后发现收益很小，所以需要先衡量包的大小会不会对网络传输造成影响，如果仅仅是几KB的优化，从上面实验可以看出，基本收益不大，如果是上百KB，收益肯定是有的。