应用程序后台服务的启动方法及移动终端的制作方法
【专利摘要】本发明涉及通信领域，公开了一种应用程序后台服务的启动方法及移动终端。本发明中，应用程序后台服务的启动方法，包括：在应用程序启动时，创建至少一个定时广播；定时广播根据预定规则发送；应用程序在收到一定时广播时，启动预定的后台服务；检测是否存在待发送的定时广播；在检测到不存在时，再次创建定时广播。本发明还提供了一种包括：创建模块、接收模块、启动模块以及检测模块的移动终端。本发明能够使得处于关闭状态的应用程序的某些服务可以实现自启动，以便于移动终端能够接收到与该应用相关的服务信息，避免了应用程序在移动终端中关闭时，与该应用对应的所有的服务都被关闭，移动终端接收不到与该应用信息相关的服务信息的情况。
【专利说明】
应用程序后台服务的启动方法及移动终端
技术领域
[0001] 本发明涉及通信领域，特别涉及应用程序后台服务的启动方法及移动终端。
【背景技术】
[0002] 随着移动终端技术的不断发展，手机、电脑、平板电脑等移动终端已经成为人们生 活中不可缺少的一部分。目前，移动终端的应用程序种类越来越多，移动终端的功能也越来 越完善，用户可以通过在移动终端上安装各种各样的应用程序的方式来丰富生活，如，在移 动终端上安装音乐播放应用、游戏应用、购物应用、社交类应用等。
[0003] 在实现本发明过程中，发明人发现现有技术中至少存在如下问题：用户在启动移 动终端中的某一应用程序后，如果用户不将其在移动终端中关闭，应用程序就会在移动终 端的后台运存，容易造成移动终端的内存资源的浪费，且应用程序在后台运行时，耗电量较 大，会缩短移动终端的待机时间。但是，如果用户将应用程序在移动终端中关闭，便会同时 关闭与该应用对应的所有的服务，移动终端便无法接收到与该应用相关的服务信息，从而 使得用户不能及时的通过移动终端的获知有用信息。如，用户将"微信"关闭后，移动终端便 不能接收到微信朋友发送的信息。
【发明内容】
[0004] 本发明的目的在于提供一种应用程序后台服务的启动方法及移动终端，使得应用 程序的特定服务可以持续工作，不受应用程序被关闭的影响。
[0005] 为解决上述技术问题，本发明的实施方式提供了一种应用程序后台服务的启动方 法，包括：
[0006] 在应用程序启动时，创建至少一个定时广播;定时广播根据预定规则发送；
[0007] 应用程序在收到一定时广播时，启动预定的后台服务；
[0008] 检测是否存在待发送的定时广播;在检测到不存在时，再次创建定时广播。
[0009 ]本发明的实施方式还提供了 一种移动终端，包括：
[0010] 创建模块，用于在应用程序启动时，创建至少一个定时广播;还用于在检测模块检 测到不存在待发送的定时广播时，创建定时广播;其中，定时广播根据预定规则发送；
[0011] 接收模块，用于接收定时广播；
[0012] 启动模块，用于在接收模块接收到一定时广播时，启动预定的后台服务；
[0013] 检测模块，用于在预定的后台服务启动完成时，检测是否存在待发送的定时广播。
[0014] 本发明实施方式相对于现有技术而言，应用程序在启动时，则创建一个或多个定 时广播，被创建的定时广播根据预定规则发送。当应用程序接收到一个定时广播时，则应用 程序启动预定的后台服务，使得应用程序的某些服务启动，以保证用户所需要的服务正常 运行。并且，应用程序还检测是否存在待发送的定时广播，在不存在待发送的定时广播时， 再次创建定时广播，从而避免了应用程序在移动终端中关闭时，与该应用对应的所有的服 务都被关闭的情况。通过这种方式，相当于应用程序在启动时，给自己设置了一个"闹钟事 件"，预定规则就相当于"闹钟事件"的触发条件，移动终端在满足触发条件时，触发"闹钟事 件"，以启动预定的后台服务，从而使得处于关闭状态的应用程序的某些服务可以实现自启 动，以便于移动终端能够接收到与该应用相关的服务信息，避免了应用程序被关闭时，与该 应用对应的所有的服务都被关闭，用户接收不到与该应用信息相关的服务信息的情况。
[0015] 另外，在应用程序后台服务的启动方法中，具体包括:如果创建的定时广播数量大 于一个，则不同定时广播对应的预定时间点不同。这样，应用程序所创建的每个定时广播都 是有意义的，避免了定时广播创建重复，造成移动终端内存资源浪费的情况发生。并且，预 定的后台服务能够在预定时间点启动，以便于移动终端能够在不同的预定时间点接收到与 该应用相关的服务信息，获取的服务信息的时效性较强，且所占用的移动终端的内存资源 较少。
[0016] 另外，预定规则为:在终端开机时发送;或者，在终端亮屏时启动。由于终端开机时 或者终端亮屏时，用户很可能正在使用移动终端。因此，通过这种方式，以便于用户能够及 时的看到移动终端接收到的服务信息，在及时接收的同时，减少自启动次数，降低功耗，符 合用户的使用习惯。
[0017] 另外，创建至少一个定时广播中，利用提醒应用创建定时广播。由于移动终端中， 很可能本身就存在该提醒应用。因此，利用提醒应用创建定时广播，可以实现通过调用移动 终端中已有的应用程序的方式，执行该创建定时广播的操作，合理利用了移动终端中的现 有资源，在实现提醒功能时，尽量减少系统负担，从而不需要在移动终端中下载安装其他的 应用程序，节约了移动终端内存资源的使用，操作较为简单便捷，且可行性较高。
[0018] 另外，定时广播的名称由应用程序和提醒应用约定。这样，应用程序便能够在接收 到某个具体名字的广播时，执行启动预定的后台服务的操作。
【附图说明】
[0019] 图1是根据本发明第一实施方式中的应用程序后台服务的启动方法的流程示意 图；
[0020] 图2是根据本发明第二实施方式中的应用程序后台服务的启动方法的流程示意 图；
[0021 ]图3是根据本发明第三实施方式中的移动终端的结构示意图；
[0022]图4是根据本发明第四实施方式中的移动终端的结构示意图。
【具体实施方式】
[0023]为使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明的各实 施方式进行详细的阐述。然而，本领域的普通技术人员可以理解，在本发明各实施方式中， 为了使读者更好地理解本申请而提出了许多技术细节。但是，即使没有这些技术细节和基 于以下各实施方式的种种变化和修改，也可以实现本申请各权利要求所要求保护的技术方 案。
[0024] 本发明的第一实施方式涉及一种应用程序后台服务的启动方法。本实施方式在移 动终端的基础上进行实施，移动终端可以是手机、电脑、平板电脑等电子设备。
[0025] 本实施方式中的应用程序后台服务的启动方法的具体流程如图1所示，步骤如下：
[0026] 步骤101，判断应用程序是否启动。若是，则执行步骤102,否则结束。
[0027] 本实施方式中，应用程序对自己是否启动进行判断。具体的说，当一个应用程序启 动时，就有一个进程被操作系统创建，每个进程都会对应有一个主线程。主线程是在应用程 序开始时就执行的，对用户在应用程序中的每个操作进行监测，以便于及时的给予用户响 应。本实施方式中，当主线程开始监控时，则判定应用程序启动。如，用户点击应用程序在移 动终端中对应的图标时，则移动终端的操作系统接收到打开该图标对应的应用程序的操作 指令，移动终端的操作系统创建与该应用程序对应的进程，该进程都会对应有一个主线程， 此时判断结果为是。
[0028] 步骤102,创建至少一个定时广播。
[0029] 具体的说，应用程序创建一个或多个定时广播，创建的定时广播在移动终端的后 台运行，定时广播的运行与否与应用程序是否关闭无关。当应用程序被关闭时，定时广播依 然在移动终端的后台运行。其中，定时广播根据预定规则发送。本实施方式中，预定规则为： 在终端的系统时间到达预设时间点时发送。
[0030] 本实施方式中，应用程序利用提醒应用创建定时广播。如，移动终端的操作系统为 安卓系统，提醒应用可以是全局定时器AlarmManager。由于全局定时器AlarmManager是安 卓系统中常用的一种系统级别的提示服务，可以实现从指定时间开始，以一个固定的间隔 时间执行某项操作，所以常常与广播连用，实现闹钟等提示功能。因此，利用提醒应用创建 定时广播，可以实现通过调用移动终端中已有的应用程序的方式，执行该创建定时广播的 操作，合理利用了移动终端中的现有资源，在实现提醒功能时，尽量减少系统负担，从而不 需要在移动终端中下载安装其他的应用程序，节约了移动终端内存资源的使用，操作较为 简单便捷，且可行性较高。
[0031 ]步骤103,判断终端的系统时间是否到达一定时广播对应的预设时间点。若是，则 执行步骤104,否则执行步骤103。
[0032] 具体的说，应用程序在创建定时广播时，每个定时广播都对应有一预定时间点。并 且，应用程序创建的定时广播的个数为大于1时，不同的定时广播对应的预定时间点不同， 以便于应用程序所创建的每个定时广播都是有意义的，避免了定时广播创建重复，造成移 动终端内存资源浪费的情况发生。
[0033] 更具体的说，移动终端实时的获取当前系统时间，并将获取的当前系统时间与各 定时广播对应的预设时间点进行匹配，判断是否存在一定时广播对应的预设时间点与当前 系统时间相匹配。如果存在一定时广播与当前时间相匹配，则判断结果为是。否则，判断结 果为否。
[0034] 在实际操作时，技术人员可以将预设时长设置并保存在移动终端中。当应用程序 创建的定时广播为一个时，该定时广播对应的预设时间点可以设置为滞后于当前系统时间 点预设时长所对应的时间点。当应用程序创建的定时广播的个数为多个时，应用程序创建 的第一个定时广播对应的预设时间点可以为第一时间点，第一时间点可以设置为滞后于当 前系统时间点预设时长所对应的时间点，应用程序创建的第二个定时广播对应的预设时间 点可以为第二时间点，第二时间点可以设置为滞后于第一时间点预设时长所对应的时间 点，依次类推，以使得设置的多个不同定时广播对应的预定时间点不同。
[0035]以下进行举例说明：如，预设时长为10分钟，定时广播与预定时间点的对应关系以 表格的形式存在，在移动终端中存在如表一所示的定时广播--预定时间点对照表：
[0036]表一
[0038] 其中，预定时间点B为滞后于预定时间点A10分钟所对应的时间点，预定时间点C为 滞后于预定时间点B10分钟所对应的时间点。当移动终端获取的当前系统时间为A时，存在 一定时广播1的预定时间点与当前系统时间A相匹配，判定终端的系统时间到达一定时广播 对应的预设时间点。当过去10分钟后，移动终端获取的当前系统时间为B时，定时广播2的预 定时间点与当前系统时间B相匹配，判定终端的系统时间到达一定时广播对应的预设时间 点。
[0039] 步骤104，发送该预设时间点对应的定时广播。
[0040] 具体的说，提醒应用发送该预设时间点对应的定时广播。如，移动终端的操作系统 为安卓系统，提醒应用为全局定时器AlarmManager，则全局定时器AlarmManager发送该预 设时间点对应的定时广播。
[0041] 步骤105,应用程序判断是否接收到一定时广播。若是，则执行步骤106,否则执行 步骤105。
[0042] 步骤106，启动预定的后台服务。
[0043] 具体的说，预定的后台服务可以由技术人员预先设置并保存在移动终端中。如，预 定的后台服务可以是更新服务。
[0044] 本实施方式中，应用程序在创建定时广播时，定时广播具有名称，且定时广播的名 称由应用程序和提醒应用约定。这样，应用程序便能够在接收到某个具体名字的广播时，将 接收到的广播的名称与约定的定时广播的名称相匹配，在匹配成功时，执行启动预定的后 台服务的操作。
[0045] 在实际操作时，移动终端中的每个应用程序与提醒应用约定的方式不同，以便于 各应用程序在接收到广播时，各应用程序将接收到的广播的名称与约定的定时广播的名称 相匹配，只有接收到的广播的名称与约定的定时广播的名称相匹配的应用程序，才会执行 启动预定的后台服务的操作。
[0046] 步骤107,判断是否存在待发送的定时广播。若是，则执行步骤103,否则执行步骤 108〇
[0047] 具体的说，应用程序判断是否存在与该应用程序对应的待发送的定时广播。如，每 个应用程序在移动终端中具有唯一的标识码，应用程序在创建定时广播时，所创建的每个 定时广播都与该标识码相对应，应用程序查询移动终端中各待发送的定时广播的标识码， 判断是否存在一标识码与自己的标识码相匹配，若存在，则判断结果为是。否则，判断结果 为否。
[0048] 步骤108,再次创建定时广播。
[0049]综上所述，本实施方式中，相当于应用程序在启动时，给自己设置了一个"闹钟事 件"，预定规则就相当于"闹钟事件"的触发条件，移动终端在满足触发条件时，触发"闹钟事 件"，以启动预定的后台服务，从而使得处于关闭状态的应用程序的某些服务可以实现自启 动，以便于移动终端能够接收到与该应用相关的服务信息，避免了应用程序在移动终端中 关闭时，与该应用对应的所有的服务都被关闭，移动终端接收不到与该应用信息相关的服 务信息的情况。
[0050]本发明的第二实施方式涉及一种应用程序后台服务的启动方法，具体流程如图2 所示。第二实施方式与第一实施方式大致相同，主要区别之处在于:在第一实施方式中，预 定规则为:在终端的系统时间到达预设时间点时发送。而在本发明第二实施方式中，预定规 则为:在终端开机时发送;或者，在终端亮屏时启动。
[0051 ]本实施方式中的步骤201至步骤202与第一实施方式中的步骤101与步骤102大致 相同，步骤204至步骤208与第一实施方式中的步骤104与第一实施方式中的步骤104至步骤 108大致相同，为减少重复，在此不再赘述，以下对不同部分进行说明：
[0052]步骤203，判断终端是否亮屏或者终端是否开机。若是，则执行步骤204，否则执行 步骤203。
[0053]具体的说，移动终端判断当前是否处于亮屏状态。或者，移动终端判断是否开机。 当移动终端满足亮屏状态或者开机的两个条件的其中之一时，则判断结果为是。如，移动终 端的显示屏当前处于工作状态，则判断结果为是。如，移动终端的操作系统开始运行，则判 断结果为是。然而，上述举例仅为说明，本实施方式中，并不对判断终端是否亮屏或者终端 是否开机做任何限制。
[0054]由于终端开机时或者终端亮屏时，用户很可能正在使用移动终端。因此，通过这种 方式，以便于用户能够及时的看到移动终端接收到的服务信息。
[0055]上面各种方法的步骤划分，只是为了描述清楚，实现时可以合并为一个步骤或者 对某些步骤进行拆分，分解为多个步骤，只要包含相同的逻辑关系，都在本专利的保护范围 内；对算法中或者流程中添加无关紧要的修改或者引入无关紧要的设计，但不改变其算法 和流程的核心设计都在该专利的保护范围内。
[0056]本发明第三实施方式涉及一种移动终端，如图3所示，包括：
[0057]创建模块1，用于在应用程序启动时，创建至少一个定时广播。创建模块1还用于在 检测模块4检测到不存在待发送的定时广播时，创建定时广播。其中，定时广播根据预定规 则发送。
[0058]接收模块2,用于接收定时广播。
[0059] 启动模块3,用于在接收模块接收到一定时广播时，启动预定的后台服务。
[0060] 检测模块4,用于在预定的后台服务启动完成时，检测是否存在待发送的定时广 播。
[0061] 本实施方式中，创建模块1利用提醒应用创建定时广播。创建模块1中，预定规则 为:在终端的系统时间到达预设时间点时发送，且创建的定时广播数量大于一个时，不同定 时广播对应的预定时间点不同。
[0062] 以实际装置为例进行说明：移动终端包含处理器，处理器用于在应用程序启动时， 控制应用程序创建至少一个定时广播。处理器还用于在应用程序检测到不存在待发送的定 时广播时，控制应用程序创建定时广播。其中，定时广播根据预定规则发送。处理器还用于 接收定时广播。处理器还用于在接收到一定时广播时，控制应用程序启动预定的后台服务。 处理器还用于在预定的后台服务启动完成时，检测是否存在待发送的定时广播。
[0063]不难发现，本实施方式为与第一实施方式相对应的系统实施例，本实施方式可与 第一实施方式互相配合实施。第一实施方式中提到的相关技术细节在本实施方式中依然有 效，为了减少重复，这里不再赘述。相应地，本实施方式中提到的相关技术细节也可应用在 第一实施方式中。
[0064]值得一提的是，本实施方式中所涉及到的各模块均为逻辑模块，在实际应用中，一 个逻辑单元可以是一个物理单元，也可以是一个物理单元的一部分，还可以以多个物理单 元的组合实现。此外，为了突出本发明的创新部分，本实施方式中并没有将与解决本发明所 提出的技术问题关系不太密切的单元引入，但这并不表明本实施方式中不存在其它的单 J L 〇
[0065]本发明第四实施方式涉及一种移动终端，如图4所示。第四实施方式与第三实施方 式大致相同，主要区别之处在于:在第三实施方式中，创建模块1中，预定规则为:在终端的 系统时间到达预设时间点时发送，且创建的定时广播数量大于一个时，不同定时广播对应 的预定时间点不同。而在本发明第四实施方式中，预定规则为:在终端开机时发送;或者，在 终端亮屏时启动。
[0066]以实际装置为例进行说明：移动终端包含处理器5以及显示屏6。处理器5用于在应 用程序启动时，控制应用程序创建至少一个定时广播。处理器5还用于在应用程序检测到不 存在待发送的定时广播时，控制应用程序创建定时广播。处理器5还用于检测显示屏6是否 处于工作状态，或者检测移动终端的操作系统是否开始运行。处理器5还用于在显示屏6处 于工作状态，或者移动终端的操作系统开始运行时，发送定时广播。处理器5还用于在应用 程序接收到一定时广播时，控制应用程序启动预定的后台服务。处理器5还用于在预定的后 台服务启动完成时，检测是否存在待发送的定时广播。
[0067]由于第二实施方式与本实施方式相互对应，因此本实施方式可与第二实施方式互 相配合实施。第二实施方式中提到的相关技术细节在本实施方式中依然有效，在第二实施 方式中所能达到的技术效果在本实施方式中也同样可以实现，为了减少重复，这里不再赘 述。相应地，本实施方式中提到的相关技术细节也可应用在第二实施方式中。
[0068]本领域技术人员可以理解实现上述实施例方法中的全部或部分步骤是可以通过 程序来指令相关的硬件来完成，该程序存储在一个存储介质中，包括若干指令用以使得一 个设备(可以是单片机，芯片等)或处理器(processor)执行本申请各个实施例所述方法的 全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器（R0M，Read-0nly Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程 序代码的介质。
[0069]本领域的普通技术人员可以理解，上述各实施方式是实现本发明的具体实施例， 而在实际应用中，可以在形式上和细节上对其作各种改变，而不偏离本发明的精神和范围。
【主权项】
1. 一种应用程序后台服务的启动方法，其特征在于，包括： 在应用程序启动时，创建至少一个定时广播;所述定时广播根据预定规则发送； 所述应用程序在收到一定时广播时，启动预定的后台服务； 检测是否存在待发送的定时广播;在检测到不存在时，再次创建定时广播。2. 根据权利要求1所述的应用程序后台服务的启动方法，其特征在于，所述预定规则 为:在终端的系统时间到达预设时间点时发送。3. 根据权利要求2所述的应用程序后台服务的启动方法，其特征在于，在所述应用程序 后台服务的启动方法中，具体包括:如果创建的定时广播数量大于一个，则不同定时广播对 应的预定时间点不同。4. 根据权利要求1所述的应用程序后台服务的启动方法，其特征在于，所述预定规则 为:在终端开机时发送;或者，在所述终端亮屏时启动。5. 根据权利要求1至4中任一项所述的应用程序后台服务的启动方法，其特征在于，所 述创建至少一个定时广播中，利用提醒应用，创建所述定时广播。6. 根据权利要求5所述的应用程序后台服务的启动方法，其特征在于，所述定时广播的 名称由所述应用程序和所述提醒应用约定。7. -种移动终端，其特征在于，包括： 创建模块，用于在应用程序启动时，创建至少一个定时广播;还用于在检测模块检测到 不存在待发送的定时广播时，创建定时广播;其中，所述定时广播根据预定规则发送； 接收模块，用于接收定时广播； 启动模块，用于在所述接收模块接收到一定时广播时，启动预定的后台服务； 所述检测模块，用于在所述预定的后台服务启动完成时，检测是否存在待发送的定时 广播。8. 根据权利要求7所述的移动终端，其特征在于，所述创建模块中，所述预定规则为:在 终端的系统时间到达预设时间点时发送;或者，在所述终端开机时发送;或者，在所述终端 亮屏时启动。9. 根据权利要求8所述的移动终端，其特征在于，在所述预定规则为:在终端的系统时 间到达预设时间点时发送，且创建的定时广播数量大于一个时，不同定时广播对应的预定 时间点不同。10. 根据权利要求7至9中任一项所述的移动终端，其特征在于，所述创建模块利用提醒 应用创建所述定时广播。
【文档编号】G06F9/54GK106055360SQ201610371888
【公开日】2016年10月26日
【申请日】2016年5月30日
【发明人】李腾飞
【申请人】乐视控股（北京）有限公司, 乐视网信息技术（北京）股份有限公司