TBox与APP如何分工

设想以下场景，汽车时速在80公里以下，你可以打开车窗吹风。而如果车速在120公里以上时，你还会打开车窗吹风吗？反正我不会，因为我在高速上试过，噪音特别大，而且也不安全。

所以，可以定义一个场景，当车速在120公里以上时（这个可以再考虑，甚至80公里以下也可以包括进去），如果车窗还是打开的，需要提醒用户关闭车窗。

当前的实现步骤是这样的，如果车窗打开，TBox会向APP发送车窗打开的信号，APP会向TBox请求车辆速度数据，如果速度大于等于120公里，就会弹出“车速高速120公里，请勿打开车窗”的提醒。否则没有提醒。

仔细斟酌上面的流程，我们会发现这个流程的设计有缺陷。因为这个流程只会在车速大于120公里打开车窗时有效。而如果在车速80公里以下时打开车窗，当车速提高到120公里时，虽然车窗还是打开的，但没有提醒。

是问题吗？是问题，也可以解决。最简单明了的办法就是当车窗打开时，APP定时的向TBox请求车辆速度数据进行判断。这个方法技术上可行，但是，实际上不可行。因为我们要考虑一个很重要的情况，那就是APP是跑在手机上的，而手机电池总是那么不给力。如果用户只是在80公里以下开车，那么APP的这些请求就是做了无用功，而且因为要不断的动用与TBox连接的无线模块进行通信，会造成手机电池耗电过快。

所以，所以，技术上可行，实际上不可行。因为你不能让用户的手机耗电过快。那怎么办？要彻底的解决问题，就要重新定义TBox与APP的功能。

原来的定义是：TBox负责从Can总线上取数据，然后传给手机APP，手机APP对各个业务场景进行逻辑判断，并给用户提醒。

TBox就是个数据通路，它不负责逻辑判断。它不负责逻辑判断，那么这个判断就会交给APP，而根据上面场景的描述，我们发现如果APP中进行逻辑判断，就会造成许多场景实现困难。

那么重新定义后的功能是什么样的？

TBox取得数据，并进行逻辑判断，判断结果通知APP。这样APP变成一个显示终端，尽量减少逻辑处理，这样可以减少电量消耗。当然，TBox耗电多一点是没有问题的，因为他连接的是汽车电源。

再分析下上面的场景，如果车窗打开，TBox会记录这个状态，并且在状态列表中根据Can数据上传的车辆速度（Can数据上传的频率是100ms），来决定是否产生提醒信息，如果有提醒信息就通知APP弹出提醒框。

这下，场景看起来就合理了，因为TBox与Can之间的数据交换是自动的，频繁的，所以不需要像APP那样要加个定时器进行定期查询了。

最后，再对TBox进行下功能定义，TBox不仅仅是从Can取数据，并转发数据的通路，它应该还有运算功能，根据设定的场景条件进行逻辑判断，并得出正确结果，通知其它模块。

我这里多说一句，每个博文下来，有人围观，没有人出声。

麻烦大家告诉下，你们在哪里看到，然后来围观的？