资讯专栏INFORMATION COLUMN

性能优化5--网络优化

nodejh / 1920人阅读

摘要:二网络优化网络优化主要从三个方面进行速度成功率流量。直连与解析的失败率占联网失败中很大一种,而且首次域名解析一般需要几百毫秒。请求打包合并网络请求,减少请求次数。

一. 网络监控

1 Network Monitor
Android Studio自带的Network Monitor简单直观,可以看出时间段之内的网络请求数量及访问速率;

2 Charles、Fiddler等抓包工具
使用Charles、Fiddler等抓包工具同样可以实现Network Monitor的功能,而且更加强大。

3 Stetho
Stetho是Facebook出品的一个Android应用的调试工具。无需Root即可通过Chrome,在Chrome Developer Tools中可视化查看应用布局,网络请求,sqlite,preference等。同样集成了Stetho之后也可以很方便的查看网络请求的各种情况。

二 网络优化
网络优化主要从三个方面进行:1. 速度;2. 成功率;3. 流量。

1 Gzip压缩
HTTP协议上的Gzip编码是一种用来改进WEB应用程序性能的技术,用来减少传输数据量大小,减少传输数据量大小有两个明显的好处:
可以减少流量消耗;
可以减少传输的时间。

2 IP直连与HttpDns;
DNS解析的失败率占联网失败中很大一种,而且首次域名解析一般需要几百毫秒。针对此,我们可以不用域名,才用IP直连省去 DNS 解析过程,节省这部分时间。
另外熟悉阿里云的小伙伴肯定知道HttpDns:HttpDNS基于Http协议的域名解析,替代了基于DNS协议向运营商Local DNS发起解析请求的传统方式,可以避免Local DNS造成的域名劫持和跨网访问问题,解决域名解析异常带来的困扰。   3 图片处理
3.1 图片下载
使用WebP格式;同样的照片,采用WebP格式可大幅节省流量,相对于JPG格式的图片,流量能节省将近 25% 到 35 %;相对于 PNG 格式的图片,流量可以节省将近80%。最重要的是使用WebP之后图片质量也没有改变。
使用缩略图;App中需要加载的图片按需加载,列表中的图片根据需要的尺寸加载合适的缩略图即可,只有用户查看大图的时候才去加载原图。不仅节省流量,同时也能节省内存!之前使用某公司的图片存储服务在原图链接之后拼接宽高参数,根据参数的不同返回相应的图片。
3.2 图片上传
图片(文件)的上传失败率比较高,不仅仅因为大文件,同时带宽、时延、稳定性等因素在此场景下的影响也更加明显;
避免整文件传输,采用分片传输;
根据网络类型以及传输过程中的变化动态的修改分片大小;
每个分片失败重传的机会。
备注:图片上传是一项看似简单、共性很多但实际上复杂、需要细分的工作。移动互联网的场景和有线的场景是有很多区别的,例如移动网络的质量/带宽经常会发生“跳变”,但有线网络却是“渐变”。   4 协议层的优化
使用最新的协议,Http协议有多个版本:0.9、1.0、1.1、2等。新版本的协议经过再次的优化,例如:
Http1.1版本引入了“持久连接”,多个请求被复用,无需重建TCP连接,而TCP连接在移动互联网的场景下成本很高,节省了时间与资源;
Http2引入了“多工”、头信息压缩、服务器推送等特性。
新的版本不仅可以节省资源,同样可以减少流量;我对Http2并没有实际接入经验,此处仅从原理进行分析。   5 请求打包
合并网络请求,减少请求次数。对于一些接口类如统计,无需实时上报,将统计信息保存在本地,然后根据策略统一上传。这样头信息仅需上传一次,减少了流量也节省了资源。   6 网络缓存
对服务端返回数据进行缓存,设定有效时间,有效时间之内不走网络请求,减少流量消耗。对网络的缓存可以参见HttpResponseCache。
备注:我们也可以自定义缓存的实现,一些网络库例如:Volley、Okhttp等都有好的实践供参考。   7 网络状态
根据网络状态对网络请求进行区别对待,2G与Wifi状态下网络质量肯定是不一样的,那对应的网络策略也应该是不一样的。例如:在Wifi场景下可以进行数据的预取、一些统计的集中上传等;而在2G场景下此类操作以及网络请求的次数策略都应该调低。网络状态可以由TelephonyManager.getNetworkType()方法获取到。
备注:还可以使用Facebook的开源库network-connection-class来做网络状态的判断。   8 其它
断点续传,文件、图片等的下载,采用断点续传,不浪费用户之前消耗过的流量;
重试策略,一次网络请求的失败,需要多次的重试来断定最终的失败,可以参考Volley的重试机制实现。
Protocol Buffer
Protocol Buffer是Google的一种数据交换的格式,它独立于语言,独立于平台。相较于目前常用的Json,数据量更小,意味着传输速度也更快。
具体的对比可以参见:《Protobuffer和json深度对比》。
尽量避免客户端的轮询,而使用服务器推送的方式;
数据更新采用增量,而不是全量,仅将变化的数据返回,客户端进行合并,减少流量消耗;

 

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/2962.html

相关文章

  • JavaScript 是如何工作的:深入网络层 + 如何优化性能和安全

    摘要:是如何工作的深入网络层如何优化性能和安全这是专门探索及其所构建的组件的系列文章的第篇。为了使网络层高效,它需要扮演的角色不仅仅是一个简单的套接字管理器。套接字组织在按源分组的池中,每个池执行自己的连接限制和安全约束。 JavaScript 是如何工作的:深入网络层 + 如何优化性能和安全 这是专门探索 JavaScript 及其所构建的组件的系列文章的第 12 篇。 如果你错过了前面的...

    BWrong 评论0 收藏0
  • JavaScript 是如何工作的:深入网络层 + 如何优化性能和安全

    摘要:是如何工作的深入网络层如何优化性能和安全这是专门探索及其所构建的组件的系列文章的第篇。为了使网络层高效,它需要扮演的角色不仅仅是一个简单的套接字管理器。套接字组织在按源分组的池中,每个池执行自己的连接限制和安全约束。 JavaScript 是如何工作的:深入网络层 + 如何优化性能和安全 这是专门探索 JavaScript 及其所构建的组件的系列文章的第 12 篇。 如果你错过了前面的...

    susheng 评论0 收藏0
  • 基于文件存储UFS的Pytorch训练IO优化实践

    摘要:我们在协助某客户排查一个文件存储的性能时发现,其使用的训练性能和硬件的能力有很大的差距后面内容有具体性能对比数据。但直接缓存数据在集群规模上升之后肯定是不现实的,我们初步只缓存各个训练文件的句柄信息,以降低元数据访问开销。我们在协助某AI客户排查一个UFS文件存储的性能case时发现,其使用的Pytorch训练IO性能和硬件的IO能力有很大的差距(后面内容有具体性能对比数据)。让我们感到困惑...

    Tecode 评论0 收藏0
  • ThinkPHP 3.2 性能优化,实现高性能API开发

    摘要:目前的业务访问量数千万,后端台,平均使用率。产生的问题长连接数超过时,性能会下降。很可惜,我们目前使用的青云,目前尚不能实现超高可用,也不能实现无缝扩容,私网内的网络传输性能延迟都有很大优化空间。经测试,性能有的提升。 需求分析 目前的业务全站使用ThinkPHP 3.2.3,前台、后台、Cli、Api等。目前的业务API访问量数千万,后端7台PHP 5.6,平均CPU使用率20%。 ...

    siberiawolf 评论0 收藏0
  • ThinkPHP 3.2 性能优化,实现高性能API开发

    摘要:目前的业务访问量数千万,后端台,平均使用率。产生的问题长连接数超过时,性能会下降。很可惜,我们目前使用的青云,目前尚不能实现超高可用,也不能实现无缝扩容,私网内的网络传输性能延迟都有很大优化空间。经测试,性能有的提升。 需求分析 目前的业务全站使用ThinkPHP 3.2.3,前台、后台、Cli、Api等。目前的业务API访问量数千万,后端7台PHP 5.6,平均CPU使用率20%。 ...

    Chao 评论0 收藏0

发表评论

0条评论

最新活动
阅读需要支付1元查看
<