数据上报装置及方法

数据上报装置及方法
【专利摘要】本发明公开了一种数据上报装置，包括：存储模块，用于在每次接收到软件开发工具包发送的数据时，保存所述数据，其中，所述数据为所述软件开发工具包对应的应用在运行中时，所述软件开发工具包采集的数据，所述数据包括紧急类型数据和普通类型数据；第一发送模块，用于每间隔第一预设时长将所述第一预设时长内保存的紧急类型数据上报至服务器；第二发送模块，用于每间隔第二预设时长将所述第二预设时长内保存的普通类型数据上报至所述服务器；其中，所述第一预设时长小于所述第二预设时长。本发明还公开了一种数据上报方法。本发明实现了低功耗的同时，及时上报紧急类型数据。
【专利说明】
数据上报装置及方法
技术领域
[0001 ]本发明涉及通信技术领域，尤其涉及一种数据上报装置及方法。
【背景技术】
[0002] 在移动互联网时代，随着智能手机、PAD(平板电脑）等终端的推广和普及，形式色 色的各种应用应运而生。各应用在运行中时，会记录相应的数据并将其上报至服务器，通过 服务器对上报的数据进行分析，从而根据分析结果实现制定应用下一版本的开发计划、完 善应用运营策略等效果。现有将数据上报至服务器的方式主要包括以下两种：（1)、在各应 用中集成数据统计SDK软件开发工具包(Software Development Kit，软件开发工具包），由 各SDK软件开发工具包将对应应用运行的数据独立上报至服务器；（2)、将各应用运行数据 统一由一个数据上报应用定时上报至服务器。在第(1)种方式中，由于软件开发工具包每当 采集到数据时，就将其上报至服务器，虽然对于一些需要及时上报的紧急类型数据，能够达 到及时上报至服务器的效果，但由于不断地上报数据，导致了非常高的功耗;在第(2)种方 式中，通过数据上报应用统一定时上报，虽然降低了功耗，但又存在紧急类型数据不能及时 上报的问题。总之，现有的上报数据的方式无法兼顾低功耗和及时上报紧急类型数据。

【发明内容】

[0003] 本发明的主要目的在于提出一种数据上报装置及方法，旨在解决现有技术中不能 兼顾低功耗和及时上报紧急类型数据的技术问题。
[0004] 为实现上述目的，本发明提供的一种数据上报装置，所述数据上报装置包括：
[0005] 存储模块，用于在每次接收到软件开发工具包发送的数据时，保存所述数据，其 中，所述数据为所述软件开发工具包对应的应用在运行中时，所述软件开发工具包采集的 数据，所述数据包括紧急类型数据和普通类型数据；
[0006] 第一发送模块，用于每间隔第一预设时长将所述第一预设时长内保存的紧急类 型数据上报至服务器；
[0007] 第二发送模块，用于每间隔第二预设时长将所述第二预设时长内保存的普通类型 数据上报至所述服务器;其中，所述第一预设时长小于所述第二预设时长。
[0008] 可选地，所述数据上报装置还包括：
[0009] 获取模块，用于每间隔第一预设时长，获取所述第一预设时长内保存的封装有紧 急标识信息的数据，其中，所述软件开发工具包在根据预设的数据格式封装数据时，在紧急 类型数据中封装紧急标识信息；
[0010]确定模块，用于将封装有所述紧急标识信息的数据作为紧急类型数据。
[0011] 可选地，所述数据上报装置还包括：
[0012] 第一判断模块，用于判断当前接收到的所述数据是否为紧急类型数据；
[0013] 第二判断模块，用于在当前接收到的所述数据为紧急类型数据时，确定是否已开 始计时；
[0014]计时模块，用于在未开始计时时，开始计时；
[0015]所述第一发送模块，用于在计时达到所述第一预设时长时，将所述第一预设时长 内保存的紧急类型数据上报至所述服务器。
[0016] 此外，为实现上述目的，本发明还提出一种数据上报装置，所述数据上报装置包 括：
[0017] 采集模块，用于采集软件开发工具包对应的应用在运行中的数据，其中，所述数据 包括紧急类型数据和普通类型数据；
[0018] 第三发送模块，用于在采集的所述数据为紧急类型数据时，调用预设的加急接口 将所述紧急类型数据发送至数据上报应用，以供所述数据上报应用保存所述紧急类型数 据，并每间隔第一预设时长将所述第一预设时长内保存的紧急类型数据上报至服务器；
[0019] 第四发送模块，用于在采集的所述数据为普通类型数据时，调用预设的普通接口 将所述普通类型数据发送至所述数据上报应用，以供所述数据上报应用保存所述普通类型 数据，并每间隔第二预设时长将所述第二预设时长内保存的普通类型数据上报至所述服务 器；
[0020] 其中，所述第一预设时长小于所述第二预设时长。
[0021] 可选地，所述第三发送模块包括：
[0022] 封装单元，用于在采集的所述数据为紧急类型数据时，在所述紧急类型数据中封 装紧急标识信息；
[0023] 发送单元，用于调用预设的加急接口将封装有所述紧急标识信息的所述紧急类型 数据发送至数据上报应用。
[0024] 此外，为实现上述目的，本发明还提出一种数据上报方法，所述数据上报方法包括 以下步骤：
[0025] 在每次接收到软件开发工具包发送的数据时，保存所述数据，其中，所述数据为所 述软件开发工具包对应的应用在运行中时，所述软件开发工具包采集的数据，所述数据包 括紧急类型数据和普通类型数据；
[0026] 每间隔第一预设时长将所述第一预设时长内保存的紧急类型数据上报至服务器；
[0027] 每间隔第二预设时长将所述第二预设时长内保存的普通类型数据上报至所述服 务器；
[0028] 其中，所述第一预设时长小于所述第二预设时长。
[0029] 可选地，所述每间隔第一预设时长将所述第一预设时长内保存的紧急类型数据上 报至服务器的步骤之前，还包括：
[0030] 每间隔第一预设时长，获取所述第一预设时长内保存的封装有紧急标识信息的数 据，其中，所述软件开发工具包在根据预设的数据格式封装数据时，在紧急类型数据中封装 紧急标识信息；
[0031 ]将封装有所述紧急标识信息的数据作为紧急类型数据。
[0032] 可选地，所述在每次接收到软件开发工具包发送的数据时，保存所述数据的步骤 之后，还包括：
[0033] 判断当前接收到的所述数据是否为紧急类型数据；
[0034] 在当前接收到的所述数据为紧急类型数据时，确定是否已开始计时；
[0035] 若未开始计时，则开始计时；
[0036] 在计时达到所述第一预设时长时，将所述第一预设时长内保存的紧急类型数据上 报至所述服务器。
[0037] 此外，为实现上述目的，本发明还提出一种数据上报方法，所述数据上报方法包括 以下步骤：
[0038] 软件开发工具包采集所述软件开发工具包对应的应用在运行中的数据，其中，所 述数据包括紧急类型数据和普通类型数据；
[0039] 在采集的所述数据为紧急类型数据时，调用预设的加急接口将所述紧急类型数据 发送至数据上报应用，以供所述数据上报应用保存所述紧急类型数据，并每间隔第一预设 时长将所述第一预设时长内保存的紧急类型数据上报至服务器；
[0040] 在采集的所述数据为普通类型数据时，调用预设的普通接口将所述普通类型数据 发送至所述数据上报应用，以供所述数据上报应用保存所述普通类型数据，并每间隔第二 预设时长将所述第二预设时长内保存的普通类型数据上报至所述服务器；
[0041] 其中，所述第一预设时长小于所述第二预设时长。
[0042] 可选地，所述在采集的所述数据为紧急类型数据时，调用预设的加急接口将所述 紧急类型数据发送至数据上报应用的步骤包括：
[0043] 在采集的所述数据为紧急类型数据时，在所述紧急类型数据中封装紧急标识信 息；
[0044] 调用预设的加急接口将封装有所述紧急标识信息的所述紧急类型数据发送至数 据上报应用。
[0045] 本发明提出的数据上报装置及方法，在每次接收到软件开发工具包发送的数据 时，不管该数据是紧急类型数据还是普通类型数据，存储模块先保存该数据，然后针对保存 的紧急类型数据，第一发送模块以较短时间的第一预设时长的时间间隔，将其上报至服务 器，从而实现了紧急类型数据能及时地上报至服务器;而针对保存的普通类型数据，第二发 送模块以较长时间的第二预设时长的时间间隔，将其上报至服务器，从而减少了与服务器 连接次数和数据上报的次数，降低了功耗，因此，本发明实现了低功耗的同时，及时上报紧 急类型数据。
【附图说明】
[0046] 图1为实现本发明各个实施例一个可选的移动终端的硬件结构示意图；
[0047] 图2为如图1所示的移动终端的无线通信系统示意图；
[0048]图3为本发明数据上报装置第一实施例的模块示意图；
[0049] 图4为本发明中数据上报系统的一个可选示意图；
[0050] 图5为本发明数据上报装置第二实施例的模块示意图；
[0051]图6为本发明数据上报装置第三实施例的模块示意图；
[0052]图7为本发明数据上报装置第四实施例的模块示意图；
[0053]图8为本发明数据上报方法第一实施例的流程示意图；
[0054]图9为本发明数据上报方法第二实施例的流程示意图；
[0055]图10为本发明数据上报方法第三实施例的流程示意图；
[0056] 图11为本发明数据上报方法第四实施例的流程示意图。
[0057] 本发明目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。
【具体实施方式】
[0058]应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。
[0059] 现在将参考附图描述实现本发明各个实施例的移动终端。在后续的描述中，使用 用于表示元件的诸如"模块"、"部件"或"单元"的后缀仅为了有利于本发明的说明，其本身 并没有固有的意义。因此，"模块"与"部件"可以混合地使用。
[0060] 移动终端可以以各种形式来实施。例如，本发明中描述的终端可以包括诸如移动 电话、智能电话、笔记本电脑、数字广播接收器、PDA(个人数字助理）、PAD(平板电脑）、PMP (便携式多媒体播放器）、导航装置等等的移动终端以及诸如数字TV、台式计算机等等的固 定终端。下面，假设终端是移动终端。然而，本领域技术人员将理解的是，除了特别用于移动 目的的元件之外，根据本发明的实施方式的构造也能够应用于固定类型的终端。
[0061] 图1为实现本发明各个实施例的一个可选的移动终端的硬件结构示意。
[0062] 移动终端100可以包括无线通信单元110、A/V(音频/视频)输入单元120、输出单 元150、存储器160、接口单元170、控制器180和电源单元190等等。图1示出了具有各种组件 的移动终端，但是应理解的是，并不要求实施所有示出的组件。可以替代地实施更多或更少 的组件。将在下面详细描述移动终端的元件。
[0063] 无线通信单元110通常包括一个或多个组件，其允许移动终端100与无线通信系统 或网络之间的无线电通信。例如，无线通信单元可以包括移动通信模块112、无线互联网模 块113、短程通信模块114中的至少一个。
[0064] 移动通信模块112将无线电信号发送到基站(例如，接入点、节点B等等）、外部终端 以及服务器中的至少一个和/或从其接收无线电信号。这样的无线电信号可以包括语音通 话信号、视频通话信号、或者根据文本和/或多媒体消息发送和/或接收的各种类型的数据。 [0065]无线互联网模块113支持移动终端的无线互联网接入。该模块可以内部或外部地 耦接到终端。该模块所涉及的无线互联网接入技术可以包括WLAN(无线LAN) (Wi-Fi)、Wibro (无线宽带）、Wimax(全球微波互联接入）、HSDPA(高速下行链路分组接入)等等。
[0066]短程通信模块114是用于支持短程通信的模块。短程通信技术的一些示例包括蓝 牙?、射频识别(RFID)、红外数据协会(IrDA)、超宽带(UWB)、紫蜂?等等。
[0067] A/V输入单元120用于接收音频或视频信号。A/V输入单元120可以包括相机121和 麦克风122,相机121对在视频捕获模式或图像捕获模式中由图像捕获装置获得的静态图片 或视频的图像数据进行处理。处理后的图像帧可以显示在显示单元151上。经相机121处理 后的图像帧可以存储在存储器160(或其它存储介质）中或者经由无线通信单元110进行发 送，可以根据移动终端的构造提供两个或更多相机121。麦克风122可以在电话通话模式、记 录模式、语音识别模式等等运行模式中经由麦克风接收声音(音频数据），并且能够将这样 的声音处理为音频数据。处理后的音频(语音)数据可以在电话通话模式的情况下转换为可 经由移动通信模块112发送到移动通信基站的格式输出。麦克风122可以实施各种类型的噪 声消除（或抑制）算法以消除（或抑制)在接收和发送音频信号的过程中产生的噪声或者干 扰。
[0068] 接口单元170用作至少一个外部装置与移动终端100连接可以通过的接口。例如， 外部装置可以包括有线或无线头戴式耳机端口、外部电源(或电池充电器)端口、有线或无 线数据端口、存储卡端口、用于连接具有识别模块的装置的端口、音频输入/输出（I/O)端 口、视频I/O端口、耳机端口等等。识别模块可以是存储用于验证用户使用移动终端100的各 种信息并且可以包括用户识别模块(UIM)、客户识别模块(SIM)、通用客户识别模块(USM) 等等。另外，具有识别模块的装置(下面称为"识别装置")可以采取智能卡的形式，因此，识 别装置可以经由端口或其它连接装置与移动终端100连接。接口单元170可以用于接收来自 外部装置的输入(例如，数据信息、电力等等)并且将接收到的输入传输到移动终端100内的 一个或多个元件或者可以用于在移动终端和外部装置之间传输数据。
[0069] 另外，当移动终端100与外部底座连接时，接口单元170可以用作允许通过其将电 力从底座提供到移动终端100的路径或者可以用作允许从底座输入的各种命令信号通过其 传输到移动终端的路径。从底座输入的各种命令信号或电力可以用作用于识别移动终端是 否准确地安装在底座上的信号。输出单元150被构造为以视觉、音频和/或触觉方式提供输 出信号(例如，音频信号、视频信号、警报信号、振动信号等等）。
[0070] 输出单元150可以包括显示单元151、音频输出模块152等等。
[0071] 显示单元151可以显示在移动终端100中处理的信息。例如，当移动终端100处于电 话通话模式时，显示单元151可以显示与通话或其它通信(例如，文本消息收发、多媒体文件 下载等等)相关的用户界面(UI)或图形用户界面(GUI)。当移动终端100处于视频通话模式 或者图像捕获模式时，显示单元151可以显示捕获的图像和/或接收的图像、示出视频或图 像以及相关功能的UI或GUI等等。
[0072]同时，当显示单元151和触摸板以层的形式彼此叠加以形成触摸屏时，显示单元 151可以用作输入装置和输出装置。显示单元151可以包括液晶显示器(LCD)、薄膜晶体管 IXD(TFT-IXD)、有机发光二极管(0LED)显示器、柔性显示器、三维(3D)显示器等等中的至少 一种。这些显示器中的一些可以被构造为透明状以允许用户从外部观看，这可以称为透明 显示器，典型的透明显示器可以例如为T0LED(透明有机发光二极管）显示器等等。根据特定 想要的实施方式，移动终端100可以包括两个或更多显示单元(或其它显示装置），例如，移 动终端可以包括外部显示单元(未示出）和内部显示单元(未示出）。触摸屏可用于检测触摸 输入压力以及触摸输入位置和触摸输入面积。
[0073]音频输出模块152可以在移动终端处于呼叫信号接收模式、通话模式、记录模式、 语音识别模式、广播接收模式等等模式下时，将无线通信单元110接收的或者在存储器160 中存储的音频数据转换音频信号并且输出为声音。而且，音频输出模块152可以提供与移动 终端100执行的特定功能相关的音频输出（例如，呼叫信号接收声音、消息接收声音等等）。 音频输出模块152可以包括扬声器、蜂鸣器等等。
[0074]存储器160可以存储由控制器180执行的处理和控制操作的软件程序等等，或者可 以暂时地存储己经输出或将要输出的数据(例如，电话簿、消息、静态图像、视频等等）。而 且，存储器160可以存储关于当触摸施加到触摸屏时输出的各种方式的振动和音频信号的 数据。
[0075]存储器160可以包括至少一种类型的存储介质，所述存储介质包括闪存、硬盘、多 媒体卡、卡型存储器(例如，SD或DX存储器等等）、随机访问存储器(RAM)、静态随机访问存储 器（SRAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、可编程只读存储器 (PROM)、磁性存储器、磁盘、光盘等等。而且，移动终端100可以与通过网络连接执行存储器 160的存储功能的网络存储装置协作。
[0076] 控制器180通常控制移动终端的总体操作。例如，控制器180执行与语音通话、数据 通信、视频通话等等相关的控制和处理。控制器180可以执行模式识别处理，以将在触摸屏 上执行的手写输入或者图片绘制输入识别为字符或图像。
[0077]电源单元190在控制器180的控制下接收外部电力或内部电力并且提供操作各元 件和组件所需的适当的电力。
[0078]这里描述的各种实施方式可以以使用例如计算机软件、硬件或其任何组合的计算 机可读介质来实施。对于硬件实施，这里描述的实施方式可以通过使用特定用途集成电路 (ASIC)、数字信号处理器(DSP)、数字信号处理装置(DSPD)、可编程逻辑装置(PLD)、现场可 编程门阵列(FPGA)、处理器、控制器、微控制器、微处理器、被设计为执行这里描述的功能的 电子单元中的至少一种来实施，在一些情况下，这样的实施方式可以在控制器180中实施。 对于软件实施，诸如过程或功能的实施方式可以与允许执行至少一种功能或操作的单独 的软件模块来实施。软件代码可以由以任何适当的编程语言编写的软件应用程序(或程序） 来实施，软件代码可以存储在存储器160中并且由控制器180执行。
[0079] 至此，己经按照其功能描述了移动终端。下面，为了简要起见，将描述诸如折叠型、 直板型、摆动型、滑动型移动终端等等的各种类型的移动终端中的滑动型移动终端作为示 例。因此，本发明能够应用于任何类型的移动终端，并且不限于滑动型移动终端。
[0080] 如图1中所示的移动终端100可以被构造为利用经由帧或分组发送数据的诸如有 线和无线通信系统以及基于卫星的通信系统来操作。
[0081] 现在将参考图2描述其中根据本发明的移动终端能够操作的通信系统。
[0082] 这样的通信系统可以使用不同的空中接口和/或物理层。例如，由通信系统使用的 空中接口包括例如频分多址(FDMA)、时分多址(TDMA)、码分多址(CDMA)和通用移动通信系 统(UMTS)(特别地，长期演进(LTE))、全球移动通信系统(GSM)等等。作为非限制性示例，下 面的描述涉及CDMA通信系统，但是这样的教导同样适用于其它类型的系统。
[0083] 参考图2,⑶MA无线通信系统可以包括多个移动终端100、多个基站(BS)270、基站 控制器(BSC)275和移动交换中心(MSC)2800MSC280被构造为与公共电话交换网络(PSTN) 290形成接口。MSC280还被构造为与可以经由回程线路耦接到基站270的BSC275形成接口。 回程线路可以根据若干己知的接口中的任一种来构造，所述接口包括例如E1/T1、ATM，IP、 PPP、帧中继、HDSL、ADSL或xDSL。将理解的是，如图2中所示的系统可以包括多个BSC2750。
[0084]每个BS270可以服务一个或多个分区（或区域），由多向天线或指向特定方向的天 线覆盖的每个分区放射状地远离BS270。或者，每个分区可以由用于分集接收的两个或更多 天线覆盖。每个BS270可以被构造为支持多个频率分配，并且每个频率分配具有特定频谱 (例如，1·25ΜΗζ，5ΜΗζ 等等）。
[0085]分区与频率分配的交叉可以被称为CDMA信道。BS270也可以被称为基站收发器子 系统（BTS)或者其它等效术语。在这样的情况下，术语"基站"可以用于笼统地表示单个 BSC275和至少一个BS270。基站也可以被称为〃蜂窝站〃。或者，特定BS270的各分区可以被称 为多个蜂窝站。
[0086] 在图2中，示出了几个全球定位系统(GPS)卫星300。卫星300帮助定位多个移动终 端100中的至少一个。
[0087] 在图2中，描绘了多个卫星300,但是理解的是，可以利用任何数目的卫星获得有用 的定位信息。替代GPS跟踪技术或者在GPS跟踪技术之外，可以使用可以跟踪移动终端的位 置的其它技术。另外，至少一个GPS卫星300可以选择性地或者额外地处理卫星DMB传输。 [0088]作为无线通信系统的一个典型操作，BS270接收来自各种移动终端100的反向链路 信号。移动终端100通常参与通话、消息收发和其它类型的通信。特定基站270接收的每个反 向链路信号被在特定BS270内进行处理。获得的数据被转发给相关的BSC275ASC提供通话 资源分配和包括BS270之间的软切换过程的协调的移动管理功能。BSC275还将接收到的数 据路由到MSC280,其提供用于与PSTN290形成接口的额外的路由服务。类似地，PSTN290与 MSC280形成接口，MSC与BSC275形成接口，并且BSC275相应地控制BS270以将正向链路信号 发送到移动终端100。
[0089] 基于上述移动终端硬件结构以及通信系统，提出本发明数据上报装置各个实施 例。
[0090] 如图3所示，在第一实施例中，该数据上报装置包括：
[0091 ]存储模块1，用于在每次接收到软件开发工具包SDK发送的数据时，保存所述数据， 其中，所述数据为所述SDK对应的应用在运行中时，所述SDK采集的数据，所述数据包括紧急 类型数据和普通类型数据；
[0092] 本实施例中，该数据上报装置设置于移动终端内，且移动终端内加载的各个应用 中集成有数据统计软件开发工具包SDK(Software Development Kit，软件开发工具包），软 件开发工具包被集成到各个应用中，用于统计各个应用的启动信息、页面信息、事件点击信 息、CRASH信息等。并且，移动终端中还加载有一数据上报应用。可选地，该数据上报应用安 装于移动终端ROM中。当移动终端要将各个应用运行中对应的数据上报至服务器时，如图4 所示，各个应用对应的软件开发工具包、数据上报应用以及服务器组成数据上报系统。在各 个应用运行中时，其对应的软件开发工具包采集应用在运行中对应的数据，并将采集到的 数据发送至数据上报应用。可选地，软件开发工具包在采集到数据时，根据对应事件是否 为加急事件，将数据确定为紧急类型数据或普通类型数据。比如，当事件为加急事件时，软 件开发工具包将事件的数据确定为紧急类型数据;否则，软件开发工具包将事件的数据确 定为普通类型数据。然后，软件开发工具包将确定的紧急类型数据或者普通类型数据发送 至数据上报应用。
[0093] 当接收到软件开发工具包发送的数据时，存储模块1将接收到的数据进行保存。其 中，接收到的数据可能为紧急类型数据，也可能为普通类型数据，也即存储模块1保存的数 据包括紧急类型数据和普通类型数据。
[0094] 第一发送模块2,用于每间隔第一预设时长将所述第一预设时长内保存的紧急类 型数据上报至服务器；
[0095] 本实施例中，预先设置有第一预设时长Ti，该第一预设时长Ti的具体数值可根据事 件的加急情况进行灵活设置，在此不作限制。例如，当某一款应用对应的开发商需要在某个 节日做活动，开发商希望能够尽快掌握活动的效果，根据用户使用情况动态调整活动策略， 也即开发商希望能尽快获取各用户运行该应用对应的数据时，可将该第一预设时长!^设置 为10分钟。第一发送模块2每间隔第一预设时长Ti，就从第一预设时长Ti内保存的数据中查 询出紧急类型数据，也即每间隔10分钟就从当前10分钟内保存的数据中查询出紧急类型数 据，并将查询到的紧急类型数据上报至服务器，从而实现了在短时间内及时地上报紧急类 型数据。
[0096] 并且，由于在与服务器的每次通讯中，在每次上报数据至服务器的同时，还必须携 带公用的移动终端信息，包括移动终端的MEI号、MAC地址、移动终端生产厂商、操作系统、 操作系统版本、移动终端型号等。因此，现有技术中采用的在软件开发工具包每次接收到数 据时，就将其上报至服务器的方式，上报了很多的冗余数据。而本实施例中，由于第一发送 模块2是每间隔第一预设时长上报一次紧急类型数据，在实现及时地上报紧急类型数据的 同时，还减少了冗余数据的上传，因此可以节约耗费的流量。同时，由于不必在每次接收到 紧急类型数据时，就与服务器连接，大大减少了与服务器连接的次数，从而还达到了节约电 量的效果。
[0097]第二发送模块3,用于每间隔第二预设时长将所述第二预设时长内保存的普通类 型数据上报至所述服务器;其中，所述第一预设时长小于所述第二预设时长。
[0098]由于普通类型数据不需要快速上报至服务器，第一发送模块2每间隔第一预设时 长!^，只将紧急类型数据发送至服务器，而并未将保存的普通类型数据发送至服务器。为了 将普通类型数据上报至服务器，在本实施例中，除了上述的第一预设时长Ti，还预先设置有 第二预设时长T 2,第二发送模块3每间隔第二预设时长T2将第二预设时长内保存的普通类型 数据上报至服务器。其中，该第二预设时长Τ 2大于第一预设时长h，第二预设时长1~2的具体 数值可根据实际情况进行灵活设置，在此不作限制，例如，设置第二预设时长T 2的具体数值 为24小时，第二发送模块3每间隔24小时将当前24小时内保存的普通类型数据上报至服务 器。
[0099]服务器在接收到第一发送模块2上报的紧急类型数据或者第二发送模块3上报的 普通类型数据时，保存接收到的紧急类型数据或者普通类型数据，并确定紧急类型数据或 者普通类型数据对应的应用，然后对保存的该应用对应的所有紧急类型数据或者普通类型 数据进行分析，获知该应用运行的详细信息，从而根据获得的详细信息进一步进行该应用 下一版本开发等相关操作。
[0100] 本实施例提出的方案，在每次接收到软件开发工具包发送的数据时，不管该数据 是紧急类型数据还是普通类型数据，存储模块1先保存该数据，然后针对保存的紧急类型数 据，第一发送模块2以较短时间的第一预设时长的频率，将其上报至服务器，而针对保存的 普通类型数据，第二发送模块3以较长时间的第二预设时长的频率，将其上报至服务器，也 即将紧急类型数据快速上报至服务器、普通类型数据集中上报至服务器，从而不仅实现了 紧急类型数据能及时地上报至服务器，还减少了移动终端连接服务器的次数，降低了功耗。
[0101] 如图5所示，提出本发明数据上报装置第二实施例。数据上报装置第二实施例与数 据上报装置第一实施例的区别在于，在数据上报装置第二实施例中，所述数据上报装置还 包括：
[0102] 获取模块4,用于每间隔第一预设时长，获取所述第一预设时长内保存的封装有紧 急标识信息的数据，其中，所述软件开发工具包在根据预设的数据格式封装数据时，在紧急 类型数据中封装紧急标识信息；
[0103] 确定模块5,用于将封装有所述紧急标识信息的数据作为紧急类型数据。本实施例 中，为了降低数据的耦合性，存储模块1将软件开发工具包发送的紧急类型数据和普通类型 数据保存在一起。因此，为了能够从保存的数据中区分出紧急类型数据和普通类型数据，从 而将紧急类型数据和普通类型数据分别上报至服务器，本实施例中，预先定义软件开发工 具包封装数据的数据格式，当软件开发工具包采集到新的数据时，不需要升级数据库，通过 紧急标识信息来区分紧急类型数据和普通类型数据。软件开发工具包在根据预定义的数据 格式封装数据时，将紧急类型数据中封装紧急标识信息，而普通类型数据中不封装紧急标 识信息。例如，定义紧急类型数据的数据格式如表1所示：
[0104] 表1
[0106] 本领域技术人员可以理解的是，数据格式不一定是上述列举的格式，可以是任何 类型，只要能够区分数据类型、以及数据的参数和取值即可，例如json格式也能满足需求， 或者如下的通用的数据格式：
[0107] (parami = valuei) (param2=value2)......(paramn-i = valuen-1) (paramn = valuen)；
[0108] 其中，param代表某类型数据的参数，如点击事件的id、时长、次数等，value代表参 数param的取值，如下载事件、30秒、4次点击等。
[0109] 并且，本实施例中，软件开发工具包提供加急接口，将紧急类型数据发送至数据上 报应用。为了避免接口碎片化，而且由于事件加急接口已经能够满足业务需求，因此，本实 施例中，只提供事件的加急接口，不提供页面、session、Crash等加急接口，从而避免数据上 报应用丧失控制权。
[0110] 在每间隔第一预设时长1\，获取模块4首先解析在当前第一预设时长1^内保存的每 个数据是否封装有紧急标识信息，获取第一预设时长Ti内保存封装有紧急标识信息的数 据，确定模块5将获取模块4获取到的封装有紧急标识信息的数据作为紧急类型数据，而对 于未封装有紧急标识信息数据，确定模块5确定为普通类型数据。然后第一发送模块2将确 定模块5确定的当前第一预设时长1^内保存的紧急类型数据全部上报至服务器。
[0111] 可选地，本实施例中，所述数据上报装置还包括：
[0112] 删除模块，用于在将所述第一预设时长内保存的紧急类型数据上报至服务器后， 删除所述第一预设时长内保存的紧急类型数据;并在将所述第二预设时长内保存的普通类 型数据上报至所述服务器后，删除所述第二预设时长内保存的普通类型数据。
[0113] 当第一发送模块2将当前第一预设时长Ti内保存的紧急类型数据全部上报至服务 器后，删除模块删除当前第一预设时长!^内保存的紧急类型数据，也即从保存的数据中删 除当前上报至服务器的紧急类型数据。之后，在下一个第一预设时长!^内，当接收到软件开 发工具包发送的紧急类型数据时，存储模块1将其进行保存，从而确保保存的紧急类型数据 均是在一个第一预设时长Ti内接收到的紧急类型数据，从而增加了数据上报应用的可用存 储空间。
[0114] 同样地，当第二发送模块3将当前第二预设时长T2ft保存的普通类型数据全部上 报至服务器后，删除模块删除当前第二预设时长T2ft保存的普通类型数据，也即从保存的 数据中删除当前上报至服务器的普通类型数据。之后，在下一个第二预设时长T2内，当接收 到软件开发工具包发送的普通类型数据时，存储模块1将其进行保存，从而确保保存的普通 类型数据均是在一个第二预设时长Τ 2内接收到的普通类型数据，从而进一步增加了数据上 报应用的可用存储空间，确保数据上报应用的存储空间充足。
[0115]本实施例提出的方案，当第一发送模块2将当前第一预设时长1^内保存的紧急类 型数据全部上报至服务器后，删除模块删除当前第一预设时长h内保存的紧急类型数据， 并且，当第二发送模块3将当前第二预设时长T 2内保存的普通类型数据全部上报至服务器 后，删除模块删除当前第二预设时长T2ft保存的普通类型数据，从而保证在任何时刻保存 的所有紧急类型数据只是当前第一预设时长!^内接收到的紧急类型数据，之前保存的紧急 类型数据均删除了，保存的所有普通类型数据只是当前第二预设时*Τ 2内接收到的普通类 型数据，之前保存的普通类型数据均删除了，从而增加了数据上报应用的可用存储空间。 [0116]如图6所示，提出本发明数据上报装置第三实施例。数据上报装置第三实施例与数 据上报装置第二实施例的区别在于，在数据上报装置第三实施例中，所述数据上报装置还 包括：
[0117] 第一判断模块6,用于判断当前接收到的所述数据是否为紧急类型数据；
[0118] 第二判断模块7,用于在当前接收到的所述数据为紧急类型数据时，确定是否已开 始计时；
[0119] 计时模块8,用于在未开始计时时，开始计时；
[0120] 所述第一发送模块2，用于在计时达到所述第一预设时长时，将所述第一预设时长 内保存的紧急类型数据上报至所述服务器。
[0121]本实施例中，存储模块1在接收到软件开发工具包发送的数据并将其进行保存后， 第一判断模块6判断当前接收到的数据是否为紧急类型数据。当第一判断模块6判断当前接 收到的数据不为紧急类型数据时，不进行响应处理。在继续接收到软件开发工具包发送的 数据时，存储模块1将其进行保存，第一判断模块6判断判断当前接收到的数据是否为紧急 类型数据。直至当第一判断模块6判断当前接收到的数据为紧急类型数据时，此时，第二判 断模块7判断是否已经开始计时。若第二判断模块7判断此时还未开始计时，计时模块8开始 计时。在计时还未达到第一预设时长!^的过程中，在每次接收到软件开发工具包发送的数 据时，不论接收到的数据是紧急类型数据，还是普通类型数据，存储模块1均将其进行保存。 之后，当计时达到第一预设时长^时，第一发送模块2从该第一预设时长1^内保存的数据中 查询出紧急类型数据，将查询出的紧急类型数据上报至服务器。同时，计时模块8将计时更 新为初始时间，可选地，将计时清零。并且，删除模块删除该第一预设时长Ti内保存的紧急 类型数据，也即删除当前上报至服务器的紧急类型数据。
[0122]在本实施例中，当计时更新为初始时间时，存储模块1保存的数据中不存在紧急类 型数据了。之后，当存储模块1再保存接收到的软件开发工具包发送的数据时，第一判断模 块6判断接收并保存的该数据是否为紧急类型数据，当该数据为普通类型数据时，计时模块 8不进行计时。存储模块1继续接收并保存软件开发工具包发送的数据，直至第一判断模块6 判断当前接收并保存的数据为紧急类型数据时，此时，若第二判断模块7判断还未开始计 时，则计时模块8重新开始计时。当计时达到第一预设时长^时，第一发送模块2继续执行上 述的将第一预设时长!^内保存的紧急类型数据上报至服务器的操作，在此就不再赘述。
[0123] 本实施例提出的方案，由于每次第一发送模块2将保存的紧急类型数据上报至服 务器后，删除模块均将保存的紧急类型数据删除，当之后存储模块1再保存接收到的软件开 发工具包发送的数据时，若该数据为普通类型数据，则计时模块8不进行计时，直至当某次 接收并保存的数据为紧急类型数据时，计时模块8才开始计时，在计时达到第一预设时长 时，第一发送模块2再次执行将此时间段内保存的紧急类型数据上报至服务器的操作。因 此，本实施例中不需要刻板地按照第一预设时长的频率上报紧急类型数据至服务器，增加 了紧急类型数据上报的灵活性。
[0124] 如图7所示，提出本发明数据上报装置第四实施例。数据上报装置第四实施例与上 述任一实施例的区别在于，所述数据上报装置包括：
[0125] 采集模块9,用于采集软件开发工具包对应的应用在运行中的数据，其中，所述数 据包括紧急类型数据和普通类型数据；
[0126] 第三发送模块10,用于在采集的所述数据为紧急类型数据时，调用预设的加急接 口将所述紧急类型数据发送至数据上报应用，以供所述数据上报应用保存所述紧急类型数 据，并每间隔第一预设时长将所述第一预设时长内保存的紧急类型数据上报至服务器；
[0127] 第四发送模块11，用于在采集的所述数据为普通类型数据时，调用预设的普通接 口将所述普通类型数据发送至所述数据上报应用，以供所述数据上报应用保存所述普通类 型数据，并每间隔第二预设时长将所述第二预设时长内保存的普通类型数据上报至所述服 务器；
[0128] 其中，所述第一预设时长小于所述第二预设时长。
[0129] 在本实施例中，移动终端内加载的各个应用中集成有数据统计软件开发工具包 (Software Development Kit，软件开发工具包），软件开发工具包被集成到各个应用中，用 于统计各个应用的启动信息、页面信息、事件点击信息、CRASH信息等。数据上报装置设置于 各软件开发工具包中。并且，移动终端中还加载有一数据上报应用。当移动终端要将各个应 用运行中对应的数据上报至服务器时，如图4所示，各个应用对应的软件开发工具包、数据 上报应用以及服务器组成数据上报系统。在各个应用运行中时，采集模块9采集应用在运行 中对应的数据，该数据包括紧急类型数据和普通类型数据。
[0130] 对于数据为紧急类型数据还是普通类型数据的判断，软件开发工具包可通过各 种灵活方式进行判断。例如，对于各种不同应用，可预先根据用户要求，将某些应用设置为 数据加急上报的应用，而将另外的应用设置为数据不需要加急上报的应用。则当采集模块9 采集的是数据加急上报的应用运行的数据时，判断采集的该数据为紧急类型数据；当采集 模块9采集的是数据不需要加急上报的应用运行的数据时，判断采集的该数据为普通类型 数据。或者，对于某一应用，由于应用运行中包括了各种数据，可预先设置其中的某些类型 的数据为紧急类型数据，其他类型的数据为普通类型数据。例如，将点击事件对应的数据设 置为紧急类型数据，则当采集模块9采集到点击事件对应的数据时，判断采集到的该数据为 紧急类型数据。
[0131] 对于紧急类型数据和普通类型数据，第三发送模块10和第四发送模块11分别采用 不同的方式发送至数据上报应用。具体地，本实施例中，预先设置有软件开发工具包对应的 加急接口和普通接口，加急接口用于软件开发工具包将采集到的紧急类型数据发送至数据 上报应用，普通接口用于将普通类型数据发送至数据上报应用。当采集模块9在每次采集到 紧急类型数据时，第三发送模块10调用预设的加急接口将采集到的紧急类型数据发送至数 据上报应用。数据上报应用在接收到紧急类型数据后，将紧急类型数据保存于一存储区。当 采集模块9在每次采集到普通类型数据时，第四发送模块11调用预设的普通接口将采集到 的普通类型数据发送至数据上报应用。数据上报应用在接收到普通类型数据后，将普通类 型数据保存于另一存储区。
[0132] 为了避免接口碎片化，而且由于事件加急接口已经能够满足业务需求，因此，本实 施例中，只提供事件的加急接口，不提供页面、session、Crash等加急接口，从而避免数据上 报应用丧失控制权。
[0133] 本实施例中，所述第三发送模块10包括：
[0134] 封装单元，用于在采集的所述数据为紧急类型数据时，在所述紧急类型数据中封 装紧急标识信息；
[0135] 发送单元，用于调用预设的加急接口将封装有所述紧急标识信息的所述紧急类型 数据发送至数据上报应用。
[0136] 为了降低数据的耦合性，使数据上报应用能将紧急类型数据和普通类型数据保存 在一起，也即数据上报应用能从保存在一起的所有数据中区分出紧急类型数据和普通类型 数据。本实施例中，采集模块9在采集到紧急类型数据时，封装单元在根据预定义的数据格 式封装数据时，将紧急类型数据中封装紧急标识信息，而普通类型数据中不封装紧急标识 信息。例如，定义紧急类型数据的数据格式如表1所示。
[0137] 本领域技术人员可以理解的是，数据格式不一定是上述列举的格式，可以是任何 类型，只要能够区分数据类型、以及数据的参数和取值即可，例如json格式也能满足需求， 或者如下的通用的数据格式：
[0138] (parami = valuei) (param2 = value2)......(paramn-i = valuen-i) (paramn = valuen)；
[0139] 其中，param代表某类型数据的参数，如点击事件的id、时长、次数等，value代表参 数param的取值，如下载事件、30秒、4次点击等。
[0140]之后，发送单元调用预设的加急接口将封装有所述紧急标识信息的所述紧急类型 数据发送至数据上报应用。
[0141] 数据上报应用每间隔第一预设时长h，将第一预设时长1^内保存的紧急类型数据 上报至服务器。每间隔第二预设时长^将第二预设时长内保存的普通类型数据上报至服务 器。其中，该第二预设时长T 2大于第一预设时长1\。
[0142] 服务器在接收到数据上报应用上报的紧急类型数据或者普通类型数据时，保存接 收到的紧急类型数据或者普通类型数据，并确定紧急类型数据或者普通类型数据对应的应 用，然后对保存的该应用对应的所有紧急类型数据或者普通类型数据进行分析，获知该应 用运行的详细信息，从而根据获得的详细信息进一步进行该应用下一版本开发等相关操 作。
[0143] 本实施例提出的方案，采集模块9在每次采集到对应应用运行的数据时，若该数据 为紧急类型数据，则第三发送模块10调用预设的加急接口将紧急类型数据发送至数据上报 应用，数据上报应用保存紧急类型数据，若该数据为普通类型数据，则第四发送模块11调用 预设的普通接口将普通类型数据发送至数据上报应用，数据上报应用保存普通类型数据， 然后针对保存的紧急类型数据，以较短时间的第一预设时长的频率，将其上报至服务器，而 针对保存的普通类型数据，以较长时间的第二预设时长的频率，将其上报至服务器，也即将 紧急类型数据快速上报至服务器、普通类型数据集中上报至服务器，从而不仅实现了紧急 类型数据能及时地上报至服务器，还减少了移动终端连接服务器的次数，降低了功耗。
[0144] 本发明实施例还提供一种数据上报方法。
[0145] 参照图8,图8为本发明数据上报方法第一实施例的流程示意图，在第一实施例中， 该数据上报方法包括以下步骤：
[0146] 步骤S10,在每次接收到软件开发工具包发送的数据时，保存所述数据，其中，所述 数据为所述软件开发工具包对应的应用在运行中时，所述软件开发工具包采集的数据，所 述数据包括紧急类型数据和普通类型数据；
[0147] 本实施例中，移动终端内加载的各个应用中集成有数据统计软件开发工具包 (Software Development Kit，软件开发工具包），软件开发工具包被集成到各个应用中，用 于统计各个应用的启动信息、页面信息、事件点击信息、CRASH信息等。并且，移动终端中还 加载有一数据上报应用。可选地，该数据上报应用安装于移动终端ROM中。当移动终端要将 各个应用运行中对应的数据上报至服务器时，如图4所示，各个应用对应的软件开发工具 包、数据上报应用以及服务器组成数据上报系统。在各个应用运行中时，其对应的软件开发 工具包采集应用在运行中对应的数据，并将采集到的数据发送至数据上报应用。可选地，软 件开发工具包在采集到数据时，根据对应事件是否为加急事件，将数据确定为紧急类型数 据或普通类型数据。比如，当事件为加急事件时，软件开发工具包将事件的数据确定为紧急 类型数据；否则，软件开发工具包将事件的数据确定为普通类型数据。然后，软件开发工具 包将确定的紧急类型数据或者普通类型数据发送至数据上报应用。
[0148] 当数据上报应用接收到软件开发工具包发送的数据时，将接收到的数据进行保 存。其中，接收到的数据可能为紧急类型数据，也可能为普通类型数据，也即数据上报应用 中保存的数据包括紧急类型数据和普通类型数据。
[0149] 步骤S20,每间隔第一预设时长将所述第一预设时长内保存的紧急类型数据上报 至服务器；
[0150] 本实施例中，预先设置有第一预设时长Ti，该第一预设时长Ti的具体数值可根据事 件的加急情况进行灵活设置，在此不作限制。例如，当某一款应用对应的开发商需要在某个 节日做活动，开发商希望能够尽快掌握活动的效果，根据用户使用情况动态调整活动策略， 也即开发商希望能尽快获取各用户运行该应用对应的数据时，可将该第一预设时长!^设置 为10分钟。数据上报应用每间隔第一预设时长!\，就从第一预设时长h内保存的数据中查询 出紧急类型数据，也即每间隔10分钟就从当前10分钟内保存的数据中查询出紧急类型数 据，并将查询到的紧急类型数据上报至服务器，从而实现了在短时间内及时地上报紧急类 型数据。
[0151] 并且，由于在与服务器的每次通讯中，在每次上报数据至服务器的同时，还必须携 带公用的移动终端信息，包括移动终端的MEI号、MAC地址、移动终端生产厂商、操作系统、 操作系统版本、移动终端型号等。因此，现有技术中采用的在软件开发工具包每次接收到数 据时，就将其上报至服务器的方式，上报了很多的冗余数据。而本实施例中，由于是每间隔 第一预设时长上报一次紧急类型数据，在实现及时地上报紧急类型数据的同时，还减少了 冗余数据的上传，因此可以节约耗费的流量。同时，由于不必在每次接收到紧急类型数据 时，就与服务器连接，大大减少了与服务器连接的次数，从而还达到了节约电量的效果。
[0152] 步骤S30,每间隔第二预设时长将所述第二预设时长内保存的普通类型数据上报 至所述服务器;其中，所述第一预设时长小于所述第二预设时长。
[0153] 由于普通类型数据不需要快速上报至服务器，数据上报应用每间隔第一预设时长 Ti，只将紧急类型数据发送至服务器，而并未将保存的普通类型数据发送至服务器。为了将 普通类型数据上报至服务器，在本实施例中，除了上述的第一预设时长Ti，还预先设置有第 二预设时长T 2,数据上报应用每间隔第二预设时长^将第二预设时长内保存的普通类型数 据上报至服务器。其中，该第二预设时长Τ 2大于第一预设时长h，第二预设时长1~2的具体数 值可根据实际情况进行灵活设置，在此不作限制，例如，设置第二预设时长T 2的具体数值为 24小时，数据上报应用每间隔24小时将当前24小时内保存的普通类型数据上报至服务器。 [0154]服务器在接收到数据上报应用上报的紧急类型数据或者普通类型数据时，保存接 收到的紧急类型数据或者普通类型数据，并确定紧急类型数据或者普通类型数据对应的应 用，然后对保存的该应用对应的所有紧急类型数据或者普通类型数据进行分析，获知该应 用运行的详细信息，从而根据获得的详细信息进一步进行该应用下一版本开发等相关操 作。
[0155]本实施例提出的方案，在每次接收到软件开发工具包发送的数据时，不管该数据 是紧急类型数据还是普通类型数据，数据上报应用先保存该数据，然后针对保存的紧急类 型数据，以较短时间的第一预设时长的频率，将其上报至服务器，而针对保存的普通类型数 据，以较长时间的第二预设时长的频率，将其上报至服务器，也即将紧急类型数据快速上报 至服务器、普通类型数据集中上报至服务器，从而不仅实现了紧急类型数据能及时地上报 至服务器，还减少了移动终端连接服务器的次数，降低了功耗。
[0156]如图9所示，提出本发明数据上报方法第二实施例。数据上报方法第二实施例与数 据上报方法第一实施例的区别在于，在数据上报方法第二实施例中，所述步骤S20之前，还 包括：
[0157] 步骤S40,每间隔第一预设时长，获取所述第一预设时长内保存的封装有紧急标识 信息的数据，其中，所述软件开发工具包在根据预设的数据格式封装数据时，在紧急类型数 据中封装紧急标识信息；
[0158] 步骤S50,将封装有所述紧急标识信息的数据作为紧急类型数据。
[0159] 本实施例中，为了降低数据的耦合性，数据上报应用将软件开发工具包发送的紧 急类型数据和普通类型数据保存在一起。因此，为了数据上报应用能够从保存的数据中区 分出紧急类型数据和普通类型数据，从而分别上报至服务器，本实施例中，预先定义软件开 发工具包封装数据的数据格式，当软件开发工具包采集到新的数据时，不需要升级数据库， 通过紧急标识信息来区分紧急类型数据和普通类型数据。软件开发工具包在根据预定义的 数据格式封装数据时，将紧急类型数据中封装紧急标识信息，而普通类型数据中不封装紧 急标识信息。例如，定义紧急类型数据的数据格式如表1所示。
[0160] 本领域技术人员可以理解的是，数据格式不一定是上述列举的格式，可以是任何 类型，只要能够区分数据类型、以及数据的参数和取值即可，例如json格式也能满足需求， 或者如下的通用的数据格式：
[0161 ] (parami = valuei) (param2=value2)......(paramn-1 = valuen-1) (paramn = valuen)；
[0?62]其中，param代表某类型数据的参数，如点击事件的id、时长、次数等，value代表参 数param的取值，如下载事件、30秒、4次点击等。
[0163] 并且，本实施例中，软件开发工具包提供加急接口，将紧急类型数据发送至数据上 报应用。为了避免接口碎片化，而且由于事件加急接口已经能够满足业务需求，因此，本实 施例中，只提供事件的加急接口，不提供页面、session、Crash等加急接口，从而避免数据 上报应用丧失控制权。
[0164] 在每间隔第一预设时长!^，数据上报应用解析在当前第一预设时长Ti内保存的每 个数据是否封装有紧急标识信息，获取第一预设时长Ti内保存封装有紧急标识信息的数 据，将获取到的封装有紧急标识信息的数据作为紧急类型数据，而对于未封装有紧急标识 信息数据，确定为普通类型数据。然后将确定的当前第一预设时长Ti内保存的紧急类型数 据全部上报至服务器。
[0165] 本实施例中，所述步骤S20之后，还包括：
[0166] 步骤a，删除所述第一预设时长内保存的紧急类型数据；
[0167] 所述步骤S30之后，还包括：
[0168] 步骤b，删除所述第二预设时长内保存的普通类型数据。
[0169] 当数据上报应用将当前第一预设时长1^内保存的紧急类型数据全部上报至服务 器后，数据上报应用删除当前第一预设时长!^内保存的紧急类型数据，也即从保存的数据 中删除当前上报至服务器的紧急类型数据。之后，在下一个第一预设时长!^内，当接收到软 件开发工具包发送的紧急类型数据时，将其进行保存，也即确保数据上报应用保存的紧急 类型数据均是在一个第一预设时长Ti内接收到的紧急类型数据，从而增加了数据上报应用 的可用存储空间。
[0170] 同理，当数据上报应用将当前第二预设时长T2内保存的普通类型数据全部上报至 服务器后，数据上报应用删除当前第二预设时长T 2ft保存的普通类型数据，也即从保存的 数据中删除当前上报至服务器的普通类型数据。之后，在下一个第二预设时长T 2内，当接收 到软件开发工具包发送的普通类型数据时，将其进行保存，也即确保数据上报应用保存的 普通类型数据均是在一个第二预设时长Τ 2内接收到的普通类型数据，从而进一步增加了数 据上报应用的可用存储空间，确保数据上报应用的存储空间充足。
[0171]本实施例提出的方案，当数据上报应用将当前第一预设时长Ti内保存的紧急类型 数据全部上报至服务器后，数据上报应用删除当前第一预设时长Ti内保存的紧急类型数 据，并且，当数据上报应用将当前第二预设时长T 2内保存的普通类型数据全部上报至服务 器后，数据上报应用删除当前第二预设时长T2ft保存的普通类型数据，从而保证在任何时 刻数据上报应用保存的所有紧急类型数据只是当前第一预设时长!^内接收到的紧急类型 数据，之前保存的紧急类型数据均删除了，保存的所有普通类型数据只是当前第二预设时 长!^内接收到的普通类型数据，之前保存的普通类型数据均删除了，从而增加了数据上报 应用的可用存储空间。
[0172]如图10所示，提出本发明数据上报方法第三实施例。数据上报方法第三实施例与 数据上报方法第二实施例的区别在于，在数据上报方法第三实施例中，所述步骤S10之后， 还包括：
[0173] 步骤S60,判断当前接收到的所述数据是否为紧急类型数据；
[0174] 步骤S70,在当前接收到的所述数据为紧急类型数据时，确定是否已开始计时；
[0175] 步骤S80，若未开始计时，则开始计时
[0176] 步骤S90,在计时达到所述第一预设时长时，将所述第一预设时长内保存的紧急类 型数据上报至所述服务器。
[0177] 本实施例中，数据上报应用在接收到软件开发工具包发送的数据并将其进行保存 后，数据上报应用判断当前接收到的数据是否为紧急类型数据。当判断当前接收到的数据 不为紧急类型数据时，数据上报应用不执行其他的操作，只继续在接收到软件开发工具包 发送的数据时，将其进行保存，并判断当前接收到的数据是否为紧急类型数据。直至当数据 上报应用判断当前接收到的数据为紧急类型数据时，此时，数据上报应用判断是否已经开 始计时，若此时还未开始计时，则数据上报应用开始计时;若此时已经计时了，则继续计时。 在计时还未达到第一预设时长!^的过程中，数据上报应用在每次接收到软件开发工具包发 送的数据时，不论接收到的数据是紧急类型数据，还是普通类型数据，数据上报应用均将其 进行保存。之后，当计时达到第一预设时长^时，数据上报应用从该第一预设时长h内保存 的数据中查询出紧急类型数据，将查询出的紧急类型数据上报至服务器。同时，数据上报应 用将计时更新为初始时间，可选地，将计时清零。并且，数据上报应用删除该第一预设时长 TiR保存的紧急类型数据，也即删除当前上报至服务器的紧急类型数据。
[0178] 在本实施例中，当计时更新为初始时间时，数据上报应用保存的数据中不存在紧 急类型数据了。之后，当数据上报应用再接收到软件开发工具包发送的数据并保存该数据 时，数据上报应用判断接收并保存的该数据是否为紧急类型数据，当该数据为普通类型数 据时，不进行计时。数据上报应用继续接收并保存软件开发工具包发送的数据，直至判断当 前接收并保存的数据为紧急类型数据时，此时，数据上报应用判断还未开始计时，执行开始 计时的操作。当计时达到第一预设时长^时，数据上报应用继续执行上述的将第一预设时 长1^内保存的紧急类型数据上报至服务器的操作，在此就不再赘述。
[0179]本实施例提出的方案，由于数据上报应用每次将保存的紧急类型数据上报至服务 器后，均将保存的紧急类型数据删除，当之后再接收并保存软件开发工具包发送的数据时， 若该数据为普通类型数据，则不进行计时，直至当某次接收并保存的数据为紧急类型数据 时，才开始计时，在计时达到第一预设时长时，数据上报应用再次执行将此时间段内保存的 紧急类型数据上报至服务器的操作。因此，本实施例中不需要刻板地按照第一预设时长的 频率上报紧急类型数据至服务器，增加了紧急类型数据上报的灵活性。
[0180] 如图11所示，提出本发明数据上报方法第四实施例。数据上报方法第四实施例与 上述任一实施例的区别在于，所述数据上报方法包括以下步骤：
[0181] 步骤S100,软件开发工具包采集所述软件开发工具包对应的应用在运行中的数 据，其中，所述数据包括紧急类型数据和普通类型数据；
[0182] 步骤S110，在采集的所述数据为紧急类型数据时，调用预设的加急接口将所述紧 急类型数据发送至数据上报应用，以供所述数据上报应用保存所述紧急类型数据，并每间 隔第一预设时长将所述第一预设时长内保存的紧急类型数据上报至服务器；
[0183] 步骤S120,在采集的所述数据为普通类型数据时，调用预设的普通接口将所述普 通类型数据发送至所述数据上报应用，以供所述数据上报应用保存所述普通类型数据，并 每间隔第二预设时长将所述第二预设时长内保存的普通类型数据上报至所述服务器；
[0184] 其中，所述第一预设时长小于所述第二预设时长。
[0185] 在本实施例中，移动终端内加载的各个应用中集成有数据统计软件开发工具包 (Software Development Kit，软件开发工具包），软件开发工具包被集成到各个应用中，用 于统计各个应用的启动信息、页面信息、事件点击信息、CRASH信息等。并且，移动终端中还 加载有一数据上报应用，以下简称数据上报应用。当移动终端要将各个应用运行中对应的 数据上报至服务器时，如图4所示，各个应用对应的软件开发工具包、数据上报应用以及服 务器组成数据上报系统。在各个应用运行中时，其对应的软件开发工具包采集应用在运行 中对应的数据，该数据包括紧急类型数据和普通类型数据。
[0186] 对于数据为紧急类型数据还是普通类型数据的判断，软件开发工具包可通过各种 灵活方式进行判断。例如，对于各种不同应用，可预先根据用户要求，将某些应用设置为数 据加急上报的应用，而将另外的应用设置为数据不需要加急上报的应用。则当软件开发工 具包采集的是数据加急上报的应用运行的数据时，判断采集的该数据为紧急类型数据；当 软件开发工具包采集的是数据不需要加急上报的应用运行的数据时，判断采集的该数据为 普通类型数据。或者，对于某一应用，由于应用运行中包括了各种数据，可预先设置其中的 某些类型的数据为紧急类型数据，其他类型的数据为普通类型数据。例如，将点击事件对应 的数据设置为紧急类型数据，则当软件开发工具包采集到点击事件对应的数据时，判断采 集到的该数据为紧急类型数据。
[0187] 软件开发工具包对于紧急类型数据和普通类型数据，分别采用不同的方式发送至 数据上报应用。具体地，本实施例中，预先设置有软件开发工具包对应的加急接口和普通接 口，加急接口用于软件开发工具包将采集到的紧急类型数据发送至数据上报应用，普通接 口用于将普通类型数据发送至数据上报应用。当软件开发工具包在每次采集到紧急类型数 据时，调用预设的加急接口将采集到的紧急类型数据发送至数据上报应用。数据上报应用 在接收到紧急类型数据后，将紧急类型数据保存于一存储区。当软件开发工具包在每次采 集到普通类型数据时，调用预设的普通接口将采集到的普通类型数据发送至数据上报应 用。数据上报应用在接收到普通类型数据后，将普通类型数据保存于另一存储区。
[0188] 为了避免接口碎片化，而且由于事件加急接口已经能够满足业务需求，因此，本实 施例中，只提供事件的加急接口，不提供页面、session、Crash等加急接口，从而避免数据上 报应用丧失控制权。
[0189] 进一步地，本实施例中，所述步骤S110包括：
[0190] 步骤c，在每次采集的所述数据为紧急类型数据时，将所述紧急类型数据中封装 紧急标识信息；
[0191]步骤d，调用预设的加急接口将封装有所述紧急标识信息的所述紧急类型数据发 送至数据上报应用。
[0192]进一步地，为了降低数据的耦合性，使数据上报应用能将紧急类型数据和普通类 型数据保存在一起，也即数据上报应用能从保存在一起的所有数据中区分出紧急类型数据 和普通类型数据。本实施例中，软件开发工具包在采集到紧急类型数据时，软件开发工具包 在根据预定义的数据格式封装数据时，将紧急类型数据中封装紧急标识信息，而普通类型 数据中不封装紧急标识信息。例如，定义紧急类型数据的数据格式如表1所示。
[0193] 本领域技术人员可以理解的是，数据格式不一定是上述列举的格式，可以是任何 类型，只要能够区分数据类型、以及数据的参数和取值即可，例如json格式也能满足需求， 或者如下的通用的数据格式：
[0194] (parami = valuei) (param2 = value2)......(paramn-i = valuen-i) (paramn = valuen)；
[0195]其中，param代表某类型数据的参数，如点击事件的id、时长、次数等，value代表参 数param的取值，如下载事件、30秒、4次点击等。
[0196] 数据上报应用每间隔第一预设时长h，将第一预设时长1^内保存的紧急类型数据 上报至服务器。每间隔第二预设时长^将第二预设时长内保存的普通类型数据上报至服务 器。其中，该第二预设时长T 2大于第一预设时长1\。
[0197] 服务器在接收到数据上报应用上报的紧急类型数据或者普通类型数据时，保存接 收到的紧急类型数据或者普通类型数据，并确定紧急类型数据或者普通类型数据对应的应 用，然后对保存的该应用对应的所有紧急类型数据或者普通类型数据进行分析，获知该应 用运行的详细信息，从而根据获得的详细信息进一步进行该应用下一版本开发等相关操 作。
[0198] 本实施例提出的方案，软件开发工具包在每次采集到对应应用运行的数据时，若 该数据为紧急类型数据，则调用预设的加急接口将紧急类型数据发送至数据上报应用，数 据上报应用保存紧急类型数据，若该数据为普通类型数据，则调用预设的普通接口将普通 类型数据发送至数据上报应用，数据上报应用保存普通类型数据，然后针对保存的紧急类 型数据，以较短时间的第一预设时长的频率，将其上报至服务器，而针对保存的普通类型数 据，以较长时间的第二预设时长的频率，将其上报至服务器，也即将紧急类型数据快速上 报至服务器、普通类型数据集中上报至服务器，从而不仅实现了紧急类型数据能及时地上 报至服务器，还减少了移动终端连接服务器的次数，降低了功耗。
[0199] 需要说明的是，在本文中，术语"包括"、"包含"或者其任何其他变体意在涵盖非排 他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而 且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有 的要素。在没有更多限制的情况下，由语句"包括一个……"限定的要素，并不排除在包括该 要素的过程、方法、物品或者装置中还存在另外的相同要素。
[0200] 上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。
[0201] 通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方 法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下 前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做 出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质 (如R0M/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，月艮 务器，空调器，或者网络设备等)执行本发明各个实施例所述的方法。
[0202] 以上仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发 明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技 术领域，均同理包括在本发明的专利保护范围内。
【主权项】
1. 一种数据上报装置，其特征在于，所述数据上报装置包括： 存储模块，用于在每次接收到软件开发工具包发送的数据时，保存所述数据，其中，所 述数据为所述软件开发工具包对应的应用在运行中时，所述软件开发工具包采集的数据， 所述数据包括紧急类型数据和普通类型数据； 第一发送模块，用于每间隔第一预设时长将所述第一预设时长内保存的紧急类型数据 上报至服务器； 第二发送模块，用于每间隔第二预设时长将所述第二预设时长内保存的普通类型数据 上报至所述服务器;其中，所述第一预设时长小于所述第二预设时长。2. 如权利要求1所述的数据上报装置，其特征在于，所述数据上报装置还包括： 获取模块，用于每间隔第一预设时长，获取所述第一预设时长内保存的封装有紧急标 识信息的数据，其中，所述软件开发工具包在根据预设的数据格式封装数据时，在紧急类型 数据中封装紧急标识信息； 确定模块，用于将封装有所述紧急标识信息的数据作为紧急类型数据。3. 如权利要求1或2所述的数据上报装置，其特征在于，所述数据上报装置还包括： 第一判断模块，用于判断当前接收到的所述数据是否为紧急类型数据； 第二判断模块，用于在当前接收到的所述数据为紧急类型数据时，确定是否已开始计 时； 计时模块，用于在未开始计时时，开始计时； 所述第一发送模块，用于在计时达到所述第一预设时长时，将所述第一预设时长内保 存的紧急类型数据上报至所述服务器。4. 一种数据上报装置，其特征在于，所述数据上报装置包括： 采集模块，用于采集软件开发工具包对应的应用在运行中的数据，其中，所述数据包括 紧急类型数据和普通类型数据； 第三发送模块，用于在采集的所述数据为紧急类型数据时，调用预设的加急接口将所 述紧急类型数据发送至数据上报应用，以供所述数据上报应用保存所述紧急类型数据，并 每间隔第一预设时长将所述第一预设时长内保存的紧急类型数据上报至服务器； 第四发送模块，用于在采集的所述数据为普通类型数据时，调用预设的普通接口将所 述普通类型数据发送至所述数据上报应用，以供所述数据上报应用保存所述普通类型数 据，并每间隔第二预设时长将所述第二预设时长内保存的普通类型数据上报至所述服务 器； 其中，所述第一预设时长小于所述第二预设时长。5. 如权利要求4所述的数据上报装置，其特征在于，所述第三发送模块包括： 封装单元，用于在采集的所述数据为紧急类型数据时，在所述紧急类型数据中封装紧 急标识信息； 发送单元，用于调用预设的加急接口将封装有所述紧急标识信息的所述紧急类型数据 发送至数据上报应用。6. -种数据上报方法，其特征在于，所述数据上报方法包括步骤： 在每次接收到软件开发工具包发送的数据时，保存所述数据，其中，所述数据为所述软 件开发工具包对应的应用在运行中时，所述软件开发工具包采集的数据，所述数据包括紧 急类型数据和普通类型数据； 每间隔第一预设时长将所述第一预设时长内保存的紧急类型数据上报至服务器； 每间隔第二预设时长将所述第二预设时长内保存的普通类型数据上报至所述服务器； 其中，所述第一预设时长小于所述第二预设时长。7. 如权利要求6所述的数据上报方法，其特征在于，所述每间隔第一预设时长将所述第 一预设时长内保存的紧急类型数据上报至服务器的步骤之前，还包括： 每间隔第一预设时长，获取所述第一预设时长内保存的封装有紧急标识信息的数据， 其中，所述软件开发工具包在根据预设的数据格式封装数据时，在紧急类型数据中封装紧 急标识信息； 将封装有所述紧急标识信息的数据作为紧急类型数据。8. 如权利要求6或7所述的数据上报方法，其特征在于，所述在每次接收到软件开发工 具包发送的数据时，保存所述数据的步骤之后，还包括： 判断当前接收到的所述数据是否为紧急类型数据； 在当前接收到的所述数据为紧急类型数据时，确定是否已开始计时； 若未开始计时，则开始计时； 在计时达到所述第一预设时长时，将所述第一预设时长内保存的紧急类型数据上报至 所述服务器。9. 一种数据上报方法，其特征在于，所述数据上报方法包括步骤： 软件开发工具包采集所述软件开发工具包对应的应用在运行中的数据，其中，所述数 据包括紧急类型数据和普通类型数据； 在采集的所述数据为紧急类型数据时，调用预设的加急接口将所述紧急类型数据发送 至数据上报应用，以供所述数据上报应用保存所述紧急类型数据，并每间隔第一预设时长 将所述第一预设时长内保存的紧急类型数据上报至服务器； 在采集的所述数据为普通类型数据时，调用预设的普通接口将所述普通类型数据发送 至所述数据上报应用，以供所述数据上报应用保存所述普通类型数据，并每间隔第二预设 时长将所述第二预设时长内保存的普通类型数据上报至所述服务器； 其中，所述第一预设时长小于所述第二预设时长。10. 如权利要求9所述的数据上报方法，其特征在于，所述在采集的所述数据为紧急类 型数据时，调用预设的加急接口将所述紧急类型数据发送至数据上报应用的步骤包括： 在采集的所述数据为紧急类型数据时，在所述紧急类型数据中封装紧急标识信息； 调用预设的加急接口将封装有所述紧急标识信息的所述紧急类型数据发送至数据上 报应用。
【文档编号】H04L12/863GK106027415SQ201610355246
【公开日】2016年10月12日
【申请日】2016年5月25日
【发明人】黄小峰
【申请人】努比亚技术有限公司