CN100390734C - 器件状态改变消息的处理方法 - Google Patents

Abstract

本发明涉及电子或通信设备，公开了一种器件状态改变消息的处理方法，使得提高系统的健壮性以及系统对消息处理的正确性。本发明中，在器件状态相关消息的处理过程中，对器件当前状态的进行再确认，如果该器件的当前与待处理消息所期望的状态不一致则触发异常处理。作为一种异常处理方式，如果器件只有两个状态并且当前处理的是器件状态改变消息，则可通过丢弃一下条器件状态改变消息以实现去抖动。

Description

器件状态改变消息的处理方法

技术领域

本发明涉及电子或通信设备，特别涉及电子或通信设备中器件状态改变消息的处理方法。

背景技术

随着通信技术与计算机科学的不断发展，人们对软件系统规模的要求愈来愈高。为了满足市场需求以及软件系统的开发效率，系统开发人员往往采用模块化的开发方法，也就是将整的一个软件系统按功能划分成各个模块，每个模块实现其相应的功能。为了提高该系统的性能稳定性，模块与模块之间应当尽量满足低耦合、高内聚的要求。低耦合指的是不同模块之间相互联系的程度应尽量的低；高内聚指的是同一模块内各个元素之间相互联系的程度应尽量的高。

在现代软件设计过程中普遍采用消息处理机制来大大的降低软件系统各模块之间的耦合度，使软件系统内各模块之间能更好的分工与合作。在采用消息处理机制的软件系统中，各功能模块之间的信息交互是由消息的发送以及消息的接收处理来实现的。

目前，在许多电子产品中，相关器件的状态是由底层驱动模块进行实时检测的，当器件的状态改变时，底层驱动模块就会向上层应用模块发送器件状态改变消息。上层应用模块负责接受该器件状态改变消息，并按照定义的规程执行相应的操作。如图1所示，在全球移动通信系统(Global System formobile Communication，简称“GSM”)系统中，提供用户身份识别的用户身份鉴别模件(Subscriber Identification Module，简称“SIM”)是由底层驱动模块进行实时检测的，当底层驱动模块发现SIM的状态改变时，就会向上层应用模块发送器件状态改变消息，该消息存储在起缓存作用的消息队列中。上层应用模块从消息队列中取出器件状态改变消息，按照器件状态改变消息的内容执行相应的操作。

在实际应用中，上述方案存在以下问题：当底层驱动模块检测到器件状态发生改变并将器件状态改变消息发送到上层应用模块后，如果该器件的状态在很短的时间内再次发生改变，软件系统就有可能出现异常。例如，器件的抖动就有可能引起软件系统的异常。

造成这种情况的主要原因在于，消息的发送与消息的处理是一个异步过程。也就是说，在底层驱动模块将器件状态改变消息发送到上层应用模块与上层应用模块接收并开始处理该消息之间存在着一定的时间间隔，并且，这段时间间隔的大小因不同的现实系统或同一系统所处的不同状态而不同。而在现有的消息处理过程中，上层应用模块一旦接收到由底层驱动模块发送来的器件状态改变消息，就依据器件状态改变消息的内容立即处理该消息。因此，如果在上层应用模块处理器件状态改变消息时，该器件状态已经再次发生改变，那么，上层应用模块简单的按照该器件状态改变消息的内容进行处理就有可能引起软件系统的异常。如图1所示，如果SIM发生抖动，那么SIM的状态就会在极短的时间内发生两次改变。由于底层驱动模块是实时检测SIM的状态，所以，底层驱动模块就会几乎连续的发送两次器件状态改变消息给上层应用模块，这两条消息都先存储在消息队列中。当上层应用模块从消息队列中取出第一条器件状态改变消息并按照该消息的内容进行处理时，SIM已经发生了第二次的状态改变，也就是说上层应用模块在处理该器件状态改变消息时所期待的器件状态与当前SIM的器件状态不一致。此时，就有可能引起软件系统的异常。

虽然，也可以通过在底层驱动模块的器件状态检测过程中增加一个延时再确认的过程来改善器件状态的去抖动处理以及系统消息处理的正确性。其中，延时再确认指的是当底层驱动模块检测到器件的状态发生改变时，并不立即发送器件状态改变消息给上层应用模块，而是延时一段时间，如果该器件的状态没有再次发生改变，才将器件状态改变消息发送给上层应用模块。但是，对延时时间的设置难度较大。如果延时时间设置的过短，去抖动效果较差，而且同样可能出现因为器件状态的再次改变导致上层应用模块错误处理消息；如果延时时间设置的过长，虽然去抖动效果以及消息处理的正确性会有所改善，但是系统的实时性较差。

发明内容

有鉴于此，本发明的主要目的是在上层应用模块的器件状态改变消息处理过程中实现对器件状态抖动的去抖动处理。

为实现上述目的，本发明提供了一种器件状态改变消息的处理方法，涉及用于实时检测器件状态的底层驱动模块和处理器件状态改变消息的上层应用模块，所述方法包含以下步骤：

A当所述底层驱动模块检测到器件的状态发生变化时，记录该器件的当前状态，向所述上层应用模块上报器件状态改变消息，所述器件的状态只有两个状态；

B所述上层应用模块处理状态改变消息时，先查看是否有消息处理异常标志，如果是则放弃该消息的处理并清除消息处理异常标志；如果否，则查询该器件被记录的当前状态，比较查询结果和被处理消息所期望的状态，如果不一致则直接丢弃下一条所述底层驱动模块上报的器件状态改变消息。

此外在所述方法中，所述步骤A中，所述底层驱动模块将所述器件的当前状态记录在本地；

所述步骤B中，所述上层应用模块通过与所述底层驱动模块的交互，查询所述器件被记录的当前状态。

此外在所述方法中，所述步骤A中，所述底层驱动模块将所述器件的当前状态记录在所述上层应用模块可以访问的公共存储区或寄存器；

所述步骤B中，所述上层应用模块通过从所述公共存储区或寄存器直接读取相应的数据，查询所述器件被记录的当前状态。

此外在所述方法中，所述步骤B中，如果所述查询结果和被处理消息所期望的状态一致，则所述上层应用模块正常处理所述消息。

此外在所述方法中，所述器件可以是用户身份鉴别模件或用户服务识别模块，该器件的状态可以是在位和不在位两种。

此外在所述方法中，所述器件可以是耳机，该器件的状态可以是插入和未插入两种。

此外在所述方法中，所述步骤B中，所述步骤B中，所述状态改变消息可以是耳机按键状态改变消息，查询的该器件被记录的当前状态可以是耳机插入或未插入状态，所述耳机按键状态改变消息所期望的状态是耳机插入状态，如果查询结果是耳机未插入状态，则忽略当前的耳机按键状态改变消息。

这种技术方案上的区别，带来了较为明显的有益效果，可以很简单的在上层应用模块的器件状态改变消息处理过程中实现对器件状态抖动的去抖动处理。这里因为抖动时两个状态的消息一定是成对出现的，如果处理一条器件状态改变消息时发现与器件当前的状态不匹配，则下一条器件状态改变消息一定是与处理中的消息起抵消作用的，因此可以通过成对地忽略器件状态改变消息达到去抖动的效果。

附图说明

图1是现有技术中对SIM状态检测及消息处理的结构图；

图2是根据本发明第一实施例中底层驱动模块检测器件状态的流程图；

图3是根据本发明第一实施例中上层应用模块处理器件状态改变消息的流程图；

图4是根据本发明第二实施例中底层驱动模块检测器件状态的流程图；

图5是根据本发明第二实施例中上层应用模块处理器件状态改变消息的流程图；

图6是根据本发明第三实施例中其他与器件相关的消息处理流程图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明作进一步地详细描述。

本发明通过记录器件的当前状态，使上层应用模块在处理器件状态改变消息时，能够先核对该消息所期待的器件状态是否为器件的当前状态。如果是，就按照该消息的内容正常处理该消息；否则，就进行异常处理。对只有两个状态的器件而言，所进行的异常处理就是对该器件进行去抖动的处理。

本发明的第一实施例是与自身器件相关的消息处理方法。该方法包含两部分：底层驱动模块对器件的检测以及上层应用模块对器件状态改变消息的处理。

其中，底层驱动模块检测器件状态的流程图如图2所示。在步骤210中，底层驱动模块检测器件的状态是否发生改变。需要说明的是，底层驱动模块对器件状态的检测是实时的，一旦检测到器件状态发生改变，就立即进入步骤220。以GSM中的SIM为例，底层驱动模块实时检测SIM的状态，SIM的状态只有在位和不在位两种，如果SIM的状态从在位转变成了不在位，那么，就立即进入步骤220。

在步骤220中，底层驱动模块在本地记录下器件的当前状态。针对上述案例，底层驱动模块将SIM当前的不在位状态记录在本地。

接着，进入步骤230，上报器件状态改变消息。也就是由底层驱动模块向上层应用模块发送器件状态改变消息。针对上述案例，底层驱动模块将SIM状态改变消息上报给上层应用模块。

步骤210至步骤230是底层驱动模块对器件的检测过程，接下来，详细说明上层应用模块对器件状态改变消息的处理。

如图3所示，在步骤310中，上层应用模块查看是否有消息处理异常标志。当上层应用模块接收到由底层驱动模块上报的器件状态改变消息时，并不急于对该消息进行处理，而是先查看是否有消息处理异常标志。消息处理异常标志是上层应用模块自行设置的一个标志，表示上层应用模块对一个器件状态改变消息是进行了异常处理，该异常处理可以是放弃对该器件状态改变消息的处理。如果查看结果是有消息处理异常标志，就进入步骤350；否则，就进入步骤320。

在步骤320中，向底层驱动模块查看器件的当前状态。如果没有消息处理异常标志，那么，上层应用模块就可以通过与底层驱动模块的交互查看器件的当前状态。比如说，上层应用模块先向底层驱动模块发送一个想要查看器件当前状态的请求，底层驱动模块接收到该请求后，再向上层应用模块返回一个含有该器件当前状态信息的消息。针对上述案例，当上层应用模块接收到SIM状态改变消息后，如果查看到没有消息处理异常标志，那么，上层应用模块就向底层驱动模块查看SIM的当前状态。

接着，进入步骤330，上层应用模块判断器件状态改变消息中所期待的器件状态是否与在步骤320中查看到的器件当前状态一致。如果一致，就进入步骤340；否则，就进入步骤360。针对上述案例，如果底层驱动模块是因为检测到SIM的状态从在位转变成不在位，而向上层应用模块发送器件状态改变消息，并且，上层应用模块向底层驱动模块查看到的SIM当前状态是不在位状态，那么，上层应用模块就可以判断出器件状态改变消息中所期待的器件状态与器件的当前状态是一致的，进入步骤340。如果底层驱动模块是因为检测到SIM的状态从不在位转变成在位，而向上层应用模块发送器件状态改变消息，但是，上层应用模块向底层驱动模块查看到的SIM当前状态是不在位状态，那么，上层应用模块就可以判断出器件状态改变消息中所期待的器件状态与器件的当前状态是不一致的，进入步骤360。

在步骤340中，上层应用模块根据器件状态改变消息的内容正常处理该消息。

在步骤350中，放弃该消息的处理并清除消息处理异常标志。正如在步骤310中所述，如果有消息处理异常标志，表示上层应用模块对上一条器件状态改变消息进行了异常处理。因为只有在器件的当前状态与上层应用模块处理器件状态改变消息时所期待的状态不一致的情况下，上层应用模块才会对该消息进行异常处理。并且，只有在发生抖动的情况下，才会出现器件的当前状态与上层应用模块处理器件状态改变消息时所期待的状态不一致(原因见步骤360)。对于只有两种状态的器件而言，器件的抖动势必会使器件状态改变消息成对出现。所以，如果对上一条器件状态改变消息已经进行了异常处理，那么，只要对这一条器件状态改变消息继续进行异常处理，也就是放弃对该消息的处理，就可以达到去抖动的目的。另外，清除消息处理异常标志使得这次抖动对上层应用模块在处理之后接收到的器件状态改变消息时，不产生任何影响。针对上述案例，当上层应用模块接收到SIM状态改变消息后，如果查看到有消息处理异常标志，就说明上层应用模块已经异常处理了一条由于抖动而产生的SIM状态改变消息，那么，这条消息就一定是由于抖动而产生的第二条SIM状态改变消息，所以，要放弃对该消息的处理，并清除消息处理异常标志。

在步骤360中，上层应用模块放弃对该器件状态改变消息的处理并设置消息处理异常标志。虽然底层驱动模块将器件状态改变消息发送到上层应用模块与上层应用模块接收并开始处理该消息是一个异步过程，其间存在着一定的时间间隔。但是由于这段时间间隔极短，在正常情况下，器件状态不会在这段时间间隔内再次发生改变。但是在抖动的情况下，器件状态就会连续的发生改变。如果器件状态改变消息中所期待的器件状态与器件的当前状态不一致，就说明器件状态在这段极短的时间间隔内再次发生了改变，也就说明了该器件发生了抖动。所以，上层应用模块就要对由于抖动而产生的器件状态改变消息采取异常处理，也就是放弃对该消息的处理。并且，正是因为不存在消息处理异常标志才会进入到本步骤，因此可以判断出该器件状态改变消息是由于抖动而产生的第一条器件状态改变消息。所以，要设置消息处理异常标志，表示已经对由于抖动而产生的第一条器件状态改变消息采取了异常处理。针对上述案例，如果SIM发生了抖动，那么在上层应用模块处理第一条由于抖动而产生的器件状态改变消息时会发现消息中所期待的器件状态与SIM的当前状态不一致，因而放弃对该消息的处理，并且设置消息处理异常标志。

需要说明的是，本实施例中的器件除了可以是SIM，还可以是用户服务识别模块(User Service Identify Module，简称“USIM”)，USIM的状态也只有在位与不在位两种。本实施例中通过上层应用模块在处理器件状态改变消息时，对器件的当前状态进行的再确认，可以避免上层应用模块对由于抖动而产生的器件状态改变消息所进行的误处理，从而提高了系统的健壮性以及系统对消息处理的正确性。对只有两个状态的器件而言，可以很简单地在上层应用模块的器件状态改变消息处理过程中实现对器件状态的去抖动处理。

本发明的第二实施例也是与自身器件相关的消息处理方法，该方法也包含两部分：底层驱动模块对器件的检测以及上层应用模块对器件状态改变消息的处理。

底层驱动模块对器件的检测如图4所示。在步骤410中，底层驱动模块检测器件的状态是否发生改变。本步骤同步骤210。

接着，进入步骤420，底层驱动模块将器件的当前状态记录在公共存储区或者寄存器。本步骤同220类似，都是记录器件的当前状态。所不同的是，在步骤220中，器件的当前状态是记录在底层驱动模块中；而在本步骤中，器件的当前状态是记录在公共存储区或者是寄存器中。

接着，进入步骤430，底层驱动模块将器件状态改变消息上报给上层应用模块。本步骤同步骤230。

上层应用模块对器件状态改变消息的处理如图5所示。在步骤510中，上层应用模块查看是否有消息处理异常标志，本步骤同步骤310。如果有消息处理异常标志，就进入步骤550；否则，就进入步骤520。

在步骤550中，上层应用模块放弃对该器件状态改变消息的处理并清除消息处理异常标志。本步骤同步骤350。

在步骤520中，上层应用模块向公共存储区或者寄存器查看器件的当前状态。由于在步骤420中，底层驱动模块已将器件的当前状态记录在公共存储区或者是寄存器中，所以，上层应用模块只要通过从公共存储区或寄存器中直接读取相应的数据，就可以查看到该器件被记录的当前状态。本步骤与步骤320类似，都是上层应用模块查看器件的当前状态。所不同的是，在步骤320中，上层应用模块是向底层驱动模块查看器件的当前状态；而在本步骤中，上层应用模块是向公共存储区或者寄存器查看器件的当前状态。

接着，进入步骤530，上层应用模块判断器件状态改变消息中所期待的器件状态是否与在步骤520中所查看到的器件当前状态一致，如果一致，就进入步骤540；否则，就进入步骤560。

在步骤540中，上层应用模块根据器件状态改变消息的内容正常处理该消息。本步骤同步骤340。

在步骤560中，上层应用模块放弃对该器件状态改变消息的处理并设置消息处理异常标志。本步骤同步骤360。

可见，本实施例与第一实施例基本相同，不同之处仅在于：在第一实施例中，器件的当前状态是记录在底层驱动模块中，所以上层应用模块是向底层驱动模块查看器件的当前状态；而在本实施例中，器件的当前状态是记录在公共存储区或者是寄存器中，所以上层应用模块是从公共存储区或者寄存器查看到器件的当前状态。因此，本实施例中的器件也可以是SIM或者USIM。并且，本实施例完全可以达到第一实施例的作用与效果。

本发明的第三实施例是与其他器件相关的消息处理方法。本实施例是在第一、第二实施例的基础上，新增其他与器件相关的消息处理部分。

为了使本实施例的说明更加清楚，以耳机按键为例进行说明。与耳机按键相关的器件是耳机，耳机的状态有两种：插入和未插入。底层驱动模块对耳机状态的检测以及上层应用模块对耳机状态改变消息的处理与第一或第二实施例完全相同，在此仅对其作简单说明。底层驱动模块对耳机的状态进行实时检测，一旦发现耳机的状态发生了改变，就记录耳机的当前状态并将耳机的状态改变消息上报给上层应用模块。上层应用模块接收到耳机的状态改变消息后并不急于处理，而是先查看是否有消息处理异常标志，如果有，就说明耳机发生了抖动，放弃对该消息的处理并清除消息处理异常标志；如果没有，就比较该消息中所期待的耳机状态与记录下来的耳机状态是否一致，如果一致，就按该消息的内容正常处理；如果不一致，就说明该消息是由于耳机发生了抖动而产生的耳机状态改变消息，放弃对该消息的处理，设置消息处理异常标志。

新增的其他与器件相关的消息处理流程在本例中指的就是耳机按键状态改变消息的处理流程。如图6所示，在步骤610中，由底层驱动模块实施检测耳机按键状态，一旦检测到耳机按键状态发生改变，就进入步骤620。

在步骤620中，底层驱动模块向上层应用模块上报耳机按键状态改变消息。接着，进入步骤630。

在步骤630中，上层应用模块接收耳机按键状态改变消息。接着，进入步骤640。

在步骤640中，上层应用模块判断耳机的当前状态是否为所期待的状态。因为耳机的当前状态已由底层驱动模块记录下来，如果是记录在底层驱动模块，上层应用模块通过与底层驱动模块的交互就可以查询耳机被记录的当前状态；如果是记录在公共存储区或寄存器，上层应用模块通过从公共存储区或寄存器直接读取相应的数据，就可以查询耳机被记录的当前状态。由于处理耳机按键状态改变消息时所期待的状态是耳机插入状态，所以，在本步骤中，上层应用模块就是要判断查询到的耳机当前状态是否为插入状态。如果是，就进入步骤650；如果不是，就结束本流程，也就是不对该消息进行处理。

在步骤650中，上层应用模块按照耳机按键状态改变消息的内容正常处理该消息。

本实施例中，在处理与某个器件相关的消息时，先对其相关器件的当前状态进行确认，如果是所期待的状态，就正常处理该消息；如果不是所期待的状态，就放弃对该消息的处理。以此来提高系统的健壮性以及系统对消息处理的正确性。

虽然通过参照本发明的某些优选实施例，已经对本发明进行了图示和描述，但本领域的普通技术人员应该明白，可以在形式上和细节上对其作各种改变，而不偏离本发明的精神和范围。

Claims (7)

1.一种器件状态改变消息的处理方法，涉及用于实时检测器件状态的底层驱动模块和处理器件状态改变消息的上层应用模块，其特征在于，所述方法包含以下步骤：

A当所述底层驱动模块检测到器件的状态发生变化时，记录该器件的当前状态，向所述上层应用模块上报器件状态改变消息，所述器件的状态只有两个状态；

B所述上层应用模块处理状态改变消息时，先查看是否有消息处理异常标志，如果是则放弃该消息的处理并清除消息处理异常标志；如果否，则查询该器件被记录的当前状态，比较查询结果和被处理消息所期望的状态，如果不一致则直接丢弃下一条所述底层驱动模块上报的器件状态改变消息。

2.根据权利要求1所述的器件状态改变消息的处理方法，其特征在于，所述步骤A中，所述底层驱动模块将所述器件的当前状态记录在本地；

所述步骤B中，所述上层应用模块通过与所述底层驱动模块的交互，查询所述器件被记录的当前状态。

3.根据权利要求1所述的器件状态改变消息的处理方法，其特征在于，所述步骤A中，所述底层驱动模块将所述器件的当前状态记录在所述上层应用模块可以访问的公共存储区或寄存器；

所述步骤B中，所述上层应用模块通过从所述公共存储区或寄存器直接读取相应的数据，查询所述器件被记录的当前状态。

4.根据权利要求1至3中任一项所述的器件状态改变消息的处理方法，其特征在于，所述步骤B中，如果所述查询结果和被处理消息所期望的状态一致，则所述上层应用模块正常处理所述消息。

5.根据权利要求4所述的器件状态改变消息的处理方法，其特征在于，所述器件可以是用户身份鉴别模件或用户服务识别模块，该器件的状态可以是在位和不在位两种。

6.根据权利要求4所述的器件状态改变消息的处理方法，其特征在于，所述器件可以是耳机，该器件的状态可以是插入和未插入两种。

7.根据权利要求6所述的器件状态改变消息的处理方法，其特征在于，所述步骤B中，所述状态改变消息可以是耳机按键状态改变消息，查询的该器件被记录的当前状态可以是耳机插入或未插入状态，所述耳机按键状态改变消息所期望的状态是耳机插入状态，如果查询结果是耳机未插入状态，则忽略当前的耳机按键状态改变消息。

Images