软件的是与非

July 5, 2016

做了这么多年软件,一直有这样的体会,想实现的东西一句话说得完,但用软件实现却是像搭建一座大厦,不得不惊叹人的高级之处,人类统治地球是有道理的,共党统治中国同样也有深奥的学问,万事皆相通。

自然逻辑的抽象与实现

这里的自然逻辑不是指大自然的逻辑,而是人类自然而然的要求,显然,符合常规思维习惯,也符合常规逻辑推理。如果想在智能产品上实现这些东西,显然需要考虑到硬件的工作环境,硬件响应的及时性和准确性,软件层面的缜密和时效性。

比如,要实现一款定位鞋,需要硬件端感知触摸、按压以及运动,然后将这些数据反映到软件端,再由软件来实现自然逻辑。鞋子有哪些自然逻辑?很简单的就有,孩子穿脱鞋时给家长提醒。这是多么简单的一个诉求啊!简单的话再加一个吧,同时还要知道穿脱时的地理位置。

要实现这个诉求,是一个完整的闭环功能:鞋子需要有定位模块,定位模块的作用是采集数据交给服务端分析获得坐标点。鞋子要有能感应到穿脱的模块,暂且叫cap sensor。这个模块要解决很多问题:模块受潮了怎么办?孩子坐着模块感觉不到了压力怎么办?孩子跳动怎么办?等等。如果实际场景下,现硬件技术无法克服所有的这些问题怎么办?

再引入一个硬件:G-sensor,用于感应硬件的运动,脱鞋后鞋子必然是静止的了,那这是不是双保险了?但是如果穿着鞋子静止不动呢?

所有的这些事通过软件来解决吧,也就是软硬的互补,因为硬件稳定可靠性,特别是真实场景与硬件工作原理冲突的问题,这时需要软件介入,规避类似问题,但不能完全规避。

一个流程图看到的处理逻辑

为了解决上段提到的硬件和场景受限的问题,软件来辅助,以下是穿脱鞋子提醒的完整逻辑图: 穿脱鞋子提醒的完整逻辑图

这张图看出,正因为源头数据的不完全可靠,最后不得不分析多项条件,只要条件适合便做出相应的判定。要发送穿鞋通知,只要满足两套组合条件中的一套:
(1)最好的情况:收到G-sensor运动提示,且收到穿鞋数据;组合条件之二:之前发出的是脱鞋通知
(2)不良现象:G-sensor或不稳定,这时连续收到两次穿鞋数据即认为真实状态为穿鞋;组合条件之二:之前发出的是脱鞋通知

要发送脱鞋通知,只要满足三套组合条件中的一套:
(1)最好的情况:收到G-sensor静止的提示,且一直收到的脱鞋数据;组合条件之二:之前发出的是穿鞋通知
(2)不良场景:G-sensor一直感知运动,这样硬件一直在线,但cap sensor感应到脱鞋,设定连续10分钟为脱鞋即视为真实的状态为脱鞋;组合条件之二:之前发出的是穿鞋通知
(3)不良现象:cap sensor不良,最后一段时间一直感应到是穿鞋,或偶有穿鞋,其实已经脱鞋。解决办法是:只要G-sensor下线后,连续10分钟未上线见认为脱鞋;组合条件之二:之前发出的是穿鞋通知

别认为以上仅保存数据、比较数据、查历史状态就可以了,特别是发送脱鞋通知时的第三套组合条件,有以下几个场景:
(1)cap sensor不良才处理,不良的判定
(2)G-sensor正常,说明已经离线,即与服务端的会话已经终结,但需要一个作业,在10分钟后来干活,肯定不能由会话内部来管理这个作业,因为会话已经没有了。另外,会话的数据也将消失,要保存在一个地方被作业获得
(3)假如之后的10分钟内,又上线了,需要取消作业
(4)10分钟之后作业触发,发送脱鞋通知

以上穿脱N套逻辑在一段代码里如何实现?这真是软开的家常便饭了。自然逻辑里的一个简单诉求,在软开里几乎是虐人,不单这样,对测试部门也是一个压力。

引申——人工智能

大脑是一个复杂的物体,近期很火的自动驾驶,是一个非常复杂的命题,大脑轻易完成的事,用软件来实现将变得非常复杂和困难,大脑的认知和分析是无可比拟的。假如,车前方横出来的一个行人,面对他的走向、速度,司机的反应时间点以及实行正确的处理方式,用软件去完成你说难不难?


loading