相对于有线网络，移动网络有如下的特性：带宽低，延迟高，丢包率高，稳定性差。3G网络的带宽一般为下行100-200KB/S，上行10-100KB/S，延迟0-400ms，带宽方面基本逼近2M有线网络，但延迟较高，稳定性不够。而2G更是惨不忍睹：一般只有10KB/S下行和1KB/S左右的上行速度，延迟基本不低于400ms，网络环境不好时甚至有数秒的延迟。下面针对这些情况给出个人总结的八条网络优化的小贴士。
建议1：尽量使用IP而非域名进行连接
对于有线网络来说DNS查询可能是一件不费吹灰之力的事，但是对于移动网络来说却不是这样，一次DNS查询的耗时甚至都能赶得上一次连接的耗时。于是在有条件的情况下，缓存服务器IP地址和端口，并尽量使用IP进行连接是个好的选择。另一个原因是中国移动的DNS服务相当不靠谱，错误率极高(传闻出错率在60%以上)。我们就碰到过几次某个地段的童鞋使用移动2G总是无法解析域名的情况。
建议2：减少不必要的网络连接
大多数的移动网络(3G)并不允许一个给定IP地址超过两个的并发HTTP请求，既当你有两个针对同一个地址的连接时，再发起的第三个连接总是会超时。而2G网络下这个限定为1个。同一时间发起过多的网络请求不仅不会起到加速的效果，反而有副作用。
另一方面，由于网络连接很是费时，保持和共享某一条连接就是一个不错的选择：比如短时间内多次的HTTP请求。像ASIHttpRequest就提供setShouldAttemptPersistentConnection的方法：
By default, ASIHTTPRequest will attempt to keep
connections to a server open so that they can be reused by other
requests to the same server (this generally results in significant speed
boost, especially if you have many small requests). Persistent
connections will be used automatically when connecting to an HTTP 1.1
server, or when the server sends a keep-alive header. Persistent
connections are not used if the server explicitly sends a ‘Connection:
close’ header.
建议3：设置合理的超时时间
过短的超时容易导致连接超时的事情频频发生，甚至一直无法连接，而过长的超时则会带来等待时间过长，体验差的问题。就目前来看，对于普通的TCP连接30秒是个不错的超时值，而Http请求可以按照重要性和当前网络情况动态调整超时，尽量将超时控制在一个合理的数值内，以提高单位时间内网络的利用率。即时通讯聊天软件app开发可以加蔚可云的v：weikeyun24咨询
建议4：减少网络请求
使用一种有效的传输格式和压缩网络请求/反馈是两种行之有效的方法。前者主要应用于使用自定义协议的场景：用protobuf明显会比json/xml更省流量；而后者多出现在Http相关的场景，比如使用gzip对Http请求和反馈进行压缩。
建议5：使用缓存
其实这也算是对好地方4的补充：在本地有有效数据的情况下直接不发起网络请求。配置文件，资源文件，描述文件，几乎所有的文件都可以成为我们缓存的对象，而大部分涉及到网络相关的iOS第三方库都提供了极其方便的缓存方法，程序员唯一需要考虑的就只有缓存容量和过期时间的问题。
建议6：使用断点上传和分段上传
一方面可以在重新传输时省去已传输数据的流量，而另一方面将文件分成几个请求上传可以尽量减少传输中的包大小，避免高丢包率环境导致TCP包丢包重传甚至失败，保证传输的成功率(当然也减低了效率)。
建议7：平衡网络延迟和带宽的影响
对于移动网络这种高延迟低带宽的情况，需要综合考虑进行平衡配置：在一个固定网络下，当包大小小于1500字节时(一个TCP的Payload)，网络延迟的影响基本是一个常数，此时网络延迟的影响主要体现在请求次数上，所以合并多个小请求到一个包内是一个合理且有效的做法。而在包大小超过1500字节后，随着包大小的增加，延迟的影响会越来越小，但相应的带宽的影响会越来越大。
建议8：合理地选择加密
对于信息安全来说，最理想的状态是所有的请求都是通过加密的。这对于PC来说并不是一个问题，但是对于电量资源有限的移动端来说却是一个需要好好权衡的问题：网络传输中加密的使用增加了CPU的负担同时也激活了其他资源，这将导致电量更快地被损耗。对于非机密的信息比如图片资源，描述资源就完全可以不进行任何加密。