android app性能优化_百度地图 APP 网络性能优化实践

最新推荐文章于 2022-01-13 11:08:15 发布

weixin_39638188

最新推荐文章于 2022-01-13 11:08:15 发布

阅读量303

点赞数

文章标签： android app性能优化 vue2.0 唤起百度地图app 百度地图ip地址

点击上方“开发者技术前线”，选择“星标”

13：21 在看真爱

作者：obom | 责编 :可可

来源：百度地图技术团队

随着移动互联网的普及,无线网络的性能优化一直是手机产品 APP 性能优化的重要课题之一,面对移动无线网络的复杂环境,在 APP 开发时面临比传统 PC 互联网更具挑战性的网络性能问题。百度地图手机端引擎团队联合运维团队、CDN 团队,在APP 网络性能优化方面总结了一些实践经验,并取得了一定的成果。

一

百度手机地图网络整体框图

端:区分 Native 端与 Hybrid 端两部分。

端网络:系统自带的 RESTful HTTP 与自有的 HTTP。自有的 HTTP 是基于 TCP、UDP 实现的,可以自由切换。其中TCP 又包含长连接、短连接两条通道可供选择。NA 可以直接使用自有的 HTTP,Hybrid 的请求中也部分会走自有的 HTTP 以提高请求效率。

Server 端:针对TCP 长连接与 UDP 通信分别部署对应的 Server,PHPUI 作为业务服务的转接、适配层与客户端直接对接。

二

无线网络常见问题

2.1 DNS

Ø 失败率高、解析慢:主流的手机系统 Android、iPhone 都是基于 linux 内核进行开发的,传统的local DNS解析接口gethostbyname()为系统进程同步,再加上运营商 DNS 基本是由第三方公司整体集成发布提供服务,解析递归时存在不稳定等原因,造成无线网络产品在网络请求时 DNS 出错的占比是最大的。

Ø 劫持:网络链路上的路由、网管、运营商等提供的DNS 缓存存在被非法修改的风险,比如明明请求的是 A,结果返回的却是 B,就有可能是你的域名被劫持了。比如Apple内部DNS问题导致APP Store, iTunes Connect 帐号无法登录;百度地图去年在重庆、广州也遇到过 DNS 劫持的问题。

2.2 网络劫持

Ø 断点续传劫持:此类问题在酒店、餐馆等开放场所比较容易遇到,无线网络提供方主要基于视频或大文件下载占用带宽过高,造成其他用户网络慢,不通等问题在路由进行的相关过滤策略。

Ø 固定域名劫持:出口路由或者运营商LAC 层面,会对本区域内域名访问进行统计, 如果发现异常或者请求频繁、数据量过大,会对该域名进行强制

拦截。

Ø 端口拦截: 例如网络运营会对非80,8080,443 等的端口进行封禁。

Ø 运营商Cache策略诱发的劫持:运营上的初衷是增加 Cache,提升访问效率,并调整其内部机器资源、带宽占用, 但不同产品、不同业务对数据试试性要求不同, 运营商的 Cache 机制,会将旧数据返回客户端,而不是业务服务真正的数据。

2.3 网络不稳定

Ø 运动状态,移动网络基站切换造成网络的抖动;

Ø 基站小区用户拥塞;

Ø 信号差; 网络不稳定是无线网络的特性之一,上面列举出来的三种情况, 运营商会有专门的网优团队进行优化,我们应用方要关注的点就是如何处理我们的业务,能够最大程度的规避、快速反应来处理该类问题。

2.4 数据传输量过大无线网络带宽是固定的,数据量传输越大,传输时间越长,用户体验就越差。这就要求为了追求极致的用户体验,把业务数据内容跟体积做到最优化。

2.5 跨机房访问

三

无线网络优化实践

3.1 HTTP-DNS与并行DNS解析

很多网络开源库中都是采用 gethostbyname()接口来进行 DNS 解析工作,但该接口在 linux 内核中是系统级进程同步的,可以采用 getaddrinfo()接口进行替换实现并发,一个 APP 中肯定会使用到多个域名、即可以通过该接口来实现 DNS 解析工作的并发请求。

HTTP-DNS 技术,是基于自建的DNS 解析服务,通过 HTTP 请求,及时获取用户当前的最优 IP 节点,保证用户访问的最佳网络链路,减少不必要的数据传输通道延迟。并且自建的DNS解析服务更能够有效的杜绝Local DNS链路上面各层劫持的问题,保证用户使用的IP地址为正确的业务服务。下图是HTTP-DNS 的原理实现。

3.2 自定义基于 TCP 连接的 HTTP

系统集成的RESTful HTTP , 如 DefaultHttpClient ( Android ), NSURLConnection(iOS)对 HTTP 请求进行了整体封装,请求的各个环节不受控制,仅能提供一定的超时设置,而基于 TCP 的自有 HTTP 实现,可以从DNS 解析、建链、数据读写等各环节灵活控制,各步骤的超时、重试机制, 包括不同网络(2g、3g、4g、wifi),用户所处网络环境等特征进行动态设置, 保证用户请求的最大成功率。

Ø 自建内存DNS-IP池,节省HTTP请求的DNS解析时间,提高访问效率, 通过两种方式1、local DNS方式获取;2、HTTP-DNS方式获取,通过定时拉取更新,用户操作触发异步更新,并采用权值计算方式保证 HTTP 请求使用 IP 的正确性。

Ø 自动检测当前网络环境下断点续传可用性,当遇到端点续传不可用网络时,自动切换为非断点续传请求。

Ø 根据系统底层反馈的网络错误或者网络超时问题,分别进行不同的处理, 比如如果发现是连接错误,则立即重联、如果为连接超时,则会等待几秒再次进行重试。

Ø 基于TCP的长连接实现,减少握手时间,提升访问性能。

3.3 自定义基于UDP连接的 HTTPUDP 相较 TCP 会减少握手时间,减少网络耗时,这是基于 UDP 进行 HTTP 封装的初衷,从我们自己的性能测试来看,基于 UDP 的传输性能会提升 30% 左右。当然因为 UDP 不是基于可靠连接的,所以我们会在 UDP 协议基础上面包装一层协议,来保证协议的可靠、稳定。因此我们推出了一套LIGHT 协议来实现,可以认为是类似 QUIC 来实现。因为是在传输层,因此对实现数据包的自由切分,传输策略等相较 TCP,会有更加灵活的控制和策略。而且在服务部署中,接入 CDN,保证用户采用 UDP 进行传输时,共享 CDN 加速效果。

3.4 数据协议格式

通过采用自定义数据格式,压缩数据体积,主要采用的技术手段有三种:

1、通用的gzip 压缩;

2、基于nanopb 自定义的数据格式;

3、根据业务进行针对性数据压缩;

以 TCP 为例,TCP 数据传输会有一个自加速的过程,在基站部署中,运营商的资源调度也会对已有链接进行数据传输速度的动态调整,因此在数据格式设计中,不仅仅要考虑体积的压缩,还要结合业务本身的逻辑,综合考虑来确定最终的协议。

3.5 域名统一

采用统一的服务入口,一方面能够提高链路的复用率,减少 DNS、建链的耗时,另一方面,数据协议压缩,对端产品的适配都可以统一处理,具体业务服务可以仅考虑业务功能逻辑实现,减少其他因素干扰。

3.6 服务部署根据不同运营商、分机房部署;

服务双活、三活甚至更多,保证服务的持续可用; CDN 部署,减少链路路径;

四

网络技术前沿方向