App与Server的交互依赖于网络优化,网络优化项

序言

互联网时代,App作为于用户交互的端,可以说实际上是一个界面,产品的业务,服务都是由Server提供的.而App与Server的交互依赖于网路,故而网路优化,也是我们的App优化中不可缺乏的一个优化项.

1,网路联接对用户的影响

App的网路联接对于用户来说,影响好多,且多数情况下都很直观,直接影响用户对这个App的使用体验.其中较为重要的几点:

2,剖析网路联接的工具

2.1NetworkMonitor

AndroidStudio外置的Monitor工具中就有一个NetworkMonitor:

NetworkMonitor

其中:

如何使用NetworkMonitor?

Networkmonitor实时跟踪选取应用的数据恳求情况.我们可以连上手机,选取调试应用进程,之后在App上操作我们须要剖析的页面恳求.

比如,上图就是以CoderPub为例,针对从repo列表界面步入repo详情界面的监控数据.

可以看见从10s到30s之间,20s时间内发生了多次数据恳求,且22s到27s之间的恳求数据量还很大.

剖析代码可以看见,在恳求repo详情的时侯是打包了好多恳求的:

@OverridepublicObservablegetRepoDetail(Stringowner,Stringname){returnObservable.zip(mRepoService.get(owner,name),mRepoService.contributors(owner,name),mRepoService.listForks(owner,name,”newest”),mRepoService.readme(owner,name),isStarred(owner,name),newFunc5,ArrayList,Content,Boolean,RepoDetail>(){@OverridepublicRepoDetailcall(Reporepo,ArrayListusers,ArrayListforks,Contentreadme,BooleanisStarred){RepoDetaildetail=newRepoDetail();repo.setStarred(isStarred);detail.setBaseRepo(repo);detail.setForks(forks);//becausethereadmecontentisencodewithBase64bygithub.readme.content=StringUtil.base64Decode(readme.content);detail.setReadme(readme);detail.setContributors(users);returndetail;}});}

这也验证了14s到20s间的四次数据恳求,另外因为repo详情界面会显示作者以及贡献者的图片,而图片的数据量相对大,故而23s到27s间有多次数据量很大的恳求发生.

这个实际是有好多优化空间的,我们稍后再说.

2.2网路代理工具

通常来说,网路代理工具有两个作用:

查获网路恳求响应包,剖析网路恳求设置代理网路,联通App开发中通常拿来做不同网路环境的测试,比如Wifi/4G/3G/弱网等.

代理工具好多,例如Wireshark,Fiddler,Charles等,在此不一一细说了,使用方式自行问微软度娘.:)

3,什么方面取优化网路联接

第一节说到了网路恳求对App和用户的影响,这么我们如何从什么方面去优化网路从而降低甚至剿灭这种影响呢?

简单来说,两个方面:

这么,具体应当从什么方面着手呢?

3.1插口设计

API设计

App与Server之间的API设计要考虑网路恳求的频次,资源的状态等.便于App可以以较少的恳求来完成业务需求和界面的展示.

比如,注册登入.正常会有两个API,注册和登陆,并且设计API时我们应当给注册插口包含一个隐式的登陆.来防止App在注册后还得恳求一次登陆插口(有可能失败,因而造成业务流程失败).

再比如,上文提及的获取repo详情,实际上恳求了4个插口,恳求了repo的信息,forks列表,contributors列表,readme,这是由于github提供的插口是尽量单一职责的.但是在我们的实际开发中,我们的Server不仅提供这种单一职责的小插口外,最好能够组合一个满足顾客端业务需求的repo详情插口下来.

Gzip压缩

使用Gzip来压缩request和response,降低传输数据量,因而降低流量消耗.

考虑使用ProtocolBuffer取代JSON

从前我们传输数据使用XML,后来使用JSON取代了XML,很大程度上也是为了可读性和降低数据量(其实还有映射成POJO的便捷程度).

ProtocolBuffer是Google推出的一种数据交换格式.

假如我们的插口每次传输的数据量很大的话,可以考虑下protobuf,会比JSON数据量小好多.

其实相比来说,JSON也有其优势,可读性更高.

本文以网路流量优化的角度推荐protobuf作为一个选择,具体还需更具实际情况考虑.

图片的Size

里面NetworkMonitor中见到的22s到27s之间的有多次恳求,且数据量还很大.就是在获取图片资源.

图片相对于插口恳求来说,数据量要大得多.故而也是我们须要优化的一个点.

我们可以在获取图片时告知服务器须要的图片的宽高,便于服务器给出合适的图片,防止浪费.

我们如今好多公司的图片资源都是使用第三方的云储存服务的(七牛,阿里云储存之类的).

以七牛为例,可以在恳求图片的url中添加例如质量,格式,width,height等path来获取合适的图片资源:

imageView2//w//h//format//interlace//q//ignore-error/

参考七牛官方文档.

3.2网路缓存

适当的缓存,既可以让我们的应用看上去更快,也能防止一些毋须要的流量消耗.

关于AndroidApp的网路缓存,请参考MVP构架实现的Github顾客端(4-加入网路缓存)一文.

3.3打包网路恳求

当插口设计不能满足我们的业务需求时.诸如可能一个界面须要恳求多个插口,或是网路良好,处于Wifi状态下时我们想获取更多的数据等.

这时就可以打包一些网路恳求,比如恳求列表的同时,获取Header点击率较高的的item项的详情数据.

可以通过一些统计数据来帮助我们定位用户接出来的操作是高机率的,提早获取这部份的数据.

3.4窃听相关状态

通过窃听设备的状态:

结合JobScheduler来按照实际情况做网路恳求.比方说Splash死机广告图片,我们可以在联接到Wifi时下载缓存到本地;新闻类的App可以在充电,Wifi状态下做离线缓存.

3.5弱网测试&优化

不仅正常的网路优化,我们还需考虑到弱网情况下,App的表现.

3.5.1弱网测试

有几种方法来模拟弱网进行测试.

AndroidEmulator

创建和启动Android模拟器可以设置网路速率和延后:

创建时:

createemulator

启动时,使用emulator命令:

$emulator-netdelaygprs-netspeedgsm-avdNexus_5_API_22

具体参数参考这儿和这儿,须要翻墙.

使用网路代理工具

以Charles为例:

保持手机和PC处于同一个局域网,在手机端wifi设置中级设置中设置代理形式为自动,代理ip填写PC端ip地址,端标语默认8888.

charlesproxy

charlesthrottling

其他模拟弱网形式

假如你正好也是iOS的开发者,Apple提供了NetworkLinkConditioner,特别好用.

可以模拟的网路情况与上述类似:

ios_network

假如你使用Linux环境开发,还可以试下facebook出的ATC.

3.5.2弱网优化

借助上述工具模拟弱网,在弱网情况下身验我们的App.通常来说,网路延后在60ms内,是OK的,超过200ms就比较糟糕了.我们须要做的是在比较糟糕的网路环境下就能给用户较好的体验.

弱网优化,本质上是在弱网的情况下能让用户流畅的使用我们的App.我们要做的就是结合上述的优化项:

结语

网路优化,是App优化中相当重要的一项优化.不仅顾客端,插口的优化外,好多一部份优化还依赖于服务器端,包括服务器端的代码开发,布署方法等.跟你的服务器开发/运维工程师一起说说这个话题吧:)

理论上这个应当是App优化系列的最后一篇,惯例得做些总结啊.并且如上面显存优化所言,显存优化的相关东西将单拎下来,并且还是会作为本系列的延续.到时再总结吧.

Android开发技术交流QQ群：150923287，本群可免费获取Flutter、Gradle、RxJava、小程序、Hybrid、移动构架、NDK等技术教程！