移动端开发网络优化建议

一个网络请求可以简单分为连接服务器 -> 获取数据两个部分。
其中连接服务器前还包括 DNS 解析的过程;获取数据后可能会对数据进行缓存。

一、连接服务器优化策略

1. 不用域名,用 IP 直连
省去 DNS 解析过程,DNS 全名 Domain Name System,解析意指根据域名得到其对应的 IP 地址。
如 www.codekk.com 的域名解析结果就是 104.236.147.76。

首次域名解析一般需要几百毫秒,可通过直接向 IP 而非域名请求,节省掉这部分时间,同时可以预防域名劫持等带来的风险。

当然为了安全和扩展考虑,这个 IP 可能是一个动态更新的 IP 列表,并在 IP 不可用情况下通过域名访问。

2. 服务器合理部署
服务器多运营商多地部署,一般至少含三大运营商、南中北三地部署。

配合上面说到的动态 IP 列表,支持优先级,每次根据地域、网络类型等选择最优的服务器 IP 进行连接。

对于服务器端还可以调优服务器的 TCP 拥塞窗口大小、重传超时时间(RTO)、最大传输单元(MTU)等。

二、获取数据优化策略

1. 连接复用
节省连接建立时间,如开启 keep-alive。

对于 Android 来说默认情况下 HttpURLConnection 和 HttpClient 都开启了 keep-alive。只是 2.2 之前 HttpURLConnection 存在影响连接池的 Bug,具体可见:Android HttpURLConnection 及 HttpClient 选择

2. 请求合并
即将多个请求合并为一个进行请求,比较常见的就是网页中的 CSS Image Sprites。
如果某个页面内请求过多,也可以考虑做一定的请求合并。

3. 减小请求数据大小
(1) 对于 POST 请求,Body 可以做 Gzip 压缩,如日志。

(2) 对请求头进行压缩
这个 Http 1.1 不支持,SPDY 及 Http 2.0 支持。
Http 1.1 可以通过服务端对前一个请求的请求头进行缓存,后面相同请求头用 md5 之类的 id 来表示即可。

4. CDN 缓存静态资源
缓存常见的图片、JS、CSS 等静态资源。

5. 减小返回数据大小
(1) 压缩
一般 API 数据使用 Gzip 压缩,下图是之前测试的 Gzip 压缩前后对比图。

(2) 精简数据格式
如 JSON 代替 XML,WebP 代替其他图片格式,回复 20 查看关于 WebP 的介绍。

(3) 对于不同的设备不同网络返回不同的内容
如不同分辨率图片大小。

(4) 增量更新
需要数据更新时,可考虑增量更新。如常见的服务端进行 bsdiff,客户端进行 bspatch。

(5) 大文件下载
支持断点续传,并缓存 Http Resonse 的 ETag 标识,下次请求时带上,从而确定是否数据改变过,未改变则直接返回 304。

6. 数据缓存
缓存获取到的数据,在一定的有效时间内再次请求可以直接从缓存读取数据。

关于 Http 缓存规则 Grumoon 在 Volley 源码解析最后杂谈中有详细介绍。

三、其他优化手段

这类优化方式在性能优化系列总篇中已经有过完整介绍
1. 预取
包括预连接、预取数据。

2. 分优先级、延迟部分请求
将不重要的请求延迟,这样既可以削峰减少并发、又可以和后面类似的请求做合并。

3. 多连接
对于较大文件,如大图片、文件下载可考虑多连接。
需要控制请求的最大并发量,毕竟移动端网络受限。

四、监控

优化需要通过数据对比才能看出效果,所以监控系统必不可少,通过前后端的数据监控确定调优效果。

时间: 2024-10-25 21:36:28

移动端开发网络优化建议的相关文章

移动端开发适配总结

移动端开发适配2种方案总结 针对移动端适配的方案~ 一: 第一种方案是:所有的单位使用rem来适配:首先在页面上设置html的font-size的大小:如下我项目中的设置: html { font-size: 100px; } @media(min-width: 320px) { html { font-size: 100px; } } @media(min-width: 360px) { html { font-size: 112.5px; } } @media(min-width: 400p

移动端开发流程

和PC端网站的设计和开发相比,移动客户端的开发工作,对绝大多数人来说,绝对是一个崭新的行当. 那么,当我们每天在iphone上,在各种安卓在各种pad上习以为常的刷着微博看着网文切着西瓜找着你妹的时候,当一大波人信心满怀的开始步入这个看似熟悉,或者说"简单"的工作中后,突然发现,悲催,完全不是那么回事嘛! 相信很大一部分产品或者设计或者开发人员是从之前的传统互联网"出家"过来的,当然,这包括我,还有身边很多很多人.总之,这是一个坑,因为,APP,这个"看上

29.html5 移动端开发总结

手机与浏览器 浏览器: 移动端开发主要针对手机,ipad等移动设备,随着地铁里的低头族越来越多,移动端开发在前端的开发任务中站的比重也越来越大.各种品牌及尺寸的手机也不尽相同.尺寸不同就算了分辨率,视网膜屏 自动的各种内核的浏览器,想想头都大了. 先说下浏览器.在中国有多少种浏览器? ie.百度.360.搜狗.火狐.欧朋.Chrome.谷歌.行者无疆.财猫省钱.遨游.Wise光速.UC.智慧.QQ.海豚...(大概有70-80多种) 五花八门,还好不用担心这都是表象.虽然浏览器各不相同但从浏览器

现代Java服务端开发核心技术之开发工具箱

现代Java服务端开发核心技术之开发工具箱 现代Java服务端开发核心技术 2.1 开发工具概述 俗话说,工欲善其事必先利其器,掌握一些日常开中常用的工具软件能够大大提开发效率,工具本身的目的也是解放生产力.在安装各种软件时注意如果没有特殊需要不必使用最新版本,尤其是操作系统,例如当前(2018/10/12)最新版的macOS是10.14,但是运行在macOS之上的其他应用软件可能还没有及时做兼容新系统的版本,可能在系统升级之后无法正常使用,因此推荐在新系统正式推出半年后再升级最为稳妥. 而且软

移动端开发适配的2中方案

原文地址:http://www.cnblogs.com/tugenhua0707/p/5568734.html 针对移动端适配的方案~ 一: 第一种方案是:所有的单位使用rem来适配:首先在页面上设置html的font-size的大小:如下我项目中的设置: html { font-size: 100px; } @media(min-width: 320px) { html { font-size: 100px; } } @media(min-width: 360px) { html { font

移动端开发的注意事项

PC端与移动端的区别 1.从兼容方面来说, PC考虑的是浏览器的兼容性,而移动端开发考虑的更多的是手机兼容性,因为目前不管是android手机还是ios手机, 一般浏览器使用的都是webkit内核. 2.在部分事件的处理上,移动端多出来的事件是触屏事件,而缺少的是hover事件. 另外包括移动端弹出的手机键盘的处理,这样的问题 在PC端都是遇不到的. 3.在布局上,移动端开发一般是要做到布局自适应的,我使用的一直是rem布局,感觉很好. 4.在动画处理上,PC端由于要考虑IE的兼容性,所以通常使

跨端开发小程序

在微信小程序中,每个页面都是由.js..wxss..wxmk和.json四个部分构成,代码结构比较复杂.另外,由于对ES6语法和sass等css预处理支持的不友好,导致开发效率很低,所以早早就有用vue.js来开发小程序的框架,比如webpy和mpvue,但是基本都是单纯的开发微信小程序. 可是,随着微信小程序.网页H5.头条小程序.百度小程序.支付宝小程序.快运用.原生APP的增多,每个都独立开发的话,每个前端估计都要吐血了,所以,就出现了跨端开发的框架.现在基本对多端支持足够好的,就是tar

开发人员建议阅读:Spring Boot 架构中的国际化支持实践

pring Boot 主要通过 Maven 或 Gradle 这样的构建系统以继承方式添加依赖,同时继承了 Spring 框架中的优秀元素,减少了 Spring MVC 架构中的复杂配置,内置 Tomcat,Jetty 容器,使用 Java application 运行程序,而不是传统地把 WAR 包置于 Tomcat 等容器中运行,从而简化加速开发流程.此外,Spring Boot 学习简单.轻量级.容易扩展.基于这些优秀的特点,Spring Boot 成为了蓬勃发展的快速应用开发领域的领导者

从架构师视角看是否该用Kotlin做服务端开发?

前言 自从Oracle收购Sun之后,对Java收费或加强控制的尝试从未间断,谷歌与Oracle围绕Java API的官司也跌宕起伏.虽然Oracle只是针对Oracle JDK8的升级收费,并释放了OpenJDK一直开源这份善意,但是如果没有各个大非Oracle的JVM.JDK和众多其它基于JVM的语言,Oracle这份善意能维持到什么时候可不好说. 大厂要从JVM和JDK的层面早做打算,而广大中小企业,就只能先从Java语言的层面,先找到Oracle以外的备胎.自从被谷歌钦定为Android