CN117156603A - 一种求救方法及终端设备 - Google Patents

Abstract

本申请公开一种求救方法及终端设备，所述方法应用于第一终端设备，所述方法包括：响应于第一用户操作指令，显示第一界面，所述第一界面显示低功耗求救控件和强力求救控件；当接收到对强力求救控件的第一触控指令时，开启强力求救模式；或当接收到对低功耗求救控件的第二触控指令时，开启低功耗求救模式；其中，第一终端设备在同一时刻开启强力求救模式和低功耗求救模式中的一种求救工作模式；相同长度的时间窗口下第一终端设备在强力求救模式下的功耗大于第一终端设备在低功耗求救模式下的功耗。从而用户可以根据具体场景和需求使用对应的低功耗求救模式或强力求救模式，提高救援成功率。

Description

一种求救方法及终端设备

技术领域

本申请涉及计算机存储领域，尤其涉及一种求救方法及终端设备。

背景技术

随着生活水平的不断提高，野外活动日益受到人们的青睐，如何为用户在野外遇险情境中提供及时救援尤为重要。

一般地，用户出游大多携带移动终端，不会随身携带户外专用救援对讲机，于是有了采用移动终端进行救援工作的救援方案。例如，在需要展开紧急救援任务时，利用两个移动终端可以在同一频段进行通信的原理，建立救援通信链路进行救援沟通。具体的，求救终端广播求救信号，邻近的救援终端又恰好侦听到该求救信号，从而求救终端与救援终端发现彼此后，根据通信协议建立通信链路以进行救援沟通。

然而，移动终端设备广播求救信号所需的功耗较大，移动终端的电池较小，在求救过程中很可能会由于电量不足关机，求救时间短，导致与救援终端建立通信链路的可建链时间短，无法成功建立通信链路完成救援，救援成功率低。

由此，如何提供一种在建链等待时间与移动终端的功耗之间做适当取舍的求救方法使得提高救援成功率，成为了技术领域内重要的研究课题。

发明内容

第一方面，本申请提供一种求救方法，应用于第一终端设备，所述方法包括：响应于第一用户操作指令，显示第一界面，所述第一界面显示低功耗求救控件和强力求救控件；当接收到对所述强力求救控件的第一触控指令时，开启强力求救模式；或当接收到对所述低功耗求救控件的第二触控指令时，开启低功耗求救模式；其中，所述第一终端设备在同一时刻开启所述强力求救模式和所述低功耗求救模式中的一种求救工作模式；相同长度的时间窗口下所述第一终端设备在所述强力求救模式下的功耗大于所述第一终端设备在所述低功耗求救模式下的功耗；所述强力求救模式和所述低功耗求救模式用于和第二终端设备建立第一网络连接。

示例性的，上述相同长度的时间窗口下所述第一终端设备在所述强力求救模式下的功耗大于所述第一终端设备在所述低功耗求救模式下的功耗，可以是：强力求救模式下第一终端设备周期性向外发送求救信号以及侦听救援终端发送的救援信号，低功耗求救模式下第一终端设备仅周期性执行侦听任务，而不向外发送求救信号，且强力求救模式下第一终端设备执行侦听救援信号的任务的工作时长小于强力求救模式下第一终端设备执行侦听救援信号的任务的工作时长。从而可以实现当第一终端设备运行强力求救模式时，虽然第一终端设备的功耗较大，但第一终端设备可以更快地与救援终端建立通信链路，及时获取救援；当第一终端设备运行低功耗求救模式时，虽然第一终端设备与救援终端成功建立通信链路的等待时间更长，但相对应的第一终端设备的功耗较小，可以延长可求救时间。

由此，提供强力求救和低功耗求救两种求救模式，并针对两种不同的模式在第一终端设备的功耗与建立通信链路所需的等待时间之间做权衡设计，用户可以根据具体场景和需求使用对应的求救工作模式(例如若用户预估当前附近存在救援终端正在搜救，且第一终端设备当前电量不是很低的情况，用户可以选择开启强力求救模式，牺牲设备功耗以换取建链等待时间，及时与救援终端建立通信链路；例如用户预估当前附近可能不存在救援终端正在搜救，且第一终端设备当前电量不多的情况，用户可以选择低功耗求救模式，牺牲建链等待时间以降低设备功耗，延长可求救时间)。从而解决在求救过程中，第一终端设备由于无论何种场景都只能运行一种固定的求救工作模式，导致运行的求救模式与当前电量不匹配用户不能及时获取救援的问题，或第一终端设备运行模式与当前电量不匹配导致电量不足被迫停止求救任务，求救或救援时间过短，无法成功建立通信链路完成救援的问题，提高救援成功率。

在一种可能的实现方式中，所述强力求救模式为周期性执行第一任务的求救工作模式，所述第一任务包括被动侦听任务、发送紧急救援建链请求帧的任务以及进入睡眠的任务；所述低功耗求救模式为周期性执行第二任务的求救工作模式，所述第二任务包括被动侦听任务和进入睡眠的任务。

在一种可能的实现方式中，在所述开启强力求救模式之后，所述方法还包括：确定所述第一终端设备的当前电量是否大于第一电量阈值；在确定所述当前电量大于所述第一电量阈值的情况下，保持开启所述强力求救模式。

在一种可能的实现方式中，所述方法还包括：在确定所述当前电量小于或等于所述第一电量阈值的情况下，关闭所述强力求救模式，并开启所述低功耗求救模式。

由此，在用户手动开启了强力求救模式后，第一终端设备主动根据电量信息确定是否保持开启强力求救工作模式。例如，若求救终端的电量大于第一电量阈值(例如50％)，则保持开启强力求救模式，牺牲功耗以减小建链等待时间，避免用户等待救援时间过长发生意外；若求救终端的电量较少，则切换至低功耗求救模式，降低功耗，延长可求救时间，避免继续运行强力求救模式导致终端功耗过大出现关机等情况。针对不同的场景，在第一终端设备的功耗与建立通信链路所需的等待时间之间做权衡选择，从而提高救援成功率，同时也可以避免用户手动开启了与当前求救情境不匹配的求救工作模式，导致救援成功率低的问题。

在一种可能的实现方式中，所述方法还包括在确定所述当前电量小于或等于所述第一电量阈值的情况下，确定当前电量是否大于或等于第二电量阈值，所述第二电量阈值小于所述第一电量阈值；在确定所述当前电量大于或等于所述第二电量阈值的情况下，若反映用户身体状况的数据出现异常，保持开启所述强力求救模式；若所述反映用户身体状况的数据未出现异常，关闭所述强力求救模式，并开启所述低功耗求救模式；在确定所述当前电量小于所述第二电量阈值的情况下，关闭所述强力求救模式，并开启所述低功耗求救模式。

也就是说，若求救终端的电量不是很多但用户的生理数据异常，则保持开启强力求救模式，牺牲电量以减小建链等待时间，以免等待救援时间过长用户身体支撑不住；若求救终端的电量不是很多但用户的生理数据正常或者求救终端的电量很少，则开启低功耗求救模式，降低功耗，避免继续运行强力求救模式导致终端功耗过大出现关机等情况，延长可求救时间。

由此，在用户手动开启了强力求救模式后，综合根据第一终端设备的电量和用户生理数据确定是否保持开启强力求救模式或切换至低功耗求救模式，对开启强力求救模式与低功耗求救模式的场景做更精确的分析，使得终端运行与当前情境更匹配的求救模式，进一步提高救援成功率。

在一种可能的实现方式中，在所述开启所述低功耗求救模式之后，所述方法还包括：确定所述当前电量是否小于第四电量阈值；在确定所述当前电量小于所述第四电量阈值的情况下，保持开启所述低功耗求救模式。

在一种可能的实现方式中，所述方法还包括：在确定所述当前电量大于或等于所述第四电量阈值的情况下，关闭所述低功耗求救模式，并开启所述强力求救模式。

由此，在用户手动开启了低功耗求救模式后，第一终端设备主动根据电量信息确定是否保持开启低功耗求救工作模式。例如，若求救终端的电量小于第四电量阈值(例如40％)，则保持开启低功耗求救模式，牺牲建链等待时间以减少功耗；若求救终端的电量较多，则切换至强力求救模式。针对不同的场景，在第一终端设备的功耗与建立通信链路所需的等待时间之间做权衡选择，从而提高救援成功率，同时也可以避免用户手动开启了与当前求救情境不匹配的求救工作模式，导致救援成功率低的问题。

在一种可能的实现方式中，所述方法还包括：在确定所述当前电量大于或等于所述第四电量阈值的情况下，确定所述当前电量是否小于或等于第三电量阈值，所述第三电量阈值大于所述第四电量阈值；在确定所述当前电量小于或等于所述第三电量阈值的情况下，若反映用户身体状况的数据未出现异常，保持开启所述低功耗求救模式；若所述反映用户身体状况的数据出现异常，关闭所述低功耗求救模式，并开启所述强力求救模式；在确定所述当前电量大于所述第三电量阈值的情况下，关闭所述低功耗求救模式，并开启所述强力求救模式。

由此，在用户手动开启了低功耗求救模式后，综合根据第一终端设备的电量和用户生理数据确定是否保持开启低功耗求救模式或切换至强力求救模式，对开启强力求救模式与低功耗求救模式的场景做更精确的分析，使得终端运行与当前情境更匹配的求救模式，进一步提高救援成功率。

在一种可能的实现方式中，所述第三电量阈值大于第一电量阈值，所述第四电量阈值大于第二电量阈值。

可理解的，该第一电量阈值和该第二电量阈值虽然均未加“所述”一词，该第一电量阈值也仍是指上文提到的第一电量阈值，该第二电量阈值也仍为上文提到的第二电量阈值。

也就是说，该第一电量阈值即为在用户手动开启了强力求救模式后，第一终端设备根据第一电量阈值自动确定是否保持开启强力求救模式或切换至低功耗求救模式中的第一电量阈值。也即，该第一电量阈值为上述在接收到开启所述强力求救模式的开启指令后，开启所述强力求救模式之后，第一终端设备确定当前电量是否大于第一电量阈值，在确定当前电量大于第一电量阈值的情况下，保持开启强力求救模式中所描述的第一电量阈值。该第二电量阈值即为在用户手动开启了强力求救模式后，第一终端设备根据第一电量阈值、第二电量阈值和用户身体状况确定是否保持开启强力求救模式或切换至低功耗求救模式中的第二电量阈值。也即，该第二电量阈值为上述在确定所述当前电量小于或等于所述第一电量阈值的情况下，确定当前电量是否大于或等于第二电量阈值中所描述的第二电量阈值。

该第一电量阈值和该第二电量阈值为用户手动开启强力求救模式后的电量阈值，该第三电量阈值和该第四电量阈值为用户手动开启低功耗求救模式后的电量阈值。可理解的，用户手动开启强力求救模式，则表明用户的求救需求较为迫切，用户手动开启低功耗求救模式，则表明用户希望尽量降低求救功耗。则第一电量阈值(例如40％)小于第三电量阈值(例如80％)，可以使得当用户手动开启强力求救模式时，即使第一终端设备的当前电量不是很多了(例如小于60％)，但只要电量高于该第一电量阈值(40％)就仍然运行强力求救模式，满足用户迫切的求救需求。当用户手动开启了低功耗求救模式时，即使第一终端设备的当前电量较多(例如70％)，但只要电量低于该第三电量阈值(80％)第一终端设备就仍有可能运行低功耗求救模式，例如第一终端设备的电量大于40％且小于80％，且用户的身体状况很好，不存在异常情况，则第一终端设备仍运行低功耗求救模式，满足用户对尽量降低求救功耗的需求。第四电量阈值(例如40％)大于第二电量阈值(例如20％)，可以使得当用户手动开启强力求救模式时，即使第一终端设备的当前电量较少(例如30％)，但只要电量高于该第二电量阈值(20％)第一终端设备也还是可以继续运行强力求救模式，例如第一终端设备的电量高于20％但低于40％，且用户身体状况较差的情况下，第一终端设备继续运行强力求救模式，满足用户迫切的求救需求。当用户手动开启低功耗求救模式时，即使第一终端设备的当前电量不是很少(例如30％)，但只要第一终端设备的电量小于第四电量阈值(40％)，则仍然运行低功耗求救模式，满足用户对尽量降低求救功耗的需求。

由此，在采用电量阈值和用户身体状况进行自动化管控的同时优先满足用户需求，提高救援成功率的同时提高用户的使用体验。

在一种可能的实现方式中，所述第一终端设备支持的求救工作模式还包括一键求救模式，所述第一界面显示低功耗求救控件和强力求救控件包括：所述第一界面显示所述低功耗求救控件、所述强力求救控件以及一键求救控件；所述一键求救控件用于响应于第三触控指令，所述第一终端设备开启一键求救模式；所述一键求救模式下所述第一终端设备根据第一预设开启规则开启所述强力求救模式或所述低功耗求救模式中的一种求救工作模式。

由此，在用户无法判断应该手动开启何种求救工作模式的情况下，用户可以选择开启一键求救模式，由第一终端设备根据设备电量信息和用户生理数据信息，确定开启对应的强力或低功耗求救模式，提高救援成功率；同时，也可以避免用户手动开启了与当前求救情境不匹配的求救工作模式，导致无法及时获得救援的问题。

在一种可能的实现方式中，所述方法还包括：在第一终端设备未接收到上述第一用户操作指令未显示第一界面的情况下，或者，在第一终端设备已接收到第一用户操作指令显示第一界面后，第一终端设备未接收到上述第一触控指令、第二触控指令以及第三触控指令中的任一个触控指令的情况下，第一终端设备主动监测是否开启上述一键求救模式。示例性的，第一终端设备确定是否满足第一预设条件；当满足第一预设条件时，开启所述一键求救模式；所述第一预设条件为：所述第一终端设备未开启所述一键求救模式、所述强力求救模式或所述低功耗求救模式中的任一种求救工作模式、且所述第一终端设备处于无网络状态、以及反映用户身体状况的数据出现异常。

由此，第一终端设备可以根据网络状态和用户生理数据主动监测，当第一终端设备处于无网络状态且用户的身体状况异常时，自动开启该一键求救模式。可以避免用户遭遇紧急情况(例如突发疾病)无法手动开启求救模式导致无法及时获得救援的问题，提高救援成功率。

在一种可能的实现方式中，所述根据第一预设开启规则开启所述强力求救模式或所述低功耗求救模式中的一种求救工作模式包括：确定所述当前电量是否大于第五电量阈值；在确定所述当前电量大于所述第五电量阈值的情况下，开启所述强力求救模式。

在一种可能的实现方式中，所述方法还包括：在确定所述当前电量小于或等于所述第五电量阈值的情况下，开启所述低功耗求救模式。

在一种可能的实现方式中，所述方法还包括：在所述当前电量小于或等于所述第五电量阈值的情况下，确定当前电量是否大于或等于第六电量阈值，所述第六电量阈值小于所述第五电量阈值；在确定所述当前电量大于或等于所述第六电量阈值的情况下，若反映用户身体状况的数据出现异常，开启所述强力求救模式；若所述反映用户身体状况的数据未出现异常，开启所述低功耗求救模式；在确定所述当前电量小于所述第六电量阈值的情况下，开启所述低功耗求救模式。

在一种可能的实现方式中，所述第五电量阈值大于第一电量阈值，且，所述第六电量阈值小于第四电量阈值。

针对用户手动开启了强力求救模式的情况，考虑到可能是由于用户的求救需求较为迫切，或者也可能是用户基于当前求救情境认为开启强力求救模式的救援成功率更大，才开启了强力求救模式，则可以将电量阈值设置得比一键求救模式下的电量阈值更为激进，也即第一电量阈值(例如40％)小于第五电量阈值(例如60％)，只要第一终端设备的电量大于第一电量阈值，就优先满足用户的迫切求救需求，运行强力求救模式。

针对用户手动选择开启低功耗求救模式的情况，考虑到可能是用户对功耗尤为敏感，或者也可能是用户基于当前求救情境认为开启低功耗求救模式的救援成功率更大，才开启了低功耗求救模式，则对应的可以将电量阈值设置得更为保守，也即第四电量阈值(例如40％)大于第六电量阈值(30％)，只要第一终端设备的电量小于第四电量阈值，就优先满足用户的低功耗需求，运行低功耗求救模式。

由此，针对用户开启求救模式不同方式，以不同的电量阈值应对用户在不同情境下的不同需求，提高救援成功率。同时，以不同的电量阈值体现用户手动开启与第一终端设备自动开启的优先级中优先满足用户需求，以用户手动开启的优先级更高，提高用户使用体验。

在一种可能的实现方式中，所述第五电量阈值小于第三电量阈值，且，所述第六电量阈值大于第二电量阈值。

也就是说，针对用户手动开启了强力求救模式的情况，只要高于该第二电量阈值(例如20％)第一终端设备也还是可以继续运行强力求救模式，例如第一终端设备的电量高于20％但低于40％，且用户身体状况较差的情况下，第一终端设备继续运行强力求救模式，满足用户迫切的求救需求。当用户手动开启低功耗求救模式时，即使第一终端设备的当前电量不是很少(例如60％)，及时第一终端设备的电量大于第三电量阈值(80％)，第一终端设备仍有可能运行低功耗求救模式，例如第一终端设备的电量大于40％且小于60％，且用户的身体状况很好，不存在异常情况，则第一终端设备仍运行低功耗求救模式，满足用户对尽量降低求救功耗的需求。

由此，针对用户开启求救模式不同方式，以不同的电量阈值应对用户在不同情境下的不同需求，进一步提高救援成功率，以及进一步提高用户使用体验。

在一种可能的实现方式中，所述关闭所述强力求救模式，并开启所述低功耗求救模式，具体包括：输出第一提示信息，所述第一提示信息用于请求用户确定是否切换至所述低功耗求救模式；在未接收到所述用户发起的拒绝切换至所述低功耗求救模式的指令或接收到所述用户发起的确定切换至所述低功耗求救模式的指令的情况下，关闭所述强力求救模式，并开启所述低功耗求救模式。

在一种可能的实现方式中，所述关闭所述低功耗求救模式，并开启所述强力求救模式，具体包括：输出第二提示信息，所述第二提示信息用于请求用户确定是否切换至所述强力求救模式；在未接收到所述用户发起的拒绝切换至所述强力求救模式的指令或接收到所述用户发起的确定切换至所述强力求救模式的指令的情况下，关闭所述低功耗求救模式，并开启所述强力求救模式。

由此，在切换求救模式时，优先询问用户意见，用户确定允许切换求救模式时或用户超时未拒绝时，再执行切换任务，进一步提高救援成功率以及进一步提高用户使用体验。

在一种可能的实现方式中，在所述开启所述强力求救模式后，所述方法还包括：以第一时长为周期执行以下任务，其中所述第一时长包括第一工作时长、第二工作时长和第一预设睡眠时长：先后交替执行发送紧急救援建链请求帧和被动侦听任务，直到在所述第一工作时长内所述第一终端设备与救援终端成功建立通信链路、或直到所述强力求救模式被关闭、或直到所述第一工作时长结束；在所述第一工作时长结束后所述第一终端设备仍未与所述救援终端成功建立通信链路的情况下，先后交替执行被动侦听和发送紧急救援建链请求帧任务，直到在所述第二工作时长内所述第一终端设备与救援终端成功建立通信链路、或直到所述强力求救模式被关闭、或直到所述第二工作时长结束；在所述第二工作时长结束后所述第一终端设备仍未与所述救援终端成功建立通信链路的情况下，在所述第一预设睡眠时长内暂停执行所述发送紧急救援建链请求帧和所述被动侦听的任务。

可理解的，第一工作时长内与第二工作时长内执行被动侦听和发送紧急救援建链请求帧任务的先后顺序不同，也即在第一工作时长结束仍未与救援终端成功建链，则在第二个工作时长中将发送紧急救援建链请求帧的发送时间向后偏置预设时长(例如32ms)(也可以是其他合适的时长)。从而可以避免出现求救终端与救援终端因执行的任务相同产生冲突无法发现彼此的问题，进一步提高救援成功率。

在一种可能的实现方式中，在所述开启所述低功耗求救模式后，所述方法还包括：以第二时长为周期执行以下任务，其中所述第二时长包括第三工作时长和第二预设睡眠时长：执行被动侦听任务，直到在所述第三工作时长内所述第一终端设备与救援终端成功建立通信链路、或直到所述低功耗求救模式被关闭、或直到所述第三工作时长结束；在所述第三工作时长结束后所述第一终端设备仍未与所述救援终端成功建立通信链路的情况下，在所述预设睡眠时长内暂停执行发送紧急救援建链请求帧和所述被动侦听的任务。

也就是说，第一终端设备在第三工作时长内只执行被动侦听任务，从而进一步减少第一终端设备执行发送求救信号的任务带来的性能损耗(例如电量损耗)，延长求救终端的工作时间，争取更长的求救时间，给予救援终端更长的搜救时间，增大获救成功率。

在一种可能的实现方式中，所述方法还包括：确定反映用户身体状况的数据是否出现异常；所述确定反映用户身体状况的数据是否出现异常，具体包括：在基于所述第一终端设备内的体温传感器和/或与所述第一终端设备通信连接的穿戴设备内的体温传感器确定到用户的体温小于第一体温阈值或大于第二体温阈值的情况下，确定所述用户的生理数据异常；或者，在基于所述第一终端设备内的光电传感器和/或与所述第一终端设备通信连接的穿戴设备内的光电传感器确定到所述用户的血压中的收缩压小于第一收缩压阈值或大于第二收缩压阈值，和/或，所述用户的血压中的舒张压小于第一舒张压阈值或大于第二舒张压阈值的情况下，确定所述反映用户身体状况的数据出现异常。或者，在基于所述第一终端设备内的光电传感器和/或与所述第一终端设备通信连接的穿戴设备内的光电传感器确定到所述用户的心率小于第一心率阈值或大于第二心率阈值的情况下，确定所述反映用户身体状况的数据出现异常；或者，在基于所述第一终端设备内的光电传感器和/或与所述第一终端设备通信连接的穿戴设备内的光电传感器确定到所述用户的血氧饱和度小于第一血氧饱和度阈值的情况下，确定所述反映用户身体状况的数据出现异常；或者，在基于所述第一终端设备内的加速度传感器和/或与所述第一终端设备通信连接的穿戴设备内的加速度传感器确定到所述用户存在异常行为的情况下，确定所述反映用户身体状况的数据出现异常，所述异常行为包括跌倒行为；在确定所述体温大于或等于所述第一体温阈值且小于或等于所述第二体温阈值、所述收缩压大于或等于所述第一收缩压阈值且小于或等于所述第二收缩压阈值，所述舒张压大于或等于所述第一舒张压阈值且小于或等于所述第二舒张压阈值、所述心率大于或等于所述第一心率阈值且小于或等于所述第二心率阈值、所述血氧饱和度大于或等于所述第一血氧饱和度阈值、以及确定到所述用户不存在所述异常行为的情况下，确定所述反映用户身体状况的数据未出现异常。

在一种可能的实现方式中，所述方法还包括：在确定所述第一终端设备与所述第二终端设备成功建立所述第一网络连接、或所述第一终端设备接收到用户发起的结束求救模式的第四触控指令后，结束求救模式；或者，在确定所述第一终端设备已获得稳定的网络信号后，弹窗请求用户确认是否解除求救模式；在接收到用户确认解除求救模式的确认指令后，结束求救模式；所述结束求救模式，具体包括：在确定所述第一终端设备开启了所述强力求救模式的情况下，关闭所述强力求救模式；或者，在确定所述第一终端设备开启了所述低功耗求救模式的情况下，关闭所述低功耗求救模式。

第二方面，本申请实施例提供一种求救方法，应用于第一终端设备，其特征在于，所述方法包括：当满足第一预设条件时，开启一键求救模式；在开启所述一键求救模式后，根据第一预设开启规则开启所述强力求救模式或所述低功耗求救模式中的一种求救工作模式；其中，所述第一终端设备在同一时刻开启所述强力求救模式和所述低功耗求救模式中的一种求救工作模式；在相同长度的时间窗口下所述第一终端设备在所述强力求救模式下的功耗大于所述第一终端设备在所述低功耗求救模式下的功耗；所述强力求救模式和所述低功耗求救模式用于和第二终端设备建立第一网络连接。

由此，第一终端设备可以主动执行监测任务，在确定满足第一预设条件的情况下自动开启一键求救模式，并在开启一键求救模式后根据第一预设开启规则开启对应的求救工作模式。可以避免用户遭遇紧急情况(例如突发疾病)无法手动开启求救模式导致无法及时获得救援的问题，提高救援成功率。

在一种可能的实现方式中，所述第一预设条件为：所述第一终端设备未开启所述一键求救模式、所述强力求救模式或所述低功耗求救模式中的任一种求救工作模式、且所述第一终端设备处于无网络状态、以及反映用户身体状况的数据出现异常。

在一种可能的实现方式中，所述第一终端设备处于无网络状态包括所述第一终端设备搜索不到任何的蜂窝网络信号或搜索到的所有蜂窝网络都不满足通信业务需求、且第一终端设备无法连接到无线保真(Wireless Fidelity，WiFi)网络。

在一种可能的实现方式中，所述当满足第一预设条件时，开启一键求救模式包括：当满足第一预设条件时，输出第三提示信息，所述第三提示信息用于请求用户确定是否开启所述一键求救模式；在未接收到所述用户发起的拒绝开启所述一键求救模式的指令或接收到所述用户发起的确定开启所述一键求救模式的指令的情况下，开启所述一键求救模式。

由此，在自动触发开启一键求救模式的情境下，优先询问用户意见，用户确定允许开启求救模式时或用户超时未拒绝时，再执行开启一键求救模式的任务，一方面，可以降低误触发的概率，进一步提高程序运行的准确率；另外一方面，可以进一步提高用户使用体验。

在一种可能的实现方式中，所述根据第一预设开启规则开启所述强力求救模式或所述低功耗求救模式中的一种求救工作模式包括：确定所述第一终端设备的当前电量是否大于第五电量阈值；在确定所述当前电量大于所述第五电量阈值的情况下，开启所述强力求救模式。

在一种可能的实现方式中，在确定所述当前电量小于或等于所述第五电量阈值的情况下，开启所述低功耗求救模式。

在一种可能的实现方式中，所述方法还包括：在所述当前电量小于或等于所述第五电量阈值的情况下，确定当前电量是否大于或等于第六电量阈值，所述第六电量阈值小于所述第五电量阈值；在确定所述当前电量大于或等于所述第六电量阈值的情况下，若反映用户身体状况的数据出现异常，开启所述强力求救模式；若所述反映用户身体状况的数据未出现异常，开启所述低功耗求救模式；在确定所述当前电量小于所述第六电量阈值的情况下，开启所述低功耗求救模式。

可理解的，第一方面和第二方面所描述的方案是可以组合的方案，在同一个终端设备中可以既执行第一方面的方法也可以执行第二方面的方法，本文对此不做限定。

第三方面，本申请实施例提供一种终端设备，该终端设备包括：一个或多个处理器和存储器；该存储器与该一个或多个处理器耦合，该存储器用于存储计算机程序代码，该计算机程序代码包括计算机指令，该一个或多个处理器调用该计算机指令以使得该电子设备执行第一方面或第一方面的任意可能的实现方式中的方法，或以使得该电子设备执行第二方面或第二方面的任意可能的实现方式中的方法。

第四方面，本申请实施例提供一种芯片系统，该芯片系统应用于电子设备，该芯片系统包括一个或多个处理器，该处理器用于调用计算机指令以使得该电子设备执行该第一方面或第一方面的任意可能的实现方式所示的方法。

第五方面，本申请实施例提供一种包含指令的计算机程序产品，当该计算机程序产品在电子设备上运行时，使得该电子设备执行该第一方面、第一方面的任意可能的实现方式、第二方面或第二方面的任意可能的实现方式所示的方法。

第六方面，本申请实施例提供一种计算机可读存储介质，包括指令，其特征在于，当该指令在电子设备上运行时，使得该电子设备执行该第一方面、第一方面的任意可能的实现方式、第二方面或第二方面的任意可能的实现方式所示的方法。

可以理解的，上述第三方面提供的终端设备、第四方面提供的芯片系统、第五方面提供的计算机程序产品和第六方面提供的计算机存储介质均用于执行本申请实施例第一方面、第一方面的任一实现方式、第二方面或第二方面的任意可能的实现方式所示的方法。因此，其所能达到的有益效果可参考对应方法中的有益效果，此处不再赘述。

附图说明

图1为本申请实施例提供的一种求救工作模式选择的用户界面的示意图；

图2为本申请实施例提供的一种第一终端设备主动开启一键求救模式相关的用户界面示意；

图3为本申请实施例提供的一种在一键求救模式下切换求救模式的用户界面示意图；

图4为本申请实施例提供的一种由用户手动开启的强力求救模式切换至低功耗求救模式相关的用户界面示意图；

图5为本申请实施例提供的一种由用户手动开启的低功耗求救模式切换至强力求救模式相关的用户界面示意图；

图6为本申请实施例提供的一种编辑用户个人信息的用户界面示意图；

图7为本申请实施例提供的一种修改电量阈值的用户界面示意图；

图8为本申请实施例提供的一种请求用户许可解除求救模式的用户界面示意图；

图9为本申请实施例提供的一种应用环境示意图；

图10为本申请实施例提供的一种第一终端设备开启求救模式的不同开启方式的示意图；

图11A为本申请实施例提供的一种开启强力或低功耗求救模式的方法的流程示意图；

图11B为本申请实施例提供的一种确定用户的生理数据是否异常的方法流程示意图；

图12为本申请实施例提供的又一种开启强力或低功耗求救模式的方法的流程示意图；

图13为本申请实施例提供的又一种开启强力或低功耗求救模式的方法的流程示意图；

图14为本申请实施例提供的又一种开启强力或低功耗求救模式的方法的流程示意图；

图15A为本申请实施例提供的一种第一终端设备在强力求救模式下的工作时间与工作状态的示意图；

图15B为本申请实施例提供的一种第一终端设备在低功耗求救模式下的工作时间与工作状态的示意图；

图16A为本申请实施例提供的一种求救终端与救援终端发现彼此以使得建立救援通信链路的示意图；

图16B为本申请实施例提供的又一种求救终端与救援终端发现彼此以使得建立救援通信链路的示意图；

图16C为本申请实施例提供的又一种求救终端与救援终端发现彼此以使得建立救援通信链路的示意图；

图17为本申请实施例提供的终端设备100的硬件结构示意图；

图18为本申请实施例的终端设备100的软件结构框图。

具体实施方式

为了使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请作进一步地描述。

本申请的说明书、权利要求书及附图中的术语“第一”和“第二”等仅用于区别不同对象，而不是用于描述特定顺序。此外，术语“包括”和“具有”以及它们的任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备等，没有限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元等，或可选地还包括对于这些过程、方法、产品或设备等固有的其它步骤或单元。

在本文中提及的“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本申请的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员可以显式地和隐式地理解的是，本文所描述的实施例可以与其它实施例相结合。

在本申请中，“至少一个(项)”是指一个或者多个，“多个”是指两个或两个以上，“至少两个(项)”是指两个或三个及三个以上，“和/或”，用于描述关联对象的关联关系，表示可以存在三种关系，例如，“A和/或B”可以表示：只存在A，只存在B以及同时存在A和B三种情况，其中A，B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项(个)”或其类似表达，是指这些项中的任意组合。例如，a，b或c中的至少一项(个)，可以表示：a，b，c，“a和b”，“a和c”，“b和c”，或“a和b和c”。

下面结合几种其他的求救工作模式切换的实现方式，对比说明本申请实施例中求救方法的优势：

在一些求救方法中，提供一种求救模式和一种救援模式，并由用户手动切换为开启或关闭。其中，运行求救模式的第一终端设备(求救终端)与运行救援终端的第二终端设备(救援终端)在满足一定的通信条件的情况下发现彼此，进而建立通信链路，进行救援沟通。这种求救方法，不能应对不同的场景需求，救援成功率低。例如，当用户遇到危险时，用户打开第一终端设备的求救模式，求救终端持续或间断性地主动发送紧急救援建链请求帧，若求救终端的周围并没有工作在救援模式下的救援终端(例如由于用户走失时间过短，没有人注意到用户走失并通过另外一个第二终端设备开启救援模式进行救援工作)，则求救终端无论发送多少求救信号都无法与救援设备建链。从而，在求救过程中，第一终端设备很可能会由于电量不足被迫停止求救任务，导致求救时间过短，无法成功建立通信链路完成救援，救援成功率低。或者，用户发现很长时间的求救并没有得到回应，选择关闭求救模式，隔一段时间再开启求救模式，这种切换方法受随机因素影响大，很可能会由于用户判断失误，导致用户错过救援终端的救援或无法及时获得救援，求援成功率低。

然而，采用本申请实施例提供的求救方法，一方面，提供低功耗求救模式(建链等待时间长、功耗小)和强力求救模式(建链等待时间短、功耗大)两种不同的求救工作模式，其中，低功耗求救模式下第一终端设备发送求救信号的频率小于强力求救模式下第一终端设备发送求救信号的频率，在相同长度的时间窗口下低功耗求救模式下第一终端设备执行侦听救援信号的任务的工作时长小于强力求救模式下第一终端设备执行侦听救援信号的任务的工作时长。针对不同的模式在第一终端设备的功耗与建立通信链路所需的等待时间之间做权衡设计，用户可以根据具体场景和需求使用对应的求救工作模式，解决在求救过程中，第一终端设备由于无论何种场景都只能运行一种固定的求救工作模式，导致运行模式与当前电量不匹配不能及时获取救援的问题，或第一终端设备运行的求救模式与当前电量不匹配导致电量不足被迫停止求救任务，求救时间过短，无法成功与救援终端建立通信链路完成救援的问题，提高救援成功率。

另外，第一终端设备还提供了一键求救模式，第一终端设备可以根据网络状态和用户生理数据主动监测自动开启该一键求救模式。由此，可以避免用户遭遇紧急情况(例如突发疾病)无法手动开启求救模式导致无法及时获得救援的问题，提高救援成功率。

或者，在用户无法判断应该手动开启何种求救工作模式的情况下，用户可以选择开启一键求救模式，由第一终端设备根据设备电量信息和用户生理数据信息，针对不同的场景，在第一终端设备的功耗与建立通信链路所需的等待时间之间做权衡选择，确定开启对应的强力或低功耗求救模式，提高救援成功率；同时，也可以避免用户手动开启了与当前求救情境不匹配的求救工作模式，导致无法及时获得救援的问题。

另外一方面，第一终端设备在开启了一键求救模式后或第一终端设备基于用户发起的开启指令开启了求救工作模式后，可以主动根据电量信息和用户生理数据信息确定开启对应的求救工作模式或检测是否需要切换对应的求救工作模式。例如，若求救终端的电量较多，则开启强力求救模式，减小建链等待时间，以免用户等待救援时间过长发生意外；若求救终端的电量不是很多但用户的生理数据异常，则开启强力求救模式，牺牲电量以减小建链等待时间，以免等待救援时间过长用户身体支撑不住；若求救终端的电量不是很多但用户的生理数据正常，则开启低功耗求救模式，降低功耗，延长可求救时间。若求救终端的电量很少，则开启低功耗求救模式，降低功耗，延长可求救时间。针对不同的场景，在第一终端设备的功耗与建立通信链路所需的等待时间之间做权衡选择，提高救援成功率。

另外一方面，第一终端设备还可以根据开启求救模式的不同方式，设置不同的电量阈值。

示例性的，一键求救模式的电量阈值为T1(例如60％)和T2(例如30％)，若在一键求救模式下开启了强力求救模式，当终端电量小于30％时，则切换为低功耗求救模式。若在一键求救模式下开启了低功耗求救模式，当终端电量大于60％时，则切换为强力求救模式。

针对用户手动开启了强力求救模式的情况，考虑到可能是由于用户的求救需求较为迫切，或者也可能是用户基于当前求救情境认为开启强力求救模式的救援成功率更大，才开启了强力求救模式。则可以将电量阈值设置得更激进，电量阈值设置为T3(T3小于T1，例如T3为40％)和T4(T4小于T2，例如T4为20％)，只要电量大于40％则持续开启强力求救模式，如果终端电量小于20％则切换至低功耗求救模式。

针对用户手动选择开启低功耗求救模式的情况，考虑到可能是用户对功耗尤为敏感，或者也可能是用户基于当前求救情境认为开启低功耗求救模式的救援成功率更大，才开启了低功耗求救模式。则对应的可以将电量阈值设置得更为保守，电量阈值设置为T5(T5大于T1，例如T5为80％)和T6(T6大于T2，例如T6为40％)，只要终端电量低于40％则持续开启低功耗求救模式，如果终端电量大于80％则切换至强力求救模式。

由此，针对用户开启求救模式不同方式，以不同的电量阈值应对用户在不同情境下的不同需求，提高救援成功率。同时，以不同的电量阈值体现用户手动开启与第一终端设备自动开启的优先级中优先满足用户需求，以用户手动开启的优先级更高，提高用户使用体验。

示例性的，用户在失事后，第一终端设备在很短的时间内获得了稳定的信号，求救用户在这短短的时间内与救援用户拨通了电话，但求救用户可能由于对地形不了解，仅是将大概的求救位置传达与救援用户，救援用户根据求救位置将大概的救援时间传达与求救用户，从而求救用户会在预估最可能获得救援的时间开启强力求救模式，这时第一终端设备基于更低的电量阈值(也即T3和T4)确定是否需要切换求救工作模式，以优先满足用户需求，提高救援成功率。同时提高用户使用体验，例如用户在预估最可能获得救援的时间开启了强力求救模式，且设备的电量为29％，若按照T2(30％)的电量阈值，则第一终端设备会立即切换为低功耗求救模式或者立即弹出所运行的模式与当前情境不符的弹窗，提示用户已切换为低功耗求救模式，或者弹窗询问用户是否需切换至低功耗求救模式，从而在一定程度上给用户带来困扰。

再一方面，第一终端设备(求救终端)处于强力求救模式的情况下，求救终端在每个周期包括两个工作时长和一个睡眠时长，在工作时长内求救终端交替执行主动发送紧急救援建链请求帧和被动侦听的任务。若在第一个工作时长结束仍未与救援终端成功建链，则在第二个工作时长将发送紧急救援建链请求帧的发送时间偏置目标时长，示例性的，该目标时长为第一终端设备每交替执行一次主动发送紧急救援建链请求帧和被动侦听任务的时长的一半；例如第一终端设备交替执行一次主动发送紧急救援建链请求帧和被动侦听任务的时长为64ms，则该目标时长为32ms(可理解的，该目标时长还可以是其他合适时长，本文对此不做限定)，例如，在第二个工作时长内，求救终端先花32ms的时间执行被动侦听任务，而后再交替执行主动发送紧急救援建链请求帧和被动侦听的任务。从而可以避免出现求救终端与救援终端同时执行侦听任务或同时执行发送紧急救援建链请求帧任务而产生冲突无法发现彼此的问题，进一步提高救援成功率。

例如，由于求救终端在发送紧急救援建链请求帧的时救援终端也恰好在发送紧急救援建链请求帧，求救终端执行被动侦听任务时救援终端也恰好正在执行被动侦听任务；从而救援终端无法侦听到求救终端发送的紧急救援建链请求帧，求救终端也无法侦听到救援终端的紧急救援建链请求帧，导致求救终端在第一个工作时长中未与救援终端成功建链。这时本申请可以通过在求救终端的上述第二个工作时长中将发送紧急救援建链请求帧的发送时间偏置32ms，避免出现求救终端与救援终端在第一个工作时长因执行的任务相同产生冲突而无法发现彼此，在第二个工作时长仍因执行的任务相同产生冲突而无法发现彼此的问题。

第一终端设备处于低功耗求救模式的情况下，求救终端在每个周期包括一个工作时长和一个睡眠时长，在工作时长内求救终端只执行被动侦听任务，从而进一步减少求救终端执行发送紧急救援建链请求帧的任务带来的性能损耗(例如电量损耗)，可以延长求救终端的工作时间，争取更长的求救时间，给予救援终端更长的搜救时间，增大获救成功率。

例如，在求救终端的电量较少、或求救用户根据失事时间和/或之前已经运行过的求救工作模式(例如强力求救模式)判断到当前周围存在救援终端的概率较小的情况下，第一终端设备主动或用户手动启用为运行低功耗求救模式，以延长求救终端的工作时间，争取更长的求救时间，给予救援终端更长的搜救时间，增大获救成功率。

下面介绍本申请实施例提供的一种求救方法对应的用户界面图。

可理解的，本申请实施例提供的求救方法可以由任意支持设备间通信的终端设备(例如本文中的第一终端设备)执行。示例性的，该第一终端设备包括可穿戴终端、移动终端、平板电脑、桌面型计算机、膝上型计算机、手持计算机、笔记本电脑、以及超级移动个人计算机(ultra-mobile personal computer，UMPC)、等。为便于描述，以移动终端作为该第一终端设备的一个示例，介绍本申请实施例提供的用户界面。

在本申请实施例中，第一终端设备响应于第一用户操作指令，显示第一界面，该第一界面用于显示低功耗求救控件、强力求救控件以及一键求救控件。示例性的，如图1所示，本申请实施例提供的第一界面如用户界面01所示，该用户界面01包括触发对应工作模式的功能控件。具体的，该用户界面01可以包括与强力求救模式、低功耗求救模式以及一键求救模式对应的功能控件，分别为强力求救控件、低功耗求救控件、以及一键求救控件。

在用户界面01下，第一终端设备可以响应于用户对上述强力求救控件的第一触控指令，开启强力求救模式，以及第一终端设备可以响应于用户对上述低功耗求救控件的第二触控指令时，开启低功耗求救模式。

其中，强力求救模式下，第一终端设备交替进行主动呼救和被动侦听的工作，可以及时被附近的另外一个运行救援模式下的第一终端设备发现，睡眠时长较短，工作时长大于低功耗求救模式下的工作时长，救援建链等待时间短，但功耗高(例如耗电量大)。救援建链等待时间短也可以理解为工作在强力求救模式下的求救终端很快地与救援终端相互发现彼此的概率较大。

低功耗求救模式下，第一终端设备进行被动侦听工作，可以被附近运行救援模式下的另外一个第一终端设备发现，睡眠时长较长，工作时长小于强力求救模式下的工作时长，功耗较少(例如耗电量小)，但救援建链等待时间较长。救援建链等待时间长也可以理解为工作在强力求救模式下的求救终端很快地与救援终端相互发现彼此的概率较小。

一键求救模式下，第一终端设备可以根据电量以及用户身体数据的信息自动选择运行强力求救模式或低功耗求救模式。

示例性的，相对于运行救援模式的救援终端，第一终端设备运行本申请提供的强力求救模式或低功耗求救模式时，该第一终端设备可以称为求救终端。可理解的，若救援终端中也安装了可以执行本申请实施例提供的求救方法的软件应用程序，则救援终端也可以执行本申请实施例提供的求救方法。求救终端和救援终端只是针对不同的场景对第一终端设备的一个别称，并不表示运行救援模式的救援终端不能执行本方案提供的关于求救工作模式的触发与切换的方法。

可理解的，如图1所示的用户界面01，可以比上述触发对应工作模式的功能控件、个人信息入口更多或更少的内容，本文对此不做限定，示例性的，还可以包括解除求救模式的功能控件。

在本申请实施例中，第一终端设备可以主动检测求救需求，在需要开启求救模式时开启对应的求救工作模式。示例性的，在确定到第一终端设备处于无网络状态、且用户的生理数据异常(例如通过与第一终端设备连接的穿戴设备中的温度传感器检测到用户的体温较高)的情况下，如图2所示，第一终端设备可以弹窗询问用户是否开启一键求救模式，若用户确定开启或者用户超时未确定开启，则自动开启一键求救模式。开启一键求救模式后，第一终端设备自动根据电量信息和用户生理数据信息确定开启强力求救模式或低功耗求救模式。

示例性的，开启一键求救模式后，第一终端设备自动根据电量信息和用户生理数据信息确定开启强力求救模式或低功耗求救模式，有以下几种情况：

1)第一终端设备在确定设备的电量大于T1(例如T1为第一终端设备总电量的60％)的情况下，开启强力求救模式。

2)第一终端设备在确定设备电量小于或等于T1，且大于或等于T2(例如T2为30％)，以及用户生理数据(例如体温)异常的情况下，则开启强力求救模式。

3)第一终端设备在确定设备电量小于或等于T1，且大于或等于T2，以及用户生理数据正常的情况下，则开启低功耗求救模式。

4)第一终端设备在确定设备电量小于T2的情况下，则开启低功耗求救模式。

另外，一键求救模式下开启了对应的强力求救模式或低功耗求救模式后，第一终端设备持续根据第一终端设备的电量、用户生理数据、上述T1以及T2确定是否需要切换求救模式，或者保持对应的求救模式，具体实现方式与上述第一终端设备自动根据电量信息和用户生理数据信息确定开启强力求救模式或低功耗求救模式的四种实现方式一致，在此不再赘述。

例如，开启一键求救模式后，第一终端设备确定设备的电量大于上述T1，从而开启了强力求救模式；过了一段时间后，第一终端设备若确定到设备的电量小于上述T2，则将强力求救模式切换为低功耗求救模式，如图3所示(T2在图3中以30％示出)，还可以弹框提示用户已将一键求救模式下的求救模式由强力求救模式切换至低功耗求救模式。

在本申请实施例中，在求救场景中，用户也可以根据具体需求手动点击选择对应的求救模式。

例如，用户基于希望尽快与附近的救援终端建链的需求，选择开启了强力求救模式。可理解的，用户一开始就选择了强力求救模式，说明对求救需求比较迫切。这时，第一终端设备接收到用户发起的开启强力求救模式的开启指令后，开启强力求救模式。并在开启了强力求救模式后，根据第一终端设备的电量、用户生理数据、T3(T3小于T1，例如T3为40％)以及T4(T4小于T2，例如T4为20％)确定是否需要切换至低功耗求救模式，或者保持该强力求救模式。

示例性的，第一终端设备在接收到用户发起的开启强力求救模式的开启指令，开启了强力求救模式后，根据第一终端设备的电量、用户生理数据、上述T3以及T4确定是否需要切换至低功耗求救模式，或者保持该强力求救模式，有以下几种情况：

1)第一终端设备在确定设备电量大于T3的情况下，则保持强力求救模式。

2)第一终端设备在确定设备电量小于或等于T3，且大于或等于T4，以及用户生理数据(例如体温)异常的情况下，则保持强力求救模式。

3)第一终端设备在确定设备电量小于或等于T3，且大于或等于T4，以及用户生理数据正常的情况下，则切换至低功耗求救模式。

4)第一终端设备在确定设备电量小于T4的情况下，则切换至低功耗求救模式。示例性的，用户一开始设置了强力求救模式，过一段时间后，第一终端设备检测到设备电量小于T4的情况下，切换至低功耗求救模式。如图4所示(T4在图4中以20％示出)，还可以弹框提示用户已将用户设置的强力求救模式切换至低功耗求救模式。

在本申请实施例中，用户根据具体需求手动点击选择对应的工作模式时，用户基于希望维持较长的呼救时长，避免求救终端用电量过大无法维持较长的呼救时长的需求，可以选择开启低功耗求救模式。这时，第一终端设备接收到用户发起的开启低功耗求救模式的开启指令后，开启低功耗求救模式。并在开启了低功耗求救模式后，根据第一终端设备的电量、用户生理数据、T5(T5大于T1，例如T5为80％)以及T6(T6大于T2，例如T6为40％)确定是否需要切换至强力求救模式，或者保持该低功耗求救模式。

示例性的，第一终端设备在接收到用户发起的开启低功耗求救模式的开启指令，开启了低功耗求救模式后，根据第一终端设备的电量、用户生理数据、上述T5以及T6确定是否需要切换至强力求救模式，或者保持该低功耗求救模式，有以下几种情况：

1)第一终端设备在确定设备电量大于T5的情况下，则切换至强力求救模式。示例性的，用户一开始设置了低功耗求救模式。过一段时间后，第一终端设备得到电量补给，在确定电量大于T5后，则切换至强力求救模式。如图5所示(T5在图5中以80％示出)，还可以弹框提示用户已将用户设置的低功耗求救模式切换至强力求救模式。

2)第一终端设备在确定设备电量小于或等于T5，且大于或等于T6，以及用户生理数据(例如体温)异常的情况下，则切换至强力求救模式。

3)第一终端设备在确定设备电量小于或等于T5，且大于或等于T6，以及用户生理数据正常的情况下，则保持低功耗求救模式。

4)第一终端设备在确定设备电量小于T6的情况下，则保持低功耗求救模式。

在本申请实施例中，用户根据具体需求手动点击选择对应的工作模式时，若用户不能很好地判断应该选择强力求救模式还是低功耗求救模式，则可以在用户界面01中点击一键求救模式对应的控件触发一键求救模式；或者，用户还可以通过敲击组合控件的方式触发一键求救模式。示例性的，用户可以通过连续按电源键N次(N为大于2的正整数)(例如N为8)，触发一键求救模式。一键求救模式触发后由第一终端设备自动根据电量信息和用户生理数据信息确定开启强力求救模式或低功耗求救模式。

由此，针对不同的模式在第一终端设备的功耗与建立通信链路所需的等待时间之间做权衡设计，尽可能避免第一终端设备在求救过程中由于电量不足导致求救时间短，无法成功建立通信链路完成救援的问题，提高救援成功率。

在本申请实施例中，图1所示的用户界面01中，除了上述触发工作模式对应的功能控件之外，上述用户界面01还可以包括“个人信息”入口，如图6中的6A和6B所示，用户可以点击该“个人信息”入口进入编辑个人信息的个人信息编辑界面02，可以在该个人信息编辑界面02对用户个人信息相关的数据内容进行编辑和/或保存操作。如图6中的6B所示，用户个人信息可以包括用户姓名、用户手机号码、紧急联系人姓名以及紧急联系人联系方式。可理解的，用户个人信息还包括比用户姓名、用户手机号码、紧急联系人姓名以及紧急联系人联系方式更多或更少的数据内容，本文对此不做限定。例如，用户个人信息还可以包括用户的性别和/或年龄等信息。

示例性的，如图7所示，第一终端设备可以向用户提供修改(包括编辑和保存)上述T1至T6的取值的功能，由用户根据个性化需求自定义设置T1至T6的取值。

示例性的，在检测到求救终端与救援终端已成功建链，或者，接收到用户解除求救模式的指令后，求救终端解除求救模式。或者，求救终端检测到自身已获得稳定的蜂窝网络或无线保真(Wireless Fidelity，wifi)后，弹窗提示并经用户许可后自动解除求救模式。例如，如图8所示，当检测到求救终端已进入网络良好区域，弹窗提示用户是否解除求救模式，若用户确定解除则解除求救模式，若用户未确定解除，则继续保持对应的求救模式。可理解的，若用户未确定解除，则可能这时用户处于无意识的状态，由此需要继续保持求救状态。

在本文一些描述中，T1也称为第五电量阈值，T2也称为第六电量阈值，T3也称为第一电量阈值，T4也称为第二电量阈值，T5也称为第三电量阈值，T6也称为第四电量阈值。用户的生理数据也称为反映用户身体状况的数据。

下面介绍本申请实施例提供的一种求救方法应用环境图。

如图9所示，该应用环境图包括求救终端和救援终端。

在本申请实施例中，求救终端和救援终端可以通过终端直连技术(也即设备间通信技术)在同一频段进行通信，从而求救终端可以与救援终端建立通信链路，以进行救援沟通。

可理解的，求救终端与救援终端可以在同一频段通信前提是求救终端支持的通信频段与救援终端支持的通信频段中存在相同的通信频段。在此前提下，示例性的，求救终端与救援终端的通信频段可以是5G通信频段中预留的用于进行D2D通信技术(Device-to-Device，D2D)、多跳网或自组网的频段；示例性的，求救终端与救援终端的通信频段还可以是求救终端和救援终端中现有WiFi频段、蓝牙频段、或者一些非授权频段，本文对此不做限定。可理解的，若求救终端与救援终端使用5G通信频段中预留的用于进行D2D通信的频段进行通信，则求救终端与救援终端之间的可通信范围更大，若求救终端与救援终端使用wifi或蓝牙频段，求救终端与救援终端之间基于wifi或蓝牙等无线通信技术的通信原理进行通信，则求救终端与救援终端之间的可通信范围较小。

示例性的，上述求救终端处于无网络状态(没有蜂窝移动通信网络也没有无线保真网络)。可理解的，求救终端处于无网络状态是指，当求救终端在无网络状态的情况下才更有需求执行本申请提供的求救方法，若求救终端有网络则用户可以通过网络进行求救工作，但并不表示求救终端只能在无网络状态下执行本申请提供的求救方法。

示例性的，第一终端设备开启上述一键求救模式、强力求救模式或低功耗求救模式的方式如图10所述。

其中，开启一键求救模式可以有以下两种方式：

1)111、用户手动开启。也即第一终端设备在接收到用户发起的开启一键求救模式的指令后，开启一键求救模式。示例性的，第一终端设备在检测到用户点击了上述用户界面01中的与触发一键求救模式对应的功能控件后，开启一键求救模式。或者，第一终端设备在接收到用户通过预设的组合控件敲击的方式触发一键求救模式的指令后，开启一键求救模式。

2)112、第一终端设备检测到满足预设条件后，询问用户是否开启，若用户未拒绝，则自动开启。示例性的，第一终端设备确定设备处于无网络状态，且用户生理数据异常的情况下，弹窗输出提示信息，请求用户确定是否开启一键求救模式(例如图2所示)。若用户在预设时长内(例如10s内)未拒绝开启一键求救模式的请求，则开启该一键求救模式。

开启强力求救模式可以有以下四种方式：

1)121、用户手动开启。也即第一终端设备在接收到用户发起的开启强力求救模式的指令后，开启强力求救模式。示例性的，第一终端设备在检测到用户点击了上述用户界面01中与触发强力求救模式对应的功能控件后，开启强力求救模式。

2)122、一键求救模式下第一终端设备自动开启。示例性的，一键求救模式下，在确定第一终端设备的电量大于T1(例如60％)的情况下，第一终端设备开启强力求救模式(在图10中以连接线和情况1示出)；或者，在确定第一终端设备的电量大于或等于T1且小于或等于T2(例如30％)、以及用户生理数据异常(例如体温高于37.3度)的情况下，第一终端设备开启强力求救模式。

3)123、由一键求救模式下开启的低功耗求救模式切换得到。示例性的，第一终端设备基于一键求救模式的设计原理开启了低功耗求救模式，一段时间后，第一终端设备电量得到补充，第一终端设备的电量大于T1(例如60％)，则第一终端设备将求救模式切换至强力求救模式。

4)124、由用户手动开启的低功耗求救模式切换得到。示例性的，第一终端设备基于用户的自定义选择开启了低功耗求救模式，一段时间后，第一终端设备电量得到补充，第一终端设备的电量大于T5(例如80％)，则第一终端设备将求救模式切换至强力求救模式。

开启低功耗求救模式可以有以下四种方式：

1)131、用户手动开启。也即第一终端设备在接收到用户发起的开启低功耗求救模式的指令后，开启低功耗求救模式。示例性的，第一终端设备在检测到用户点击了上述用户界面01中与触发低功耗求救模式对应的功能控件后，开启低功耗求救模式。

2)132、一键求救模式下第一终端设备自动选择开启。示例性的，一键求救模式下，在确定第一终端设备的电量小于T2(例如30％)的情况下，第一终端设备开启低功耗求救模式(在图10中以连接线和情况2示出)；或者，在确定第一终端设备的电量大于或等于T1且小于或等于T2(例如30％)、以及用户生理数据正常(例如体温小于或等于37.3度)的情况下，第一终端设备开启低功耗求救模式。

3)133、由一键求救模式下开启的强力求救模式切换得到。示例性的，第一终端设备基于一键求救模式的设计原理开启了强力求救模式，一段时间后，第一终端设备电量减少，电量小于T2(例如30％)，则第一终端设备将求救模式切换至强力求救模式。

4)134、由用户手动开启的强力求救模式切换得到。示例性的，第一终端设备基于用户的自定义选择开启了强力求救模式，一段时间后，第一终端设备电量减少，电量小于T4(例如20％)，则第一终端设备将求救模式切换至低功耗求救模式。

可理解的，由用户手动开启的强力求救模式切换得到的低功耗求救模式，是指在用户手动启用求救工作模式之后，任意一次由强力求救模式切换得到的低功耗求救模式。示例性的，也可以是由用户手动开启的第一强力求救模式切换为第一低功耗求救模式，再由该第一低功耗求救模式切换为第二强力求救模式后，由该第二强力求救模式切换得到134中的低功耗求救模式。

在本申请实施例中，针对求救模式的不同开启方式(通过一键求救模式自动开启求救模式或用户手动开启求救模式)，设置不同的电量阈值。

示例性的，若第一终端设备通过一键求救模式自动开启强力求救或低功耗求救模式，则电量阈值为上述T1和T2，第一终端设备根据剩余电量(也可以理解为设备当前电量)、T1电量阈值、以及T2电量阈值确定是否开启强力求救模式或者开启低功耗求救模式，例如图10中122和132所示开启方式。并在开启了对应的求救模式后根据电量、T1、T2以及用户生理数据确定是否需要切换求救模式，例如图10中123和133所示的开启方式。

示例性的，若第一终端设备基于用户手动发起的开启强力求救模式的指令开启强力求救模式(也即图10中121所示的由用户手动开启强力求救模式的开启方式)。在开启了强力求救模式后，根据第一终端设备的电量、T3、T4电量阈值以及用户生理数据确定是否需要切换求救模式或者保持对应的求救模式，例如图10中的134所示的由用户手动开启的强力求救模式切换得到低功耗求救模式的开启方式。

示例性的，若第一终端设备基于用户手动发起的开启低功耗求救模式的指令开启低功耗求救模式(也即图10中131所示的由用户手动开启低功耗求救模式的开启方式)。在开启了低功耗求救模式后，根据第一终端设备的电量、T5、T6电量阈值以及用户生理数据确定是否需要切换求救模式或者保持对应的求救模式，例如图10中的124所示的由用户手动开启的低功耗求救模式切换得到强力求救模式的开启方式。

另外针对第一终端设备通过一键求救模式自动开启强力求救或低功耗求救模式，又包括用户手动开启一键求救模式的开启方式(图10中111所示的开启方式)和由第一终端设备自动检测开启一键求救模式(图10中112所示的开启方式)。针对第一终端设备开启一键求救模式的这两种开启方式中，对于111开启方式，第一终端设备接收到用户的开启指令之前并未检测用户的生理数据是否异常，从而在开启了一键求救模式后，第一终端设备需要确定用户生理数据是否异常，根据电量和生理数据确定开启强力或低功耗求救模式。针对第一终端设备开启一键求救模式的这两种开启方式中，对于112开启方式，第一终端设备是在检测到无网络且用户生理数据异常的情况下主动开启，从而在开启了一键求救模式后，只需根据电量确定开启强力或低功耗求救模式。

以下针对不同的开启方式通过不同的实施例进行详细说明。

可理解的，由第一终端设备执行本申请实施例提供的求救方法。该第一终端设备可以运行上述一键求救模式、强力求救模式或低功耗求救模式中的任意一种工作模式。以下为便于描述，在一些描述中，将省略执行本申请实施例提供的求救方法的执行主体第一终端设备。

实施例1：

基于上述关于图1-图10的相关说明，以下结合图11A以第一终端设备未开启任意一种求救模式下，第一终端设备后台自动检测确定在需要时主动开启一键求救模式，并通过一键求救模式自动开启对应的求救模式为例，详细描述本申请提供的一种求救方法。

如图11A所示，本申请实施例提供的求救方法包括：

阶段1：第一终端设备主动检测设备网络状态和用户生理数据，确定当前情境是否需要启用一键求救模式。

S1101，确定第一终端设备是否处于无网络状态。

示例性的，第一终端设备在搜索不到任何的蜂窝网络信号或搜索到的所有蜂窝网络都不满足通信业务需求，且第一终端设备未连接无线保真(Wireless Fidelity，WiFi)网络的情况下，确定第一终端设备处于无网络状态。

可理解的，第一终端设备搜索不到任何的蜂窝网络信号或搜索到的所有蜂窝网络都不满足通信业务需求，是指在第一终端设备中插入了或未插入用户识别卡(SIM卡)的情况下，第一终端设备搜索不到任何的蜂窝网络信号或搜索到的所有蜂窝网络都不满足通信业务需求。例如，对于第一终端设备中未插入用户识别卡的情况，若第一终端设备可以搜索到蜂窝网络信号，仍可以通过拨打紧急电话的方式进行救援，也即第一终端设备中未插入用户识别卡，但可以搜索到满足拨打紧急电话的蜂窝网络信号，则表明第一终端设备处于有网络状态，不处于无网络状态。

在一种可能的实现方式中，第一终端设备在主动检测设备网络状态和用户生理数据，确定当前情境是否需要启用一键求救模式之前(也可以理解为在上述S1101之前)，还会确定第一终端设备是否均未开启一键求救模式、强力求救模式或低功耗求救模式中的任意一种求救模式，若是才会执行主动检测设备网络状态和用户生理数据，确定当前情境是否需要启用一键求救模式的任务。

示例性的，第一终端设备可以通过第一全局变量记录当前是否开启对应的求救工作模式，并根据该第一全局变量确定第一终端设备当前是否开启了对应的求救工作模式。例如，用第一全局变量取值为00表示未开启任一个求救工作模式，用第一全局变量取值为11表示开启了一键求救模式，用第一全局变量取值为22表示开启了强力求救模式，用第一全局变量取值为33表示开启了低功耗求救模式。可理解的，第一终端设备开启了一键求救模式后则根据对应的电量阈值和开启规则开启强力求救模式或低功耗求救模式，由此，在一种可能的实现方式中，上述第一全局变量也可以不需要设置用于表示开启了一键求救模式的取值，本文对此不做限定。

在确定第一终端设备处于无网络状态的情况下，执行步骤S1102；在确定第一终端设备未处于无网络状态的情况下，执行步骤S1106。

S1102，确定用户的生理数据是否出现异常。

示例性的，上述用户的生理数据包括体温、心率、血压、或血氧含量中的一项或多项。例如，上述用户的生理数据包括体温、心率、血压、以及血氧含量。如图11B所示，上述确定用户的生理数据是否出现异常包括以下步骤：

S11021，确定用户的体温是否大于或等于M1(例如35.5度)且小于或等于M2(例如37.3度)。

可理解的，关于上述M1取值35.5度和M2取值37.3度均为示例，在实际应用中，M1和/或M2还可以是其他合适的取值，本文对此不做限定。

在确定用户的体温大于或等于M1(例如35.5度)且小于或等于M2(例如37.3度)的情况下(也即体温正常的情况下)，执行步骤S11022；在确定用户的体温小于M1或大于M2的情况下，执行步骤S11026。

S11022，确定用户的血压中的收缩压是否大于或等于M3(例如90mmHg)且小于或等于M4(例如M4等于140mmHg)，以及舒张压是否大于或等于M5(例如60mmHg)且小于或等于M6(例如90mmHg)。

可理解的，关于上述M3取值90mmHg、M4取值140mmHg、M5取值60mmHg以及M6取值90mmHg均为示例，在实际应用中M3、M4、M5或M6中的一项或多项还可以是其他合适的取值，本文对此不做限定。

在确定用户的血压中的收缩压大于或等于M3且小于或等于M4，以及舒张压大于或等于M5且小于或等于M6的情况下(也即用户的血压正常的情况下)，执行步骤S11023；在确定用户的血压中的收缩压小于M3或大于M4，或者舒张压小于M5或大于M6的情况下，执行步骤S11026。

S11023，确定用户的心率是否大于或等于M7且小于或等于M8。

示例性的，上述M7的取值可以为60次/分，上述M8的取值可以为110次/分。可理解的，该M7和M8的取值均为示例，还可以为其他合适的取值，本文对此不做限定。例如，在实际应用中，第一终端设备还可以根据用户的性别和/或年龄信息选择对应的M7和M8的值确定用户的心率是否正常。

在确定用户的心率大于或等于M7且小于或等于M8的情况下(也即用户的心率正常的情况下)，执行步骤S11024；在确定用户的心率小于M7或大于M8的情况下，执行步骤S11026。

S11024，确定用户的血氧饱和度是否大于或等于M9(例如M9的取值为95％)。

可理解的，上述M9的取值仅为示例，该M9还可以是其他合适的取值，本文对此不做限定。在一种实现方式中，第一终端设备还可以根据用户的性别和/或年龄消息选择对应的M9的值确定用户的血氧饱和度是否正常。

确定用户的血氧饱和度大于或等于M9的情况下(也即用户的血氧饱和度正常的情况下)，执行步骤S11025，在确定用户的血氧饱和度小于M9的情况下，执行步骤S11026。

S11025，确定用户的生理数据未出现异常，并持续监测用户生理数据是否出现异常。

示例性的，上述持续监测用户生理数据是否出现异常也可以理解为循环执行步骤S11021至步骤S11026。

S11026，确定用户生理数据出现异常。

在本申请实施例中，关于上述步骤S11021、S11022、S11023以及S11024的先后执行顺序仅为示例，上述步骤S11021、S11022、S11023以及S11024中的两项或大于两项步骤可以同时执行，也可以包括除上述图11B所示的执行顺序之外的其他执行顺序，本文对此不做限定。可理解的，若上述步骤S11021、S11022、S11023以及S11024中的两项或大于两项步骤之间若存在先后执行顺序，则不论是何种执行顺序，都遵循以下规律：先执行的步骤，若判断到生理数据正常则继续判断下一项生理数据是否正常，直到确定所有生理数据均正常执行步骤S11025。若其中任意一项生理数据异常，则执行步骤S11026。

可理解的，在实际应用中，上述用户生理数据可以包括体温、心率、血压、或血氧含量中的一项、两项、三项或四项；对应的，第一终端设备可以执行上述步骤S11021、S11022、S11023以及S11024中的一项、两项、三项或四项。可理解的，不论第一终端设备需要执行上述步骤S11021、S11022、S11023以及S11024中的一项、两项、三项或四项，以及步骤之间是何种执行顺序，都遵循以下规律：若生理数据仅包括一项，则第一终端设备在确定该一项生理数据正常的情况下，执行步骤S11025，第一终端设备在确定该一项生理数据不正常的情况下，执行步骤S11026。先执行的步骤，若判断到生理数据正常则继续判断下一项生理数据是否正常，直到确定所有生理数据均正常执行步骤S11025。若其中任意一项生理数据异常，则执行步骤S11026。示例性的，若用户生理数据仅包括体温，则第一终端设备仅执行上述步骤S11021、步骤S11025、以及步骤S11026。其中，执行步骤S11021，并在确定用户的体温大于或等于M1(例如35.5度)且小于或等于M2(例如37.3度)的情况下，执行步骤S11025。

示例性的，在本申请实施例中，第一终端设备可以通过以下几种方式完成上述步骤S11021、S11022、S11023以及S11024：

1)第一终端设备中配置了相应的传感器，从而第一终端设备可以通过对应的传感器采集用户的生理数据，并确定用户的生理数据是否正常。示例性的，第一终端设备中配置了温度传感器，从而第一终端设备可以通过温度传感器采集用户的体温。示例性的，第一终端设备中配置了光电传感器，从而第一终端设备可以通过光电传感器采集用户的心率、血压、以及血氧饱和度中的一项或多项。

2)与第一终端设备通过有线通信连接或无线通信连接的方式建立连接的穿戴设备中配置有相应的传感器，该穿戴设备可以采集用户的生理数据。从而第一终端设备可以通过与穿戴设备通信获取该穿戴设备采集的用户的生理数据，确定用户的生理数据是否正常。示例性的，上述有线通信连接包括通用串行总线(universal serial bus，USB)接口，上述无线通信连接包括蓝牙连接、近距离无线通信技术(near field communication，NFC)。

示例性的，上述穿戴设备可以是有线耳机、蓝牙耳机、蓝牙手环或蓝牙手表等。

可理解的，可以是仅由穿戴设备采集用户的全部所需生理数据；也可以由穿戴设备采集用户的部分生理数据，并由第一终端设备中的相应传感器采集用户剩余部分的生理数据，本文对此不做限定。

3)与第一终端设备通信连接的穿戴设备中配置有相应的传感器，由穿戴设备采集用户的生理数据，并由穿戴设备确定用户的生理数据是否正常。穿戴设备再将确定结果(确定用户的生理数据是否正常的确定结果)发送给第一终端设备，第一终端设备根据穿戴设备发送的确定结果确定用户的生理数据是否正常。

可理解的，可以是仅由穿戴设备采集用户的全部所需生理数据，并仅由穿戴设备确定用户的全部生理数据是否正常，再由穿戴设备将确定用户的全部所需生理数据是否正常的确定结果发送给第一终端设备；第一终端设备根据该确定结果用户的生理数据是否正常。或者，也可以由穿戴设备采集用户的部分生理数据，由穿戴设备确定用户的部分生理数据是否正常，再由穿戴设备将确定用户的部分所需生理数据是否正常的确定结果发送给第一终端设备；另外，第一终端设备中的相应传感器采集用户剩余部分的生理数据，并确定用户剩余部分的生理数据是否正常；第一终端设备；第一终端设备根据穿戴设备发送的确定用户的部分生理数据是否正常的确定结果以及第一终端设备确定的用户的剩余生理数据是否正常的确定结果确定用户的全部生理数据是否均正常。

若确定用户的生理数据出现异常，则第一终端设备询问用户是否需要开启一键求救模式。若用户的生理数据未出现异常，则第一终端设备不开启一键求救模式，并持续监测是否需要开启一键求救模式。

也即，在确定用户的生理数据出现异常的情况下，执行步骤S1103；在确定用户的生理数据未出现异常的情况下，执行步骤S1106。

在一种可能的实现方式中，第一终端设备还可以通过第一终端设备中设置的传感器或与第一终端设备连接的穿戴设备中的传感器确定用户是否存在异常行为(例如跌倒和/或呕吐行为)，并在确定用户存在异常行为和/或确定用户的生理数据出现异常的情况下，执行步骤S1103；在确定用户不存在异常行为，且用户的生理数据未出现异常的情况下，执行步骤S1106。

可理解的，如图11A所示，可以先执行上述步骤S1101再执行上述步骤S1102，或者也可以基于需求或具体设计意愿先执行步骤S1102再执行上述步骤S1101，本文对此不做限定。

阶段2：第一终端设备在阶段1根据设备网络状态和用户生理数据确定需要启用一键求救模式后，第一终端设备基于用户指示确定是否启用一键求救模式。

S1103，输出第三提示信息。

在本申请实施例中，上述第三提示信息用于请求用户确定是否开启一键求救模式；示例性的，如图2所示，该第三提示信息包括向用户提供发起确定开启一键求救模式的确定指令的控件和发起拒绝开启一键求救模式的拒绝指令的控件。

可理解的，在实际应用中该第三提示信息也可以仅向用户提供发起确定开启一键求救模式的确定指令的控件，或，该第三提示信息也可以仅向用户提供发起拒绝开启一键求救模式的拒绝指令的控件，本文对此不做限定。

S1104，确定第一预设时长内第一终端设备是否接收到用户发起的拒绝开启一键求救模式的指令。

示例性的，上述第一预设时长为10s(s为时间单位：秒)。该第一预设时长还可以是其他合适的取值，本文对此不做限定。

若用户在第一预设时长内确定开启一键求救模式，或者，用户在第一预设时长内未确定也未拒绝开启一键求救模式(用户可以由于处于无意识状态无法发起确定指令或拒绝指令)，则第一终端设备开启一键求救模式。

若用户在第一预设时长内发起拒绝开启一键求救模式的指令，则第一终端设备不开启一键求救模式。或者第一终端设备还可以隔一段时间后执行步骤S1101-S1104再次确定仍需要开启一键求救模式的情况下，再次请求用户是否需要开启一键求救模式。

也即，在确定第一预设时长内第一终端设备未接收到用户发起的拒绝开启一键求救模式的指令的情况下，执行步骤S1105；在确定第一预设时长内第一终端设备接收到用户发起的拒绝开启一键求救模式的指令的情况下，执行步骤S1106。

S1105，开启一键求救模式。

S1106，不开启一键求救模式。

可理解的，第一终端设备还可以隔一段时间后重复执行步骤S1101-S1104确定仍需要开启一键求救模式的情况下，再次请求用户是否需要开启一键求救模式，直到第一终端设备确定需要开启一键求救模式，或者，直到第一终端设备接收到用户手动发起的开启相应的求救工作模式的指令。

阶段3：第一终端设备开启一键求救模式后，根据设备当前电量、T1以及T2电量阈值确定开启低功耗或强力求救模式。

在本申请实施例中，第一终端设备在执行步骤S1105(开启一键求救模式)之后，再根据第一终端设备的电量确定开启强力求救模式或低功耗求救模式。具体的，结合步骤S1107至S1110进行详细说明。

S1107，确定第一终端设备的电量是否大于T1。

示例性的，上述T1用于表示第一终端设备的剩余电量与第一终端设备的最大电量的电量百分比，第一终端设备的最大电量也可以理解为第一终端设备的电池容量。上述确定第一终端设备的电量是否大于T1为确定第一终端设备的电量百分比是否大于T1。

可理解的，上述T1也可以是除了电量百分比之外的其他涵义，例如，T1的数值单位为mAh(毫安时)，用于表示第一终端设备的剩余电量值。关于本文中所描述的T2、T3、T4、T5、以及T6的涵义与T1的涵义描述一致。本文为便于描述，以T1、T2、T3、T4、T5、以及T6为第一终端设备的剩余电量与第一终端设备的最大电量的电量百分比为例说明本申请实施例提供的求救方法。

在本申请实施例中，上述T1大于0％且小于100％。示例性的，上述T1的取值为60％。该T1也可以为其他合适的取值，本文对此不做限定。本文关于T1的说明均与此一致。

若第一终端设备的电量大于T1，可以理解为第一终端设备的电量充足，则此时第一终端设备可以开启强力求救模式。

若第一终端设备的电量小于或等于T1，则第一终端设备确定电量是否大于T2(T2小于T1)。

也即，在确定第一终端设备的电量小于或等于T1的情况下，执行步骤S1108；在确定上述电量大于T1的情况下，执行步骤S1110。

S1108，确定上述电量是否大于T2。

在本申请实施例中，上述T2大于上述T1。示例性的，上述T2的取值为30％。该T2也可以为其他合适的取值，本文对此不做限定。本文关于T2的说明均与此一致。

若第一终端设备的电量小于或等于T1且大于T2，可以理解为第一终端设备的电量不多了，但由于在步骤S1102确定到用户的生理数据异常，则第一终端设备可以开启强力求救模式。

若第一终端设备的电量小于或等于T2，可以理解为第一终端设备的电量非常少，则第一终端设备开启低功耗求救模式。

也即，在确定上述电量小于或等于T2的情况下，执行步骤S1109；在确定第一终端设备的电量大于T2的情况下，执行步骤S1110。

S1109，开启低功耗求救模式。

S1110，开启强力求救模式。

在本申请实施例中，第一终端设备在开启了求救模式(强力求救模式或低功耗求救模式)后，在确定到该第一终端设备已与救援终端建立通信链路的情况下，或者，在确定到该第一终端设备已获得稳定的蜂窝通信网络或wifi网络信号并弹窗经用户许可解除求救模式的情况下，或者，第一终端设备接收到用户发起的解除求救模式的指令后，解除求救模式。

可理解的，若求救终端与救援终端已成功建链，则求救终端可以通过已建立的通信链路向救援终端发送求救信息(例如位置信息、求救者信息等)，或者，若求救终端有网络则用户可以通过网络进行求救工作，从而求救终端不需要再开启求救模式。

在一些可能的实现方式中，若求救终端与救援终端已成功建链，但在第一预设时间(例如5s)内又断开了通信链路，这时，求救终端仍可以根据本申请实施例提供的求救方法再次开启对应的求救模式，本文对此不做限定。

由此，第一终端设备根据设备网络状态和用户生理数据主动检测求救情境，确定需要开启一键求救模式时自动开启一键求救模式，避免用户遭遇紧急情况(例如突发疾病)无法手动开启求救模式，从而无法及时获得救援的问题，提高救援成功率。并且，一键求救模式下，第一终端设备根据设备电量信息确定开启对应的强力或低功耗求救模式，针对不同的场景，在第一终端设备的功耗与建立通信链路所需的等待时间之间做权衡选择，进一步提高救援成功率。

实施例2：

在一种可能的实现方式中，第一终端设备还可以基于用户手动发起的开启一键求救模式的指令开启一键求救模式。以下结合图12以第一终端设备基于用户手动发起的开启一键求救模式的指令开启一键求救模式，并通过一键求救模式自动开启求救模式中的强力求救模式或低功耗求救模式为例详细描述本申请实施例提供的求救方法的具体实现方式。

如图12所示，本申请实施例提供的求救方法包括：

阶段1：第一终端设备检测到用户发起的开启一键求救模式的指令后，开启一键求救模式。

S1201，第一终端设备在接收到用户发起的开启一键求救模式的指令后，开启一键求救模式。

阶段2：第一终端设备开启一键求救模式后，根据设备当前电量、用户生理数据、T1以及T2电量阈值确定开启低功耗或强力求救模式。

S1202，确定第一终端设备的电量是否大于T1。

关于确定第一终端设备的电量是否大于T1的相关说明请参照本文其他实施例的相关描述(例如上述步骤S1107的相关说明)，在此不再详述。

在确定第一终端设备的电量小于或等于T1的情况下，执行步骤S1203；在确定上述电量大于T1的情况下，执行步骤S1206。

S1203，确定上述电量是否大于T2。

若第一终端设备的电量小于或等于T1且大于T2，可以理解为第一终端设备的电量不多了，此时执行步骤S1204确定用户的生理数据是否异常，若用户生理数据异常，则第一终端设备应该开启强力求救模式。

若第一终端设备的电量小于或等于T2，可以理解为第一终端设备的电量非常少，则第一终端设备开启低功耗求救模式。

也即，在确定上述电量大于T2的情况下，执行步骤S1204；在确定第一终端设备的电量小于或等于T2的情况下，执行步骤S1205。

S1204，确定用户的生理数据是否出现异常。

关于确定用户的生理数据是否出现异常的具体实现方式请参照本文其他实施例的相关说明(例如上述步骤S1102的相关说明)，在此不再详述。

可理解的，在图11A中，第一终端设备在确定处于无网络状态且用户生理数据异常的情况下，才可能执行上述步骤S1103-S1105自动开启一键求救模式。也即，由第一终端设备自动检测开启一键求救模式，则表明用户的生理数据一定出现了异常，从而在开启一键求救模式后，不需要再判断用户的生理数据，只需要根据电量通过步骤S1107-S1110开启对应的强力求救模式或低功耗求救模式。而对于用户手动开启一键求救模式的情况，也即图12所示的情况下，第一终端设备通过一键求救模式开启对应的强力求救模式或低功耗求救模式时，需要确定用户的生理数据是否出现异常；也即，根据用户的生理数据和第一终端设备的电量确定开启对应的强力求救模式或低功耗求救模式。

在确定用户的生理数据出现异常的情况下，执行步骤S1206；在确定用户的生理数据未出现异常的情况下，执行步骤S1205。

S1205，开启低功耗求救模式。

S1206，开启强力求救模式。

可理解的，图12中上述步骤S1204在上述步骤S1202和S1203之后执行的描述仅为示例，上述步骤S1204可以在步骤S1202之前或之后，或在步骤S1203之前或之后执行，本文对此不做限定。

由此，当用户无法正确判断应该开启何种求救工作模式时，用户可以选择开启一键求救模式，由第一终端设备根据设备电量信息和用户生理数据信息，针对不同的场景，在第一终端设备的功耗与建立通信链路所需的等待时间之间做权衡选择，确定开启对应的强力或低功耗求救模式，提高救援成功率；同时也可以避免用户手动开启了与当前求救情境不匹配的求救模式，导致无法及时获得救援的问题，提高救援成功率。

关于第一终端设备在开启了求救模式(强力求救模式或低功耗求救模式)后，如何解除求救模式的说明请参照本申请其他实施例(例如上述实施例1)中的相关说明，在此不再详述。

在本申请实施例中，在上述步骤S1109、S1110、S1205以及S1206之后，第一终端设备还可以重复执行上述步骤S1202至S1206，从而通过上述步骤S1202至S1206确定需要保持对应的求救模式，还是需要切换求救模式。示例性的，第一终端设备通过一键求救模式开启了强力求救模式后，执行步骤S1202至S1206，其中S1205(开启低功耗求救模式)相当于：将求救模式切换至低功耗求救模式(也可以理解为关闭强力求救模式，开启低功耗求救模式)；S1206(开启强力求救模式)相当于：持续开启强力求救模式。示例性的，第一终端设备通过一键求救模式开启了低功耗求救模式后，执行步骤S1202至S1206，其中S1205相当于：持续开启低功耗求救模式；S1206相当于：将求救模式切换至强力求救模式(也可以理解为关闭低功耗求救模式，开启强力求救模式)。

在一种可能的实现方式中，由于终端电量以及用户生理数据不会毫秒或秒级别的时间内发生太大的突变，从而第一终端设备为减少不必要的监测任务给第一终端设备带来的性能损耗，可以间断性执行地重复执行上述步骤S1202至S1206，例如，每隔8分钟(还可以是其他合适的时长)执行一次。

在一种可能的实现方式中，第一终端设备若在步骤S1202中监测到终端电量小于T4，并执行步骤S1205开启了低功耗求救模式后，未检测到第一终端设备的电量得到补充，则可以不再重复执行上述步骤S1202至S1206；直到检测到终端电量得到补充，再执行上述步骤S1202至S1206，以减少不必要的监测任务给第一终端设备带来的性能损耗(例如电量损耗)。

在一种可能的实现方式中，第一终端设备若在步骤S1202中监测到终端电量大于T1，并执行步骤S1206开启强力求救模式后，又检测到第一终端设备的电量得到补充(第一终端设备处于充电状态)，则可以不再重复执行上述步骤S1202至S1206；直到检测到终端电量未持续获得补充，再执行上述步骤S1202至S1206，以减少不必要的监测任务给第一终端设备带来的性能损耗(例如第一终端设备同时在搜索网络、执行本申请的方法、又执行充电任务，运行过多的程序导致设备发热、运行速度减小或设备死机等问题)。

实施例3：

在本申请实施例中，第一终端设备在接收到用户手动发起的开启强力求救模式的指令后开启强力求救模式。并在开启强力求救模式后，根据第一终端设备电量、T3、T4以及用户生理数据持续监测是否需要持续开启强力求救模式或切换求救模式。

以下结合图13以用户手动发起开启强力求救模式的开启指令为例详细描述本申请实施例提供的求救方法的具体实现方式。

如图13所示，本申请实施例提供的求救方法包括：

阶段1：第一终端设备检测到用户发起的开启强力求救模式的指令后，开启强力求救模式。

S1301，在接收到用户发起的开启强力求救模式的开启指令后，开启强力求救模式。

阶段2：第一终端设备开启强力求救模式后，根据设备当前电量、用户生理数据、T3以及T4电量阈值确定是否需要切换至低功耗求救模式或保持强力求救模式。

S1302，确定第一终端设备的电量是否大于T3。

在一些可能的实现方式中，上述T3与上述T1(也即上述实施例1或实施例2中所描述的T1)不存在大小关联关系，也可以理解为，该T3与该T1相等或不相等。示例性的，所述T3大于0％且小于100％，例如该T3的取值为50％。

在一些可能的实现方式中，上述T3小于上述T1。示例性的，上述T1的取值为60％，该T3的取值为40％。可理解的，用户手动开启了强力求救模式，说明求救意愿颇为迫切，则电量阈值可以设置得比通过一键求救模式的电量阈值更低，只要第一终端设备的电量大于T3，就持续开启强力求救模式。

本文关于T3的说明均与此一致。

若第一终端设备的电量大于T3，则认为第一终端设备的电量充足，此时第一终端设备可以持续开启强力求救模式。

若第一终端设备的电量小于或等于T3，则第一终端设备确定电量是否大于T4(T4小于T3)。

也即，在确定第一终端设备的电量小于或等于T3的情况下，执行步骤S1303；在确定上述电量大于T3的情况下，执行步骤S1306。

S1303，确定上述电量是否大于T4。

在一些可能的实现方式中，上述T4与上述T2(也即上述实施例1或实施例2中所描述的T2)不存在大小关联关系，也即T4与T2相等或不相等，该T4小于上述T3。

在一些可能的实现方式中，T4小于上述T2。示例性的，上述T3取值为40％，T2取值为30％，该T4取值为20％。该T4也可以为其他合适的取值，本文对此不做限定。可理解的，用户手动开启了强力求救模式，说明求救意愿颇为迫切，则电量阈值可以设置得比通过一键求救模式的电量阈值更低，只要第一终端设备的电量大于或等于T4，第一终端设备还是可能保持执行强力求救模式的，例如若第一终端设备的电量大于或等于T4且用户的身体状况出现异常，则仍执行强力求救模式，以进一步满足用户的强力求救模式的需求。

本文关于T4的说明均与此一致。

若第一终端设备的电量大于T4且小于或等于T3，可以理解为第一终端设备的电量不多了，此时执行步骤S1304确定用户的生理数据是否异常，若用户生理数据异常，则第一终端设备应该持续开启强力求救模式。

若第一终端设备的电量小于或等于T4，可以理解为第一终端设备的电量非常少，则第一终端设备将求救模式切换至低功耗求救模式。

也即，在确定上述电量大于T4的情况下，执行步骤S1304；在确定第一终端设备的电量小于或等于T4的情况下，执行步骤S1305。

S1304，确定用户的生理数据是否出现异常。

关于确定用户的生理数据是否出现异常的具体实现方式请参照本文其他实施例的相关说明(例如上述步骤S1102的相关说明)，在此不再详述。

在确定用户的生理数据出现异常的情况下，执行步骤S1306；在确定用户的生理数据未出现异常的情况下，执行步骤S1305。

S1305，切换至低功耗求救模式。

S1306，保持强力求救模式。

可理解的，图13中上述步骤S1304在上述步骤S1302和S1303之后执行的描述仅为示例，上述步骤S1304可以在步骤S1302之前或之后，或在步骤S1303之前或之后执行，本文对此不做限定。

上述S1305(切换至低功耗求救模式)，还可以为S1305：切换至低功耗求救模式，并根据终端电量、T3、T4以及用户生理数据持续监测是否保持低功耗求救模式或切换至强力求救模式。上述S1306(保持强力求救模式)，还可以为S1306：保持强力求救模式，并根据终端电量、T3、T4以及用户生理数据持续监测是否保持强力求救模式或切换至低功耗求救模式。也即在S1305或S1306之后，第一终端设备可以重复执行上述步骤S1302至S1306，确定是否需要保持对应的求救模式后切换对应的求救模式。

以下结合图14以用户手动发起开启低功耗求救模式的开启指令为例详细描述本申请实施例提供的求救方法的具体实现方式。

如图14所示，本申请实施例提供的求救方法包括：

阶段1：第一终端设备检测到用户发起的开启低功耗求救模式的指令后，开启低功耗求救模式。

S1401，在接收到用户发起的开启低功耗求救模式的开启指令后，开启低功耗求救模式。

阶段2：第一终端设备开启低功耗求救模式后，根据设备当前电量、用户生理数据、T5以及T6电量阈值确定是否需要切换至强力求救模式或保持低功耗求救模式。

S1402，确定第一终端设备的电量是否大于T5。

在一些可能的实现方式中，上述T5与上述T3不存在大小关联关系，T5与T3相等或不相等。示例性的，T5大于0％且小于100％，例如，该T5的取值为50％。

在一些可能的实现方式中，上述T5大于上述T3，例如上述T3取值为40％，上述T5取值为80％。可理解的，用户手动开启了低功耗求救模式，说明用户对功耗较为敏感，则电量阈值应该设置得比通过强力求救模式的电量阈值更高，只要第一终端设备的电量小于或等于T5，第一终端设备都还是有可能执行低功耗求救模式的，例如若第一终端设备的电量小于或等于T5且用户的身体状况正常，则执行低功耗求救模式，以进一步满足用户低功耗求救模式的需求。

在一些可能的实现方式中，上述T5与上述T1不存在大小关联关系，T5与T1相等或不相等。示例性的，T5大于0％且小于100％，例如，该T5的取值为50％。

在一些可能的实现方式中，上述T5大于上述T1(也即上述实施例1或实施例2中所描述的T1)。示例性的，上述T1的取值为60％，该T5的取值为80％。可理解的，用户手动开启了低功耗求救模式，说明用户对功耗较为敏感，则电量阈值应该设置得比通过一键求救模式的电量阈值更高，只要第一终端设备的电量小于或等于T5，第一终端设备都还是有可能执行低功耗求救模式的，例如若第一终端设备的电量小于或等于T5且用户的身体状况正常，则执行低功耗求救模式，以进一步满足用户低功耗求救模式的需求。

本文关于T5的说明均与此一致。

若第一终端设备的电量大于T5，则认为第一终端设备的电量充足，此时第一终端设备可以从低功耗求救模式切换至开启强力求救模式。

若第一终端设备的电量小于或等于T5，则第一终端设备确定电量是否大于T6(T6小于T5)。

也即，在确定第一终端设备的电量小于或等于T5的情况下，执行步骤S1403；在确定上述电量大于T5的情况下，执行步骤S1406。

S1403，确定上述电量是否大于T6。

在一些可能的实现方式中，上述T6与上述T4不存在大小关联关系，T6与T4相等或不相等。示例性的，T6大于0％且小于100％，例如，该T5的取值为30％。

在一些可能的实现方式中，上述T6大于上述T4。示例性的，T4取值20％，该T6取值40％。可理解的，用户手动开启了低功耗求救模式，说明用户对功耗较为敏感，则电量阈值应该设置得比通过一键求救模式的电量阈值更高，只要终端电量小于该T6(T6大于T4)，则仍保持低功耗求救模式。

在一些可能的实现方式中，上述T6与上述T2不存在大小关联关系，T6与T2相等或不相等。例如，该T5的取值为30％。

在一些可能的实现方式中，T6大于上述T2且小于上述T5。示例性的，上述T2取值为30％，该T6取值为40％。该T4也可以为其他合适的取值，本文对此不做限定。本文关于T4的说明均与此一致。可理解的，用户手动开启了低功耗求救模式，说明用户对功耗较为敏感，则电量阈值应该设置得比通过一键求救模式的电量阈值更高，只要终端电量小于该T6(T6大于T2)，则仍保持低功耗求救模式。

本文关于T6的说明均与此一致。

若第一终端设备的电量大于T6且小于或等于T5，可以理解为第一终端设备的电量不多了，此时执行步骤S1304确定用户的生理数据是否异常，若用户生理数据异常，则第一终端设备应该从低功耗求救模式切换至强力求救模式。

若第一终端设备的电量小于或等于T6，可以理解为第一终端设备的电量非常少，则第一终端设备持续开启低功耗求救模式。

也即，在确定上述电量大于T6的情况下，执行步骤S1404；在确定第一终端设备的电量小于或等于T6的情况下，执行步骤S1405。

S1404，确定用户的生理数据是否出现异常。

关于确定用户的生理数据是否出现异常的具体实现方式请参照本文其他实施例的相关说明(例如上述步骤S1102的相关说明)，在此不再详述。

在确定用户的生理数据出现异常的情况下，执行步骤S1406；在确定用户的生理数据未出现异常的情况下，执行步骤S1405。

S1405，持续开启低功耗求救模式。

S1406，切换至强力求救模式。

由此，针对用户开启求救模式的不同方式，以不同的电量阈值应对用户在不同情境下的不同需求，提高救援成功率。同时，以不同的电量阈值体现用户手动开启与第一终端设备自动开启的优先级中优先满足用户需求，以用户手动开启的优先级更高，提高用户使用体验。

关于第一终端设备在开启了求救模式(强力求救模式或低功耗求救模式)后，如何解除求救模式的说明请参照本申请其他实施例(例如上述实施例1)中的相关说明，在此不再详述。

上述S1405(切换至低功耗求救模式)，还可以为S1405：持续开启低功耗求救模式，并根据终端电量、T3、T4以及用户生理数据持续监测是否继续保持低功耗求救模式或切换至强力求救模式。上述S1306(保持强力求救模式)，还可以为S1306：切换至强力求救模式，并根据终端电量、T3、T4以及用户生理数据持续监测是否继续保持强力求救模式或切换至低功耗求救模式。也即在S1305或S1306之后，第一终端设备可以重复执行上述步骤S1302至S1306，确定是否需要保持对应的求救模式后切换对应的求救模式。

在一种可能的实现方式中，第一终端设备在由其中一个求救模式切换至另外一个求救模式时，可以输出提示信息，请求用户确定是否切换，用户确定切换后，再执行切换任务。

示例性的，第一终端设备在由低功耗求救模式切换至强力求救模式之前，输出第二提示信息，该第二提示信息用于请求用户确定是否切换至强力求救模式；并在10s内(也可以是其他合适时长)未接收到用户拒绝切换至强力求救模式的指令，则将求救工作模式由低功耗求救模式切换至强力求救模式。

示例性的，第一终端设备在由强力求救模式切换至低功耗求救模式之前，输出第一提示信息，该第一提示信息用于请求用户确定是否切换至低功耗求救模式；并在10s内(也可以是其他合适时长)未接收到用户拒绝切换至低功耗求救模式的指令，则将求救工作模式由强力求救模式切换至低功耗求救模式。

可理解的，第一终端设备在由其中一个求救模式切换至另外一个求救模式时，可以输出提示信息，请求用户确定是否切换，用户确定切换后，再执行切换任务的方案适用于本申请的任意一个实施例(例如实施例1至实施例3中的任意一个实施例)。

在一种可能的实现方式中，由于终端电量以及用户生理数据不会毫秒或秒级别的时间内发生太大的突变，从而第一终端设备为减少不必要的监测动作给第一终端设备带来的性能损耗，可以间断性执行地重复执行上述步骤S1402至S1406和/或上述步骤S1302至S1306，例如，每隔8分钟(还可以是其他合适的时长)执行一次。

在一种可能的实现方式中，第一终端设备若在步骤S1403中监测到终端电量小于T6，并执行步骤S1405持续开启低功耗求救模式后，未检测到第一终端设备的电量得到补充，则可以不再重复执行上述步骤S1402至S1406和/或上述步骤S1302至S1306；直到检测到终端电量得到补充，再执行上述步骤S1402至S1406和/或上述步骤S1302至S1306。

在一种可能的实现方式中，第一终端设备若在步骤S1402中监测到终端电量大于T5，并执行步骤S1406开启强力求救模式后，又检测到第一终端设备的电量得到补充(第一终端设备处于充电状态)，则可以不再重复执行上述步骤S1402至S1406和/或上述步骤S1302至S1306；直到检测到终端电量未持续获得补充，再执行上述步骤S1402至S1406和/或上述步骤S1302至S1306。

可理解的，上述关于实施例1至实施例3(图11A至图14)所描述的方案内容可以均设置在同一个第一终端设备中，由同一个第一终端设备执行。

示例性的，关于在同一个第一终端设备中设置图11A至图14的方案内容，第一终端设备开启了对应的求救工作模式后，有以下两种确定是根据图11A或图12(T1和T2)、或是根据图13(T3和T4)、或是根据图14(T5和T6)中的电量阈值确定是否需要切换求救工作模式或保持对应的求救工作模式的确定方式：

1、第一终端设备设置第二全局变量，针对求救模式的不同开启方式赋予第二全局变量不同的值。

示例性的，第一终端设备在开启一键求救模式后(也可以理解为第一终端设备通过一键求救模式自动开启对应的求救模式)，将第二全局变量赋值为0。第一终端设备在接收到用户发起的开启强力求救模式的开启指令并开启强力求救模式后，将第二全局变量赋值为1。第一终端设备在接收到用户发起的开启低功耗求救模式的开启指令并开启低功耗求救模式后，将第二全局变量赋值为2。

示例性的，第一终端设备开启了强力求救模式后，确定上述第二全局变量的取值；若第二全局变量的取值为0，则第一终端设备根据终端电量、T1、T2以及用户生理数据确定是否保持强力求救模式或是切换至低功耗求救模式；若第二全局变量的取值为1，则第一终端设备根据终端电量、T3、T4以及用户生理数据确定是否保持强力求救模式或是切换至低功耗求救模式；若第二全局变量的取值为2，则第一终端设备根据终端电量、T5、T6以及用户生理数据确定是否保持强力求救模式或是切换至低功耗求救模式。

由此，第一终端设备开启了对应的求救模式后，可以根据第二全局变量的取值，确定是根据图11A或图12(T1和T2)、或根据图13(T3和T4)、或是根据图14(T5和T6)中的电量阈值确定是否需要切换求救工作模式或保持对应的求救工作模式。

2、第一终端设备设置第二全局变量，而是针对图11A、图12、图13以及图14对应需要重复执行的步骤，设置对应的循环语句和停止执行循环语句的条件(例如停止执行循环语句的条件第一终端设备接收到解除求救模式)。

由此，第一终端设备通过不同的开启方式触发执行图11A、图12、图13以及图14对应的程序，并开启了对应的求救模式后，仍会根据对应的循环语句继续在对应的图11A、图12、图13或图14的程序中重复执行根据对应的电量阈值确定是否需要切换或保持求救模式的任务。

在一种可能的实现方式中，上述第二全局变量还可以包括取值为3的第二全局变量，用于表示二次或大于二次接收到用户手动开启同一类型求救工作模式(例如求救模式)的指令，从而不再通过电量或生理数据确定是否需要切换求救工作模式，或者，直到第一终端设备检测到第一终端设备的电量满足一定的阈值后，再弹窗询问用户是否继续重复执行监测任务，并在接收到用户的同意指令后继续。

示例性的，当前第一终端设备中的上述第二全局变量的值为1或2时，若再次接收到用户手动发起的开启强力求救模式或低功耗求救模式的开启指令后，将第二全局变量的值修改为3，表示不再通过电量或生理数据确定是否需要切换求救工作模式。

例如，第一终端设备基于用户手动开启强力求救模式的开启指令开启对应的求救模式后(第二全局变量为1)，第一终端设备运行图13的程序，且基于图13的程序将用户设置的求救模式切换为低功耗求救模式后，若第一终端设备又再次接收到用户手动将求救模式切换至强力求救模式的情况下，第一终端设备不再重复运行图13所示的程序确定是否需要切换至低功耗求救模式(将第二全局变量修改为3)。或者，直到第一终端设备检测到第一终端设备的电量小于或等于10％(也可以是其他合适的取值)的情况下，再弹窗询问用户是否切换至低功耗求救模式，用户同意后切换，并在满足相应条件后(例如第一终端设备电量得到补充)再重复执行图13所示的程序。

例如，针对第一终端设备基于用户手动开启低功耗求救模式的开启指令开启对应的求救模式后(第二全局变量为2)，第一终端设备运行图14的程序，且基于图14的程序将用户设置的求救模式切换为强力求救模式后，若第一终端设备又再次接收到用户手动将求救模式切换至低功耗求救模式的情况下，第一终端设备不再重复运行图14所示的程序确定是否需要切换至强力求救模式(将第二全局变量修改为3)。或者，直到第一终端设备检测到第一终端设备的电量大于或等于98％(也可以是其他合适的取值)的情况下，再弹窗询问用户是否切换至强力求救模式，用户同意后切换，并在满足相应条件后重复执行图14所示的程序。

实施例5：

以下结合图15A至图16C详细说明本申请提供的强力求救模式和低功耗求救模式如何在建链等待时间和功耗之间权衡设计的具体实现方式。

本申请提供的强力求救模式和低功耗求救模式中，强力求救模式下，第一终端设备以第一发送频率发送求救信号、并以第一接收频率侦听救援信号；低功耗求救模式下，第一终端设备以第二接收频率侦听救援信号；其中，第一接收频率大于第二接收频率。

示例性的，以黑条表示第一终端设备正在向外发送紧急救援建链请求帧(也可以理解为救援紧急救援建链请求帧)；以灰格表示第一终端设备不向外发送紧急救援建链请求帧，而是处于被动侦听状态；以空白格表示第一终端设备进入睡眠状态(可理解为，第一终端设备进行睡眠状态是指在运行对应的求救模式下第一终端设备不向外发送紧急救援建链请求帧也不执行侦听任务，而不是指第一终端设备处于关机状态)。

其中，如图15A所示，强力求救模式下，求救终端以第一时长为周期执行向外发送紧急救援建链请求帧、被动侦听以及进入睡眠的任务。示例性的，周期时长内(第一时长内)包括第一工作时长、第二工作时长以及睡眠时长，第一终端设备第一工作时长和第二工作时长内交替执行被动侦听和主动发送紧急救援建链请求帧的任务。示例性的，该第一时长为8192ms，求救终端针对每8192ms中的第一个工作时长(在图15A中以第一个512ms示出)，在该第一个512ms中的每一个64ms内先执行发送紧急救援建链请求帧的任务(例如发送时长大于或等于2ms小于或等于5ms)，并在每一个64ms中除了发送紧急救援建链请求帧之外的其他时间执行被动侦听任务。例如在图15A则表现为在该第一个512ms内第一终端设备交替执行发送紧急救援建链请求帧和被动侦听的任务，具体为在该第一个512ms中的每一个64ms中，求救终端先执行发送紧急救援建链请求帧的任务，后执行被动侦听的任务；其中在该第一个512ms内，求救终端执行发送紧急救援建链请求帧的任务总共占用的时长可以远小于256ms，求救终端执行被动侦听任务的总时长可以小于512ms且远大于256ms。

若在上述8192ms中的第一个工作时长(第一个512ms)结束后，求救终端仍未与救援终端成功建链，则求救终端在上述8192ms中的第二个工作时长将发送紧急救援建链请求帧的发送时间点向后偏置目标时长，例如该目标时长为32ms，也就是说，求救终端针对每8192ms中的第二个工作时长(在图15A中以第二个512ms示出)，在该第二个512ms中的每一个64ms内，求救终端先采用32ms的时长执行被动侦听的任务，再针对该第二个512ms剩余的480ms(相当于7.5个64ms)执行上述第一个512ms内执行的动作，也即在该480ms中以64ms为周期交替执行上述发送紧急救援建链请求帧的任务和被动侦听的任务。其中，在该480ms中求救终端执行发送紧急救援建链请求帧的任务占用的总时长小于240ms，求救终端执行被动侦听任务占用的总时长大于240ms。

由此，强力求救模式下，第一终端设备增加执行扫描求救信号或发送求救信号的任务的工作时长，不仅执行侦听任务且主动发送紧急救援建链请求帧，在设备电量充足时用功耗换取更短的建链等待时间(例如建链等待时间可能小于5ms、或大于5ms且小于64ms、或大于64ms且小于512ms、或大于512ms且小于1024ms)。另外，通过在上述第二个512ms中将求救终端发送紧急救援建链请求帧的发送时间偏置32ms，避免出现求救终端与救援终端因执行的任务相同产生冲突无法发现彼此的问题，进一步提高救援成功率。

在一种可能的实现方式中，也可以将上述第一个512ms内求救终端执行发送紧急救援建链请求帧的任务和被动侦听的任务的执行顺序调换位置，以实现求救终端在上述第二个512ms中将发送紧急救援建链请求帧的发送时间点向后偏置目标时长，其中该目标时长的值与上述每64ms中求救终端执行被动侦听任务占用的时长的值相等。

若在上述8192ms中的第一个512ms以及第二个512ms结束后，求救终端仍未与救援终端成功建链，则求救终端进行睡眠，直到该8192ms结束后再次唤醒，也即睡眠时长为7168ms。

如图15B所示，低功耗求救模式下，求救终端以第二时长为周期执行被动侦听和进入睡眠的任务。示例性的，周期时长内(第二时长内)包括第一工作时长和睡眠时长，第一终端设备在第一工作时长内执行被动侦听任务。示例性的，该第二时长为(8192+64)ms，求救终端在每(8192+64)ms开始时执行侦听任务，连续侦听第一个工作时长(在图15B中以64ms示出)，若64ms后求救终端未与救援终端成功建链，则求救终端进行睡眠，直到该第二时长结束后再次唤醒，也即睡眠时长为8192ms。

由此，低功耗求救模式下，第一终端设备减少执行扫描求救信号任务的工作时长，求救终端在工作时长内只执行被动侦听任务，避免求救终端执行发送紧急救援建链请求帧的任务带来的性能损耗。在第一终端设备能量较少时，通过有限的能量(最低的功耗)牺牲建链等待时间(例如建链等待时间小于64ms、或大于8192ms的整数倍)的以换取更长的可求救时间，延长求救终端的工作时间，争取更长的求救时间，给予救援终端更长的搜救时间，增大获救成功率。

可理解的，本文所描述的强力求救模式建链等待时间短、功耗大，低功耗求救模式建链等待时间长、功耗小，是指在相同条件下强力求救模式的建链等待时间短、功耗大，低功耗求救模式的建链等待时间长、功耗小。例如，求救终端和救援终端之间的距离小于或等于成功建链所需的通信距离，具备成功建链的通信距离条件下，工作在强力求救模式下的求救终端很快地与救援终端相互发现彼此的概率较大(例如建链等待时间小于5ms、或大于5ms且小于64ms、或大于64ms且小于512ms、或大于512ms且小于1024ms、或大于8192ms)，工作在低功耗求救模式下的救援终端则很快地与救援终端相互发现彼此的概率较小(例如建链等待时间小于64ms、或大于8192ms的整数倍)。

可理解的，运行救援模式的救援终端可能会执行的任务包括：发送同步帧(例如救援终端为在设备间通信的主节点或同步节点时，救援终端可能会定期广播同步帧)、发送紧急救援建链请求帧、以及被动侦听任务。

可理解的，求救终端与救援终端均可以发送紧急救援建链请求帧和建链响应帧，为避免求救终端接收到来自另外一个求救终端发送的紧急救援建链请求帧或建链响应帧，或者救援终端接收到来自另外一个救援终端发送的紧急救援建链请求帧或建链响应帧，可以通过在紧急救援建链请求帧和建链响应帧中加入标识符，该标识符用于标识该帧是由求救终端还是由救援终端发出的。

本文为便于区分，用第一、第二的描述区分紧急救援建链请求帧或建链响应帧是由求救终端还是由救援终端发送的。其中，第一紧急救援建链请求帧和第一建链响应帧为求救终端发出的，第二紧急救援建链请求帧和第二建链响应帧为救援终端发出的。

示例性的，在求救终端开启了强力求救模式的情况下，求救终端与救援终端可以通过以下三种方式发现彼此以使得建立救援通信链路。

方式1，请参阅图16A：

S11，求救终端发送第一紧急救援建链请求帧，相应地，救援终端侦听到该第一紧急救援建链请求帧。

可理解的，当求救终端发送第一紧急救援建链请求帧时，救援终端正好在执行侦听任务，则救援终端可以侦听到求救终端发送的该第一紧急救援建链请求帧。

S12，救援终端侦听到该紧急救援建链请求帧后，向求救终端发送第二建链响应帧，相应地，求救终端侦听到该第二建链响应帧。

在本申请实施例中，救援终端在侦听过程中，若侦听到求救终端发送的第一紧急救援建链请求帧，则会向求救终端发送第二建链响应帧(具体可以是通过广播的方式向求救终端发送第二建链响应帧)。

可理解的，在强力求救模式下，求救终端交替进行发送紧急救援建链请求帧和被动侦听的任务。也就是说，求救终端在发送完上述第一紧急救援建链请求帧后，则继续执行被动侦听任务，从而可以侦听到(接收到)救援终端发送的上述第二建链响应帧。

S13，求救终端在上述第二建链响应帧指示的接入信道发送认证请求，以使得与救援终端成功建链。

具体如何在接入信道发送认证请求，以使得求救终端与救援终端成功建链，以求救终端与救援终端通信所使用的通信协议规定的接入流程为准。

方式2，请参阅图16B：

S21，求救终端侦听到救援终端发送的第一同步帧。

可理解的，当求救终端在执行侦听任务时，若救援终端广播第一同步帧时，则求救终端可以侦听到该第一同步帧。

S22，求救终端在上述第一同步帧指示的接入信道发送认证请求，以使得与救援终端成功建链。

方式3，请参阅图16C：

S31，救援终端发送第二紧急救援建链请求帧，相应地，求救终端侦听到该第二紧急救援建链请求帧。

可理解的，当救援终端发送第二紧急救援建链请求帧时，求救终端正好在执行侦听任务，则求救终端可以侦听到该第二紧急救援建链请求帧。

S32，求救终端侦听到该紧急救援建链请求帧后，向救援终端发送第一建链响应帧，相应地，救援终端侦听到该第一建链响应帧。

可理解的，强力救援模式下，救援终端在发送了上述第二紧急救援建链请求帧后则执行侦听任务，从而可以侦听到上述求救终端发送的第一建链响应帧。

在本申请实施例中，求救终端在侦听过程中，若侦听到救援终端发送的第二紧急救援建链请求帧，则会向救援终端发送第一建链响应帧(具体可以是通过广播的方式向求救终端发送第一建链响应帧)。

S33，求救终端在上述第二紧急救援建链请求帧指示的接入信道发送认证请求，以使得与救援终端成功建链。

示例性的，在求救终端开启了低功耗求救模式的情况下，求救终端与救援终端仅可以通过上述方式2和方式3成功建链。

下面以终端设备100作为本文中的第一终端设备为例对实施例进行具体说明。应该理解的是，终端设备100可以具有比图17中所示的更多的或者更少的部件，可以组合两个或多个的部件，或者可以具有不同的部件配置。图17中所示出的各种部件可以在包括一个或多个信号处理和/或专用集成电路在内的硬件、软件、或硬件和软件的组合中实现。

终端设备100可以包括：处理器110，外部存储器接口120，内部存储器121，通用串行总线(universal serial bus，USB)接口130，充电管理模块140，电源管理模块141，电池142，天线1，天线2，天线3，移动通信模块150，无线通信模块160，设备间通信模块170，传感器模块180，显示屏191以及用户标识模块(subscriber identification module，SIM)卡接口192等。其中传感器模块180可以包括指纹传感器，温度传感器，传感器模块180还可以包括压力传感器，陀螺仪传感器，气压传感器，磁传感器，加速度传感器，距离传感器，接近光传感器，触摸传感器，环境光传感器，骨传导传感器等，本文对此不做限定。

可以理解的是，本发明实施例示意的结构并不构成对终端设备100的具体限定。在本申请另一些实施例中，终端设备100可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件的组合实现。

处理器110可以包括一个或多个处理单元，例如：处理器110可以包括应用处理器(application processor，AP)，调制解调处理器，图形处理器(graphics processingunit，GPU)，图像信号处理器(image signal processor，ISP)，控制器，存储器，视频编解码器，数字信号处理器(digital signal processor，DSP)，和/或基带处理器等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。

其中，处理器110中可以设置存储器，用于存储指令和数据。在一些实施例中，处理器110中的存储器为高速缓冲存储器。该存储器可以保存处理器110刚用过或循环使用的指令或数据。如果处理器110需要再次使用该指令或数据，可从所述存储器中直接调用。避免了重复存取，减少了处理器110的等待时间，因而提高了系统的效率。

在一些实施例中，处理器110可以包括一个或多个接口。接口可以包括集成电路(inter-integrated circuit，I2C)接口，集成电路内置音频(inter-integrated circuitsound，I2S)接口，脉冲编码调制(pulse code modulation，PCM)接口，通用异步收发传输器(universal asynchronous receiver/transmitter，UART)接口，移动产业处理器接口(mobile industry processor interface，MIPI)，通用输入输出(general-purposeinput/output，GPIO)接口，用户标识模块(subscriber identity module，SIM)接口，和/或通用串行总线(universal serial bus，USB)接口等。

USB接口130是符合USB标准规范的接口，具体可以是Mini USB接口，Micro USB接口，USB Type C接口等。USB接口130可以用于连接充电器为终端设备100充电，也可以用于终端设备100与外围设备之间传输数据。也可以用于连接耳机，通过耳机播放音频。该接口还可以用于连接其他电子设备，例如AR设备等。示例性的，终端设备100可以通过USB接口130与穿戴设备建立有线通信连接，并基于有线通信连接获取穿戴设备采集的用户的生理数据和/或接收穿戴设备发送的对于用户的生理数据判断是否异常的结果。

充电管理模块140用于从充电器接收充电输入。其中，充电器可以是无线充电器，也可以是有线充电器。在一些有线充电的实施例中，充电管理模块140可以通过USB接口130接收有线充电器的充电输入。在一些无线充电的实施例中，充电管理模块140可以通过终端设备100的无线充电线圈接收无线充电输入。充电管理模块140为电池142充电的同时，还可以通过电源管理模块141为电子设备供电。

电源管理模块141用于连接电池142，充电管理模块140与处理器110。电源管理模块141接收电池142和/或充电管理模块140的输入，为处理器110，内部存储器121，外部存储器，显示屏191，摄像头，和无线通信模块160等供电。电源管理模块141还可以用于监测电池容量，电池循环次数，电池健康状态(漏电，阻抗)等参数。在其他一些实施例中，电源管理模块141也可以设置于处理器110中。在另一些实施例中，电源管理模块141和充电管理模块140也可以设置于同一个器件中。

示例性的，终端设备100可以通过充电管理模块140确定第一终端设备的充电状态，通过电源管理模块141确定第一终端设备的电量大小，以使得终端设备100根据本申请提供的求救方法确定开启何种求救工作模式。

终端设备100的无线通信功能可以通过天线1，天线2，天线3，移动通信模块150，无线通信模块160，设备间通信模块170，调制解调处理器以及基带处理器等实现。

天线1、天线2以及天线3用于发射和接收电磁波信号。终端设备100中的每个天线可用于覆盖单个或多个通信频带。不同的天线还可以复用，以提高天线的利用率。例如：可以将天线1复用为无线局域网的分集天线；例如，将天线1和/或天线2复用为D2D通信技术(Device-to-Device，D2D)的天线。在另外一些实施例中，天线可以和调谐开关结合使用。

移动通信模块150可以提供应用在终端设备100上的包括2G/3G/4G/5G等无线通信的解决方案。移动通信模块150可以包括至少一个滤波器，开关，功率放大器，低噪声放大器(low noise amplifier，LNA)等。移动通信模块150可以由天线1接收电磁波，并对接收的电磁波进行滤波，放大等处理，传送至调制解调处理器进行解调。移动通信模块150还可以对经调制解调处理器调制后的信号放大，经天线1转为电磁波辐射出去。在一些实施例中，移动通信模块150的至少部分功能模块可以被设置于处理器110中。在一些实施例中，移动通信模块150的至少部分功能模块可以与处理器110的至少部分模块被设置在同一个器件中。

调制解调处理器可以包括调制器和解调器。其中，调制器用于将待发送的低频基带信号调制成中高频信号。解调器用于将接收的电磁波信号解调为低频基带信号。随后解调器将解调得到的低频基带信号传送至基带处理器处理。低频基带信号经基带处理器处理后，被传递给应用处理器。应用处理器通过音频设备(不限于扬声器，受话器等)输出声音信号，或通过显示屏191显示图像或视频。在一些实施例中，调制解调处理器可以是独立的器件。在另一些实施例中，调制解调处理器可以独立于处理器110，与移动通信模块150或其他功能模块设置在同一个器件中。

在本申请实施例中，显示屏191可以为可触控的显示屏也可以为不可触控的显示屏，本文对此不做限定。显示屏191可以用于显示用户界面，例如显示如图1-图8所示的用户界面。

无线通信模块160可以提供应用在终端设备100上的包括无线局域网(wirelesslocal area networks，WLAN)(如无线保真(wireless fidelity，Wi-Fi)网络)，蓝牙(bluetooth，BT)，全球导航卫星系统(global navigation satellite system，GNSS)，调频(frequency modulation，FM)，近距离无线通信技术(near field communication，NFC)，红外技术(infrared，IR)等无线通信的解决方案。无线通信模块160可以是集成至少一个通信处理模块的一个或多个器件。无线通信模块160经由天线2接收电磁波，将电磁波信号调频以及滤波处理，将处理后的信号发送到处理器110。无线通信模块160还可以从处理器110接收待发送的信号，对其进行调频，放大，经天线2转为电磁波辐射出去。

设备间通信模块170可以提供应用在终端设备100上的包括D2D通信，点对点通信(Ad-Hoc)(也可以理解为多跳网或自组网)等设备间通信的解决方案。其中天线3的通信频段包括5G通信频段中预留的用于进行D2D通信技术(Device-to-Device，D2D)、多跳网或自组网的通信频段。设备间通信模块170经由天线3接收电磁波，将电磁波信号调频以及滤波处理，将处理后的信号发送到处理器110。设备间通信模块170还可以从处理器110接收待发送的信号，对其进行调频，放大，经天线3转为电磁波辐射出去。

示例性的，终端设备100中也可以不包括上述天线3和设备间通信模块170。若终端设备100中包括上述天线3和设备间通信模块170，则求救终端与救援终端之间的可以通过天线3支持的频段(包括5G通信频段中预留的用于进行D2D通信技术(Device-to-Device，D2D)、多跳网或自组网的通信频段)进行通信。若终端设备100中不包括上述天线3，求救终端与救援终端也可以通过上述天线1和/或天线2提供的通信频段，基于设备间通信模块170以及wifi或蓝牙等无线通信技术的通信原理进行通信。

在一些实施例中，终端设备100的天线1和移动通信模块150耦合，天线2和无线通信模块160耦合，使得终端设备100可以通过无线通信技术与网络以及其他设备通信；例如终端设备100可以通过蓝牙或NFC等通信方式与穿戴设备建立无线通信连接，并基于无线通信连接获取穿戴设备采集的用户的生理数据和/或接收穿戴设备发送的对于用户的生理数据判断是否异常的结果。天线3与设备间通信模块170耦合，使得终端设备100可以通过设备间通信技术与其他设备；例如求救终端与救援终端可以通过天线3和设备间通信模块170通信。所述无线通信技术可以包括全球移动通讯系统(global system for mobilecommunications，GSM)，通用分组无线服务(general packet radio service，GPRS)，码分多址接入(code division multiple access，CDMA)，宽带码分多址(wideband codedivision multiple access，WCDMA)，时分码分多址(time-division code divisionmultiple access，TD-SCDMA)，长期演进(long term evolution，LTE)，BT，GNSS，WLAN，NFC，FM，和/或IR技术等。所述GNSS可以包括全球卫星定位系统(global positioning system，GPS)，全球导航卫星系统(global navigation satellite system，GLONASS)，北斗卫星导航系统(beidou navigation satellite system，BDS)，准天顶卫星系统(quasi-zenithsatellite system，QZSS)和/或星基增强系统(satellite based augmentation systems，SBAS)。

可理解的，终端设备100通过GPU，显示屏191，以及应用处理器等实现显示功能。GPU为图像处理的微处理器，连接显示屏191和应用处理器。GPU用于执行数学和几何计算，用于图形渲染。处理器110可包括一个或多个GPU，其执行程序指令以生成或改变显示信息。显示屏191用于显示图像，视频等。

外部存储器接口120可以用于连接外部存储卡，例如Micro SD卡，实现扩展终端设备100的存储能力。外部存储卡通过外部存储器接口120与处理器110通信，实现数据存储功能。例如将音乐，视频等文件保存在外部存储卡中。

内部存储器121可以用于存储计算机可执行程序代码，所述可执行程序代码包括指令。处理器110通过运行存储在内部存储器121的指令，从而执行终端设备100的各种功能应用以及数据处理。内部存储器121可以包括存储程序区和存储数据区。其中，存储程序区可存储操作系统，至少一个功能所需的应用(比如人脸识别功能，指纹识别功能、移动支付功能等)等。存储数据区可存储终端设备100使用过程中所创建的数据(比如人脸信息模板数据，指纹信息模板等)等。此外，内部存储器121可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件，闪存器件，通用闪存存储器(universalflash storage，UFS)等。

示例性的，终端设备100可以通过上述处理器110、无线通信模块160、显示屏191、天线2以及设备间通信模块170等配合执行本申请实施例提供的求救方法。

示例性的，求救终端的处理器110通过移动通信模块150和无线通信模块160确定到第一终端设备处于无网络状态，且处理器110通过传感器(或通过无线通信模块160与处理器110建立无线通信连接的穿戴设备)确定到用户的生理数据异常的情况下，处理器110通过显示屏191输出第三提示信息，并在确定10s内是否接收到用户发起的拒绝开启一键求救模式的指令后，处理器110根据本申请提供的求救方法执行相应程序，开启上述一键求救模式。并在开启一键求救模式后，处理器110通过上述电源管理模块141确定设备电量是否大于上述T1(例如60％)。在确定设备电量大于T1的情况下，处理器110根据本申请提供的求救方法执行相应程序，开启上述强力求救模式。并在开启了强力求救模式后，基于电源管理模块确定的设备电量大小持续检测是否需要切换至低功耗求救模式。或者，在开启了强力求救模式后，基于充电管理模块140确定终端设备100当前是否正在充电，若终端设备100当前正在充电，且基于电源管理模块141确定到第一终端设备的电量大于T1的情况下，可以不根据第一终端设备的电量以及用户的生理数据持续检测是否需要切换至低功耗求救模式，直到设备电量得不到补充且设备的电量小于或等于T1。另外，处理器110基于开启的求救工作模式，通过天线3和设备间通信模块170确定是否具备与救援终端建立设备间通信的通信链路的条件(求救终端与救援终端之间满足如图16A至图16C所示的任意一种情况)。

图18是本申请实施例的终端设备100的软件结构框图。

分层架构将软件分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中，将系统分为四层，从上至下分别为应用程序层，应用程序框架层，运行时(Runtime)和系统库，以及内核层。

应用程序层可以包括一系列应用程序包。

如图18所示，应用程序包可以包括相机，图库，日历，通话，地图，导航，WLAN，蓝牙，音乐，视频，短信息等应用程序(也可以称为应用(application，App))。

本申请实施例中，该应用程序层还可以包括求救模块，该求救模块用于执行本申请实施例中的求救方法。

在本申请的一些实施例中，求救模块也可以位于该软件构架的其他层级中，例如应用程序框架层、系统库、内核层等，此处不作限定。

应用程序框架层为应用程序层的应用程序提供应用编程接口(applicationprogramming interface，API)和编程框架。应用程序框架层包括一些预先定义的函数。

如图18所示，应用程序框架层可以包括窗口管理器，内容提供器，视图系统，电话管理器，资源管理器，通知管理器等。

窗口管理器用于管理窗口程序。内容提供器用来存放和获取数据，并使这些数据可以被应用程序访问。视图系统包括可视控件，例如显示文字的控件，显示图片的控件等。视图系统可用于构建应用程序。电话管理器用于提供终端设备100的通信功能。资源管理器为应用程序提供各种资源，比如本地化字符串，图标，图片，布局文件，视频文件等等。通知管理器使应用程序可以在状态栏中显示通知信息，可以用于传达告知类型的消息，可以短暂停留后自动消失，无需用户交互。

运行时(Runtime)包括核心库和虚拟机。Runtime负责系统的调度和管理。

核心库包含两部分：一部分是编程语言(例如，jave语言)需要调用的功能函数，另一部分是系统的核心库。

应用程序层和应用程序框架层可以运行在虚拟机中。虚拟机可以将应用程序层和应用程序框架层的编程文件(例如，jave文件)执行为二进制文件。虚拟机用于执行对象生命周期的管理，堆栈管理，线程管理，安全和异常的管理，以及垃圾回收等功能。

系统库可以包括多个功能模块。例如：表面管理器(surface manager)，媒体库(Media Libraries)，三维图形处理库(例如：OpenGL ES)，二维图形引擎(例如：SGL)等。

内核层是硬件和软件之间的层。内核层可以包含显示驱动，摄像头驱动，音频驱动，传感器驱动，虚拟卡驱动等。

上述实施例中所用，根据上下文，术语“当…时”可以被解释为意思是“如果…”或“在…后”或“响应于确定…”或“响应于检测到…”。类似地，根据上下文，短语“在确定…时”或“如果检测到(所陈述的条件或事件)”可以被解释为意思是“如果确定…”或“响应于确定…”或“在检测到(所陈述的条件或事件)时”或“响应于检测到(所陈述的条件或事件)”。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线)或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如DVD)、或者半导体介质(例如固态硬盘)等。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，该流程可以由计算机程序来指令相关的硬件完成，该程序可存储于计算机可读取存储介质中，该程序在执行时，可包括如上述各方法实施例的流程。而前述的存储介质包括：ROM或随机存储记忆体RAM、磁碟或者光盘等各种可存储程序代码的介质。

以上所述，以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

Claims (30)

1.一种求救方法，应用于第一终端设备，其特征在于，所述方法包括：

响应于第一用户操作指令，显示第一界面，所述第一界面显示低功耗求救控件和强力求救控件；

当接收到对所述强力求救控件的第一触控指令时，开启强力求救模式；

或当接收到对所述低功耗求救控件的第二触控指令时，开启低功耗求救模式；

其中，所述第一终端设备在同一时刻开启所述强力求救模式和所述低功耗求救模式中的一种求救工作模式；相同长度的时间窗口下所述第一终端设备在所述强力求救模式下的功耗大于所述第一终端设备在所述低功耗求救模式下的功耗；所述强力求救模式和所述低功耗求救模式用于和第二终端设备建立第一网络连接。

2.根据权利要求1所述的方法，其特征在于，所述强力求救模式为周期性执行第一任务的求救工作模式，所述第一任务包括被动侦听任务、发送紧急救援建链请求帧的任务以及进入睡眠的任务；所述低功耗求救模式为周期性执行第二任务的求救工作模式，所述第二任务包括被动侦听任务和进入睡眠的任务。

3.根据权利要求1或2所述的方法，其特征在于，在所述开启强力求救模式之后，所述方法还包括：

确定所述第一终端设备的当前电量是否大于第一电量阈值；

在确定所述当前电量大于所述第一电量阈值的情况下，保持开启所述强力求救模式。

4.根据权利要求3所述的方法，其特征在于，所述方法还包括：

在确定所述当前电量小于或等于所述第一电量阈值的情况下，关闭所述强力求救模式，并开启所述低功耗求救模式。

5.根据权利要求3所述的方法，其特征在于，所述方法还包括：

在确定所述当前电量小于或等于所述第一电量阈值的情况下，确定当前电量是否大于或等于第二电量阈值，所述第二电量阈值小于所述第一电量阈值；

在确定所述当前电量大于或等于所述第二电量阈值的情况下，若反映用户身体状况的数据出现异常，保持开启所述强力求救模式；若所述反映用户身体状况的数据未出现异常，关闭所述强力求救模式，并开启所述低功耗求救模式；

在确定所述当前电量小于所述第二电量阈值的情况下，关闭所述强力求救模式，并开启所述低功耗求救模式。

6.根据权利要求1至5任一项所述的方法，其特征在于，在所述开启所述低功耗求救模式之后，所述方法还包括：

确定所述当前电量是否小于第四电量阈值；

在确定所述当前电量小于所述第四电量阈值的情况下，保持开启所述低功耗求救模式。

7.根据权利要求6所述的方法，其特征在于，所述方法还包括：

在确定所述当前电量大于或等于所述第四电量阈值的情况下，关闭所述低功耗求救模式，并开启所述强力求救模式。

8.根据权利要求6所述的方法，其特征在于，所述方法还包括：

在确定所述当前电量大于或等于所述第四电量阈值的情况下，确定所述当前电量是否小于或等于第三电量阈值，所述第三电量阈值大于所述第四电量阈值；

在确定所述当前电量小于或等于所述第三电量阈值的情况下，若反映用户身体状况的数据未出现异常，保持开启所述低功耗求救模式；若所述反映用户身体状况的数据出现异常，关闭所述低功耗求救模式，并开启所述强力求救模式；

在确定所述当前电量大于所述第三电量阈值的情况下，关闭所述低功耗求救模式，并开启所述强力求救模式。

9.根据权利要求8所述的方法，其特征在于，所述第三电量阈值大于第一电量阈值，所述第四电量阈值大于第二电量阈值。

10.根据权利要求1所述的方法，其特征在于，所述第一界面显示低功耗求救控件和强力求救控件包括：

所述第一界面显示所述低功耗求救控件、所述强力求救控件以及一键求救控件；所述一键求救控件用于响应于第三触控指令，所述第一终端设备开启一键求救模式；所述一键求救模式下所述第一终端设备根据第一预设开启规则开启所述强力求救模式或所述低功耗求救模式中的一种求救工作模式。

11.根据权利要求9或10所述的方法，其特征在于，所述根据第一预设开启规则开启所述强力求救模式或所述低功耗求救模式中的一种求救工作模式包括：

确定所述当前电量是否大于第五电量阈值；

在确定所述当前电量大于所述第五电量阈值的情况下，开启所述强力求救模式。

12.根据权利要求11所述的方法，其特征在于，所述方法还包括：

在确定所述当前电量小于或等于所述第五电量阈值的情况下，开启所述低功耗求救模式。

13.根据权利要求11所述的方法，其特征在于，所述方法还包括：

在所述当前电量小于或等于所述第五电量阈值的情况下，确定当前电量是否大于或等于第六电量阈值，所述第六电量阈值小于所述第五电量阈值；

在确定所述当前电量大于或等于所述第六电量阈值的情况下，若反映用户身体状况的数据出现异常，开启所述强力求救模式；若所述反映用户身体状况的数据未出现异常，开启所述低功耗求救模式；

在确定所述当前电量小于所述第六电量阈值的情况下，开启所述低功耗求救模式。

14.根据权利要求13所述的方法，其特征在于，所述第五电量阈值大于第一电量阈值，且，所述第六电量阈值小于第四电量阈值。

15.根据权利要求13或14所述的方法，其特征在于，所述第五电量阈值小于第三电量阈值，且，所述第六电量阈值大于第二电量阈值。

16.根据权利要求4或5所述的方法，其特征在于，所述关闭所述强力求救模式，并开启所述低功耗求救模式，具体包括：

输出第一提示信息，所述第一提示信息用于请求用户确定是否切换至所述低功耗求救模式；

在未接收到所述用户发起的拒绝切换至所述低功耗求救模式的指令或接收到所述用户发起的确定切换至所述低功耗求救模式的指令的情况下，关闭所述强力求救模式，并开启所述低功耗求救模式。

17.根据权利要求7或8所述的方法，其特征在于，所述关闭所述低功耗求救模式，并开启所述强力求救模式，具体包括：

输出第二提示信息，所述第二提示信息用于请求用户确定是否切换至所述强力求救模式；

在未接收到所述用户发起的拒绝切换至所述强力求救模式的指令或接收到所述用户发起的确定切换至所述强力求救模式的指令的情况下，关闭所述低功耗求救模式，并开启所述强力求救模式。

18.根据权利要求1至17任一项所述的方法，其特征在于，在所述开启所述强力求救模式后，所述方法还包括：

以第一时长为周期执行以下任务，其中所述第一时长包括第一工作时长、第二工作时长和第一预设睡眠时长：

先后交替执行发送紧急救援建链请求帧和被动侦听任务，直到在所述第一工作时长内所述第一终端设备与所述第二终端设备成功建立通信链路、或直到所述强力求救模式被关闭、或直到所述第一工作时长结束；

在所述第一工作时长结束后所述第一终端设备仍未与所述第二终端设备成功建立通信链路的情况下，先后交替执行被动侦听和发送紧急救援建链请求帧任务，直到在所述第二工作时长内所述第一终端设备与所述第二终端设备成功建立通信链路、或直到所述强力求救模式被关闭、或直到所述第二工作时长结束；

在所述第二工作时长结束后所述第一终端设备仍未与所述第二终端设备成功建立通信链路的情况下，在所述第一预设睡眠时长内暂停执行所述发送紧急救援建链请求帧和所述被动侦听的任务。

19.根据权利要求1至18任一项所述的方法，其特征在于，在所述开启所述低功耗求救模式后，所述方法还包括：

以第二时长为周期执行以下任务，其中所述第二时长包括第三工作时长和第二预设睡眠时长：

执行被动侦听任务，直到在所述第三工作时长内所述第一终端设备与所述第二终端设备成功建立通信链路、或直到所述低功耗求救模式被关闭、或直到所述第三工作时长结束；

在所述第三工作时长结束后所述第一终端设备仍未与所述第二终端设备成功建立通信链路的情况下，在所述预设睡眠时长内暂停执行发送紧急救援建链请求帧和所述被动侦听的任务。

20.根据权利要求1至19任一项所述的方法，其特征在于，所述方法还包括：

确定反映用户身体状况的数据是否出现异常；

所述确定反映用户身体状况的数据是否出现异常，具体包括：

在基于所述第一终端设备内的体温传感器和/或与所述第一终端设备通信连接的穿戴设备内的体温传感器确定到用户的体温小于第一体温阈值或大于第二体温阈值的情况下，确定所述用户的生理数据异常；或者，

在基于所述第一终端设备内的光电传感器和/或与所述第一终端设备通信连接的穿戴设备内的光电传感器确定到所述用户的血压中的收缩压小于第一收缩压阈值或大于第二收缩压阈值，和/或，所述用户的血压中的舒张压小于第一舒张压阈值或大于第二舒张压阈值的情况下，确定所述反映用户身体状况的数据出现异常；或者，

在基于所述第一终端设备内的光电传感器和/或与所述第一终端设备通信连接的穿戴设备内的光电传感器确定到所述用户的心率小于第一心率阈值或大于第二心率阈值的情况下，确定所述反映用户身体状况的数据出现异常；或者，

在基于所述第一终端设备内的光电传感器和/或与所述第一终端设备通信连接的穿戴设备内的光电传感器确定到所述用户的血氧饱和度小于第一血氧饱和度阈值的情况下，确定所述反映用户身体状况的数据出现异常；或者，

在基于所述第一终端设备内的加速度传感器和/或与所述第一终端设备通信连接的穿戴设备内的加速度传感器确定到所述用户存在异常行为的情况下，确定所述反映用户身体状况的数据出现异常，所述异常行为包括跌倒行为；

在确定所述体温大于或等于所述第一体温阈值且小于或等于所述第二体温阈值、所述收缩压大于或等于所述第一收缩压阈值且小于或等于所述第二收缩压阈值，所述舒张压大于或等于所述第一舒张压阈值且小于或等于所述第二舒张压阈值、所述心率大于或等于所述第一心率阈值且小于或等于所述第二心率阈值、所述血氧饱和度大于或等于所述第一血氧饱和度阈值、以及确定到所述用户不存在所述异常行为的情况下，确定所述反映用户身体状况的数据未出现异常。

21.根据权利要求1至20任一项所述的方法，其特征在于，所述方法还包括：

在确定所述第一终端设备与所述第二终端设备成功建立所述第一网络连接、或所述第一终端设备接收到用户发起的结束求救模式的第四触控指令后，结束求救模式；或者，

在确定所述第一终端设备已获得稳定的网络信号后，弹窗请求用户确认是否解除求救模式；在接收到用户确认解除求救模式的确认指令后，结束求救模式；

所述结束求救模式，具体包括：

在确定所述第一终端设备开启了所述强力求救模式的情况下，关闭所述强力求救模式；或者，在确定所述第一终端设备开启了所述低功耗求救模式的情况下，关闭所述低功耗求救模式。

22.一种求救方法，应用于第一终端设备，其特征在于，所述方法包括：

当满足第一预设条件时，开启一键求救模式；

在开启所述一键求救模式后，根据第一预设开启规则开启所述强力求救模式或所述低功耗求救模式中的一种求救工作模式；

其中，所述第一终端设备在同一时刻开启所述强力求救模式和所述低功耗求救模式中的一种求救工作模式；在相同长度的时间窗口下所述第一终端设备在所述强力求救模式下的功耗大于所述第一终端设备在所述低功耗求救模式下的功耗；所述强力求救模式和所述低功耗求救模式用于和第二终端设备建立第一网络连接。

23.根据权利要求22所述的方法，其特征在于，所述第一预设条件为：所述第一终端设备未开启所述一键求救模式、所述强力求救模式或所述低功耗求救模式中的任一种求救工作模式、且所述第一终端设备处于无网络状态、以及反映用户身体状况的数据出现异常。

24.根据权利要求22或23所述的方法，其特征在于，所述当满足第一预设条件时，开启一键求救模式包括：

当满足第一预设条件时，输出第三提示信息，所述第三提示信息用于请求用户确定是否开启所述一键求救模式；

在未接收到所述用户发起的拒绝开启所述一键求救模式的指令或接收到所述用户发起的确定开启所述一键求救模式的指令的情况下，开启所述一键求救模式。

25.根据权利要求22至24任一项所述的方法，其特征在于，所述根据第一预设开启规则开启所述强力求救模式或所述低功耗求救模式中的一种求救工作模式包括：

确定所述第一终端设备的当前电量是否大于第五电量阈值；

在确定所述当前电量大于所述第五电量阈值的情况下，开启所述强力求救模式。

26.根据权利要求25所述的方法，其特征在于，所述方法还包括：

在确定所述当前电量小于或等于所述第五电量阈值的情况下，开启所述低功耗求救模式。

27.根据权利要求25所述的方法，其特征在于，所述方法还包括：

在所述当前电量小于或等于所述第五电量阈值的情况下，确定当前电量是否大于或等于第六电量阈值，所述第六电量阈值小于所述第五电量阈值；

在确定所述当前电量大于或等于所述第六电量阈值的情况下，若反映用户身体状况的数据出现异常，开启所述强力求救模式；若所述反映用户身体状况的数据未出现异常，开启所述低功耗求救模式；

在确定所述当前电量小于所述第六电量阈值的情况下，开启所述低功耗求救模式。

28.一种终端设备，其特征在于，所述电子设备包括：一个或多个处理器、存储器和显示屏；

所述存储器与所述一个或多个处理器耦合，所述存储器用于存储计算机程序代码，所述计算机程序代码包括计算机指令，所述一个或多个处理器调用所述计算机指令以使得所述电子设备执行如权利要求1-27任一项所述的方法。

29.一种芯片系统，所述芯片系统应用于电子设备，所述芯片系统包括一个或多个处理器，所述处理器用于调用计算机指令以使得所述电子设备执行如权利要求1-27中任一项所述的方法。

30.一种计算机可读存储介质，包括指令，其特征在于，当所述指令在电子设备上运行时，使得所述电子设备执行如权利要求1-27中任一项所述的方法。