一种数据处理方法、装置、终端及存储介质与流程

1.本发明涉及数据处理领域，尤其涉及的是一种数据处理方法、装置、终端及存储介质。


背景技术：

2.在android企业级工程开发过程中，消息的分发是很重要的一个环节，优秀的消息分发方案可以大大增加开发效率。eventbus是一种用于android的事件发布
‑
订阅总线，主要功能是线程之间传递消息。eventbus可以简化应用程序内各个组件之间进行通信的复杂度，尤其是碎片之间进行通信的问题，可以避免由于使用广播通信而带来的诸多不便。
3.然而，现有的基于eventbus实现的消息分发方案，在订阅消息之前需要先在eventbus进行注册，在发送消息之后需要在eventbus解除注册。由于现有的基于eventbus实现的消息分发方案必须经过繁琐的注册和注销的步骤，因此导致工程存在内存泄漏的风险。
4.因此，现有技术还有待改进和发展。


技术实现要素：

5.本发明要解决的技术问题在于，针对现有技术的上述缺陷，提供一种数据处理方法、装置、终端及存储介质，旨在解决现有的基于eventbus实现的消息分发方案必须经过繁琐的注册和注销的步骤，因此导致工程存在内存泄漏的风险。
6.本发明解决问题所采用的技术方案如下：
7.第一方面，本发明实施例提供一种数据处理方法，其中，所述方法包括：
8.获取请求数据，根据所述请求数据查询目标消息容器；
9.当查询成功时，从所述目标消息容器中获取与所述请求数据对应的目标消息；
10.获取所述请求数据对应的数据类别，根据所述数据类别对所述目标消息进行处理。
11.在一种实现方式中，所述根据所述请求数据查询目标消息容器，包括：
12.获取所述请求数据中的消息类名；
13.获取预设的消息容器映射关系；
14.从预设的消息容器映射关系中查询与所述消息类名对应的所述目标消息容器。
15.在一种实现方式中，所述根据所述数据类别对所述目标消息进行处理，包括：
16.当所述数据类别为监听类别时，对所述目标消息进行监听，得到所述目标消息对应的更新信息。
17.在一种实现方式中，所述根据所述数据类别对所述目标消息进行处理，包括：
18.当所述数据类别为发送类别时，对所述目标消息进行审查；
19.当所述目标消息通过所述审查时，发送所述目标消息。
20.在一种实现方式中，所述对所述目标消息进行审查，包括：
21.将所述目标消息对应的代码作为待核查代码；
22.获取所述目标消息对应的审查机制代码；
23.根据所述审查机制代码对所述待核查代码进行审查。
24.在一种实现方式中，所述发送所述目标消息，包括：
25.获取所述目标消息对应的订阅者名单数据；
26.根据所述订阅者名单数据发送所述目标消息。
27.在一种实现方式中，所述根据所述订阅者名单数据发送所述目标消息，包括：
28.获取所述订阅者名单数据中每一订阅者对应的生命周期状态信息；
29.将所述生命周期状态信息为活动状态的所述订阅者作为目标订阅者；
30.将所述目标消息发送至所述目标订阅者。
31.第二方面，本发明实施例还提供一种数据处理装置，其中，所述装置包括：
32.查询模块，用于获取请求数据，根据所述请求数据查询目标消息容器；
33.获取模块，用于当查询成功时，从所述目标消息容器中获取与所述请求数据对应的目标消息；
34.处理模块，用于获取所述请求数据对应的数据类别，根据所述数据类别对所述目标消息进行处理。
35.第三方面，本发明实施例还提供一种终端，其中，所述终端包括有存储器，以及一个或者一个以上的程序，其中一个或者一个以上程序存储于存储器中，且经配置以由一个或者一个以上处理器执行所述一个或者一个以上程序包含用于执行如上述任一所述的数据处理方法。
36.第四方面，本发明实施例还提供一种计算机可读存储介质，其上存储有多条指令，其中，所述指令适用于由处理器加载并执行，以实现上述任一所述的数据处理方法的步骤。
37.本发明的有益效果：本发明实施例通过获取请求数据，根据所述请求数据查询目标消息容器；当查询成功时，从所述目标消息容器中获取与所述请求数据对应的目标消息；获取所述请求数据对应的数据类别，根据所述数据类别对所述目标消息进行处理。本发明在进行订阅消息和发送消息时，只需要生成相应的请求数据，根据该请求数据查询待目标消息容器，并直接使用目标消息容器拿到该消息进行订阅或者发送，而不需要在eventbus进行注册和注销，因此可以有效解决现有的基于eventbus实现的消息分发方案必须经过繁琐的注册和注销的步骤，因此导致工程存在内存泄漏的风险。
附图说明
38.为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
39.图1是本发明实施例提供的数据处理方法的流程示意图。
40.图2是本发明实施例提供的对目标消息进行监听的流程示意图。
41.图3是本发明实施例提供的对目标消息进行发送的流程示意图。
42.图4是本发明实施例提供的消息作用域的参考图。
43.图5是本发明实施例提供的数据处理装置的内部模块连接图。
44.图6是本发明实施例提供的终端的原理框图。
具体实施方式
45.为使本发明的目的、技术方案及优点更加清楚、明确，以下参照附图并举实施例对本发明进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。
46.需要说明，若本发明实施例中有涉及方向性指示(诸如上、下、左、右、前、后
……
)，则该方向性指示仅用于解释在某一特定姿态(如附图所示)下各部件之间的相对位置关系、运动情况等，如果该特定姿态发生改变时，则该方向性指示也相应地随之改变。
47.在android企业级工程开发过程中，消息的分发是很重要的一个环节，优秀的消息分发方案可以大大增加开发效率。eventbus是一种用于android的事件发布
‑
订阅总线，主要功能是线程之间传递消息。eventbus可以简化应用程序内各个组件之间进行通信的复杂度，尤其是碎片之间进行通信的问题，可以避免由于使用广播通信而带来的诸多不便。
48.现有的基于eventbus实现的消息分发方案主要具有以下缺陷：
49.1.需要注册和注销，工程会有内存泄漏的风险。
50.2.eventbus发送消息成指数增长，增加出错的风险。
51.3.定位消息发送位置较为复杂。
52.4.eventbus每个事件都是单独一个类，维护较为困难。
53.5.消息没有作用域限制。
54.6.消息没有业务控制的审查机制。
55.概括地讲，现有的基于eventbus实现的消息分发方案，在订阅消息之前需要先在eventbus进行注册，在发送消息之后需要在eventbus解除注册。由于现有的基于eventbus实现的消息分发方案必须经过繁琐的注册和注销的步骤，因此导致工程存在内存泄漏的风险。
56.针对现有技术的上述缺陷，本发明提供一种数据处理方法，所述方法包括：获取请求数据，根据所述请求数据查询目标消息容器；当查询成功时，从所述目标消息容器中获取与所述请求数据对应的目标消息；获取所述请求数据对应的数据类别，根据所述数据类别对所述目标消息进行处理。本发明在进行订阅消息和发送消息时，只需要生成相应的请求数据，根据该请求数据查询待目标消息容器，并直接使用目标消息容器拿到该消息进行订阅或者发送，而不需要在eventbus进行注册和注销，因此可以有效解决现有的基于eventbus实现的消息分发方案必须经过繁琐的注册和注销的步骤，因此导致工程存在内存泄漏的风险。
57.如图1所示，所述方法包括如下步骤：
58.步骤s100、获取请求数据，根据所述请求数据查询目标消息容器。
59.具体地，本实施例预先创建了多个消息容器，每个消息容器中都可以容纳有多条消息，维护效率较高。当用户需要订阅或者发送某一条消息时，会先生成该消息对应的请求数据，并将该请求数据发送给终端，使终端根据该请求数据查询存储有该消息的消息容器，并将查询出来的消息容器作为目标消息容器。
60.在一种实现方式中，如图4所示，每一消息容器具有其对应的消息作用域。其中，消息作用域共有两种类别，一种是全局消息作用域，一种是局部消息作用域。全局消息作用域可以在整个工程范围内发送和订阅消息，局部消息作用域只可以在指定的模块内部发送和订阅消息。
61.在一种实现方式中，所述根据所述请求数据查询目标消息容器，具体包括如下步骤：
62.步骤s101、获取所述请求数据中的消息类名；
63.步骤s102、获取预设的消息容器映射关系；
64.步骤s103、从预设的消息容器映射关系中查询与所述消息类名对应的所述目标消息容器。
65.具体地，请求数据中除了包含有相应的控制指令以外，还包含有用户请求订阅或者发送的消息对应的消息类名。终端获取到该请求数据以后，对该请求数据进行分析，即得到该消息类名。然后，终端会调取预先存储的消息容器映射关系，由于该消息容器映射关系可以反映不同消息类名与消息容器之间的对应关系，因此根据得到的消息类名和消息容器映射关系，即可查询到存储有用户请求订阅/发送的消息所对应的目标消息容器。
66.举例说明，如图2或者图3所示，假设用户请求订阅或者发送消息m，则请求数据中将包含有消息m对应的消息类名，终端获取到该请求数据中的消息类名后，即在预先存储的消息容器映射关系中查询消息m对应的消息容器，若查询成功，则将查询得到的消息容器作为消息m对应的目标消息容器。
67.如图1所示，所述方法还包括如下步骤：
68.步骤s200、当查询成功时，从所述目标消息容器中获取与所述请求数据对应的目标消息。
69.具体地，当查询成功时，表示存在该请求数据对应的目标消息容器，即用户请求订阅/发送的消息为历史消息，因此可以直接从目标消息容器中获得用户请求订阅/发送的消息，即得到目标消息。
70.如图1所示，所述方法包括如下步骤：
71.步骤s300、获取所述请求数据对应的数据类别，根据所述数据类别对所述目标消息进行处理。
72.由于用户可以订阅消息，即对某一条消息进行监听，以实时获得该消息的更新情况；用户也可以发送消息，即将某一条消息发送给其他的订阅者，以实现消息共享。因此请求数据对应的数据类别，可以反映用户期望对目标消息执行的具体操作，即反映用户期望对目标消息执行订阅操作还是执行发送操作，从而使得终端对目标消息进行不同的处理。
73.在一种实现方式中，所述步骤s300具体包括如下步骤：
74.步骤s301、当所述数据类别为监听类别时，对所述目标消息进行监听，得到所述目标消息对应的更新信息。
75.具体地，当请求数据对应的数据类别为监听类别时，表示用户期望对目标消息进行监听，以实时得到目标消息对应的更新信息。则终端会根据该目标消息的生成相应的监听事件，并将用户设置为监听者，当终端根据监听事件得到目标消息对应的更新信息以后，就会将该更新信息传递给监听者，以使得用户可以及时得知目标消息的更新(如图2所示)。
76.在一种实现方式中，所述步骤s300具体包括如下步骤：
77.步骤s302、当所述数据类别为发送类别时，对所述目标消息进行审查；
78.步骤s303、当所述目标消息通过所述审查时，发送所述目标消息。
79.具体地，当请求数据对应的数据类别为发送类别时，表示用户期望将目标消息发送给其他的订阅者，使其他订阅者可以查看到该目标消息。在本实施例中，业务端不需要考虑初始化问题，基于android contentprovider实现无感知初始化，并且每条消息的发送都可以控制logcat的输出代码行数，并直接跳转到该行代码调试。因此终端在发送该目标消息之前，需要目标消息进行审查，确保其对应的代码正确。只有当目标消息通过审查以后，终端才会发送该目标消息给其他订阅者(如图3所示)。
80.在一种实现方式中，所述对所述目标消息进行审查，具体包括如下步骤：
81.步骤s3021、将所述目标消息对应的代码作为待核查代码；
82.步骤s3022、获取所述目标消息对应的审查机制代码；
83.步骤s3023、根据所述审查机制代码对所述待核查代码进行审查。
84.具体地，本实施例在业务端创建每一个消息时，都会同时创建该消息对应的审查机制代码，该审查机制代码可以反映该消息对应的审查逻辑，从而根据该审查逻辑对该消息进行审查，经过该审查逻辑的审查可以确定该消息是否符合规范，从而实现对消息的选择性发送，即不符合规范的消息拒绝发送，符合规范的消息进行发送。
85.在一种实现方式中，所述发送所述目标消息，具体包括如下步骤：
86.步骤s3031、获取所述目标消息对应的订阅者名单数据；
87.步骤s3032、根据所述订阅者名单数据发送所述目标消息。
88.具体地，为了控制消息指数增长通知，本实施例在创建每一条消息时会同时设置可以接收到该消息的订阅者名单数据。因此当用户需要对目标消息进行发送时，终端会先获取到该目标消息对应的订阅者名单，再根据订阅者名单数据对该目标消息进行选择性地发送。由于本实施例是基于订阅者名单数据发送目标消息，而不是像现有的基于eventbus实现的消息分发方法中基于java反射调用发送目标消息，因此可以有效地控制消息指数增长通知。
89.在一种实现方式中，所述根据所述订阅者名单数据发送所述目标消息，包括：获取所述订阅者名单数据中每一订阅者对应的生命周期状态信息；将所述生命周期状态信息为活动状态的所述订阅者作为目标订阅者；将所述目标消息发送至所述目标订阅者。
90.由于随着时间变化，有部分原本存在于订阅者名单数据上的订阅者可能已经消亡了，因此将目标消息发送给订阅者名单数据中的每一订阅者是不现实的。所以本实施例在发送目标消息之前，需要先获取订阅者名单数据中每一订阅者的生命周期状态信息，该生命周期状态信息可以反映该订阅者目前的存在状态，如果该订阅者的生命周期状态信息为消亡状态，表示该订阅者已经不存在了，如果该订阅者的生命周期状态信息为活动状态，表示该订阅者现在还存在。因此本实施例将生命周期状态信息为活动状态的订阅者筛选出来，作为目标订阅者，并将目标消息发送至每一目标订阅者，从而避免对已经不存在的订阅者发送消息。
91.在一种实现方式中，所述将所述目标消息发送至所述目标订阅者之前还包括：获取预设的发送频率映射表，根据所述发送频率映射表确定每一目标订阅者对应的发送频
率，根据所述发送频率从所述目标订阅者中选择出有效订阅者，将所述目标消息发送至所述有效订阅者。从而避免livedata粘性消息的问题。
92.在一种实现方式中，所述方法还包括如下步骤：
93.步骤s1、当未查询成功时，根据所述消息类名创建与所述请求数据对应的新增消息容器；
94.步骤s3、获取预设的容器映射关系，在所述容器映射关系中添加所述消息类名和所述新增消息容器的对应关系。
95.具体地，当未查询成功时，表示用户请求订阅/发送的消息为新的消息，之前未存储过该消息，则根据预设的网络密钥(default_key)和请求数据中的消息类名，自动创建一个新增消息容器，该新增消息容器即用于存储请求数据对应的消息数据。此外，还需要在原先的容器映射关系中添加该消息类名与新增消息容器之间的对应关系，以供下次获取使用。
96.本发明实施例相较于现有的基于eventbus实现的消息分发方案所具有的优势为：
97.1.不会发生内存泄漏；
98.2.不会因activity停止而导致崩溃；
99.3.不需要手动处理生命周期；
100.4.数据始终会保持最新状态；
101.5.可以编写消息容器，控制消息作用域；
102.6.业务添加审查逻辑，控制消息发送入口；
103.7.基于jetpack库，无需引入其他三方库；
104.8.无需注册、注销、减少代码风险；
105.9.log定位，每一条消息都可以直接定位到发送代码位置，方便调试。
106.基于上述实施例，本发明还提供了一种数据处理装置，如图5所示，所述装置包括：
107.查询模块01，用于获取请求数据，根据所述请求数据查询目标消息容器；
108.获取模块02，用于当查询成功时，从所述目标消息容器中获取与所述请求数据对应的目标消息；
109.处理模块03，用于获取所述请求数据对应的数据类别，根据所述数据类别对所述目标消息进行处理。
110.在一种实现方式中，所述查询模块01包括：
111.拆包单元，用于获取所述请求数据中的消息类名；
112.获取单元，用于获取预设的消息容器映射关系；
113.查询单元，用于从预设的消息容器映射关系中查询与所述消息类名对应的所述目标消息容器。
114.在一种实现方式中，所述处理模块03包括：
115.监听单元，用于当所述数据类别为监听类别时，对所述目标消息进行监听，得到所述目标消息对应的更新信息；
116.审查单元，用于当所述数据类别为发送类别时，对所述目标消息进行审查；
117.发送单元，用于当所述目标消息通过所述审查时，发送所述目标消息。
118.基于上述实施例，本发明还提供了一种终端，其原理框图可以如图6所示。该终端
包括通过系统总线连接的处理器、存储器、网络接口、显示屏。其中，该终端的处理器用于提供计算和控制能力。该终端的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统和计算机程序。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该终端的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现数据处理方法。该终端的显示屏可以是液晶显示屏或者电子墨水显示屏。
119.本领域技术人员可以理解，图6中示出的原理框图，仅仅是与本发明方案相关的部分结构的框图，并不构成对本发明方案所应用于其上的终端的限定，具体的终端可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。
120.在一种实现方式中，所述终端的存储器中存储有一个或者一个以上的程序，且经配置以由一个或者一个以上处理器执行所述一个或者一个以上程序包含用于进行数据处理方法的指令。
121.本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本发明所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(rom)、可编程rom(prom)、电可编程rom(eprom)、电可擦除可编程rom(eeprom)或闪存。易失性存储器可包括随机存取存储器(ram)或者外部高速缓冲存储器。作为说明而非局限，ram以多种形式可得，诸如静态ram(sram)、动态ram(dram)、同步dram(sdram)、双数据率sdram(ddrsdram)、增强型sdram(esdram)、同步链路(synchlink)dram(sldram)、存储器总线(rambus)直接ram(rdram)、直接存储器总线动态ram(drdram)、以及存储器总线动态ram(rdram)等。
122.综上所述，本发明公开了一种数据处理方法、装置、终端及存储介质，所述方法包括：获取请求数据，根据所述请求数据查询目标消息容器；当查询成功时，从所述目标消息容器中获取与所述请求数据对应的目标消息；获取所述请求数据对应的数据类别，根据所述数据类别对所述目标消息进行处理。本发明在进行订阅消息和发送消息时，只需要生成相应的请求数据，根据该请求数据查询待目标消息容器，并直接使用目标消息容器拿到该消息进行订阅或者发送，而不需要在eventbus进行注册和注销，因此可以有效解决现有的基于eventbus实现的消息分发方案必须经过繁琐的注册和注销的步骤，因此导致工程存在内存泄漏的风险。
123.应当理解的是，本发明的应用不限于上述的举例，对本领域普通技术人员来说，可以根据上述说明加以改进或变换，所有这些改进和变换都应属于本发明所附权利要求的保护范围。