CN111835700B - 一种数据处理方法、装置、电子设备及存储介质 - Google Patents

一种数据处理方法、装置、电子设备及存储介质 Download PDF

Info

Publication number
CN111835700B
CN111835700B CN201911229011.6A CN201911229011A CN111835700B CN 111835700 B CN111835700 B CN 111835700B CN 201911229011 A CN201911229011 A CN 201911229011A CN 111835700 B CN111835700 B CN 111835700B
Authority
CN
China
Prior art keywords
state data
data
target
compression
state
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201911229011.6A
Other languages
English (en)
Other versions
CN111835700A (zh
Inventor
李新虎
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Didi Infinity Technology and Development Co Ltd
Original Assignee
Beijing Didi Infinity Technology and Development Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing Didi Infinity Technology and Development Co Ltd filed Critical Beijing Didi Infinity Technology and Development Co Ltd
Priority to CN201911229011.6A priority Critical patent/CN111835700B/zh
Publication of CN111835700A publication Critical patent/CN111835700A/zh
Application granted granted Critical
Publication of CN111835700B publication Critical patent/CN111835700B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/04—Protocols for data compression, e.g. ROHC
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/302—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system component is a software system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3065—Monitoring arrangements determined by the means or processing involved in reporting the monitored data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00—Reducing energy consumption in communication networks
    • Y02D30/50—Reducing energy consumption in communication networks in wire-line communication networks, e.g. low power modes or reduced link rate

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computing Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Signal Processing (AREA)
  • Quality & Reliability (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Mathematical Physics (AREA)
  • Computer Hardware Design (AREA)
  • Debugging And Monitoring (AREA)

Abstract

本申请提供了一种数据处理方法、装置、电子设备及存储介质，其中，该数据处理方法包括：获取目标应用程序在运行过程中产生的状态数据，所述状态数据包括所述目标应用程序在启动至少一个目标监测事件后，每个目标监测事件的运行状态信息；对获取到的状态数据按照目标压缩方式进行数据压缩，得到压缩状态数据；将所述压缩状态数据和所述目标压缩方式发送至后台服务器；所述目标压缩方式用于所述后台服务器确定对应的解压缩方式，基于确定的解压缩方式对所述压缩状态数据进行解压，以确定所述目标监测事件的运行状态。本申请降低了对数据传输信道的占用率，从而减少对信道资源的消耗。

Description

一种数据处理方法、装置、电子设备及存储介质
技术领域
本申请涉及数据处理技术领域，具体而言，涉及一种数据处理方法、装置、电子设备及存储介质。
背景技术
随着互联网和计算机的高速发展，使用应用程序(Application，APP)的客户端越来越普及，例如APP客户端和便携智能设备、传统计算机上安装的各类软件和应用服务。
一般APP上市前或者升级后，需要对该应用程序的运行状态进行监控，便于及时对APP进行修正，企业在针对移动终端上的APP监控时，常常采用在APP内部埋点的方式，来获取APP在运行时产生的运行数据，这些运行数据中有些数据为大概率连续型数据，也可以称为状态数据，比如，监测车辆里程数据的监测事件的运行状态，这些数据需要向后台服务器及时反馈，以便后台服务器用来确定APP中一些重要功能的运行情况，从而便于后台服务器在确定APP出现故障时，及时采取相应的改进或者修正方案。
目前，通常采取按照较短的时间间隔直接将状态数据发送至后台服务器，存在当数据传输过程中对数据传输信道的占用率高，资源消耗率较大的问题。
发明内容
有鉴于此，本申请的目的在于提供一种数据处理方法、装置、电子设备及存储介质，降低了对数据传输信道的占用率，从而减少对信道资源的消耗。
第一方面，本申请实施例提供了一种数据处理方法，应用于终端设备，所述数据处理方法包括：
获取目标应用程序在运行过程中产生的状态数据，所述状态数据包括所述目标应用程序在启动至少一个目标监测事件后，每个目标监测事件的运行状态信息；
对获取到的状态数据按照目标压缩方式进行数据压缩，得到压缩状态数据；
将所述压缩状态数据和所述目标压缩方式发送至后台服务器；所述目标压缩方式用于所述后台服务器确定对应的解压缩方式，基于确定的解压缩方式对所述压缩状态数据进行解压，以确定所述目标监测事件的运行状态。
在一些实施方式中，所述目标应用程序为出行应用程序，所述目标监测事件包括监测车辆里程数据、监测车辆行驶速度数据和监测车辆行程价格数据。
在一些实施方式中，所述目标监测事件包括多个，所述目标压缩方式为包括第一数据压缩和第二数据压缩的二次压缩方式，所述对获取到的状态数据按照目标压缩方式进行数据压缩，得到压缩状态数据，包括：
针对每个目标监测事件对应的至少一条状态数据，对该至少一条状态数据进行第一数据压缩，得到该目标监测事件对应的中间压缩状态数据；
将多个目标监测事件对应的中间压缩状态数据进行第二数据压缩，得到最终压缩后的所述压缩状态数据；所述第二数据压缩为打包压缩。
在一些实施方式中，所述状态数据中包含属性标签，针对每个目标监测事件对应的至少一条状态数据，对该至少一条状态数据进行第一数据压缩，得到该目标监测事件对应的中间压缩状态数据，包括：
针对所述状态数据中包含的每个属性标签，按照该属性标签对应的标识字符对该属性标签进行替换，以缩短所述状态数据所占用的字节长度；和/或，
对该目标监测事件对应的状态数据中的设定位置的字符进行删除，以缩短所述状态数据所占用的字节长度。
在一些实施方式中，所述将多个目标监测事件对应的中间压缩状态数据进行第二数据压缩之前，还包括：
判断所述中间压缩状态数据中是否包含所述终端设备对应的用户信息；
若包含，则对所述用户信息进行加密处理。
第二方面，本申请实施例提供了一种数据处理方法，应用于后台服务器，所述数据处理方法包括：
接收到终端设备上传的压缩状态数据和目标压缩方式后，按照与所述目标压缩方式对应的解压方式对所述压缩状态数据进行解压，得到目标应用程序启动的每个目标监测事件的状态数据；所述状态数据中包含该状态数据产生的时间戳和状态码；
基于每个目标监测事件的状态数据对应的所述时间戳、所述状态码的类型和设定次数阈值，确定所述目标监测事件在被触发后，目标类型的状态码对应的运行状态是否存在。
在一些实施方式中，所述目标压缩方式包括第一数据压缩和第二数据压缩，所述按照与所述目标压缩方式对应的解压方式对所述压缩状态数据进行解压，包括：
对所述压缩状态数据按照与所述第二数据压缩对应的第二解压方式进行数据解压，得到各个目标监测事件对应的中间压缩状态数据；
针对每个目标监测事件对应的中间压缩状态数据，按照与该目标监测事件的第一数据压缩对应的第一解压方式，对该目标监测事件对应的中间压缩状态数据进行解压，得到与各个目标监测事件对应的解压后的状态数据。
在一些实施方式中，所述针对每个目标监测事件对应的中间压缩状态数据，按照与该目标监测事件的第一数据压缩对应的第一解压方式，对该目标监测事件对应的中间压缩状态数据进行解压，得到与各个目标监测事件对应的解压后的状态数据之前，所述数据处理方法还包括：
判断所述中间压缩状态数据中是否包含加密后的用户信息；
若包含，基于所述目标压缩方式确定所述用户信息对应的加密算法，按照所述加密算法对应的解密算法对所述加密后的用户信息进行解密处理。
在一些实施方式中，所述中间压缩状态数据包含多个标识字符，针对每个目标监测事件对应的中间压缩状态数据，按照与该目标监测事件的第一数据压缩对应的第一解压方式，对该目标监测事件对应的中间压缩状态数据进行解压，得到与各个目标监测事件对应的解压后的状态数据，包括：
针对所述中间压缩状态数据中包含的每个标识字符，按照该标识字符对应的属性标签对该标识字符进行替换，以还原所述中间压缩状态数据中表征所述属性标签的字符所占用的字节长度；和/或，
在该目标监测事件对应的中间压缩状态数据中的设定位置处添加与该设定位置对应的字符，以还原设定位置处的字符所占用的字节长度。
在一种实施方式中，所述状态数据包括多条，所述基于每个目标监测事件的状态数据对应的所述时间戳、所述状态码的类型和设定次数阈值，确定所述目标监测事件在被触发后，目标类型的状态码对应的运行状态是否存在，包括：
基于每条状态数据包含的时间戳和状态码，确定所述目标类型的状态码对应的至少一个连续次数；
判断所述至少一个连续次数中的最大值是否达到所述设定次数阈值；
在确定所述至少一个连续次数中的最大值达到所述设定次数阈值时，确定所述目标监测事件在被触发后，该目标类型的状态码对应的运行状态存在。
在一些实施方式中，所述基于每条状态数据包含的时间戳和状态码，确定所述目标类型的状态码对应的至少一个连续次数，包括：
按照每条状态数据包含的时间戳，对多条所述状态数据进行排序，得到包含所述状态数据的第一序列以及每条状态数据在所述第一序列中对应的序列号；
对所述第一序列中包含相同状态码的状态数据按照该状态数据对应的时间戳进行序号更新，得到包含对应序列号更新后的状态数据的第二序列以及每条状态数据在所述第二序列中对应的序列号；
将第一序列中的每条状态数据对应的序列号与第二序列中的该条状态数据对应的序列号作差，得到每条状态数据对应的序列号差值；
将所述目标类型的状态码对应的同一序列号差值的重复次数，作为所述目标类型的状态码对应的至少一个连续次数。
第三方面，本申请实施例提供了一种数据处理装置，驻留于终端设备，所述数据处理装置包括：
获取模块，用于获取目标应用程序在运行过程中产生的状态数据，所述状态数据包括所述目标应用程序在启动至少一个目标监测事件后，每个目标监测事件的运行状态信息；
压缩模块，用于对获取到的状态数据按照目标压缩方式进行数据压缩，得到压缩状态数据；
发送模块，用于将所述压缩状态数据和所述目标压缩方式发送至后台服务器；所述目标压缩方式用于所述后台服务器确定对应的解压缩方式，基于确定的解压缩方式对所述压缩状态数据进行解压，以确定所述目标监测事件的运行状态。
在一些实施方式中，所述目标应用程序为出行应用程序，所述目标监测事件包括监测车辆里程数据、监测车辆行驶速度数据和监测车辆行程价格数据。
在一些实施方式中，所述目标监测事件包括多个，所述目标压缩方式为包括第一数据压缩和第二数据压缩的二次压缩方式，所述压缩模块在用于对获取到的状态数据按照目标压缩方式进行数据压缩，得到压缩状态数据时，包括：
针对每个目标监测事件对应的至少一条状态数据，对该至少一条状态数据进行第一数据压缩，得到该目标监测事件对应的中间压缩状态数据；
将多个目标监测事件对应的中间压缩状态数据进行第二数据压缩，得到最终压缩后的所述压缩状态数据；所述第二数据压缩为打包压缩。
在一些实施方式中，所述状态数据中包含属性标签，所述压缩模块在用于针对每个目标监测事件对应的至少一条状态数据，对该至少一条状态数据进行第一数据压缩，得到该目标监测事件对应的中间压缩状态数据时，包括：
针对所述状态数据中包含的每个属性标签，按照该属性标签对应的标识字符对该属性标签进行替换，以缩短所述状态数据所占用的字节长度；和/或，
对该目标监测事件对应的状态数据中的设定位置的字符进行删除，以缩短所述状态数据所占用的字节长度。
在一些实施方式中，所述压缩模块在将多个目标监测事件对应的中间压缩状态数据进行第二数据压缩之前，还用于：
判断所述中间压缩状态数据中是否包含所述终端设备对应的用户信息；
若包含，则对所述用户信息进行加密处理。
第四方面，本申请实施例提供了一种数据处理装置，驻留于后台服务器，所述数据处理装置包括：
解压模块，用于接收到终端设备上传的压缩状态数据和目标压缩方式后，按照与所述目标压缩方式对应的解压方式对所述压缩状态数据进行解压，得到目标应用程序启动的每个目标监测事件的状态数据；所述状态数据中包含该状态数据产生的时间戳和状态码；
确定模块，用于基于每个目标监测事件的状态数据对应的所述时间戳、所述状态码的类型和设定次数阈值，确定所述目标监测事件在被触发后，目标类型的状态码对应的运行状态是否存在。
在一些实施方式中，所述目标压缩方式包括第一数据压缩和第二数据压缩，所述解压模块在用于按照与所述目标压缩方式对应的解压方式对所述压缩状态数据进行解压时，包括：
对所述压缩状态数据按照与所述第二数据压缩对应的第二解压方式进行数据解压，得到各个目标监测事件对应的中间压缩状态数据；
针对每个目标监测事件对应的中间压缩状态数据，按照与该目标监测事件的第一数据压缩对应的第一解压方式，对该目标监测事件对应的中间压缩状态数据进行解压，得到与各个目标监测事件对应的解压后的状态数据。
在一些实施方式中，所述解压模块在针对每个目标监测事件对应的中间压缩状态数据，按照与该目标监测事件的第一数据压缩对应的第一解压方式，对该目标监测事件对应的中间压缩状态数据进行解压，得到与各个目标监测事件对应的解压后的状态数据之前，还用于：
判断所述中间压缩状态数据中是否包含加密后的用户信息；
若包含，基于所述目标压缩方式确定所述用户信息对应的加密算法后，按照所述加密算法对应的解密算法对所述加密后的用户信息进行解密处理。
在一些实施方式中，所述中间压缩状态数据包含多个标识字符，所述解压模块在用于针对每个目标监测事件对应的中间压缩状态数据，按照与该目标监测事件的第一数据压缩对应的第一解压方式，对该目标监测事件对应的中间压缩状态数据进行解压，得到与各个目标监测事件对应的解压后的状态数据时，包括：
针对所述中间压缩状态数据中包含的每个标识字符，按照该标识字符对应的属性标签对该标识字符进行替换，以还原所述中间压缩状态数据中表征所述属性标签的字符所占用的字节长度；和/或，
在该目标监测事件对应的中间压缩状态数据中的设定位置处添加与该设定位置对应的字符，以还原设定位置处的字符所占用的字节长度。
在一种实施方式中，所述状态数据包括多条，所述确定模块在用于基于每个目标监测事件的状态数据对应的所述时间戳、所述状态码的类型和设定次数阈值，确定所述目标监测事件在被触发后，目标类型的状态码对应的运行状态是否存在时，包括：
基于每条状态数据包含的时间戳和状态码，确定所述目标类型的状态码对应的至少一个连续次数；
判断所述至少一个连续次数中的最大值是否达到所述设定次数阈值；
在确定所述至少一个连续次数中的最大值达到所述设定次数阈值时，确定所述目标监测事件在被触发后，该目标类型的状态码对应的运行状态存在。
在一些实施方式中，所述状态数据包括多条，所述确定模块在用于基于每条状态数据包含的时间戳和状态码，确定所述目标类型的状态码对应的至少一个连续次数时，包括：
按照每条状态数据包含的时间戳，对多条所述状态数据进行排序，得到包含所述状态数据的第一序列以及每条状态数据在所述第一序列中对应的序列号；
对所述第一序列中包含相同状态码的状态数据按照该状态数据对应的时间戳进行序号更新，得到包含对应序列号更新后的状态数据的第二序列以及每条状态数据在所述第二序列中对应的序列号；
将第一序列中的每条状态数据对应的序列号与第二序列中的该条状态数据对应的序列号作差，得到每条状态数据对应的序列号差值；
将所述目标类型的状态码对应的同一序列号差值的重复次数，作为所述目标类型的状态码对应的至少一个连续次数。
第五方面，本申请实施例提供了一种电子设备，包括：处理器、存储介质和总线，所述存储介质存储有所述处理器可执行的机器可读指令，当电子设备运行时，所述处理器与所述存储介质之间通过总线通信，所述处理器执行所述机器可读指令，以执行如第一方面或第二方面所述数据处理方法的步骤。
第六方面，本申请实施例提供了一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器运行时执行如第一方面或第二方面所述数据处理方法的步骤。
本申请实施例提供的数据处理方法，在获取到目标应用程序在运行过程中产生的状态数据后，首先对获取到的状态数据按照目标压缩方式进行数据压缩，然后再将压缩状态数据和目标压缩方式发送至后台服务器，以使后台服务器基于确定的解压缩方式对压缩状态数据进行解压后，确定目标监测事件的运行状态。
这里的状态数据为后台服务器需要及时接收，用来确定目标应用程序中一些重要功能的运行情况的数据，因此这些状态数据需要及时向后台服务器发送，比如按照较短的时间间隔向后台服务器进行发送，通过在每次发送前对这些状态数据进行数据压缩，能够降低这类数据对数据传输信道的占用率，从而降低资源消耗。
附图说明
为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。
图1示出了本申请实施例提供的一种数据处理方法的流程图；
图2示出了本申请实施例提供的另一种数据处理方法的流程图；
图3示出了本申请实施例提供的一种确定目标类型的状态码对应的运行状态是否存在的方法流程图；
图4示出了本申请实施例提供的一种数据处理装置的结构示意图；
图5示出了本申请实施例提供的另一种数据处理装置的结构示意图；
图6示出了本申请实施例提供的一种电子设备的结构示意图；
图7示出了本申请实施例提供的另一种电子设备的结构示意图。
具体实施方式
为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，应当理解，本申请中附图仅起到说明和描述的目的，并不用于限定本申请的保护范围。另外，应当理解，示意性的附图并未按实物比例绘制。本申请中使用的流程图示出了根据本申请的一些实施例实现的操作。应该理解，流程图的操作可以不按顺序实现，没有逻辑的上下文关系的步骤可以反转顺序或者同时实施。此外，本领域技术人员在本申请内容的指引下，可以向流程图添加一个或多个其他操作，也可以从流程图中移除一个或多个操作。
另外，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。
为了使得本领域技术人员能够使用本申请内容，结合特定应用场景“行车应用程序中的数据处理方法”，给出以下实施方式。对于本领域技术人员来说，在不脱离本申请的精神和范围的情况下，可以将这里定义的一般原理应用于其他实施例和应用场景。虽然本申请主要围绕行车应用程序中的数据处理方法进行描述，但是应该理解，这仅是一个示例性实施例。
需要说明的是，本申请实施例中将会用到术语“包括”，用于指出其后所声明的特征的存在，但并不排除增加其它的特征。
目前，一般应用程序上市前或者升级后，需要对该应用程序的运行状态进行监控，便于及时对应用程序进行修正，企业在针对移动终端上的应用程序监控时，常常采用在应用程序内部埋点的方式对应用程序进行监控，从而获取应用程序在运行时产生的运行数据。
在对应用程序进行监控时，有些埋点的目的是为了监控应用程序在运行过程中产生的大概率连续型数据，这些数据可以称为状态数据，表示需要向后台服务器及时反馈，使得后台服务器用来确定目标应用程序中一些重要功能的运行情况的数据，这些数据需要及时向后台服务器反馈，目前一般是按照较短的时间间隔直接发送至后台服务器，这样对于数据传输信道的占用率较高，造成资源消耗率大，针对此，本申请实施例提供了一种数据处理方法，将结合以下具体实施例进行阐述。
如图1所示，为本申请实施例提供的一种数据处理方法，应用于终端设备，该数据处理方法包括以下具体步骤S101～S103：
S101，获取目标应用程序在运行过程中产生的状态数据，状态数据包括目标应用程序在启动至少一个目标监测事件后，每个目标监测事件的运行状态信息。
这里的目标应用程序是指后台服务器需要监控的应用程序，被监测的目标应用程序在开发过程中或者升级过程中，常采用在应用程序内部埋点的方案来获取目标应用程序在被启动后产生的数据。
这里的目标应用程序可以是社交应用程序(Application，APP)，也可以是一些视频播放APP，还可以是一些其它类型的APP。
这里的状态数据是指预先设定好的特定类型的数据，这些特定类型的数据为应用程序在运行过程中产生的大概率连续型数据，具体可以指需要向后台服务器及时连续的反馈，以便后台服务器用来确定该应用程序中一些重要功能的运行情况的数据。
比如，以目标应用程序为出行应用程序为例，即目前在出行领域中，服务提供端和服务请求端上通常可以装载有出行应用程序，服务请求方比如乘客可以通过服务请求端上的出行应用程序发起出行订单，服务提供方比如司机可以通过服务提供端上的出行应用程序承接出行订单。
具体地，在车辆行驶过程中，出行应用程序还可以监测车辆运行数据，并将监测到的车辆运行数据，比如车辆里程数据、车辆速度数据和车辆行程价格数据发送至后台服务器，便于后台服务器及时掌握车辆运行状况，一般出行应用程序上市前，或者需要更新后，会在该出行应用程序进行埋点以获取出行应用程序在监测车辆运行数据时产生的状态数据，比如在出行应用程序中设置多个埋点，每个埋点即为一个目标监测事件，用于监测应用程序中该目标监测事件对应的功能在启动后产生的状态数据，比如目标监测事件包括监测车辆里程数据、监测车辆行驶速度数据和监测车辆行程价格数据。
其中，监测车辆里程数据的目标监测事件在出行应用程序启动后用于监测车辆里程变化的状态数据；监测车辆行驶速度数据的目标监测事件在出行应用程序启动后用于监测车辆行驶速度变化的状态数据；监测车辆行程价格的目标监测事件在出行应用程序启动后用于监测车辆行程价格变化的状态数据。
具体地，该出行应用程序在启动后，若针对某个目标监测事件进行了触发，则该目标监测事件会生成对应的运行状态信息，这些运行状态信息能够表征出行应用程序在运行过程中与该目标监测事件对应的运行状态，因此需要及时向后台服务器进行反馈，便于后台服务器能够基于这些运行状态信息确定出行应用程序的性能，并在出现问题时及时对该出行应用程序进行改进。
S102，对获取到的状态数据按照目标压缩方式进行数据压缩，得到压缩状态数据。
这里因为状态数据是连续型数据，且需要及时向后台服务器反馈，目前一般是按照设定时间间隔将获取到的状态数据发送至后台服务器，比如每隔一分钟向后台服务器发送一次获取到的状态数据，本申请实施例提出在向后台服务器发送之前，先对状态数据进行数据压缩，这样能够最大限度的减少对信道的占用，降低资源消耗。
进一步地，目标监测事件包括多个，目标压缩方式为包括第一数据压缩和第二数据压缩的二次压缩方式，则步骤S102中，对获取到的状态数据按照目标压缩方式进行数据压缩，得到压缩状态数据，包括：
(1)针对每个目标监测事件对应的至少一条状态数据，对该至少一条状态数据进行第一数据压缩，得到该目标监测事件对应的中间压缩状态数据；
(2)将多个目标监测事件对应的中间压缩状态数据进行第二数据压缩，得到最终压缩后的压缩状态数据；第二数据压缩为打包压缩。
具体地，在针对每个目标监测事件对应的状态数据进行第一数据压缩时，可以是按照该目标监测事件对应的第一数据压缩方式进行压缩，这里，由于不同的目标监测事件监测的事件不同，其对应的第一数据压缩方式也可能不同。
比如，包括3个目标监测事件分别记录为目标监测事件A、目标监测事件B和目标监测事件C，其中，每个目标监测事件得到3条状态数据，则这里针对目标监测事件A对应的3条状态数据按照目标监测事件A对应的第一数据压缩方式进行数据压缩，得到目标监测事件A对应的中间压缩状态数据；针对目标监测事件B对应的3条状态数据按照目标监测事件B对应的第一数据压缩方式进行数据压缩，得到目标监测事件B对应的中间压缩状态数据；针对目标监测事件C对应的3条状态数据按照目标监测事件C对应的第一数据压缩方式进行数据压缩，得到目标监测事件C对应的中间压缩状态数据。
具体地，状态数据中包含属性标签，这里的属性标签包括状态数据中的数据格式、内容等提前设置好的标签，比如可以包括状态数据的命名方式、状态数据监测的内容名称等，则上述提到的针对每个目标监测事件对应的至少一条状态数据，对该至少一条状态数据进行第一数据压缩，得到该目标监测事件对应的中间压缩状态数据，包括：
(1)针对状态数据中包含的每个属性标签，按照该属性标签对应的标识字符对该属性标签进行替换，以缩短状态数据所占用的字节长度；和/或，
(2)对该目标监测事件对应的状态数据中的设定位置的字符进行删除，以缩短状态数据所占用的字节长度。
具体这里的第一数据压缩可以包括这里的第(1)种数据压缩方式，也可以包括这里的第(2)种数据压缩方式，或者同时包括这里的第(1)种数据压缩方式和第(2)种数据压缩方式。
其中，以第(1)种数据压缩方式为例，比如状态数据中包含属性标签为“车辆的行驶速度数据”，则可以按照该属性标签对应的标识字符“1234”对该属性标签进行替换，这样就将“车辆的行驶速度数据”在状态数据中所占用的字节变为标识字符“1234”所占用的字节，即缩短了状态数据所占用的字节长度。
或者，以第(2)种数据压缩方式为例，可以对目标监测事件对应的状态数据中的设定位置的字符进行删除，这里可以指删除掉该目标监测事件对应的多条状态数据中含义一致的设定位置的字符，比如针对状态数据中时间戳的设定位置的字符进行删除，比如针对时间戳“2019年8月26日10:44:43”，因为在相同时长内采集到的该目标监测事件对应的状态数据中包含的时间戳的年月日相同，可以统一进行删除，即可以得到时间戳“10:44:43”，这样，也可以达到缩短状态数据所占用的字节长度的目的。
以上两种方式可以分别单独实施，也可以一同实施，且一同实施时，实施的先后顺序不做限定。
在对每个目标监测事件对应的状态数据进行第一数据压缩得到该目标监测事件对应的中间压缩状态数据后，可以考虑将多个目标监测事件对应的中间压缩状态数据进行进一步压缩，比如进行打包压缩，以此来进一步减少对信道的占用，降低资源消耗。
比如，还是针对上文提到的3个目标监测事件分别记录为目标监测事件A、目标监测事件B和目标监测事件C，若目标监测事件A对应的状态数据压缩后得到3条中间压缩状态数据，目标监测事件B对应的状态数据压缩后得到3条中间压缩状态数据，目标监测事件C对应的状态数据压缩后也得到3条中间压缩状态数据，则总共有9条中间压缩状态数据，此时可以对这9条中间压缩状态数据进行打包压缩，比如按照GZIP压缩技术对这9条中间压缩状态数据进行打包压缩，最终得到压缩后的压缩状态数据。
另外，为了在数据传输过程中保护用户隐私数据，这里在将多个目标监测事件对应的中间压缩状态数据进行第二数据压缩之前，还包括：
(1)判断中间压缩状态数据中是否包含终端设备对应的用户信息；
(2)若包含，则对用户信息进行加密处理。
这里的用户信息可以指用户姓名、用户手机号码、用户身份证号码、用户账号等用户隐私的数据，为了防止在数据传输过程中数据泄露导致用户信息不安全的问题，这里在对中间压缩状态数据进行第二数据压缩之前，可以对用户信息进行加密处理，当然，也可以在第一数据压缩之前对用户信息进行加密处理，在此不再赘述。
这里的加密处理可以是按照设定加密算法对用户信息进行加密，比如可以通过数据加密标准(Data Encryption Standard，DES)算法、高级加密标准(Advanced EncryptionStandard，AES)算法或者RSA加密算法进行加密处理。
S103，将压缩状态数据和目标压缩方式发送至后台服务器；目标压缩方式用于后台服务器确定对应的解压缩方式，基于确定的解压缩方式对压缩状态数据进行解压，以确定目标监测事件的运行状态。
在得到压缩状态数据后，即可以将压缩状态数据和目标压缩方式发送至后台服务器，这里的目标压缩方式可以是表示目标压缩方式的标识信息，后台服务器接收到该标识信息后，就可以确定与目标压缩方式对应的解压缩方式，然后基于确定的解压缩方式对压缩状态数据进行解压，以还原终端设备获取到的状态数据，然后进一步基于状态数据确定目标应用程序中目标监测事件的运行状态。
如图2所示，为本申请实施例提供的另一种数据处理方法，应用于后台服务器，该数据处理方法包括以下具体步骤S201～S202：
S201，接收到终端设备上传的压缩状态数据和目标压缩方式后，按照与目标压缩方式对应的解压方式对压缩状态数据进行解压，得到目标应用程序启动的每个目标监测事件的状态数据；状态数据中包含该状态数据产生的时间戳和状态码。
当终端设备的目标压缩方式包括第一数据压缩和第二数据压缩时，这里按照与目标压缩方式对应的解压方式对压缩状态数据进行解压，包括：
(1)对压缩状态数据按照与第二数据压缩对应的第二解压方式进行数据解压，得到各个目标监测事件对应的中间压缩状态数据；
(2)针对每个目标监测事件对应的中间压缩状态数据，按照与该目标监测事件的第一数据压缩对应的第一解压方式，对该目标监测事件对应的中间压缩状态数据进行解压，得到与各个目标监测事件对应的解压后的状态数据。
这里的解压缩过程与终端设备的压缩过程对应，具体地，这里的第二解压方式与压缩过程中的第二数据压缩过程对应，比如，当第二数据压缩过程为基于GZIP压缩技术进行压缩时，这里的第二解压方式即为基于GZIP解压缩技术进行解压缩，第一解压方式与压缩过程中的第一数据压缩过程对应，在整个解压过程中，首先对压缩状态数据按照第二解压方式进行解压，即可以得到各个目标监测事件对应的中间压缩状态数据，然后针对每个目标监测事件对应的中间压缩状态数据按照该目标监测事件对应的第一解压方式进行解压。
比如，针对上文在压缩过程中提到的3个目标监测事件，即目标监测事件A、目标监测事件B和目标监测事件C在某个时刻对应的压缩状态数据，首先针对该压缩状态数据按照第二解压方式，得到9条中间压缩状态数据，分别为目标监测事件A对应的3条中间压缩状态数据，目标监测事件B对应的3条中间压缩状态数据，以及目标监测事件C对应的3条中间压缩状态数据，然后再分别对这3个目标监测事件对应的中间压缩状态数据，按照与该目标监测事件的第一数据压缩对应的第一解压方式进行数据解压，进而得到与各个目标监测事件对应的解压后的状态数据。
具体地，在针对每个目标监测事件对应的中间压缩状态数据，按照与该目标监测事件的第一数据压缩对应的第一解压方式，对该目标监测事件对应的中间压缩状态数据进行解压，得到与各个目标监测事件对应的解压后的状态数据之前，数据处理方法还包括：
(1)判断中间压缩状态数据中是否包含加密后的用户信息；
(2)若包含，基于目标压缩方式确定用户信息对应的加密算法，按照加密算法对应的解密算法对加密后的用户信息进行解密处理。
这里是指在对中间压缩状态数据进行解压前，可以先判断中间压缩状态数据中是否包含加密后的用户信息，包含的话，则需要对加密后的用户信息进行解密，以便于后续确定该目标应用程序对应的用户身份。
这里可以通过目标压缩方式来确定用户信息对应的解密算法，比如目标压缩方式中可以包含加密处理的方式，比如可以包含表征加密处理方式的加密标识，比如DES算法、AES算法或者RSA加密算法分别对应的加密标识为D-1、A-1和R-1，则若目标压缩方式中携带的加密标识为D-1，则可以确定加密算法为DES算法，则这里可以按照DES算法对应的解密算法对加密后的用户信息进行解密处理。
当然，本申请实施例中的加密算法和解密算法也可以是提前设置好的，比如目标压缩方式中携带的加密标识表征默认的加密算法，则这里可以按照设置好的与默认的加密算法对应的解密算法进行解密。
在按照第二解压方式对压缩状态数据进行解压缩后，得到的每个目标监测事件对应的中间压缩状态数据可以包含多个标识字符，然后上文提到的针对每个目标监测事件对应的中间压缩状态数据，按照与该目标监测事件的第一数据压缩对应的第一解压方式，对该目标监测事件对应的中间压缩状态数据进行解压，得到与各个目标监测事件对应的解压后的状态数据，包括：
(1)针对中间压缩状态数据中包含的每个标识字符，按照该标识字符对应的属性标签对该标识字符进行替换，以还原中间压缩状态数据中表征属性标签的字符所占用的字节长度；和/或，
(2)在该目标监测事件对应的中间压缩状态数据中的设定位置处添加与该设定位置对应的字符，以还原设定位置处的字符所占用的字节长度。
在得到每个目标监测事件对应的中间压缩状态数据后，可以继续按照第一解压方式对各个目标监测事件对应的中间压缩状态数据进行进一步解压，具体这里的第一解压方式可以包括这里的第(1)种解压方式，也可以包括这里的第(2)解压种方式，或者同时包括这里的第(1)种解压方式和第(2)解压种方式。
其中，以第(1)种解压方式为例，比如针对某个中间压缩状态数据中包含的标识字符“1234”，按照该标识字符“1234”对应的属性标签“车辆的行驶速度数据”对该标识字符“1234”进行替换，这样就将该中间压缩状态数据中表征属性标签的字符“1234”所占用的字节长度还原为属性标签“车辆的行驶速度数据”所占用的字节长度，即还原了中间压缩状态数据中表征属性标签的字符所占用的字节长度。
或者，以第(2)种解压方式为例，在对目标监测事件对应的中间压缩状态数据中的设定位置处添加与该设定位置对应的字符，这里可以指添加上该目标监测事件对应的多条中间压缩状态数据中含义一致的设定位置的字符，比如针对中间压缩状态数据中表示时间戳的设定位置处的字符进行添加，比如可以在时间戳“10:44:43”之前统一添加“2019年8月26日”得到还原后的时间戳“2019年8月26日10:44:43”，这样，即还原了设定位置处的字符所占用的字节长度。
这里第一解压方式具体是单独采用第(1)种解压方式还是单独采用第(2)种解压方式，还是同时采用第(1)种解压方式和第(2)种解压方式与后台服务器接收到的终端设备上传的目标压缩方式有关，若终端设备对状态数据进行第一数据压缩时，采取的是第一数据压缩中的第(1)种数据压缩方式，则这里单独采用第(1)种解压方式对中间压缩状态数据进行解压；若终端设备对状态数据进行第一数据压缩时，采取的是第一数据压缩中的第(2)种数据压缩方式，则这里单独采用第(2)种解压方式对中间压缩状态数据进行解压；若终端设备对状态数据进行第一数据压缩时，同时采取的是第一数据压缩中的第(1)种数据压缩方式和第(2)种数据压缩方式，则这里也同时采取第(1)种解压方式和第(2)种解压方式对中间压缩状态数据进行解压，至于第(1)种解压方式和第(2)种解压方式的顺序，与按照第一数据压缩过程中，第(1)种数据压缩方式和第(2)种数据压缩方式的执行顺序对应。
在对压缩状态数据进行解压，得到每个目标监测事件的状态数据后，可以根据状态数据中包含有状态数据产生的时间戳和状态码，进一步地判断目标应用程序的运行状态。
这里的时间戳是目标监测事件对应的状态数据产生的时刻，因为状态数据是批量上报至后台服务器的，每条状态数据对应的时刻可能并不相同，这里需要依据时间戳来确定状态数据发生的先后顺序。
这里的状态码可以是在目标应用程序中进行埋点时，即布置目标监测事件时，提前设置好用于表征该目标监测事件状态的标识码，比如用状态码A来表征目标监测事件的状态为正常、用状态码B来表征目标监测事件的状态为异常。
S202，基于每个目标监测事件的状态数据对应的时间戳、状态码的类型和设定次数阈值，确定目标监测事件在被触发后，目标类型的状态码对应的运行状态是否存在。
这里状态码的类型是提前确定好并存储在后台服务器中的，比如接收到的状态数据中包含状态码B，则可以按照存储记录确定该状态码对应的类型为异常类型。
这里的设定次数阈值可以是经过前期大量数据统计得到的，比如表征某异常事件的标识连续N次出现，且N大于该设定次数阈值，则确定该异常事件存在，若表征该异常事件的标识仅仅是偶然发生，则并不能说明该异常事件发生。
具体地，状态数据包括多条，步骤S202中，基于每个目标监测事件对应的时间戳、状态码的类型和设定次数阈值，确定目标监测事件在被触发后，目标类型的状态码对应的运行状态是否存在，包括如图3所示的流程图，具体步骤包括以下步骤S301～S303：
S301，基于每条状态数据包含的时间戳和状态码，确定目标类型的状态码对应的至少一个连续次数。
这里每条状态数据中包含的时间戳即为该状态数据产生的时刻，这里确定目标类型的状态码对应的连续次数，比如服务器对压缩状态数据进行解压后，获取到20条状态数据，若按照时间戳对这20条状态数据进行排序后，发现5条连续的状态数据，均包含异常类型的状态码B，则状态码B对应的连续次数为5次。
当然，若这20条状态数据中有两条连续的状态数据，包含异常类型的状态码B，然后间隔了包含其它类型的状态码后，又发现5条连续的状态数据，均包含异常类型的状态码B，则状态码B对应的连续次数分别为2次和5次。
S302，判断至少一个连续次数中的最大值是否达到设定次数阈值。
在本申请实施例中，这里的连续次数为最高连续次数，比如针对状态码B对应的连续次数分别为2次和5次时，这里为判断连续次数5是否超过设定次数阈值。
S303，在确定至少一个连续次数中的最大值达到设定次数阈值时，确定目标监测事件在被触发后，该目标类型的状态码对应的运行状态存在。
对应的，这里在确定目标类型的状态码对应的最高连续次数达到设定次数阈值时，确定该目标类型的状态码对应的运行状态存在。
上述确定目标类型的状态码对应的连续次数的方式可以包括多种，比如，可以采用数值标记算法，即终端设备在生成每条状态数据后，对该状态数据进行编码，服务器解压获取到带有编码的状态数据后，通过编码来确定目标类型的状态码对应的连续次数，但是该方式需要在每条状态数据上额外增加编码位数，本申请实施例提出基于双指针差值计算法来确定目标类型的状态码对应的连续次数的方式，具体地，步骤S301中，基于每条状态数据包含的时间戳和状态码，确定目标类型的状态码对应的至少一个连续次数时，可以通过以下4个步骤实现：
(1)按照每条状态数据包含的时间戳，对多条状态数据进行排序，得到包含状态数据的第一序列以及每条状态数据在第一序列中对应的序列号；
(2)对第一序列中包含相同状态码的状态数据按照该状态数据对应的时间戳进行序号更新，得到包含对应序列号更新后的状态数据的第二序列以及每条状态数据在第二序列中对应的序列号；
(3)将第一序列中的每条状态数据对应的序列号与第二序列中的该条状态数据对应的序列号作差，得到每条状态数据对应的序列号差值；
(4)将目标类型的状态码对应的同一序列号差值的重复次数，作为所述目标类型的状态码对应的至少一个连续次数。
下面结合目标监测事件A对应的10条状态数据，来确定异常状态码对应的连续次数，具体结合下表1进行阐述：
表1
记录名 订单id 状态码 序列I 序列II 差值
Record1 834211134212 A 1 1 0
Record2 834211134212 A 2 2 0
Record3 834211134212 B 3 1 2
Record4 834211134212 B 4 2 2
Record5 834211134212 A 5 3 2
Record6 834211134212 B 6 3 3
Record7 834211134212 B 7 4 3
Record8 834211134212 B 8 5 3
Record9 834211134212 B 9 6 3
Record10 834211134212 B 10 7 3
如上表1所示，针对目标监测事件A，在解压后得到该目标监测事件A对应的10条状态数据，即Record1～Record10这10条状态数据，然后根据每条状态数据包含的时间戳，按照时间先后顺序对这10条状态数据进行排序，得到第一序列，第一序列中的每条状态数据的序列号逐次递增；然后对第一序列中包含相同状态码的状态数据按照该状态数据对应的时间戳进行序号更新，比如以包含状态码A的状态数据为单元，对该单元内的状态数据进行序列号更新，以及以包含状态码B的状态数据为单元，对该单元内的状态数据进行序列号更新。
在对包含状态码A的状态数据进行序列号更新时，若遇到包含其它类型的状态码的状态数据，则直接跳过，同理，在对包含状态码B的状态数据进行更新时，若遇到包含其它类型的状态码的状态数据，也直接跳过，按照该方式对第一序列中的序列号进行更新，得到第二序列。
然后将第一序列中的每条状态数据对应的序列号与第二序列中的该条状态数据对应的序列号作差，即可以得到每条状态数据对应的序列号差值，进一步通过判断同一类型的状态码对应的同一序列号差值的重复次数，即可以确定该类型的状态码的连续次数，比如，由上述表1可知，包含状态码A的状态数据出现一个2次连续，包含状态码B的状态数据出现一个2次连续，一个5次连续。
这里即将状态码B对应的连续次数分别为2次和5次，进一步地，则可以判断这里包含状态码B对应的连续次数中的最大值5次是否达到设定次数阈值，若达到，则确定状态码B对应的运行状态存在，否则，则不存在。
本申请实施例采用的双指针差值计算法可以在统计算法层面进行优化，优于常用的数值标记算法，该方法在计算资源占用量和灵活性上更具有优势。
另外，采用上述双指针差值计算法统计出包含每种状态码的状态数据的重复次数后，可以对各个状态码对应的重复次数进行分布统计，以便于后续基于分布统计结果对该目标应用程序进行状态分析，在此不做具体阐述。
本申请实施例提供的该数据处理方法，在接收到终端设备上传的压缩状态数据和目标压缩方式后，可以按照与目标压缩方式对应的解压方式对压缩状态数据进行解压，得到目标应用程序启动的每个目标监测事件的状态数据，然后基于每个目标监测事件对应的状态数据中包含该状态数据产生的时间戳和状态码来进一步确定目标监测事件在被触发后，目标类型的状态码对应的运行状态是否存在，即本申请实施例能够对终端设备上传的压缩状态数据进行还原，并进一步确定目标应用程序的运行状态，这样通过移动终端来对状态数据进行压缩，后台服务器进一步对状态数据进行解压，从而降低这类数据对数据传输信道的占用率，以降低资源消耗。
基于同一发明构思，本申请实施例中还提供了与数据处理方法对应的数据处理装置，由于本申请实施例中的装置解决问题的原理与本申请实施例上述数据处理方法相似，因此装置的实施可以参见方法的实施，重复之处不再赘述。
参照图4所示，为本申请实施例提供的一种数据处理装置400的示意图，该数据处理装置驻留于终端设备，具体包括：获取模块401、压缩模块402、发送模块403。
其中，获取模块401，用于获取目标应用程序在运行过程中产生的状态数据，状态数据包括目标应用程序在启动至少一个目标监测事件后，每个目标监测事件的运行状态信息；
压缩模块402，用于对获取到的状态数据按照目标压缩方式进行数据压缩，得到压缩状态数据；
发送模块403，用于将压缩状态数据和目标压缩方式发送至后台服务器；目标压缩方式用于后台服务器确定对应的解压缩方式，基于确定的解压缩方式对压缩状态数据进行解压，以确定目标监测事件的运行状态。
在一种实施方式中，目标应用程序为出行应用程序，目标监测事件包括监测车辆里程数据、监测车辆行驶速度数据和监测车辆行程价格数据。
在一种实施方式中，目标监测事件包括多个，目标压缩方式为包括第一数据压缩和第二数据压缩的二次压缩方式，压缩模块302在用于对获取到的状态数据按照目标压缩方式进行数据压缩，得到压缩状态数据时，包括：
针对每个目标监测事件对应的至少一条状态数据，对该至少一条状态数据进行第一数据压缩，得到该目标监测事件对应的中间压缩状态数据；
将多个目标监测事件对应的中间压缩状态数据进行第二数据压缩，得到最终压缩后的压缩状态数据；第二数据压缩为打包压缩。
在一种实施方式中，状态数据中包含属性标签，压缩模块402在用于针对每个目标监测事件对应的至少一条状态数据，对该至少一条状态数据进行第一数据压缩，得到该目标监测事件对应的中间压缩状态数据时，包括：
针对状态数据中包含的每个属性标签，按照该属性标签对应的标识字符对该属性标签进行替换，以缩短状态数据所占用的字节长度；和/或，
对该目标监测事件对应的状态数据中的设定位置的字符进行删除，以缩短状态数据所占用的字节长度。
在一种实施方式中，压缩模块402在将多个目标监测事件对应的中间压缩状态数据进行第二数据压缩之前，还用于：
判断中间压缩状态数据中是否包含终端设备对应的用户信息；
若包含，则对用户信息进行加密处理。
本申请实施例提供的数据处理装置，在获取到目标应用程序在运行过程中产生的状态数据后，首先对获取到的状态数据按照目标压缩方式进行数据压缩，然后再将压缩状态数据和目标压缩方式发送至后台服务器，以使后台服务器基于确定的解压缩方式对压缩状态数据进行解压后，确定目标监测事件的运行状态。
这里的状态数据为后台服务器需要及时接收，用来确定目标应用程序中一些重要功能的运行情况的数据，因此这些状态数据需要及时向后台服务器发送，比如按照较短的时间间隔向后台服务器进行发送，通过在每次发送前对这些状态数据进行数据压缩，能够降低这类数据对数据传输信道的占用率，从而降低资源消耗。
如图5所示，为本申请实施例提供的另一种数据处理装置500，该数据处理装置500驻留于后台服务器，具体包括：
解压模块501，用于接收到终端设备上传的压缩状态数据和目标压缩方式后，按照与目标压缩方式对应的解压方式对压缩状态数据进行解压，得到目标应用程序启动的每个目标监测事件的状态数据；状态数据中包含该状态数据产生的时间戳和状态码；
确定模块502，用于基于每个目标监测事件的状态数据对应的时间戳、状态码的类型和设定次数阈值，确定目标监测事件在被触发后，目标类型的状态码对应的运行状态是否存在。
在一种实施方式中，目标压缩方式包括第一数据压缩和第二数据压缩，解压模块在用于按照与目标压缩方式对应的解压方式对压缩状态数据进行解压时，包括：
对压缩状态数据按照与第二数据压缩对应的第二解压方式进行数据解压，得到各个目标监测事件对应的中间压缩状态数据；
针对每个目标监测事件对应的中间压缩状态数据，按照与该目标监测事件的第一数据压缩对应的第一解压方式，对该目标监测事件对应的中间压缩状态数据进行解压，得到与各个目标监测事件对应的解压后的状态数据。
在一种实施方式中，解压模块501在针对每个目标监测事件对应的中间压缩状态数据，按照与该目标监测事件的第一数据压缩对应的第一解压方式，对该目标监测事件对应的中间压缩状态数据进行解压，得到与各个目标监测事件对应的解压后的状态数据之前，还用于：
判断中间压缩状态数据中是否包含加密后的用户信息；
若包含，基于目标压缩方式确定用户信息对应的加密算法后，按照加密算法对应的解密算法对加密后的用户信息进行解密处理。
在一种实施方式中，中间压缩状态数据包含多个标识字符，解压模块501在用于针对每个目标监测事件对应的中间压缩状态数据，按照与该目标监测事件的第一数据压缩对应的第一解压方式，对该目标监测事件对应的中间压缩状态数据进行解压，得到与各个目标监测事件对应的解压后的状态数据时，包括：
针对中间压缩状态数据中包含的每个标识字符，按照该标识字符对应的属性标签对该标识字符进行替换，以还原中间压缩状态数据中表征属性标签的字符所占用的字节长度；和/或，
在该目标监测事件对应的中间压缩状态数据中的设定位置处添加与该设定位置对应的字符，以还原设定位置处的字符所占用的字节长度。
在一种实施方式中，状态数据包括多条，确定模块502在用于基于每个目标监测事件的状态数据对应的时间戳、状态码的类型和设定次数阈值，确定目标监测事件在被触发后，目标类型的状态码对应的运行状态是否存在时，包括：
基于每条状态数据包含的时间戳和状态码，确定目标类型的状态码对应的至少一个连续次数；
判断至少一个连续次数中的最大值是否达到设定次数阈值；
在确定至少一个连续次数中的最大值达到设定次数阈值时，确定目标监测事件在被触发后，该目标类型的状态码对应的运行状态存在。
在一种实施方式中，状态数据包括多条，确定模块502在用于基于每条状态数据包含的时间戳和状态码，确定目标类型的状态码对应的至少一个连续次数时，包括：
按照每条状态数据包含的时间戳，对多条状态数据进行排序，得到包含状态数据的第一序列以及每条状态数据在第一序列中对应的序列号；
对第一序列中包含相同状态码的状态数据按照该状态数据对应的时间戳进行序号更新，得到包含对应序列号更新后的状态数据的第二序列以及每条状态数据在第二序列中对应的序列号；
将第一序列中的每条状态数据对应的序列号与第二序列中的该条状态数据对应的序列号作差，得到每条状态数据对应的序列号差值；
将目标类型的状态码对应的同一序列号差值的重复次数，作为目标类型的状态码对应的至少一个连续次数。
本申请实施例提供的该数据处理装置，在接收到终端设备上传的压缩状态数据和目标压缩方式后，可以按照与目标压缩方式对应的解压方式对压缩状态数据进行解压，得到目标应用程序启动的每个目标监测事件的状态数据，然后基于每个目标监测事件对应的状态数据中包含该状态数据产生的时间戳和状态码来进一步确定目标监测事件在被触发后，目标类型的状态码对应的运行状态是否存在，即本申请实施例能够对终端设备上传的压缩状态数据进行还原，并进一步确定目标应用程序的运行状态，这样通过移动终端来对状态数据进行压缩，后台服务器进一步对状态数据进行解压，从而降低这类数据对数据传输信道的占用率，以降低资源消耗。
关于装置中的各模块的处理流程、以及各模块之间的交互流程的描述可以参照上述方法实施例中的相关说明，这里不再详述。
本申请实施例还提供了一种电子设备，该电子设备可以为终端设备或者后台服务器，当该电子设备为终端设备时，如图6所示，为本申请实施例提供的电子设备600的结构示意图，包括：处理器601、存储介质602、和总线603。存储介质602存储有处理器601可执行的机器可读指令(比如，图4中的装置中获取模块401、压缩模块402、发送模块403对应的执行指令等)，当电子设备600运行时，处理器601与存储介质602之间通过总线603通信，机器可读指令被处理器601执行时执行如下处理：
获取目标应用程序在运行过程中产生的状态数据，状态数据包括目标应用程序在启动至少一个目标监测事件后，每个目标监测事件的运行状态信息；
对获取到的状态数据按照目标压缩方式进行数据压缩，得到压缩状态数据；
将压缩状态数据和目标压缩方式发送至后台服务器；目标压缩方式用于后台服务器确定对应的解压缩方式，基于确定的解压缩方式对压缩状态数据进行解压，以确定目标监测事件的运行状态。
一种可能的实施方式中，处理器601执行的指令中，目标应用程序为出行应用程序，目标监测事件包括监测车辆里程数据、监测车辆行驶速度数据和监测车辆行程价格数据。
一种可能的实施方式中，目标监测事件包括多个，处理器601执行的指令中，包括：
针对每个目标监测事件对应的至少一条状态数据，对该至少一条状态数据进行第一数据压缩，得到该目标监测事件对应的中间压缩状态数据；
将多个目标监测事件对应的中间压缩状态数据进行第二数据压缩，得到最终压缩后的压缩状态数据；第二数据压缩为打包压缩。
一种可能的实施方式中，状态数据中包含属性标签，处理器601执行的指令中，包括：
针对状态数据中包含的每个属性标签，按照该属性标签对应的标识字符对该属性标签进行替换，以缩短状态数据所占用的字节长度；和/或，
对该目标监测事件对应的状态数据中的设定位置的字符进行删除，以缩短状态数据所占用的字节长度。
一种可能的实施方式中，将多个目标监测事件对应的中间压缩状态数据进行第二数据压缩之前，处理器601执行的指令中，还包括：
判断中间压缩状态数据中是否包含终端设备对应的用户信息；
若包含，则对用户信息进行加密处理。
当该电子设备为后台服务器时，如图7所示，为本申请实施例提供的电子设备700的结构示意图，包括：处理器701、存储介质702、和总线703。存储介质702存储有处理器701可执行的机器可读指令(比如，图5中的装置中解压模块501、确定模块502对应的执行指令等)，当电子设备700运行时，处理器701与存储介质702之间通过总线703通信，机器可读指令被处理器701执行时执行如下处理：
接收到终端设备上传的压缩状态数据和目标压缩方式后，按照与目标压缩方式对应的解压方式对压缩状态数据进行解压，得到目标应用程序启动的每个目标监测事件的状态数据；状态数据中包含该状态数据产生的时间戳和状态码；
基于每个目标监测事件的状态数据对应的时间戳、状态码的类型和设定次数阈值，确定目标监测事件在被触发后，目标类型的状态码对应的运行状态是否存在。
一种可能的实施方式中，目标压缩方式包括第一数据压缩和第二数据压缩，处理器701执行的指令中，包括：
对压缩状态数据按照与第二数据压缩对应的第二解压方式进行数据解压，得到各个目标监测事件对应的中间压缩状态数据；
针对每个目标监测事件对应的中间压缩状态数据，按照与该目标监测事件的第一数据压缩对应的第一解压方式，对该目标监测事件对应的中间压缩状态数据进行解压，得到与各个目标监测事件对应的解压后的状态数据。
一种可能的实施方式中，处理器701执行的指令中，还包括：
针对每个目标监测事件对应的中间压缩状态数据，按照与该目标监测事件的第一数据压缩对应的第一解压方式，对该目标监测事件对应的中间压缩状态数据进行解压，得到与各个目标监测事件对应的解压后的状态数据之前，判断中间压缩状态数据中是否包含加密后的用户信息；
若包含，基于目标压缩方式确定用户信息对应的加密算法，按照加密算法对应的解密算法对加密后的用户信息进行解密处理。
一种可能的实施方式中，中间压缩状态数据包含多个标识字符，处理器701执行的指令中，包括：
针对中间压缩状态数据中包含的每个标识字符，按照该标识字符对应的属性标签对该标识字符进行替换，以还原中间压缩状态数据中表征属性标签的字符所占用的字节长度；和/或，
在该目标监测事件对应的中间压缩状态数据中的设定位置处添加与该设定位置对应的字符，以还原设定位置处的字符所占用的字节长度。
一种可能的实施方式中，状态数据包括多条，处理器701执行的指令中，包括：
基于每条状态数据包含的时间戳和状态码，确定目标类型的状态码对应的至少一个连续次数；
判断至少一个连续次数中的最大值是否达到设定次数阈值；
在确定至少一个连续次数中的最大值达到设定次数阈值时，确定目标监测事件在被触发后，该目标类型的状态码对应的运行状态存在。
一种可能的实施方式中，处理器701执行的指令中，包括：
按照每条状态数据包含的时间戳，对多条状态数据进行排序，得到包含状态数据的第一序列以及每条状态数据在第一序列中对应的序列号；
对第一序列中包含相同状态码的状态数据按照该状态数据对应的时间戳进行序号更新，得到包含对应序列号更新后的状态数据的第二序列以及每条状态数据在第二序列中对应的序列号；
将第一序列中的每条状态数据对应的序列号与第二序列中的该条状态数据对应的序列号作差，得到每条状态数据对应的序列号差值；
将目标类型的状态码对应的同一序列号差值的重复次数，作为目标类型的状态码对应的至少一个连续次数。
本申请实施例还提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行上述数据处理方法的步骤。
具体地，该存储介质能够为通用的存储介质，如移动磁盘、硬盘等，该存储介质上的计算机程序被运行时，能够执行上述数据处理方法，从而降低对数据传输信道的占用率，减少对信道资源的消耗。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的***和装置的具体工作过程，可以参考方法实施例中的对应过程，本申请中不再赘述。在本申请所提供的几个实施例中，应该理解到，所揭露的***、装置和方法，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，所述模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，又例如，多个模块或组件可以结合或者可以集成到另一个***，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，装置或模块的间接耦合或通信连接，可以是电性，机械或其它的形式。
所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个处理器可执行的非易失的计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。
以上仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。

Claims (20)

1.一种数据处理方法，其特征在于，应用于终端设备，所述数据处理方法包括：
获取目标应用程序在运行过程中产生的状态数据，所述状态数据包括所述目标应用程序在启动至少一个目标监测事件后，每个目标监测事件的运行状态信息，其中，所述状态数据包括用于表示所述目标应用程序中的功能的运行情况，以便对所述目标应用程序进行修正，所述状态数据为大概率连续型数据；
对获取到的状态数据按照目标压缩方式进行数据压缩，得到压缩状态数据；
将所述压缩状态数据和所述目标压缩方式发送至后台服务器；所述目标压缩方式用于所述后台服务器确定对应的解压缩方式，基于确定的解压缩方式对所述压缩状态数据进行解压，以确定所述目标监测事件的运行状态；
其中，所述目标监测事件的运行状态是所述后台服务器基于判断目标类型的状态码对应的至少一个连续次数中的最大值是否达到设定次数阈值得到的，所述目标类型的状态码对应的至少一个连续次数是所述后台服务器基于解压得到的每条状态数据中的时间戳和状态码确定的，在所述目标类型的状态码对应的至少一个连续次数达到所述设定次数阈值的情况下，确定所述目标监测时间被触发，则该目标类型的状态码对应的运行状态存在；所述目标类型的状态码对应的至少一个连续次数为所述目标类型的状态码对应的同一序列号差值的重复次数，每条状态数据对应的序列号差值是将第一序列中的每条状态数据对应的序列号与第二序列中的该条状态数据对应的序列号作差得到的，所述状态数据的第一序列以及每条状态数据在所述第一序列中对应的序列号是按照每条状态数据包含的时间戳，对多条所述状态数据进行排序得到的，包含对应序列号更新后的状态数据的第二序列以及每条状态数据在所述第二序列中对应的序列号是对所述第一序列中包含相同状态码的状态数据按照该状态数据对应的时间戳进行序号更新得到的。
2.根据权利要求1所述的数据处理方法，其特征在于，所述目标应用程序为出行应用程序，所述目标监测事件包括监测车辆里程数据、监测车辆行驶速度数据和监测车辆行程价格数据。
3.根据权利要求1所述的数据处理方法，其特征在于，所述目标监测事件包括多个，所述目标压缩方式为包括第一数据压缩和第二数据压缩的二次压缩方式，所述对获取到的状态数据按照目标压缩方式进行数据压缩，得到压缩状态数据，包括：
针对每个目标监测事件对应的至少一条状态数据，对该至少一条状态数据进行第一数据压缩，得到该目标监测事件对应的中间压缩状态数据；
将多个目标监测事件对应的中间压缩状态数据进行第二数据压缩，得到最终压缩后的所述压缩状态数据；所述第二数据压缩为打包压缩。
4.根据权利要求3所述的数据处理方法，其特征在于，所述状态数据中包含属性标签，针对每个目标监测事件对应的至少一条状态数据，对该至少一条状态数据进行第一数据压缩，得到该目标监测事件对应的中间压缩状态数据，包括：
针对所述状态数据中包含的每个属性标签，按照该属性标签对应的标识字符对该属性标签进行替换，以缩短所述状态数据所占用的字节长度；和/或，
对该目标监测事件对应的状态数据中的设定位置的字符进行删除，以缩短所述状态数据所占用的字节长度。
5.根据权利要求3所述的数据处理方法，其特征在于，所述将多个目标监测事件对应的中间压缩状态数据进行第二数据压缩之前，还包括：
判断所述中间压缩状态数据中是否包含所述终端设备对应的用户信息；
若包含，则对所述用户信息进行加密处理。
6.一种数据处理方法，其特征在于，应用于后台服务器，所述数据处理方法包括：
接收到终端设备上传的压缩状态数据和目标压缩方式后，按照与所述目标压缩方式对应的解压方式对所述压缩状态数据进行解压，得到目标应用程序启动的每个目标监测事件的状态数据；所述状态数据中包含该状态数据产生的时间戳和状态码，其中，所述状态数据包括用于表示所述目标应用程序中的功能的运行情况，以便对所述目标应用程序进行修正，所述状态数据为大概率连续型数据；
基于每个目标监测事件的状态数据对应的所述时间戳、所述状态码的类型和设定次数阈值，确定所述目标监测事件在被触发后，目标类型的状态码对应的运行状态是否存在；
其中，所述状态数据包括多条，所述基于每个所述目标监测事件的状态数据对应的所述时间戳、所述状态码的类型和设定次数阈值，确定所述目标监测事件在被触发后，目标类型的状态码对应的运行状态是否存在，包括：
当基于每条所述状态数据中的时间戳和所述状态码，确定出所述目标类型的状态码对应的至少一个连续次数中的最大值达到所述设定次数阈值时，则确定所述目标监测事件在被触发后，该目标类型的状态码对应的运行状态存在；
所述基于每条状态数据包含的时间戳和状态码，确定所述目标类型的状态码对应的至少一个连续次数，包括：
按照每条状态数据包含的时间戳，对多条所述状态数据进行排序，得到包含所述状态数据的第一序列以及每条状态数据在所述第一序列中对应的序列号；
对所述第一序列中包含相同状态码的状态数据按照该状态数据对应的时间戳进行序号更新，得到包含对应序列号更新后的状态数据的第二序列以及每条状态数据在所述第二序列中对应的序列号；
将第一序列中的每条状态数据对应的序列号与第二序列中的该条状态数据对应的序列号作差，得到每条状态数据对应的序列号差值；
将所述目标类型的状态码对应的同一序列号差值的重复次数，作为所述目标类型的状态码对应的至少一个连续次数。
7.根据权利要求6所述的数据处理方法，其特征在于，所述目标压缩方式包括第一数据压缩和第二数据压缩，所述按照与所述目标压缩方式对应的解压方式对所述压缩状态数据进行解压，包括：
对所述压缩状态数据按照与所述第二数据压缩对应的第二解压方式进行数据解压，得到各个目标监测事件对应的中间压缩状态数据；
针对每个目标监测事件对应的中间压缩状态数据，按照与该目标监测事件的第一数据压缩对应的第一解压方式，对该目标监测事件对应的中间压缩状态数据进行解压，得到与各个目标监测事件对应的解压后的状态数据。
8.根据权利要求7所述的数据处理方法，其特征在于，所述针对每个目标监测事件对应的中间压缩状态数据，按照与该目标监测事件的第一数据压缩对应的第一解压方式，对该目标监测事件对应的中间压缩状态数据进行解压，得到与各个目标监测事件对应的解压后的状态数据之前，所述数据处理方法还包括：
判断所述中间压缩状态数据中是否包含加密后的用户信息；
若包含，基于所述目标压缩方式确定所述用户信息对应的加密算法，按照所述加密算法对应的解密算法对所述加密后的用户信息进行解密处理。
9.根据权利要求7所述的数据处理方法，其特征在于，所述中间压缩状态数据包含多个标识字符，针对每个目标监测事件对应的中间压缩状态数据，按照与该目标监测事件的第一数据压缩对应的第一解压方式，对该目标监测事件对应的中间压缩状态数据进行解压，得到与各个目标监测事件对应的解压后的状态数据，包括：
针对所述中间压缩状态数据中包含的每个标识字符，按照该标识字符对应的属性标签对该标识字符进行替换，以还原所述中间压缩状态数据中表征所述属性标签的字符所占用的字节长度；和/或，
在该目标监测事件对应的中间压缩状态数据中的设定位置处添加与该设定位置对应的字符，以还原设定位置处的字符所占用的字节长度。
10.一种数据处理装置，其特征在于，驻留于终端设备，所述数据处理装置包括：
获取模块，用于获取目标应用程序在运行过程中产生的状态数据，所述状态数据包括所述目标应用程序在启动至少一个目标监测事件后，每个目标监测事件的运行状态信息，其中，所述状态数据包括用于表示所述目标应用程序中的功能的运行情况，以便对所述目标应用程序进行修正，所述状态数据为大概率连续型数据；
压缩模块，用于对获取到的状态数据按照目标压缩方式进行数据压缩，得到压缩状态数据；
发送模块，用于将所述压缩状态数据和所述目标压缩方式发送至后台服务器；所述目标压缩方式用于所述后台服务器确定对应的解压缩方式，基于确定的解压缩方式对所述压缩状态数据进行解压，以确定所述目标监测事件的运行状态；
其中，所述目标监测事件的运行状态是所述后台服务器基于判断目标类型的状态码对应的至少一个连续次数中的最大值是否达到设定次数阈值得到的，所述目标类型的状态码对应的至少一个连续次数是所述后台服务器基于解压得到的每条状态数据中的时间戳和状态码确定的，在所述目标类型的状态码对应的至少一个连续次数达到所述设定次数阈值的情况下，确定所述目标监测时间被触发，则该目标类型的状态码对应的运行状态存在；所述目标类型的状态码对应的至少一个连续次数为所述目标类型的状态码对应的同一序列号差值的重复次数，每条状态数据对应的序列号差值是将第一序列中的每条状态数据对应的序列号与第二序列中的该条状态数据对应的序列号作差得到的，所述状态数据的第一序列以及每条状态数据在所述第一序列中对应的序列号是按照每条状态数据包含的时间戳，对多条所述状态数据进行排序得到的，包含对应序列号更新后的状态数据的第二序列以及每条状态数据在所述第二序列中对应的序列号是对所述第一序列中包含相同状态码的状态数据按照该状态数据对应的时间戳进行序号更新得到的。
11.根据权利要求10所述的数据处理装置，其特征在于，所述目标应用程序为出行应用程序，所述目标监测事件包括监测车辆里程数据、监测车辆行驶速度数据和监测车辆行程价格数据。
12.根据权利要求10所述的数据处理装置，其特征在于，所述目标监测事件包括多个，所述目标压缩方式为包括第一数据压缩和第二数据压缩的二次压缩方式，所述压缩模块在用于对获取到的状态数据按照目标压缩方式进行数据压缩，得到压缩状态数据时，包括：
针对每个目标监测事件对应的至少一条状态数据，对该至少一条状态数据进行第一数据压缩，得到该目标监测事件对应的中间压缩状态数据；
将多个目标监测事件对应的中间压缩状态数据进行第二数据压缩，得到最终压缩后的所述压缩状态数据；所述第二数据压缩为打包压缩。
13.根据权利要求12所述的数据处理装置，其特征在于，所述状态数据中包含属性标签，所述压缩模块在用于针对每个目标监测事件对应的至少一条状态数据，对该至少一条状态数据进行第一数据压缩，得到该目标监测事件对应的中间压缩状态数据时，包括：
针对所述状态数据中包含的每个属性标签，按照该属性标签对应的标识字符对该属性标签进行替换，以缩短所述状态数据所占用的字节长度；和/或，
对该目标监测事件对应的状态数据中的设定位置的字符进行删除，以缩短所述状态数据所占用的字节长度。
14.根据权利要求12所述的数据处理装置，其特征在于，所述压缩模块在将多个目标监测事件对应的中间压缩状态数据进行第二数据压缩之前，还用于：
判断所述中间压缩状态数据中是否包含所述终端设备对应的用户信息；
若包含，则对所述用户信息进行加密处理。
15.一种数据处理装置，其特征在于，驻留于后台服务器，所述数据处理装置包括：
解压模块，用于接收到终端设备上传的压缩状态数据和目标压缩方式后，按照与所述目标压缩方式对应的解压方式对所述压缩状态数据进行解压，得到目标应用程序启动的每个目标监测事件的状态数据；所述状态数据中包含该状态数据产生的时间戳和状态码，其中，所述状态数据包括用于表示所述目标应用程序中的功能的运行情况，以便对所述目标应用程序进行修正，所述状态数据为大概率连续型数据；
确定模块，用于基于每个目标监测事件的状态数据对应的所述时间戳、所述状态码的类型和设定次数阈值，确定所述目标监测事件在被触发后，目标类型的状态码对应的运行状态是否存在；
其中，所述状态数据包括多条，所述确定模块在用于基于每个目标监测事件的状态数据对应的所述时间戳、所述状态码的类型和设定次数阈值，确定所述目标监测事件在被触发后，目标类型的状态码对应的运行状态是否存在时，包括：
当基于每条所述状态数据中的时间戳和所述状态码，确定出所述目标类型的状态码对应的至少一个连续次数中的最大值达到所述设定次数阈值时，则确定所述目标监测事件在被触发后，该目标类型的状态码对应的运行状态存在；
所述确定模块在用于基于每条状态数据包含的时间戳和状态码，确定所述目标类型的状态码对应的至少一个连续次数时，包括：
按照每条状态数据包含的时间戳，对多条所述状态数据进行排序，得到包含所述状态数据的第一序列以及每条状态数据在所述第一序列中对应的序列号；
对所述第一序列中包含相同状态码的状态数据按照该状态数据对应的时间戳进行序号更新，得到包含对应序列号更新后的状态数据的第二序列以及每条状态数据在所述第二序列中对应的序列号；
将第一序列中的每条状态数据对应的序列号与第二序列中的该条状态数据对应的序列号作差，得到每条状态数据对应的序列号差值；
将所述目标类型的状态码对应的同一序列号差值的重复次数，作为所述目标类型的状态码对应的至少一个连续次数。
16.根据权利要求15所述的数据处理装置，其特征在于，所述目标压缩方式包括第一数据压缩和第二数据压缩，所述解压模块在用于按照与所述目标压缩方式对应的解压方式对所述压缩状态数据进行解压时，包括：
对所述压缩状态数据按照与所述第二数据压缩对应的第二解压方式进行数据解压，得到各个目标监测事件对应的中间压缩状态数据；
针对每个目标监测事件对应的中间压缩状态数据，按照与该目标监测事件的第一数据压缩对应的第一解压方式，对该目标监测事件对应的中间压缩状态数据进行解压，得到与各个目标监测事件对应的解压后的状态数据。
17.根据权利要求16所述的数据处理装置，其特征在于，所述解压模块在针对每个目标监测事件对应的中间压缩状态数据，按照与该目标监测事件的第一数据压缩对应的第一解压方式，对该目标监测事件对应的中间压缩状态数据进行解压，得到与各个目标监测事件对应的解压后的状态数据之前，还用于：
判断所述中间压缩状态数据中是否包含加密后的用户信息；
若包含，基于所述目标压缩方式确定所述用户信息对应的加密算法后，按照所述加密算法对应的解密算法对所述加密后的用户信息进行解密处理。
18.根据权利要求16所述的数据处理装置，其特征在于，所述中间压缩状态数据包含多个标识字符，所述解压模块在用于针对每个目标监测事件对应的中间压缩状态数据，按照与该目标监测事件的第一数据压缩对应的第一解压方式，对该目标监测事件对应的中间压缩状态数据进行解压，得到与各个目标监测事件对应的解压后的状态数据时，包括：
针对所述中间压缩状态数据中包含的每个标识字符，按照该标识字符对应的属性标签对该标识字符进行替换，以还原所述中间压缩状态数据中表征所述属性标签的字符所占用的字节长度；和/或，
在该目标监测事件对应的中间压缩状态数据中的设定位置处添加与该设定位置对应的字符，以还原设定位置处的字符所占用的字节长度。
19.一种电子设备，其特征在于，包括：处理器、存储介质和总线，所述存储介质存储有所述处理器可执行的机器可读指令，当电子设备运行时，所述处理器与所述存储介质之间通过总线通信，所述处理器执行所述机器可读指令，以执行如权利要求1至9任一所述数据处理方法的步骤。
20.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器运行时执行如权利要求1至9任一所述数据处理方法的步骤。
CN201911229011.6A 2019-12-04 2019-12-04 一种数据处理方法、装置、电子设备及存储介质 Active CN111835700B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201911229011.6A CN111835700B (zh) 2019-12-04 2019-12-04 一种数据处理方法、装置、电子设备及存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201911229011.6A CN111835700B (zh) 2019-12-04 2019-12-04 一种数据处理方法、装置、电子设备及存储介质

Publications (2)

Publication Number Publication Date
CN111835700A CN111835700A (zh) 2020-10-27
CN111835700B true CN111835700B (zh) 2022-07-22

Family

ID=72911721

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201911229011.6A Active CN111835700B (zh) 2019-12-04 2019-12-04 一种数据处理方法、装置、电子设备及存储介质

Country Status (1)

Country Link
CN (1) CN111835700B (zh)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112968751A (zh) * 2021-01-27 2021-06-15 伊之密机器人自动化科技(苏州)有限公司 一种工业时序数据压缩方法及***
CN113536060B (zh) * 2021-06-23 2024-04-16 上海市计算技术研究所有限公司 数据采集设备及方法、电子设备和计算机存储介质
CN113487275B (zh) * 2021-06-29 2022-02-11 北京三维天地科技股份有限公司 一种基于区块链的实验室检测报告管理***
CN114449041A (zh) * 2021-12-30 2022-05-06 东软集团股份有限公司 数据传输方法、装置、存储介质及电子设备
CN115297182B (zh) * 2022-06-29 2023-04-07 江苏英达思自动化技术有限公司 一种控制柜运行状态数据远程传输方法和***
CN115598559B (zh) * 2022-12-16 2023-03-14 深圳市云帆自动化技术有限公司 一种智能ups电池健康状态监测***

Citations (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1760914A (zh) * 2005-11-01 2006-04-19 中国地质调查局发展研究中心 国家地质空间数据网格服务***
US7162643B1 (en) * 2001-06-15 2007-01-09 Informatica Corporation Method and system for providing transfer of analytic application data over a network
CN102445940A (zh) * 2011-09-28 2012-05-09 马秀文 一种汽车监测诊断***
CN102932465A (zh) * 2012-11-08 2013-02-13 北京工商大学 一种高效智能手机用户交互特征的监测方法
CN104571064A (zh) * 2015-01-27 2015-04-29 蒋雨兰 一种物联网车载云平台智能管控***
CN106375379A (zh) * 2016-08-26 2017-02-01 无锡挪瑞科技股份有限公司 船舶相关数据压缩后回传到岸基服务器的方法及***
CN107026799A (zh) * 2017-03-01 2017-08-08 杭州伯坦科技工程有限公司 新能源汽车车联网***车载终端的流量控制方法
CN107390564A (zh) * 2016-05-16 2017-11-24 云南力帆骏马车辆有限公司 一种车辆远程监控***
CN107590054A (zh) * 2017-09-21 2018-01-16 大连君方科技有限公司 船舶服务器日志监控***
CN108924766A (zh) * 2018-08-07 2018-11-30 天津五八到家科技有限公司 位置数据上传方法、里程计算方法及装置
CN109450926A (zh) * 2018-12-06 2019-03-08 成都路行通信息技术有限公司 一种行车数据包压缩时机计算方法及数据包压缩装置
CN109947632A (zh) * 2017-12-20 2019-06-28 瑞萨电子株式会社 跟踪数据压缩方法选择设备、方法和程序
CN110493116A (zh) * 2018-05-14 2019-11-22 广州小鹏汽车科技有限公司 一种车联网数据传输方法及装置

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2018077764A (ja) * 2016-11-11 2018-05-17 東京エレクトロン株式会社 異常検知装置

Patent Citations (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7162643B1 (en) * 2001-06-15 2007-01-09 Informatica Corporation Method and system for providing transfer of analytic application data over a network
CN1760914A (zh) * 2005-11-01 2006-04-19 中国地质调查局发展研究中心 国家地质空间数据网格服务***
CN102445940A (zh) * 2011-09-28 2012-05-09 马秀文 一种汽车监测诊断***
CN102932465A (zh) * 2012-11-08 2013-02-13 北京工商大学 一种高效智能手机用户交互特征的监测方法
CN104571064A (zh) * 2015-01-27 2015-04-29 蒋雨兰 一种物联网车载云平台智能管控***
CN107390564A (zh) * 2016-05-16 2017-11-24 云南力帆骏马车辆有限公司 一种车辆远程监控***
CN106375379A (zh) * 2016-08-26 2017-02-01 无锡挪瑞科技股份有限公司 船舶相关数据压缩后回传到岸基服务器的方法及***
CN107026799A (zh) * 2017-03-01 2017-08-08 杭州伯坦科技工程有限公司 新能源汽车车联网***车载终端的流量控制方法
CN107590054A (zh) * 2017-09-21 2018-01-16 大连君方科技有限公司 船舶服务器日志监控***
CN109947632A (zh) * 2017-12-20 2019-06-28 瑞萨电子株式会社 跟踪数据压缩方法选择设备、方法和程序
CN110493116A (zh) * 2018-05-14 2019-11-22 广州小鹏汽车科技有限公司 一种车联网数据传输方法及装置
CN108924766A (zh) * 2018-08-07 2018-11-30 天津五八到家科技有限公司 位置数据上传方法、里程计算方法及装置
CN109450926A (zh) * 2018-12-06 2019-03-08 成都路行通信息技术有限公司 一种行车数据包压缩时机计算方法及数据包压缩装置

Also Published As

Publication number Publication date
CN111835700A (zh) 2020-10-27

Similar Documents

Publication Publication Date Title
CN111835700B (zh) 一种数据处理方法、装置、电子设备及存储介质
CN110955914A (zh) 一种待脱敏数据的处理方法、***、终端设备和存储介质
CN108268211B (zh) 一种数据处理方法及装置
CN110908833A (zh) 一种数据备份方法、装置、设备及计算机可读存储介质
EP2759929B1 (en) A radio handheld device and method for starting the radio handheld device
CN106055375B (zh) 应用程序安装方法及装置
US20130007172A1 (en) Methods and apparatus for content based notification using hierarchical groups
CN107105324B (zh) 一种保护弹幕信息的方法及客户端
JP5753946B2 (ja) フォントファイルをダウンロードする方法およびシステム
CN110381378B (zh) 网络多媒体播放量的推算方法、装置、服务器及存储介质
CN113961226B (zh) 一种软件开发工具包修复方法、终端、服务器及设备
CN115473722A (zh) 数据加密方法、装置、电子设备及存储介质
CN109561045B (zh) 数据拦截方法及装置、存储介质和电子设备
CN113986313A (zh) 软件升级方法、装置、电子设备以及存储介质
CN102611716B (zh) 一种传输媒体文件的方法、装置及***
CN112182602A (zh) 一种磁盘剩余信息保护方法、装置及计算机可读存储介质
CN116776352A (zh) 一种数据处理方法及装置
CN115037654B (zh) 流量统计方法、装置、电子设备及可读存储介质
CN114095037B (zh) 应用程序的更新方法、更新数据的压缩方法、装置及设备
CN112823349A (zh) 数据处理方法、装置、电子设备以及存储介质
CN113810174A (zh) 一种数据处理方法以及相关设备
CN110489988B (zh) 一种曝光设备数量的计算方法及装置
CN113992345A (zh) 网页敏感数据加解密方法、装置、电子设备及存储介质
CN111414341B (zh) 一种物联网环境下的数据归一化描述方法
CN107678928B (zh) 应用程序的处理方法及服务器

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant