CN115016954A - 事件消息管理方法、电子设备和计算机可读取存储介质 - Google Patents

Abstract

本申请公开了一种事件消息管理方法，应用于电子设备，该方法包括：事件发布者确定事件消息，并将事件消息发送给对应的事件轻量级总线，事件消息包括事件过滤条件和事件内容，事件过滤条件根据事件消息对应的业务类型确定；事件轻量级总线接收事件发布者发送来的事件消息，根据事件消息中的事件过滤条件，和事件轻量级总线存储的情报站信息，确定事件消息对应的目标情报站；并且事件轻量级总线将事件消息发送给目标情报站，以使目标情报站按照对应的事件消息接收模式将事件消息回调给对应的事件订阅者。如此，可以简化实现代码，使得代码更容易理解和维护，并且可以提高事件消息的管理效率。本申请还公开了一种电子设备和计算机可读取存储介质。

Description

事件消息管理方法、电子设备和计算机可读取存储介质

技术领域

本申请涉及计算机技术领域，特别涉及一种事件消息管理方法、电子设备和计算机可读取存储介质。

背景技术

在应用程序(Application，APP，可以简称为应用)软件开发过程中，应用的不同类之间(即不同类对象之间，或者也可以是不同线程、组件、功能模块之间等)，通常需要根据业务需求，传递事件(Event)消息。例如，在后台任务线程下载应用、前台页面线程监听以及显示下载进度的场景中，后台任务线程和前台页面线程作为需要传递事件消息的类，并且后台任务线程需要将应用下载事件对应的下载进度作为事件消息，发送给前台页面线程。

随着应用功能的不断增加，需要传递的事件消息也越来越多，随之实现事件消息管理的代码也越来越复杂，使得代码不容易理解和维护。并且，复杂的代码还存在影响事件消息的传递等管理效率的问题。

发明内容

本申请提供了一种事件消息管理方法、电子设备和计算机可读取存储介质，可以解决现有技术中存在的实现事件消息管理的代码不容易理解和维护，以及影响事件消息的管理效率的问题。即，本申请技术方案可以简化实现事件消息管理的代码，使得代码更容易理解和维护，并且可以提高事件消息的管理效率。

为解决上述技术问题，第一方面，本申请的实施方式提供了一种事件消息管理方法，应用于电子设备，该方法包括：事件发布者确定事件消息，并将事件消息发送给对应的事件轻量级总线，事件消息包括事件过滤条件和事件内容，事件过滤条件根据事件消息对应的业务类型确定；事件轻量级总线接收事件发布者发送来的事件消息，根据事件消息中的事件过滤条件，和事件轻量级总线存储的情报站信息，确定事件消息对应的目标情报站，其中，情报站信息包括至少一个已在事件轻量级总线注册的情报站的情报站标识信息、事件过滤条件和事件消息接收模式，一个情报站至少对应于一个事件订阅者；并且事件轻量级总线将事件消息发送给目标情报站，以使目标情报站按照对应的事件消息接收模式将事件消息回调给对应的事件订阅者。

如此，可以简化实现事件消息管理的代码，使得代码更容易理解和维护，并且可以提高事件消息的管理效率。

在上述第一方面的一种可能的实现中，事件消息接收模式包括主线程接收模式、子线程接收模式和跟随线程接收模式中的任意一种。

在上述第一方面的一种可能的实现中，若事件消息接收模式为主线程接收模式，以使目标情报站按照对应的事件消息接收模式将事件消息回调给对应的事件订阅者，包括：在主线程中执行主线程接收模式对应的事件消息处理方法，以使目标情报站通过事件消息处理方法将事件消息回调给对应的事件订阅者。如此，可以确保事件消息的发布和接收都在主线程进行。

在上述第一方面的一种可能的实现中，若事件消息接收模式为子线程接收模式，以使目标情报站按照对应的事件消息接收模式将事件消息回调给对应的事件订阅者，包括：若事件发布者在主线程发送事件消息，则创建新的子线程，并在子线程中执行子线程接收模式对应的事件消息处理方法，以使目标情报站通过事件消息处理方法将事件消息回调给对应的事件订阅者；若事件发布者在子线程发送事件消息，则在子线程中执行子线程接收模式对应的事件消息处理方法，以使目标情报站通过事件消息处理方法将事件消息回调给对应的事件订阅者。如此，可以保证事件消息的发布和接收都在子线程进行。

在上述第一方面的一种可能的实现中，若事件消息接收模式为跟随线程接收模式，以使目标情报站按照对应的事件消息接收模式将事件消息回调给对应的事件订阅者，包括：若事件发布者在主线程发送事件消息，则在主线程中执行跟随线程接收模式对应的事件消息处理方法，以使目标情报站通过事件消息处理方法将事件消息回调给对应的事件订阅者；若事件发布者在子线程发送事件消息，则在子线程中执行跟随线程接收模式对应的事件消息处理方法，以使目标情报站通过事件消息处理方法将事件消息回调给对应的事件订阅者。如此，可以使得事件消息的发布线程和接收线程一致。

在上述第一方面的一种可能的实现中，事件消息接收模式根据事件消息对应的业务类型确定，和/或根据事件消息对应的事件处理耗时信息确定。如此，可以有效地提高事件消息的处理效率。

在上述第一方面的一种可能的实现中，情报站基于创建者模式对应的创建方法创建。当然，情报站也可以基于其他模式或者分发创建，其可以根据需要选择。

在上述第一方面的一种可能的实现中，事件消息接收模式通过事件消息处理方法函数定义。

在上述第一方面的一种可能的实现中，方法还包括：通过map格式存储情报站信息。

在上述第一方面的一种可能的实现中，情报站标识信息通过map的键存储，并且情报站标识信息包括情报站创建时传入的类的包名和类名，事件过滤条件和事件消息接收模式通过map的值存储。

通过map格式可以方便地存储情报站信息，并且可以方便事件轻量级总线确定目标情报站。

第二方面，本申请的实施方式提供了一种电子设备，包括：存储器，用于存储计算机程序，计算机程序包括程序指令；控制器，用于执行程序指令，以使电子设备执行如上述第一方面和/或第一方面的任意一种可能的实现方式所提供的事件消息管理方法。

第三方面，本申请的实施方式提供了一种计算机可读取存储介质，计算机可读取存储介质存储有计算机程序，计算机程序包括程序指令，程序指令被电子设备运行以使电子设备执行如上述第一方面和/或第一方面的任意一种可能的实现方式所提供的事件消息管理方法。

可以理解的是，上述第二方面至第三方面的有益效果也可以参见上述第一方面中的相关描述，在此不再赘述。

附图说明

为了更清楚地说明本申请的技术方案，下面将对实施方式描述中所使用的附图作简单介绍。

图1示出了一种事件消息管理架构示意图；

图2是根据本申请的一些实施方式，示出了本申请提供的一种事件消息管理架构以及管理过程示意图；

图3是根据本申请的一些实施方式，示出了本申请提供的一种情报站的示意图；

图4是根据本申请的一些实施方式，示出了本申请提供的一种事件消息管理方法的流程示意图；

图5是根据本申请的一些实现方式，示出了一种片上系统(SoC)的结构示意图。

具体实施方式

下面将结合附图对本申请的技术方案作进一步详细描述。

请参见图1，图1示出了一种用于实现事件消息管理的事件发布—订阅模式对应的架构示意图。该架构包括事件发布者(Event Publisher)、事件总线(Event Bus)、以及多个事件订阅者(Event Subscriber)。

其中，事件发布者用于发布事件，即用于通知事件订阅者有事件发生，事件可以是任意类型的对象。并且，事件发布者可以调用事件总线的postEvent方法(即Post()方法)，通过事件消息的方式发布事件。但是，事件发布者不会将事件消息直接发送给事件订阅者，而是将发布的事件消息以不同的类别(即不同的事件类)发送给事件总线，事件发布者无需了解可能存在的事件订阅者。

事件订阅者用于接收特定的事件消息。即事件订阅者可以表达对一个或者多个类别的事件消息的兴趣，只接收感兴趣的特定事件，而无需了解可能存在的事件发布者。另外，事件订阅者可以调用OnEvent()方法接收或者获取事件消息。

事件总线具有事件消息的发布、订阅以及分发管理能力，用于将事件发布者发送来的事件消息发送给事件订阅者。即，事件总线是通过事件发布和订阅实现事件消息的传递的。

基于图1所示的事件发布—订阅模式架构，事件总线实现事件发布者和事件订阅者之间的事件消息传递的过程可以是：

开发人员自定义事件类，并且通过事件类的注释框架(或者也可以称为注解框架)的方式准备事件订阅者，准备事件订阅者包括开发人员自定义事件类对应的事件消息处理方法(也可以称为事件消息接收方法，或者事件消息订阅方法等)，并且通过给事件消息处理方法添加注释框架的方式(即通过给事件消息处理方法添加注释@Subscribe的方式)指定事件订阅者，以及指定事件订阅者接收事件消息的线程模式。即，通过注释框架可以确定事件订阅者，以及确定事件订阅者接收事件消息的线程模式和事件消息处理方法。

例如，如下方代码示例所示，其中：

根据@Subscribe后的“threadMode＝ThreadMode.MainThread”，可以确定事件订阅者接收事件消息的线程模式为“MainThread”(即主线程模式)。

根据OnEvent()可以确定事件消息处理方法。

另外，public classMessageEvent{}中的“MessageEvent”即为开发人员自定义的事件类，则根据“public classMessageEvent”和OnEvent中的“MessageEventmessageEvent”，都可以确定事件订阅者为对“MessageEvent”事件类表达了兴趣的事件订阅者(即可以理解为是订阅了MessageEvent的事件订阅者)。

代码示例：

public class MessageEvent{

……

}

……

@Subscribe(threadMode＝ThreadMode.MainThread)

public void OnEvent(MessageEventmessageEvent){

……

}

需要说明的是，若线程模式为主线程模式，则说明事件订阅者需要在主线程中接收事件消息。

然后，事件订阅者在事件总线中注册订阅事件，事件总线通过map格式记录订阅记录信息等注册相关信息。Map格式指的是通过键(Key)值(value)的形式存储信息，输出时用“＝”链接，例如{Key1＝value，Key2＝value}。其中Key是存储事件订阅者信息的标记，例如可以包括作为事件订阅者的类的包名和类名，value存储订阅记录信息。

例如，对于一个MainActivity类，若其写在包名是“com.pyh.event”的包下，则其对应的Key可以是com.pyh.event.MainActivity。需要说明的是，Key作为存储事件订阅者信息的标记，后续在修改事件订阅者的订阅记录信息或者注销订阅的时候，也可以通过传入对应类的包名和类名的方式修改订阅记录信息或者注销订阅。

订阅记录信息中至少包含了两个内容，一个是订阅了这个事件的事件订阅者的信息，一个是事件消息处理方法和其对应的线程模式信息。例如可以是前述代码示例中的“@Subscribe(threadMode＝ThreadMode.MainThread)”、“public void OnEvent(MessageEventmessageEvent)”等信息。

即这个map的目的是为了事件总线在向事件订阅者发送事件消息的时候，可以在这个map中找到所有订阅了这个事件类的订阅记录。事件总线找到订阅记录后，就可以根据订阅记录中的线程模式信息将事件消息发布至对应的线程，并且利用反射等方式，调用事件订阅者对此事件的事件消息处理方法，完成事件处理。

后续，事件发布者发布事件，并通过postEvent方法将事件通过事件消息的方式发送给事件总线，事件消息包括事件类的信息(如前述的MessageEvent事件类)和事件内容(Object)。

事件总线从map中获取所有订阅了这个事件类的订阅记录，并且根据订阅记录中的线程模式信息将事件消息发布至对应的线程，并且利用反射等方式，调用事件订阅者对此事件的事件消息处理方法，完成事件处理。本实现方式中，由于事件订阅者在注册订阅事件时，订阅的是事件类，所以只要是订阅了该事件类的事件订阅者，都会收到该事件消息。

本实现方式中，事件类的命名是开发人员根据需要自定义的，即开发人员可以根据开发需求、事件消息的不同来源和接收事件消息的不同事件订阅者等需求随意命名事件类，从而区分事件类。在实际应用开发过程中，要实现事件发布者与事件订阅者之间的事件消息的传递，通常需要定义很多事件类，所以这种通过自定义事件类参数来区分事件的来源和接收的方式，增加了开发人员开发应用的难度，以及增加了代码的维护难度。

并且，如果开发人员在开发前期没有规划好事件类的命名规则，后续如果需要新增事件类(即新增接收事件回调)，开发人员则需要修改之前的事件类的命名以与后续新增的事件类做兼容，增加了开发人员的工作量，以及由于开发人员在进行软件开发的时候，对事件类命名等标准不一定统一，使得后续代码维护难度较大。另外，修改之前定义好的事件类的过程中，通常还需要修改一些相关信息，开发人员很容易出错，修改后的代码容易存在影响应用功能的问题。

另外，事件消息处理方法的命名也是开发人员根据需要自定义的，即开发人员可以根据需要随意命名事件消息接收方法，并且开发人员需要通过注释框架的方式实现事件消息处理方法对应的线程模式等内容的定义。由于开发人员在进行软件开发的时候，对事件消息处理方法的命名等标准不一定统一，并且通过注释框架定义事件消息处理方法对应的线程模式(即实现接收内容的接收条件)，对于初学者来说比较难理解代码的内部实现原理，所以对于开发人员和后期软件维护人员的能力要求会比较高。

另外，在代码比较多的情况下，这种通过注释框架实现事件消息处理方法对应的线程模式等内容的定义的方式，在注册事件订阅者的时候，事件总线需要调用反射方法去遍历注册对象的方法在其中找出带有@subscriber标签的方法，确定事件消息处理方法，以及其对应的线程模式等内容，使得事件消息处理方法比较难找，影响事件消息的处理效率。并且，后期进行代码维护的时候，也不容易找到事件消息处理方法，使得代码难维护。

需要理解的是，本实现方式中，事件订阅者订阅的是自定义的事件类(即当前类对象)，事件总线向事件订阅者发送的也是自定义的事件类，并且如前所述，订阅了该事件类的事件订阅者，都会收到该事件消息，即事件消息的过滤通过自定义的事件类实现。另外，本实现方式中，前述事件消息处理方法也可以理解为事件订阅者接收事件消息的接收条件。

为解决上述问题，本申请实现方式提供了一种新的事件消息管理方法，请参见图2，该事件消息管理方法涉及的架构包括事件发布者、事件轻量级总线(EventLightBus)、多个情报站(InformationStation)。

其中，事件发布者用于发布事件消息，并将事件消息发布至事件轻量级总线，事件消息包括事件过滤条件(ACTION)和事件内容(Object)。

事件轻量级总线用于存储多个情报站和事件发布者发送来的事件消息，并且根据事件过滤条件轮询情报站，以匹配对应的目标情报站，并将事件消息发送给目标情报站，实现事件发布者与情报站之间事件消息的传递。

需要理解的是，本申请实现方式中的事件轻量级总线也可以称为事件总线，由于其对应的代码内容逻辑相比于前述现有技术中的事件总线更为简单，所以此处称其为事件轻量级总线，以用于与现有技术进行区别。

情报站用于接收事件轻量级总线发送来的特定事件消息，并且根据对应的事件消息接收模式将事件消息回调给对应的事件订阅者。如此，实现事件发布者与事件订阅者之间事件消息的传递。需要说明的是，本实现方式中，一个类只能对应一个情报站，即一个情报站通常对应于一个事件订阅者，事件订阅者为用于接收事件消息的类。当然，在本申请的另一些实现方式中，一个情报站也可以对应于多个事件订阅者，其可以根据需要选择和设置。

事件轻量级总线实现事件发布者和事件订阅者之间的事件消息传递的过程可以是：

用于接收事件消息的类，作为接收事件消息的一方，即作为事件接收者，向事件轻量级总线注册情报站(即注册情报站类)。事件轻量级总线保存情报站，从而实现情报站的注册。

本实现方式中，可以通过创建者模式(Builder Pattern，也可以称为构建者模式)对应的创建方法(例如builder方法)为用于接收事件消息的类创建情报站，并且一个类只能对应一个情报站，即一个事件订阅者对应一个情报站，则说明该事件轻量级总线可以是单例模式。其中，创建者模式是一直软件设计模式，其核心思想是将一个“复杂对象的构建算法”与它的“部件及组装方式”分离，使得构件算法和组装方式可以独立应对变化；复用同样的构建算法可以创建不同的表示，不同的构建过程可以复用相同的部件组装方式，此处不再对通过创建者模式创建情报站的过程做详细说明。

本实现方式中，事件轻量级总线以map格式存储情报站对应的情报站信息，该情报站信息包括情报站标识信息、过滤条件(ACTION)信息和事件消息接收模式信息。其中，情报站标识信息通过Key存储，过滤条件(ACTION)信息和事件消息接收模式信息通过value存储。

示例性的，情报站信息可以如下表所示：

其中，Key根据用于接收事件消息的类订阅的类确定，Key例如可以包括情报站创建的时候传入的类的包名和类名。如此，可以保证Key唯一。

进一步地，对于一个MainActivity类，若其写在包名是：com.pyh.event的包下，则其对应的key可以是com.pyh.event.MainActivity。若其写在包名是：com.and.event的包下，则其对应的key可以是com.and.event.MainActivity。若MainActivity在一个内部类MyThread里注册，则其对应的key可以是com.pyh.event.MainActivity.MyThread。

则上表所示的Key1例如可以是com.pyh.event.MainActivity，Key2例如可以是com.and.event.MainActivity，Key3例如可以是com.pyh.event.MainActivity.MyThread。当然，Key1、Key2和Key3也可以是其他类的包名和类名，其可以根据需要选择和设置。

过滤条件(ACTION，或者action)即为事件过滤条件，用于匹配事件消息的来源(即事件发布者)和接收(即情报站，可以理解为事件消息的去处)，即作为接收事件消息时的过滤条件用，用于确定接收事件消息的情报站。过滤条件(ACTION)可以只设置一个，也可以设置多个，其可以根据需要具体选择和设置。另外，过滤条件(ACTION)可以根据事件消息对应的业务类型信息(即要实现的功能或者业务)确定。该事件消息对应的业务类型信息也可以理解为事件发布者对应的业务类型信息，或者事件订阅者对应的业务类型信息等。当然，也可以以其他信息确定，其可以根据需要选择和设置。

进一步地，如上表所示，其中ACTION1可以是“下载进度”，ACTION2可以是“推送消息”等。

本申请实现方式中，事件消息接收模式为主线程接收模式、子线程接收模式和跟随线程接收模式三种模式中的任意一种。

其中，主线程接收模式指的是，若事件发布者通过主线程向事件轻量级总线发送事件消息，即事件消息发布在主线程，则在主线程中执行主线程接收模式对应的事件消息处理方法，以使目标情报站通过事件消息处理方法将事件消息回调给对应的事件订阅者。若事件发布者通过子线程发布向事件轻量级总线发送事件消息，即事件消息发布在子线程，则也在主线程中执行主线程接收模式对应的事件消息处理方法，以使目标情报站通过事件消息处理方法将事件消息回调给对应的事件订阅者。即，若事件消息接收模式为主线程接收模式，则不论事件发布者在主线程还是子线程发布事件消息，都是在主线程中执行对应的事件消息处理方法，即事件订阅者总是从主线程去接收或者获取事件消息。

子线程接收模式指的是，若事件发布者通过主线程向事件轻量级总线发送事件消息，即事件消息发布在主线程，则通过主线程创建新的子线程，并在子线程中执行子线程接收模式对应的事件消息处理方法，以使目标情报站通过事件消息处理方法将事件消息回调给对应的事件订阅者。若事件发布者通过子线程向事件轻量级总线发送事件消息，即事件消息发布在子线程，则在子线程中执行子线程接收模式对应的事件消息处理方法，以使目标情报站通过事件消息处理方法将事件消息回调给对应的事件订阅者。即，若事件消息接收模式为子线程接收模式，则不论事件消息发布在主线程还是子线程，都在相应的子线程中执行对应的事件消息处理方法，即事件订阅者总是从子线程去接收或者获取事件消息。

跟随线程接收模式指的是，若事件发布者通过主线程向事件轻量级总线发送事件消息，即事件消息发布在主线程，则在主线程中执行跟随线程接收模式对应的事件消息处理方法，以使目标情报站通过事件消息处理方法将事件消息回调给对应的事件订阅者。若事件发布者通过子线程向事件轻量级总线发送事件消息，即事件消息发布在子线程，则在子线程中执行跟随线程接收模式对应的事件消息处理方法，以使目标情报站通过事件消息处理方法将事件消息回调给对应的事件订阅者。即，事件消息的接收线程与发布线程对应，事件订阅者是从发布事件消息的相同线程去接收或者获取事件消息。

本申请实现方式中，可以根据事件消息对应的业务类型信息确定事件消息接收模式和/或事件消息对应的事件处理耗时信息确定，即可以根据事件消息要实现的业务或者功能，或者事件处理耗时等信息，定义对应的事件消息接收模式。例如，如果事件消息用于更新用户界面(User Interface，UI)，则对应的事件消息接收模式可以是主线程接收模式，如此，可以保证UI界面的顺利更新。如果事件消息需要进行耗时操作，即事件消息对应的事件处理耗时较长，则对应的事件消息接收模式可以是子线程接收模式，如此，可以保证不同的事件消息在对应的子线程中进行操作，可以避免线程阻塞的问题。

另外，在设置事件消息接收模式的时候，还可以注意以下事项：用户界面显示相关的事件消息可以通过主线程进行处理，数据库等功能相关的事件消息可以通过子线程进行处理。另外，对于事件处理耗时较长的事件，可以尽量避免在主线程或者跟随线程中执行其事件消息处理方法，以避免阻塞事件消息传递的问题。对于UI更新操作相关的事件消息，可以尽量避免在子线程中执行其事件消息处理方法。

需要说明的是，本实现方式中，事件消息接收模式可以理解为情报站接收事件消息的回调接口方法，前述三种事件消息接收模式可以分别理解为是三个类接口。另外，事件消息处理方法也可以称为事件消息回调函数等，例如可以是图2所示的onEventReceive方法。

进一步地，本实现方式中，对于主线程接收模式，可以通过在方法.setRecerveMessage(作为事件消息处理方法函数的一种示例)中设置EventMainCallback回调的方式进行定义；对于子线程接收模式，可以通过在方法.setRecerveMessage中设置EventThreadCallback回调的方式进行定义；对于跟随线程接收模式，可以通过在方法.setRecerveMessage中设置EventFlowCallback回调的方式进行定义。如此，即可以方便地完成对事件消息接收模式的定义。

本实现方式中，事件轻量级总线用于存储前述情报站信息，以及存储事件发布者发布来的事件消息。

后续，事件轻量级总线实现事件发布者和情报站之间的事件消息传递的过程可以是：

事件发布者通过事件发布方法(例如postEvent方法)将事件消息发送给事件轻量级总线。事件消息包括事件内容(Object)和过滤条件(ACTION)。

事件轻量级总线接收事件消息，根据过滤条件(ACTION)与前述以map格式存储的情报站信息中的过滤条件(ACTION)进行匹配，以轮询情报站，匹配到过滤条件(ACTION)的情报站即为订阅了该事件消息的目标情报站，从而可以过滤出接收事件消息的目标情报站。另外，事件轻量级总线可以根据情报站信息确定该目标情报站接收事件消息的事件消息接收模式。

然后，事件轻量级总线确定事件发布者发布事件消息的线程，并且根据事件发布者发布事件消息的线程和事件消息接收模式，确定对应事件消息处理方法的执行线程，该执行线程也可以理解为事件订阅者获取事件消息的线程。

事件轻量级总线在该确定的执行线程中执行事件消息处理方法，从而使得情报站可以通过该事件消息处理方法将事件消息回调回去(即回调给事件订阅者)，从而实现事件轻量级总线将事件发布者发送来的事件消息发送给事件订阅者。例如，若事件消息接收模式为主线程接收模式，则不论事件发布者将事件消息发布在主线程还是子线程，都是在主线程中执行情报站对应的事件消息处理方法，以使事件订阅者通过主线程获取事件消息。

事件订阅者接收到事件消息后，对接收到的事件消息进行相应的处理，以实现事件消息对应的功能。

请参见图3，本实现方式中，事件轻量级总线类似于生活场景中的邮件派送汽车，情报站类似于收件地点，事件消息类似于邮件，事件消息的过滤条件(ACTION)类似于邮票(邮票中包括收件地点信息)。事件发布者每发布一次事件消息，作为邮件派送汽车的事件轻量级总线会轮循一遍作为收件地点的情报站，匹配作为邮票的过滤条件(ACTION)，若事件消息中携带的过滤条件(ACTION)和情报站注册时候所注册的过滤条件(ACTION)一致，则事件轻量级总线确定该情报站为目标情报站，并且把事件消息传递给该目标情报站。

或者，本实现方式中，事件轻量级总线类似于生活场景中的公交汽车，情报站类似于汽车站点，事件消息类似于乘客，事件消息的过滤条件(ACTION)类似于车票(车票中包括乘客的目的地址信息)。事件发布者每发布一次事件消息，作为公交汽车的事件轻量级总线会轮循一遍作为汽车站点的情报站，匹配作为车票的过滤条件(ACTION)，若事件消息中携带的过滤条件(ACTION)和情报站注册时候所注册的过滤条件(ACTION)一致，则事件轻量级总线确定该情报站为目标情报站，并且把事件消息传递给该目标情报站。

即，本实现方式中，只有事件消息中携带的过滤条件(ACTION)和注册时候所注册的过滤条件(ACTION)一致的情报站，才会接收到事件消息。

进一步地，如图3所示，例如事件轻量级总线上注册了情报站1(InformationStation1)、情报站2(InformationStation2)、情报站3(InformationStation3)和情报站4(InformationStation4)四个情报站，其中：

以情报站1为例，情报站1对应的情报站信息包括事件消息接收模式“EventCallback接收事件消息回调”，过滤条件(ACTION)“String[]过滤条件集合”，以及事件内容(Object)“Object事件消息携带的事件内容”。

另外，情报站2对应的情报站信息包括事件消息接收模式“EventMainCallback(即主线程接收模式)”，“String[]＝ACTION1，ACTION2”，以及事件内容(Object)“Object＝2”。

情报站3对应的情报站信息包括事件消息接收模式“EventFolwCallback(即跟随线程接收模式)”，过滤条件(ACTION)“String[]＝”，以及事件内容(Object)“Object＝Object”。

情报站4对应的情报站信息包括事件消息接收模式“EventThreadCallback(即子线程接收模式)”，过滤条件(ACTION)“String[]＝ACTION1”，以及事件内容(Object)“Object＝null”。

需要说明的是，事件消息中的事件内容(Object)可以带数据，也可以不带数据，即事件内容(Object)可以为空，也可以不为空，其可以根据需要具体设置。

另外，上述情报站1、情报站2、情报站3和情报站4对应的情报站信息，还包括情报站对应的key(即情报站标识信息)，此处未示出。

本实现方式中，上述ACTION1，ACTION2等ACTION信息可以根据需要具体设置。

本实现方式提供的事件消息管理方法，可以实现应用的不同类之间事件消息的传递，从而可以实现不同类之间传递的事件消息的解耦，以及实现相应代码的解耦，可以简化不同类之前事件消息的传递。其中，发布事件消息的类作为事件发布者，接收事件消息的类作为事件订阅者，并且创建和注册对应的情报站。并且，本实现方式提供的基于事件轻量级总线的事件消息管理架构，其内部实现原理比较简单，代码实现也较为简单，通过传入参数(ACTION)就可以方便地确定对应的目标情报站，并且由于是预先设置好的固定的情报站类，使得确定事件消息对应的事件接收(即情报站)也比较容易，只需要找情报站就可以，更容易开发人员理解、使用和维护，并且事件消息管理的效率更高。

另外，作为事件接收的情报站只接收过滤条件(ACTION)匹配成功的事件消息，类似于广播原理，实现更为简单，更符合事件消息传递的场景需要，即可以更为准确地将事件消息发送给对应的情报站，并且可以满足不同场景的需要。

并且，若后期需要新增事件消息，只需添加对应的过滤条件(ACTION)即可，不会影响原有的逻辑和回调，便于开发人员进行后续的代码维护。

进一步地，情报站可以在很多类或者组件等需要接收事件消息的地方进行注册。例如，可以是活动(activity)、fragment，也可以是子线程，或者类对象等。注销的时候，只需要在activity、fragment或类对象调用相应的注销方法就可以实现注销。

本申请实现方式提供的事件消息管理方法，可以应用于前台页面监听后台数据变化(例如数据下载)和数据的传递等事件消息的管理场景。其中，后台任务对应的后台任务线程作为事件发布者，前台页面对应的前台页面线程作为事件订阅者，并且创建和注册对应的情报站。即需要在前台页面对应的前台页面线程中创建情报站，并且使得情报站在事件轻量级总线进行注册，事件轻量级总线保存情报站。例如，后台任务线程下载应用，并且下载到80％，若前台页面需要显示下载进度。则后台任务线程发布事件消息至事件轻量级总线，该事件消息包括事件内容(Object)“80％”和过滤条件(ACTION)“下载进度”。事件轻量级总线接收事件消息，根据过滤条件(ACTION)与前述情报站信息中的过滤条件(ACTION)，通过例如sendActionStation等方法进行匹配，确定接收该事件消息的情报站为情报站2。并且，确定情报站对应的事件订阅者的事件消息接收模式为主线程接收模式，则在主线程中执行对应的事件消息处理方法，以使情报站2通过事件消息处理方法将事件消息回调给事件订阅者。

本申请实现方式提供的事件消息管理方法，也可以应用于后台任务状态变化显示到活动(activity)前台页面(view)的事件消息管理场景，即后台任务线程通过事件消息的形式发送数据到页面层。其中，后台任务对应的后台任务线程作为事件发布者，活动前台页面对应的前台页面线程作为事件订阅者，并且创建和注册对应的情报站。

本申请实现方式提供的事件消息管理方法，可以应用于页面1内容变化，页面2关联内容也需要变化的事件消息管理场景。其中，页面1对应的线程作为事件发布者，页面2对应的线程作为事件订阅者，并且创建和注册对应的情报站。

本申请实现方式提供的事件消息管理方法，可以应用于数据的传递和消息的传递等事件消息管理场景。例如类之间的数据传递，或者应用内部组件、模块之间的数据传递等。。

本申请实现方式提供的事件消息管理方法，可以应用于延时消息发送相关的事件消息管理场景，或者替代应用内广播和handler的使用等。当然，本申请实现方式提供的事件消息管理方法，还可以应用于其他应用的其他功能模块、组件、类之间的事件消息的传递，用于实现模块之间或类之间传递事件消息的解耦，或者应用于应用与系统服务之间的事件消息的传递，或者应用于其他场景中的事件消息的传递等，以用于实现代码解耦，其可以根据需要具体选择和设置。

本实现方式图2和图3所示的事件消息管理架构和其对应的事件消息管理方法，相比于前述图1所示的事件消息管理架构和其对应的事件消息管理方法，存在以下优点：

关于事件消息的订阅者：本实现方式图2和图3所示的事件轻量级总线订阅的是情报站，其中情报站的创建依附于当前类，情报站的key包括情报站构建时候传入类的包名和类名，是固定并且唯一的。相比于图1所示的事件总线订阅事件类(即当前类对象)，并且事件类的名称是开发人员随意命名的方式。可以使得情报站的key的确定更加有规律，便于后续代码的维护。

关于接收事件消息和发送事件消息：本实现方式图2和图3所示的事件轻量级总线中，情报站创建的时候会设置过滤条件(ACTION)，并且在后续事件消息传递的过程中，只有与事件消息中的过滤条件(ACTION)匹配上的情报站才能收到事件消息，即通过方法传入参数过滤条件(ACTION)来匹配事件消息的来源和接收，其实现原理类似于广播。相比于图1所示的事件总线需要开发人员自定义事件类，并且事件消息处理方法也是开发人员自己随意命名并需要通过注释框架添加注释实现事件订阅者的注册的方式。可以简化代码，并且方便开发人员理解。另外，不需要通过反射、注释框架等方式确定事件订阅者相关的信息，并且由于代码实现更为简单，并且内部原理更为简单，可以提升事件消息的处理效率。作为事件接收的情报站只接收过滤条件(ACTION)匹配成功的事件消息，类似于广播原理，实现更为简单，比起图1所示的事件订阅者接收所有的事件类的方式，更符合事件消息传递的场景需要，并且可以满足不同场景的需要。

进一步地，后续情报站若需要订阅新的事件消息，只需要为情报站配置对应的新增过滤条件(ACTION)即可，或者后续情报站若需要取消订阅一些事件消息，只需要删减情报站配置对应的过滤条件(ACTION)即可。事件轻量级总线传递事件消息的时候，直接根据过滤条件(ACTION)强转对应的事件消息给情报站。如此，可以方便开发人员进行后续的代码维护。

请参见图4，本申请提供一种事件消息管理方法，应用于电子设备，该方法包括以下步骤：

S110，事件发布者确定事件消息，并将事件消息发送给对应的事件轻量级总线。

其中，事件消息包括事件过滤条件和事件内容，其中事件过滤条件可以是前述的“下载进度”等，事件内容可以是“80％”等。

S120，事件轻量级总线接收事件发布者发送来的事件消息，根据事件消息中的事件过滤条件，和事件轻量级总线存储的情报站信息，确定事件消息对应的目标情报站。

其中，情报站信息包括至少一个已在事件轻量级总线注册的情报站的情报站标识信息、事件过滤条件和事件消息接收模式，一个情报站至少对应于一个事件订阅者。

S130，事件轻量级总线将事件消息发送给目标情报站，以使目标情报站按照对应的事件消息接收模式将事件消息回调给对应的事件订阅者。

例如，通过前述在主线程中执行主线程接收模式对应的事件消息处理方法，以使目标情报站通过事件消息处理方法将事件消息回调给对应的事件订阅者(例如前台页面)。

需要说明的是，本实现方式中，各步骤的具体实现过程，前述已有详细说明，此处不再赘述。

进一步地，需要说明的是，本申请实现方式中，事件总线接收到事件消息后，可以先将事件消息存放至消息队列中，然后按照事件消息加入队列的时间，依次读取对应的事件消息，并完成对应事件消息的分发。或者按照事件消息的优先级进行事件消息的分发。

另外，本申请实现方式中，情报站还可以通过取消注册的方法传入情报站创建的时候传入的类以取消事件订阅，即注销注册。

本实现方式中，事件轻量级总线是线程处理等信息的处理总线，用于实现前述事件消息发布以及接收线程的管理等。另外，事件轻量级总线中，事件消息的实体是事件内容(Object)，事件发布者自己向事件轻量级总线传递消息实体，情报站接收到的事件消息也是事件内容(Object)。另外，事件轻量级总线可以是观察者模式。

需要说明的是，前述事件发布者也可以称为事件发送者或者事件发布对象等，情报站也可以称为情报接收站，事件订阅者也可以称为事件接收者或者事件订阅对象等，事件轻量级总线也可以称为轻量级事件总线、事件调度中心等，事件消息也可以称为情报、情报消息等，事件消息接收模式也可以是主线程接收模式、子线程接收模式和跟随线程接收模式以外的其他模式，其皆可以根据需要选择和设置。

另外，本申请实现方式提供的事件消息管理方法，可以应用于应用的不同类之间(即不同类对象之间，或者也可以是不同线程、组件、功能模块之间等)传递的事件消息的管理，事件订阅者位于电子设备的应用层，则可以为应用层中作为事件订阅者的某个应用的类，创建事件轻量级总线以及注册前述的情报站等，以实现事件消息的分发等管理。例如，可以在前台页面线程中创建事件轻量级总线注册以及前述的情报站等。

当然，本申请实现方式提供的事件消息管理方法，也可以应用于电子设备的框架层和系统层等层内的事件消息传递的管理，或者应用于电子设备的应用层、框架层、系统层等层之间的事件消息传递的管理，因此可以为其他层的类创建事件轻量级总线以及注册前述的情报站等，以实现事件消息的分发等管理，其可以根据需要选择和设置。

请参见图5，图5所示为根据本申请的一种实现方式提供的SoC(System on Chip，片上系统)1000的结构示意图。在图5，相似的部件具有同样的附图标记。另外，虚线框是更先进的SoC 1000的可选特征。该SoC 1000可以被用于根据本申请的任一电子设备，根据其所在的设备不同以及其内所存储的指令的不同，可以实现相应的功能。

在图5中，SoC1000包括：互连单元1002，其被耦合至处理器1001；系统代理单元1006；总线控制器单元1005；集成存储器控制器单元1003；一组或一个或多个协处理器1007，其可包括集成图形逻辑、图像处理器、音频处理器和视频处理器；静态随机存取存储器(Static Random-Access Memory，SRAM)单元1008；直接存储器存取(Direct MemoryAccess，DMA)单元1004。在一个实施例中，协处理器1007包括专用处理器，诸如例如网络或通信处理器、压缩引擎、GPGPU、高吞吐量MIC处理器、或嵌入式处理器等等。

SRAM单元1008中可以包括用于存储数据和/或指令的一个或多个计算机可读介质。计算机可读存储介质中可以存储有指令，具体而言，存储有该指令的暂时和永久副本。该指令可以包括：由处理器1001中的至少一个单元执行时导致电子设备实施如前述所提到的事件消息管理方法的指令。

需要说明的是，术语“第一”、“第二”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

需要说明的是，在附图中，可以以特定布置和/或顺序示出一些结构或方法特征。然而，应该理解，可能不需要这样的特定布置和/或排序。而是，在一些实施例中，这些特征可以以不同于说明性附图中所示的方式和/或顺序来布置。另外，在特定图中包括结构或方法特征并不意味着暗示在所有实施例中都需要这样的特征，并且在一些实施例中，可以不包括这些特征或者可以与其他特征组合。

虽然通过参照本申请的某些实现方式，已经对本申请进行了图示和描述，但本领域的普通技术人员应该明白，以上内容是结合具体的实现方式对本申请所作的进一步详细说明，不能认定本申请的具体实施只局限于这些说明。本领域技术人员可以在形式上和细节上对其作各种改变，包括做出若干简单推演或替换，而不偏离本申请的精神和范围。

Claims (12)

1.一种事件消息管理方法，其特征在于，应用于电子设备，所述方法包括：

事件发布者确定事件消息，并将所述事件消息发送给对应的事件轻量级总线，所述事件消息包括事件过滤条件和事件内容，所述事件过滤条件根据所述事件消息对应的业务类型确定；

所述事件轻量级总线接收所述事件发布者发送来的事件消息，根据所述事件消息中的所述事件过滤条件，和所述事件轻量级总线存储的情报站信息，确定所述事件消息对应的目标情报站，其中，所述情报站信息包括至少一个已在所述事件轻量级总线注册的情报站的情报站标识信息、事件过滤条件和事件消息接收模式，一个情报站至少对应于一个事件订阅者；并且

所述事件轻量级总线将所述事件消息发送给所述目标情报站，以使所述目标情报站按照对应的事件消息接收模式将所述事件消息回调给对应的事件订阅者。

2.根据权利要求1所述的事件消息管理方法，其特征在于，所述事件消息接收模式包括主线程接收模式、子线程接收模式和跟随线程接收模式中的任意一种。

3.根据权利要求2所述的事件消息管理方法，其特征在于，若所述事件消息接收模式为所述主线程接收模式，以使所述目标情报站按照对应的事件消息接收模式将所述事件消息回调给对应的事件订阅者，包括：

在主线程中执行所述主线程接收模式对应的事件消息处理方法，以使所述目标情报站通过所述事件消息处理方法将所述事件消息回调给对应的事件订阅者。

4.根据权利要求2所述的事件消息管理方法，其特征在于，若所述事件消息接收模式为所述子线程接收模式，以使所述目标情报站按照对应的事件消息接收模式将所述事件消息回调给对应的事件订阅者，包括：

若所述事件发布者在主线程发送所述事件消息，则创建新的子线程，并在所述子线程中执行所述子线程接收模式对应的事件消息处理方法，以使所述目标情报站通过所述事件消息处理方法将所述事件消息回调给对应的事件订阅者；

若所述事件发布者在子线程发送所述事件消息，则在所述子线程中执行所述子线程接收模式对应的事件消息处理方法，以使所述目标情报站通过所述事件消息处理方法将所述事件消息回调给对应的事件订阅者。

5.根据权利要求2所述的事件消息管理方法，其特征在于，若所述事件消息接收模式为所述跟随线程接收模式，以使所述目标情报站按照对应的事件消息接收模式将所述事件消息回调给对应的事件订阅者，包括：

若所述事件发布者在主线程发送所述事件消息，则在所述主线程中执行所述跟随线程接收模式对应的事件消息处理方法，以使所述目标情报站通过所述事件消息处理方法将所述事件消息回调给对应的事件订阅者；

若所述事件发布者在子线程发送所述事件消息，则在所述子线程中执行所述跟随线程接收模式对应的事件消息处理方法，以使所述目标情报站通过所述事件消息处理方法将所述事件消息回调给对应的事件订阅者。

6.根据权利要求1-5任意一项所述的事件消息管理方法，其特征在于，所述事件消息接收模式根据所述事件消息对应的所述业务类型确定，和/或根据所述事件消息对应的事件处理耗时信息确定。

7.根据权利要求1-6任意一项所述的事件消息管理方法，其特征在于，所述情报站基于创建者模式对应的创建方法创建。

8.根据权利要求1-7任意一项所述的事件消息管理方法，其特征在于，所述事件消息接收模式通过事件消息处理方法函数定义。

9.根据权利要求1-8任意一项所述的事件消息管理方法，其特征在于，所述方法还包括：

通过map格式存储所述情报站信息。

10.根据权利要求9所述的事件消息管理方法，其特征在于，所述情报站标识信息通过所述map的键存储，并且所述情报站标识信息包括情报站创建时传入的类的包名和类名，所述事件过滤条件和事件消息接收模式通过所述map的值存储。

11.一种电子设备，其特征在于，包括：

存储器，用于存储计算机程序，所述计算机程序包括程序指令；

处理器，用于执行所述程序指令，以使所述电子设备执行如权利要求1-10任意一项所述的事件消息管理方法。

12.一种计算机可读取存储介质，其特征在于，所述计算机可读取存储介质存储有计算机程序，所述计算机程序包括程序指令，所述程序指令被电子设备运行以使所述电子设备执行如权利要求1-10任意一项所述的事件消息管理方法。

Images