CN105306497A - 应用程序中用户界面ui与模型层数据交互的方法和装置 - Google Patents

Abstract

本发明实施例提供了一种应用程序中用户界面UI与模型层数据交互的方法及装置，所述方法包括：所述UI线程接收所述工作线程发送的消息处理通知；所述UI线程依据所述消息处理通知获取所述消息数据；所述UI线程采用所述消息数据更新所述用户界面UI。本发明实施例使得UI线程能够根据数据模型变化时更新界面，而不必使用线程间复杂同步机制来实现界面更新。在模型层数据发生变化时，可以通过内部维护的消息处理队列转发到UI线程中进行界面更新，不仅简化了实现逻辑，同时也解耦了用户界面UI与数据模型层，因此更加容易适应可扩放性和更为动态的网络拓扑。

Description

应用程序中用户界面UI与模型层数据交互的方法和装置

技术领域

本发明涉及应用程序技术领域，特别是涉及一种应用程序中用户界面UI与模型层数据交互的方法和一种应用程序中用户界面UI与模型层数据交互的装置。

背景技术

应用程序中的UI(UserInterface，用户界面)亦称使用者界面，是应用程序和用户之间进行交互和信息交换的媒介，它实现信息的内部形式与用户可以接受形式之间的转换。

应用程序的程序架构利用模型层来抽象应用程序中更新用户界面UI用到的所有数据，一般将与用户交互操作的用户界面UI与实际数据分开来处理，实际数据可能来自网络、本地数据库、配置文件等。这种分开处理的方式能有效地应用处理逻辑与用户界面UI交互的耦合关系。通常所有用户界面UI的操作必须在主线程中完成，而实际数据的读取会建立对应的线程，此时不仅需要实现在用户界面UI与数据模型的通信机制，还需要考虑跨线程传递消息的问题。目前的解决的方式是通过自定义的窗口消息来完成线程传递消息，但是自定义的窗口消息实现用户界面UI与模型层数据通信机制存在以下问题：

1)不同种类消息需定义一个不与应用程序中其它窗口冲突的消息号，维护比较麻烦。

2)消息只能使用两个32位整型数据传递，如果采用其它数据类型传递还需要考虑内存释放问题，很容易造成内存泄漏。

3)必须知道目标窗口的句柄才能正确发送消息。

4)若要增加消息需要改动原有代码，不符合开闭原则。

因此，目前需要本领域技术人员迫切解决的一个技术问题就是：提出一种应用程序中用户界面UI与模型层数据交互的通信机制，使得UI线程能够根据数据模型变化时更新界面，而不必使用线程间复杂同步机制来实现界面更新。在模型层数据发生变化时，可以通过内部维护的消息处理队列转发到UI线程中进行界面更新，不仅简化了实现逻辑，同时也解耦了用户界面UI与数据模型层，因此更加容易适应可扩放性和更为动态的网络拓扑。

发明内容

本发明实施例所要解决的技术问题是提供一种应用程序中用户界面UI与模型层数据交互的方法，使得UI线程能够根据数据模型变化时更新界面，而不必使用线程间复杂同步机制来实现界面更新。在模型层数据发生变化时，可以通过内部维护的消息处理队列转发到UI线程中进行界面更新，不仅简化了实现逻辑，同时也解耦了用户界面UI与数据模型层，因此更加容易适应可扩放性和更为动态的网络拓扑。

相应的，本发明实施例还提供了一种应用程序中用户界面UI与模型层数据交互的装置，用以保证上述方法的实现及应用。

为了解决上述问题，本发明公开了一种应用程序中用户界面UI与模型层数据交互的方法，所述应用程序中还包括工作线程，所述用户界面UI中包括UI线程，所述工作线程用于获取所述模型层数据的消息数据，并用于依据所述消息数据后生成消息处理通知；

所述方法包括：

所述UI线程接收所述工作线程发送的消息处理通知；

所述UI线程依据所述消息处理通知获取所述消息数据；

所述UI线程采用所述消息数据更新所述用户界面UI。

优选地，所述工作线程中包括主题TOPIC对象，所述主题TOPIC对象中包括消息处理队列，所述工作线程获取的消息数据保存于所述主题TOPIC对象的消息处理队列中，所述消息处理通知中包括所述消息数据对应的消息标识，所述UI线程依据所述消息处理通知获取所述消息数据的步骤包括：

所述UI线程针对所述消息处理通知发送消息获取请求至所述主题TOPIC对象；所述消息获取请求中包括消息标识，所述主题TOPIC对象用于在所述消息处理队列中查找与所述消息标识对应的消息数据；

所述UI线程接收所述主题TOPIC对象针对所述消息标识发送的消息数据；

优选地，在所述UI线程依据所述消息处理通知获取所述消息数据的步骤之后，还包括：

所述UI线程针对所述消息处理通知发送消息确认响应至所述工作线程。

优选地，所述消息数据具有不允许修改的属性。

本发明实施例还公开了一种应用程序中用户界面UI与模型层数据交互的方法，所述应用程序中还包括工作线程，所述用户界面UI中包括UI线程，所述方法包括：

所述工作线程从所述模型层数据中获取消息数据；

所述工作线程针对所述消息数据向所述UI线程发送消息处理通知；

所述工作线程接收所述UI线程针对所述消息处理通知发送的消息获取请求；

所述工作线程针对所述消息获取请求向所述UI线程发送消息数据。

优选地，所述消息获取请求中包括所述消息数据对应的消息标识，所述工作线程中包括主题TOPIC对象，所述主题TOPIC对象中包括消息处理队列，所述工作线程接收的消息数据保存于所述主题TOPIC对象的消息处理队列中，所述消息处理队列的各个表项中包括消息标识及对应的消息数据，若所述主题TOPIC对象为采用升序的方式生成所述消息标识，所述工作线程针对所述消息获取请求向所述UI线程发送消息数据的步骤包括：

子步骤S11，所述主题TOPIC对象在所述消息处理队列的中间位置查找是否存在所述消息标识的匹配项；若是，则执行子步骤S12，若否，则执行子步骤S13；

子步骤S12，所述主题TOPIC对象获取所述消息标识对应的消息数据，并发送至所述UI线程；

子步骤S13，所述主题TOPIC对象判断所述消息标识是否大于所述消息处理队列的中间位置的消息标识；若是，则执行子步骤S14，若否，则执行子步骤S15；

子步骤S14，所述主题TOPIC对象在所述消息处理队列的中间位置之前的表项作为消息处理队列，并返回子步骤S11；

子步骤S15，所述主题TOPIC对象在所述消息处理队列的中间位置之后的表项作为消息处理队列，并返回子步骤S11。

本发明实施例还公开了一种应用程序中用户界面UI与模型层数据交互的装置，所述应用程序中还包括工作线程，所述用户界面UI中包括UI线程，所述工作线程用于获取所述模型层数据的消息数据，并用于依据所述消息数据后生成消息处理通知；

所述装置包括：

位于UI线程的接收模块，用于接收所述工作线程发送的消息处理通知；

位于UI线程的获取模块，用于依据所述消息处理通知获取所述消息数据；

位于UI线程的更新收模块，用于采用所述消息数据更新所述用户界面UI。

优选地，所述工作线程中包括主题TOPIC对象，所述主题TOPIC对象中包括消息处理队列，所述工作线程获取的消息数据保存于所述主题TOPIC对象的消息处理队列中，所述消息处理通知中包括所述消息数据对应的消息标识，所述位于UI线程的获取模块包括：

位于UI线程的发送子模块，用于针对所述消息处理通知发送消息获取请求至所述主题TOPIC对象；所述消息获取请求中包括消息标识，所述主题TOPIC对象用于在所述消息处理队列中查找与所述消息标识对应的消息数据；

位于UI线程的接收子模块，用于接收所述主题TOPIC对象针对所述消息标识发送的消息数据；

优选地，所述装置还包括：

位于UI线程的发送模块，用于针对所述消息处理通知发送消息确认响应至所述工作线程。

本发明实施例还公开了一种应用程序中用户界面UI与模型层数据交互的装置，所述应用程序中还包括工作线程，所述用户界面UI中包括UI线程，所述装置包括：

位于工作线程的第一接收模块，用于从所述模型层数据中获取消息数据；

位于工作线程的第一发送模块，用于针对所述消息数据向所述UI线程发送消息处理通知；

位于工作线程的第二接收模块，用于接收所述UI线程针对所述消息处理通知发送的消息获取请求；

位于工作线程的第二发送模块，用于针对所述消息获取请求向所述UI线程发送消息数据。

与现有技术相比，本发明实施例包括以下优点：

在本发明实施例中，将用以更新用户界面UI的消息数据的发布者(工作线程)，以及，预定所述消息数据的预订者(UI线程)独立开来，使得各个模块解耦，便于适用用户需求的不断变化，因此提高应用程序的性能，并且较容易维护。

此外，使用闭包技术保证在消息数据接收时不至于由于运行环境变化引起消息处理的不确定性问题，提高了系统的安全性。另外，实现上采用了对有序表的二分查找方式，运行效率高。

附图说明

图1是本发明的一种应用程序中用户界面UI与模型层数据交互的方法实施例1的步骤流程图；

图2是本发明的一种发布/订阅式的消息发送的示意图；

图3是本发明的一种发布/订阅式的消息发送的流程图；

图4是本发明的一种应用程序的线程工作流程图；

图5是本发明的一种应用程序中用户界面UI与模型层数据交互的方法实施例2的步骤流程图；

图6是本发明的一种应用程序中用户界面UI与模型层数据交互的装置实施例1的结构框图；

图7是本发明的一种应用程序中用户界面UI与模型层数据交互的装置实施例2的结构框图。

具体实施方式

为使本发明的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本发明作进一步详细的说明。

本发明实施例的核心构思之一在于，在本发明实施例中，将用以更新用户界面UI的消息数据的发布者(工作线程)，以及，预定所述消息数据的预订者(UI线程)独立开来，使得各个模块解耦，便于适用用户需求的不断变化，因此提高应用程序的性能，并且较容易维护。此外，使用闭包技术保证在消息数据接收时不至于由于运行环境变化引起消息处理的不确定性问题，提高了系统的安全性。

参照图1，示出了本发明的一种应用程序中用户界面UI与模型层数据交互的方法实施例1的步骤流程图，所述应用程序中还可以包括工作线程，所述用户界面UI中可以包括UI线程，所述工作线程可以用于获取所述模型层数据的消息数据，并用于依据接收所述消息数据后生成消息处理通知；

所述方法具体可以包括如下步骤：

步骤101，所述UI线程接收所述工作线程发送的消息处理通知；

在具体实现中，应用程序的程序架构利用模型层来抽象应用程序中用到的所有消息数据，这些消息数据有些来自本地数据库，有些来自网络通信，例如在网络通过HTTP(HyperTextTransportProtocol，超文本传输协议)、FTP(FileTransferProtocol，文件传输协议)、XMPP(ExtensibleMessageingandPresenceProtocol，可扩展消息与存在协议)等协议发送消息，有些消息数据则可能来自应用程序所在机器的其它进程。

在本发明实施例中，当工作线程获取并发送模型层数据的消息数据至消息处理队列后，则可以通知相应的UI线程接收所述消息数据。

在本发明的一种优选实施例中，所述工作线程中可以包括主题TOPIC对象，所述主题TOPIC对象中可以包括消息处理队列，所述工作线程获取的消息数据可以保存于所述主题TOPIC对象的消息处理队列中，所述消息处理通知中可以包括所述消息数据对应的消息标识，所述步骤101具体可以包括如下子步骤：

子步骤101-1，所述UI线程针对所述消息处理通知发送消息获取请求至所述主题TOPIC对象；所述消息获取请求中包括消息标识，所述主题TOPIC对象用于在所述消息处理队列中查找与所述消息标识对应的消息数据；

子步骤101-2，所述UI线程接收所述主题TOPIC对象针对所述消息标识发送的消息数据；

在本发明实施例中，使用JMS(JavaMessagingService，Java消息服务)主题TOPIC对象实现publisher/subscribe(发布/订阅式)的消息数据发送。发布/订阅式是一种消息范式，消息的发送者(发布者)不是计划发送其消息给特定的接收者(预订者)。将发布的消息分为不同的类别，而不需要知道什么样的预订者订阅。预订者对一个或多个类别表达兴趣，于是只接收感兴趣的消息，而不需要知道什么样的发布者发布的消息。使得发布者和预订者的解耦，可以允许更好的可扩放性和更为动态的网络拓扑。

参照图2所示的本发明的一种发布/订阅式的消息发送的示意图，在本示例的JMS的发布/订阅式中，工作线程可以为JMS发布者，UI线程可以作为JMS预订者，消息处理队列为JMS提供者，其中JMS提供者可以认为是介于发布者和预订者之间。JMS发布者利用方法调用将每条消息数据发送给多个JMS预订者，具体地，JMS发布者发送消息数据到JMS提供者，JMS预订者从JMS提供者接收消息数据。

参照图3所示的本发明的一种发布/订阅式的消息发送的流程图，在本示例的JMS的在JMS的发布/订阅式中，消息发送使用JMS管理的主题TOPIC对象来管理JMS发布者到JMS预订者的消息流。JMS发布者又叫做消息生产者，而JMS预订者又叫做消息消费者。消息生产者获得JMS主题TOPIC对象的引用，并向该主题TOPIC对象发送消息数据。当消息数据到达时，通知所有预订了该主题TOPIC对象的消息消费者。

采用JMS主题TOPIC对象的发布/订阅式具有松耦合的特点。具体地，JMS发布者与JMS预定者松散地耦合，并且不需要知道对方的存在，即两者是互相独立的。由于主题TOPIC对象是被关注的，JMS发布者和JMS预定者可以对系统拓扑毫无所知。JMS发布者和JMS预订者都可以继续正常操作，不管对方状态如何。在传统的紧耦合的范式中，在服务器进程不运行时，发布者无法发送消息给服务器，服务器也无法在发布者不运行时接收消息。许多发布/订阅式系统不单解耦JMS发布者和JMS预订者的位置，还从时间上解耦JMS发布者和JMS预订者。

发布/订阅式的消息发送是一对多的，发布的消息只递送给主题TOPIC对象当前的预订者。JMS提供者存储由于JMS预订者出于某种原因不可用而无法递送给JMS预订者的消息。在下次JMS预订者连接上的时候，这些存储的消息将会被递送。这确保了JMS预订者预订一个主题TOPIC对象之后，所有发布的消息都会保证递送，哪怕该JMS预订者不是总在运行。不然，在JMS预订者掉线时，发布的任何消息都不会递送到JMS预订者。

当然，在本发明实施例中还可以采用JMS队列Queue进行点到点的消息发送，以及其他消息发送方式，本发明实施例对此不作限制。

步骤102，所述UI线程依据所述消息处理通知获取所述消息数据；

在本发明实施例中，当UI线程接收到所述消息处理通知时，将相应到工作线程中的消息处理队列中去获取消息数据。在实际应用中，工作线程也可以在接收到消息数据时直接将其发送至对应UI线程，以提高系统的处理效率。

需要说明的是，在本发明实施例中还可以通过自定义的窗口消息来完成消息发送。具体地，定义一组窗口消息，当工作线程需要发送消息时，使用自定义窗口消息向之前注册的窗口句柄发送消息，其中，在对应窗口中在消息处理函数中增加代码，用以处理自定义窗口消息，根据消息内容更新用户界面等，本发明实施例对此不作限制。

在本发明的一种优选实施例中，在所述步骤102之后，还可以包括如下步骤：

所述UI线程针对所述消息处理通知发送消息确认响应至所述工作线程。

可选地，当UI线程获取到消息数据后，可以向工作线程发送接收到消息数据的响应消息，表示已经接收到了消息数据，工作线程则以将该消息数据从消息处理队列中删除。

步骤103，所述UI线程采用所述消息数据更新所述用户界面UI。

在本发明的一种优选实施例中，所述消息数据可以具有不允许修改的属性。

为了保证在消息数据接收时UI线程不至于由于运行环境变化引起消息处理的不确定性问题，故消息数据不允许随便进行修改。具体而言，在本发明实施例中，可以使用闭包技术保证在消息数据接收时不被随意修改，以遵循开闭原则。

开闭原则是面向对象设计中最重要的原则之一，其它很多的设计原则都是实现开闭原则的一种手段。遵循开闭原则设计出的模块具有两个主要特征：

(1)对于扩展是开放的(Openforextension)。这意味着模块的行为是可以扩展的。当应用程序的需求改变时，可以对模块进行扩展，使其具有满足那些改变的新行为。也就是说，可以改变模块的功能。

(2)对于修改是关闭的(Closedformodification)。对模块行为进行扩展时，不必改动模块的源代码或者二进制代码。模块的二进制可执行版本，无论是可链接的库、DLL或者.EXE文件，都无需改动。

如果一个程序或软件系统符合开闭原则的，至少具有如下的好处：

(1)可复用性好。

当完成以后，仍然可以对软件进行扩展，加入新的功能，非常灵活。因此，这个软件系统就可以通过不断地增加新的组件，来满足不断变化的需求。

(2)可维护性好。

由于对于已有的软件系统的组件，特别是它的抽象底层不去修改，因此，不用担心系统中原有组件的稳定性，这就使变化中的系统有一定的稳定性和延续性。

开闭原则是面向对象设计的终极目标。开闭原则的实现方式有里氏代换原则、依赖倒转原则、接口隔离原则以及抽象类(AbstractClass)、接口(Interface)等等，都可以看作是开闭原则的实现方法。

综和可知，在应用程序中包含的各种组件，例如模块(Modules)、类(Classes)以及功能(Functions)等等，应该在不修改现有代码的基础上，引入新功能。开闭原则中“开”，是指对于组件功能的扩展是开放的，是允许对其进行功能扩展的；开闭原则中“闭”，是指对于原有代码的修改是封闭的，即不应该修改原有的代码。

当然，在本发明实施例中也可以采用其他方式来实现消息的不能随意被修改，例如可以在UI线程侧及工作线程侧设置加密或完整性算法，若UI线程采用所述加密或完整性算法发现消息被修改，则禁止使用该消息更新用户界面UI，保证系统的数据安全。

为了使本领域技术人员进一步理解本发明实施例，以下采用具体的示例进行说明。

参照图4所示的本发明的一种应用程序的线程工作流程图，假设应用程序通过FTP(FileTransferProtocol，文件传输协议)从站点下载一个较大文件(可能需要十几分钟才能下载完成)。这时工作线程会在不同状态发出消息至其的主题TOPIC对象，其中，消息可以保存在主题TOPIC对象的消息处理队列中。

UI线程接收到工作线程发送的处理通知后，可以到主题TOPIC对象的消息处理队列中去查找匹配的消息，以及，获取所述匹配的消息对应的处理函数，再根据消息及处理函数更新界面。例如更新界面提示，让用户实时知道：开始下载了、下载正在进行中、下载完成或下载出错。

参照图5，示出了本发明的一种应用程序中用户界面UI与模型层数据交互的方法实施例2的步骤流程图，所述应用程序中还可以包括工作线程，所述用户界面UI中可以包括UI线程；

所述方法具体可以包括如下步骤：

步骤201，所述工作线程从所述模型层数据中获取消息数据；

步骤202，所述工作线程针对所述消息数据向所述UI线程发送消息处理通知；

步骤203，所述工作线程接收所述UI线程针对所述消息处理通知发送的消息获取请求；

步骤204，所述工作线程针对所述消息获取请求向所述UI线程发送消息数据。

在本发明的一种优选实施例中，所述消息获取请求中可以包括所述消息数据对应的消息标识，所述工作线程中可以包括主题TOPIC对象，所述主题TOPIC对象中可以包括消息处理队列，所述工作线程接收的消息数据可以保存于所述主题TOPIC对象的消息处理队列中，所述消息处理队列的各个表项中包括消息标识及对应的消息数据，若所述主题TOPIC对象为采用升序的方式生成所述消息标识，所述步骤204可以包括如下子步骤：

子步骤S11，所述主题TOPIC对象在所述消息处理队列的中间位置查找是否存在所述消息标识的匹配项；若是，则执行子步骤S12，若否，则执行子步骤S13；

子步骤S12，所述主题TOPIC对象获取所述消息标识对应的消息数据，并发送至所述UI线程；

子步骤S13，所述主题TOPIC对象判断所述消息标识是否大于所述消息处理队列的中间位置的消息标识；若是，则执行子步骤S14，若否，则执行子步骤S15；

子步骤S14，所述主题TOPIC对象在所述消息处理队列的中间位置之前的表项作为消息处理队列，并返回子步骤S11；

子步骤S15，所述主题TOPIC对象在所述消息处理队列的中间位置之后的表项作为消息处理队列，并返回子步骤S11。

在本发明实施例中，可以采用二分查找的方式在消息处理队列中查找对应的消息。二分查找又称为折半查找，其优点是比较次数少，查找速度快，平均性能好，折半查找方法比较适用于有序列表。

具体而言，假设消息队列的列表中元素是按升序排列，将列表中间位置记录的关键字(消息标识)与查找关键字比较，如果两者相等，则查找成功；否则利用中间位置记录将列表分成前、后两个子列表，如果中间位置记录的关键字大于查找关键字，则进一步查找前一子列表，否则进一步查找后一子列表。重复以上过程，直到找到满足条件的记录，消息查找成功，或直到子列表不存在为止，此时消息查找不成功。

在具体实现中，如果在消息处理队列中消息数据按降序排列，则将列表中间位置记录的关键字与查找关键字比较，如果两者相等，则查找成功；否则利用中间位置记录将列表分成前、后两个子列表，如果中间位置记录的关键字大于查找关键字，则进一步查找后一子列表，否则进一步查找前一子列表。重复以上过程，直到找到满足条件的记录，消息查找成功，或直到子列表不存在为止，此时消息查找不成功。

当然，在实际中也可以采用其他方式在消息处理队列的队列中进行查找，按降序或者升序逐个进行查找，本发明实施例对此不作限制。

本发明实施例采用发布/订阅模型结合仿函数将消息数据的发布者与接收者独立开来，另外使用闭包技术保证在消息数据接收时不至于由于运行环境变化引起消息数据处理的不确定性问题。另外，实现上采用了对有序表的二分查找，运行效率高。

应用本发明实施例，可以使得UI线程能够根据数据模型变化时更新界面，而不必使用线程间复杂同步机制来实现界面更新。在模型层数据发生变化时，可以通过内部维护的消息处理队列转发到UI线程中进行界面更新，不仅简化了实现逻辑，同时也解耦了用户界面UI与数据模型层，因此更加容易适应可扩放性和更为动态的网络拓扑。

需要说明的是，对于方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明实施例并不受所描述的动作顺序的限制，因为依据本发明实施例，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作并不一定是本发明实施例所必须的。

参照图6，示出了本发明一种应用程序中用户界面UI与模型层数据交互的装置实施例1的结构框图，所述应用程序中还可以包括工作线程，所述用户界面UI中可以包括UI线程，所述工作线程可以用于获取所述模型层数据的消息数据，并用于依据所述消息数据后生成消息处理通知；

所述装置具体可以包括如下模块：

位于UI线程的接收模块601，用于接收所述工作线程发送的消息处理通知；

在本发明的一种优选实施例中，所述消息数据可以具有不允许修改的属性。

位于UI线程的获取模块602，用于依据所述消息处理通知获取所述消息数据；

位于UI线程的更新收模块603，用于采用所述消息数据更新所述用户界面UI。

在本发明的一种优选实施例中，所述工作线程中可以包括主题TOPIC对象，所述主题TOPIC对象中可以包括消息处理队列，所述工作线程获取的消息数据可以保存于所述主题TOPIC对象的消息处理队列中，，所述消息处理通知中包括所述消息数据对应的消息标识，所述位于UI线程的获取模块602可以包括：

位于UI线程的发送子模块，用于针对所述消息处理通知发送消息获取请求至所述主题TOPIC对象；所述消息获取请求中包括消息标识，所述主题TOPIC对象用于在所述消息处理队列中查找与所述消息标识对应的消息数据；

位于UI线程的接收子模块，用于接收所述主题TOPIC对象针对所述消息标识发送的消息数据；

在本发明的一种优选实施例中，所述装置还可以包括：

位于UI线程的发送模块，用于针对所述消息处理通知发送消息确认响应至所述工作线程。

参照图7，示出了本发明一种应用程序中用户界面UI与模型层数据交互的装置实施例2的结构框图，所述应用程序中还可以包括工作线程，所述用户界面UI中可以包括UI线程；

所述装置具体可以包括如下模块：

位于工作线程的第一接收模块701，用于从所述模型层数据中获取消息数据；

位于工作线程的第一发送模块702，用于针对所述消息数据向所述UI线程发送消息处理通知；

位于工作线程的第二接收模块703，用于接收所述UI线程针对所述消息处理通知发送的消息获取请求；

位于工作线程的第二发送模块704，用于针对所述消息获取请求向所述UI线程发送消息数据。

在本发明的一种优选实施例中，所述消息获取请求中可以包括所述消息数据对应的消息标识，所述工作线程中可以包括主题TOPIC对象，所述主题TOPIC对象中可以包括消息处理队列，所述工作线程接收的消息数据可以保存于所述主题TOPIC对象的消息处理队列中，所述消息处理队列的各个表项中可以包括消息标识及对应的消息数据，若所述主题TOPIC对象为采用升序的方式生成所述消息标识，所述位于工作线程的第二发送模块704可以包括：

位于工作线程的查找子模块，用于所述主题TOPIC对象在所述队列的中间位置查找是否存在所述消息标识的匹配项；若是，则调用位于工作线程的消息获取子模块，若否，则调用位于工作线程的标识判定子模块；

位于工作线程的消息获取子模块，用于所述主题TOPIC对象获取所述消息标识对应的消息数据，并发送至所述UI线程；

位于工作线程的标识判定子模块，用于所述主题TOPIC对象判断所述消息标识是否大于所述消息处理队列的中间位置的消息标识；若是，则调用位于工作线程的第一返回子模块，若否，则调用位于工作线程的第二返回子模块；

位于工作线程的第一返回子模块，用于所述主题TOPIC对象在所述队列的中间位置之前的表项作为队列，并返回子步骤S11；

位于工作线程的第二返回子模块，用于所述主题TOPIC对象在所述队列的中间位置之后的表项作为队列，并返回位于工作线程的查找子模块。

对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

本领域内的技术人员应明白，本发明实施例的实施例可提供为方法、装置、或计算机程序产品。因此，本发明实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明实施例是参照根据本发明实施例的方法、终端设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理终端设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理终端设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理终端设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理终端设备上，使得在计算机或其他可编程终端设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程终端设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本发明实施例的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明实施例范围的所有变更和修改。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的相同要素。

以上对本发明所提供的一种应用程序中用户界面UI与模型层数据交互的方法和一种应用程序中用户界面UI与模型层数据交互的装置，进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。

Claims (10)

1.一种应用程序中用户界面UI与模型层数据交互的方法，其特征在于，所述应用程序中还包括工作线程，所述用户界面UI中包括UI线程，所述工作线程用于获取所述模型层数据的消息数据，并用于依据所述消息数据后生成消息处理通知；

所述方法包括：

所述UI线程接收所述工作线程发送的消息处理通知；

所述UI线程依据所述消息处理通知获取所述消息数据；

所述UI线程采用所述消息数据更新所述用户界面UI。

2.根据权利要求1所述的方法，其特征在于，所述工作线程中包括主题TOPIC对象，所述主题TOPIC对象中包括消息处理队列，所述工作线程获取的消息数据保存于所述主题TOPIC对象的消息处理队列中，所述消息处理通知中包括所述消息数据对应的消息标识，所述UI线程依据所述消息处理通知获取所述消息数据的步骤包括：

所述UI线程针对所述消息处理通知发送消息获取请求至所述主题TOPIC对象；所述消息获取请求中包括消息标识，所述主题TOPIC对象用于在所述消息处理队列中查找与所述消息标识对应的消息数据；

所述UI线程接收所述主题TOPIC对象针对所述消息标识发送的消息数据。

3.根据权利要求1所述的方法，其特征在于，在所述UI线程依据所述消息处理通知获取所述消息数据的步骤之后，还包括：

所述UI线程针对所述消息处理通知发送消息确认响应至所述工作线程。

4.根据权利要求1或2或3所述的方法，其特征在于，所述消息数据具有不允许修改的属性。

5.一种应用程序中用户界面UI与模型层数据交互的方法，其特征在于，所述应用程序中还包括工作线程，所述用户界面UI中包括UI线程，所述方法包括：

所述工作线程从所述模型层数据中获取消息数据；

所述工作线程针对所述消息数据向所述UI线程发送消息处理通知；

所述工作线程接收所述UI线程针对所述消息处理通知发送的消息获取请求；

所述工作线程针对所述消息获取请求向所述UI线程发送消息数据。

6.根据权利要求5所述的方法，其特征在于，所述消息获取请求中包括所述消息数据对应的消息标识，所述工作线程中包括主题TOPIC对象，所述主题TOPIC对象中包括消息处理队列，所述工作线程接收的消息数据保存于所述主题TOPIC对象的消息处理队列中，所述消息处理队列的各个表项中包括消息标识及对应的消息数据，若所述主题TOPIC对象为采用升序的方式生成所述消息标识，所述工作线程针对所述消息获取请求向所述UI线程发送消息数据的步骤包括：

子步骤S11，所述主题TOPIC对象在所述消息处理队列的中间位置查找是否存在所述消息标识的匹配项；若是，则执行子步骤S12，若否，则执行子步骤S13；

子步骤S12，所述主题TOPIC对象获取所述消息标识对应的消息数据，并发送至所述UI线程；

子步骤S13，所述主题TOPIC对象判断所述消息标识是否大于所述消息处理队列的中间位置的消息标识；若是，则执行子步骤S14，若否，则执行子步骤S15；

子步骤S14，所述主题TOPIC对象在所述消息处理队列的中间位置之前的表项作为消息处理队列，并返回子步骤S11；

子步骤S15，所述主题TOPIC对象在所述消息处理队列的中间位置之后的表项作为消息处理队列，并返回子步骤S11。

7.一种应用程序中用户界面UI与模型层数据交互的装置，其特征在于，所述应用程序中还包括工作线程，所述用户界面UI中包括UI线程，所述工作线程用于获取所述模型层数据的消息数据，并用于依据所述消息数据后生成消息处理通知；

所述装置包括：

位于UI线程的接收模块，用于接收所述工作线程发送的消息处理通知；

位于UI线程的获取模块，用于依据所述消息处理通知获取所述消息数据；

位于UI线程的更新收模块，用于采用所述消息数据更新所述用户界面UI。

8.根据权利要求7所述的装置，其特征在于，所述工作线程中包括主题TOPIC对象，所述主题TOPIC对象中包括消息处理队列，所述工作线程获取的消息数据保存于所述主题TOPIC对象的消息处理队列中，所述消息处理通知中包括所述消息数据对应的消息标识，所述位于UI线程的获取模块包括：

位于UI线程的发送子模块，用于针对所述消息处理通知发送消息获取请求至所述主题TOPIC对象；所述消息获取请求中包括消息标识，所述主题TOPIC对象用于在所述消息处理队列中查找与所述消息标识对应的消息数据；

位于UI线程的接收子模块，用于接收所述主题TOPIC对象针对所述消息标识发送的消息数据。

9.根据权利要求7所述的装置，其特征在于，还包括：

位于UI线程的发送模块，用于针对所述消息处理通知发送消息确认响应至所述工作线程。

10.一种应用程序中用户界面UI与模型层数据交互的装置，其特征在于，所述应用程序中还包括工作线程，所述用户界面UI中包括UI线程，所述装置包括：

位于工作线程的第一接收模块，用于从所述模型层数据中获取消息数据；

位于工作线程的第一发送模块，用于针对所述消息数据向所述UI线程发送消息处理通知；

位于工作线程的第二接收模块，用于接收所述UI线程针对所述消息处理通知发送的消息获取请求；

位于工作线程的第二发送模块，用于针对所述消息获取请求向所述UI线程发送消息数据。