深度优化 iOS 网络模块

   <p>几乎每一个讲究的iOS项目都会有一个「网络模块」，大部分的网络请求都是通过HTTP完成，使用成熟的第三方库诸如AFNetworking很容易搭建一个功能简易的网络模块。但这一模块要优化好却没那么简单，是个旷日持久的工作，笔者根据自己多年的“填坑”经验，总结一下深度优化iOS项目网络模块的方方面面，也给自己做下知识梳理。</p>    <h3><strong>预热</strong></h3>    <p>网络模块的接口设计不在本文讨论之列，设计思路有些偏个人口味，我只探讨一些可以深度优化的硬性指标。在开始讨论优化之前，需要读者对网络方面的理论基础知识有一定的掌握。读过TCP/IP协议详解，RFC文档就更佳。优化的东西对知识的深度和广度都有相当的要求，各项目场景不一样，依葫芦画瓢很可能会导致更多的问题，“优化”是个危险活。</p>    <p>在开始优化之前，我们先建立样例代码，这样讨论起来才能有的放矢。假设我们定义这样两个请求类：</p>    <pre>  <code class="language-objectivec">@interface PPRequestManager : NSObject  @end  @implementationPPRequestManager  @end     @interface PPRequest : NSObject  @end  @implementationPPRequest  @end     </code></pre>    <p>一个Manager负责管理Request，一个Request基类处理公共逻辑。</p>    <h3><strong>优化清单</strong></h3>    <p><strong>DNS映射</strong></p>    <p>无论是HTTP还是Socket长连接，第一步都是DNS解析。域名根据层级「主机名.次级域名.顶级域名.根域名」去解析，每一级缓存生命周期不同。在iOS设备上几乎每次断网重连，重启设备都会使DNS缓存失效，触发重新查询。这一步的优化对请求的延迟来说至关重要，具体优化手段可参考我之前一篇关于 <a href="/misc/goto?guid=4959721347959752715" rel="nofollow,noindex">DNS映射的文章</a> ，配有可用的demo代码，这里就不复述了。</p>    <p><strong>请求压缩</strong></p>    <p>DNS查询之后是TCP握手建立连接，并发送请求数据。对于TCP来说，单个IP包大小受限于MSS值，大部分用户所处网络环境下每个包的大小约在1.5KB，新建立的HTTP连接由于TCP的slow start特性，会导致本地的部分IP包本临时缓存，从而增加了整体request的延迟。所以我们应该尽可能尝试去压缩我们的网络请求业务数据，减少一个Request的IP包数量，或许可以让用户少经历一个RTT，降低请求延迟的用户感知。</p>    <p><strong>请求合并</strong></p>    <p>对于非关键性的业务数据，或者对实时性要求不高的请求来说，通过合并请求的方式可以减少和服务器交互的次数，一则降低服务器压力，二则合并之后再压缩能节约客户端的流量。这类请求一般见于打点SDK，crash日志收集等非业务型请求。</p>    <p><strong>请求的安全性</strong></p>    <p>请求的网络安全是个容易被忽视的话题，建议细读再配合使用HTTPS来做到基本的网络安全，这里也不再细述了。</p>    <p><strong>合理的并发数</strong></p>    <p>有些业务场景会出现多个Request集中产生的情况，此时我们需要设置一个合理的并发数。并发数如果太小，会导致“劣质”的请求block住“优质”的请求。如果并发数太大，带宽有限的场景下，会增加请求的整体延迟。</p>    <p><strong>可靠性保障</strong></p>    <p>可靠性保障也是个容易被忽视的方面，在深入探讨之前，可以先将Request按业务属性分类。</p>    <ul>     <li> <p>第一类：关键核心的业务数据，期望能100%送达服务器。</p> </li>     <li> <p>第二类：重要内容请求，需要较高的请求成功率。</p> </li>     <li> <p>第三类：一般性内容请求，对成功率无要求。</p> </li>    </ul>    <p>之所以要将请求分为三类，是要在可靠性保障上做区分。理论上我们应该尽可能让所有的请求成功率达到最高，但客户端的流量，带宽，手机电量，服务器的压力等都是有限的资源，所以我们采取的策略是只对关键性的网络请求做高强度的可靠性保障。</p>    <p>第一类请求类似大家用微信时发送的消息，消息数据一旦从输入框发出，从用户来的角度感知这个消息数据是一定会到达对方的。如果网络环境差，网络模块会自动在后头悄悄重试，一段时间后仍无法成功就通过产品交互的方式告知用户发送失败了，即使失败，请求的数据（消息本身）一直存在客户端。</p>    <p>对于这类请求的处理方式第一步不是通过网络发送，而是持久化到Database当中。一旦入了DB，即使断网，断电，重启，请求数据依然还在，只需在App重启的时候还原请求数据，再次发送即可。我们用代码来进一步阐释。</p>    <pre>  <code class="language-objectivec">//定义请求可靠性类型  typedef enum : NSUInteger {      PPRequestReliability_PersistentToDB,      PPRequestReliability_Retry,      PPRequestReliability_Normal,  } PPRequestReliability;     //增加持久化接口  @interface PPRequest : NSObject     @property (nonatomic, assign) PPRequestReliability    reliability;  @property (nonatomic, strong) NSNumber*              rowID;  @property (nonatomic, strong) NSNumber*              reliabilityStatus;     - (PPRequestRecord*)serializeToRecord;  - (PPRequest*)deserializeFromRecord:(PPRequestRecord*)record;     @end     </code></pre>    <p>第一类请求是PPRequestReliability_PersistentToDB，新增了rowID用作存储DB时的唯一标识，reliabilityStatus表示请求的当前状态（成功 or 失败 or 取消 or 进行中），我们再看下发送请求的流程。</p>    <pre>  <code class="language-objectivec">@implementationPPRequestManager     - (void)sendRequest:(PPRequest*)reqwithDelegate:(id)delegate  {      if (req.reliability == PPRequestReliability_PersistentToDB) {          PPRequestRecord* record = [reqserializeToRecord];          //save record to database      }            //send request  }     - (void)onRequestSucceed:(PPRequest*)req  {      //add to resend queue      [_resendQueueaddObject:req];            //remove from db  }     - (void)onRequestFail:(PPRequest*)req  {      //add to resend queue      [_resendQueueaddObject:req];  }     @end     </code></pre>    <p>如果判断为第一类请求，第一步我们先将请求持久化到DB当中。</p>    <p>第二步发送请求，如果请求失败则将请求加入重试队列，成功则从重试队列中移除。重试队列背后也需要一套通用机制，比如多久重试一次，重试几次之后放弃。</p>    <p>遇到最恶劣的场景，请求发送失败之后，App被kill。我们需要在App重启之后从DB当中重新load所有失败的请求再次重试。</p>    <pre>  <code class="language-objectivec">- (void)resendPreviousFailedRequest  {      //load from db            //send requests  }     </code></pre>    <p>通过上述几步基本上可以使请求的可靠性得到极大的保障。但100%是无法实现的理想，失败的时候用户重装App，所有持久化的数据丢失，请求数据也就丢了，不过这种极端的场景非常少。</p>    <p>第二类请求的可靠性为PPRequestReliability_Retry，这类请求的例子可以是我们App启动时用户看到的首页，首页的内容从服务器获取，如果第一次请求就失败体验较差，这种场景下我们应该允许请求有机会多试几次，增加一个retryCount即可。</p>    <pre>  <code class="language-objectivec">//PPRequest.h  @property (nonatomic, assign) int                    retryCount;     </code></pre>    <p>一般3次的重试基本可以排除网络抖动的情况。三次失败之后即可认为请求失败，通过产品交互告知用户。</p>    <p>第三类请求的重要性最低，比如进入Controller的UV采集打点。这类请求只需要做一次，即使失败也不会对产品体验产生什么负面影响。</p>    <p><strong>多通道</strong></p>    <p>现在不少有技术条件的团队都有自己的tcp长连接通道，技术再硬点的甚至配有UDP通道，UDP在丢包率高的网络环境下能极大的提高请求成功的概率。如果能同时具备HTTP，TCP，UDP三条网络通道，在某些场景下，如果不考虑流量（比如wifi），可以针对某个网络请求，两通道或者三通道齐发，对请求成功的速度和可靠性有明显的疗效，不过客户端和服务器都需要针对业务场景做去重。我工作过的一个IM App在发送消息的时候，就是Socket配合HTTP双通道工作。UDP在VOIP服务当中使用较多，不过据说淘宝这类大厂也部分启用了UDP。</p>    <p><strong>网络环境监控</strong></p>    <p>现在网络环境虽然越来越好，Wifi，4G，3G在一二线城市都有很好的普及，但还是有不少场景会导致网络状态突然变差，比如进电梯，做火车，人多的集会场所，从公司回家4G切Wifi等等，这些场景在生活当中并不少见，健壮的网络模块需要仔细的检测网络的变化，针对性的做请求重试。</p>    <p><strong>请求成功率监控</strong></p>    <p>网络模块应该能监控当前App的网络请求成功率，对于失败率较高的请求，带上业务数据，手机网络环境，系统参数等等，在用户不活跃的时候能打包上报给server端，一则能找出更多需要优化的业务场景，二则能实时监控server端的健康状态，三则能从数据层面精确判断每一次网络优化是否有成效。</p>    <p>以上是做项目当中容易遇到的优化点，有些方面只是提到，要实际操作深入优化还有很多可以细说，后续如果想到更多再补充。</p>    <p> </p>    <p> </p>    <p> </p>    <p>来自：http://ios.jobbole.com/89789/</p>    <p> </p>