五味杂陈，生活琐事，闲来思考作乐。
平时大家都见到过或者使用过共享电单车，偶尔一次看到别人扫码用车整个动作，突然就想到了很多。
首先能肯定的一点是，每辆车是固定的，所谓固定，就是它自身的唯一编号及二维码是恒定的，除非被损坏否则一直不变，保证任何人扫码都可成功。这种固定的二维码与平时我们电脑登录微信又是不一样的，电脑登录微信时，它所展示的二维码是变化的，这是比较独特的一种，可以想象一下，电脑打开、打开微信客户端它会展示一个二维码，这时不论用你的手机微信还是别人的手机微信扫描此码，都是能正常登录的，关于二维码暂先提到这里，下面继续。
第一个阶段：扫码使用
扫码后客户端后台获得了该车的车辆信息，能想到的比如具体位置信息（定位与导航传输，可能是锁车时的位置为准，也可能是以刷新当前位置为准）、当前状态如电量、是否登记有问题（是否可使用）、还能用多久、车辆自身标识信息（用于传递、后续的用量计算及扣费等），此时客户端界面会展示一些信息，同时可能会显示周边可以停车的位置等，用户可以点击“确认解锁”等进行解锁然后使用，点击后先需要检查与检验，尽管扫码后会展示一些车辆信息，但在解锁时（使用时）还会做一些检查操作，包括车辆本身是否可使用、位置（起点）校验、用户信息登记、付费情况检查（如有的根据产品使用策略用户账户无余额时不能使用、欠费）等。
这一系列计算完毕后，若符合使用标准则自动解锁成功，自动解锁又是咋回事呢？猜测可能是车辆自身具有机械控制，而程序获得“解锁”这个动作后由电子系统控制机械解锁，进而达到可正常骑行的状态。
需要说明的是一旦一个车辆是使用中状态，则会自动上报信息（也可能是pull）到一个“池子”中，也就是纳入到一个范围进行管理，这些信息包括下面将要说的行程信息、费用等等。
第二阶段：骑行数据统计与计算
起始位置被记录后车辆的前进过程被依次记下（路程而非位移），这个过程的实现思路实际有很多种，但为了计算的更精确，就让我想到了微积分的计算原理，实际上就是依次滚动向前间断性计算，圆圈的面积也是这样计算的，这种思想其实被许多业务模型应用，如一些音视频领域用户的用量计算等，可以平滑统计。不断累加里程并同步消耗/计算电量得到两者最新值。骑行过程中一旦发现速度超过电单车警告上限就会语音播报用户，同时骑出服务区之类的提示也会按需播报，这一些动作实际是由车辆的一些系统如测速系统及定位系统触发，原始消息经另一个系统转换及组装得到用户可以识别的语音信号，它的转换过程其实也是一个一一对应的映射关系，如骑出服务区会对应一个标识a，对端根据a去该版本字典中查询，获得对应的信息（也就是a是什么意思），然后通过另一个系统转换即可。
另外猜测可能的动作及指令触发，如车停止时（不论停多久）会即时记录最新位置及电量等信息。
第三阶段：锁定停止
用户停止使用后，像刚才一样发生与解锁相反的控制过程。锁定指令触发后，首先就是获得当前位置信息、用户信息及车辆信息并上报，服务端计算各种信息确认是否扣取费用，扣多少，将行程、里程、费用、用户等信息结合实际需要入库，同时刷新锁定车辆的状态。
可能产生的运营信息：经过服务调用、上报、行程计算、扣费等信息，即可获得一些使用指标，如几分钟内、一小时内使用量、某个地区的使用频率、额度等运营指标，可以用来分析并后续精准投放。