CN112188224B - 界面消息流控制方法、装置、设备及存储介质 - Google Patents

Abstract

本申请公开界面消息流控制方法、装置、设备及存储介质，所述的方法包括：持续接收符合同一协议规范的不同类型的界面消息，按序将界面消息添加到消息队列中；依据队列规则按序从消息队列中获取界面消息，将该界面消息转换为界面对象，其中界面消息的类型信息被转换为界面对象的视图层索引；适应每一界面对象，根据其视图层索引从图形用户界面的多个视图层中选定一个目标视图层，在该目标视图层中输出显示所述界面对象。本申请实现了一种有序处理大量界面消息的解决方案，实现对图形用户界面的纵深方向上的不同层级的视图层的集中有序调度利用，有助于提升该类应用程序的开发效率，可以降低运行设备的运行压力。

Description

界面消息流控制方法、装置、设备及存储介质

技术领域

本申请涉及计算机控制技术领域，尤其涉及一种界面消息流控制方法、装置、设备及存储介质。

背景技术

随着网络技术的发展，人们在线上娱乐项目越来越多，近年来直播节目逐渐走进大众视野，尤其一些优秀的主播直播的节目更是受观众的喜爱。在直播间，当主播的表演到精彩之处时，观众往往会通过给主播留言，送礼等行为表示对节目的喜爱。在直播间业务场景中，直播间内根据实际业务展示各种动效或者广播各种通知来反馈和刺激用户在直播间内的积极行为，如响应于用户向主播送礼的操作而播放精美的动效给予视觉上的反馈，对于送礼或者做任务的操作结果给予精美动效或者直播间播放广播等的视觉反馈，通过这些动效肯定用户的付出及激发用户在直播间交互的积极性，从而提高观众在观赏直播节目的体验度。同理，平台方也常会向直播间用户发送各种通知，这些通过以广播的形式同样送达用户界面进行展示。

目前直播间业务场景中，当多种类型的界面消息在终端设备并发时，直播间接收到繁多的各类型的界面消息无法有序的处理，且无法协调处理各类型的界面消息在直播间图形用户界面的显示，繁多的界面消息堆积在设备缓存中，可能导致直播间应用程序在终端设备运行时发生崩溃。

另外，由于现有技术没有一个通用性强、扩展性强的队列管理模块，由此不同的开发团队提供的不同类型的界面消息分别建立自己对应的队列管理模块，同时也需要投入人力物力去支持新的相关业务的视图管理模块，随着业务不断增加，维护成本也会不断增高，且繁多的队列管理模块及视图管理模块，导致直播间应用程序占用终端设备的大量内存，同时也将使繁多的界面消息繁杂错乱显示在直播间图形用户界面中。

可见，现有技术中无法有效的有序地处理并发的多种类型的界面消息，将导致界面消息在直播间图形用户界面中繁乱显示，亟待业内开发有效的解决方案。

发明内容

本申请的首要目的旨在提供一种界面消息流控制方法，以便有序处理任一界面消息。

作为本申请的另一目的，提供一种与前述的方法相适应的界面消息流控制装置、电子设备、非易失性存储介质。

为满足本申请的各个目的，本申请采用如下技术方案：

适应本申请的首要目的而提供的一种界面消息流控制方法，包括如下步骤：

持续接收符合同一协议规范的不同类型的界面消息，按序将界面消息添加到消息队列中；

依据队列规则按序从消息队列中获取界面消息，将该界面消息转换为界面对象，其中界面消息的类型信息被转换为界面对象的视图层索引；

适应每一界面对象，根据其视图层索引从图形用户界面的多个视图层中选定一个目标视图层，在该目标视图层中输出显示所述界面对象。

部分实施例中，按序将界面消息添加到消息队列的步骤中，存在多个与界面消息的不同类型一一对应的消息队列，界面消息按照其不同类型被添加到对应的消息队列中，各消息队列被并行处理以便并行显示。

进一步的实施例中，每个消息队列均设置有优先级，根据消息队列的优先级处理不同消息队列的界面消息的显示关系。

部分实施例中，按序将界面消息添加到消息队列的步骤中，存在单个所述的消息队列，不同类型的界面消息被添加到该单个消息队列中。

进一步的实施例中，将该界面消息转换为界面对象的步骤中，将界面消息所包含的类型信息包含所述视图层索引，直接将其作为界面对象的类型字段的值，以用于选定所述的目标视图层。

较佳的实施例中，将该界面消息转换为界面对象的步骤中，当不存在与其视图层索引相对应的目标视图层时，创建相对应的视图层作为该目标视图层。

进一步的实施例中，输出显示所述界面对象的步骤中，当目标视图层被占用时，候至该目标视图层进入空闲状态以执行本步骤。

进一步的实施例中，本方法还包括如下前置步骤：

启动直播间应用程序进程，由该进程创建所述的消息队列和/或视图层。

较佳的实施例中，本方法还包括如下后置步骤：

所述直播间应用程序进程退出后，销毁所述消息队列和/或视图层。

队列添加消息模块：持续接收符合同一协议规范的不同类型的界面消息，按序将界面消息添加到消息队列中；

获取队列消息模块：依据队列规则按序从消息队列中获取界面消息，将该界面消息转换为界面对象，其中界面消息的类型信息被转换为界面对象的视图层索引；

视图定位显示模块；适应每一界面对象，根据其视图层索引从图形用户界面的多个视图层中选定一个目标视图层，在该目标视图层中输出显示所述界面对象。

适应本申请的另一目的而提供的一种界面消息流控制装置，其包括：

队列添加消息模块：持续接收符合同一协议规范的不同类型的界面消息，按序将界面消息添加到消息队列中；

获取队列消息模块：依据队列规则按序从消息队列中获取界面消息，将该界面消息转换为界面对象，其中界面消息的类型信息被转换为界面对象的视图层索引；

视图定位显示模块；适应每一界面对象，根据其视图层索引从图形用户界面的多个视图层中选定一个目标视图层，在该目标视图层中输出显示所述界面对象。

适应本申请的另一目的而提供的一种电子设备，包括中央处理器和存储器，所述中央处理器用于调用运行存储于所述存储器中的计算机程序以执行本申请所述的界面消息流控制方法的步骤。

适应本申请的另一目的而提供的一种非易失性存储介质，其存储有依据所述的界面消息流控制方法所实现的计算机程序，该计算机程序被计算机调用运行时，执行该方法所包括的步骤。

相对于现有技术，本申请的优势如下：

首先，本申请结合消息队列对接收到的经统一协议规范的界面消息进行了有序处理，使其有序地在图形用户界面得以展现，由此可以构建一个统一、通用性强、扩展性强的队列管理模块，只要界面消息符合统一的协议规范，本申请的技术方案就可以将其按序添加到所述消息队列中，依照队列规则按序处理界面消息，将界面消息有序地显示在直播间图形用户界面中，使界面消息的显示具备流控制的特点，防止繁多的界面消息堆积在设备缓存中，导致直播间应用程序在终端设备运行时发生崩溃。

其次，本申请按照队列规则按序从消息队列中获取界面消息，将其转换为界面对象，所述的界面对象包含界面消息的类型转换而成的视图层索引，以便通过所述视图层索引从多个视图层选定一个目标视图层，实现将界面对象输出显示，通过这一原理实现的方法，不同团队或者不同表现形式的界面消息中指定视图层索引，便可完成开发，无需自行负责视图层创建、维护、销毁等开发工作，并且，在本申请所实现的服务机制的协调下，各种类型的界面消息可以通过不同视图层实现有序的界面表现，以便通过界面的Z轴方向的集中统一管理所述的界面消息的显示。

此外，本申请对消息队列的个数未设限，理论上允许存在多个消息队列，以便进一步通过分门别类，细分控制不同类型界面消息的显示，因此，消息队列的设置，使得本申请强化了其对图形用户界面的分层显示进行调度的技术能力。

本申请附加的方面和优点将在下面的描述中部分给出，这些将从下面的描述中变得明显，或通过本申请的实践了解到。

附图说明

本申请上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：

图1为实施本申请的技术方案相关的一种典型的网络部署架构示意图；

图2为本申请的界面消息流控制方法的典型实施例的流程示意图；

图3位本申请的界面消息流控制方法的另一实施例的流程示意图，其相对添加了前置步骤；

图4位本申请的界面消息流控制方法的再一实施例的流程示意图，其相对添加了后置步骤；

图5为本申请的界面消息流控制装置典型实施例的原理框图；

图6为本申请的直播间图形用户界面的样式示意图。

具体实施方式

下面详细描述本申请的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，仅用于解释本申请，而不能解释为对本申请的限制。

本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是，本申请的说明书中使用的措辞“包括”是指存在所述特征、整数、步骤、操作、元件和/或组件，但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组。应该理解，当我们称元件被“连接”或“耦接”到另一元件时，它可以直接连接或耦接到其他元件，或者也可以存在中间元件。此外，这里使用的“连接”或“耦接”可以包括无线连接或无线耦接。这里使用的措辞“和/或”包括一个或更多个相关联的列出项的全部或任一单元和全部组合。

本技术领域技术人员可以理解，除非另外定义，这里使用的所有术语(包括技术术语和科学术语)，具有与本申请所属领域中的普通技术人员的一般理解相同的意义。还应该理解的是，诸如通用字典中定义的那些术语，应该被理解为具有与现有技术的上下文中的意义一致的意义，并且除非像这里一样被特定定义，否则不会用理想化或过于正式的含义来解释。

本技术领域技术人员可以理解，这里所使用的“客户端”、“终端”、“终端设备”既包括无线信号接收器的设备，其仅具备无发射能力的无线信号接收器的设备，又包括接收和发射硬件的设备，其具有能够在双向通信链路上，进行双向通信的接收和发射硬件的设备。这种设备可以包括：蜂窝或其他诸如个人计算机、平板电脑之类的通信设备，其具有单线路显示器或多线路显示器或没有多线路显示器的蜂窝或其他通信设备；PCS(PersonalCommunications Service，个人通信系统)，其可以组合语音、数据处理、传真和/或数据通信能力；PDA(Personal Digital Assistant，个人数字助理)，其可以包括射频接收器、寻呼机、互联网/内联网访问、网络浏览器、记事本、日历和/或GPS(Global PositioningSystem，全球定位系统)接收器；常规膝上型和/或掌上型计算机或其他设备，其具有和/或包括射频接收器的常规膝上型和/或掌上型计算机或其他设备。这里所使用的“客户端”、“终端”、“终端设备”可以是便携式、可运输、安装在交通工具(航空、海运和/或陆地)中的，或者适合于和/或配置为在本地运行，和/或以分布形式，运行在地球和/或空间的任何其他位置运行。这里所使用的“客户端”、“终端”、“终端设备”还可以是通信终端、上网终端、音乐/视频播放终端，例如可以是PDA、MID(Mobile Internet Device，移动互联网设备)和/或具有音乐/视频播放功能的移动电话，也可以是智能电视、机顶盒等设备。

本申请所称的“服务器”、“客户端”、“服务节点”等名称所指向的硬件，本质上是具备个人计算机等效能力的电子设备，为具有中央处理器(包括运算器和控制器)、存储器、输入设备以及输出设备等冯诺依曼原理所揭示的必要构件的硬件装置，计算机程序存储于其存储器中，中央处理器将存储在外存中的程序调入内存中运行，执行程序中的指令，与输入输出设备交互，借此完成特定的功能。

需要指出的是，本申请所称的“服务器”这一概念，同理也可扩展到适用于服务器机群的情况。依据本领域技术人员所理解的网络部署原理，所述各服务器应是逻辑上的划分，在物理空间上，这些服务器既可以是互相独立但可通过接口调用的，也可以是集成到一台物理计算机或一套计算机机群的。本领域技术人员应当理解这一变通，而不应以此约束本申请的网络部署方式的实施方式。

请参阅图1，本申请相关技术方案实施时所需的硬件基础可按图中所示的架构进行部署。本申请所称的服务器80部署在云端，作为一个前端的应用服务器，其可以负责进一步连接起相关数据服务器、视频流服务器以及其他提供相关支持的服务器等，以此构成逻辑上相关联的服务机群，来为相关的终端设备例如图中所示的智能手机81和个人计算机82提供服务。所述的智能手机和个人计算机均可通过公知的网络接入方式接入互联网，与云端的服务器80建立数据通信链路，以便运行所述服务器所提供的服务相关的终端应用程序。在本申请的相关技术方案中，可以由智能手机81或个人计算机(统称终端设备或本机设备)接收由服务器80发送过来的消息报文，终端设备运行相应的应用程序，对所述的消息报文做相应处理。

需要指出的是，在支持直播间运营的服务器机群中，某些场景中将支持直播间消息服务的服务器与支持直播间的视频流合成的服务器合并为同一服务器或同一网络地址，有时亦可相互独立由同一应用服务器建立整个机群的相互关联，从而使用同一网络地址即可指向最终负责服务的服务器。对此，本领域技术人员应当理解。

为了支持所述的应用程序的运行，终端设备配备有相关操作系统，例如IOS、HMS(鸿蒙)、Android以及其他提供同等功能的操作系统，在此类操作系统的支持下，适应性开发的应用程序得以正常运行，实现人机交互以及远程交互。

本申请的方法被编程内置于提供网络直播的终端设备应用程序中，作为其基础服务功能。所述的网络直播，是指一种基于前述的网络部署架构所实现的一种直播间网络服务。

本申请所称的直播间，是指依靠互联网技术实现的一种视频聊天室，通常具备音视频播控功能，包括主播用户和观众用户，观众用户可以包括已经在平台中注册的注册用户，也可以是未注册的游客用户；可以是关注了主播用户的注册用户，也可以是未关注主播用户的注册或未注册用户。主播用户与观众用户之间可通过语音、视频、文字等公知的线上交互方式来实现交互，一般是主播用户以音视频流的形式为观众用户表演节目，并且在交互过程中还可产生经济交易行为。当然，直播间的应用形态并不局限于在线娱乐，也可推广到其他相关场景中，例如教育培训场景、视频会议场景、产品推介销售场景以及其他任何需要类似交互的场景中。

本申请运行于终端设备的应用程序可以依其平台方设计的需要而触发显示界面消息，目前常见的界面消息主要用于实现动效信息或广播信息的播放，当然也不局限于此。因此可以理解，任何受直播间服务所支持的，旨在向所述的应用程序运行时所构造的直播间的图形用户界面输出某种通知消息的行为，均可被理解为本申请的界面消息。

类似的界面消息不胜枚举，各种类型彼此之间的分类标准，主要是依据彼此均各维持一份通信协议来区分，而不一定在于其展示的通知消息的内容和形式。目前，业内提供的市面上活跃的应用产品中，即存在多份这种通信协议，例如直播间进场动效通信协议、直播间主播等级升级动效数据通信协议、直播间用户等级升级动效数据通信协议、直播间礼物动效数据通信协议、直播间横幅动效数据通信协议、直播间内其它的动效类、广播类数据通信协议等等。可见，以上种种实现的各类通知消息，均可在本申请中被概括为所述的界面消息。

本领域技术人员对此应当知晓：本申请的各种方法，虽然基于相同的概念而进行描述而使其彼此间呈现共通性，但是，除非特别说明，否则这些方法都是可以独立执行的。同理，对于本申请所揭示的各个实施例而言，均基于同一发明构思而提出，因此，对于相同表述的概念，以及尽管概念表述不同但仅是为了方便而适当变换的概念，应被等同理解。

请参阅图2，本申请的一种界面消息流控制方法可被实现为直播间应用程序，运行于终端设备中，其典型实施例中，包括以下步骤：

步骤S11，持续接收符合同一协议规范的不同类型的界面消息，按序将界面消息添加到消息队列中：

本申请出于统一管理所有类型界面消息的目的，对所接收的界面消息有一定的限定，不同团队或者不同表现形式的界面消息的报文格式需要符合统一协议规范，可按照统一协议规范界面消息的格式，也可在服务器上将不符合统一协议的不同类型界面消息进行规范，以便直播应用间程序识别各类型的所述界面消息，并将其所述的界面消息按序添加到消息队列中；统一协议规范界面消息的实施的方法可灵活设计，只需要实现直播间应用程序接收到的界面消息是符合统一协议规范的，便不影响本申请的实施。

需要注意的是，所述界面消息的来源，也不局限于服务器推送的界面消息，也可以是直播间应用程序在本地运行过程中产生的界面消息，只要其格式遵守相同协议即可。

如前所述，统一协议规范了界面消息的格式，所以可以用于封装前述各类通知消息，即现有技术中以不同协议分别对应封装的各类数据通信协议相关的消息，对应这些原来不同的数据通信协议，可以分别转换为不同的类型信息，以便后续分别对应处理。关于类型信息的作用，主要是为了方便对界面消息进行区别对待，例如，根据所述界面消息的类型信息，将不同类型的界面消息分别添加到相应的消息队列中，通过对不同消息队列进行区别处理，使不同消息队列具备不同的对应关系，以便分类调度管理；又如，根据上述的类型信息将其转换为界面对象的视图层索引，以便据此确定界面消息要显示的视图层。总言而之，本申请接收的界面消息需要符合统一协议规范，以便有效地控制及管理所述界面消息。

所述的消息队列可为单队列或多队列，例如，当所述消息队列为单队列时，其实现先进先出的存储结构，即队首出队、队尾入队的原则，保证直播间应用程序优先处理较早接收到的界面消息，当所述的消息队列为多队列时，直播间应用程序则存在多个与所述界面消息的不同类型一一对应的消息队列，每个所述消息队列依旧遵循前文所述的先进先出的访问规则。为此而改进的一种实施例中，不同类型的消息队列会设置不同的优先级，以便处理不同消息队列界面消息之间的显示关系，例如，一个用于存储大礼物动效类型的界面消息的消息队列，其优先级大于一个用于存储小礼物动效类型的界面消息的消息队列，前者队首的所述界面消息相对后者的界面消息将得到优先处理，这种优先可以体现为时序上的优先处理，例如，前者的界面消息先于后者的界面消息被输出到视图层中显示；也可以体现为在图形用户界面的Z轴纵深方向的层级上的优先处理，例如将前者的界面消息优先显示在直播间图形用户界面中。更为复杂的情况是允许多个消息队列具有等值的优先级，这种情况下，这些消息队列的界面消息可被并行处理，其各自的界面消息可以被并行输出至直播间图形用户界面的不同视图层中同步显示。关于消息队列的队列数量，本领域技术人员可灵活设计，按需确定。

按照以上各种实施方式实施的方法，说明了本申请只接受符合统一协议规范的不同类型的界面消息的意义，结合所述消息队列对所述界面消息的按序添加原则，构建了一个统一的、通用性强、扩展性强的队列管理模块，体现出本步骤拥有持续处理大量不同类型的界面消息的流控制服务能力，且节省了运行直播间应用程序的终端设备的计算资源及减少直播间应用程序在运行时占用的内存。

步骤S12，依据队列规则按序从消息队列中获取界面消息，将该界面消息转换为界面对象，其中界面消息的类型信息被转换为界面对象的视图层索引：

考虑到本领域技术人员在实施本申请时，对消息队列的队列实施可能为单队列或多队列其中一种方式，为此本申请在此提供相应的方案，供技术人员参考，具体如下：

当本申请的消息队列为单一消息队列时，消息队列遵守先进先出的原则，队首的所述界面消息优先出队，即直播间应用程序获取的所述界面对象为其接收到的第一个符合统一协议规范的界面对象。

当本申请的消息队列为与界面消息的类型一一对应的多消息队列时，一种实施例中，循环访问多个消息队列的队首的界面消息，不同消息队列之间，优先级最高的消息队列在其各自遵守先进先出的原则的基础上将队首的所述界面消息优先出队，优先级相同的界面消息则如前所述可同步处理；另一实施例中，可由多个线程分别负责一个消息队列的出队，再集中比较已出队的多个界面消息的优先级，按优先级处理显示关系，同理高优先级的界面消息将被优先处理。通过此处的揭示可以理解，多个消息队列作为界面消息管理的一个维度进行组织之后，还结合其优先级进行了另一维度的组织，等效于在实际上对界面消息进行了两个维度的组织，通过两个维度的有序调度，可以更有序地处理多界面消息之间的显示关系。

被出队并确定输出显示的界面消息，在处理顺序上解决了排队等候的问题，获得了进入后续显示的资格，后续直接按照显示所需的逻辑进行处理即可。为了规范界面消息的最终显示，需要将确定输出显示的界面消息转换为界面对象。

所述界面对象由所述界面消息转换而来。当所述消息队列的所述界面消息出队后，可以被输出显示时，需要将界面消息做本地处理，将界面消息转换为本申请的界面对象，以实现所述界面消息在图形用户界面的展示。界面消息转换为界面对象的过程，实际上是将界面消息的格式描述转换为对应的类的描述的过程，也即，可以为界面对象创建一个类，在需要转换界面消息时，为该界面消息实例化一个类，获得其实例对象，将界面消息所包含的各类信息对应转换为该实例对象的属性和接口即可。

考虑到界面消息与界面对象最终在图形用户界面中显示时所采用的视图层之间的对应关系，为了匹配这种关系，所述界面对象将设置一个视图层索引，从获取的界面信息中提取其类型信息的内容转换为界面对象的视图层索引，用于记载该界面对象指定的视图层索引，以便供确定其目标视图层。后续根据所述的视图层索引，为相应的界面消息匹配相应的目标视图层以便进行界面显示。此举也在实质上完成了对界面消息的本地化处理。

步骤S13，适应每一界面对象，根据其视图层索引从图形用户界面的多个视图层中选定一个目标视图层，在该目标视图层中输出显示所述界面对象：

如前所述，所述的界面对象中存在用于指定其所需采用的具体视图层的视图层索引，便可从缓存中已存在的多个视图层中确定该界面对象相对应的目标视图层，以便将该界面对象加载到该目标视图层中，实现该界面对象所表征的界面消息在直播间图形用户界面中的显示。

为了具备有序处理大量的界面对象的能力，本方法负责维护一个由视图层构成的树结构，每个所述的视图层对应由一个视图容器实施界面表现，视图容器用于集中管理其负责表现的视图层(参阅图6)，所有视图容器均关联于同一根容器以便实现所述的树结构组织。因此，所述的根容器适于集中管理一个或多个所述的视图容器，可以理解，一个直播间中只需设置一个根容器便可组织起所有的视图层。为了便于确定具体的某个视图层，视图层会被分配相应的索引编号，后续通过提供相同的编号作为该视图层的索引，便可直接调用该视图层。这一树结构一旦被创建，其中的根容器和各个视图容器便可在缓存中存续，除非被销毁。可以理解，所述的视图层可以按需创建，也可以按需销毁。

所述根容器，其对应的类可以由开发人员进行自定义，例如基于Android的View或ViewGroup基类按需进行自定义开发而成，使其具备ViewGroup的适于支持视图容器(如View)和ViewGroup的能力即可，也即，根容器适于关联管理其下一级的视图容器，而视图容器同理可与根容器同理自同一自定义的类实例化而得。理论上，由于根容器具备ViewGroup的同等能力，因此，根容器还可以进一步的关联管理下一级的父容器，父容器与根容器派生于同一自定义类而具备根容器同等的支持下一级View的能力，通过这种基于类的派生关系构造而成的树结构，可以实现对繁多的视图容器的组织和调用。一般情况下，在根容器的基础上，关联单层的视图容器，可以满足一般数量的视图层使用需求。如果开发人员自知所需视图层较多时，也可实现多层级联以满足需求。开发人员在自定义根容器及其视图容器相关联的类时，可以适应其他需求而扩展一些属性或接口，以丰富视图容器的功能，只要这种实施不影响本申请的实施即可，本领域技术人员对此应当理解。

可以理解，同一视图容器可以被多次复用以服务于同一类型的界面对象，也可以单次使用，至于具体如何应用，可由本领域技术人员灵活确定。例如，一种复用视图层的实施例中，一个被初次创建并使用的目标视图层，除了用于实现将其当时对应的界面对象所表征的界面消息显示在直播间图形用户界面中，后续也可用于加载其他界面对象，完全视界面对象本身的类型字段的内容而定，也即是说，只要不同界面对象在各自的类型字段指定了相同的视图层索引，则与该视图层索引相对应的视图层便会被该些不同界面对象先后复用。

通常，界面消息是频发的，因此，同一时间段内，往往需要处理大量的界面对象。当存在这样的情况时，由于大量的界面对象可能由于属于不同类型的界面消息而分别指定至少部分不同的视图层索引，而本步骤则根据这些不同索引而调用不同的视图层供显示不同的界面对象，因此，大量的界面对象的显示位置最终通过直播间图形用户界面的Z轴纵深方向的不同层级来实施显示，显示过程并行不悖。可见，本申请具备利用图形用户界面的Z轴纵深方向的不同层级来展示不同界面消息的调度服务能力，可以自动且科学合理地组织各个所述界面消息的显示，满足不断增多的各类型界面消息其动效信息的业务需求。

请参阅图6，本申请根据所述界面对象的视图层索引，确定该界面对象的目标视图层后，将该界面对象加载到其所属的所述目标视图层中，以便将该界面对象所属的所述界面消息在直播间图形用户界面显示。

可以理解，符合统一协议规范的不同类型的界面消息，其均会描述如何在图形用户界面中展示何种资源的图形对象，因此，界面消息中通常也便会包含对图形对象的显示位置、显示尺寸、引用资源、动画效果等等信息的描述，这些描述形成的描述信息同理会被转换到其相应的界面对象中，因此，加载所述界面对象时，便会根据这些描述信息调用相应的引用资源然后输出到所述的目标视图层中展示，从而实现相应的界面通知消息的显示。

当消息队列为单一队列时，依据队列访问规则，源源不断地对消息队列进行出队并显示操作，在时序上通过不同视图层对先后出现的不同界面对象启动显示，表现在图形用户界面上，这些不同视图层显示的界面对象，由于彼此显示时长不同，也可能出现重复交叉，但由于其启动是受控的，因此仍然能够取得并行不悖的效果。

当消息队列为多消息队列时，由于多消息队列被进行了两个维度的调度，最终按照队列的优先级协调显示关系，因此，与单消息队列同理，最终也可在不同视图层比较协调有序地展示多种不同的界面对象。相对而言，多消息队列比单一队列的情况，由于组织更细致，因此其显示调度效果更细腻。

除以上各实施例外，为丰富本申请的实现方式，如下继续揭示本申请的其他多种实施方式：

一种实施例中，为了丰富关于所述消息队列的实施，细化步骤S11关于按序将界面消息添加到消息队列的步骤，具体如下：

存在多个与界面消息的不同类型一一对应的消息队列，界面消息按照其不同类型被添加到对应的消息队列中，各消息队列被并行处理以便并行输出显示。

为了更好的管理符合统一协议规范的界面消息，本申请存在多个消息队列其与所述界面消息的类型一一对应，根据所述界面消息的类型信息将其按序添加到相应的消息列队中，且可根据消息列队的类型，为每个所述消息列队增设优先级属性，可根据为每个消息队列规划的功能是用于容置何种界面消息而为这些消息队列设置其优先级，例如，除了前言所述按照大、小礼物类型进行优先级设置的方式之外，还可以例如将用于专门处理礼物类型的动效界面消息的消息列队设置为更低优先级，将用于专门处理广播消息的界面消息的消息列队的设置为更低优先级，于是可以根据消息队列的优先级，优先处理优先级较高的消息队列里的界面消息，以提高用户体验。

另一种实施例中，是上述关于丰富所述消息队列的实施例的另一种实施例，具体如下：

本申请存在单个所述的消息队列，不同类型的界面消息被添加到该单个消息队列中。

为了轻量化本申请所述的消息队列，节省终端设备的内存及计算资源，所述消息队列可为单队列，将所有不同类型的界面消息按序添加到所述消息队列中，且所述消息队列实现为先进先出的存储结构，以便优先处理较早接收到的符合统一协议规范的界面消息，防止因接收大量的所述界面消息而出现数据堵塞，导致直播间应用程序奔溃。

在一种实施例中，提供另一种关于步骤S12关于将该界面消息转换为界面对象的典型实施例中的视图层索引由来的实施方式，具体如下：

将界面消息所包含的类型信息包含所述视图层索引，直接将其作为界面对象的类型字段的值，以用于选定所述的目标视图层。

符合统一协议规范的界面消息，将包含所述视图层索引，使所述界面消息转换为界面对象的实施更全面，节省本申请在实施将所述界面消息转换为界面对象时所占用的计算资源。

同理，当界面消息所包含的类型信息包含所述视图层索引，所述消息列表的设计及实施也可更加灵活，例如，根据界面消息的所述视图层索引将其添加到相应的消息列队中，以实现更好的并行显示效果。

另一实施例中，本申请在以上任意一种实施例的基础上，进一步为步骤S13增设如下具体实施例：

当不存在与其视图层索引相对应的目标视图层时，创建相对应的视图层作为该目标视图层。

在直播间应用程序时，可以预先创建一些视图层以便供即时调用，但是，大量创建空置的视图层，会占用缓存，所以，本实施例通过实现动态创建视图层的功能来优化内存管理。

具体而言，当需要显示的界面对象指定的视图层索引所对应的视图层并不存在时，此时，调用相对应的目标视图层将会导致调用失败，当接收到调用失败的结果时，便可创建一个新的视图容器，将该视图层索引作为该视图容器的编号，利用该视图容器用于表现与视图层索引相对应的视图层。同理，该新建的视图容器应当关联从属于所述的根容器，以方便当前应用程序进程可以正常对其进行维护。

再一实施例中，进一步为步骤S13增设如下具体实施例：

当目标视图层被占用时，候至该目标视图层进入空闲状态以执行本步骤。

为了防止过多的所述界面对象在图形用户界面中繁乱显示及无序显示，影响直播间用户观看体验，当界面对象的所述目标视图层被占用时，其将进入等待状态，不可占用该目标视图层与其他界面对象并行错乱显示在图形用户界面中，候至该目标视图层进入空闲状态，该界面对象才执行步骤S13，确定其目标视图层，并在该目标视图层进行可视化，显示在直播间图形用户界面中。

又一实施例中，考虑到在消息队列和视图层是本方法实施的关键组件，参考图3，本方法还包括如下前置步骤：

步骤S10，启动直播间应用程序进程，由该进程创建所述的消息队列和/或视图层：

在启动直播间应用程序进程时，需要同时创建所述的消息队列或视图层或者并行创建消息队列和视图层，防止本方法无法正常运行，导致直播间应用程序无法处理界面消息，甚至出现直播间应用程序报错和崩溃，严重影响用户体验。

另一实施例中，为了优化优化内存管理，参考图4，本方法还包括如下后置步骤：

步骤S14，所述直播间应用程序进程退出后，销毁所述消息队列和/或视图层：

直播间应用程序可以自行实施自身的内存管理，因此，可以通过自身设置的功能模块对所述信息队列及每个视图层的的存续进行管理，当直播间应用程序进程退出后，便可直接销毁所述信息队列及所有存在的所述视图，释放终端设备的内存及计算资源。

可以看出，当本步骤与前一实施例相结合时，使得直播间应用程序既管理所述消息队列及每个视图层的存续的能力，也具备动态销毁所述消息队列及每个视图层的能力，可以自动化地实施对终端设备内存及缓存的动态维护，优化内存占用，这一机制可以大大提升直播间应用程序的运行流畅度。

进一步，可以通过将上述各实施例所揭示的方法中的各个步骤进行功能化，构造出本申请的一种界面消息流控制装置，按照这一思路，请参阅图5，其中的一个典型实施例中，该装置包括：

队列添加消息模块11：持续接收符合同一协议规范的不同类型的界面消息，按序将界面消息添加到消息队列中；

获取队列消息模块12：依据队列规则按序从消息队列中获取界面消息，将该界面消息转换为界面对象，其中界面消息的类型信息被转换为界面对象的视图层索引；

视图定位显示模块13；适应每一界面对象，根据其视图层索引从图形用户界面的多个视图层中选定一个目标视图层，在该目标视图层中输出显示所述界面对象。

进一步，为便于本申请的执行，本申请提供一种电子设备，包括中央处理器和存储器，所述中央处理器用于调用运行存储于所述存储器中的计算机程序以执行如前所述的各实施例中所述界面消息流控制方法的步骤。

可以看出，存储器适宜采用非易失性存储介质，通过将前述的方法实现为计算机程序，安装到手机或计算机之类电子设备中，相关程序代码和数据便被存储到电子设备的非易失性存储介质中，进一步通过电子设备的中央处理器运行该程序，将其从非易性存储介质中调入内存中运行，便可实现本申请所期望的目的。因此，可以理解，本申请的一个实施例中，还可提供一种非易失性存储介质，其中存储有依据所述的界面消息流控制方法各个实施例所实现的计算机程序，该计算机程序被计算机调用运行时，执行该方法所包括的步骤。

综上所述，根据本申请可以通过所述的消息队列，有效且高效地管理符合统一协议规范的各类型的界面消息，及为各类型的所述界面消息自动化且科学地规划图形用户界面的纵深方向不同层级视图层，适于直播间应用程序有序地控制大量相同和不同类型的界面消息及其在直播间图形用户界面中的显示，简化开发难度，降低运行设备的运行压力，以及提高运行设备计算资源的处理效率。

本技术领域技术人员可以理解，本申请包括涉及用于执行本申请中所述操作、方法中的一项或多项的设备。这些设备可以为所需的目的而专门设计和制造，或者也可以包括通用计算机中的已知设备。这些设备具有存储在其存储器之内的计算机程序，这些计算机程序选择性地激活或重构。这样的计算机程序可以被存储在设备(例如，计算机)可读介质中或者存储在适于存储电子指令并分别耦联到总线的任何类型的介质中，所述计算机可读介质包括但不限于任何类型的盘(包括软盘、硬盘、光盘、CD-ROM、和磁光盘)、ROM(Read-Only Memory，只读存储器)、RAM(Random Access Memory，随即存储器)、EPROM(ErasableProgrammable Read-Only Memory，可擦写可编程只读存储器)、EEPROM(ElectricallyErasable Programmable Read-Only Memory，电可擦可编程只读存储器)、闪存、磁性卡片或光线卡片。也就是，可读介质包括由设备(例如，计算机)以能够读的形式存储或传输信息的任何介质。

本技术领域技术人员可以理解，可以用计算机程序指令来实现这些结构图和/或框图和/或流图中的每个框以及这些结构图和/或框图和/或流图中的框的组合。本技术领域技术人员可以理解，可以将这些计算机程序指令提供给通用计算机、专业计算机或其他可编程数据处理方法的处理器来实现，从而通过计算机或其他可编程数据处理方法的处理器来执行本申请公开的结构图和/或框图和/或流图的框或多个框中指定的方案。

本技术领域技术人员可以理解，本申请中已经讨论过的各种操作、方法、流程中的步骤、措施、方案可以被交替、更改、组合或删除。进一步地，具有本申请中已经讨论过的各种操作、方法、流程中的其他步骤、措施、方案也可以被交替、更改、重排、分解、组合或删除。进一步地，现有技术中的具有与本申请中公开的各种操作、方法、流程中的步骤、措施、方案也可以被交替、更改、重排、分解、组合或删除。

以上所述仅是本申请的部分实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。

Claims (11)

1.一种界面消息流控制方法，其特征在于，包括如下步骤：

持续接收直播间服务器推送的符合同一协议规范的不同类型的界面消息，按序将界面消息添加到消息队列中，所述界面消息为向当前应用程序运行时所构造的直播间的图形用户界面输出的通知消息，该界面消息包含对图形对象的描述信息，描述信息中包含对引用资源的描述；

依据队列规则按序从消息队列中获取界面消息，将该界面消息转换为界面对象，其中界面消息的类型信息被转换为界面对象的视图层索引；

适应每一界面对象，根据其视图层索引从图形用户界面的多个视图层中选定一个目标视图层，根据界面消息的描述信息在该目标视图层中输出显示所述界面对象，实现界面消息中的引用资源在图形用户界面的展示。

2.根据权利要求1所述的方法，其特征在于，按序将界面消息添加到消息队列的步骤中，存在多个与界面消息的不同类型一一对应的消息队列，界面消息按照其不同类型被添加到对应的消息队列中，各消息队列被并行处理。

3.根据权利要求1所述的方法，其特征在于，每个消息队列均设置有优先级，根据消息队列的优先级处理不同消息队列的界面消息的显示关系。

4.根据权利要求1所述的方法，其特征在于，按序将界面消息添加到消息队列的步骤中，存在单个所述的消息队列，不同类型的界面消息被添加到该单个消息队列中。

5.根据权利要求1所述的方法，其特征在于，将该界面消息转换为界面对象的步骤中，将界面消息所包含的类型信息包含所述视图层索引，直接将其作为界面对象的类型字段的值，以用于选定所述的目标视图层。

6.根据权利要求5所述的方法，其特征在于，将该界面消息转换为界面对象的步骤中，当不存在与其视图层索引相对应的目标视图层时，创建相对应的视图层作为该目标视图层。

7.根据权利要求1所述的方法，其特征在于，输出显示所述界面对象的步骤中，当目标视图层被占用时，候至该目标视图层进入空闲状态以执行本步骤。

8.根据权利要求1所述的方法，其特征在于，还包括如下前置步骤：

启动直播间应用程序进程，由该进程创建所述的消息队列和/或视图层。

9.一种界面消息流控制装置，其特征在于，其包括：

队列添加消息模块：持续接收直播间服务器推送的符合同一协议规范的不同类型的界面消息，按序将界面消息添加到消息队列中，所述界面消息为向当前应用程序运行时所构造的直播间的图形用户界面输出的通知消息，该界面消息包含对图形对象的描述信息，描述信息中包含对引用资源的描述；

获取队列消息模块：依据队列规则按序从消息队列中获取界面消息，将该界面消息转换为界面对象，其中界面消息的类型信息被转换为界面对象的视图层索引；

视图定位显示模块：适应每一界面对象，根据其视图层索引从图形用户界面的多个视图层中选定一个目标视图层，根据界面消息的描述信息在该目标视图层中输出显示所述界面对象，实现界面消息中的引用资源在图形用户界面的展示。

10.一种电子设备，包括中央处理器和存储器，其特征在于，所述中央处理器用于调用运行存储于所述存储器中的计算机程序以执行如权利要求1至8中任意一项所述的界面消息流控制方法的步骤。

11.一种非易失性存储介质，其特征在于，其存储有依据权利要求1至8中任意一项所述的界面消息流控制方法所实现的计算机程序，该计算机程序被计算机调用运行时，执行该方法所包括的步骤。

Images