CN111796577A - 一种数据指令处理方法、装置、车辆及存储介质 - Google Patents

Abstract

本申请公开了一种数据指令处理方法、装置、车辆及存储介质。其中，该方法包括：在车载Android系统应用请求CAN网络时，采用MVVM设计模式，在用户操作View层时，先进行UI界面的刷新，同时下发处理指令并启动定时器，由中间层接收ECU针对处理指令发送的当前定时周期反馈结果，并基于上一个定时周期的反馈结果对当前定时周期反馈结果进行处理。这样可以避免用户频繁操作、请求ECU时，UI界面来回跳变的异常情况。

Description

一种数据指令处理方法、装置、车辆及存储介质

技术领域

本申请实施例涉及数据处理技术，尤其涉及一种数据指令处理方法、装置、车辆及存储介质。

背景技术

在汽车领域，搭载基于安卓(Andriod)系统的车载信息娱乐系统的车型逐渐增多，运行基于车载Andriod系统的应用除了需要请求超文本传输协议(HyperText TransferProtocol,Http)网络之外，还需要请求控制器局域网(Controller Area Network)网络，以对CAN网络的业务逻辑(如图1所示)和用户界面(User Interface，UI)进行管理。

现有的实现方案为采用模型、视图、控制器(Model、View、Controller，MVC)设计模式或MVC改良设计模式(Model、View、Presenter，MVP)，在数据变化时，增加耦合度进行模式设置以刷新UI界面。但是，MVC设计模式中View的刷新需要由View触发，在车载Andriod CAN网络中，由CAN网络反馈不同Model的信号会被同时集中到Controller中进行界面控制，造成Controller代码膨胀，并且开发过程中对功能划分后，对不同模块的维护的难度也较大。而在MVP设计模式中，去掉了View和Model的耦合，当系统内存不足时，系统会回收Activity组件(在Android中通常使用Activity组件执行Controller角色)，通常用OnSaveInstanceState()去保存状态，用OnRestoreInstanceState()去恢复状态。但在MVP设计模式中，View层不应该直接操作Model，这样会增大Model与View之间的耦合，而且UI改变时，可能导致Presenter更新UI的接口也需要同步更改，这样也会产生一定的耦合。

发明内容

为了解决上述至少一个技术问题，本申请实施例提供了以下方案。

第一方面，本申请实施例还提供了一种数据指令处理方法，该方法包括：

视图层接收操作指令，并根据操作指令向用户界面层发送刷新指令；

视图层根据所述操作指令向视图模型层发送处理指令；

视图模型层将处理指令通过中间层传输至电子控制单元(Electronic ControlUnit，ECU)，并启动定时器；

中间层接收ECU针对处理指令发送的当前定时周期反馈结果，并基于上一个定时周期的反馈结果对当前定时周期反馈结果进行处理。

第二方面，本申请实施例还提供了一种数据指令处理装置，该装置包括：

视图模块，用于接收操作指令，并根据操作指令向用户界面层发送刷新指令；

视图模块，还用于根据操作指令向视图模型模块发送处理指令；

视图模型模块，用于将处理指令通过中间模块传输至ECU，并启动定时器；

中间模块，用于接收ECU针对处理指令发送的当前定时周期反馈结果，并基于上一个定时周期的反馈结果对当前定时周期反馈结果进行处理。

第三方面，本申请实施例还提供了一种车辆，包括：ECU、存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，当处理器执行计算机程序时，实现如本申请任一实施例提供的数据指令处理方法。

第四方面，本申请实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时，实现如本申请任一实施例提供的数据指令处理方法。

本申请实施例提供了一种数据指令处理方法、装置、车辆及存储介质，在车载Android系统应用请求CAN网络时，采用MVVM设计模式，在用户操作View层时，先进行UI界面的刷新，同时下发处理指令并启动定时器，由中间层接收ECU针对处理指令发送的当前定时周期反馈结果，并基于上一个定时周期对当前定时周期反馈结果进行处理。这样可以避免用户频繁操作、请求ECU时，UI界面来回跳变的异常情况。

附图说明

图1为现有技术中的CAN网络的业务逻辑示意图；

图2是MVC设计模式示意图；

图3是MVP设计模式示意图；

图4是MVVM设计模式示意图；

图5是本申请实施例提供的一种数据指令处理方法流程图；

图6是本申请实施例提供的一种交互架构示意图；

图7是本申请实施例提供的一种数据指令处理装置结构示意图；

图8是本申请实施例提供的一种设备结构示意图。

具体实施方式

下面结合附图和实施例对本申请作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释本申请，而非对本申请的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与本申请相关的部分而非全部结构。

另外，在本申请实施例中，“可选地”或者“示例性地”等词用于表示作例子、例证或说明。本申请实施例中被描述为“可选地”或者“示例性地”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用“可选地”或者“示例性地”等词旨在以具体方式呈现相关概念。

为了便于理解，示例地给出了部分与本申请相关概念的说明以供参考。如下所示：

MVC设计模式如图2所示，包括：

Model为模型，用于进行数据保存，数据更新后，用于通过View进行界面更新。

View为视图，用于接收用户的请求，并将请求传递给Controller。

Controller为控制器，用于进行业务逻辑处理后，通知Model进行更新。在Android系统中，通常是使用Activity组件来执行Controller角色，但在实际应用中，Activity也会控制一些UI元素，例如，进度条等有业务逻辑刷新的UI元素，这样可能导致部分View和Controller在同一个类中，使承担了两个角色的Activity组件的代码迅速膨胀起来。

MVP设计模式如图3所示，包括：

MVP设计模式的Model和View与MVC设计模式中的Model和View策略一致，Presenter用于负责逻辑业务的处理，修改Model，通知界面更新View。但Presenter与MVC中Controller不同的是，当页面逻辑复杂的话，相应的接口也会增加，从而增加维护成本。

MVVM设计模式如图4所示，包括：

Model为模型，负责处理数据的加载或存储，Model数据有更新后，将更新后的数据传递至ViewModel。

View为视图，负责界面数据的展示，与用户进行交互，并与ViewModel进行双向交互。View绑定ViewModel，当ViewModel数据发生改变时，View进行相应的UI更新，或者，UI更新时，View向ViewModel发送指令。

ViewModel为视图模型，负责实现View与Model的交互，负责业务逻辑，并通知Model进行数据更新。

车载Andriod系统下的应用区别于其他终端应用最主要的功能在于对涉及CAN网络的业务逻辑和UI管理上。车载Andriod应用请求CAN网络和其他终端Andriod请求Http网络具有的不同的特点，例如：

1、请求网络的反馈时间。由于请求CAN网络的时间包括ECU运算的时间，因此，请求CAN网络的时间比请求Http网络的时间长，其中，ECU用于与Andriod系统进行通信。但在传统的MVC、MVP设计模式中，长时间的等待反馈会造成界面卡住。

2、CAN网络可以周期性反馈ECU的状态。ECU作为具有独立计算和存储能力的电子控制单元，在ECU内部错误或者基于其他原因的逻辑变化时，可能会在车载信息娱乐系统(In-Vehicle Infotainment，IVI)未请求ECU时，发出反馈，此时，IVI显示ECU的真实状态。

3、ECU有非可预见错误时，可以通过CAN网络反馈无效值或预留值，此时，IVI结合自身业务逻辑进行相应的UI显示刷新。

在上述概念的基础上，本申请实施例提供了一种数据指令处理方法，该方法可以应用于搭载Andriod系统的IVI系统的车辆中，通过上述MVVM设计模式，以高效、正确地处理CAN网络的反馈。如图5所示，该方法包括：

S501、视图层接收操作指令，并根据操作指令向用户界面层发送刷新指令。

本步骤中的操作指令可以为用户在View层上进行操作，以对车辆空调、车身控制模块(Body Control Module，BCM)等进行控制时，View层接收到的操作指令。

当用户操作View层时，可以先进行UI界面的刷新，即根据接收到的操作指令向UI层发送刷新指令，以进行UI界面的变化，这样可以避免UI界面卡住。

S502、视图层根据操作指令向视图模型层发送处理指令。

可选地，View层上设置有数据捆绑机制，即Data Binding模式，UI层的相关元素通过数据捆绑机制与ViewModel层绑定，以充分解耦View层和ViewModel层。但在Android系统的实际应用中，可以通过Android组件，例如，Activity、Fragment进行View和ViewModel的绑定。

S503、视图模型层将处理指令通过中间层传输至ECU，并启动定时器。

在本申请实施例中，View层的事件与ViewModel层是绑定的，用户操作View层引起View的数据变化时，那么ViewModel层可以根据View层发送的处理指令进行业务处理，并将处理指令通过中间层和网络层传输至ECU，该交互架构如图6所示，处理指令可以以CAN消息的形式发送。

需要说明的是，ViewModel层每次在下发指令的同时启动一个定时器，并将上一个定时器清零，其中，该定时器的定时时间可以根据Android系统的应用层的实际需要确定，并由ViewModel层判断定时时间是否到时。如图6所示，该应用层包括本申请实施例中的View层、ViewModel层、中间层等。

S504、中间层接收ECU针对处理指令发送的当前定时周期反馈结果，并基于上一个定时周期的反馈结果对当前定时周期反馈结果进行处理。

ECU接收到处理指令后进行业务处理并反馈处理结果，该反馈结果可以理解为当前定时周期反馈结果，由于不同ECU的处理时间不同，例如，从百毫秒级别至秒级别。因此，在本申请实施例中，先进行UI处理，以避免用户感知到操作界面卡住，频繁点击导致Android系统错误处理机制无响应。

中间层接收到ECU进行业务处理后发送的当前定时周期反馈结果后，根据ECU发送的上一个定时周期的反馈结果和当前定时周期反馈结果，对当前定时周期反馈结果进行处理。

本申请实施例提供了一种数据指令处理方法，在车载Android系统应用请求CAN网络时，采用MVVM设计模式，在用户操作View层时，先进行UI界面的刷新，同时下发处理指令并启动定时器，由中间层接收ECU针对处理指令发送的当前定时周期反馈结果，并基于上一个定时周期的反馈结果对当前定时周期反馈结果进行处理。这样可以避免用户频繁操作、请求ECU时，UI界面来回跳变的异常情况。

在一种实施例中，上述步骤S104包括但不限于以下实现方式，例如，中间层对ECU通过网络传输层发送的当前定时周期反馈结果进行解析封装，当上一个定时周期和当前定时周期的反馈结果不同，当前定时周期反馈结果相比于上一个定时周期的反馈结果有变化时，中间层将封装后的反馈结果传输至视图模型层。

如图6所示，该传输方式可以为通过模型层和领域对象(Domain object)层传输。当业务逻辑需要，要求对反馈结果进行存储时，领域对象层对业务操作、业务状态、业务规则等进行保存。另外，处理后的反馈结果可以根据业务逻辑的需要融合为不同的模型。

反之，当上一个定时周期的反馈结果与当前定时周期反馈结果相同时，中间层不处理封装后的反馈结果，即与UI界面先变化的结果一致时，不进行UI界面的刷新。

ViewModel层接收到封装后的反馈结果后，向View层发送修改指令，通知View层更新数据，并向UI层发送刷新指令进行界面。

在本申请实施例中，当View层未接收操作指令，即用户未对View进行操作时，若中间层接收到更新信号，则中间层将更新信号传输至ViewModel层，ViewModel层将更新信号分别发送至View层和UI层。

其中，上述更新信号可以为ECU反馈的变化消息，例如，ECU发生故障，或者车辆上安装的传感器(例如，阳光雨露传感器、PM2.5传感器等)出现故障时，ECU以CAN消息的形式反馈更新信号，以通过UI界面提醒用户。

图7为本申请实施例提供的一种数据指令处理装置，如图7所示，该装置包括：视图模块701、视图模型模块702、中间模块703；

其中，视图模块，用于接收操作指令，并根据操作指令向用户界面层发送刷新指令；

视图模块，还用于根据操作指令向视图模型模块发送处理指令；

视图模型模块，用于将处理指令通过中间模块传输至ECU，并启动定时器；

中间模块，用于接收ECU针对处理指令发送的当前定时周期反馈结果，并基于上一个定时周期的反馈结果对当前定时周期反馈结果进行处理。

在一种可能的实现方式中，中间模块，用于对当前定时周期反馈结果进行解析封装；

以及，当上一个定时周期的反馈结果与当前定时周期反馈结果不同时，中间模块，用于将封装后的反馈结果传输至视图模型模块；

或者，当上一个定时周期的反馈结果与当前定时周期反馈结果相同时，中间模块不处理封装后的反馈结果。

在一种可能的实现方式中，视图模型模块，用于根据封装后的反馈结果向视图模块发送修改指令，并向用户界面层发送刷新指令。

可选地，在视图模块未接收操作指令的情况下，若中间模块接收到更新信号，则中间模块将更新信号传输至视图模型模块；视图模型模块，用于将更新信号分别发送至视图模块和UI层。

另外，在视图模块上可以设置数据捆绑机制，UI层的相关元素可以通过数据捆绑机制与视图模型模块绑定。

上述数据指令处理装置可以实现图5所提供的数据指令处理方法，具备执行方法相应的器件和有益效果。

图8为一实施例提供的一种设备，如图8所示，该设备包括：处理器801、存储器802、输入装置803、输出装置804；设备中的处理器801的数量可以是一个或多个，图8中以一个处理器801为例；设备中的处理器801、存储器802、输入装置803、输出装置804可以通过总线或其他方式连接，图8中以通过总线连接为例。

存储器802作为一种计算机可读存储介质，可用于存储软件程序、计算机可执行程序以及模块，如本发明实施例中的数据指令处理方法对应的程序指令/模块(例如，数据指令处理装置中的视图模块701、视图模型模块702、中间模块703)。处理器801通过运行存储在存储器802中的软件程序、指令以及模块，从而执行设备的各种功能应用以及数据处理，即实现上述的数据指令处理方法。

存储器802可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序；存储数据区可存储根据终端的使用所创建的数据等。此外，存储器802可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实例中，存储器802可进一步包括相对于处理器901远程设置的存储器，这些远程存储器可以通过网络连接至设备/终端/服务器。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

输入装置803可用于接收输入的数字或字符信息，以及产生与用户设置以及功能控制有关的键信号输入。输出装置804可包括显示屏等显示设备。

本申请实施例还提供一种包含计算机可执行指令的存储介质，该计算机可执行指令在由计算机处理器执行时用于执行一种数据指令处理方法，该方法包括：

视图层接收操作指令，并根据操作指令向用户界面层发送刷新指令；

视图层根据操作指令向视图模型层发送处理指令；

视图模型层将处理指令通过中间层传输至ECU，并启动定时器；

中间层接收ECU针对处理指令发送的当前定时周期反馈结果，并基于上一个定时周期的反馈结果对当前定时周期反馈结果进行处理。

通过以上关于实施方式的描述，所属领域的技术人员可以清楚地了解到，本申请可借助软件及必需的通用硬件来实现，当然也可以通过硬件实现，但很多情况下前者是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如计算机的软盘、只读存储器(Read-Only Memory,ROM)、随机存取存储器(RandomAccess Memory,RAM)、闪存(FLASH)、硬盘或光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述的方法。

值得注意的是，上述数据指令处理装置中所包括的模块只是按照功能逻辑进行划分，但并不局限于上述的划分方式，只要能够实现相应的功能即可；另外，视图模块等模块的具体名称也只是为了便于区分，并不用于限制本申请的保护范围。

注意，上述仅为本申请的较佳实施例及所运用技术原理。本领域技术人员会理解，本申请不限于这里所述的特定实施例，对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本申请的保护范围。因此，虽然通过以上实施例对本申请进行了较为详细的说明，但是本申请不仅仅限于以上实施例，在不脱离本申请构思的情况下，还可以包括更多其他等效实施例，而本申请的范围由所附的权利要求范围决定。

Claims (10)

1.一种数据指令处理方法，其特征在于，包括：

视图层接收操作指令，并根据所述操作指令向用户界面层发送刷新指令；

所述视图层根据所述操作指令向视图模型层发送处理指令；

所述视图模型层将所述处理指令通过中间层传输至电子控制单元ECU，并启动定时器；

所述中间层接收所述ECU针对所述处理指令发送的当前定时周期反馈结果，并基于上一个定时周期的反馈结果对所述当前定时周期反馈结果进行处理。

2.根据权利要求1所述的方法，其特征在于，所述中间层基于上一个定时周期的反馈结果对所述当前定时周期反馈结果进行处理，包括：

所述中间层对所述当前定时周期反馈结果进行解析封装；

当上一个定时周期的反馈结果与当前定时周期反馈结果不同时，所述中间层将封装后的反馈结果传输至视图模型层；

当上一个定时周期的反馈结果与当前定时周期反馈结果相同时，所述中间层不处理封装后的反馈结果。

3.根据权利要求2所述的方法，其特征在于，在所述中间层将封装后的反馈结果传输至视图模型层之后，所述方法还包括：

所述视图模型层根据所述封装后的反馈结果向所述视图层发送修改指令，并向所述用户界面层发送刷新指令。

4.根据权利要求1所述的方法，其特征在于，所述方法还包括：

在所述视图层未接收操作指令的情况下，若所述中间层接收到更新信号，则所述中间层将所述更新信号传输至视图模型层；

所述视图模型层将所述更新信号分别发送至视图层和用户界面层。

5.根据权利要求1-4任一项所述的方法，其特征在于，所述方法还包括：

所述视图层上设置数据捆绑机制，所述用户界面层的元素通过所述数据捆绑机制与所述视图模型层绑定。

6.一种数据指令处理装置，其特征在于，包括：

视图模块，用于接收操作指令，并根据所述操作指令向用户界面层发送刷新指令；

所述视图模块，还用于根据所述操作指令向视图模型模块发送处理指令；

所述视图模型模块，用于将所述处理指令通过中间模块传输至电子控制单元ECU，并启动定时器；

所述中间模块，用于接收所述ECU针对所述处理指令发送的当前定时周期反馈结果，并基于上一个定时周期的反馈结果对所述当前定时周期反馈结果进行处理。

7.根据权利要求6所述的装置，其特征在于，所述中间模块，用于对所述当前定时周期反馈结果进行解析封装；

以及，当上一个定时周期的反馈结果与当前定时周期反馈结果不同时，所述中间模块，用于将封装后的反馈结果传输至视图模型模块；

或者，当上一个定时周期的反馈结果与当前定时周期反馈结果相同时，所述中间模块不处理封装后的反馈结果。

8.根据权利要求7所述的装置，其特征在于，所述视图模型模块，用于根据所述封装后的反馈结果向所述视图模块发送修改指令，并向所述用户界面层发送刷新指令。

9.一种车辆，其特征在于，包括：ECU、存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时，实现如权利要求1-5任一项所述的数据指令处理方法。

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时，实现如权利要求1-5任一项所述的数据指令处理方法。

Images