APP的优化是任重而道远的过程,必须在意每一个环节,否者当你想要优化的时候,发现到处都是坑,已经不知道填补哪里了,所以我们必须一点一滴的做起。
网络优化
正常一条网络请求需要经过的流程是这样:
①DNS 解析,请求DNS服务器,获取域名对应的 IP 地址。
②与服务端建立连接,包括 tcp 三次握手,安全协议同步流程。
③连接建立完成,发送和接收数据,解码数据。
这里有明显的三个优化点:
①直接使用 IP 地址,去除 DNS 解析步骤。
②不要每次请求都重新建立连接,复用连接或一直使用同一条连接(长连接)或合并接口。
③压缩数据,减小传输的数据大小。
DNS优化
DNS:它的作用是根据域名查出IP地址。
DNS 完整的解析流程很长,会先从本地系统缓存取,若没有就到最近的 DNS 服务器取,若没有再到主域名服务器取,每一层都有缓存,但为了域名解析的实时性,每一层缓存都有过期时间。
DNS的缺点:
①缓存时间设置得长,域名更新不及时,设置得短,大量 DNS 解析请求影响请求速度。
②域名劫持,容易被中间人攻击,或被运营商劫持,把域名解析到第三方 IP 地址,据统计劫持率会达到7%。
③DNS 解析过程不受控制,无法保证解析到最快的IP。
④一次请求只能解析一个域名。
HTTPDNS
原理很简单,就是自己做域名解析的工作,通过 HTTP 请求后台去拿到域名对应的 IP 地址,直接解决上述所有问题。
HTTPDNS的好处总结就是:
①Local DNS 劫持:由于 HttpDns 是通过 IP 直接请求 HTTP 获取服务器 A 记录地址,不存在向本地运营商询问domain 解析过程,所以从根本避免了劫持问题。
②DNS 解析由自己控制,可以确保根据用户所在地返回就近的 IP 地址,或根据客户端测速结果使用速度最快的IP。
③一次请求可以解析多个域名。
PS:HTTPDNS 几乎成为中大型 APP 的标配。解决了第一个问题, DNS 解析耗时的问题,顺便把DNS 劫持也解决了。
连接优化
连接建立耗时的问题,这里主要的优化思路是复用连接,不用每次请求都重新建立连接,如何更有效率地复用连接,可以说是网络请求速度优化里最主要的点了。
keep-alive:
HTTP 协议里有个 keep-alive,HTTP1.1默认开启,一定程度上缓解了每次请求都要进行TCP三次握手建立连接的耗时。原理是请求完成后不立即释放连接,而是放入连接池中,若这时有另一个请求要发出,请求的域名和端口是一样的,就直接拿出连接池中的连接进行发送和接收数据,少了建立连接的耗时。 实际上现在无论是客户端还是浏览器都默认开启了keep-alive,对同个域名不会再有每发一个请求就进行一次建连的情况,纯短连接已经不存在了。
但有 keep-alive 的连接一次只能发送接收一个请求,在上一个请求处理完成之前,无法接受新的请求。若同时发起多个请求,就有两种情况:
①若串行发送请求,可以一直复用一个连接,但速度很慢,每个请求都要等待上个请求完成再进行发送。
②若并行发送请求,那么只能每个请求都要进行tcp三次握手建立新的连接。
多路复用
对并行请求的问题,新一代协议 HTTP2 提出了多路复用去解决。 HTTP2 的多路复用机制一样是复用连接,但它复用的这条连接支持同时处理多条请求,所有请求都可以并发在这条连接上进行,也就解决了上面说的并发请求需要建立多条连接带来的问题。
多路复用把在连接里传输的数据都封装成一个个stream,每个stream都有标识,stream的发送和接收可以是乱序的,不依赖顺序,也就不会有阻塞的问题,接收端可以根据stream的标识去区分属于哪个请求,再进行数据拼接,得到最终数据。Android 的开源网络库OKhttp默认就会开启keep-alive ,并且在Okhttp3以上版本也支持了 HTTP2。
数据压缩
传输数据大小的问题。数据对请求速度的影响分两方面,一是压缩率,二是解压序列化反序列化的速度。目前最流行的两种数据格式是 json 和 protobuf,json 是字符串,protobuf 是二进制,即使用各种压缩算法压缩后,protobuf 仍会比 json 小,数据量上 protobuf 有优势,序列化速度 protobuf 也有一些优势 。
除了选择不同的序列化方式(数据格式)之外,Http可以对内容(也就是body部分)进行编码,可以采用gzip这样的编码,从而达到压缩的目的。如在开源网络库OKhttp的 BridgeInterceptor 中会自动为我们开启gzip解压的支持。
其他优化方式
1、使用webp代替png/jpg。
2、不同网络的不同图片下发,如(对于原图是300x300的图片):
(1)2/3G使用低清晰度图片:使用100X100的图片;
(2)4G再判断信号强度为强则使用使用300X300的图片,为中等则使用200x200,信号弱则使用100x100图片;
(3)WiFi网络:直接下发300X300的图片
3、不同需求的不同图片下发,如(对于原图是300x300的图片),若实际只需要25X25,则向服务器请求该尺寸的图片
4、http开启缓存,根据应用的实际情况并和协商缓存方案。什么情况下读取缓存,针对部分接口直接采取长缓存机制。通过缓存时间控制缓存的使用。
5. 通过okhttp拦截器设置,模拟网络环境,让你更好的找到发现问题。