资源类性能中，磁盘、内存、CPU是本地资源，但是除了这些之外，还有一个特别的存在——网络，之所以特别是因为它是外部资源。对于移动互联网来说，优化网络的性能非常重要。而我们优化网络性能无非看三个问题：业务成功率、业务网络时延、业务宽带成本。

基本概念

业务成功率

有两个真实的场景是用户可能遇到的：一个是点外卖时进了电梯，一个是听演唱会时上传照片。就大家的体验来说，这是最有可能发送失败的场景。刚好，这两个场景分别代表两种典型的网络差的场景，进电梯代表弱信号网络，而演唱会则代表拥塞网络，处理不当都会直接影响业务的成功率。

弱信号，可以简单看成当手机信号只有一两格的时候，这时不仅仅是信令（无线网络其实通信的都是一个个信令）发出去困难，而且还有可能导致不断切换网络、切换基站。App能做的，就是在应用层做重试，因为很有可能这个弱信号是一时的。

另外一个是拥塞网络，简单地理解就是，堵车、排队，数据包排队，信令也在排队。这时App不断重试，只会使得拥塞更为严重。最多能做的就是让自己的非核心业务不要捣乱，不要也去排队，让核心业务的数据量更少，协议来回更少。

业务网络延时

比起成功率，网络延时虽然影响没这么直接，但是慢带来的不爽，也是会流失用户的。这个慢就必须从一个数据包的发送历程开始说起，如图所示。以下我们来对业务网络延时的原因作逐个分析。

DNS解析，简单来说就是域名换IP。这一步看似简单却是充满陷阱，10分钟的DNS Cache过期时间，200～2000ms不等的DNS解析耗时，就像猪一样的队友，坑了无数应用。解决无非有三个策略：IP直连、域名重用、HttpDNS（简单来说就是利用自定义的协议获取域名对应的IP地址，甚至是列表）。

建立连接，大多数应用都是基于TCP的，所以无非就是三次握手建立TCP连接。这一步的耗时，如果是长连接的话，就是一次消耗，短连接则是每次都会有这个消耗。要维护长连接就必须要心跳包，心跳包多，会耗电，特别是当心跳间隔等于移动网络状态机Active-Idle切换间隔时，简直就是悲剧，同时对于移动网络来说还会增加信令通道的负担；心跳包少了，会让连接在NAT中超时，导致长连接断开。在建立连接的过程中，TCP会进行一些商定，其中影响网络时延最明显的就是窗口。

接收窗口，用于拥塞控制。以发送图片为例，服务器的接收窗口就像你告诉客户端，我的池子有多大，你就放多少水给我，客户端放多少水涉及同一时间发送多少TCP数据包，当前的带宽有没有被充分利用，直接影响发送的速度。而让窗口太少的原因无非几个：①服务器的ReceiveBuffer太小；②因为慢启动，而包又太小，刚刚连接，慢启动会逐步放大窗口，没有等放大完，数据就发完了；③Window size scaling factor失效，这里最有可能的原因是网络代理，失效的结果就是窗口最大只有65536字节。

业务宽带成本

如果说一定要考虑流量的原因，除了流量大对业务成功率和网络时延的影响外，就应该是宽带成本了。对于视频、图片这些富媒体业务，每天在宽带成本上的投入，跟烧钱没什么区别。如何节省这些成本，同时也为用户带来好处呢？策略有压缩、增量、去重复三种。

先说压缩，图片用WebP压缩、PNG压缩，还可以用progressive jpeg的不同程度压缩来替代大中小图，视频用H264、H265压缩，文本用gzip压缩和其他ZIP压缩方案。除此之外还有一些细节可以说说：①图片的尺寸在不同分辨率的屏幕上要下载不同的尺寸，设计时要注意；②WebP图片的编码和解码对于手机是有压力的，CPU消耗是JPEG的3倍以上，编码耗时也比JPEG要长不少。所以使用的时候要注意，千万不要是性能压力大的场景。建议解码后在本地保存成JPEG，以降低下次解码的压力。

增量，要做增量，协议的复杂度会上升不少。因此也不要强求，关键要看业务是不是经常变化与业务的规模。

最后是去重复，表面上这看是最简单的问题，但是却最常见。如压缩包里面的图片和没有压缩的内容重复，CSS里面的内嵌图片与压缩包里面的图片重复。

网络测试要点

各个网络下功能测试

各个网络下的功能测试建议将整体的功能测试用例在弱网环境下进行一轮测试，相同模块下的功能可以分多个网络条件进行测试。

这部分发现的问题可能会有：页面图片在弱网环境下加载不出来（图片加载逻辑需优化）、需要模版的页面版式结构混乱（模版文件在弱网环境的加载需优化）、页面响应时间较长没有任何显示（页面显示逻辑待优化、重试机制加入）等。

无网测试

无网状态测试则是在切断网络的情况下进行的测试，主要关注页面的显示与交互、本地数据的存储、断网功能的使用等。通常来说需要注意下面几点：

1、断网情况下请求一个非本地数据的页面需要设定一定的时间等待上限，及时提示网络异常以及提示重试；

2、断网情况下请求一个部分本地数据的页面需要观察本地数据的部分是否加载显示正常，待请求的部分是否符合交互给的缺省样式；

3、断网情况下请求一个完全本地数据的页面是否显示正常。这里还需考虑本地数据存储的情况，有些需要联网后上报服务器的数据本地是否正确存储，联网后这些数据能否正常上报。

无网状态测试建议按照页面划分进行，针对每个页面单独测试无网状态的显示，页面间跳转的显示，页面内功能的点击和显示，同时关注无网到有网时的页面恢复显示状态、数据上报情况是否正常。

网络切换测试

这部分主要是进行几个不同网络场景的切换，包括wifi-2G/3G/4G、wifi-无网、2G/3G/4G-wifi、2G/3G/4G-无网、无网-2G/3G/4G、无网-wifi等。主要关注页面的显示与交互，尤其是弱网到wifi，wifi到弱网的情况，是否会有页面的crash以及显示的错乱、session是否一致、请求堆积处理等。

用户体验关注

弱网测试的目的就是尽可能保证用户体验，关注的关键点包括：

页面响应时间是否可接受，关注包括热启动、冷启动时间，页面切换，前后台切换，首字时间，首屏时间等。
页面呈现是否完整一致。
超时文案是否符合定义，异常信息是否显示正常。
是否会有超时重连。
安全角度：是否会发生dns劫持、登录ip更换频繁、单点登录异常等。
大流量事件风险：是否会在弱网下进行更新apk包、下载文件等大流量动作。

弱网测试

什么样的网络属于弱网

低于2G速率的时候都属于弱网，3G也可划分为弱网，一般Wi-Fi不划入弱网测试范畴。

如何进行弱网测试

SIM卡的网络切换（手机-设置-移动网络设置-网络类型选择，3G、4G卡都可以设置关闭3G/4G，只走2G网络）
具体弱网场景测试，常见场景包括：地铁/巴士、电梯、楼梯间、停车场
使用虚拟机模拟网络速度，如用树莓派搭建的弱网测试仪
使用软件进行网络代理，模拟不同的网络带宽、延时率、丢包率

弱网模拟常用工具

方法一：利用抓包工具charles进行弱网设置，适用PC端和移动端（IOS／Android）

配置参数解析：

bandwidth —— 带宽，即上行、下行数据传输速度。

utilisation —— 带宽可用率，大部分 modern是100%。

round-trip latency —— 第一个请求的时延，单位是ms。

MTU —— 最大传输单元，即TCP包的最大size，可以更真实模拟TCP层，每次传输的分包情况。

Releability —— 指连接的可靠性。这里指的是10kb的可靠率，用于模拟网络不稳定。

Stability —— 连接稳定性，也会影响带宽可用性，用于模拟移动网络，移动网络连接一般不可靠。

具体网络设置参考：

方法二：使用chrome浏览器的开发者工具，适用web端打开开发者工具，打开Network，点击No throttling下拉框

方法三：使用手机自带的限速功能，只适用iOS设备打开iOS设备，设置->开发者->NETWORK LINK CONDITIONER，系统已经内置常见网络配置，也可以增加自定义配置。（我们集团内部有个叫网络大师的应用可以在iOS和Android手机上直接通过VPN设置网络状态）

有兴趣的同学也可以自己通过树莓派利用Facebook的 ATC搭建弱网模拟环境，后面有时间我再写一篇关于这部分的文章。

案例分析

从公司大数据平台中可以看出我们的应用在各网络类型的分布，其中2G和3G用户仍然占有不小的比重，所以弱网络下的性能更需要关注和优化，尤其当低端机碰上弱网络，情况更糟糕。

我们分别在高、中、低三种类型的设备上进行了在不同弱网环境下的测试，大致发现存在下面的一些问题：

在弱网、高延时等网络环境下定位时间过长
在弱网下部分H5页面加载失败率较高
无网络状态下显示加载失败状态时间过长
在WiFi/2G/3G/4G切换到无网状态时，首页UI呈现有问题，卡在加载状态

基于上面发现的问题进行针对性修复，特别是当检测到当前无网络，最好降低请求超时时间或者停止网络请求（如果最终大概率会加载失败，那最好不要让用户等待太长时间）

总结：通过以上分析，不通过弱网进行测试，这些问题不易被发现，用户量极大的APP应用，网络性能测试是必须要做的，这样才能有效地保证用户体验。

通过标准

最佳实践