原创 2017-02-28

关键点：

• 共享单车体验
• 摩拜单车技术实现的思考
• ofo单车技术实现的思考
• Locman现阶段技术实现分析
• 对于Locman后期实现的一点小思考

自2015年Uber、Airbnb火热起来之后给O2O创业带了一个新的名词 共享经济（所谓的共享经济模式就是通过一个平台化的互联网工具，把社会上具有相同属性的闲散资源整合到一起，以更加高效的方式满足市场的供给），在国内就出现了一大批如滴滴、易到用车、神州专车等基于共享模式号称解决人们打车难的平台出现，统治了打车这个行业，但在人们“最后一公里”出行方面还是面临了难题。世界就是这么奇妙，哪里有需求哪里就会有解决方案，在2016年中相继出现了摩拜单车、ofo单车、小蓝单车等方便出行的“原始交通工具”，在一开始出来之后，作为屌丝的我为了不给 299、99 元的押金，并没有想过会使用它们，然而一次出行让我不得不使用上它，后来竟然喜欢上了。下面就来说说我使用到的共享单车以及体验感受：

摩拜单车

第一次使用上宣称 触手可骑 的摩拜单车是在2017年2月6日，由于出行需要开通并使用了摩拜单车。

• 找车：摩拜App感觉是比较轻量级的实现，仅包含了我地图找车、开锁、投诉等几个主要功能模块，找车直观简洁，在这次骑行选择上我用了mobike lite，通过地图上显示的车位置，很快找到了。
• 用车： 扫码->开锁->go 短短几秒钟就完成了开锁功能，这体验感觉比较方便快捷，满足了人们习惯上使用的扫码功能，也增加了蓝牙开锁功能。
• 骑行：摩拜单车第一代骑行很笨重，这有可能与其使用了实心胎、单臂前轴、大功率电机有关。相较于传统自行车体验很是不好，在第二代上摩拜单车做出了改进，使用了与传统自行车基本一样的设计，在重量上来说已经减轻很多，但是相较于ofo单车还是比较笨重。
• 结束行程：摩拜在还车计费上做到了也比较智能， 只需要将锁开关关闭即可完成还车计费，比较方便，不需要用户手动操作App结束计费。

ofo单车

第一次使用ofo单车是在2017年2月10日，骑行了摩拜单车后感觉坐垫不能调节，骑行比较费力，当时也没有在周边找到摩拜单车，就开通了宣称 随时随地有车骑(ANYTIME ANYWHERE) 骑行体验比较好的ofo单车。

• 找车：下载ofo单车App后，说实话在找车方面相较于摩拜做的实在太不智能，从App上只能了解到周边有多少辆车，并没有一个很直观的标注告知车的位置，给找车上带了了一定的困难，但是ofo单车的数量也还多，也能够比较快速的找到车。
• 用车：与摩拜类似，在App上有一个扫码开锁的功能，但是还提供了一个用户直接输入车牌号开锁的入口（这对于骑行者手机摄像头不行或者二维码损坏是一个比较好的解决策略）。由于ofo使用的是机械锁，所以在开锁方面并没有给我带来所谓科技感，开锁也不是很方便，需要用户手动调节密码，按下弹簧开关才能够开锁。
• 骑行：骑行体验上感觉与传统自行车相差无几，但是感觉更加轻便，更不必提与摩拜笨重的车体，加上可充气轮胎与可调节高度的坐垫使骑行更加舒适，这也是我一直比较喜欢使用小黄车的原因。
• 结束行程：在还车体验上也是并没有互联网带来的便捷感，需要用户手动关闭锁之后，打乱密码，在还车之后还需手动在App上点击结束行程才能停止计费。这里也存在一个比较大的漏洞就是用户可以先结束行程或者记住该辆车的密码长期使用，这也是ofo单车在小区单元楼下、地下车库经常见到的原因。

以上就是我在使用了共享单车的一些直观感受，但是作为一个Coder我比较关注的是摩拜单车整个用车流程的体验，以下就是我参考网络大牛，以及自己的一些感受揣测的摩拜单车开锁、关锁的技术实现（因为与现在的工作遇到的问题以及解决办法相似），如果有不合理的地方欢迎指正，联系我的邮箱。

摩拜单车的开锁、关锁技术实现思考

作为一个Coder，在现阶段项目中遇到很多问题，发现与摩拜单车实现技术类似，但是未做到与摩拜单车一样的体验。在体验了摩拜单车以及参考了各位网络大神对于摩拜单车通信的讲解，也有一点自己的体会，现只对摩拜通信记录如下（关于硬件方面如何设计及工作此处省略1000......字）：

摩拜单车通信示意图

摩拜整个通信中，有三个比较关键节点：

• [x] 自行车：最重要的设备
• [x] 手机终端：也可以叫做我们的一个用户
• [x] 服务器：处理相关信息

上述图示，可以看出，这三者之间存在两两相互通信：单车与手机终端、手机终端与服务器、单车与服务器，再这三者之间相互通信，技术最为难实现也最重要的一环是单车与服务器之间的通信。

• 单车与服务器通信
     从网络各位大神分享的技术博客综合（因为硬件方面不是太懂，网上有大神对摩拜的车锁进行了一个拆解），单车与服务器之间的通信方式存在两种方式：一种是使用SIM卡通过短信方式向单车发送开锁/关锁命令，这种是不需要TCP/IP建立一个长连接的，这种方式存在一个弊端就是发送短信的寻址需要一个比较长的时间，所以在摩拜单车的第一代部分单车开锁就存在一个延迟较大、不稳定的一个情况；第二种就是通过TCP/IP创建长连接，在这里猜想使用长连接的方式主要是用在单车像服务器发送定位信息使用，毕竟摩拜是在其单车中提供了发电装置，而且在我使用单车的过程中关闭了手机终端的网络，同样是在结束行程之后查看我的行程轨迹。

• 单车与手机终端通信
     在第一阶段，摩拜采用的是手机扫描二维码的方式读取单车信息，这是一个手机主动读取数据的过程，在此过程中应该是不存在手机与单车的通信机制的；摩拜后期新增了蓝牙开锁（也是摩拜比较推崇的一个开锁方式），毕竟低功耗蓝牙4.0在技术上已经很成熟，价格低廉，特别是耗电量低等诸多有点。本人猜测可能出于省电考虑，使用蓝牙之后单车无需实时在线（所有命令可以通过手机端链接服务器，接收并取得命令激活单车 这里只是一种猜测,但是具有可行性），在蓝牙开启的情况下摩拜App会主动尝试连接单车蓝牙，链接成功后通过蓝牙指令读取单车信息，然后通过App的网络传输指定单车信息至服务器请求开锁。在此过程后，摩拜可以通过两种方式向单车发送开锁指令：第一种是与扫描二维码方式一样，通过服务器端直接发送开锁指令到单车；另一种是将开锁指令下发给手机端，然后手机端通过蓝牙发送指令开锁并将单车从睡眠状态激活（我觉得应该是采用的此种方式，不然摩拜也没有必要再做一个蓝牙开锁）。

• 手机终端与服务器端通信
     在这里就比较简单了，与我们常见App服务器交换数据类似。在行程开始前App获取单车信息直接上传服务器请求开锁，服务器下发开锁指令（不管是二维码方式下发到单车，还是蓝牙方式下发至App然后通过App发送开锁指令），得到单车锁已开回执后开始计费；行程结束后，服务器收到了单车的关锁信息，结束计费并向手机下发结束计费指令。

摩拜整个通信流程

• 二维码方式开锁猜想

  二维码开锁方式

• 蓝牙开锁方式猜想
     关于摩拜单车蓝牙开锁，在这里个人觉得有两种方式：一种是与二维码相同直接向服务器请求开锁指令后，通过服务器发送指令到单车开锁；另一种是请求成功后指令直接发送到用户手机端，此时在通过手机与单车的蓝牙发送指令开锁，个人比较倾向于第二种（不然摩拜在后阶段也不会大力推行蓝牙开锁方式，有可能还存在更多好处，暂时未分析出来），此种方式可以减少服务器与单车链接的不确定性，增加开锁成功几率，同时通过蓝牙开启成功后，单车的锁已开状态信息可以又通过手机直接上传至服务器并同时开启计费。
  

  蓝牙开锁-方式1
  蓝牙开锁-方式2

ofo单车开锁、关锁技术实现

相较于摩拜单车，ofo在实现开锁、关锁功能上，并没有用到任何复杂的技术，虽然也存在单车、手机终端、服务器这三个关键节点。从下图图示可以看出，ofo单车也存在单车与手机终端、手机终端与服务器之间通信，只比摩拜少了一个单车与服务器端的通信。在ofo中单车与手机终端通信也可以弱化，虽然存在扫码开锁，其实单车与手机终端是没有任何实质通信。

ofo单车通信模型

• 手机终端与服务器之间的通信
     ofo在与服务通信过程中，其实主要也只有三个比较重要的请求：一个是向服务器请求开锁密码，请求成功后一段时间开始计费，与摩拜单车请求成功后单车回执锁已开命令存在实质性差别；一个是请求关锁然后结束行程；另一个就是向服务器上传已经记录的GPS定位轨迹数据（这里也是ofo在开始骑行前为什么需要开启GPS定位功能）。这与其他所有手机终端与服务器Request-Response并无差异，在技术上也很简单。

现阶段Locman技术实现分析

前后已经开发过两个版本的Locman软件(存在N多个定制版本，应该在后续考虑引入模块化组件化开发）：一个是Locman2.0，另一个是现阶段的哑资源管理平台；对于这两个版本不作软件硬件实现以及工作流程不做任何评价，这里我只是谈一谈我在做了这两个版本之后的整个开锁关锁流程 （仅代表个人理解）。
   现阶段Locman与摩拜单车实现流程非常类似也是存在三个非常重要的节点+人工操作：

• [x] 硬件设备：人井，光交等（自研硬件）
• [x] 手机终端：移动管理软件
• [x] 服务器：C/S、平台系统

Locman通信模型

从上图可以看出，Locman平台开锁、关锁通信方式与摩拜基本是一致的，也是存在：硬件设备与服务器、硬件设备与手机终端、手机终端与服务器之间的两两通信，但是在实现上存在许多不同（与业务场景相关），比较重要的一点是我们的硬件设备必须手动激活，加入了应急开锁功能。

• 硬件设备与服务器通信
     当硬件设备手动激活后，在手机终端发送远程开启请求指令，服务器会通过两种方式：一种是SIM卡发送短信远程开锁指令；另一种是通过GPRS发送。同理设备上报状态信息也采用以上两种方式。

• 硬件设备与手机终端通信
     这种通信现阶段仅存在于光交设备。当设备人工激活后，通过手机App连接设备，连接成功之后读取设备信息并请求开锁指令，通过蓝牙向设备发送开锁指令开锁。

• 手机终端与服务器通信
     手机终端与服务器通信方式比较简单：一个是服务器通过推送方式提示手机用户告警信息；另一个是当设备手动激活后，需要通过工单中已知的设备信息（这里手机终端并未与设备通信）向服务器请求远程开启指令。服务器并没有向手机终端返回确实已开启设备的信息（因为是现场作业，而且无需其他附加操作：例如摩拜单车的计费功能，可以通过设备锁人工判定）。

Locman开锁流程

蓝牙开锁方式

远程开锁方式

为什么现阶段我们开锁存在人工操作

• 省电
• 省电
• 省电

这里与摩拜存在很大的区别，由于我们的设备是需要长时间保持电量（无充电来源），所以我们的设备并没有通过TCP/IP与服务器端保持长连接，并且设备在使用后会自动进入关机状态，如果在无人工参与时设备只会固定一个周期上报状态信息。

对体验共享单车后Locman后期的一点思考

以下问题只是个人的一些思考，如存在不合理或者不全面欢迎指正，请联系我的公司邮箱，谢谢！

• Locman可以不使用激活钥匙激活设备吗？
     现在蓝牙4.0技术发展已经很成熟，相较于以前老的蓝牙2.0在功耗上大大降低，从现在使用的蓝牙鼠标来看，两节5号电池雷柏蓝牙鼠标可以使用大约3个半个月（亲身体验），如果是4节1号电池应该使用周期会更长（这个有待技术后期验证）。以上的说法在技术上来说相当不严谨，这里我从网上找到了关于蓝牙4.0相关功耗文章：
  蓝牙4.0低功耗技术及其认证要求，提到可以使一枚纽扣电池工作长达数年；
  nRF8001纽扣电池续航的超低功耗蓝牙4.0技术，讯通科技电子技术公司；
  更多关于蓝牙4.0功耗问题，请进入百度文库 搜索 蓝牙4.0功耗

  通过上述了解后，如果我们设备使用蓝牙可以直接保持蓝牙在线，并且可以被搜索到（至于如何与我们自己的App安全配对问题，需要硬件与软件共同解决），当施工人员靠近设备即可直接连接上蓝牙，此时有两种方式开锁以及上报设备状态信息：

  • App通过蓝牙近距发送激活命令，设备接收到激活命令之后按照以前手动插入激活钥匙相同，激活设备；等待设备激活后，发送远程控制开锁命令开锁，并上报状态信息。相较于之前只是去除了人工手动激活，也并没有解决掉开锁延时、开锁成功率不高的问题；
  • App通过蓝牙近距离发送激活命令获取到设备信息，通过App网络请求服务器远程控制权限命令后通过蓝牙直接开锁，并且可以同App直接上报设备状态。快速方便、开锁成功率高。

• Locman可以使用二维码扫描开锁吗？

在现阶段设备开锁情况只需要读取到我们的设备信息并且具有开锁权限的用户都可以开锁。权限已由服务器自动判断，现在主要的就是设备信息问题，我们可以通过在设备上加入具有设备信息的二维码标签即可。后续的开锁流程：一种是就可直接参照现阶段远程开锁流程操作；另一种是结合上一个问题已讨论的蓝牙进行开锁。

• Locman可以增加离线开锁功能吗？

关于Locman离线开锁功能，在完成2.0版本之后就有了这个想法。在外施工的工作人员会遇到网络信号不好，这种情况应该是比较常见的，这不仅仅是只包含我们手机终端设备信号，也包括我们硬件设备在很多时候请求了远程开锁并不能够成功的开启。
   在现阶段实现流程中加入离线开锁功能是不现实的，首先我们设备是需要手动激活，然后通过服务器发送开锁命令才能够完成开锁流程。但是如果结合上述 Locman可以不使用激活钥匙激活设备吗？
能够新增蓝牙开锁。大致流程如下：
   施工人员在处于有网络状态下，下载离线设备数据，并且根据用户权限获取开锁命令（命令可以是：根据用户权限生成的一次性命令、永久命令），在用户处于网络不好的情况，通过蓝牙连接发送获取设备信息并且得到信息与离线存储口令进行匹配，匹配成功后再通过蓝牙直接发送开锁命令直接开启设备。

• Locman可以增加预约功能吗？

我觉得答案是肯定的，参照 Locman可以增加离线开锁功能吗？ 用户可以直接选择预先下载对应设备的开锁命令（这里的命令与离线命令需要区分开来）进行预约，在用户预约之后冻结该设备（冻结时长或者其他参考因素）为其他人操作。后续操作方式与上述 Locman可以增加离线开锁功能吗？ 相同。

• 关于以上问题思考后Locman开/关设备实现流程图
     整个流程主要是结合上述提出的几个问题进行一个简单得梳理，在现阶段正在使用的流程中加入/新增了：
  • 手动激活改为蓝牙自动激活；
  • 预约流程；
  • 读取设备信息从离线数据、蓝牙读取、二维码扫描；
  • 设备上传信息修改为手机App与设备可以同时上传。
    
    Locman流程优化

最后这些想法是否合理还有待验证，在这里感谢我的同事邓xx（就不写全名了）对我在Locman整个开锁流程上的梳理与帮助。