基本概念
业务成功率
有两个真实的场景是用户可能遇到的：一个是点外卖时进了电梯，一个是听演唱会时上传照片。就大家的体验来说，这是最有可能发送失败的场景。刚好，这两个场景分别代表两种典型的网络差的场景，进电梯代表弱信号网络，而演唱会则代表拥塞网络，处理不当都会直接影响业务的成功率。
弱信号，可以简单看成当手机信号只有一两格的时候，这时不仅仅是信令（无线网络其实通信的都是一个个信令）发出去困难，而且还有可能导致不断切换网络、切换基站。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里面的内嵌图片与压缩包里面的图片重复。
