数据处理方法、装置、设备、系统及存储介质与流程

1.本公开涉及设备监控技术领域，尤其涉及一种数据处理方法、装置、设备、系统及存储介质。


背景技术：

2.随着智能设备的广泛应用，如何保证智能设备中的应用的稳定、高效运转得到越来越多的研究和重视。由于应用性能表现能够通过性能指标数据体现，现有技术中一般通过多个应用的性能指标数据结合，从而对应用的性能表现进行评估。
3.当前性能指标数据主要是依赖应用对应的软件开发工具包(software development kit，简称sdk)进行。而sdk在采集多个应用性能指标数据时，会造成应用性能的大量消耗，反倒降低了应用性能表现。


技术实现要素：

4.本公开提供了一种数据处理方法、装置、设备、系统及存储介质，以减小采集应用性能指标数据时，对应用性能的消耗，提高应用性能表现评估的效率。
5.第一方面，本公开提供了一种数据处理方法，应用于智能设备，数据处理方法包括：
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.可选地，处理模块还用于，在根据流程数据和基础数据，确定智能设备的当前运行状态之后，根据智能设备的当前运行状态，生成并下发对应的检测配置信息。
38.可选地，处理模块还用于，在根据流程数据和基础数据，确定智能设备的当前运行状态之后，当智能设备的当前运行状态满足设定的判断规则时，向智能设备发送应用运维策略，应用运维策略用于调整智能设备上的应用的运行状态。
39.第五方面，本公开还提供了一种电子设备，该电子设备包括：
40.至少一个处理器；
41.以及与至少一个处理器通信连接的存储器；
42.其中，存储器存储有可被至少一个处理器执行的指令，指令被至少一个处理器执行，以使电子设备执行如第一方面任一的数据处理方法；和/或，指令被至少一个处理器执行，以使电子设备执行如第二方面任一的数据处理方法。
43.第六方面，本公开还提供了一种数据处理系统，该数据处理系统包括：相互通信连接的智能设备和服务器；
44.智能设备，用于执行如第一方面中任一项的数据处理方法；
45.服务器，用于执行如第二方面中任一项的数据处理方法。
46.第七方面，本公开还提供了一种计算机程序产品，计算机程序产品包括计算机程序，该计算机程序被处理器执行时实现本公开第一方面任一的数据处理方法，和/或，该计
算机程序被处理器执行时实现本公开第二方面任一的数据处理方法。
47.第八方面，本公开还提供了一种计算机可读存储介质，计算机可读存储介质中存储有计算机执行指令，计算机执行指令被处理器执行时用于实现如本公开第一方面任一的数据处理方法，和/或，计算机执行指令被处理器执行时用于实现如本公开第一方面任二的数据处理方法。
48.本公开提供的数据处理方法、装置、设备、系统及存储介质，基于设定的检测配置信息，通过智能设备上的应用的软件开发工具包采集应用的流程数据，并通过软件开发工具包将性能数据发送到本地服务模块，然后基于检测配置信息，通过本地服务模块采集智能设备的基础数据，通过本地服务模块将流程数据和基础数据上报到服务器，由此，能避免消现有技术中由应用的软件开发工具包采集所有数据的情况，减小软件开发工具包采集的数据数量，减小对应用性能的消耗，同时提高采集效率，进而能够提高应用性能的评估效率。
附图说明
49.此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。
50.图1为本公开实施例提供的数据处理方法的一种应用场景图；
51.图2为本公开一个实施例提供的数据处理方法的流程图；
52.图3为本公开又一个实施例提供的数据处理方法的流程图；
53.图4为本公开又一个实施例提供的数据处理方法的流程图；
54.图5为本公开又一个实施例提供的数据处理装置的结构示意图；
55.图6为本公开又一个实施例提供的数据处理装置的结构示意图；
56.图7为本公开又一个实施例提供的电子设备的结构示意图；
57.图8为本公开一个实施例提供的数据处理系统的结构示意图。
58.通过上述附图，已示出本公开明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本公开构思的范围，而是通过参考特定实施例为本领域技术人员说明本公开的概念。
具体实施方式
59.这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。
60.下面以具体地实施例对本公开的技术方案以及本公开的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本公开的实施例进行描述。
61.下面是本公开涉及的名词的解释：
62.软件开发工具包(software development kit，简称sdk)，在本公开中，用于表示与应用程序配合的开发工具模块，包括用于调试和数据采集的实用工具。sdk能够对应用中
的各种性能指标数据通过不同工具进行采集。
63.服务器：在本公开中，用于表示与智能设备通信以获取性能数据，并对智能设备中的应用性能表现进行管理的云端服务器。一个服务器可以对应多个智能设备。
64.现有智能设备技术中，应用程序业务的复杂性不断提高，为了保证应用的稳定、高效运转，需要对应用的性能表现进行监测，并根据应用的性能表现管理智能设备内的应用运维策略。现有技术中，应用性能表现的相关数据，均由应用对应的sdk进行获取，为保证监测的准确性，每个应用的sdk都会获取尽量多种类的应用性能数据，导致智能设备监测的性能数据既有重复，又因为获取的应用性能数据较多，占用应用本身的运行资源，进而降低应用的性能表现。
65.为了解决上述问题，本公开实施例提供一种数据处理方法，通过设置单独的本地服务模块采集智能设备的基础数据，减少sdk所采集的数据种类，提高sdk采集数据的效率，减少智能设备获取的性能数据的数量，并提高应用的性能表现。
66.下面对本公开实施例的应用场景进行解释：
67.图1为本公开实施例提供的数据处理方法的一种应用场景图。如图1所示，在进行数据处理流程中，智能设备100采集应用的性能数据后，上传到服务器110，服务器110通过性能数据对智能设备100的应用性能表现进行评估，并下发对应的应用运维策略的指令。
68.需说明的是，图1所示场景中智能设备和服务器仅以一个为例进行示例说明，但本公开不以此为限制，也就是说，智能设备和服务器的个数可以是任意的。
69.以下通过具体实施例详细说明本公开提供的数据处理方法。需要说明的是，下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。
70.图2为本公开一个实施例提供的数据处理方法的流程图。如图2所示，本实施例提供的数据处理方法应用于智能设备，包括以下步骤：
71.步骤s201、基于设定的检测配置信息，通过智能设备上的应用的sdk采集应用的流程数据。
72.其中，检测配置信息包括待采集的性能数据，流程数据用于表示体现应用实时运行状态的性能数据。
73.其中，智能设备可以是车载或交通工具上安装的车机系统，也可以是个人移动终端，如智能手机或定制的个人数字终端(personal digital assistant，简称pda)。
74.具体的，检测配置信息是负责管理智能设备的应用性能的服务器下发的命令或文件。检测配置信息一般是根据智能设备上配置的应用和服务器上预先设定的规则而设置。当智能设备接收到检测配置信息之后，一般会基于检测配置信息中对应不同应用所需要的待采集的性能数据分发到对应的应用。
75.一些实施例中，检测配置信息中针对每个应用所需要采集的性能数据互不相同，以更好的评估应用性能。如桌面背景管理类的应用和短时间运行的游戏类应用所对应的性能数据，后者需要更多实时内存占用和启动时间相关的性能数据，而前者一般不需要监测启动时间类的性能数据，因为前者一般是持续工作状态。
76.流程数据可以是应用实时运行过程中的涉及的所有相关数据，如应用启动时、关闭时和运行中涉及的数据，例如启动时间、运行卡顿记录、关闭时间等。
77.每个应用对应需要的流程数据一般根据开发阶段或维护后重新下发的测试配置确定，如开发商在智能设备上测试应用时发现与应用性能表现和使用体验强相关的数据，或在接收到用户在实际使用中经常接收到反馈出现异常的数据，都可以作为sdk所需要采集的应用的流程数据。
78.特别地，sdk采集的数据均为被动触发式采集，而不需要sdk主动定时采集，由此能够答复降低sdk的性能消耗，进而降低sdk对应用性能表现的影响。
79.步骤s202、通过sdk将流程数据发送到本地服务模块。
80.具体的，智能设备上一般只有一个本地服务模块，该本地服务模块同时与多个sdk数据连接，本地服务模块既能接收sdk发送的数据，也能向sdk发送检测配置信息，以告知sdk需要采集的数据。
81.一般的，sdk可以每次只采集一种流程数据，如采集完启动时间后，再采集运行卡顿记录，也可以同时采集多种流程数据，如同时采集内存泄漏和慢方法等记录，然后将采集到流程数据一起传输给本地服务模块。
82.一些实施例中，sdk可以将每个采集到的流程数据直接发送到本地服务模块，如采集应用关闭时间时，在应用关闭后即进行采集，采集完直接发送。
83.一些实施例中，sdk也可以定时发送采集结果，如内存泄漏记录和运行卡顿记录，可以在监测到该记录数据时，固定间隔30秒，以统一发送。
84.步骤s203、基于检测配置信息，通过本地服务模块采集智能设备的基础数据。
85.其中，基础数据用于表示体现智能设备配置信息和整体运行状态的性能数据。
86.具体的，基础数据包括体现智能设备配置信息的设备基础数据，和体现智能设备内应用整体运行状态的应用共性数据。设备基础数据可以如设备型号、系统版本型号、屏幕分辨率、屏幕刷新率等，应用共性数据可以如cpu使用率、内存占用率。
87.一般地，应用共性数据为表现应用整体运行状态的数据，因此，只需要通过本地服务模块采集一次即可。
88.一些实施例中，采集耗时的性能数据，如需要获取智能设备内部文件并进行读取后，才能得到的数据，可以通过本地服务模块进行采集，如内存泄漏信息。
89.步骤s204、通过本地服务模块将流程数据和基础数据上报到服务器。
90.具体的，本地服务模块会将sdk监测到的流程数据和自身监测到的基础数据共同上传到服务器中。
91.一些实施例中，当需要对sdk监测到的流程数据进行初步预处理时，本地服务模块会进行预处理后再进行上传，如需要对日志文件进行解析才能得到的数据。
92.一些实施例中，本地服务模块会根据检测配置信息中包含的上传策略，将流程数据和基础数据打包后，再进行上传。
93.一些实施例中，本地服务模块可以定时进行上传，也可能满足检测配置信息中包含的设定条件，如特定性能数据出现异常或者智能设备存在异常工况时进行上传。
94.一些实施例中，本地服务模块可以在上传之前对流程数据和基础数据进行缓存，以便在无法完成上传时，能够避免性能数据的遗失。
95.本公开实施例提供的数据处理方法，基于设定的检测配置信息，通过智能设备上的应用的软件开发工具包采集应用的流程数据，并通过软件开发工具包将性能数据发送到
本地服务模块，然后基于检测配置信息，通过本地服务模块采集智能设备的基础数据，通过本地服务模块将流程数据和基础数据上报到服务器，由此，能避免现有技术中由应用的软件开发工具包采集所有数据的情况，减小软件开发工具包采集的数据数量，减小对应用性能的消耗，同时提高采集效率，进而能够提高应用性能的评估效率。
96.图3为本公开另一个实施例提供的数据处理方法的流程图。本实施例中是在图2实施例基础上的进一步细化，如图3所示，本实施例提供的数据处理方法可以包括以下步骤：
97.步骤s301、响应于接收到的服务器发送的检测配置信息，通过本地服务模块将检测配置信息中的流程数据种类分发到对应的sdk。
98.其中，检测配置信息包括待检测的性能数据的种类和上传性能数据的设定时间间隔，性能数据包括流程数据和基础数据。
99.进一步地，当智能设备初始化或安装有新应用时，会先通过本地服务模块采集智能设备上的基础数据并上传，以获取应用检测配置信息。此时，基础数据包括智能设备中安装有的应用名及其版本号，以便服务器发送对应应用的检测配置信息。
100.一些实施例中，当智能设备安装新应用或对现有应用进行升级时，根据本地服务模块上传的基础数据，服务器只会下发新应用或进行了升级的应用对应的检测配置信息，以减小数据处理量，提高处理效率。
101.步骤s302、通过本地服务模块缓存检测配置信息中的基础数据种类和设定时间间隔。
102.本地服务模块通过缓存检测配置信息，以便确定需要采集的数据种类，并根据设定时间间隔进行上传。
103.一些实施例中，本地服务模块还会缓存流程数据的种类，以核对sdk发送的流程数据。
104.步骤s303、基于设定的检测配置信息，通过智能设备上的应用的sdk采集应用的流程数据。
105.其中，检测配置信息包括待采集的性能数据，流程数据用于表示体现应用实时运行状态的性能数据。
106.可选地，sdk包含多种不同的数据采集工具，可以针对不同类型的数据通过不同的采集方法进行采集，如通过字节码插桩的方式采集启动时间、慢方法等流程数据，通过直接采集路径的方式采集需要读取日志记录的数据。
107.特别地，当待采集的流程数据为内存泄漏记录时，通过sdk采集内存泄漏对应的日志信息文件的路径。
108.其中，流程数据包括日志信息文件的路径。
109.由于因为内存泄漏记录涉及对智能设备内存的读取和分析，会占用较多系统cpu的负载，且可能存在多个应用都需要采集内存泄漏记录的情况，如果分别由sdk完成，容易出现重复采集，影响系统内各应用性能表现的问题。因此统一由本地服务模块进行采集，能够避免重复采集。
110.相应地，通过本地服务模块对日志信息文件的路径进行解析，获取对应的内存泄露记录。
111.一些实施例中，当本地服务模块一般接收到多个相同的待解析文件路径时，只会
解析一次。如本地服务模块在1分钟内接到3个不同应用的sdk发送的相同待解析文件路径，此时本地服务模块只会在第一次接收到该路径时进行处理。
112.步骤s304、通过sdk将性能数据发送到本地服务模块。
113.可选地，sdk可以对采集到的流程数据进行初步处理后再发送，如根据采集到的时间戳计算出对应应用的运行时间，也可以直接发送采集到的原始数据，如应用停止运行的时间点。
114.步骤s305、基于检测配置信息，通过本地服务模块采集智能设备的基础数据。
115.其中，基础数据用于表示体现智能设备配置信息和整体运行状态的性能数据。
116.一些实施例中，当本地服务模块先后接收到多个检测配置信息时，一般根据最后接收到的检测配置信息采集对应的基础数据。
117.步骤s306、通过本地服务模块缓存基础数据，根据设定时间间隔将流程数据和基础数据上报到服务器。
118.一些实施例中，当本地服务模块可能存在上报性能数据失败的情况时，可以设置根据设定时间间隔重复上传的功能。
119.具体的，可以在上报失败时，按照设定间隔进行重试，如果重试设定次数后均未能成功上报性能数据，本地服务模块可以暂停上报性能数据。其中，设定间隔和设定次数都可以由检测配置信息下发，也可以由管理人员在本地服务模块中预先配置。
120.一些实施例中，本地服务模块在上报性能数据失败时，可以暂停设定时长后重新进行上传，如暂停1小时候再进行上传；也可以在监测到网络通信正常后再上传。
121.可选地，当智能设备处于调试环境时，当流程数据和基础数据满足预先设置的报警规则时，通过本地服务模块生成报警规则对应的告警信息，并，停止向服务器上报流程数据和基础数据。
122.具体的，调试环境下，一般是由开发人员预先配置基础的报警规则，再根据服务器接收到的报警和对应的运行状态，或通过智能设备直接读取本地服务模块中生成的告警信息相关数据，对报警规则进行反馈调节，直到该报警规则能够满足有效监测报警运行状态的需求。
123.步骤s307、通过本地服务模块对流程数据和基础数据进行压缩后，再上传到服务器。
124.一些实施例中，当多个应用的流程数据和智能设备的基础数据的总数据量较大时，如果直接进行上传，需要消耗较多的流量和存储空间，此时，本地服务模块通过自动对性能数据进行压缩后再上传，能够显著节省流量和占用的存储空间。
125.一些实施例中，本地服务模块可以同时具有步骤s306中的设定时间间隔上报功能和步骤s307中的压缩后上传功能，以提高上传效率和稳定性。
126.步骤s308、当本地服务模块接收到服务器发送的应用运维策略时，向应用运维策略对应的应用的sdk发送处理命令。
127.其中，应用运维策略用于表示对设定应用的运行状态进行调整的信息，处理命令用于改变应用的运行状态。
128.具体的，应用运维策略一般用于关闭闲置应用或处于异常状态的应用，以减小智能设备的处理器负荷。如某记事本类应用已经在后台运行1小时，且一直未被启用，而智能
设备此时已经处于cpu高负荷状态运行中，服务器就可以发出关闭该记事本类应用以减小cpu负荷的应用运维策略。
129.步骤s309、通过sdk执行处理命令。
130.一些实施例中，sdk除了采集性能数据外，还能对相对应的应用进行直接操纵，如关闭应用或重置应用状态。此时，通过向sdk发送应用运维策略对应命令，从而能够直接实现如关闭应用等操作。
131.本公开实施例提供的数据处理方法，通过将接收到的检测配置信息分发到对应的sdk，使sdk收集检测配置信息对应流程数据后发送到本地服务模块，再通过本地服务模块定时压缩后上传服务器，并根据服务器发送的应用运维策略，通过sdk对应用执行对应命令，从而实现基于应用的性能数据的采集实现对应用的运行状态进行维护管理的过程。由于性能数据能够通过本地服务模块和sdk分别采集，且能够通过本地服务模块专门进行上传工作，既能保证性能数据的采集效率，又能保证性能数据得到有效上传，从而有效提高智能设备应用性能管理的效率。
132.图4为本公开另一个实施例提供的数据处理方法的流程图。该数据处理方法应用于服务器。如图4所示，本实施例提供的数据处理方法包括以下步骤：
133.步骤s401、接收智能设备上报的流程数据和基础数据。
134.其中，流程数据是智能设备基于检测配置信息，通过应用的软件开发工具包采集的，基础数据是智能设备基于检测配置信息，通过本地服务模块采集的，流程数据用于表示体现应用实时运行状态的性能数据，基础数据用于表示体现智能设备配置信息和整体运行状态的性能数据。
135.服务器主要用于接收智能设备上传的各种性能数据，通过数据分析和整理，以便对智能设备的运行状态进行管理，并通过性能数据辅助智能设备上的应用的开发升级。
136.一些实施例中，在智能设备初始化或安装新应用时，也会接收到智能设备上报的性能数据，此时智能设备上报的性能数据主要是包括智能设备中所安装应用信息在内的基础数据，智能设备会根据智能设备上报的性能数据下发检测配置信息，以供智能设备配置各应用的sdk。
137.一些实施例中，当服务器在接收到智能设备上报的数据时，会生成反馈回执，发送到智能设备，以通知智能设备上报成功。
138.步骤s402、根据流程数据和基础数据，确定智能设备的当前运行状态。
139.具体的，服务器确定智能设备的当前运行状态之后，可以将数据保存，也可以分享给进行应用开发的第三方；当服务器根据预先设置的规则，若认为需要智能设备采取行动，如调整某些应用的运行状态，则会向该应用所在的智能设备发送对应的命令。
140.一些实施例中，如应用开发场景下，服务器会将确定的运行状态和数据发送到应用开发者，以便进行改进。
141.步骤s403、根据智能设备的当前运行状态，生成并下发对应的检测配置信息。
142.其中，检测配置信息一般根据服务器内预设的规则生成，一般针对服务器接收到的性能数据对应的应用进行检测。
143.步骤s404、当智能设备的当前运行状态满足设定的判断规则时，向智能设备发送应用运维策略。
144.其中，应用运维策略用于调整智能设备上的应用的运行状态。
145.具体的，判断规则也是系统开发者预先设定的，如智能设备处于持续高负荷工作的状态，或持续处于工作状态的应用数量较多时，就会生成对应的应用运维策略。
146.一些实施例中，应用运维策略会具体到智能设备所处于的场景和对应的具体应用所需要采取的处理方式。如在回家场景中，需要保障导航应用和音乐/收音机应用能够顺畅运行，服务器下发应用运维策略至智能设备的本地服务模块，通过本地服务模块对未运行的非导航和音乐/收音机应用进行关闭或转后台处理，以回收处理器资源，保证导航应用和音乐/收音机应用的性能表现。
147.此时，智能设备所处的场景可以由智能设备的用户配置，并通过本地服务模块在上报性能数据时一同发送到服务器；也可以由服务器的开发者配置，并根据接收到的性能数据和当前时刻对应场景，发送对应的应用运维策略。
148.本公开实施例提供的数据处理方法，服务器通过对接收到的智能设备分钟的性能数据进行分析，确定智能设备的当前状态，并下发相应的检测配置信息或应用运维策略，从而实现对智能设备上应用基于性能数据的管理，由于智能设备上报的数据分别由本地服务模块和sdk采集，重复数据量更小，减小了服务器的分析压力，提高分析速度，进而提高服务器对应用性能管理的效率，从而保证智能设备应用表现的可靠性。
149.图5为本公开一个实施例提供的数据处理装置的结构示意图。该数据处理装置应用于智能设备，如图5所示，该数据处理装置500包括：处理模块510和发送模块520。其中：
150.处理模块510，用于基于设定的检测配置信息，通过智能设备上的应用的软件开发工具包采集应用的流程数据，检测配置信息包括待采集的性能数据，流程数据用于表示体现应用实时运行状态的性能数据；并，基于检测配置信息，通过本地服务模块采集智能设备的基础数据，基础数据用于表示体现智能设备配置信息和整体运行状态的性能数据；
151.发送模块520，用于通过软件开发工具包将流程数据发送到本地服务模块；并，通过本地服务模块将流程数据和基础数据上报到服务器。
152.可选地，处理模块510具体用于，当待采集的流程数据为内存泄漏记录时，通过软件开发工具包采集内存泄漏对应的日志信息文件的路径，流程数据包括日志信息文件的路径。
153.可选地，处理模块510还用于，通过本地服务模块对日志信息文件的路径进行解析，获取对应的内存泄露记录信息。
154.可选地，发送模块520具体用于，通过本地服务模块缓存基础数据，根据设定时间间隔将流程数据和基础数据上报到服务器。
155.可选地，发送模块520具体用于，通过本地服务模块对流程数据和基础数据进行压缩后，再上传到服务器。
156.可选地，处理模块510还用于，响应于接收到的服务器发送的检测配置信息，通过本地服务模块将检测配置信息中的流程数据种类分发到对应的软件开发工具包，检测配置信息包括待检测的性能数据的种类和上传性能数据的设定时间间隔，性能数据包括流程数据和基础数据；通过本地服务模块缓存检测配置信息中的基础数据种类和设定时间间隔。
157.可选地，处理模块510还用于，当智能设备完成应用安装或智能设备完成初始化时，通过本地服务模块获取智能设备的应用信息和基础信息，应用信息包括智能设备中现
有应用的识别码和版本信息，基础信息包括智能设备的全部基础数据；相应地，发送模块还用于，将应用信息和基础信息发送到服务器。
158.可选地，处理模块510还用于，通过本地服务模块将流程数据和基础数据上报到服务器之后，当本地服务模块接收到服务器发送的应用运维策略时，向应用运维策略对应的应用的软件开发工具包发送处理命令，应用运维策略用于表示对设定应用的运行状态进行调整的信息，处理命令用于改变应用的运行状态；通过软件开发工具包执行处理命令。
159.可选地，发送模块520还用于，当智能设备处于调试环境时，当流程数据和基础数据满足预先设置的报警规则时，通过本地服务模块生成报警规则对应的告警信息；停止向服务器上报流程数据和基础数据。
160.在本实施例中，数据处理装置通过各模块的结合，能够实现分别收集智能设备中的流程数据和基础数据并上报，由于不同种类的性能数据能够分别收集，有效保证性能数据收集效率，同时减小数据重复，减少对应用性能表现的影响，提高应用性能表现。
161.图6为本公开一个实施例提供的数据处理装置的结构示意图。该数据处理装置应用于服务器，如图6所示，该数据处理装置600包括：接收模块610和处理模块620。其中：
162.接收模块610，用于接收智能设备上报的流程数据和基础数据，流程数据是智能设备基于检测配置信息，通过应用的软件开发工具包采集的，基础数据是智能设备基于检测配置信息，通过本地服务模块采集的，流程数据用于表示体现应用实时运行状态的性能数据，基础数据用于表示体现智能设备配置信息和整体运行状态的性能数据；
163.处理模块620，用于根据流程数据和基础数据，确定智能设备的当前运行状态。
164.可选地，处理模块620还用于，在根据流程数据和基础数据，确定智能设备的当前运行状态之后，根据智能设备的当前运行状态，生成并下发对应的检测配置信息。
165.可选地，处理模块620还用于，在根据流程数据和基础数据，确定智能设备的当前运行状态之后，当智能设备的当前运行状态满足设定的判断规则时，向智能设备发送应用运维策略，应用运维策略用于调整智能设备上的应用的运行状态。
166.在本实施例中，数据处理装置通过各模块的结合，能够实现基于接收到的智能设备上报的性能数据，确定智能设备的当前运行状态，并据此下发检测配置信息或应用运维策略，由于智能设备上报的性能数据重复率较小，能够显著提高服务器的分析效率，从而有效保证对智能设备性能表现的评估效率。
167.图7为本公开一个实施例提供的电子设备的结构示意图，如图7所示，该电子设备700包括：存储器710和处理器720。
168.其中，存储器710存储有可被至少一个处理器720执行的计算机程序。该算机程序被至少一个处理器720执行，以使电子设备实现如上任一实施例中提供的数据处理方法。
169.其中，存储器710和处理器720可以通过总线730连接。
170.相关说明可以对应参见方法实施例所对应的相关描述和效果进行理解，此处不予赘述。
171.图8为本公开一个实施例提供的一种数据处理系统。参考图8，该数据处理系统800包括：相互通信连接的智能设备810和服务器820；
172.智能设备810用于执行如图2至图3对应的任意实施例的数据处理方法；
173.服务器820用于执行如图4对应的实施例的数据处理方法。
174.其中，智能设备810包括本地服务模块811、应用812和应用对应的sdk813，本地服务模块811与服务器820通信连接，并于sdk813相互数据连接。
175.在本实施例中，智能设备将采集的性能数据发送到服务器，然后由服务器对性能数据进行分析，然后向智能设备发送对应的检测配置信息或应用运维策略，从而保证对智能设备应用运行状态的有效管理。
176.本公开一个实施例提供一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行以实现如图2至图3对应的任意实施例的数据处理方法，和/或，该计算机程序被处理器执行时实现如图4对应的实施例的数据处理方法。
177.其中，计算机可读存储介质可以是rom、随机存取存储器(ram)、cd
‑
rom、磁带、软盘和光数据存储设备等。
178.本公开一个实施例提供了一种计算机程序产品，其包含计算机执行指令，该计算机执行指令被处理器执行时用于实现如图2至图3对应的任意实施例的数据处理方法，和/或，该计算机执行指令被处理器执行时用于实现如图4对应的实施例的数据处理方法。
179.在本公开所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个模块或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或模块的间接耦合或通信连接，可以是电性，机械或其它的形式。
180.本领域技术人员在考虑说明书及实践这里公开的公开后，将容易想到本公开的其它实施方案。本公开旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由下面的权利要求书指出。
181.应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求书来限制。