#项目背景

由于目前跑男端未实现内置导航,所以跑男还是依赖于跳转到外部地图软件(百度,高德)来进行导航针对后台查看订单轨迹时,经常会出现坐标点丢失,无法确定部分路段的真实移动轨迹。如下图:

以上仅仅只采集到了刚开始出发时,以及到达终点时的几个坐标点,虽然我们显示了从起点到终点的路径,但是如果跑男不是按照这个线路去移动的话,我们也是无法感知的。跑男端没有即时上传坐标,无法准确的给跑男推送所在位置的附近订单

以上问题最直接的原因就是跑男切换使用外置导航时,跑男端app处理应用后台,这个时候app的正常运行将会受到系统一系列的限制,通过在各大主流手机系统上的测试,得出如下结论

  1. Android 将处于后台的应用进程的优先级限制为较低级别,以便让前台运行的应用进程获得更多的系统资源
  2. 后台位置更新限制:当应用程序处于后台状态时,Android 会限制应用程序的位置更新,以减少位置服务的开销和电池消耗。
  3. 后台网络访问限制:Android 限制了应用程序在后台状态下进行网络访问的频率和数据传输速率,以减少网络资源的开销和电池消耗。
  4. 后台服务限制:Android 限制了应用程序在后台状态下运行的服务的数量和运行时间,以减少电池消耗。
  5. 后台广播限制:Android 限制了应用程序在后台状态下发送的广播的数量和频率,以减少电池消耗。

所以当跑男使用外置导航软件进行导航时,我方app就要处于应用后台,这个时候,手机系统会根据当前的内存使用情况,会限制我们app的活动,这个时候推送可能会断开连接,网络可能收到限制,后台服务也会被限制,甚至app会处于一种假死状态,位置上传等功能都无法进行,当订单距离越远,使用外置导航软件的时间就更长,我方app的优先级就会变得更低,手机系统对app的限制就会更加严格。

#技术方案实现

由于跑男端未内置导航所有跑男不得不选择使用外部导航,那我们就解决这个问题,在app内部集成一个内置导航并验证该方案的可行性以及是否能解决如上痛点

集成百度地图导航SDK

关键步骤如下:

  1. 权限声明

2、授权key配置

申请到百度开放平台应用Key后,为了能够百度导航SDK正常运行,将其配置在AndroidManifest.xml的application节点内部,如下所示:

3、导航SDK核心集成

implementation ‘com.baidu.lbsyun:BaiduMapSDK_Map-BWNavi:7.5.4’

api ‘com.baidu.lbsyun:BaiduMapSDK_Map:7.5.4’ api ‘com.baidu.lbsyun:BaiduMapSDK_Search:7.5.4’ api ‘com.baidu.lbsyun:BaiduMapSDK_Util:7.5.4’ api ‘com.baidu.lbsyun:BaiduMapSDK_Location_All:9.3.7’

4、初始化地图sdk

5、导航时调用

#升级技术方案

以上基本可以实现内置导航,但针对我们app的实际运行环境以及其他现实问题,又对该技术方案进一步的做优化调整

  1. 将导航相关代码独立成公共库baiduMapNav,这样做的好处是方便代码复用,以后其他端或者其他业务需要可以直接拿来使用,快速实现内置导航功能
  2. 将内置导航功能独立成一个单独的进程,与主进程实现场景和代码隔离

这样做最大的好处就是导航功能崩溃不影响我们app的正常运行。基于之前的开发经验,即使是大厂的代码,也是会有一些bug。

  1. 多窗口实现

这样做可以实现类似于微信小程序那种,导航界面和app其他界面两个窗口,类似于两个app之间自由切换,数据和交互互不影响,提升跑男的使用体验,以及app的稳定性,

效果如下:

  1. 健壮性处理,如果app中途被回收或者其他异常导致导航界面重建,通过如下处理可以使导航回到上次的数据状态

#成果展示和分析

  1. 通过生产环境测试,实际使用情况,整个订单的路径跟踪如下

从上图可以看出,跑男的坐标点是连续不中断,从起点到终点,每一段路程都能很清晰的采集到跑男的真实移动轨迹,这样能提高平台风控能力,更好的掌握跑男的配送情况。

2、可以自定义导航界面元素,可以根据我们业务自身的需求,在导航界面添加自己的元素,比如节日期间的节日元素等等,比如播报的文本控制等等

3、对比同类型其他友商产品,比如某团,达达,闪送,顺丰等,都未实现此功能,可以使我们的app专业性更强,更有辨识度,区别于同类型别家产品,功能性更强。

4、安装包体积,若按照百度给的方案去集成实现,此时安装包与之前的体积如下图:

左侧是之前的apk体积,右侧是集成过之后的体积,可以发现,体积几乎增加了60%,这个代价还是很大的,于是着手分析去优化体积,经过一系列的技术手段处理,保证核心功能实现的前提下将体积进行精简优化,最终使得apk体积达到了一个理想水平。如下图:

对比可以发现体积仅仅增加了4M,体积仅仅增大4%,对于之前可谓是天壤之别,这样对于我们整体app的品质提升是相当巨大的。

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注