摘要：因业务需求，上次开发的H5生鲜代码需要内嵌到某APP中。在定位这个问题上，跟APP端达成共识。用户在进入APP内嵌的H5页面后，H5会通过调用bridge.callHandler('jsInNative')来获取APP经纬度数据，然后H5端调用高德的API进行逆地理编码并显示解析后的地址。本地调试正常，远在上海的老大的手机上却出现了异常，于是我采取了通过记录日志到数据库的方法进行了原因排查，最终发现原来是高德API返回的city为[]......

标题有点儿长且不好懂，是啥意思呢？是这么回事儿。

一、背景

前段时间我通过uni-app开发了一个生鲜类的微信小程序，由于原业务包括微信公众号，所以我就打包了一个H5的版本放到了公众号中。再后来由于公司业务扩展，H5页面要内嵌到某APP中。在某APP首页中留了一个小入口，进入后就是H5端页面。这样做的唯一好处就是：减轻前端的工作量，不需要再针对APP重新开发一套代码。由于H5端有定位功能，经讨论后决定：在APP中，定位功能由APP端提供经纬度给前端，前端拿到经纬度后再用高德地图的相关接口进行逆地理编码。这样一来，前端的工作量稍微加大了一些，但好在改动并不多。

二、APP端与H5端进行定位通信

刚刚说了事情的背景，下面我只重点说下前端关于定位这块儿的处理。

感谢@康贺提供了一份H5端与APP端通过JSbridge进行通信的demo，在此基础上，我想要向后端获取数据时直接执行下面1行代码就行了。
bridge.callHandler('jsInNative', data, (res) => {})
APP那边在接收到我的请求后会返回给我数据，然后我就获取到了返回的结果，即res。

在之前的文章《uni-app跨端开发微信小程序之打包成H5后加载缓慢、定位不准到底是怎么回事？》中有提到过H5端定位不准的一些因素。在APP中同样也会存在授权权限问题，最后我跟APP端达成共识：返回结果中的code为10001时为未开启定位权限，为10000时表示已经开启，此时会返回经纬度，但不一定会成功返回经纬度，有可能返回的是空的。所以对我来说，即使code === '10000'时，我也要先判断下latitude的值是否为空，若不为空我才进行地图逆地理编码；若为空则使用默认地址。

调试好久后，本地测试一切正常。公司同事也进行了测试，全都没毛病。然而，定位功能在远在上海的老大那里却异常了！

三、上传日志，分析问题

老大给我们发来了截图和视频，然后依次排除了旧APP包、缓存、未开定位的情况。附一张当时的问题照，如图：首页左上角定位处疑似乱码.png

这可咋搞呢？老大人在上海，我们在杭州。要是手机在身边还能进行调试，隔这么远，沟通都存在时间差。后来，我想了一个方法：让后端老哥@邱浩写了一个接口，对定位数据进行存储，然后我查看数据库数据来分析原因。

老哥三下五除二就把接口写完了并扔给我了，然后我把APP端返回后的数据及高德逆地理编码的数据都进行了上报，同时也把用户id进行了上报，主要是为了对应是哪个用户的数据。本地测试可以成功上报后，我清空了数据库，然后让远在上海那边的老大进行了重新定位。

片刻后我刷新数据库，发现多了2条记录。点进去一看，真相出来了！name:[]！如图：上报的日志显示：APP端成功返回经纬度但高德逆解析后出现异常.png

什么情况？怎么返回个[]，再来对比下老大的截图，这不就正确了嘛！可问题是：APP端明明返回了经纬度，高德咋就异常了呢？我带着疑问直接在浏览器中粘贴了高德逆地理编码的地址并填写了APP中返回的经纬度和自己的key后意外发现city竟然为空！！！如图：高德地图API逆解析后city确实为空.png而我代码中name的值就取的是接口返回的city，所以......

四、优化代码，吸取教训

既然问题已经找到了，那就对代码多加一些判断就行了。还有一些变通方案，比如：街道township、区district、市city、楼信息building、社区neighborhood、街道formatted_address。有关高德逆地理编码的更多资料，详情访问官方文档→→→逆地理编码

最后，让我意想不到的是：city竟然会为空而且返回的值竟然是个空数组！有值时返回的是字符串！这操作......

转载声明：
　　若亲想转载本文到其它平台，请务必保留本文出处！
本文链接：/xwzj/2020-10-24/uni-app-online-tuning-bug.html

若亲不想直保留地址，含蓄保留也行。艺灵不想再看到有人拿我的技术文章到他的地盘或者是其它平台做教(装)程(B)而不留下我的痕迹。文章你可以随便转载，随便修改，但请尊重艺灵的劳动成果！谢谢理解。