CN114860392A - 客户端的保活方法、装置及存储介质 - Google Patents

客户端的保活方法、装置及存储介质 Download PDF

Info

Publication number
CN114860392A
CN114860392A CN202110166643.3A CN202110166643A CN114860392A CN 114860392 A CN114860392 A CN 114860392A CN 202110166643 A CN202110166643 A CN 202110166643A CN 114860392 A CN114860392 A CN 114860392A
Authority
CN
China
Prior art keywords
scene
alive
keep
client
information
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202110166643.3A
Other languages
English (en)
Inventor
徐士立
洪楷
张其田
陈晶晶
刘专
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Tencent Technology Shenzhen Co Ltd
Original Assignee
Tencent Technology Shenzhen Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Tencent Technology Shenzhen Co Ltd filed Critical Tencent Technology Shenzhen Co Ltd
Priority to CN202110166643.3A priority Critical patent/CN114860392A/zh
Priority to EP22748954.9A priority patent/EP4220398A4/en
Priority to PCT/CN2022/073659 priority patent/WO2022166675A1/zh
Publication of CN114860392A publication Critical patent/CN114860392A/zh
Priority to US17/973,613 priority patent/US20230056294A1/en
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/545—Interprogram communication where tasks reside in different layers, e.g. user- and kernel-space
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
    • G06F9/4893—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues taking into account power or heat criteria
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4812—Task transfer initiation or dispatching by interrupt, e.g. masked
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/485—Task life-cycle, e.g. stopping, restarting, resuming execution
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/543—User-generated data transfer, e.g. clipboards, dynamic data exchange [DDE], object linking and embedding [OLE]

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer And Data Communications (AREA)
  • Telephonic Communication Services (AREA)

Abstract

本申请实施例提供一种客户端的保活方法、装置及存储介质，该方法包括：客户端在切换至后台时，向客户端服务器发送第一请求，客户端服务器根据第一请求为客户端所处的第一场景确定第一保活时长。客户端将第一场景的场景信息和第一保活时长携带在第二请求中发送给终端设备，以请求终端设备保活第一场景。终端设备将该第二请求发送给终端服务器，终端服务器根据该第二请求生成第一信息，该第一信息用于指示第一场景的保活信息，终端设备根据该第一信息确定是否保活第一场景，进而实现根据用户需求对第一场景的灵活保活。

Description

客户端的保活方法、装置及存储介质
技术领域
本申请实施例涉及计算机技术领域，尤其涉及一种客户端的保活方法、装置及存储介质。
背景技术
随着软件技术的快速发展和人们生活需要的提高，各种各样的客户端应用而生。通常一台终端设备上安装有多个客户端，这些客户端共享终端设备的资源。客户端在运行过程中，经常有需要切换到后台的场景，例如客户端是游戏客户端，用户在游戏运行状态A时，接听电话，此时游戏会切换至后台运行。
由于终端设备的资源有限，为了保障终端设备的性能和功耗，会定期停止后台客户端，导致用户在重新将客户端切换回至前台时，客户端的运行状态丢失，需要重新加载客户端，严重影响了用户体验。为了解决上述技术问题，终端设备需要根据用户需求对某些客户端进行保活，保活是指客户端(APP)切换至后台后，终端设备仍然保证客户端的后台运行状态。
但是，目前没有有效的方式，对用户需求的客户端进行保活。
发明内容
本申请实施例提供一种客户端的保活方法、装置及存储介质，以实现对客户端进行保活。
第一方面，本申请实施例提供一种客户端的保活方法，应用于终端设备，包括：
接收客户端切换至后台时所发送的第二请求，所述第二请求包括当前时刻所述客户端所处的第一场景的场景信息以及所述第一场景对应的第一保活时长；
将所述第二请求发送给终端服务器；
接收所述终端服务器根据所述第二请求确定的第一信息，所述第一信息用于指示所述第一场景的保活信息；
根据所述第一信息，确定是否对所述第一场景进行保活。
第二方面，本申请实施例提供一种客户端的保活方法，应用于终端设服务器，包括：
接收来自终端设备发送的第二请求，所述第二请求包括当前时刻客户端所处的第一场景的场景信息和所述第一场景对应的第一保活时长；
根据所述第一场景的场景信息和所述第一场景对应的第一保活时长中的至少一个，确定所述第一场景是否合法；
在确定所述第一场景合法时，向所述终端设备发送第一信息，所述第一信息用于指示所述第一场景的保活信息。
第三方面，本申请实施例提供一种客户端的保活方法，应用于客户端，包括：
在客户端切换至后台时，获得当前时刻所述客户端所处的第一场景的场景信息；
向客户端服务器发送第一请求，所述第一请求包括所述第一场景的场景信息；
接收所述客户端服务器发送的所述第一场景对应的第一保活时长；
向终端设备发送第二请求，所述第二请求包括所述第一场景的场景信息和所述第一场景对应的第一保活时长。
第四方面，本申请实施例提供一种客户端的保活方法，应用于客户端服务器，包括：
接收客户端切换至后台时所发送的第一请求，所述第一请求包括当前时刻所述客户端所处的第一场景的场景信息；
根据所述第一场景的场景信息，确定所述第一场景对应的第一保活时长；
将所述第一场景对应的第一保活时长发送给所述客户端。
第五方面，本申请实施例提供一种客户端的保活装置，应用于终端设备，包括：
接收单元，用于接收客户端切换至后台时所发送的第二请求，所述第二请求包括当前时刻所述客户端所处的第一场景的场景信息以及所述第一场景对应的第一保活时长；
发送单元，用于将所述第二请求发送给终端服务器；
接收单元，还用于接收所述终端服务器根据所述第二请求确定的第一信息，所述第一信息用于指示所述第一场景的保活信息；
处理单元，用于根据所述第一信息，确定是否对所述第一场景进行保活。
在一些实施例中，所述第一信息包括保活策略，所述保活策略包括所述客户端的多个可保活的第一预设场景所对应的可保活条件；上述处理单元，具体用于根据所述第一场景的场景信息和所述客户端的多个可保活的第一预设场景所对应的可保活条件，确定是否对所述第一场景进行保活。
在一些实施例中，所述第一预设场景所对应的可保活条件包括保活所述第一预设场景时所述终端设备所需的资源值，上述处理单元，具体用于根据所述第一场景的场景信息，确定所述第一场景是否为所述第一预设场景；若确定所述第一场景为所述第一预设场景，则获取当时时刻所述终端设备的空闲资源值；根据所述终端设备的空闲资源值和保活所述第一场景时所述终端设备所需的资源值，确定是否对所述第一场景进行保活。
在一些实施例中，上述处理单元，具体用于在保活所述第一场景时所述终端设备所需的资源值小于预设资源值，且所述终端设备的空闲资源值大于或等于预测资源值时，确定对所述第一场景进行保活，所述预测资源值为所述终端设备预测的在下一时刻所述终端设备运行前端程序所需的最小资源值；或者，在保活所述第一场景时所述终端设备所需的资源值大于或等于所述预设资源值时，确定对所述第一场景不进行保活；或者，在所述终端设备的空闲资源值小于预测资源值时，确定对所述第一场景不进行保活。
在一些实施例中，处理单元，还用于在所述终端设备保活所述第一场景的情况下，检测到下一时刻所述终端设备的空闲资源值小于所述预测资源值时，停止保活所述第一场景。
在一些实施例中，处理单元，还用于在所述终端设备保活所述第一场景的情况下，检测到所述第一场景对应的第一保活时长到达时，停止保活所述第一场景。
在一些实施例中，所述第一信息包括所述第一场景的保活结果，处理单元，还用于若所述第一场景的保活结果为保活时，则确定对所述第一场景进行保活；若所述第一场景的保活结果为不保活时，则确定不对所述第一场景进行保活。
在一些实施例中，接收单元，还用于接收所述终端服务器发送的第一停止保活指示，并根据所述第一停止保活指示停止保活所述第一场景，其中第一停止保活指示停止是终端服务器检测到下一时刻所述终端设备的空闲资源值小于所述预测资源值时发送的。
在一些实施例中，接收单元，还用于接收所述终端服务器发送的第二停止保活指示，并根据所述第二停止保活指示停止保活所述第一场景，其中第二停止保活指示停止是终端服务器检测到所述第一场景对应的第一保活时长到达时发送的。
在一些实施例中，接收单元，还用于在接收来自于客户端的第二请求之前，接收来自所述客户端的第三请求，所述第三请求用于查询所述终端设备是否具有保活功能，所述第三请求包括所述客户端的标识信息；
发送单元，还用于在所述终端设备具有所述保活功能时，向所述终端服务器发送所述第三请求；
接收单元，还用于接收来自所述终端服务器根据所述第三请求发送的第一响应，所述第一响应用于指示所述客户端为合法客户端；
发送单元，还用于根据所述第一响应，向所述客户端发送第二响应，所述第二响应用于指示所述终端设备具有保活功能。
在一些实施例中，发送单元，还用于将所述第一场景是否被保活的保活结果发送给所述客户端。
第六方面，本申请实施例提供一种客户端的保活装置，应用于终端服务器，包括：
接收单元，用于接收来自所述终端设备发送的第二请求，所述第二请求包括当前时刻客户端所处的第一场景的场景信息和所述第一场景对应的第一保活时长；
处理单元，用于根据所述第一场景的场景信息和所述第一场景对应的第一保活时长中的至少一个，确定所述第一场景是否合法；
发送单元，用于在确定所述第一场景合法时，向所述终端设备发送第一信息，所述第一信息用于指示所述第一场景的保活信息。
在一些实施例中，处理单元，具体用于在确定所述第一场景对应的第一保活时长大于第一预设时长时，确定所述第一场景不合法。
在一些实施例中，处理单元，具体用于根据所述第一场景的场景信息，获得历史时刻所述客户端对应的历史保活请求信息；根据所述客户端对应的历史保活请求信息，确定所述第一场景是否合法。
在一些实施例中，处理单元，具体用于根据所述历史保活请求信息中所请求保活的场景信息，确定所述客户端在历史时间内所请求保活的场景数量大于第一预设值，则确定所述第一场景不合法；或者，根据所述历史保活请求信息中所请求的保活时长信息，确定所述客户端中超过第二预设值个场景所请求的保活时长大于第二预设时长，则确定所述第一场景不合法。
在一些实施例中，处理单元，还用于获取保活策略，所述保活策略包括所述客户端的多个可保活的第一预设场景所对应的可保活条件；根据所述保活策略，生成第一信息。
在一些实施例中，所述第一信息包括保活策略。
在一些实施例中，所述第一信息包括所述第一场景的保活结果，处理单元，具体用于根据所述第一场景的场景信息和保活策略中所述客户端的多个可保活的第一预设场景所对应的可保活条件，确定所述第一场景的保活结果。
在一些实施例中，所述第一预设场景所对应的可保活条件包括保活所述第一预设场景时所述终端设备所需的资源值，处理单元，具体用于根据所述第一场景的场景信息，确定所述第一场景是否为所述第一预设场景；若确定所述第一场景为所述第一预设场景，则获取当时时刻所述终端设备的空闲资源值；根据所述终端设备的空闲资源值和保活所述第一场景时所述终端设备所需的资源值，确定所述第一场景的保活结果。
在一些实施例中，处理单元，具体用于在保活所述第一场景时所述终端设备所需的资源值小于预设资源值，且所述终端设备的空闲资源值大于或等于预测资源值时，确定所述第一场景的保活结果为保活，所述预测资源值为所述终端设备预测的在下一时刻所述终端设备运行前端程序所需的最小资源值；或者，在保活所述第一场景时所述终端设备所需的资源值大于或等于所述预设资源值时，确定所述第一场景的保活结果为不保活；或者，在所述终端设备的空闲资源值小于预测资源值时，确定所述第一场景的保活结果为不保活。
在一些实施例中，处理单元，还用于在所述终端设备保活所述第一场景的情况下，检测到下一时刻所述终端设备的空闲资源值小于预测资源值时，控制发送单元向所述终端设备发送第一停止保活指示。
在一些实施例中，处理单元，还用于在所述终端设备保活所述第一场景的情况下，检测到所述第一场景对应的第一保活时长到达时，控制发送单元向所述终端设备发送第二停止保活指示。
在一些实施例中，接收单元在接收来自所述终端设备发送的第二请求之前，还用于接收来自所述终端设备的第三请求，所述第三请求用于查询所述终端设备是否具有保活功能，所述第三请求包括所述客户端的标识信息；处理单元，还用于根据所述客户端的标识信息，检查所述客户端是否为合法客户端；发送单元，还用于在检查所述客户端是合法客户端时，向所述终端设备发送第一响应，所述第一响应用于指示所述客户端为合法客户端。
第七方面，本申请实施例提供一种客户端的保活装置，应用于客户端，包括：
处理单元，用于在所述客户端切换至后台时，获得当前时刻所述客户端所处的第一场景的场景信息；
发送单元，用于向客户端服务器发送第一请求，所述第一请求包括所述第一场景的场景信息；
接收单元，用于接收所述客户端服务器发送的所述第一场景对应的第一保活时长；
发送单元，还用于向终端设备发送第二请求，所述第二请求包括所述第一场景的场景信息和所述第一场景对应的第一保活时长。
在一些实施例中，发送单元还用于向所述终端设备发送第三请求，所述第三请求用于查询所述终端设备是否具有保活功能，所述第三请求包括所述客户端的标识信息；
接收单元还用于接收到来自所述终端设备发送的第二响应，所述第二响应用于指示所述终端设备具有保活功能。
在一些实施例中，接收单元还用于接收所述终端设备发送的所述第一场景是否被保活的保活结果；发送单元还用于将所述第一场景的保活结果发送给所述客户端服务器。
在一些实施例中，在所述第一场景处于保活状态时，发送单元还用于在检查到所述客户端进入所述第一场景的下一个场景时，向用户发送通知消息，所述通知消息用于通知所述用户返回所述客户端。
在一些实施例中，在所述第一场景的类型为主动切换后台，发送单元还用于在检查到所述第一场景对应的第一保活时长到达且所述客户端未进入所述第一场景的下一个场景时，向所述客户端服务器重新发送第一请求。
第八方面，本申请实施例提供一种客户端的保活装置，应用于客户端服务器，包括：
接收单元，用于接收客户端切换至后台时所发送的第一请求，所述第一请求包括当前时刻所述客户端所处的第一场景的场景信息；
处理单元，用于根据所述第一场景的场景信息，确定所述第一场景对应的第一保活时长；
发送单元，用于将所述第一场景对应的第一保活时长发送给所述客户端。
在一些实施例中，处理单元具体用于根据所述第一场景的场景信息，确定所述第一场景的类型；根据所述第一场景的类型，确定所述第一场景对应的第一保活时长。
在一些实施例中，处理单元具体用于若所述第一场景的类型为被动切换至后台，则确定所述当前时刻导致所述客户端切换至后台的用户行为；获取所述用户行为的历史数据；根据所述历史数据中所述用户执行所述用户行为所花费的时长，确定所述第一场景对应的第一保活时长。
可选的，所述用户行为包括所述用户接听电话或所述用户回复消息。
在一些实施例中，处理单元具体用于若所述第一场景的类型为主动切换至后台，则获取所述客户端从所述第一场景进入所述第一场景的下一个场景之间的时间间隔；根据所述客户端从所述第一场景进入所述第一场景的下一个场景之间的时间间隔，确定所述第一场景对应的第一保活时长。
在一些实施例中，处理单元还用于在所述第一场景与所述第一场景的下一个场景之间的时间间隔未知时，将预设的保活时长确定为所述第一场景对应的第一保活时长。
可选的，若所述客户端为游戏客户端，则所述第一场景包括角色死亡或等待队友进入下一局。
在一些实施例中，处理单元还用于根据所述第一场景的场景信息，确定所述第一场景是否属于预设的可保活场景；确定所述第一场景属于预设的可保活场景时，根据所述第一场景的场景信息，确定所述第一场景对应的第一保活时长。
在一些实施例中，若所述客户端服务器包括第一预设对应关系，所述第一预设对应关系包括所述客户端的多个可保活的第二预设场景所对应的保活时长，则，处理单元具体用于根据所述第一场景的场景信息，确定所述第一场景是否为所述第二预设场景；若确定所述第一场景为所述第二预设场景，则从所述第一预设对应关系中查询到所述第一场景对应的第一保活时长。
在一些实施例中，接收单元还用于接收所述客户端发送所述第一场景是否可以保活的保活结果；处理单元用于根据所述第一场景的保活结果，更新所述客户端服务器所保存的可保活的场景信息。
第九方面，本申请实施例提供一种电子设备，包括处理器和存储器；
所述存储器，用于存储计算机程序；
所述处理器，用于执行所述计算机程序以实现上述第一方面、第二方面、第三方面、第四方面所述的方法。
第十方面，本申请实施例提供了一种计算机可读存储介质，所述存储介质包括计算机指令，当所述指令被计算机执行时，使得所述计算机实现如第一方面、第二方面、第三方面、第四方面所述的方法。
第十一方面，本申请实施例提供一种计算机程序产品，所述程序产品包括计算机程序，所述计算机程序存储在可读存储介质中，计算机的至少一个处理器可以从所述可读存储介质读取所述计算机程序，所述至少一个处理器执行所述计算机程序使得计算机实施第一方面、第二方面、第三方面、第四方面所述的方法。
本申请实施例提供的客户端的保活方法、装置及存储介质，客户端在切换至后台时，向客户端服务器发送第一请求，客户端服务器根据第一请求为客户端所处的第一场景确定第一保活时长。客户端将第一场景的场景信息和第一保活时长携带在第二请求中发送给终端设备，以请求终端设备保活第一场景。终端设备将该第二请求发送给终端服务器，终端服务器根据该第二请求生成第一信息，该第一信息用于指示第一场景的保活信息，终端设备根据该第一信息确定是否保活第一场景，进而实现根据用户需求对第一场景的灵活保活。
附图说明
此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。
图1为本申请提供的应用场景示意图；
图2为本申请一实施例提供的客户端保活方法的流程示意图；
图3为本申请一实施例提供的客户端保活方法的流程示意图；
图4为本申请一实施例提供的客户端保活方法的流程示意图；
图5为本申请一实施例提供的客户端保活方法的一种流程示意图；
图6为本申请实施例提供的客户端的保活装置的一种结构示意图；
图7为本申请实施例提供的客户端的保活装置的一种结构示意图；
图8为本申请实施例提供的客户端的保活装置的一种结构示意图；
图9为本申请实施例提供的客户端的保活装置的一种结构示意图；
图10为本申请实施例涉及的电子设备的框图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。
应理解，在本发明实施例中，“与A对应的B”表示B与A相关联。在一种实现方式中，可以根据A确定B。但还应理解，根据A确定B并不意味着仅仅根据A确定B，还可以根据A和/或其它信息确定B。
在本申请的描述中，除非另有说明，“多个”是指两个或多于两个。
另外，为了便于清楚描述本申请实施例的技术方案，在本申请的实施例中，采用了“第一”、“第二”等字样对功能和作用基本相同的相同项或相似项进行区分。本领域技术人员可以理解“第一”、“第二”等字样并不对数量和执行次序进行限定，并且“第一”、“第二”等字样也并不限定一定不同。
本申请实施例涉及物联网技术领域，具体涉及一种客户端的保活方法、装置、系统。
图1为本申请提供的应用场景示意图，如图1包括：客户端、终端设备、客户端服务器和终端服务器。
其中，客户端(Client)或称为用户端，是指与服务器相对应，为客户提供本地服务的程序。客户端可以理解为应用(APP)，该客户端安装在终端设备上，并在终端设备上运行。本申请所指的客户端可以理解为任意类型的客户端，例如音乐类的、游戏类、购物类、视频类等。
客户端服务器与客户端通信连接，负责管理与客户端相关的数据。
终端设备又称为智能终端或移动智能终端，是指一类具备丰富人机交互方式、拥有接入互联网能力、通常搭载各种操作系统、具有较强处理能力的设备。终端设备包括智能手机、平板电脑、车载终端、掌上游戏主机等。
终端服务器(Terminal Servers)通常用在局域网(LAN)上将很多终端设备连接到主机系统或小型计算机系统。终端设备是通过串行端口连接到终端服务器。终端服务器基本上是一个异步多路复用器，将终端设备、调制解调器、打印机和其它外设连接到主机系统。
图1中客户端安装在终端设备上，可以与终端设备和客户端服务器进行通信，终端设备与终端服务器之间可以通信。
终端设备的资源包括终端设备的CPU、内存、GPU和网络等资源。
下面通过一些实施例对本申请实施例的技术方案进行详细说明。下面这几个实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例不再赘述。
图2为本申请一实施例提供的客户端保活方法的流程示意图，如图2所示，包括：
S201、客户端在客户端切换至后台时，获得当前时刻客户端所处的第一场景的场景信息。
客户端在终端设备的前台运行的过程中，由于某些原因导致客户端从终端设备的前台切换至后台运行，导致客户端从终端设备的前台切换至后台运行的场景通常分为被动切换至后台的场景和主动切换至后台的场景。
其中，被动切换至后台的场景：在客户端运行过程中，用户因为要临时处理其他事情，比如接听电话，回复消息等，需要临时把客户端切换到后台，一般用户都会再次回到该客户端的当前界面中。
主动切换至后台的场景：这类场景一般是客户端运行过程出现了短暂的中断，例如有限客户端中角色死亡，等待队友一起进入下一局等。
一个客户端包括多个不同的场景，本申请为每个场景设置一个唯一的标识，例如场景ID，用于唯一标识各场景。
由于终端设备的资源有限，当客户端切换至后台后，终端设备保活一小段时间后会结束该客户端。因此，客户端在检测到切换至后台时，获取当前时刻客户端所处的第一场景的场景信息，使得终端设备在后台保活客户端的第一场景，以便用户将客户端从后台切换至前台时，客户端直接进入第一场景，而无需重新加载，以提高用户的使用体验。
本申请的第一场景的场景信息包括：客户端的标识(例如客户端端的ID)、第一场景的标识(例如场景的ID)，以及第一场景的场景类型，其中第一场景的场景类型包括：被动切换至后台和主动切换至后台。
S202、客户端向客户端服务器发送第一请求，第一请求包括第一场景的场景信息。
客户端根据上述步骤获得客户端的第一场景的场景信息后，将该第一场景的场景信息携带在第一请求中发送给客户端服务器，该第一请求用于请求第一场景可保活的第一保活时长。
S203、客户端服务器根据第一场景的场景信息，确定第一场景对应的第一保活时长。
在一些实施例中，客户端服务器接收到客户端发送的第一请求后，根据该第一请求所携带的第一场景的场景信息，确定第一场景对应的第一保活时长。
在一些实施例中，客户端包括多个场景，为了节约终端设备的资源对客户端的一些场景允许保活，对客户端的一些场景不允许保活，具体根据时间需要进行设定，本申请对此不做限制。本申请的客户端服务器中包括该客户端的至少一个预设的可保活场景的标识信息，这样客户端服务器获得客户端发送的第一请求后，解析该第一请求，获得该第一请求携带的第一场景的场景信息。由上述可知该第一场景的场景信息包括第一场景的标识信息，这样客户端服务器将第一场景的标识信息与预设的可保活场景的标识信息进行匹配，判断该第一场景是否属于预设的可保活场景。若确定该第一场景不是可保活场景，则向客户端反馈保活失败的信息，整个保活过程结束。若确定该第一场景属于可保活场景，则根据第一场景的场景信息，确定第一场景对应的第一保活时长。
上述S203中客户端服务器根据第一场景的场景信息，确定第一场景对应的第一保活时长的方式包括但不限于如下几种：
方式一，上述S203包括如下S203-A1和S203-A2的步骤：
S203-A1、客户端服务器根据第一场景的场景信息，确定第一场景的类型；
S203-A2、客户端服务器根据第一场景的类型，确定第一场景对应的第一保活时长。
由上述可知，第一场景的场景信息包括第一场景的类型，这样客户端可以解析第一场景的场景信息，获得第一场景的类型，进而根据第一场景的类型确定第一场景对应的保活时长。
在一种示例中，若第一场景的类型为被动切换至后台，则客户端服务器确定当前时刻导致客户端切换至后台的用户行为，用户行为例如为用户接听电话或用户回复消息。接着，获取该用户行为的历史数据，并根据该用户行为的历史数据中用户执行该用户行为所花费的时长，确定第一场景对应的第一保活时长。例如，导致客户端切换至后台的用户行为为接听电话，这样客户端服务器可以获得预设的历史时间段内用户每次接听电话的通话时长，并根据每次接听电话的通话时长，确定第一场景对应的第一保活时长，例如将历史时间段内用户每次接听电话的通话时长的平均值作为第一场景对应的第一保活时长。例如，导致客户端切换至后台的用户行为为回复消息，这样客户端服务器可以获得预设的历史时间段内用户每次回复消息所花费的时长，并根据用户每次回复消息所花费的时长，确定第一场景对应的第一保活时长，例如将历史时间段内用户每次回复消息所花费的时长的平均值作为第一场景对应的第一保活时长。
在一种示例中，若第一场景的类型为主动切换至后台，则客户端服务器获取客户端从第一场景进入第一场景的下一个场景之间的时间间隔，根据客户端从第一场景进入第一场景的下一个场景之间的时间间隔，确定第一场景对应的第一保活时长，例如将客户端从第一场景进入第一场景的下一个场景之间的时间间隔作为第一场景对应的第一保活时长。
在一些实施例中，若第一场景的类型为主动切换至后台，但是客户端从第一场景进入第一场景的下一个场景之间的时间间隔未知时，客户端服务器可以将预设的保活时长确定为该第一场景对应的第一保活时长。其中预设的保活时长较短，这样在后续保活过程中，当预设的保活时长到达时，客户端的下一个场景依然未开始，则客户端可以参照上述方式继续发送保活请求。
可选的，若上述客户端为游戏客户端，则第一场景包括角色死亡或等待队友进入下一局。
上述方式一可以理解为客户端根据第一场景的场景信息实时计算第一场景对应的第一保活时长。下面方式二可以理解为客户端根据事先计算好的保活时长来查询第一场景所对应的第一保活时长。
方式二，客户端服务器包括第一预设对应关系，该第一预设对应关系包括客户端的多个可保活的第二预设场景所对应的保活时长，此时上述S203包括如下S203-B1和S203-B2：
S203-B1、客户端服务器根据第一场景的场景信息，确定第一场景是否为第二预设场景；
S203-B2、若确定所述第一场景为第二预设场景，则客户端服务器从第一预设对应关系中查询到第一场景对应的第一保活时长。
本申请的客户端服务器中包括第一预设对应关系，该第一预设对应关系包括客户端的多个可保活的第二预设场景所对应的保活时长，以及第二预设场景的标识信息、保活类型信息等。
在一种示例中，第一预设对应关系表1所示：
表1
Figure BDA0002934779110000131
需要说明的是，上述表1只是一种示例，表1中的各数值均是一种示例，不对本申请构成限定。其中，客户端的标识、第二预设场景的标识和保活时长的字段类型均为整数类型，第二预设场景的类型和保活类型的字段类型为枚举类型。
客户端服务器可以基于上述表1，根据第一场景的场景信息，首先判断该第一场景是否为表1中的第二预设场景。若判断该第一场景为上述表1中的第二预设场景，则从表1中查询该第一场景对应的第一保活时长，例如第一场为表1中的场景2，该场景2对应的保活时长为B秒，则将B秒作为第一场景对应的第一保活时长。
客户端服务器根据上述步骤确定出第一场景对应的第一保活时长时，执行如下S204。
S204、客户端服务器将第一场景对应的第一保活时长发送给客户端。
S205、客户端向终端设备发送第二请求，第二请求包括第一场景的场景信息和第一场景对应的第一保活时长。
上述第二请求可以理解为保活请求，用于请求终端设备为第一场景保活第一保活时长。即客户端获得客户端服务器发送的第一场景对应的第一保活时长后，结合自身获得的第一场景的场景信息生成第二请求。
在一些实施例中，第二请求所包括的信息格式如表2所示：
表2
Figure BDA0002934779110000141
需要说明的是，上述表2为第二请求所携带的信息的格式，在实际使用时，根据第一场景的具体信息对上述表2进行修改携带待第二请求中，具体是，将表2中场景的标识修改为第一场景的标识，将表2中的场景的类型修改为第一场景的类型，例如第一场景的类型为被动切换至后台，则第一场景的类型一栏里面填写1，若第一场景的类型为主动切换至后台，则第一场景的类型一栏里面填写2。将表2中的保活类型修改为第一场景对应的保活类型，例如第一场景对应的保活类型为固定时长保活，则保活类型一栏里面填写1，若第一场景对应的保活类型为非固定时长保活，则保活类型一栏里面填写2。将表2中保活时长一栏中修改为第一场景对应的第一保活时长的值。
客户端将第二请求发送给终端设备，终端设备执行如下S206。
S206、终端设备将第二请求发送给终端服务器。
在一些实施例中，终端设备获得客户端发送的第二请求后，会对第二请求进行解析与检查，检查该第二请求的数据格式是否满足协议要求，例如检测各字段的字段类型、保活类型、场景类型等是否满足上述表2的要求。若检测第二请求的数据格式正确时，将该第二请求发送给终端服务器。若检测第二请求的数据格式不正确时，向客户端反馈第二请求不满足要求的信息，使得客户端重新发送第二请求。
S207、终端服务器根据第二请求中第一场景的场景信息和第一场景对应的第一保活时长中的至少一个，确定第一场景是否合法。
上述S207中终端服务器确定第一场景是否合法的实现方式包括但不限于如下几种：
方式一，终端服务器在确定第一场景对应的第一保活时长大于第一预设时长时，确定第一场景不合法。由于终端设备的资源有限，终端设备无法长时间保活客户端，当客户端要求保活的第一保活时长大于第一预设时长时，说明该客户端为恶意客户端，进而确定该第一场景为非法场景，对该类非法场景不进行保活。
方式二，上述S207包括如下S207-A1和S207-A2：
S207-A1、终端服务器根据第一场景的场景信息，获得历史时刻该客户端对应的历史保活请求信息；
S207-A2、终端服务器根据该客户端对应的历史保活请求信息，确定第一场景是否合法。
恶意请求的特征为：请求客户端的大部分(例如60％以上)场景进行保活，或者每次请求保活的时间久，例如超过10分钟。需要说明的是，上述60％和10分钟均是一种示例，具体根据实际需要确定。
基于此，终端服务器根据不同终端设备上报的关于该客户端的历史保活请求信息，进行大数据分析判断第一场景是否合法。
在一种示例中，终端服务器根据该客户端对应的历史保活请求信息中所请求保活的场景信息，确定客户端在历史时间内所请求保活的场景数量大于第一预设值，则确定第一场景不合法。
在一种示例中，终端服务器根据历史保活请求信息中所请求的保活时长信息，确定客户端中超过第二预设值个场景所请求的保活时长大于第二预设时长(例如10分钟)，则确定第一场景不合法。
在一种示例中，终端服务器根据历史保活请求信息中所请求保活的场景信息，确定客户端在历史时间内所请求保活的场景数量大于第一预设值，且根据历史保活请求信息中所请求的保活时长信息，确定客户端中超过第二预设值个场景所请求的保活时长大于第二预设时长，则确定第一场景不合法。
终端服务器在确定第一场景不合法时，向终端设备发送保活失败的信息，以上终端设备将保活失败的信息发送给客户端。
本申请在确定第一场景不合法时，则同时确定该客户端也不合法，并在终端服务器中保存该不合法的客户端的标识信息。
终端服务器在确定第一场景合法时，执行如下S208的步骤。
S208、终端服务器在确定第一场景合法时，向终端设备发送第一信息，第一信息用于指示第一场景的保活信息。
例如，终端服务器获取保活策略，该保活策略包括客户端的多个可保活的第一预设场景所对应的可保活条件；根据保活策略，生成第一信息。
在一种示例中，保活策略所包括的信息如表3所示：
表3
场景 CPU GPU 网络 IO负载 内存
场景1 A1 C1 D1 E1 F1
场景2 A2 C2 D2 E2 F2
… … … … … …
上述表3示出了各第一预设场景所对应的可保活条件，该可保活条件为终端设备保活该第一场景时所需的最小资源，例如终端设备包括场景1时所需的CPU资源最小为A1，所需的GPU资源最小为C1，所需的网络资源最小为D1，所需的IO负载资源最小为E1，所需的内存资源最小为F1。
在一些实施例中，保活策略还可以包括第一预设场景的场景标识、场景类型、保活类型和保活时间等信息。以保活策略中的一个第一预设场景为例，该第一预设场景的信息如表4所示：
表4
Figure BDA0002934779110000171
Figure BDA0002934779110000181
上述表4示出了保活策略中一个可保活的第一预设场景对应的信息，其他第一预设场景对应的信息与上述表4一致，将上述表4中的相关参数替换为目标第一预设场景的信息即可。
本申请的终端服务器在确定第一场景合法时，根据上述表3或表4所示的信息，生成第一信息，并将生成的第一信息发给终端设备，该第一信息用于指示第一场景的保活信息。
S209、终端设备根据第一信息，确定是否对第一场景进行保活。
终端设备根据用户的请求并结合终端设备当前的资源情况，确定是否对第一场景进行保活，进而提高了客户端保活的可靠性和灵活性。具体的可以参照如下实施例的描述，在此不再赘述。
本申请实施例提供的客户端的保活方法，客户端在切换至后台时，向客户端服务器发送第一请求，客户端服务器根据第一请求为客户端所处的第一场景确定第一保活时长。客户端将第一场景的场景信息和第一保活时长携带在第二请求中发送给终端设备，以请求终端设备保活第一场景。终端设备将该第二请求发送给终端服务器，终端服务器根据该第二请求生成第一信息，该第一信息用于指示第一场景的保活信息，终端设备根据该第一信息确定是否保活第一场景，进而实现根据用户需求对第一场景的灵活保活，从而提高用户的用户体验。
在一些实施例中，在上述S201之前，如图3所示，本申请实施例的方法还包括：
S200-1、客户端向终端设备发送第三请求，该第三请求用于查询终端设备是否具有保活功能，第三请求包括客户端的标识信息。
S200-2、终端设备在终端设备具有保活功能时，向终端服务器发送第三请求。
本申请客户端向终端设备申请对第一场景进行保活时，首先需要确定该终端设备是否支持本申请的技术方案，即确定终端设备是否具有保活功能。具体是，客户端向终端设备发送第三请求，终端设备接收到该第三请求后，若自身具有保活功能则将该第三请求发送给终端服务器；若终端设备部具有保活功能时，终端设备向客户端返回保活失败的信息。
S200-3、终端服务器根据客户端的标识信息，检查客户端是否为合法客户端。
终端服务器中保存有非法客户端的标识信息，将该第三请求中携带的客户端的标识信息与非法客户端的标识信息进行匹配，检查该客户端是否为合法客户端。若该客户端的标识信息与终端服务器中保存的非法客户端的标识信息匹配，则确定该客户端为非合法客户端，终端服务器向终端设备返回保活失败的信息。若该客户端的标识信息与终端服务器中保存的非法客户端的标识信息不匹配，则确定该客户端为合法客户端，终端服务器执行如下S200-4。
S200-4、终端服务器在检查客户端是合法客户端时，向终端设备发送第一响应，第一响应用于指示客户端为合法客户端。
S200-5、终端设备根据第一响应，向客户端发送第二响应，第二响应用于指示终端设备具有保活功能。
客户端在接收到第二响应后，与终端设备建立通讯链接，开始执行上述S201至S209的保活请求步骤。
本申请中基于保活策略确定是否对第一场景进行保活的执行主体可以是终端设备，也可以是终端服务器。
下面结合图4，以终端设备基于保活策略确定是否对第一场景进行保活的过程进行详细描述。
图4为本申请一实施例提供的客户端保活方法的流程示意图，如图4所示，包括：
S401、客户端在客户端切换至后台时，获得当前时刻客户端所处的第一场景的场景信息。
S402、客户端向客户端服务器发送第一请求，第一请求包括第一场景的场景信息。
S403、客户端服务器根据第一场景的场景信息，确定第一场景对应的第一保活时长。
S404、客户端服务器将第一场景对应的第一保活时长发送给客户端。
S405、客户端向终端设备发送第二请求，第二请求包括第一场景的场景信息和第一场景对应的第一保活时长。
S406、终端设备将第二请求发送给终端服务器。
S407、终端服务器根据第一场景的场景信息和第一场景对应的第一保活时长中的至少一个，确定第一场景是否合法。
上述S401至S407的实现过程与上述S201至S207的实现过程一致，参照上述S202至S207的具体描述，在此不再赘述。
S408、终端服务器在确定第一场景合法时，将保活策略发送给终端设备。
本步骤可以理解为上述S208的一种具体的实现方式，在该实现方式中，终端服务器将保活策略携带在第一信息中发送给终端设备。
其中保活策略如表3或表4所示，包括该客户端的多个可保活的第一预设场景所对应的可保活条件。
S409、终端设备根据第一场景的场景信息和客户端的多个可保活的第一预设场景所对应的可保活条件，确定是否对第一场景进行保活。
具体的，终端设备根据第一场景的场景信息，获得保活策略中与第一场景的场景信息匹配的第一预设场景，进而根据该第一预设场景对应的可保活条件，确定是否对第一场景进行保活。例如，当前时刻终端设备满足该第一预设场景对应的可保活条件时，确定对该第一场景进行保活，若当前时刻终端设备不满足该第一预设场景对应的可保活条件时，确定对该第一场景不进行保活。
在一些实施例中，如表3或表4所示，第一预设场景所对应的可保活条件包括保活第一预设场景时终端设备所需的资源值，此时，上述S409包括如下S409-A1至S409-A3：
S409-A1、终端设备根据第一场景的场景信息，确定第一场景是否为第一预设场景；
S409-A2、终端设备若确定第一场景为第一预设场景，则获取当时时刻终端设备的空闲资源值；
S409-A3、终端设备根据终端设备的空闲资源值和保活第一场景时终端设备所需的资源值，确定是否对第一场景进行保活。
具体的，将第一场景的场景信息与保活策略中各第一预设场景的标识信息进行匹配，判断第一场景是否为保活策略中各第一预设场景中的一个第一预设场景。若确定第一场景为第一预设场景，则将保活策略中该第一预设场景对应的资源值确定为保活第一场景时终端设备所需的最小资源。
在一种示例中，在保活第一场景时终端设备所需的资源值小于预设资源值，且终端设备的空闲资源值大于或等于预测资源值时，确定对第一场景进行保活。其中，该预测资源值为终端设备预测的在下一时刻终端设备运行前端程序所需的最小资源值，预测过程为已有技术，在此不再赘述。
在一种示例中，在保活第一场景时终端设备所需的资源值大于或等于预设资源值时，确定对第一场景不进行保活，即保活客户端的第一场景所占用的资源太大，则不对该第一场景进行保活。
在一种示例中，在终端设备的空闲资源值小于预测资源值时，确定对第一场景不进行保活，即当前时刻终端设备的资源紧张，不对第一场景进行保活。
在一些实施例中，终端设备实时检查自身的空闲资源，在终端设备保活第一场景的情况下，终端设备检测到下一时刻终端设备的空闲资源值小于预测资源值时，在下一时刻停止保活第一场景，该预测资源值可以理解为终端设备预测的在下一时刻的下一时刻终端设备运行前端程序所需的最小资源值。
在一些实施例中，在终端设备保活第一场景的情况下，终端设备检测到第一场景对应的第一保活时长到达时，停止保活第一场景。
在一些实施例中，本申请还包括如下步骤：
S410、终端设备将第一场景是否被保活的保活结果发送给客户端。
S411、客户端将第一场景是否被保活的保活结果发送给客户端服务器。
在一些实施例中，终端设备向客户端发送的保活结果如表5所示：
表5
Figure BDA0002934779110000211
Figure BDA0002934779110000221
如表5所示，若终端设备确定保活第一场景时，则保活结果为0，即按照客户端的要求对第一场景进行保活。若终端设备确定当前终端设备的空闲资源值小于预测资源值，则保活结果为1，即表示终端设备当前资源紧张，无法对第一场景进行保活。若终端服务器确定该客户端为非法客户端时，则保活结果为2，表示该客户端下发过多恶意保活请求，不予保活第一场景。
客户端服务器获得表5后，若第一场景不予保活的原因为客户端下发过多恶意保活请求，不予保活时，此时客户端服务器更新自身保存的允许保活的场景信息，将该第一场景更新为不允许保活的场景。这样在后续客户端向客户端服务器发送第一请求时，客户端服务器向客户端返回保活失败的信息，进而提高了保活的准确性，避免浪费资源。
在一些实施例中，如果终端设备资源紧张，无法对客户端的第一场景进行保活，则终端设备可以将保存客户端的当前运行状态到本地存储，当用户重新进入客户端时，可以加载终端设备保存的客户端的当前运行状态，避免让用户全部重新操作一遍，也可以在一定程度上提升用户的体验。
在一些实施例中，终端设备保活客户端的第一场景时，客户端在检查到客户端进入第一场景的下一个场景时，向用户发送通知消息，该通知消息用于通知用户返回客户端。
在一些实施例中，终端设备保活客户端的第一场景，且第一场景的类型为主动切换后台，一个保活周期结束后，即第一场景对应的第一保活时长到达时，客户端检查到客户端未进入第一场景的下一个场景，此时客户端向客户端服务器重新发送第一请求，继续执行上述保活步骤，请求终端设备继续为该第一场景进行保活。
本申请通过对客户端的场景进行细分，使得终端设备可以结合终端设备的空闲资源和用户的保活需求，对第一场景进行保活或结束第一场景以节省终端设备的资源，进而平衡用户的使用体验和终端设备的资源紧张的矛盾。另外，本申请中终端设备根据终端设备的空闲资源值以及保活第一场景时终端设备所需的资源值，确定是否对第一场景进行保活，整个保活过程交互次数少，进而提高了保活效率。
下面结合图5，以终端服务器基于保活策略确定是否对第一场景进行保活的过程进行详细描述。
图5为本申请一实施例提供的客户端保活方法的一种流程示意图，如图5所示，包括：
S501、客户端在客户端切换至后台时，获得当前时刻客户端所处的第一场景的场景信息。
S502、客户端向客户端服务器发送第一请求，第一请求包括第一场景的场景信息。
S503、客户端服务器根据第一场景的场景信息，确定第一场景对应的第一保活时长。
S504、客户端服务器将第一场景对应的第一保活时长发送给客户端。
S505、客户端向终端设备发送第二请求，第二请求包括第一场景的场景信息和第一场景对应的第一保活时长。
S506、终端设备将第二请求发送给终端服务器。
S507、终端服务器根据第一场景的场景信息和第一场景对应的第一保活时长中的至少一个，确定第一场景是否合法。
上述S401至S407的实现过程与上述S201至S207的实现过程一致，参照上述S202至S207的具体描述，在此不再赘述。
S508、终端服务器在确定第一场景合法时，根据第一场景的场景信息和保活策略中客户端的多个可保活的第一预设场景所对应的可保活条件，确定第一场景的保活结果。
本步骤可以理解为上述S208的一种具体的实现方式，在该实现方式中，终端服务器根据保活策略和第一场景的场景信息确定第一场景的保活结果。
在一些实施例中，如表3或表4所示，第一预设场景所对应的可保活条件包括保活第一预设场景时终端设备所需的资源值，此时，上述S508包括如下S508-A1至S508-A3：
S508-A1、终端服务器根据第一场景的场景信息，确定第一场景是否为第一预设场景；
S508-A2、终端服务器若确定第一场景为第一预设场景，则获取当时时刻终端设备的空闲资源值；
S508-A3、终端服务器根据终端设备的空闲资源值和保活第一场景时终端设备所需的资源值，确定第一场景的保活结果。
上述S508-A1至S508-A3的实现过程与上述S409-A1至S409-A3的实现过程一致，参照上述S409-A1至S409-A3的具体描述，在此不再赘述。
在一些实施例中，上述S508-A3包括：在保活第一场景时终端设备所需的资源值小于预设资源值，且终端设备的空闲资源值大于或等于预测资源值时，确定第一场景的保活结果为保活，其中预测资源值为终端设备预测的在下一时刻终端设备运行前端程序所需的最小资源值；或者，在保活第一场景时终端设备所需的资源值大于或等于预设资源值时，确定第一场景的保活结果为不保活；或者，在终端设备的空闲资源值小于预测资源值时，确定第一场景的保活结果为不保活。
S509、终端服务器将第一场景的保活结果发送给终端设备。
S510、终端设备根据第一场景的保活结果，确定是否对第一场景进行保活。
本申请中确定第一场景是否保活的过程由终端服务器实现，终端设备根据终端服务器确定的保活结果，执行是否对第一场景进行保活。例如，若第一场景的保活结果为保活时，则确定对第一场景进行保活；若第一场景的保活结果为不保活时，则确定不对第一场景进行保活。
在一些实施例中，终端服务器在终端设备保活第一场景的情况下，检测到下一时刻终端设备的空闲资源值小于预测资源值时，向终端设备发送第一停止保活指示，该第一停止保活指示用于指示终端设备停止保活第一场景。终端设备根据第一停止保活指示停止保活第一场景。
在一些实施例中，终端服务器在终端设备保活第一场景的情况下，检测到第一场景对应的第一保活时长到达时，向终端设备发送第二停止保活指示，该第一停止保活指示用于指示终端设备停止保活第一场景。终端设备根据第二停止保活指示停止保活第一场景。
在一些实施例中，本申请还包括如下步骤：
S511、终端设备将第一场景是否被保活的保活结果发送给客户端。
S512、客户端将第一场景是否被保活的保活结果发送给客户端服务器。
上述S508至S512的实现过程与上述S409至S411的实现过程具有相同之处，参照上述S409至S411的具体描述，在此不再赘述。
本申请通过对客户端的场景进行细分，使得终端设备服务器可以结合终端设备的空闲资源和用户的保活需求，确定是对第一场景进行保活或结束第一场景以节省终端设备的资源，进而平衡用户的使用体验和终端设备的资源紧张的矛盾。另外，本申请中终端服务器根据终端设备的空闲资源值以及保活第一场景时终端设备所需的资源值，确定是否对第一场景进行保活的保活结果，终端设备根据第一场景的保活结果来确定是否对第一场景进行保活，降低了终端设备的工作量，进而节约了终端设备的资源，进而提高了终端设备保活第一场景的可能性。
应理解，图2至图5仅为本申请的示例，不应理解为对本申请的限制。
以上结合附图详细描述了本申请的优选实施方式，但是，本申请并不限于上述实施方式中的具体细节，在本申请的技术构思范围内，可以对本申请的技术方案进行多种简单变型，这些简单变型均属于本申请的保护范围。例如，在上述具体实施方式中所描述的各个具体技术特征，在不矛盾的情况下，可以通过任何合适的方式进行组合，为了避免不必要的重复，本申请对各种可能的组合方式不再另行说明。又例如，本申请的各种不同的实施方式之间也可以进行任意组合，只要其不违背本申请的思想，其同样应当视为本申请所公开的内容。
上文结合图2至图5，详细描述了本申请的方法实施例，下文结合图6至图10，详细描述本申请的装置实施例。
图6为本申请实施例提供的客户端的保活装置的一种结构示意图。该客户端的保活装置100应用于终端设备，该客户端保活装置100可以为终端设备，或者为终端设备的部件，如图6所示，客户端的保活装置100可以包括：
接收单元110，用于接收客户端切换至后台时所发送的第二请求，所述第二请求包括当前时刻所述客户端所处的第一场景的场景信息以及所述第一场景对应的第一保活时长；
发送单元120，用于将所述第二请求发送给终端服务器；
接收单元110，还用于接收所述终端服务器根据所述第二请求确定的第一信息，所述第一信息用于指示所述第一场景的保活信息；
处理单元130，用于根据所述第一信息，确定是否对所述第一场景进行保活。
在一些实施例中，所述第一信息包括保活策略，所述保活策略包括所述客户端的多个可保活的第一预设场景所对应的可保活条件；上述处理单元130，具体用于根据所述第一场景的场景信息和所述客户端的多个可保活的第一预设场景所对应的可保活条件，确定是否对所述第一场景进行保活。
在一些实施例中，所述第一预设场景所对应的可保活条件包括保活所述第一预设场景时所述终端设备所需的资源值，上述处理单元130，具体用于根据所述第一场景的场景信息，确定所述第一场景是否为所述第一预设场景；若确定所述第一场景为所述第一预设场景，则获取当时时刻所述终端设备的空闲资源值；根据所述终端设备的空闲资源值和保活所述第一场景时所述终端设备所需的资源值，确定是否对所述第一场景进行保活。
在一些实施例中，上述处理单元130，具体用于在保活所述第一场景时所述终端设备所需的资源值小于预设资源值，且所述终端设备的空闲资源值大于或等于预测资源值时，确定对所述第一场景进行保活，所述预测资源值为所述终端设备预测的在下一时刻所述终端设备运行前端程序所需的最小资源值；或者，在保活所述第一场景时所述终端设备所需的资源值大于或等于所述预设资源值时，确定对所述第一场景不进行保活；或者，在所述终端设备的空闲资源值小于预测资源值时，确定对所述第一场景不进行保活。
在一些实施例中，处理单元130，还用于在所述终端设备保活所述第一场景的情况下，检测到下一时刻所述终端设备的空闲资源值小于预测资源值时，停止保活所述第一场景。
在一些实施例中，处理单元130，还用于在所述终端设备保活所述第一场景的情况下，检测到所述第一场景对应的第一保活时长到达时，停止保活所述第一场景。
在一些实施例中，所述第一信息包括所述第一场景的保活结果，处理单元130，还用于若所述第一场景的保活结果为保活时，则确定对所述第一场景进行保活；若所述第一场景的保活结果为不保活时，则确定不对所述第一场景进行保活。
在一些实施例中，接收单元110，还用于接收所述终端服务器发送的第一停止保活指示，并根据所述第一停止保活指示停止保活所述第一场景，该第一停止保活指示是终端服务器在检测到下一时刻所述终端设备的空闲资源值小于所述预测资源值时发送的。
在一些实施例中，接收单元110，还用于接收所述终端服务器发送的第二停止保活指示，并根据所述第二停止保活指示停止保活所述第一场景，该第二停止保活指示是终端服务器检测到所述第一场景对应的第一保活时长到达时发送的。
在一些实施例中，接收单元110，还用于在接收来自于客户端的第二请求之前，接收来自所述客户端的第三请求，所述第三请求用于查询所述终端设备是否具有保活功能，所述第三请求包括所述客户端的标识信息；
发送单元120，还用于在所述终端设备具有所述保活功能时，向所述终端服务器发送所述第三请求；
接收单元110，还用于接收来自所述终端服务器根据所述第三请求发送的第一响应，所述第一响应用于指示所述客户端为合法客户端；
发送单元120，还用于根据所述第一响应，向所述客户端发送第二响应，所述第二响应用于指示所述终端设备具有保活功能。
在一些实施例中，发送单元120，还用于将所述第一场景是否被保活的保活结果发送给所述客户端。
应理解，装置实施例与方法实施例可以相互对应，类似的描述可以参照方法实施例。为避免重复，此处不再赘述。具体地，图6所示的客户端的保活装置100可以执行本申请实施例的方法，并且客户端的保活装置100中的各个单元的前述和其它操作和/或功能分别为了实现各个方法中的相应流程，为了简洁，在此不再赘述。
图7为本申请实施例提供的客户端的保活装置的一种结构示意图。该客户端的保活装置200应用于终端服务器，该客户端保活装置200可以为终端服务器，或者为终端服务器的部件，如图7所示，客户端的保活装置200可以包括：
接收单元210，用于接收来自所述终端设备发送的第二请求，所述第二请求包括当前时刻客户端所处的第一场景的场景信息和所述第一场景对应的第一保活时长；
处理单元220，用于根据所述第一场景的场景信息和所述第一场景对应的第一保活时长中的至少一个，确定所述第一场景是否合法；
发送单元230，用于在确定所述第一场景合法时，向所述终端设备发送第一信息，所述第一信息用于指示所述第一场景的保活信息。
在一些实施例中，处理单元220，具体用于在确定所述第一场景对应的第一保活时长大于第一预设时长时，确定所述第一场景不合法。
在一些实施例中，处理单元220，具体用于根据所述第一场景的场景信息，获得历史时刻所述客户端对应的历史保活请求信息；根据所述客户端对应的历史保活请求信息，确定所述第一场景是否合法。
在一些实施例中，处理单元220，具体用于根据所述历史保活请求信息中所请求保活的场景信息，确定所述客户端在历史时间内所请求保活的场景数量大于第一预设值，则确定所述第一场景不合法；或者，根据所述历史保活请求信息中所请求的保活时长信息，确定所述客户端中超过第二预设值个场景所请求的保活时长大于第二预设时长，则确定所述第一场景不合法。
在一些实施例中，处理单元220，还用于获取保活策略，所述保活策略包括所述客户端的多个可保活的第一预设场景所对应的可保活条件；根据所述保活策略，生成第一信息。
在一些实施例中，所述第一信息包括保活策略。
在一些实施例中，所述第一信息包括所述第一场景的保活结果，处理单元220，具体用于根据所述第一场景的场景信息和保活策略中所述客户端的多个可保活的第一预设场景所对应的可保活条件，确定所述第一场景的保活结果。
在一些实施例中，所述第一预设场景所对应的可保活条件包括保活所述第一预设场景时所述终端设备所需的资源值，处理单元220，具体用于根据所述第一场景的场景信息，确定所述第一场景是否为所述第一预设场景；若确定所述第一场景为所述第一预设场景，则获取当时时刻所述终端设备的空闲资源值；根据所述终端设备的空闲资源值和保活所述第一场景时所述终端设备所需的资源值，确定所述第一场景的保活结果。
在一些实施例中，处理单元220，具体用于在保活所述第一场景时所述终端设备所需的资源值小于预设资源值，且所述终端设备的空闲资源值大于或等于预测资源值时，确定所述第一场景的保活结果为保活，所述预测资源值为所述终端设备预测的在下一时刻所述终端设备运行前端程序所需的最小资源值；或者，在保活所述第一场景时所述终端设备所需的资源值大于或等于所述预设资源值时，确定所述第一场景的保活结果为不保活；或者，在所述终端设备的空闲资源值小于预测资源值时，确定所述第一场景的保活结果为不保活。
在一些实施例中，处理单元220，还用于在所述终端设备保活所述第一场景的情况下，检测到下一时刻所述终端设备的空闲资源值小于预测资源值时，控制发送单元230向所述终端设备发送第一停止保活指示。
在一些实施例中，处理单元220，还用于在所述终端设备保活所述第一场景的情况下，检测到所述第一场景对应的第一保活时长到达时，控制发送单元230向所述终端设备发送第二停止保活指示。
在一些实施例中，接收单元210在接收来自所述终端设备发送的第二请求之前，还用于接收来自所述终端设备的第三请求，所述第三请求用于查询所述终端设备是否具有保活功能，所述第三请求包括所述客户端的标识信息；
处理单元220，还用于根据所述客户端的标识信息，检查所述客户端是否为合法客户端；
发送单元230，还用于在检查所述客户端是合法客户端时，向所述终端设备发送第一响应，所述第一响应用于指示所述客户端为合法客户端。
应理解，装置实施例与方法实施例可以相互对应，类似的描述可以参照方法实施例。为避免重复，此处不再赘述。具体地，图7所示的客户端的保活装置200可以执行本申请实施例的方法，并且客户端的保活装置200中的各个单元的前述和其它操作和/或功能分别为了实现各个方法中的相应流程，为了简洁，在此不再赘述。
图8为本申请实施例提供的客户端的保活装置的一种结构示意图。该客户端的保活装置300应用于客户端，该客户端保活装置300可以为客户端，或者为客户端的一部分，如图8所示，客户端的保活装置300可以包括：
处理单元310，用于在所述客户端切换至后台时，获得当前时刻所述客户端所处的第一场景的场景信息；
发送单元320，用于向客户端服务器发送第一请求，所述第一请求包括所述第一场景的场景信息；
接收单元330，用于接收所述客户端服务器发送的所述第一场景对应的第一保活时长；
发送单元320，还用于向终端设备发送第二请求，所述第二请求包括所述第一场景的场景信息和所述第一场景对应的第一保活时长。
在一些实施例中，发送单元320还用于向所述终端设备发送第三请求，所述第三请求用于查询所述终端设备是否具有保活功能，所述第三请求包括所述客户端的标识信息；
接收单元330还用于接收到来自所述终端设备发送的第二响应，所述第二响应用于指示所述终端设备具有保活功能。
在一些实施例中，接收单元330还用于接收所述终端设备发送的所述第一场景是否被保活的保活结果；发送单元320还用于将所述第一场景的保活结果发送给所述客户端服务器。
在一些实施例中，在所述第一场景处于保活状态时，发送单元320还用于在检查到所述客户端进入所述第一场景的下一个场景时，向用户发送通知消息，所述通知消息用于通知所述用户返回所述客户端。
在一些实施例中，在所述第一场景的类型为主动切换后台，发送单元320还用于在检查到所述第一场景对应的第一保活时长到达且所述客户端未进入所述第一场景的下一个场景时，向所述客户端服务器重新发送第一请求。
应理解，装置实施例与方法实施例可以相互对应，类似的描述可以参照方法实施例。为避免重复，此处不再赘述。具体地，图8所示的客户端的保活装置300可以执行本申请实施例的方法，并且客户端的保活装置300中的各个单元的前述和其它操作和/或功能分别为了实现各个方法中的相应流程，为了简洁，在此不再赘述。
图9为本申请实施例提供的客户端的保活装置的一种结构示意图。该客户端的保活装置400应用于客户端服务器，该客户端保活装置400可以为客户端服务器，或者为客户端服务器的部件，如图9所示，客户端的保活装置400可以包括：
接收单元410，用于接收客户端切换至后台时所发送的第一请求，所述第一请求包括当前时刻所述客户端所处的第一场景的场景信息；
处理单元420，用于根据所述第一场景的场景信息，确定所述第一场景对应的第一保活时长；
发送单元430，用于将所述第一场景对应的第一保活时长发送给所述客户端。
在一些实施例中，处理单元420具体用于根据所述第一场景的场景信息，确定所述第一场景的类型；根据所述第一场景的类型，确定所述第一场景对应的第一保活时长。
在一些实施例中，处理单元420具体用于若所述第一场景的类型为被动切换至后台，则确定所述当前时刻导致所述客户端切换至后台的用户行为；获取所述用户行为的历史数据；根据所述历史数据中所述用户执行所述用户行为所花费的时长，确定所述第一场景对应的第一保活时长。
可选的，所述用户行为包括所述用户接听电话或所述用户回复消息。
在一些实施例中，处理单元420具体用于若所述第一场景的类型为主动切换至后台，则获取所述客户端从所述第一场景进入所述第一场景的下一个场景之间的时间间隔；根据所述客户端从所述第一场景进入所述第一场景的下一个场景之间的时间间隔，确定所述第一场景对应的第一保活时长。
在一些实施例中，处理单元420还用于在所述第一场景与所述第一场景的下一个场景之间的时间间隔未知时，将预设的保活时长确定为所述第一场景对应的第一保活时长。
可选的，若所述客户端为游戏客户端，则所述第一场景包括角色死亡或等待队友进入下一局。
在一些实施例中，处理单元420还用于根据所述第一场景的场景信息，确定所述第一场景是否属于预设的可保活场景；确定所述第一场景属于预设的可保活场景时，根据所述第一场景的场景信息，确定所述第一场景对应的第一保活时长。
在一些实施例中，若所述客户端服务器包括第一预设对应关系，所述第一预设对应关系包括所述客户端的多个可保活的第二预设场景所对应的保活时长，则，处理单元420具体用于根据所述第一场景的场景信息，确定所述第一场景是否为所述第二预设场景；若确定所述第一场景为所述第二预设场景，则从所述第一预设对应关系中查询到所述第一场景对应的第一保活时长。
在一些实施例中，接收单元410还用于接收所述客户端发送所述第一场景是否可以保活的保活结果；处理单元420用于根据所述第一场景的保活结果，更新所述客户端服务器所保存的可保活的场景信息。
应理解，装置实施例与方法实施例可以相互对应，类似的描述可以参照方法实施例。为避免重复，此处不再赘述。具体地，图9所示的客户端的保活装置400可以执行本申请实施例的方法，并且客户端的保活装置400中的各个单元的前述和其它操作和/或功能分别为了实现各个方法中的相应流程，为了简洁，在此不再赘述。
图10为本申请实施例涉及的电子设备的框图，该电子设备用于执行上述实施例所述的方法，图10所示的电子设备可以是上述的终端设备、终端服务器或客户端服务器，具体参见上述方法实施例中的说明。
图10所示的电子设备500包括存储器501、处理器502、通信接口503。存储器501、处理器502、通信接口503之间彼此通信连接。例如，存储器501、处理器502、通信接口503之间可以采用网络连接的方式，实现通信连接。或者，上述电子设备500还可以包括总线504。存储器501、处理器502、通信接口503通过总线504实现彼此之间的通信连接。图10是以存储器501、处理器502、通信接口503通过总线504实现彼此之间的通信连接的电子设备500。
存储器501可以是只读存储器(Read Only Memory，ROM)，静态存储设备，动态存储设备或者随机存取存储器(Random Access Memory，RAM)。存储器501可以存储程序，当存储器501中存储的程序被处理器502执行时，处理器502和通信接口503用于执行上述方法。
处理器502可以采用通用的中央处理器(Central Processing Unit，CPU)，微处理器，应用专用集成电路(Application Specific Integrated Circuit，ASIC)，图形处理器(graphics processing unit，GPU)或者一个或多个集成电路。
处理器502还可以是一种集成电路芯片，具有信号的处理能力。在实现过程中，本申请的方法可以通过处理器502中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器502还可以是通用处理器、数字信号处理器(digital signal processing，DSP)、专用集成电路(ASIC)、现成可编程门阵列(field programmable gate array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器501，处理器502读取存储器501中的信息，结合其硬件完成本申请实施例的方法。
通信接口503使用例如但不限于收发器一类的收发模块，来实现电子设备500与其他设备或通信网络之间的通信。例如，可以通过通信接口503获取数据集。
当上述电子设备500包括总线504时，总线504可包括在电子设备500各个部件(例如，存储器501、处理器502、通信接口503)之间传送信息的通路。
根据本申请的一个方面，提供了一种计算机存储介质，其上存储有计算机程序，该计算机程序被计算机执行时使得该计算机能够执行上述方法实施例的方法。或者说，本申请实施例还提供一种包含指令的计算机程序产品，该指令被计算机执行时使得计算机执行上述方法实施例的方法。
根据本申请的另一个方面，提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述方法实施例的方法。
在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘Solid State Disk(SSD))等。
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的模块及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，该模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个模块或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或模块的间接耦合或通信连接，可以是电性，机械或其它的形式。
作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理模块，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。例如，在本申请各个实施例中的各功能模块可以集成在一个处理模块中，也可以是各个模块单独物理存在，也可以两个或两个以上模块集成在一个模块中。
综上内容，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以该权利要求的保护范围为准。

Claims (36)

1.一种客户端的保活方法，其特征在于，应用于终端设备，包括：
接收客户端切换至后台时所发送的第二请求，所述第二请求包括当前时刻所述客户端所处的第一场景的场景信息以及所述第一场景对应的第一保活时长；
将所述第二请求发送给终端服务器；
接收所述终端服务器根据所述第二请求确定的第一信息，所述第一信息用于指示所述第一场景的保活信息；
根据所述第一信息，确定是否对所述第一场景进行保活。
2.根据权利要求1所述的方法，其特征在于，所述第一信息包括保活策略，所述保活策略包括所述客户端的多个可保活的第一预设场景所对应的可保活条件；所述根据所述第一信息，确定是否对所述第一场景进行保活，包括：
根据所述第一场景的场景信息和所述客户端的多个可保活的第一预设场景所对应的可保活条件，确定是否对所述第一场景进行保活。
3.根据权利要求2所述的方法，其特征在于，所述第一预设场景所对应的可保活条件包括保活所述第一预设场景时所述终端设备所需的资源值，所述根据所述第一场景的场景信息和所述客户端的多个可保活的第一预设场景所对应的可保活条件，确定是否对所述第一场景进行保活，包括：
根据所述第一场景的场景信息，确定所述第一场景是否为所述第一预设场景；
若确定所述第一场景为所述第一预设场景，则获取当时时刻所述终端设备的空闲资源值；
根据所述终端设备的空闲资源值和保活所述第一场景时所述终端设备所需的资源值，确定是否对所述第一场景进行保活。
4.根据权利要求3所述的方法，其特征在于，所述根据所述终端设备的空闲资源值和保活所述第一场景时所述终端设备所需的资源值，确定是否对所述第一场景进行保活，包括：
在保活所述第一场景时所述终端设备所需的资源值小于预设资源值，且所述终端设备的空闲资源值大于或等于预测资源值时，确定对所述第一场景进行保活，所述预测资源值为所述终端设备预测的在下一时刻所述终端设备运行前端程序所需的最小资源值；或者，
在保活所述第一场景时所述终端设备所需的资源值大于或等于所述预设资源值时，确定对所述第一场景不进行保活；或者，
在所述终端设备的空闲资源值小于预测资源值时，确定对所述第一场景不进行保活。
5.根据权利要求4所述的方法，其特征在于，所述方法还包括：
在所述终端设备保活所述第一场景的情况下，检测到下一时刻所述终端设备的空闲资源值小于所述预测资源值时，停止保活所述第一场景；或者
在所述终端设备保活所述第一场景的情况下，检测到所述第一场景对应的第一保活时长到达时，停止保活所述第一场景。
6.根据权利要求1所述的方法，其特征在于，所述第一信息包括所述第一场景的保活结果，所述保活结果由所述终端服务器计算得到，所述根据所述第一信息，确定是否对所述第一场景进行保活，包括：
若所述第一场景的保活结果为保活时，则确定对所述第一场景进行保活；
若所述第一场景的保活结果为不保活时，则确定不对所述第一场景进行保活。
7.根据权利要求6所述的方法，其特征在于，在所述第一场景处于保活状态下，所述方法还包括：
接收所述终端服务器发送的第一停止保活指示，并根据所述第一停止保活指示停止保活所述第一场景，所述第一停止保活指示是所述终端服务器检测到下一时刻所述终端设备的空闲资源值小于预测资源值时发送的；或者
接收所述终端服务器发送的第二停止保活指示，并根据所述第二停止保活指示停止保活所述第一场景，所述第一停止保活指示是所述终端服务器检测到所述第一场景对应的第一保活时长到达时发送的。
8.根据权利要求1所述的方法，其特征在于，所述接收来自于客户端的第二请求之前，所述方法还包括：
接收来自所述客户端的第三请求，所述第三请求用于查询所述终端设备是否具有保活功能，所述第三请求包括所述客户端的标识信息；
在所述终端设备具有所述保活功能时，向所述终端服务器发送所述第三请求；
接收来自所述终端服务器根据所述第三请求发送的第一响应，所述第一响应用于指示所述客户端为合法客户端；
根据所述第一响应，向所述客户端发送第二响应，所述第二响应用于指示所述终端设备具有保活功能。
9.根据权利要求1所述的方法，其特征在于，所述方法还包括：
将所述第一场景是否被保活的保活结果发送给所述客户端。
10.一种客户端的保活方法，其特征在于，应用于终端设服务器，包括：
接收来自终端设备发送的第二请求，所述第二请求包括当前时刻客户端所处的第一场景的场景信息和所述第一场景对应的第一保活时长；
根据所述第一场景的场景信息和所述第一场景对应的第一保活时长中的至少一个，确定所述第一场景是否合法；
在确定所述第一场景合法时，向所述终端设备发送第一信息，所述第一信息用于指示所述第一场景的保活信息。
11.根据权利要求10所述的方法，其特征在于，所述根据所述第一场景的场景信息和所述第一场景对应的第一保活时长中的至少一个，确定所述第一场景是否合法，包括：
在确定所述第一场景对应的第一保活时长大于第一预设时长时，确定所述第一场景不合法。
12.根据权利要求10所述的方法，其特征在于，所述根据所述第一场景的场景信息和所述第一场景对应的第一保活时长中的至少一个，确定所述第一场景是否合法，包括：
根据所述第一场景的场景信息，获得历史时刻所述客户端对应的历史保活请求信息；
根据所述客户端对应的历史保活请求信息，确定所述第一场景是否合法。
13.根据权利要求12所述的方法，其特征在于，所述根据所述客户端对应的历史保活请求信息，确定所述第一场景是否合法，包括：
根据所述历史保活请求信息中所请求保活的场景信息，确定所述客户端在历史时间内所请求保活的场景数量大于第一预设值，则确定所述第一场景不合法；或者，
根据所述历史保活请求信息中所请求的保活时长信息，确定所述客户端中超过第二预设值个场景所请求的保活时长大于第二预设时长，则确定所述第一场景不合法。
14.根据权利要求10所述的方法，其特征在于，所述向所述终端设备发送第一信息之前，所述方法还包括：
获取保活策略，所述保活策略包括所述客户端的多个可保活的第一预设场景所对应的可保活条件；
根据所述保活策略，生成第一信息。
15.根据权利要求14所述的方法，其特征在于，所述第一信息包括所述第一场景的保活结果，所述根据所述保活策略，生成第一信息，包括：
根据所述第一场景的场景信息和保活策略中所述客户端的多个可保活的第一预设场景所对应的可保活条件，确定所述第一场景的保活结果。
16.根据权利要求15所述的方法，其特征在于，所述第一预设场景所对应的可保活条件包括保活所述第一预设场景时所述终端设备所需的资源值，所述根据所述第一场景的场景信息和所述客户端的多个可保活的第一预设场景所对应的可保活条件，确定所述第一场景的保活结果，包括：
根据所述第一场景的场景信息，确定所述第一场景是否为所述第一预设场景；
若确定所述第一场景为所述第一预设场景，则获取当时时刻所述终端设备的空闲资源值；
根据所述终端设备的空闲资源值和保活所述第一场景时所述终端设备所需的资源值，确定所述第一场景的保活结果。
17.根据权利要求16所述的方法，其特征在于，所述根据所述终端设备的空闲资源值和保活所述第一场景时所述终端设备所需的资源值，确定所述第一场景的保活结果，包括：
在保活所述第一场景时所述终端设备所需的资源值小于预设资源值，且所述终端设备的空闲资源值大于或等于预测资源值时，确定所述第一场景的保活结果为保活，所述预测资源值为所述终端设备预测的在下一时刻所述终端设备运行前端程序所需的最小资源值；或者，
在保活所述第一场景时所述终端设备所需的资源值大于或等于所述预设资源值时，确定所述第一场景的保活结果为不保活；或者，
在所述终端设备的空闲资源值小于预测资源值时，确定所述第一场景的保活结果为不保活。
18.根据权利要求17所述的方法，其特征在于，所述方法还包括：
在所述终端设备保活所述第一场景的情况下，检测到下一时刻所述终端设备的空闲资源值小于所述预测资源值时，向所述终端设备发送第一停止保活指示；或者
在所述终端设备保活所述第一场景的情况下，检测到所述第一场景对应的第一保活时长到达时，向所述终端设备发送第二停止保活指示。
19.根据权利要求10所述的方法，其特征在于，所述接收来自所述终端设备发送的第二请求之前，所述方法还包括：
接收来自所述终端设备的第三请求，所述第三请求用于查询所述终端设备是否具有保活功能，所述第三请求包括所述客户端的标识信息；
根据所述客户端的标识信息，检查所述客户端是否为合法客户端；
在检查所述客户端是合法客户端时，向所述终端设备发送第一响应，所述第一响应用于指示所述客户端为合法客户端。
20.一种客户端的保活方法，其特征在于，应用于客户端，包括：
在客户端切换至后台时，获得当前时刻所述客户端所处的第一场景的场景信息；
向客户端服务器发送第一请求，所述第一请求包括所述第一场景的场景信息；
接收所述客户端服务器发送的所述第一场景对应的第一保活时长；
向终端设备发送第二请求，所述第二请求包括所述第一场景的场景信息和所述第一场景对应的第一保活时长。
21.根据权利要求20所述的方法，其特征在于，所述获得当前时刻所述客户端所处的第一场景的场景信息之前，所述方法还包括：
向所述终端设备发送第三请求，所述第三请求用于查询所述终端设备是否具有保活功能，所述第三请求包括所述客户端的标识信息；
接收到来自所述终端设备发送的第二响应，所述第二响应用于指示所述终端设备具有保活功能。
22.根据权利要求20所述的方法，其特征在于，还包括：
接收所述终端设备发送的所述第一场景是否被保活的保活结果；
将所述第一场景的保活结果发送给所述客户端服务器。
23.根据权利要求20所述的方法，其特征在于，在所述第一场景的类型为主动切换后台，所述方法还包括：
在检查到所述第一场景对应的第一保活时长到达且所述客户端未进入所述第一场景的下一个场景时，向所述客户端服务器重新发送第一请求。
24.一种客户端的保活方法，其特征在于，应用于客户端服务器，包括：
接收客户端切换至后台时所发送的第一请求，所述第一请求包括当前时刻所述客户端所处的第一场景的场景信息；
根据所述第一场景的场景信息，确定所述第一场景对应的第一保活时长；
将所述第一场景对应的第一保活时长发送给所述客户端。
25.根据权利要求24所述的方法，其特征在于，所述根据所述第一场景的场景信息，确定所述第一场景对应的第一保活时长，包括：
根据所述第一场景的场景信息，确定所述第一场景的类型；
根据所述第一场景的类型，确定所述第一场景对应的第一保活时长。
26.根据权利要求25所述的方法，其特征在于，若所述第一场景的类型为被动切换至后台，所述根据所述第一场景的类型，确定所述第一场景对应的第一保活时长，包括：
确定所述当前时刻导致所述客户端切换至后台的用户行为；
获取所述用户行为的历史数据；
根据所述历史数据中所述用户执行所述用户行为所花费的时长，确定所述第一场景对应的第一保活时长。
27.根据权利要求25所述的方法，其特征在于，若所述第一场景的类型为主动切换至后台，所述根据所述第一场景的类型，确定所述第一场景对应的第一保活时长，包括：
获取所述客户端从所述第一场景进入所述第一场景的下一个场景之间的时间间隔；
根据所述客户端从所述第一场景进入所述第一场景的下一个场景之间的时间间隔，确定所述第一场景对应的第一保活时长。
28.根据权利要求27所述的方法，其特征在于，所述方法还包括：
在所述第一场景与所述第一场景的下一个场景之间的时间间隔未知时，将预设的保活时长确定为所述第一场景对应的第一保活时长。
29.根据权利要求24-28任一项所述的方法，其特征在于，所述根据所述第一场景的场景信息，确定所述第一场景对应的第一保活时长之前，所述方法还包括：
根据所述第一场景的场景信息，确定所述第一场景是否属于预设的可保活场景；
所述根据所述第一场景的场景信息，确定所述第一场景对应的第一保活时长，包括：
确定所述第一场景属于预设的可保活场景时，根据所述第一场景的场景信息，确定所述第一场景对应的第一保活时长。
30.根据权利要求25所述的方法，其特征在于，若所述客户端服务器包括第一预设对应关系，所述第一预设对应关系包括所述客户端的多个可保活的第二预设场景所对应的保活时长，则所述客户端服务器根据所述第一场景的场景信息，确定所述第一场景对应的第一保活时长，包括：
根据所述第一场景的场景信息，确定所述第一场景是否为所述第二预设场景；
若确定所述第一场景为所述第二预设场景，则从所述第一预设对应关系中查询到所述第一场景对应的第一保活时长。
31.一种客户端的保活装置，其特征在于，应用于终端设备，包括：
接收单元，用于接收客户端切换至后台时所发送的第二请求，所述第二请求包括当前时刻所述客户端所处的第一场景的场景信息以及所述第一场景对应的第一保活时长；
发送单元，用于将所述第二请求发送给终端服务器；
接收单元，还用于接收所述终端服务器根据所述第二请求确定的第一信息，所述第一信息用于指示所述第一场景的保活信息；
处理单元，用于根据所述第一信息，确定是否对所述第一场景进行保活。
32.一种客户端的保活装置，其特征在于，应用于终端服务器，包括：
接收单元，用于接收来自所述终端设备发送的第二请求，所述第二请求包括当前时刻客户端所处的第一场景的场景信息和所述第一场景对应的第一保活时长；
处理单元，用于根据所述第一场景的场景信息和所述第一场景对应的第一保活时长中的至少一个，确定所述第一场景是否合法；
发送单元，用于在确定所述第一场景合法时，向所述终端设备发送第一信息，所述第一信息用于指示所述第一场景的保活信息。
33.一种客户端的保活装置，其特征在于，应用于客户端，包括：
处理单元，用于在所述客户端切换至后台时，获得当前时刻所述客户端所处的第一场景的场景信息；
发送单元，用于向客户端服务器发送第一请求，所述第一请求包括所述第一场景的场景信息；
接收单元，用于接收所述客户端服务器发送的所述第一场景对应的第一保活时长；
发送单元，还用于向终端设备发送第二请求，所述第二请求包括所述第一场景的场景信息和所述第一场景对应的第一保活时长。
34.一种客户端的保活装置，其特征在于，应用于客户端服务器，包括：
接收单元，用于接收客户端切换至后台时所发送的第一请求，所述第一请求包括当前时刻所述客户端所处的第一场景的场景信息；
处理单元，用于根据所述第一场景的场景信息，确定所述第一场景对应的第一保活时长；
发送单元，用于将所述第一场景对应的第一保活时长发送给所述客户端。
35.一种电子设备，其特征在于，包括：存储器，处理器；
所述存储器，用于存储计算机程序；
所述处理器，用于执行所述计算机程序以实现如上述权利要求1至9或10至19或20至23或24至30任一项所述的客户端的保活方法。
36.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机执行指令，所述计算机执行指令被处理器执行时用于实现如权利要求1至9或10至19或20至23或24至30任一项所述的客户端的保活方法。
CN202110166643.3A 2021-02-04 2021-02-04 客户端的保活方法、装置及存储介质 Pending CN114860392A (zh)

Priority Applications (4)

Application Number Priority Date Filing Date Title
CN202110166643.3A CN114860392A (zh) 2021-02-04 2021-02-04 客户端的保活方法、装置及存储介质
EP22748954.9A EP4220398A4 (en) 2021-02-04 2022-01-25 METHOD AND APPARATUS FOR MAINTAINING A CUSTOMER CONNECTION, AS WELL AS ELECTRONIC DEVICE AND STORAGE MEDIUM
PCT/CN2022/073659 WO2022166675A1 (zh) 2021-02-04 2022-01-25 客户端的保活方法、装置、电子设备及存储介质
US17/973,613 US20230056294A1 (en) 2021-02-04 2022-10-26 Client live keeping method and apparatus, electronic device, and storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110166643.3A CN114860392A (zh) 2021-02-04 2021-02-04 客户端的保活方法、装置及存储介质

Publications (1)

Publication Number Publication Date
CN114860392A true CN114860392A (zh) 2022-08-05

Family

ID=82627291

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202110166643.3A Pending CN114860392A (zh) 2021-02-04 2021-02-04 客户端的保活方法、装置及存储介质

Country Status (4)

Country Link
US (1) US20230056294A1 (zh)
EP (1) EP4220398A4 (zh)
CN (1) CN114860392A (zh)
WO (1) WO2022166675A1 (zh)

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8788863B2 (en) * 2011-08-10 2014-07-22 Microsoft Corporation System and method for restoring and/or continuing execution functionality to various processes based on predefined power classifications while transitioning a computing environment from connected standby state to execution state
US9690748B1 (en) * 2012-07-02 2017-06-27 Amazon Technologies, Inc. Delivering notifications to background applications
CN107463435B (zh) * 2017-07-31 2020-04-14 Oppo广东移动通信有限公司 应用进程优先级管理方法、装置、存储介质及电子设备
CN107463445A (zh) * 2017-07-31 2017-12-12 广东欧珀移动通信有限公司 应用进程优先级管理方法、装置、存储介质及电子设备
CN109992310B (zh) * 2019-03-12 2024-04-05 中国平安财产保险股份有限公司 应用程序保活方法、装置、计算机设备和存储介质
CN110489215A (zh) * 2019-06-29 2019-11-22 华为技术有限公司 一种应用程序中等待场景的处理方法和装置
CN111309395B (zh) * 2020-02-10 2021-07-20 北京星选科技有限公司 对象保活方法、装置、电子设备及计算机可读存储介质
CN112099757A (zh) * 2020-09-21 2020-12-18 珠海格力电器股份有限公司 一种应用保活的方法以及装置

Also Published As

Publication number Publication date
EP4220398A4 (en) 2024-03-20
US20230056294A1 (en) 2023-02-23
WO2022166675A1 (zh) 2022-08-11
EP4220398A1 (en) 2023-08-02

Similar Documents

Publication Publication Date Title
CN107277029B (zh) 一种远程过程调用的方法、装置及计算机设备
CN108834203B (zh) 网络切换方法、装置、终端及存储介质
CN108924274B (zh) 域名系统dns处理方法、装置、存储介质及电子设备
CN110351828B (zh) 一种定位方法及装置
KR20210119504A (ko) 통신 방법 및 장치, 엔티티 및 컴퓨터 판독가능 저장 매체
US11109222B2 (en) Information processing method and device, computer-readable storage medium and electronic device
CN107995286B (zh) 基于dubbo平台的服务自动启停方法、服务器及存储介质
US20130055271A1 (en) Apparatus and method for controlling polling
WO2011129643A2 (en) Method and device of managing mtc devices in a mtc network environment
CN108924043A (zh) 系统监控方法、网关通信、网关装置、业务处理设备
CN107479985B (zh) 一种远程过程调用的方法、装置及计算机设备
CN112804160B (zh) 基于应用程序的限流方法、装置、设备、介质及产品
CN107040892B (zh) 移动终端的位置信息获取方法、装置及移动终端
CN110597643B (zh) 核间通信方法、处理器以及电子设备
CN114860392A (zh) 客户端的保活方法、装置及存储介质
CN114585035B (zh) 一种语音通话方法、装置和计算机可读存储介质
CN113900815A (zh) 异构众核处理器的高带宽访存方法及装置
CN110650259B (zh) 呼叫请求的响应方法、装置、服务器、终端及存储介质
CN114302351A (zh) 短信业务处理方法、装置、计算机设备和存储介质
CN110858201B (zh) 数据处理方法及系统、处理器、存储介质
CN105142130B (zh) 一种信息处理方法及电子设备
CN108391326B (zh) 管理无线连接的方法、装置及终端
CN117883789B (zh) 数据获取方法、装置、设备、可读存储介质及程序产品
CN114189929B (zh) 网络注册方法、装置、设备及计算机可读存储介质
US20170339635A1 (en) Management of a connectivity of a mobile device

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
REG Reference to a national code

Ref country code: HK

Ref legal event code: DE

Ref document number: 40074441

Country of ref document: HK