CN108063693B - 一种信息上传方法及终端设备 - Google Patents

Abstract

本发明公开了一种信息上传方法及终端设备，其中方法包括：运行目标应用，得到至少一个操作事件对应的至少一条运行状态信息；其中，所述运行状态信息至少包括有第一类运行状态信息以及第二类运行状态信息，所述第一类运行状态信息表征所述目标应用在对应的操作事件中的正常运行状态；所述第二类运行状态信息表征所述目标应用在对应的操作事件中的异常运行状态；将所述目标应用的至少一个操作事件对应的所述至少一条运行状态信息中，至少部分运行状态信息发送至服务器侧。

Description

一种信息上传方法及终端设备

技术领域

本发明涉及信息处理领域中的信息处理技术，尤其涉及一种信息上传方法及终端设备。

背景技术

目前客户端类应用(PC,android,ios)相对于web类应用而言，日志输出一般在客户端，一般用户反馈问题时，开发人员通常需要客户端的日志信息来排查问题发生的原因，由于客户端的日志信息量较大，将所有的日志信息上传到服务器的做法并不现实，目前业内的做法通常是上传有异常场景的信息或者关键信息，对于普通级别的日志，一般由于存储成本及考虑到对用户客户端资源的消耗，一般不做上传。此时如果用户反馈问题时，开发人员一般需要用户配合将相关的日志信息发送给开发人员来还原当时的场景。

让用户配合上传相关日志的操作，因各个用户的计算机相关知识的了解的深度不同，配合操作的难度也不同，同时对于部分用户因用户时间，性格等原因，配合难度也会增加大，对于问题现场还原会有一定的成本。

发明内容

本发明实施例提供一种信息上传方法及终端设备，能至少解决现有技术中存在的上述问题。

本发明实施例提供一种信息上传方法，应用于终端设备，所述方法包括：

运行目标应用，得到至少一个操作事件对应的至少一条运行状态信息；其中，所述运行状态信息至少包括有第一类运行状态信息以及第二类运行状态信息，所述第一类运行状态信息表征所述目标应用在对应的操作事件中的正常运行状态；所述第二类运行状态信息表征所述目标应用在对应的操作事件中的异常运行状态；

将所述目标应用的至少一个操作事件对应的所述至少一条运行状态信息中，至少部分运行状态信息发送至服务器侧，以使得所述服务器侧基于所述至少一个操作事件的至少部分运行状态信息对所述目标应用进行分析处理。

本发明实施例提供一种终端设备，所述方法包括：

应用管理单元，用于运行目标应用的至少一个操作事件得到至少一条运行状态信息；其中，所述运行状态信息至少包括有第一类运行状态信息以及第二类运行状态信息，所述第一类运行状态信息表征所述目标应用在对应的操作事件中的正常运行状态；所述第二类运行状态信息表征所述目标应用在对应的操作事件中的异常运行状态；

信息上报单元，用于将所述目标应用的至少一个操作事件对应的所述至少一条运行状态信息中，至少部分运行状态信息发送至服务器侧，以使得所述服务器侧基于所述至少一个操作事件的至少部分运行状态信息对所述目标应用进行分析处理。

本发明实施例中提供的一种信息上传方法及终端设备，在终端设备侧检测到目标应用的至少一个运行状态信息的时候，主动向服务器侧上报至少一个运行状态信息中的至少部分运行状态信息。如此，就避免了由用户选择上报的状态信息而带来的***侧无法全面掌握其关心的状态信息，以及影响用户针对目标应用的使用体现等问题。

附图说明

图1为本发明实施例中终端设备硬件结构示意图；

图2为本发明实施例终端设备与网络侧建立连接的场景示意图；

图3为本发明实施例信息上传方法流程示意图；

图4为本发明实施例场景示意图一；

图5为本发明实施例场景示意图二；

图6为本发明实施例场景示意图三；

图7为本发明实施例***处理框架示意图；

图8-1为本发明实施终端设备组成结构示意图一；

图8-2为本发明实施终端设备组成结构示意图二。

具体实施方式

下面结合附图和具体实施例对本发明作进一步详细说明。

现在将参考附图描述实现本发明各个实施例的终端设备。在后续的描述中，使用用于表示元件的诸如“模块”、“部件”或“单元”的后缀仅为了有利于本发明的说明，其本身并没有特定的意义。因此，"模块"与"部件"可以混合地使用。

终端设备可以以各种形式来实施。例如，本发明中描述的终端可以包括诸如移动电话、智能电话、笔记本电脑、数字广播接收器、PDA(个人数字助理)、 PAD(平板电脑)、PMP(便携式多媒体播放器)、导航装置等等的终端设备以及诸如数字TV、台式计算机等等的固定终端。下面，假设终端是终端设备。然而，本领域技术人员将理解的是，除了特别用于移动目的的元件之外，根据本发明的实施方式的构造也能够应用于固定类型的终端。

图1为实现本发明各个实施例的终端设备的硬件结构示意。

终端设备100可以包括通信单元110、用户输入单元130、输出单元150、存储器160、接口单元170、控制器180和电源单元190等等。图1示出了具有各种组件的终端设备，但是应理解的是，并不要求实施所有示出的组件。可以替代地实施更多或更少的组件。将在下面详细描述终端设备的元件。

通信单元110通常包括一个或多个组件，其允许终端设备100与无线通信***或网络之间的无线电通信。

用户输入单元130可以根据用户输入的命令生成键输入数据以控制终端设备的各种操作。用户输入单元130允许用户输入各种类型的信息，并且可以包括键盘、锅仔片、触摸板(例如，检测由于被接触而导致的电阻、压力、电容等等的变化的触敏组件)、滚轮、摇杆等等。特别地，当触摸板以层的形式叠加在显示单元151上时，可以形成触摸屏。

接口单元170用作至少一个外部装置与终端设备100连接可以通过的接口。例如，外部装置可以包括有线或无线头戴式耳机端口、外部电源(或电池充电器) 端口、有线或无线数据端口、存储卡端口、用于连接具有识别模块的装置的端口、音频输入/输出(I/O)端口、视频I/O端口、耳机端口等等。识别模块可以是存储用于验证用户使用终端设备100的各种信息并且可以包括用户识别模块 (UIM)、客户识别模块(SIM)、通用客户识别模块(USIM)等等。另外，具有识别模块的装置(下面称为"识别装置")可以采取智能卡的形式，因此，识别装置可以经由端口或其它连接装置与终端设备100连接。接口单元170可以用于接收来自外部装置的输入(例如，数据信息、电力等等)并且将接收到的输入传输到终端设备100内的一个或多个元件或者可以用于在终端设备和外部装置之间传输数据。

另外，当终端设备100与外部底座连接时，接口单元170可以用作允许通过其将电力从底座提供到终端设备100的路径或者可以用作允许从底座输入的各种命令信号通过其传输到终端设备的路径。从底座输入的各种命令信号或电力可以用作用于识别终端设备是否准确地安装在底座上的信号。输出单元150被构造为以视觉、音频和/或触觉方式提供输出信号(例如，音频信号、视频信号、警报信号、振动信号等等)。输出单元150可以包括显示单元151等等。

存储器160可以存储由控制器180执行的处理和控制操作的软件程序等等，或者可以暂时地存储己经输出或将要输出的数据(例如，电话簿、消息、静态图像、视频等等)。而且，存储器160可以存储关于当触摸施加到触摸屏时输出的各种方式的振动和音频信号的数据。

存储器160可以包括至少一种类型的存储介质，所述存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如，SD或DX存储器等等)、随机访问存储器(RAM)、静态随机访问存储器(SRAM)、只读存储器(ROM)、电可擦除可编程只读存储器 (EEPROM)、可编程只读存储器(PROM)、磁性存储器、磁盘、光盘等等。而且，终端设备100可以与通过网络连接执行存储器160的存储功能的网络存储装置协作。

控制器180通常控制终端设备的总体操作。例如，控制器180执行与语音通话、数据通信、视频通话等等相关的控制和处理。另外，控制器180可以包括用于再现(或回放)多媒体数据的多媒体模块181，多媒体模块181可以构造在控制器180内，或者可以构造为与控制器180分离。控制器180可以执行模式识别处理，以将在触摸屏上执行的手写输入或者图片绘制输入识别为字符或图像。

电源单元190在控制器180的控制下接收外部电力或内部电力并且提供操作各元件和组件所需的适当的电力。

这里描述的各种实施方式可以以使用例如计算机软件、硬件或其任何组合的计算机可读介质来实施。对于硬件实施，这里描述的实施方式可以通过使用特定用途集成电路(ASIC)、数字信号处理器(DSP)、数字信号处理装置(DSPD)、可编程逻辑装置(PLD)、现场可编程门阵列(FPGA)、处理器、控制器、微控制器、微处理器、被设计为执行这里描述的功能的电子单元中的至少一种来实施，在一些情况下，这样的实施方式可以在控制器180中实施。对于软件实施，诸如过程或功能的实施方式可以与允许执行至少一种功能或操作的单独的软件模块来实施。软件代码可以由以任何适当的编程语言编写的软件应用程序(或程序)来实施，软件代码可以存储在存储器160中并且由控制器180执行。

进一步地，基于上述终端设备的硬件结构，本实施例所提供的终端设备还能够通过移动通信网络或其他网络接入到服务器侧以获取到相应的服务器，其连接关系图可以参见图2，包括：服务器11、终端设备21-24，终端设备21-24 通过有线网络或者无线网络与服务器进行信息交互，终端设备21-24用于表示其对应的几种实施类型，可以包括手机、台式机、PC机、一体机等类型。

基于上述终端设备硬件结构以及***结果，提出本发明以下各个实施例。

实施例一、

本发明实施例提供了一种信息上传方法，如图3所示，包括：

步骤301：运行目标应用，得到至少一个操作事件对应的至少一条运行状态信息；其中，所述运行状态信息至少包括有第一类运行状态信息以及第二类运行状态信息，所述第一类运行状态信息表征所述目标应用在对应的操作事件中的正常运行状态；所述第二类运行状态信息表征所述目标应用在对应的操作事件中的异常运行状态；

步骤302：将所述目标应用的至少一个操作事件对应的所述至少一条运行状态信息中，至少部分运行状态信息发送至服务器侧，以使得所述服务器侧基于所述至少一个操作事件的至少部分运行状态信息对所述目标应用进行分析处理。

这里，所述终端设备可以为任意一种能够提供针对应用的处理功能的设备，比如，可以为智能手机、平板电脑或者台式机等等，本实施例中不进行穷举。

所述目标应用可以为终端设备中安全的多个应用中的任意一种应用，可以为能够与网络侧进行交互的应用，可以为不能够与网络侧进行交互的应用。

所述目标应用的至少一个操作事件，可以为所述目标应用从开启到正常运行以及关闭的过程中所对应的多种操作事件，比如，如图4所示，用户开启应用A，终端设备进行开启操作事件；然后用户可以进入执行登录进程的操作，比如，图中所示用户以账号A登录应用A，此时对应的登录操作事件；用户以账号A登录应用A之后，可以进入的为交互操作事件，此时，可以针对不同的操作进入不同的操作事件，比如，可以为游戏进程、即时通信交互等等。

进一步地，至少一个操作事件的至少一条运行状态信息可以为包括有：运行目标应用的每一个操作事件的时候，可以在***中生成一个日志，该日志用于记录其对应的操作事件的正常运行状态信息或者异常运行的状态信息。

在运行目标应用的至少一个操作事件得到至少一条运行状态信息之后，还包括有将所述至少一条运行状态信息保存至所述目标应用对应的缓存中；具体来说，可以在每检测得到一条运行状态信息时就在缓存中保存一条；所述缓存可以对应一个保存路径，保存路径可以为与所述目标应用相关的一条默认路径，也可以为用户根据实际情况设定，比如，可以设定为SD卡中的文件夹1等等，这里不进行穷举。

进一步地，所述终端设备还能够对至少一条运行状态信息进行分类，比如，可以根据关键字选取得到第二类运行状态信息(即异常日志信息)，剩余的即为第一类运行状态信息。具体来说，所述关键字可以为根据实际情况设置的一些信息，比如，可以为在运行状态信息中出现“error”等信息时，确定其为第二类运行状态信息(即异常日志信息)。比如，参见图5，当运行一个应用A的时候，假设其中的一个进程为开启应用A的操作事件，此时可以生成三个日志，分别为图中的日志1、日志2和日志3；假设日志3中有“error”这种字眼，那么可以将日志3作为第二类运行状态信息即异常日志。

相应的，当得到至少一条运行状态信息之后，可以将所述至少一条运行状态信息中的至少部分运行状态信息发送至服务器侧，可以包括多种处理方式，如下：

第一种处理方式、

基于服务器发来的配置信息，从多个运行状态信息中选取部分运行状态信息发送至服务器，具体的：

比如，如图6所示，接收到所述服务器侧发来的配置信息，其中，所述配置信息中包括以下至少之一：至少一个目标操作事件、预设时间段、运行***。

其中，所述至少一个目标操作事件可以为服务器侧当前关心的某些进程下发至终端设备。

服务器侧由管理人员来确定哪些操作事件是当前关心的，比如，可以是用户报错较多的一些进程，假设用户经常上报登录问题，那么可以将登录的操作事件作为一个目标操作事件；或者，可以为根据当前目标应用出现修改版本了，那么针对修订后的最新版本比较关心修改部分对应的操作事件，那么就将修改部分对应的操作事件作为一个目标操作事件。

关于预设时间段可以根据实际情况来设置，比如，可以针对较为密集的操作时间进行采集，比如，当目标应用为一个网络游戏的时候，那么可能在晚上 8-10点之间出现较为密集的用户交互行为，那么可以将预设时间段设置在1个月内的8-10PM；或者，目标应用的新版本刚刚发布，那么正在发布的这1个月内可能会比较关心相关的使用情况，就将这1个月均作为预设时间段进行日志的上报。

另外，所述配置信息中还可以包括有其他一些信息以使得服务器结合更多的情况进行检测，比如，可以包括有登录目标应用时的用户账号、当前的终端设备的运行***(可以包括有安卓、IOS、Windows等***)、版本信息、上传路径等等信息。

本场景中，所述将所述至少一条运行状态信息中的至少部分运行状态信息发送至服务器侧，包括：

基于所述配置信息，将所述至少一个目标操作事件对应的至少一条运行状态信息，发送至所述服务器侧；

和/或，

基于所述配置信息，将生成时刻处于所述预设时间段内的至少一条运行状态信息，发送至所述服务器侧。

也就是说，不论终端设备是否检测有第二类运行状态信息，只要是针对目标操作事件、或者是在预设时间段内的运行状态信息就将该日志信息发送到服务器侧；相应的，服务器侧能够根据接收到的多个终端设备发来的运行情况来综合分析目标操作事件是否存在问题。

可以理解的是，上述上报目标操作事件、以及预设时间段内的运行状态信息这两个条件可以结合使用，比如，可以为目标操作事件在预设时间段内的部分运行状态信息。

第二种处理方式、

服务器侧下发配置信息，在配置信息中可以限定有目标操作事件、预设时间段等等参数，但是在终端设备上报运行状态信息时，可以先进行一些筛选，仅上报第二类运行状态信息，具体如下：

基于所述配置信息，将所述至少一个目标操作事件对应的至少一条第二类运行状态信息，发送至所述服务器侧；

和/或，

基于所述配置信息，将生成时刻处于所述预设时间段内的至少一条第二类运行状态信息，发送至所述服务器侧。

关于配置信息的具体获取以及其中的参数与第一种处理场景相同，这里不再进行赘述。

与第一种处理方式不同之处在于，本场景中，在上报部分运行状态信息的时候，首先进行一次筛选，仅将存在异常部分状态信息进行上报，这种处理场景，能够减少与服务器侧进行数据交互的通信量，并且并不会对服务器侧进行分析的效果有所影响，提升了一定的处理效率。

需要理解的是，上述两种处理方式在向服务器侧发送运行状态信息的时候，可以首先进行运行状态信息的打包、压缩等操作，最终将压缩后得到的信息发送给服务器侧。

第三种处理方式、

终端设备可以将检测到的运行状态信息中的第二类运行状态信息主动上报给服务器侧，以使得服务器侧进行相关分析，具体如下：

所述将所述至少一条运行状态信息中的至少部分运行状态信息发送至服务器侧，包括：

执行所述操作事件中、将至少一条运行状态信息中的第二类运行状态信息发送至所述服务器侧；也就是说，只要在处理任意一个操作事件的时候，一旦检测到第二类运行状态信息，就直接将该第二类运行状态信息上报给服务器；

或者，

当所述操作事件结束时，将所述操作事件所对应的至少一条运行状态信息中的第二类运行状态信息进行压缩，将压缩后的第二类运行状态信息发送至所述服务器侧；也就是说，处理任意一个操作事件结束的时候，将该操作事件中得到的全部第二类运行状态信息上报给服务器；

或者，

当所述目标应用关闭后、且删除所述目标应用对应的缓存信息之前，将所述目标应用中至少一个操作事件对应的至少一条运行状态信息中的第二类运行状态信息进行压缩，将压缩后的所述第二类运行状态信息发送至所述服务器侧；也就是说，处理目标应用在结束操作之后，将该目标应用的全部操作事件中得到的全部第二类运行状态信息上报给服务器。

本处理方式尤其适用于未接收到服务器侧发来的配置信息的场景中。也就是说，在本处理方式中，不受限于服务器的指令，只要检测到第二类运行状态信息(异常日志)就将该异常日志进行上报。

进一步地，上报所述第二类运行状态信息中可以至少包括有：目标应用的标识信息、操作事件、生成时刻、以及具体的运行状态信息。除了上述的一些参数之外，所述第二类运行状态信息中还可以包括有用户账号、目标应用的版本号等信息，这里不再进行穷举。

第四种处理方式、

可以综合使用第一种处理方式以及第三种处理方式，或者综合使用第二种处理方式以及第三种处理方式，具体的：

可以在接收到配置信息之后，在目标操作事件中采用第一种处理方式或第二种处理方式进行处理；除了上述目标操作事件之外，采用第三种处理方式进行处理。

基于上述第四种处理方式，结合图7，进行具体说明：分为两种场景，一种是事件监听场景，一种是主动上传场景：

事件监听场景：事件监听场景一般是用户反馈问题给开发人员后，开发人员在后台配置日志下发配置，例如指定用户ID，用户反馈的问题出现的时间点，及客户端的版本和环境信息。日志Agent相当于一个守护进程，每当用户做一些特定操作时，都会从服务器拉取相关的日志上传信息，查看是否需要拉取相关日志。当开发人员配置完相关信息后，用户触发相关事件时，日志Agent则会拉取日志上传任务信息，并解析日志上传任务的时间区间等，然后读取本地日志文件中相关区间的日志，打包，压缩并上传到服务器。

主动上传场景：事件监听场景一般是用户反馈信息后，开发人员配置相关下发任务后，才会触发上传，而对于异常场景的日志，用户可能会由于清空本地缓存等等原则，破坏第一现场的信息。所以对于异常场景的日志，不拉取日志上传任务，而是直接打包，压缩，上传到服务器上。

配置信息基于DB，开发人员配置的任务列表存储在DB中，并借助于缓存 (例如memcache)来提升访问速度，可以采用表结构。

可见，通过采用上述方案，就能够在终端设备侧检测到目标应用的至少一个运行状态信息的时候，主动向服务器侧上报至少一个运行状态信息中的至少部分运行状态信息。如此，就避免了由用户选择上报的状态信息而带来的***侧无法全面掌握其关心的状态信息，以及影响用户针对目标应用的使用体现等问题。

实施例二、

本实施例提供了一种终端设备，如图8-1所示，包括：

应用管理单元81，用于运行目标应用，得到至少一个操作事件对应的至少一条运行状态信息；其中，所述运行状态信息至少包括有第一类运行状态信息以及第二类运行状态信息，所述第一类运行状态信息表征所述目标应用在对应的操作事件中的正常运行状态；所述第二类运行状态信息表征所述目标应用在对应的操作事件中的异常运行状态；

信息上报单元82，用于将所述目标应用的至少一个操作事件对应的所述至少一条运行状态信息中，至少部分运行状态信息发送至服务器侧，以使得所述服务器侧基于所述至少一个操作事件的至少部分运行状态信息对所述目标应用进行分析处理。

这里，所述终端设备可以为任意一种能够提供针对应用的处理功能的设备，比如，可以为智能手机、平板电脑或者台式机等等，本实施例中不进行穷举。

所述目标应用可以为终端设备中安全的多个应用中的任意一种应用，可以为能够与网络侧进行交互的应用，可以为不能够与网络侧进行交互的应用。

所述目标应用的至少一个操作事件，可以为所述目标应用从开启到正常运行以及关闭的过程中所对应的多种操作事件，比如，如图4所示，用户开启应用A，终端设备进行开启操作事件；然后用户可以进入执行登录进程的操作，比如，图中所示用户以账号A登录应用A，此时对应的登录操作事件；用户以账号A登录应用A之后，可以进入的为交互操作事件，此时，可以针对不同的操作进入不同的操作事件，比如，可以为游戏进程、即时通信交互等等。

进一步地，至少一个操作事件的至少一条运行状态信息可以为包括有：运行目标应用的每一个操作事件的时候，可以在***中生成一个日志，该日志用于记录其对应的操作事件的正常运行状态信息或者异常运行的状态信息。

在运行目标应用的至少一个操作事件得到至少一条运行状态信息之后，还包括有将所述至少一条运行状态信息保存至所述目标应用对应的缓存中；具体来说，可以在每检测得到一条运行状态信息时就在缓存中保存一条；所述缓存可以对应一个保存路径，保存路径可以为与所述目标应用相关的一条默认路径，也可以为用户根据实际情况设定，比如，可以设定为SD卡中的文件夹1等等，这里不进行穷举。

进一步地，所述终端设备还能够对至少一条运行状态信息进行分类，比如，可以根据关键字选取得到第二类运行状态信息(即异常日志信息)，剩余的即为第一类运行状态信息。具体来说，所述关键字可以为根据实际情况设置的一些信息，比如，可以为在运行状态信息中出现“error”等信息时，确定其为第二类运行状态信息(即异常日志信息)。比如，参见图5，当运行一个应用A的时候，假设其中的一个进程为开启应用A的操作事件，此时可以生成三个日志，分别为图中的日志1、日志2和日志3；假设日志3中有“error”这种字眼，那么可以将日志3作为第二类运行状态信息即异常日志。

相应的，当得到至少一条运行状态信息之后，可以将所述至少一条运行状态信息中的至少部分运行状态信息发送至服务器侧，可以包括多种处理方式，如下：

第一种处理方式、

基于服务器发来的配置信息，从多个运行状态信息中选取部分运行状态信息发送至服务器，具体的：

比如，如图8-2所示，所述终端设备还包括：信息接收单元83，用于接收到所述服务器侧发来的配置信息，其中，所述配置信息中包括以下至少之一：至少一个目标操作事件、预设时间段。

其中，所述至少一个目标操作事件可以为服务器侧当前关心的某些进程下发至终端设备。

服务器侧由管理人员来确定哪些操作事件是当前关心的，比如，可以是用户报错较多的一些进程，假设用户经常上报登录问题，那么可以将登录的操作事件作为一个目标操作事件；或者，可以为根据当前目标应用出现修改版本了，那么针对修订后的最新版本比较关心修改部分对应的操作事件，那么就将修改部分对应的操作事件作为一个目标操作事件。

关于预设时间段可以根据实际情况来设置，比如，可以针对较为密集的操作时间进行采集，比如，当目标应用为一个网络游戏的时候，那么可能在晚上 8-10点之间出现较为密集的用户交互行为，那么可以将预设时间段设置在1个月内的8-10PM；或者，目标应用的新版本刚刚发布，那么正在发布的这1个月内可能会比较关心相关的使用情况，就将这1个月均作为预设时间段进行日志的上报。

另外，所述配置信息中还可以包括有其他一些信息以使得服务器结合更多的情况进行检测，比如，可以包括有登录目标应用时的用户账号、当前的终端设备的运行***(可以包括有安卓、IOS、Windows等***)、版本信息、上传路径等等信息。

本场景中，所述将所述至少一条运行状态信息中的至少部分运行状态信息发送至服务器侧，包括：

所述信息上报单元，用于基于所述配置信息，将所述至少一个目标操作事件对应的至少一条运行状态信息，发送至所述服务器侧；

和/或，

所述信息上报单元，用于基于所述配置信息，将生成时刻处于所述预设时间段内的至少一条运行状态信息，发送至所述服务器侧。

也就是说，不论终端设备是否检测有第二类运行状态信息，只要是针对目标操作事件、或者是在预设时间段内的运行状态信息就将该日志信息发送到服务器侧；相应的，服务器侧能够根据接收到的多个终端设备发来的运行情况来综合分析目标操作事件是否存在问题。

可以理解的是，上述上报目标操作事件、以及预设时间段内的运行状态信息这两个条件可以结合使用，比如，可以为目标操作事件在预设时间段内的部分运行状态信息。

第二种处理方式、

服务器侧下发配置信息，在配置信息中可以限定有目标操作事件、预设时间段等等参数，但是在终端设备上报运行状态信息时，可以先进行一些筛选，仅上报第二类运行状态信息，具体如下：

所述信息上报单元，用于基于所述配置信息，将所述至少一个目标操作事件对应的至少一条第二类运行状态信息，发送至所述服务器侧；

和/或，

所述信息上报单元，用于基于所述配置信息，将生成时刻处于所述预设时间段内的至少一条第二类运行状态信息，发送至所述服务器侧。

关于配置信息的具体获取以及其中的参数与第一种处理场景相同，这里不再进行赘述。

与第一种处理方式不同之处在于，本场景中，在上报部分运行状态信息的时候，首先进行一次筛选，仅将存在异常部分状态信息进行上报，这种处理场景，能够减少与服务器侧进行数据交互的通信量，并且并不会对服务器侧进行分析的效果有所影响，提升了一定的处理效率。

需要理解的是，上述两种处理方式在向服务器侧发送运行状态信息的时候，可以首先进行运行状态信息的打包、压缩等操作，最终将压缩后得到的信息发送给服务器侧。

第三种处理方式、

终端设备可以将检测到的运行状态信息中的第二类运行状态信息主动上报给服务器侧，以使得服务器侧进行相关分析，具体如下：

所述将所述至少一条运行状态信息中的至少部分运行状态信息发送至服务器侧，包括：

所述信息上报单元，用于执行所述操作事件中、将至少一条运行状态信息中的第二类运行状态信息发送至所述服务器侧；也就是说，只要在处理任意一个操作事件的时候，一旦检测到第二类运行状态信息，就直接将该第二类运行状态信息上报给服务器；

或者，

所述信息上报单元，用于当所述操作事件结束时，将所述操作事件所对应的至少一条运行状态信息中的第二类运行状态信息进行压缩，将压缩后的第二类运行状态信息发送至所述服务器侧；也就是说，处理任意一个操作事件结束的时候，将该操作事件中得到的全部第二类运行状态信息上报给服务器；

或者，

所述信息上报单元，用于当所述目标应用关闭后、且删除所述目标应用对应的缓存信息之前，将所述目标应用中至少一个操作事件对应的至少一条运行状态信息中的第二类运行状态信息进行压缩，将压缩后的所述第二类运行状态信息发送至所述服务器侧；也就是说，处理目标应用在结束操作之后，将该目标应用的全部操作事件中得到的全部第二类运行状态信息上报给服务器。

本处理方式尤其适用于未接收到服务器侧发来的配置信息的场景中。也就是说，在本处理方式中，不受限于服务器的指令，只要检测到第二类运行状态信息(异常日志)就将该异常日志进行上报。

进一步地，上报所述第二类运行状态信息中可以至少包括有：目标应用的标识信息、操作事件、生成时刻、以及具体的运行状态信息。除了上述的一些参数之外，所述第二类运行状态信息中还可以包括有用户账号、目标应用的版本号等信息，这里不再进行穷举。

第四种处理方式、

可以综合使用第一种处理方式以及第三种处理方式，或者综合使用第二种处理方式以及第三种处理方式，具体的：

可以在接收到配置信息之后，在目标操作事件中采用第一种处理方式或第二种处理方式进行处理；除了上述目标操作事件之外，采用第三种处理方式进行处理。

基于上述第四种处理方式，结合图8，进行具体说明：分为两种场景，一种是事件监听场景，一种是主动上传场景：

事件监听场景：事件监听场景一般是用户反馈问题给开发人员后，开发人员在后台配置日志下发配置，例如指定用户ID，用户反馈的问题出现的时间点，及客户端的版本和环境信息。日志Agent相当于一个守护进程，每当用户做一些特定操作时，都会从服务器拉取相关的日志上传信息，查看是否需要拉取相关日志。当开发人员配置完相关信息后，用户触发相关事件时，日志Agent则会拉取日志上传任务信息，并解析日志上传任务的时间区间等，然后读取本地日志文件中相关区间的日志，打包，压缩并上传到服务器。

主动上传场景：事件监听场景一般是用户反馈信息后，开发人员配置相关下发任务后，才会触发上传，而对于异常场景的日志，用户可能会由于清空本地缓存等等原则，破坏第一现场的信息。所以对于异常场景的日志，不拉取日志上传任务，而是直接打包，压缩，上传到服务器上。

配置信息基于DB，开发人员配置的任务列表存储在DB中，并借助于缓存 (例如memcache)来提升访问速度，可以采用表结构。

可见，通过采用上述方案，就能够在终端设备侧检测到目标应用的至少一个运行状态信息的时候，主动向服务器侧上报至少一个运行状态信息中的至少部分运行状态信息。如此，就避免了由用户选择上报的状态信息而带来的***侧无法全面掌握其关心的状态信息，以及影响用户针对目标应用的使用体现等问题。

本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于一计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：移动存储设备、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

或者，本发明上述集成的单元如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机、服务器、或者网络设备等)执行本发明各个实施例所述方法的全部或部分。而前述的存储介质包括：移动存储设备、ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。

Claims (5)

1.一种信息上传方法，应用于终端设备，其特征在于，所述方法包括：

接收服务器侧发送的配置信息，其中，所述配置信息包括至少一个目标操作事件和预设时间段，所述目标操作事件为登录 操作事件或者针对修订后的目标应用的修改部分的操作事件；

运行目标应用，得到至少一个操作事件对应的至少一条运行状态信息；其中，所述运行状态信息至少包括有第一类运行状态信息以及第二类运行状态信息，所述第一类运行状态信息表征所述目标应用在对应的操作事件中的正常运行状态；所述第二类运行状态信息表征所述目标应用在对应的操作事件中的异常运行状态；

针对所述目标操作事件，基于所述配置信息，将所述目标应用的至少一个操作事件对应的所述至少一条运行状态信息中，与所述目标操作事件对应的、且生成时刻处于所述预设时间段内的第二类运行状态信息发送至服务器侧，以使得所述服务器侧基于与所述目标操作事件对应的、且生成时刻处于所述预设时间段内的第二类运行状态信息，对所述目标操作事件进行异常分析；

针对所述至少一个操作事件中不同于所述目标操作事件的其他操作事件，执行以下处理：

当所述其他操作事件执行结束时，将所述其他操作事件所对应的至少一条运行状态信息中的第二类运行状态信息进行压缩，将压缩后的第二类运行状态信息发送至所述服务器侧，以使得所述服务器侧基于接收到的所述其他操作事件所对应的至少一条运行状态信息中的第二类运行状态信息，对所述其他操作事件进行异常分析；

或者，当所述目标应用关闭后、且删除所述目标应用对应的缓存信息之前，将所述目标应用的至少一个操作事件对应的至少一条运行状态信息中的第二类运行状态信息进行压缩，将压缩后的所述第二类运行状态信息发送至所述服务器侧，以使得所述服务器侧基于接收到的所述目标应用的至少一个操作事件对应的至少一条运行状态信息中的第二类运行状态信息，对所述其他操作事件进行异常分析；

其中，所述第二类运行状态信息包括以下至少之一：目标应用的标识信息、目标应用的版本号、操作事件、生成时刻以及具体运行状态信息。

2.根据权利要求1所述的方法，其特征在于，所述针对所述目标操作事件，基于所述配置信息，将所述目标应用的至少一个操作事件对应的所述至少一条运行状态信息中，与所述目标操作事件对应的、且生成时刻处于所述预设时间段内的第二类运行状态信息发送至服务器侧，包括：

执行所述目标操作事件中，基于所述配置信息，将与所述目标操作事件对应的、且生成时刻处于所述预设时间段内的第二类运行状态信息发送至所述服务器侧；

或者，

当所述目标操作事件结束时，基于所述配置信息，将与所述目标操作事件对应的、且生成时刻处于所述预设时间段内的第二类运行状态信息进行压缩，将压缩后的第二类运行状态信息发送至所述服务器侧；

或者，

当所述目标应用关闭后、且删除所述目标应用对应的缓存信息之前，基于所述配置信息，将与所述目标操作事件对应的、且生成时刻处于所述预设时间段内的第二类运行状态信息进行压缩，将压缩后的所述第二类运行状态信息发送至所述服务器侧。

3.一种终端设备，其特征在于，所述终端设备包括：

应用管理单元，用于接收服务器侧发送的配置信息，其中，所述配置信息包括至少一个目标操作事件和预设时间段，所述目标操作事件为登录 操作事件或者针对修订后的目标应用的修改部分的操作事件；运行目标应用，得到至少一个操作事件对应的至少一条运行状态信息；其中，所述运行状态信息至少包括有第一类运行状态信息以及第二类运行状态信息，所述第一类运行状态信息表征所述目标应用在对应的操作事件中的正常运行状态；所述第二类运行状态信息表征所述目标应用在对应的操作事件中的异常运行状态；

信息上报单元，用于针对所述目标操作事件，基于所述配置信息，将所述目标应用的至少一个操作事件对应的所述至少一条运行状态信息中，与所述目标操作事件对应的、且生成时刻处于所述预设时间段内的第二类运行状态信息发送至服务器侧，以使得所述服务器侧基于与所述目标操作事件对应的、且生成时刻处于所述预设时间段内的第二类运行状态信息，对所述目标操作事件进行异常分析；

针对所述至少一个操作事件中不同于所述目标操作事件的其他操作事件，执行以下处理：

当所述其他操作事件执行结束时，将所述其他操作事件所对应的至少一条运行状态信息中的第二类运行状态信息进行压缩，将压缩后的第二类运行状态信息发送至所述服务器侧，以使得所述服务器侧基于接收到的所述其他操作事件所对应的至少一条运行状态信息中的第二类运行状态信息，对所述其他操作事件进行异常分析；

或者，当所述目标应用关闭后、且删除所述目标应用对应的缓存信息之前，将所述目标应用的至少一个操作事件对应的至少一条运行状态信息中的第二类运行状态信息进行压缩，将压缩后的所述第二类运行状态信息发送至所述服务器侧，以使得所述服务器侧基于接收到的所述目标应用的至少一个操作事件对应的至少一条运行状态信息中的第二类运行状态信息，对所述其他操作事件进行异常分析；

其中，所述第二类运行状态信息包括以下至少之一：目标应用的标识信息、目标应用的版本号、操作事件、生成时刻以及具体运行状态信息。

4.根据权利要求3所述的终端设备，其特征在于，所述信息上报单元，用于执行所述目标操作事件中，基于所述配置信息，将与所述目标操作事件对应的、且生成时刻处于所述预设时间段内的第二类运行状态信息发送至所述服务器侧；

或者，

当所述目标操作事件结束时，基于所述配置信息，将与所述目标操作事件对应的、且生成时刻处于所述预设时间段内的第二类运行状态信息进行压缩，将压缩后的第二类运行状态信息发送至所述服务器侧；

或者，

当所述目标应用关闭后、且删除所述目标应用对应的缓存信息之前，基于所述配置信息，将与所述目标操作事件对应的、且生成时刻处于所述预设时间段内的第二类运行状态信息进行压缩，将压缩后的所述第二类运行状态信息发送至所述服务器侧。

5.一种存储介质，其特征在于，存储有计算机程序，用于被计算机设备执行时，实现权利要求1至2任一项所述的信息上传方法。

Images