Compose是什么
接口性能优化对于客户端的同学来讲涉及可能不是很多，但是接口的性能对于客户端的体验影响是巨大的；请求失败、loading、无数据这几个关键词跟客户端的同学一提，想必接口优化的意义就不用多说了吧。
一个快速而又稳定的接口，对于客户端的用户体验来说是大有裨益的。本文从客户端的视角，分享客户端如何协同服务端进行接口时间的优化。
分析
▐ 简析
客户端的一次完整的接口请求主要包括：
- 业务发起请求
- 网络传输
- 服务端处理
- 数据响应后解析
- 图层布局与渲染
那么我们来看一下通常客户端发起一次接口请求，耗时都发生在哪些阶段：
- Prepare：主要包括请求前的参数拼装以及发送请求处理的线程切换；
- Network Request：主要包括，鉴权、网络传输、服务端处理、Network SDK的数据处理等。
- Data Parse：业务上的数据解析，如json解析等的操作，以及线程间的切换等耗时。
- UI Refresh：主要是视图布局，渲染的操作。
- First Item Render：第一张卡片的渲染时间。
从上面数据上来看，客户端的耗时主要是：
- 请求前的参数绑定过程
- 请求后数据解析
- 数据上屏的图层布局以及渲染
- 异步请求过程中的线程不断切换造成切换耗时
客户端上这些操作往往在整个链路上占比较小，且过程优化空间较小；然而大头往往在这两个方面：网络传输和服务端处理。
方案
▐ 降低ServerRT（服务端处理耗时）
通常降低服务端处理耗时，是由服务端小伙伴来优化，当然优化过程中需要端上一起协助完成，大致了解一下服务端耗时的几种处理方案；主要有这几种方式：
- 接口加缓存：合理设计临时缓存、持久缓存可以提高接口性能
- 内部接口并发请求：通常一个复杂的接口需要调用下游几个业务的接口，如果合理的进行并发请求，将会收到很好的效果
- 异步化：如写日志，更新缓存等不会影响接口准确性的非核心流程，可以采用异步方式进行处理，不阻塞主计算逻辑处理
- 数据批量处理：接口存在较大量计算，可以通过批量分批次(分而治之)方式来解决大量数据计算耗时问题
- sql加索引：数据库SQL是最常见的性能瓶颈，如SQL子查询、不合理索引设计、全表扫描、大量数据返回、大SQL等，通过监控平台查看慢查询SQL可立即找出影响接口性能瓶颈关键点
▐ 降低网络传输时间
虽然现有阶段大多数用户网络已经很不错了，但是还是有很多场景下，网络耗时占比还是非常高，尤其长尾数据中，网络耗时往往是最大的占比，所以网络耗时的优化依然是非常重要；当然端上的小伙伴在这个阶段可参与的空间也更多。主要有哪些方式呢？
- 接口多段返回
通常一个接口承载了较多的内容的话，其内容就会无限的进行膨胀，如果将埋点，日志，反馈等非主线的数据进行多段返回的话将会有很大的收益，此方案主要结合接口组成进行分析；当然，此方案改动量也比较大，成本也比较高。 - 更换协议
大多数我们接口使用的是TCP协议，相比来说如果更换UDP协议，接口返回速度会快不少，详细原因可以翻一下资料学习一下，这里不再多说。目前也已经有成熟的方案，比如阿里的XQUIC，有感兴趣的可以了解一下，具体的收益我这里也还在测试中。 - 缩小网络包
为何缩小网络包会降低网络传输时间呢？客户端和服务端网络通信时数据传输过程如下图所示：
数据包越大，则在光纤传输时所需的时间就会越久，因此接收方等待数据包的时间也会更长，最终会导致应用层等待数据时间变长。
还有，由于TCP采用的滑动窗口机制来提升传输性能，窗口的大小受接收端处理速率和网络拥塞情况影响，因此如果传输的包越小，则可以在尽量少的窗口周期完成数据的传输，减少响应的等待时间，反之，响应等待更长。从上面几个方式来看，业务客户端能够做的一部分其实是缩小网络包的大小，那么我们下面介绍一下缩小网络包研究。收益
▐ 缩小接口网络数据包方案与收益
- 缩小网络包，是否真的会对网络的传输有效果呢？
我们对数据包的大小与网络传输时长做了一个线下的实验，以下是实验的数据：
其他条件不变，我们将一页返回数据改变后的数据；
可以看出网络传输时间与数据包的大小是有着正相关的关系的。
- 减少网络包大小有哪些措施呢？
更优的压缩算法不同的压缩算法，压缩算法是不一样的：
但是，压缩算法的调整需要考虑方面很多，如果仅仅是网络时间的收益在很多场景下可能成本较高，暂未考虑。
减少返回数据个数减少返回数据个数，服务端的同学已经在投入，但是遇到了一个问题，数据个数的减少就需要增加请求的次数，机器资源的成本就会升高，需要申请机器的资源；那就比较尴尬了，本身是优化，却让成本来买单。
精简返回字段在原有的请求数据上通过精简字段，减少数据包的大小。这样既能降低数据包，成本又不增高。如何做呢？下面来研究一下。
▐ 精简数据报文
- 做一个实验
一个接口的分页接口数据包大小在1.5M左右，Server使用的是gzip（best模式）的压缩方式，我进行压缩后的大小为106KB左右。通常其他接口数据包大小压缩后普遍在10KB以下，所以可以看出分页接口横向对比来看，数据包大小是非常严重的。这也是为什么会选择精简数据报文作为优化手段一大原因。
- 分析
精简数据报文需要根据业务的场景来看，我这里来举一个我这边实践的例子：
从数据包上分析，业务A的数据占比59.8%，而且该业务数据元素字段重复率非常高，来看一下去除该业务后的数据包大小：
| 原始数据 |
精简后 |
| 1472672 |
607587 |
| 降低率 |
59.8% |
从数据比对来看，不同的卡片有大约18处的不同，其占比：占比 = 1 - (5350 / 17439) ≈ 0.693那么，此时就有一个问题了，重复的数据，经过压缩后还会占包大小吗？所以我就用服务端的压缩方式对数据做了个压缩：
| 原始数据 |
精简后 |
原始数据Gzip压缩 |
精简后Gzip压缩 |
| 1472672 |
607587 |
147892 |
78516 |
| 降低率 |
59.8% |
90% |
95% |
数据表明，针对重复字段的精简，压缩后依然是有效的。
压缩后降低率依然有46.9%。
拿到这个结果后，如何做呢？
▐ 数据查找表
将重复的业务数据在第一页的数据中建立字段的查找表，然后通过端上进行合并操作，具体方式：
但是，与服务端的同学对方案时，发现请求的第一页数据放置查找表，服务端不容易实现，因为数据在下游。
调整方案，将数据查找表改放置在每一页数据中，这样服务端更改就非常少了，实现也比较简单。
但是数据放在每一页，压缩后还会有收益吗？来看一下实验的结果：采用压缩方式：gzip的压缩方式压缩比：best模式（系统缺省值6）
方案1：将负反馈数据查找表放在第一页数据中：
实验发现，查找表的数据仅仅占用2KB，优化依然有效。
▐ 优化效果
- 精简报文
在原有的数据包下，线下实验，精简字段会将数据包从106KB降低至63KB；线下的实验可以得到接近90ms的优化；
- 缩小返回数据个数
缩小接口返回数据的个数，从50个降低至20个，数据大小大约降低63KB，网络传输耗时减低107ms；
结论
- 数据包的大小对于接口的性能、响应以及失败率都有影响
- 在一定场景下，数据中的重复字段对压缩后数据包依然有较大的影响。
注：
- 网络传输使用的是服务端的压缩包，所以大小要看压缩后的包大小
- 精简报文有很多同学可能都试过，实现后发现收益很小，所以需要先衡量包的大小会不会对网络传输造成影响，如果仅仅是几KB的优化，从上面实验可以看出，基本收益不大，如果是上百KB，收益肯定是有的。
