这期客户端做了性能优化,程序猿到底做了啥?(二)


书接「上回」,今天咱们继续讲讲客户端性能优化的那些事儿。

上一期讲到关于程序启动速度和操作卡顿的优化,这些都是「面子」工程,用户可以很直观的感受到。今天说到的「内存」和「流量」的优化就需要「透过现象看本质」了。

1、内存优化

有篇老文章专门讲过「内存泄漏」,是内存优化过程中需要重点解决的问题。程序一旦发生了「内存泄漏」,不仅会导致应用程序自身出现卡顿甚至异常退出的现象,更会影响整个系统的性能。如果产品一直在被用户反馈「怎么用的时间长了就变卡了?」,那十有八九是「内存泄漏」了。解决「内存泄漏」的关键就是找到「谁」把内存「借走了没还」

上图就是Android 平台的一个定位「内存泄漏」的工具截图,图中的每一行都标出了当前场景下,谁(Class Name)占用了多少内存(Retained Heap),程序猿就是根据这个表格结合当前的场景来定位出哪些家伙造成了「内存泄漏」。比如在主界面,竟然发现还有一张大大的闪屏图片在内存中,这时候就要找开发闪屏的同学好好交流下了。

2、网络流量优化

在iOS系统上,由于系统的限制,应用程序一般很难会出现「异常后台流量」的情况,但是在「开放」的Android 平台上,如果控制的不好,很容易被用户吐槽App的「后台流量」问题。

「抓包」是定位流量问题的一个好方法。这个在老文章里面也有介绍过。客户端抓包与chrome浏览器内抓包方式虽有所不同,但分析的方法大同小异。

把应用程序压后台,启动抓包程序,一段时间之后,分析抓包数据。如下图:

上图就是通过WireShark软件解析出来的抓包数据,展示了抓包过程中客户端发出的网络数据包。程序猿通过分析数据包的目标IP、协议类型(TCP、UDP等)以及报文(数据包的具体内容)来定位那些网络请求在后台状态下是非必须的,哪些网络请求的频率是可以降低的,并以此来降低后台流量。

另外,程序猿还可以使用「合并请求」的方式来减少一些必要请求的流量。每个数据包都有「包头」和「数据」两部分。「包头」的格式一般是固定的,是整个数据包大小的一部分。「合并请求」就是将同一时刻相同「包头」的多个数据包,合并成一个数据包发送出去。举个栗子,你有今天你有10件物品要快递到同一个地址,合并成一个包裹邮寄肯定比分成10个包裹邮寄更省钱(至少箱子省了)!

来源:给产品经理讲技术,本文观点不代表自营销立场,网址:https://www.zyxiao.com/p/105420

发表评论

登录后才能评论
服务中心
服务中心
联系客服
联系客服
侵权联系 投诉举报
返回顶部
河南,挺住!郑州,挺住!一起为他们加油!!