物联网(谨以此文,聊以慰风尘) | 项目复盘

718 阅读10分钟

一、项目背景

2018年年底的一个下午,西安的雾霾还是有一些严重,电脑前正专心写bug的我突然被叫到去一下会议室,还沉浸在编码世界的我没想太多随手拿起笔记本和笔就过去了。会议直奔主题,因为项目组接到一个新需求,需要使用全新的技术栈来实现一个物联网管理系统,包含硬件信息采集、硬件设备消息推送监听、GIS地图交互等功能,听到这第一反应:终于有新项目了,还有新技术栈,终于等到你,还好我没放弃,幸福来得好不容易……(音乐关了,我们继续)。

这里顺便介绍一下项目背景,之前公司的技术栈是 SpringMVC + jQuery + Bootstrap,技术上难度不高(但是业务确实要学习的有很多),当时也想在之前的项目中大展身手,比如给一个前后端不分离的老项目前端模块配置了node环境,当然仅用于本地eslint格式化检查修复。

二、技术选型

确定了要干,接下来几天就是确定技术方案。因为第一版只考虑实现web端,在 Vue 和 React 中选择了vue,主要原因是 vue 相对好上手,之后其他同事参与进来学习成本也相对较低;GIS地图选择了当时地图界的老大哥百度地图;后端技术栈似乎没有争议,妥妥的 SpringBoot;对了还有消息推送 websocket。

还没开始开发,有道云笔记的文档已经整理了好几篇了,什么框架选型对比、GIS相关开源库支持情况以及业务相关的todo list(story list)。

三、实践过程

1.穿越地理围栏播报

简单的说就是通过鼠标点击地图的不同区域,要在地图上绘制出一个多边形围栏(比如点击四下你可以绘制一个四边形围栏),当用户携带硬件(手表或其他硬件设备)穿越围栏,系统会自动推送一条数据,前端如果开启了websocket订阅就能接收到一条推送消息,接下来前端要根据推送内容调用百度的语音播报SDK将文字转化为临时语音文件,播放出来。

大概列一下这个需求索要包含的技术点

  • 通过坐标拾取绘制围栏区域以及围栏的增删改查
  • 实时定位监测(判断是否穿越围栏)
  • websocket发布订阅监听预警信息
  • 百度云sdk实现离线语音合成(FIFO消息管理)

以上技术点挑两个重点来说吧,首先是坐标拾取,点击时获取点击位置的经纬度坐标,点击多个点时在地图上绘制出多边形,这个操作使用了当时 GitHub 上 star 最多的开源库 bue-baidu-map ,(源码注释中发现这个开源库的作者也是百度的大佬)项目里面有大量的demo可供使用,包括位置点采集、多边形围栏绘制等功能,可惜支持的围栏只是简单地渲染,没法从一个点开始创建,当时借鉴了这个开源库的部分代码改造实现了该功能,成就满满。

再说下 websocket,也是第一次使用,刚接收到接口推送的消息感觉很开心,感觉又入门了一项技能,在之后经过不断打磨,解决了组件切换导致重复订阅、连接不稳定、心跳监测重连等等问题后,终于能够稳定的监听硬件推送的消息了~

2.轨迹动画绘制

因为地图上轨迹动画相关实现已经在开源库中找到了解决方案,本以为这个任务能轻松搞定,结果撞了满头的包。

在开启设备定位检测后,使用最大频率采集的数据发现定位一直不太准确,明明我在公司坐着,绘制的定位点却一直有偏差,而且每一次采集还会有细微的差别,根据采集的极坐标点集绘制的运动轨迹简直没法看。一顿搜索才发现,首先是坐标系统不一致,设备返回的坐标系是地理坐标系统 WGS84 ,而百度地图默认是投影坐标 BD09。这里顺便介绍下常见的三种地图坐标系统:

  • WGS84 :地理坐标系统,Google Earth 和中国之外的 Google Map 使用,另外,目前基本上所有定位空间位置的设备都使用这种坐标系统,例如手机的GPS系统。
  • GCJ-02:投影坐标系统,也就是我们平常所说的火星坐标系,Google Map 中国、高德和腾讯正在使用,是在 WGS84 基础上加密而成。
  • BD09:投影坐标系统,百度地图使用,在 GCJ-02 基础上二次加密而成。

解决了坐标系统不统一的问题,发现设备每次返回的坐标点还是不够精准,本来以为完全是硬件问题,后来发现手机定位也是一个概率值,每次定位返回的经纬度也都是不一样的。如果发现十次测量中有一次返回的坐标点偏差很大需要将这一点数据去除掉,也就是说拿到运动坐标点集首先需要去噪。其次需要有一个模糊半径,简单的说就是如果设置模糊半径为10米,设备三次定位返回的数据都在这个模糊半径范围内,那么我们就认为设备位置没有改变,实际坐标点根据算法取多次测量的均值,具体实现代码已被自动省略,如要查看请先点赞。

简单总结一下解决方案

  • 地图坐标系统转换(封装了一个js文件搞定)
  • 噪点剔除
  • 设定模糊半径优化设备静止判断

3.硬件对接

印象最深的是当时硬件接口返回参数有两个参数写反了,反馈给硬件厂商之后就再没什么消息了,我只好这边委曲求全按照错误的字段对接完成。一个多月之后,突然发现一个神奇的 bug,一顿 debugger 操作发现硬件厂商的开发把这个问题偷偷修复了😂。 不讲武德

4.还有吗?

就这?才三点?当然不是,刚才脑子里已经走马灯似的回想起好多个值得记录的点了,包括JTW实现OAuth2以及token自动续期、硬件设备数据上报延迟问题、消息推送播报FIFO优化、vue-router踩坑、使用免费的百度地图API请求限制问题优化……。前两天刚在GitHub上看了Eno Yao大佬的前端回忆录,如果哪天我也起笔开始写我的回忆录了,我可能会把这些细节写的更加详细吧。

四、后续

1.公司内部晋升成功

还记得当时晋升刚刚遭遇公司内部改革,需要准备一份PPT,5-6个领导在线欣赏你表演,之后还有答疑环节,我的主要宣讲内容就是物联网这个项目,自我感觉很不错,结果不用说也是顺利通过(后来才知道那次晋升通过率只有40%)。

2.三次技术分享

其中前两次都是项目组内,一次主讲技术,一次主讲业务,有问有答,自我感觉还不错。第三次是领导突然周末联系我让准备下,几天后做一场技术分享,据说可能会有几个其他团队的小伙伴来听,准备一次vue的入门技术分享就好。随后建了个群加上我一共是十几个人,发现大多数是我们们项目组的小伙伴,结果群里人越来越多,等到分享开始发现群里已经有了70多人了……

图片替换文本

开始有一点紧张,但是讲到技术方案也是逐渐进入状态,包括之后的答疑环节都算是比较流畅。对了,这是我当时分享出来的文档,当然剔除了业务部分,各位看官尽可放心。

3.CMMI5认证通过

不了解CMMI的小伙伴可以先通过百度百科给出的解释了解下。

CMMI 全称是Capability Maturity Model Integration,是能力成熟度集成模型,是由美国国防部与卡内基-梅隆大学和美国国防工业协会共同开发和研制的。CMMI是一套融合多学科的、可扩充的产品集合,其研制的初步动机是为了利用两个或多个单一学科的模型实现一个组织的集成化过程改进。 CMMI分为五个等级,二十五个过程区域(PA),最高为五级。

由于公司招标及业务扩展等方面的需求,刚好需要几个的项目去完成 CMMI5 的等级认证,为了这个认证我们项目组我和几位小伙伴专门去上海参加了全天候的培训,培训完毕还有专门的内部考试,当时相关的资料也是整理了不少,好在最终顺利验收通过,圆满收场。

五、总结反思

虽说这个项目我已经在一年前就交给其他小伙伴维护了,听说现在也支持了更多更先进的硬件设备,但现在想起来还是回忆满满,当时满怀激情的与同事探讨解决方案、为解决一个问题冥思苦想、遇到没接触过的问题感觉进行不下去开始怀疑自己等等情景还历历在目,那就简简单单做个总结吧:

1. 谨慎选择解决方案

选择一个方案不光要关心它的先进性,还要考虑项目实际是否需要、学习成本、社区活跃度、生态完善性等等方案,毕竟这和学习 demo 不一样。

2. code review 很重要

哪怕公司项目开发没有code review这个环节,也应该自己 review,适当优化。比如说封装、复用性的优化,想想当时做的就有所欠缺。

3. 统一规范:请使用 eslint + githooks

多人协作开发的项目要想规范统一,首先是要有一份规范吧。其次可以通过eslints保证基本的格式能够统一,要不然默认规则不一致,随手一个格式化然后直接提交真的很要命。至于 git hooks 其实就是在 git 提交之前触发 pre-commit 钩子,然后可以配合 eslint 检测或是 commit message 格式检查,不通过验证不允许提交。

4. 结果导向

之前经常遇到一个业务问题,相关开发产品到会议室就开始轮流发表意见,一下午过去头晕脑胀的从会议室出来却发现已经记不清楚太多细节。这种情况就需要一个人专门记录结果,最终发出来大家也能有一个明确的目标方案。

谨以此文,聊以慰风尘

本文正在参与「掘金 2021 春招闯关活动」, 点击查看 活动详情