一.分析网络请求流程及耗时
1、网络请求的过程
发起请求 -> 域名解析 -> tcp三次握手 ( -> tls握手 -> ) -> request -> response -> json解析 -> 业务
2、耗时统计
在了解了网络请求的流程之后，我们可以先测试一下自己项目网络请求耗时分布。
通过监听NSURLSession的didFinishCollectingMetrics回调方法，了解各种耗时操作
- (void)URLSession:(NSURLSession *)session task:(NSURLSessionTask *)task didFinishCollectingMetrics:(NSURLSessionTaskMetrics *)metrics API_AVAILABLE(macosx(10.12), ios(10.0), watchos(3.0), tvos(10.0))
{
if (@available(iOS 10.0, *)) {
for (NSURLSessionTaskTransactionMetrics *sessionMetric in metrics.transactionMetrics) {
NSInteger dom = ([sessionMetric.domainLookupEndDate timeIntervalSince1970] - [sessionMetric.domainLookupStartDate timeIntervalSince1970]) * 1000 ;
NSInteger sec = ([sessionMetric.secureConnectionEndDate timeIntervalSince1970] - [sessionMetric.secureConnectionStartDate timeIntervalSince1970]) * 1000;
NSInteger con = ([sessionMetric.connectEndDate timeIntervalSince1970] - [sessionMetric.connectStartDate timeIntervalSince1970]) * 1000;
NSInteger req = ([sessionMetric.requestEndDate timeIntervalSince1970] - [sessionMetric.requestStartDate timeIntervalSince1970]) * 1000;
NSInteger res = ([sessionMetric.responseEndDate timeIntervalSince1970] - [sessionMetric.responseStartDate timeIntervalSince1970]) * 1000;
NSInteger tot = ([sessionMetric.responseEndDate timeIntervalSince1970] - [sessionMetric.fetchStartDate timeIntervalSince1970]) * 1000;
NSString *locip = @"";
NSString *remip = @"";
if (@available(iOS 13.0, *)) {
locip = [NSString stringWithFormat:@"%@", sessionMetric.localAddress];
remip = [NSString stringWithFormat:@"%@", sessionMetric.remoteAddress];
}
NSLog(@"metric path:%@ 总耗时:%ldms, 域名解析:%ldms, 连接耗时:%ldms(包括TLS:%ldms), 请求:%ldms, 回调:%ldms l:%@ r:%@",sessionMetric.request.URL.lastPathComponent,tot,dom,con,sec,req,res, locip, remip);
}
}
}
此时就可以进行对应的网络情况优化。
二.优化思路
1、域名解析耗时
我们常用的HTTP(HTTPS)请求，底层基于TCP连接，需要有IP和端口信息。由于IP是可变的，且不好记忆，所以有了域名这样一个字符串帮助人们进行记忆。
域名到IP需要经过DNS服务器来进行获取，这一过程使用的UDP方式，这一过程的快慢取决于网络质量以及域名映射关系存放的DNS服务器跟你所在地跨越的层级。甚至有一些不可控的情况会导致域名解析出来一个错误的IP地址。
为了提高域名解析速度，以及减低域名污染风险，我们可以使用HTTPDNS的方式来进行IP获取。也可以设计一套IP直连方式获取域名IP池机制。
在APP启动后检查更新DNS服务IP的更新，域名IP池的更新，以及对IP池中的IP进行测速，选择网速较好的IP。在使用IP直连请求时，需要修改request的host，以及证书校验的host。
2、连接耗时
2.1 建立连接需要的耗时较长，如果之前使用的是HTTPS，考虑使用HTTP。
2.2 或者如果能够利用长连接可以保持的特性，那么这块的耗时优化非常可观，长链接优化这块需要后端支持，我们可以设计一个通道API，将多个域名的请求放在同一个连接中进行请求，这块需要网络库层和后端进行协议开发，业务端可以普遍享受到增益。
当然，我们也要考虑在通道不可用时，及时采用常规请求方式的策略。以及HTTP1.1存在队头阻塞问题，需要在HTTP2.0上才能真正起到优化效果。
2.3 还有就是request及response(download)优化。request耗时一般是在服务端，如果遇到耗时较长的情况需要找一下服务端同学排查一下是否有耗时逻辑。response耗时较长一般是网速慢或者数据体积大导致的，体积大这个问题可以通过删减冗余数据，开启gzip，数据分页等方式进行优化。
3.json解析
json解析在数据量不大的情况下一般耗时不会太多，如果遇到数据量特别大的情况可能就需要考虑怎么降低数据量，采用解析效率更高的库，可以参考如下网图。（这种情况一般导致response耗时较长，并且无法优化的情况下）
YYModel原理和MJExtension类似，都是基于runtime进行动态获取属性进行赋值。前者使用了CoreFoundation更底层的方法以及内联函数的应用所以效率上得到了大幅提高。
4、业务侧优化
4.1 网络请求优先级排布，通过对业务代码梳理，在启动阶段进行高优先级接口请求，对可以合并的接口进行合并，落地点销毁的请求及时取消请求。
4.2 升级HTTP2.0，利用其二进制分帧，头部压缩，head block优化的特性，降低请求数据量，提高并发请求效率。
5、弱网优化
弱网环境是移动APP经常需要面对的问题，地铁，人员密集区域，运动，都有可能导致网络请求不稳定，失败等问题。
HTTP1.1，2.0都是采用的TCP连接方式，而TCP需要三次握手，断开后需要重新握手，这些会导致在弱网,运动环境持续请求失败。
QUIC协议是谷歌提出的基于UDP的数据传输协议，HTTP3.0就是采用的QUIC实现机制。使用HTTP3.0进行网络请求可以享受到如下这些进步，当然这得服务端和客户端共同配合才能完成。
更好的连接建立方式
更好的拥塞控制
没有队头阻塞的多路复用
前向纠错
连接迁移
