2016 March 23

Android性能优化之网络优化

熟悉 3G 网络机制,需要知道根据网络状态的不同和其电量或性能消耗是有差异的,分为 Full Power状态,Low Power状态,以及 Standby 状态;

每次发起一个网络请求将激活3G无限网络状态,直接到达FullPower状态,而后将在数据传输全程保持该状态,在数据传输完成后附带一个曳尾时间,逐步降低到 Low Power状态,最后稳定到达 Standby状态;若频繁开启网络请求,势必导致多个曳尾状态,徒增不必要的电量消耗,故而 多个请求合并是比较合适的,一种比较好的方式是数据的预读取,数据的预读取需要取舍有度,过多的预读取会导致流量消耗异常,过少的预读取往往作用不明显,同时根据网络环境的不同需要特别处理数据的预读取问题,Wifi环境下 电量的消耗要少于 3G无限网络,所以要珍惜Wifi环境的使用;

预读取比较合适的举例就是网络音乐播放器,一般我们打开音乐播放器在线播放会发现,缓存条是每次走完很长一格,这种维护数据缓存进而减少请求次数的做法是比较合适的,通过每次请求合适的缓存数据,当播放进度快到时请求下一批量数据,而不是利用网络请求维护播放数据进度,每次请求少量数据将导致大量电量被消耗;

同时 在预读取时 可以通过网络环境的判断,当确定在Wifi环境下,更加大的带宽网络可以更加显著减少数据请求次数与网络数据请求获取时间;

利用DDMS的网络监控工具可以方便的查看网络请求状态,我们也可以利用抓包工具获取网络请求以及响应数据;

网络是一项宝贵资源,网络获取的数据要珍惜,一旦下载了需要用心维护,利用缓存,在合适的场景尽可能多重用缓存,要知道磁盘的IO对比网络的操作的性能消耗以及电量消耗以及时间消耗都要少得多;这些在Volley的源码中都有完美展现,于此同时在缓存的使用过程中,要注意数据的有效性,或者说时效性;若数据失效需要更新缓存;

缓存文件的存放应该尽可能避免随意利用系统存储空间,随意的缓存目录将导致程序被删除后文件,冗余文件充斥着用户杂乱的磁盘,做一个有操守的App应该尽可能的利用 Context.getCache(); 获取内存目录,而利用 Context.getExternalCacheDir();获取外部磁盘应用关联目录,这些目录将在程序删除后,自动被系统清理;

服务器控制缓存 Http 头(Cache-Control) 以及 同时在客户端 开启 HttpURLConnection 响应缓存 —— 利用服务器 cache参数,确定数据是否缓存以及确定缓存的有效时间;理解缓存命中;

开启Http长连接复用连接,提升数据请求速度,避免多次开关Tcp连接,减少连接数可以减少Cpu以及内存使用情况,优化连接与响应情况;

尽可能避免低效率的轮询机制去更新数据,轮询会使数据即损耗性能同时导致电量大量流失,尽可能利用持续Tcp连接去做服务器推送机制,服务器推送机制可以避免无用的轮询操作;那么在某些情况下,使用轮询机制如何在轮询频率以及数据更新有效性之间平衡是一门学问,可以利用Google推荐的指数退避算法,也就是设定一个频率更新的最大值,同时指定初始更新值,若更新失败则减缓下次更新轮询的时间间隔,直到间隔时间等于最大时间间隔:

private void retryIn(long interval) {
  boolean success = attemptTransfer();

  if (!success) {
    retryIn(interval*2 < MAX_RETRY_INTERVAL ?
            interval*2 : MAX_RETRY_INTERVAL);
  }
}

总结一下

数据格式方面:精简数据格式 Json 替代 XML,具体分析情景确定是否采用更加高效的Json解析库 Jackson Gson等;数据 Body 利用 Gzip压缩;

请求方面:请求捆绑,批量请求,合适的预读取量;复用连接开启Http长连接(要理解Http长连接依旧是Tcp连接的复用);尽可能避免轮询,采用服务器推送,无法避免情况下合理控制轮询频率;采用OkHttp;

数据缓存: 服务器开启 ,缓存Lru,

大文件资源: 图片多格式定义(不同情景请求不同数据 大图、小图),Webp代替 Jpg等;针对不同的情况合适的选择牺牲图片质量;


Quote:

胡凯-Android性能优化典范

http://www.jianshu.com/p/3141d4e46240

HTTP协议 (四) 缓存

上一篇
下一篇
Loading Disqus comments...
Table of Contents