在现有技术中， 当多个应用 （如 QQ、 twitter和 emai l等） 同时运行在后台， 并根 据各自的定时器的时间与网络进行交互时， 当各自的定时时间到时后， 会分别激活 PDP

(Packet Data Protocol , 分组数据协议）， 建立数据链接， 并在分别激活 PDP的过程 中使终端产生固有功耗。 例如， QQ会每隔 30分钟， 向服务器发起请求， 要获取当前在 线好友的最新状态； 而 emai l会每隔 35分钟主动发起数据链接， 从服务器上下载邮件; 而 twitter在后台运行时以 45分钟为间隔， 发起数据链接从服务器获取数据。 综上， 集成或装载这些应用的终端会在 15分钟内 3次激活 PDP建立各自的数据链接， 并使终 端分别产生 3次固有功耗。

因此， 在采用现有技术进行处于后台应用模式下的各 个应用与网络进行数据交互 时， 由于各个应用独立发送激活 PDP建立对应的数据链接与网络进行数据交互， 从而引 起在不断独立发送激活 PDP请求中使终端重复产生大量的功耗， 增加了终端的耗电量， 使终端的待机时间降低的问题。 发明内容 有鉴于此， 本发明提供了一种数据交互的方法及装置， 以克服现有技术中由于处于 后台应用模式下的应用不断独立激活 PDP , 使终端重复不断产生大量功耗， 增加终端的 耗电量， 使终端的待机时间降低的问题。

为实现上述目的， 本发明提供如下技术方案：

一种数据交互的方法， 包括：

获取处于后台应用模式下的各个有效应用与网 络进行数据交互的时间间隔； 选取所述时间间隔中的最小时间间隔作为数据 交互的目标定时时间， 启动定时； 当所述目标定时时间到达时， 获取当前时间间隔位于前后两次目标定时时间 之间的 各个所述有效应用， 确定各个所述有效应用为目标应用； 激活分组数据协议 PDP, 建立 所述目标应用与网络之间的数据链接， 并进行数据交互。

一种数据交互的装置， 包括：

获取单元，用于获取处于后台应用模式下的各 个有效应用与网络进行数据交互的时 间间隔；

选取单元，用于选取当前所述时间间隔中的最 小时间间隔作为数据交互的目标定时 时间；

定时单元， 用于启动目标定时时间和重置目标定时时间；

确定单元， 用于当所述目标定时时间到达时， 获取当前时间间隔位于前后两次目标 定时时间之间的各个所述有效应用， 确定各个所述有效应用为目标应用；

交互单元， 用于激活分组数据协议 PDP, 建立所述目标应用与网络之间的数据链接， 并在进行数据交互后返回选取单元。

经由上述的技术方案可知， 与现有技术相比， 本发明公开了一种数据交互的方法及 装置。 通过获取处于后台应用模式下的各个有效应用 与网络进行数据交互的时间间隔， 选取当前时间间隔中的最小时间间隔作为数据 交互的目标定时时间，在目标定时时间到 达时， 确定符合进行数据交互的有效应用， 使其在同一次激活分组数据协议之后， 建立 各自的数据链接与网络进行数据交互，获取相 应的数据；并且在存在有效应用的情况下， 当目标定时时间到达时， 则循环执行有效应用与网络之间的数据交互。 利用本发明公开 的数据交互方法及装置，通过使各个运行于后 台的应用与网络之间的数据交互的频率进 行同步， 并在激活一次 PDP之后， 建立各自的数据链接与网络进行数据交互， 在满足各 个处于后台应用模式下的有效 APP的前提下， 减少激活 PDP的次数， 达到减少功耗， 降低 终端的耗电量， 使终端待机时间增长的目的。 附图说明 为了更清楚地说明本发明实施例或现有技术中 的技术方案， 下面将对实施例或现有 技术描述中所需要使用的附图作简单地介绍， 显而易见地， 下面描述中的附图仅仅是本 发明的实施例， 对于本领域普通技术人员来讲， 在不付出创造性劳动的前提下， 还可以 根据提供的附图获得其他的附图。

图 1为本发明实施例一公开的一种数据交互的方� �流程图；

图 2为实施例一中具体数据交互的过程示意图；

图 3为本发明实施例二公开的一种数据交互的方� �流程图；

图 4为实施例二中具体数据交互的过程示意图；

图 5为实施例二中另一具体数据交互的过程示意� �；

图 6为本发明实施例三公开的一种数据交互的方� �流程图；

图 7为实施例三中具体数据交互的过程示意图；

图 8为实施例三中另一具体数据交互的过程示意� �；

图 9为本发明公开的一种数据交互的装置结构示� �图；

图 10为本发明公开的另一种数据交互的装置结构� ��意图；

图 11为本发明公开的另一种数据交互的装置结构� ��意图。 具体实肺式 为了引用和清楚起见， 下文中使用的技术名词的说明、 简写或縮写总结如下： DCH: 专有通道；

PS: package switch, 分组交换；

PDP: Packet Data Protocol , 分组数据协议；

DM: daemon manager, 常驻后台的应用；

RT: required time, 时间间隔；

APP: appl ication, 泛指所有应用。

下面将结合本发明实施例中的附图， 对本发明实施例中的技术方案进行清楚、 完整 地描述， 显然， 所描述的实施例仅仅是本发明的一部分实施例 ， 而不是全部的实施例。 基于本发明中的实施例，本领域普通技术人员 在没有做出创造性劳动前提下所获得的所 有其他实施例， 都属于本发明保护的范围。

当 twitter (推特）、 windows l ive message (微软聊天工具）、 emai l (邮箱） 和 QQ (腾讯聊天工具） 等等 APP处于后台应用模式时 （例如当 QQ处于用户可见状态， 即 用户使用 QQ在进行聊天时， QQ即处于前台应用模式下； 当 QQ最小化至托盘上， 此时 QQ以用户不可见的形式存在， 即处于后台应用模式下）， 各个 APP需要在各自与网络交 互的 RT到达时， 分别激活 PDP, 并建立与网络的链接， 不断进行数据交互。 为避免处于 后台应用模式下的 APP在与网络进行交互的过程中产生大量功耗， 使终端的耗电量增加 待机时间减少，本发明通过以下方式在满足各 个处于后台应用模式下的有效 APP的前提 下， 减少激活 PDP的次数， 达到减少功耗， 降低终端的耗电量， 使终端待机时间增长的 目的： 在各个应用进入后台应用模式之后， 由各个 APP, 例如 QQ等应用向 DM提交自己 需要和网络交互的 RT， 由 DM统一管理 APP与网络交互的触发时间点， 使各个 APP与网 络进行数据交互的频率同步， 即在激活 PDP之后， 各个 APP接收到 DM的通知时开始建 立数据链接。 具体的实现方式通过以下实施例进行详细说明 。 实施例一：

请参阅附图 1， 主要包括以下步骤：

步骤 S101 , 获取处于后台应用模式下的各个有效 APP与网络进行数据交互的 RT。 在步骤 S101中， 由 DM获取处于后台应用模式下的各个有效 APP与网络进行数据交 互的 RT。

其中， 有效 APP是指在终端启动各个 APP之后， 运行状态以用户不可见的形式存在 的 APP,即当前处于后台应用模式下的 APP向 DM提交注册，而这些向 DM提交注册的 APP 即为当前有效 APP。

步骤 S102, 选取所述 RT中的最小 RT作为数据交互的目标定时时间， 启动 DM中的 定时器进行定时。

执行步骤 S102时， 从执行步骤 S101由 DM接收到时间间隔 RT中， 选取最小的 RT作为 DM 定时器的目标定时时间。

步骤 S103， 以所述目标定时时间到达时的时间点为触发数 据交互的时间点， 当所述 目标定时时间到达时， 获取当前时间间隔位于前后两次目标定时时间 之间的各个所述有 效 APP， 确定各个所述有效 APP为目标 APP。 在步骤 S103中， 确定当前的目标定时时间到达时的时间点为触 发数据交互的时间 点， 在执行步骤 S102时按照目标定时时间启动了 DM的定时器， 即将 DM的定时器设定为目 标定时时间。当目标定时时间到达时，由 DM确定需要进行数据交互的有效 APP为目标 APP, 并向各个目标 APP发送与网络进行数据交互的通知。

其中， 由 DM确定需要进行数据交互的目标 APP, 是指在 DM依据最小 RT进行循环定时 的过程中， 各个有效 APP也根据自身的定时器依据 RT进行倒计时。 在 DM的定时器每一次 到时时， 由 DM判断此时各个有效 APP自身定时器中的 RT是否位于上一次目标定时时间与 这一次目标定时时间之间， 并获取当前 RT位于前后两次目标定时时间之间的有效 APP, 该有效 APP即为符合进行数据交互的目标 APP。

需要说明的是， 定时器启动之后， 判断目标定时时间是否到达时， 可以采用正计时 的方式， 也可以采用倒计时的方式。 但是， 本发明实施例可采取的方式并不仅限于此。

步骤 S104, 激活 PDP, 建立所述目标 APP与网络之间的数据链接， 并进行数据交互。 在执行步骤 S103之后， 已确定各个目标 APP接收到与网络进行数据交互的通知， 然 后执行步骤 S104, 在第一个目标 APP去和网络进行数据交互之前， 激活 PDP, 然后， 在网 络与各个目标 APP之间建立各自的数据链接链路， 使各个目标 APP基于激活的 PDP建立各 自的数据链接， 完成与网络之间的数据交互。

需要说明的是， 在各个目标 APP与网络进行数据交互时， 所有目标 APP各自的定时器 复位， DM的定时器也复位。 在最小 RT未变的情况下， 重新启动目标 APP各自的定时器和 DM的定时器， 即循环执行步骤 S103与步骤 S104 , 直至没有目标 APP之后停止。 利用本发 明公开的方法， 可以使各个有效 APP将各自与网络进行数据交互的 RT提交给 DM， 由 DM使 各个有效 APP与网络之间的数据交互的频率进行同步， 并在只激活一次 PDP的基础上建立 各自的数据链接与网络进行数据交互， 在满足各个有效应用的前提下， 减少激活 PDP建 立数据链接的次数， 达到减少功耗， 降低终端的耗电量， 使终端待机时间增长的目的。

为使本发明公开的方法能够更加清楚的体现， 这里举例说明。 例如， 在终端的实际 应用中， 当前有 3个应用需要运行于后台， 并且需要和网络交互。 这 3个应用分别为： emai l twitter和 QQ。 emai l的 RT为 10分钟， twitter的 RT为 15分钟， QQ的 RT为 40分钟。

终端开机，在上述 3个应用进入后台应用模式之后，此 3个应用统一向 DM提交 RT时间， DM将 10分钟作为自己定时器时间。 当开机后 10分钟， DM的定时器第一次 RT超时并进行广播， email和 twitter在收到通 知后在同一时间发起请求建立数据链接， 完成与网络中的服务器的数据交互。 其中， twitter的 RT为 15分钟在两次目标定时时间之间， QQ的 RT为 40分钟不满足交互的条件， 在第 20分钟、 30分钟时， 也是如此， 但是在第 40分钟时， 此时 QQ的 RT满足数据交互的条 件， DM进行广播后， 这 3个应用便都会建立数据链接， 完成与服务器的数据交互。 由此， 与采用现有技术造成终端 7次激活 PDP并建立数据链接的方法相比，利用本发明公 开的方 法， 通过终端中的 DM对各个 APP进行协调控制， 终端只会 4次激活 PDP并建立数据链接， 减少了激活 PDP的次数， 因此能够减少终端的功耗， 节省大量的电量， 使终端的待机时 间也相对的得到增长。

其中， DM广播是指应用之间的一种交互方式， DM可以向多个已注册应用同时发送 相同信息， 即发送 APP与网络进行交互的通知 （交互指令）。 上述具体的执行过程请参 阅附图 2， 其中， A为进行数据交互的时间点 （即激活 PDP的时间点）， RT为时间间隔， email , twitter和 QQ为当前处于后台应用模式下的有效 APP。

此外， 在执行上述实施例一的步骤 S103时， 可能会出现多种情况， 下面针对执行该 步骤时可能出现的情况， 以及引起的相应的情况进行举例说明。 实施例二：

请参阅附图 3， 具体包括以下步骤：

步骤 S101 , 获取处于后台应用模式下的各个有效 APP与网络进行数据交互的 RT。 步骤 S102， 选取当前所述 RT中的最小 RT作为数据交互的目标定时时间， 启动 DM中的 定时器进行定时。

步骤 S103， 以所述目标定时时间到达时的时间点为触发数 据交互的时间点， 当所述 目标定时时间到达时， 获取当前时间间隔位于前后两次目标定时时间 之间的各个所述有 效 APP， 确定各个所述有效 APP为目标 APP。 其中， 执行步骤 S103中， 确定各个所述有效 APP为目标 APP的具体过程为：

步骤 S1031 , 以所述目标定时时间为触发数据交互的时间点 。

步骤 S1032, 当所述目标定时时间到达之前， 检测位于前后两次目标定时时间之间 的各个有效 APP中是否出现无效 APP， 如果出现， 则执行步骤 S1033; 如果没有出现， 则 执行步骤 S 1034。 其中， 无效 APP是指在处于后台应用模式下的有效 APP的工作模式转为前台应用 （前 台应用是相对于后台应用来说的， 此时的 APP处于用户主动使用的状态， 即该 APP处于用 户可见的状态） 时， 向 DM提交去注册， 当前提交去注册的有效 APP即成为无效 APP。

步骤 S 1033 , 当所述目标定时时间到达时， 确定其他有效 APP为与网络进行数据交互 的目标 APP。

步骤 S 1034, 当所述目标定时时间到达时， 确定各个所述有效 APP为目标 APP。

由上述执行步骤 S 103的具体过程中可以得知， 时间间隔在前后两次目标定时时间之 间的目标 APP的确定， 还需要在各个有效 APP收到通知后自行判断是否进行数据交互， 即 确定自身是否仍然有效， 是否仍然处于后台应用模式下。

因此， 在执行步骤 S 103确定可以与网络进行数据交互的目标 APP中， 该目标 APP需要 满足的条件是， 在定时器启动之后至到达定时时间这段时间内 ， 位于上一次目标定时时 间和这一次目标定时时间到达之间的各个有效 APP中没有出现无效的情况。

步骤 S 104, 激活 PDP, 建立所述目标 APP与网络之间的数据链接， 并进行数据交互。 执行步骤 S 104在第一个目标 APP去和网络进行数据交互之前， 激活 PDP, 然后在网络 与各个目标 APP之间建立各自的数据链接链路， 使各个目标 APP可以在只激活一次 PDP的 基础上建立各自的数据链接， 完成与网络之间的数据交互。

在本实施例二中， 执行步骤 S 101至步骤 S 102 , 以及步骤 S 104时的过程与实施例一中 相应的部分一致， 这里不再赘述。 但是， 在执行步骤 S 103时经过判断确定出现无效 APP, 此时， 依据目标定时时间， 执行步骤 S 104使各个目标 APP与网络进行数据交互时。 在所 有与网络进行数据交货的目标 APP各自维护的定时器复位， 即各个目标 APP自身的 RT复 位， DM所维护的定时器中的最小 RT也复位之后， 为保证下一次目标定时时间的准确性， 即确定最小 RT未变， 因此在执行步骤 S 104的同时， 还需要对各个有效 APP中的 RT进行检 测， 即执行步骤 S 105 (流程图中的虚线部分） 。

步骤 S 105 , 检测目标定时时间是否为无效 APP的 RT， 如果是则返回执行步骤 S 102 ; 如果否则返回执行步骤 S 1031。

因此， 在各个目标 APP与网络进行数据交互时， 所有目标 APP各自的定时器复位， DM的定时器也复位。 在出现最小 RT改变的情况下， 可以返回执行步骤 S 102 , 从当前的 RT中重新选取最小 RT作为目标定时时间，然后重新启动定时器，� ��续执行下面的步骤。

为更清楚的表述本实施例二所要表达的技术方 案， 这里针对判断的处于后台应用模 式下的 APP是否有效的情况进行举例说明。

例如， 有 2个处于后台应用模式下的 APP (QQ与 email ) 向 DM提交注册的信息， 对 应于步骤 S101由 DM接收 2个 APP提交的注册信息中的 RT。 其中， QQ提交的 RT为 30 分钟， email提交的 RT为 40分钟。对应于步骤 S102,此时 DM的定时器设定为 30分钟。 对应于步骤 S103, 此时的目标定时时间为 30分钟。

当一次 RT超时后， 即当目标定时时间 30分钟到达时， email的 RT为 40分钟位于 两次目标定时时间之内。 在确定 2个 APP都存在的情况下， 则确定 2个 APP都可以与网 络进行数据交互， 即执行对应的步骤 S104。

对应于步骤 S1032, 若在一次 RT超时之前， 即当目标定时时间 30分钟到达之前。 提交 40分钟 RT的 email去注册 （取消注册） 了， 即成为无效 APP, 此时的有效 APP只 有 QQ， 所以当 RT超时后， QQ执行步骤 S104与网络完成数据交互， 获取网络服务器上 的数据。 对应于步骤 S105, 由于无效 APP ( email ) 提交的 RT为 40分钟， 并不是目标 定时时间， 因此返回执行步骤 S1031 , 等待下一次的 RT ( 30分钟）超时。 具体数据交互 的过程请参阅附图 4， 其中， QQ和 email为 APP; A为 APP与网络进行数据交互的时间 点； B为 APP取消注册的时间点； RT为时间间隔。

对应于步骤 S1032, 若在一次 RT超时之前， 即当目标定时时间 30分钟到达之前， 提交 30分钟 RT的 QQ取消注册了。因为对应于目标定时时间的 RT30分钟的 APP取消注 册， 因此， 在执行完当前的 30分钟定时之后， 完成未取消注册的 email与网络之间进 行的数据交互之后， 对应执行步骤 S105的步骤， 返回执行步骤 S102, 重新确定目标定 时时间。 在当前实际应用中， 返回之后只有一个 RT为 40分钟的 emai l应用存在， 所以 此时 DM的定时器设置为 40分钟， 并在下一次 RT超时时生效， 即下一次目标定时时间 在 40分钟到达之后执行相关的步骤。 具体数据交互的过程请参阅附图 5， 其中， QQ和 email为 APP; A为 APP与网络进行数据交互的时间点； B为 APP取消注册的时间点； RT 为时间间隔。

通过本发明实施例二公开的方法，在面对实际 应用中可能出现的情况提供了选择的 方案。 当没有出现无效 APP的情况下， 执行与实施例一同样的技术方案， 由 DM依据确定 的目标定时时间对有效 APP与网络进行数据交互的频率进行同步， 并利用激活一次 PDP的 机会建立数据链接与网络进行数据交互， 在满足各个 APP的前提下， 减少激活 PDP建立数 据链接的次数， 达到减少功耗， 降低终端的耗电量， 使终端待机时间增长的目的。 此外， 在上述本发明公开的实施例一的基础上， 本发明还包括对检测到新提交注册 的 APP之后的执行过程， 具体由本发明公开的实施例三进行详细说明。 实施例三：

请参阅附图 6， 具体包括步骤 S 101至 S 107。 其中步骤 S 101至步骤 S 104的执行过 程与实施例一中对应的步骤 S 101至步骤 S 104—致， 这里不再赘述。 本实施例三与上述 实施例一的区别在于在所述目标定时时间重新 启动或重置之后（即完成数据交互之后）， 下次目标定时时间到达之前的一个时间点 T上， DM是否获取到新的有效 APP的注册信息， 即是否收到新的 APP提交的新 RT。 即在步骤 S 104之后还包括以下步骤：

步骤 S 106 , 获取新的有效 APP提交注册的时间点 T和新的有效 APP的新 RT。

步骤 S 107， 检测新 RT与时间点 T之和是否小于目标定时时间， 如果是， 则确定新 RT为目标定时时间， 返回执行步骤 S 103 ; 如果否， 则再执行一次步骤 S 103与步骤 S 104 之后返回执行步骤 S 102 (流程图中该返回的过程用虚线表示）。

通过执行本实施例三公开的方法， 在实施例一的基础上进一步解决了有新的有效 APP提交注册信息的问题， 即对 DM新获取的 RT与之前获取的 RT进行比较， 以确定最小的 RT，即 DM的定时时间，以保证在准确的目标定时时间� ��来时能够完成与网络的数据交互。 这里针对步骤 S 107中的两种情况， 利用该方法在终端中的实际应用进行举例说明 。

例如， 当前终端中处于后台应用模式下只有一个有效 APP1向 DM提交注册信息， 该有 效 APP的 RT1为 40分钟。

第一种情况， 在一次 RT (此时的目标定时时间为 40分钟）超时（此时完成数据交互， 定时器重新启动或重置） ， DM广播后的 5分钟 （这里的 5分钟为有效 APP2提交注册的时间 点 T ) 时， 另一个有效 APP2向 DM提交注册信息， 该有效 APP2的 RT2为 30分钟。

由于时间点 T与 RT2之和小于目标定时时间 （5+30=35〈40)， 则确定当前有效 APP2 对应的 RT为目标定时时间。 此时， DM的定时器重置时复位为 30分钟， 并在 DM复位之 后的 RT超时后 （30分钟后）， 重新循环执行步骤 S 103至步骤 S 104。 具体数据交互的过 程请参阅附图 7， 其中， A为有效 APP 1与网络进行数据交互的时间点； B为有效 APP1、 有效 APP2与网络进行数据交互的时间点； T为有效 APP2提交注册的时间点； RT为时间 间隔。

第二种情况， 在一次 RT (此时的目标定时时间为 40分钟） 超时， DM广播后的 6分钟 (对应于步骤 S 106， 其中， 这里的 6分钟为有效 APP2提交注册的时间点 T ) 时， 另一个有 效 ΑΡΡ2向 DM提交注册信息， 该有效 APP2的 RT2为 35分钟。

由于时间点 T与 RT2之和大于目标定时时间 （6+35=41〉40)， 则继续执行直至该次 的目标定时时间到达时， 使有效 APP1和有效 APP2同时完成与网络服务器的数据交互， 然后再重新选取当前有效 APP1与有效 APP2对应的 RT中最小的 RT作为数据交互的目标 定时时间。 此时， DM定时器重置（复位） 时应当被设定为 35分钟。 因此， 在 DM复位之 后的 RT超时 （35分钟） 后， 重新循环执行步骤 S 103至步骤 S 104。 具体的数据交互过 程请参阅附图 8。 其中， A为有效 APP 1与网络进行数据交互的时间点； B为有效 APP1、 有效 APP2与网络进行数据交互的时间点； T为有效 APP2提交注册的时间点； RT为时间 间隔。

需要说明的是， 在本实施例中有关时间点 T的说明并不仅限于例子中的分钟数， 该 时间点的范围根据目标定时时间而定， 只要包含在该次目标定时时间与下一次目标定 时 时间之间即可。

通过上述本发明的实施例三中的举例说明，在 解决使终端中处于后台应用模式下的 有效 APP与网络进行数据交互的频率同步的基础上， 进一步解决了在终端接收到新的有 效 APP的注册信息之后， 确定准确的目标定时时间的问题。 利用本发明公开的方法， 终 端中的 DM能够在接收到新的有效 APP的注册信息的同时，保证对各个有效 APP进行协调控 制， 以当前 RT中最小的 RT为目标定时时间， 不仅能够达到减少终端功耗， 而且还节省了 大量的电量， 使终端的待机时间得到增长的目的。

需要说明的是， 如果在执行本实施例三的同时， 出现无效 APP的情况， 按照该实施 例三公开的方法进行也可以得到解决。因此通 过利用本发明实施例三公开的一种数据交 互的方法， 不仅可以解决在终端接收到新的有效 APP的注册信息之后， 确定准确的目标 定时时间的问题， 还可以解决出现无效 APP所带来的问题。 最终， 使各个运行于后台的 应用与网络之间的数据交互的频率进行同步， 并利用终端中的 DM对各个有效 APP进行协 调控制， 并在只激活一次 PDP的基础上建立各自的数据链接与网络进行数 据交互， 在满 足各个处于后台应用模式下的有效 APP的前提下， 减少激活 PDP建立数据链接的次数， 达 到减少功耗， 降低终端的耗电量， 使终端待机时间增长的目的。 实施例四: 本实施例四所公开的方法， 在执行上述本发明公开的实施例一、 实施例二或实施例 三的各个步骤的基础上， 会实时的由 DM对终端执行监听。 以便 DM在接收到用户主动发起 PS域业务的指令时， 向各个有效 APP发送 DM广播， 使各个有效 APP建立数据链接完成与网 络之间的数据交互， 使此时的资源不会被浪费。 具体的过程为：

由 DM实时监听是否有主动发起的 PS指令。

当监听到有主动发起的 PS指令， 由 DM发送数据交互指令（DM广播）至各个有效 APP, 使各个有效 APP与网络进行数据交互。

当没有监听到主动发起的 PS指令， 则继续执行各个实施例的当前应执行的步骤。 因此， 在用户主动发起的 PS域业务， 并且使终端进入 DCH状态时， 采用本实施例公 开的方法， 可以解决因为终端进入 DCH状态时功率较大， 而没有得到合理使用， 致使资 源浪费的问题。

也就是说， 在 DM监听到用户主动发起的 PS指令时， 终端已经进入 DCH状态， 而 PDP已 经激活。 此时， 由 DM向各个有效 APP发送数据交互指令， 即便此时有效 APP或 DM的定时器 并没有到时， 例如， QQ定时 40分钟， 在还有 10分钟到时， 在 DM广播之后 QQ也利用当前的 时机， 完成与网络的数据交互， 并且将 DM的定时器复位 （因为， 已经在 QQ的最大与网络 交互时间间隔 40分钟内， 与网络进行了一次数据交互） 。 如果当前后台运行了若干个类 似 QQ的应用， 那么通过本实施例公开的方法就可以省去激活 PDP的次数， 同时， 达到节 省电量， 增加终端待机时间的目的。

为使本发明该实施例公开的方法能够更加清楚 的体现， 这里举例说明。 例如， 在终 端的实际应用中， 当前有三个应用需要运行于后台， 并且需要和网络交互。 这三个应用 分别为： emai l twitter和 QQ。 emai l的 RT为 10分钟， twitter为 15分钟， QQ为 40分钟。

终端开机后， 此三个应用统一向 DM提交 RT时间， DM将 10分钟作为自己定时器时间。 如果在开机后第 5分钟时， 用户使用浏览器打开网页 （用户主动发起 PS域业务） ， 此时 PDP被激活， 那么 DM就会向这三个应用发送通知， 此时这三个应用同时发起数据链接， 从服务器获取数据。 这样就利用用户主动发起的激活 PDP的机会完成了所有应用与网络 的交互， 同时所有定时器还需要复位。

如果 DM—直没有监听到用户主动发起 PS域业务的指令，那么这三个应用始终在 DM的 管理下进行与网络的数据交互。 当终端启动后 10分钟， DM的定时器第一次超时并进行广 播， emai l和 twitter在收到通知后， 在同一时间发起请求建立数据链接， 完成与网络服 务器的数据交互。 在第 20分钟、 30分钟到来时， 同样也是如此。 但是， 在第 40分钟到来 时， 此时 QQ的 RT满足数据交互的条件， DM进行广播后， 这 3个应用便都会建立数据链接， 完成与服务器的数据交互。 由此， 与采用现有技术造成终端 7次激活 PDP并建立数据链接 的方法相比， 利用本发明公开的方法， 通过终端中的 DM对各个 APP进行协调控制， 终端 只会 4次激活 PDP并建立数据链接， 不仅减少功耗， 而且还节省了大量的电量， 使终端的 待机时间也相对的得到增长。

上述本发明公开的实施例中详细描述了一种数 据交互的方法，对于本发明的方法可 采用多种形式的装置实现， 因此本发明还公开了一种数据交互的装置， 下面给出具体的 实施例进行详细说明。

请参阅附图 9， 为本发明公开的一种数据交互的装置结构示意 图， 主要包括： 获取 单元 201， 选取单元 202， 定时单元 203， 确定单元 204和交互单元 205。

获取单元 201，用于获取处于后台应用模式下的各个有效 APP与网络进行数据交互的

RT。

选取单元 202， 用于选取当前所述 RT中的最小 RT作为数据交互的目标定时时间。 定时单元 203， 用于启动目标定时时间和重置目标定时时间。

确定单元 204， 用于当所述目标定时时间到达时， 获取当前时间间隔位于前后两次 目标定时时间之间的各个所述有效 APP , 确定各个所述有效 APP为目标 APP。

交互单元 205， 用于激活 PDP, 建立所述目标 APP与网络之间的数据链接， 并在进行 数据交互后返回选取单元。

在进行终端中的有效 APP与网络进行数据交互的控制时， 首先， 由获取单元 201获取 有效 APP向 DM提交的与网络进行数据交互的 RT; 然后， 由选取单元 202从一个或多个有效 APP提交的 RT中， 选取最小 RT作为 DM的目标定时时间， 即用于 DM发送广播控制各个有效 APP与网络进行数据交互的时间； 然后， 在目标定时时间确定后， 由定时单元 203启动定 时，在定时到达时由确定单元 204确定当前各个有效 APP各自定时器中的 RT在 DM前后两次 目标定时时间之间， 确定符合上述条件的有效 APP为目标 APP; 最后， 由交互单元 205激 活 PDP, 并使确定的目标 APP建立数据链接与网络进行数据交互， 同时由定时单元 203重 置目标定时时间后重新开始启动定时， 进入选取单元 202继续下一循环。

通过本发明公开的装置中的各个单元， 能够完成 DM对各个有效 APP的统一管理， 使 各个满足条件的有效 APP与网络之间的数据交互的频率进行同步，在 满足各个 APP的前提 下， 减少激活 PDP建立数据链接的次数， 达到减少功耗， 降低终端的耗电量， 使终端待 机时间增长的目的。

请参阅附图 10， 为本发明公开的另一种数据交互的装置结构示 意图， 主要包括： 获 取单元 201， 选取单元 202， 定时单元 203， 确定单元 204、 交互单元 205、 第一检测单元 206和定时对比单元 207。

由图 10可知， 本发明公开的该装置在图 9所示出的装置的基础上增加了一个连接于 定时单元 203与确定单元 204之间的第一检测单元 206， 及分别与第一检测单元 206、 选取 单元 202和确定单元 204连接的定时对比单元 207。

该第一检测单元 206， 用于检测各个所述有效 APP中是否出现无效 APP， 如果出现， 则屏蔽无效 APP之后进入定时对比单元 207 ; 如果没有出现， 则直接进入确定单元 204。

该定时对比单元 207， 用于判断所述无效 APP的 RT是否为当前的目标定时时间， 如果 是， 则进入选取单元 202 ; 如果否， 则进入确定单元 204。

在图 10公开的该装置中， 获取单元 201， 选取单元 202， 定时单元 203， 确定单元 204 和交互单元 205所具有的功能与上述图 9所示出的装置中的获取单元 201， 选取单元 202， 定时单元 203， 确定单元 204和交互单元 205—致， 这里不再赘述。

但是， 与上述公开的装置的区别在于， 在定时单元 203启动定时之后， 由第一检测 单元 206对各个有效 APP进行检测， 如果没有出现无效 APP则之间计入确定单元 204， 继续 执行循环。

如果出现无效 APP则进入定时对比单元 207， 判断当前无效 APP对应的 RT是否为当前 的目标定时时间， 如果否， 则直接进入确定单元 204， 继续执行循环； 如果是， 则返回 至选定单元 202， 重新选取当前最小 RT为目标定时时间， 继续执行循环。 进一步完善了 本发明公开的装置。

请参阅附图 11， 为本发明公开的另一种数据交互的装置结构示 意图， 主要包括： 获 取单元 201， 选取单元 202， 定时单元 203， 确定单元 204、 交互单元 205和定时更新单元 208。 该定时更新单元 208连接与确定单元 204与选取单元 202之间。

其中， 该定时更新单元 208中包括： 第二检测单元 2081和更新单元 2082。

第二检测单元 2081， 用于检测在所述目标定时时间重置之后， 下一次目标定时时间 到达之前的时间点上获取的新的有效 APP的新 RT。

更新单元 2082，用于判断所述新 RT与所述时间点之和是否小于当前目标定时时� ��， 如果是， 则更新当前目标定时时间， 确定所述新 RT为目标定时时间之后， 进入确定单 元 204; 如果否， 则直接进入确定单元 204。

需要说明的是，在图 11公开的该装置中，获取单元 201，选取单元 202，定时单元 203， 确定单元 204和交互单元 205所具有的功能与上述图 9所示出的装置中的获取单元 201，选 取单元 202， 定时单元 203， 确定单元 204和交互单元 205—致， 这里不再赘述。

由图 11可知， 在定时单元 203重启或是重置的情况下， 由定时更新单元 208中的第二 检测单元 2081检测是否有新提交注册的 APP， 如果没有则直接进入确定单元 204， 继续执 行循环。

如果确定有新 APP , 则由更新单元 2082判断新 RT与接收新 APP的时间点 T之和是否小 于当前目标定时时间， 如果小于， 则将新 RT更新为当前目标定时时间， 再直接进入确定 单元 204， 继续执行循环； 如果大于， 则直接进入确定单元 204， 再通过交互单元 205返 回选取单元 202。

需要说明的是， 交互单元 205也可以与选取单元直接连接， 在更新单元 2082判断 新 RT与接收新 APP的时间点 T之和大于当前目标定时时间之后，直接进入� �定单元 204， 并通过交互单元 205返回至定时单元 203中。

为本发明公开的另一种数据交互的装置结构示 意图，在上述公开的各个装置上添加 了一个监听单元。

该监听单元， 用于监听是否有主动发起分组交换指令， 当监听到有主动发起的分组 交换指令时， 则发送数据交互指令至交互单元。

通过添加的监听单元， 能够在终端进入 DCH状态时， 合理利用由于进入该状态所产 生的较大功率，在已激活 PDP的基础上完成有效 APP与网络之间建立数据链接进行数据交 互的过程， 从而减少处于后台应用模式下的有效 APP激活 PDP的次数， 使功率资源得到节 省， 进一步达到节省终端的电量的目的。 综上所述：

利用本发明公开的数据交互方法及装置，通过 使各个运行于后台的应用与网络之间 的数据交互的频率进行同步， 并在只激活一次 PDP的基础上建立各自的数据链接与网络 进行数据交互， 在满足各个处于后台应用模式下的有效 APP的前提下， 减少激活 PDP建立 数据链接的次数， 达到减少功耗， 降低终端的耗电量， 使终端待机时间增长的目的。 此外， DM还采用实时监听的方式， 监听是否有主动发起的 PS域业务， 利用已激活的 PDP建立数据链接，使各个有效 APP与网络进行数据交互，进一步降低了终端的 功率消耗， 减少了激活 PDP建立数据链接的次数， 从而达到降低终端耗电量， 增加终端待机时间的 目的。

本说明书中各个实施例采用递进的方式描述， 每个实施例重点说明的都是与其他实 施例的不同之处， 各个实施例之间相同相似部分互相参见即可。 对于实施例公开的装置 而言， 由于其与实施例公开的方法相对应， 所以描述的比较简单， 相关之处参见方法部 分说明即可。

结合本文中所公开的实施例描述的方法或算法 的步骤可以直接用硬件、处理器执行 的软件模块， 或者二者的结合来实施。 软件模块可以置于随机存储器 （RAM)、 内存、 只 读存储器 （R0M)、 电可编程 R0M、 电可擦除可编程 R0M、 寄存器、 硬盘、 可移动磁盘、 CD-ROM, 或技术领域内所公知的任意其它形式的存储介 质中。

对所公开的实施例的上述说明， 使本领域专业技术人员能够实现或使用本发明 。 对 这些实施例的多种修改对本领域的专业技术人 员来说将是显而易见的，本文中所定义的 一般原理可以在不脱离本发明的精神或范围的 情况下， 在其它实施例中实现。 因此， 本 发明将不会被限制于本文所示的这些实施例， 而是要符合与本文所公开的原理和新颖特 点相一致的最宽的范围。