CN113903145A - 求救方法、电子设备及计算机可读存储介质 - Google Patents

Abstract

本申请实施例公开了一种求救方法、电子设备及计算机可读存储介质，该求救方法包括：在电子设备处于预求救状态时，根据用户与所述电子设备的交互，选择保持预求救状态、进入求救状态、或者进入非求救状态；在进入所述求救状态后，使所述用户对应的求救目标用户的电子设备接收到所述用户的求救消息。本申请实施例将求救过程分为三个状态，当用户察觉到危险，而又不确定是否会发生危险时，先进入预求救状态，并在真发生危险时，快速进入求救状态，发出求救，既避免虚警造成人力浪费，又避免在确实发生危险时来不及求救。

Description

求救方法、电子设备及计算机可读存储介质

技术领域

本发明涉及通信技术领域，尤其涉及一种求救方法、电子设备及计算机可读存储介质。

背景技术

这里的陈述仅提供与本发明有关的背景信息，而不必然地构成现有技术。

人们在遇到危险时，常通过手机报警、用聊天软件发消息等方式求救，但有时人们并不确定是否会遇险，而在遇险时又可能没有时间求救。

发明内容

本申请的目的在于提供了一种求救方法、电子设备及计算机可读存储介质，以便于提高求救的准确性。

第一方面，本申请实施例提供了一种求救方法，所述求救方法应用于电子设备，所述方法包括：在所述电子设备处于预求救状态时，根据用户与所述电子设备的交互，选择保持所述预求救状态、进入求救状态、或者进入非求救状态；在进入所述求救状态后，使所述用户对应的求救目标用户的电子设备接收到所述用户的求救消息；在进入所述非求救状态后，等待进入预求救状态的指令，并在接收到所述指令后进入所述预求救状态，或者，停止所述方法。

在一些实施例中，所述求救目标用户包括预设用户、处于所述电子设备实时位置一定区域的其他用户、处于或者管辖所述电子设备实时位置一定区域的治安工作人员的至少一种。

在一些实施例中，所述使所述用户对应的求救目标用户的电子设备接收到所述用户的求救消息包括：生成求救消息，直接发送或者经由服务器发送所述求救消息给所述求救目标用户的电子设备；或者，与服务器同步用户安全状态，使得在所述用户的用户安全状态为所述求救状态时，服务器生成求救消息，确定所述用户对应的求救目标用户，并向所述求救目标用户发送所述求救消息，其中，所述用户安全状态为所述预求救状态、所述求救状态或所述非求救状态。

在一些实施例中，所述根据用户与所述电子设备的交互，选择保持所述预求救状态、进入求救状态、或者进入非求救状态包括：在接收到保持所述预求救状态的交互时，保持所述预求救状态；在接收到进入所述非求救状态的交互时，进入所述非求救状态；在接收到进入所述求救状态的交互时，或者，在未接收到保持所述预求救状态的交互、并且未接收到进入所述非求救状态的交互时，进入所述求救状态。

在一些实施例中，所述根据用户与所述电子设备的交互，选择保持所述预求救状态、进入求救状态、或者进入非求救状态包括：在以预定的终止方式终止所述预求救状态时，进入所述非求救状态；或者，在以非所述预定的终止方式终止所述预求救状态时，进入所述求救状态。

在一些实施例中，所述根据用户与所述电子设备的交互，选择保持所述预求救状态、进入求救状态、或者进入非求救状态包括：在进入所述预求救状态时，获取所述预求救状态的维持时间，并在自进入所述预求救状态起的所述维持时间内，保持所述预求救状态；当在所述维持时间结束前，接收到预定的终止所述预求救状态的交互时，进入所述非求救状态；当在所述维持时间内，未接收到维持所述预求救状态的交互，且未接收到预定的终止所述预求救状态的交互时，进入所述求救状态。

在一些实施例中，所述方法还包括：当在所述维持时间结束前，接收到维持所述预求救状态的交互时，重新在所述维持时间内保持所述预求救状态，或者获取新的维持时间，并在所述新的维持时间内保持所述预求救状态。

在一些实施例中，所述根据用户与所述电子设备的交互，选择保持所述预求救状态包括：以预定的时间规则输出提示信息；当在输出所述提示信息后的预定时间内接收到维持所述预求救状态的交互时，保持所述预求救状态。

在一些实施例中，在处于所述预求救状态，且接收到保持所述预求救状态的交互时，在所述交互持续的时间内保持所述预求救状态，和/或，重新在预定的维持时间内保持所述预求救状态。

在一些实施例中，所述交互为满足预定规则的对所述电子设备按键或触控屏的手势、语音指令、密码的一种或多种。

在一些实施例中，所述方法还包括：在处于所述预求救状态时，采集预求救内容信息；在生成所述求救消息时使所述求救消息包含所述预求救内容信息，或者将所述预求救内容信息发送给服务器，使得服务器将所述预求救内容信息携带于所述求救消息中。

在一些实施例中，所述方法还包括：与服务器同步用户安全状态，所述用户安全状态为所述预求救状态、所述求救状态、所述非求救状态的一种；向服务器发送包含设备状态信息的消息，使得服务器根据所述设备状态信息确定是否将所述用户安全状态从所述预求救状态转换为所述求救状态，并在将所述用户安全状态转换为所述求救状态后向所述求救目标用户的电子设备发送所述求救消息；其中，所述设备状态信息包括所述电子设备的剩余电量、信号强度、实时位置、当前时间的至少一种。

在一些实施例中，所述方法还包括：在进入所述求救状态后，播放预定的求救音频文件。

第二方面，本申请实施例提供了一种电子设备，包括：处理器、存储有所述处理器可执行指令的存储器，当所述指令被所述处理器执行时，实现上述第一方面任一项所述的方法。

在一些实施例中，所述电子设备还包括与所述处理器耦合的触控屏，所述触控屏用于在所述处理器的控制下与用户交互。

在一些实施例中，所述电子设备还包括与所述处理器耦合的按键，所述按键用于接收用户的指令。

在一些实施例中，所述终端设备还包括通信接口，所述通信接口与所述处理器通信，所述通信接口用于在所述处理器的控制下与其他设备(如网络设备等)进行通信。

第三方面，本申请实施例提供了一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时，实现上述第一方面任一项所述的方法。

本申请实施例将求救过程分为三个状态，当用户察觉到危险，而又不确定是否会发生危险时，先进入预求救状态，并在真发生危险时，快速进入求救状态，发出求救，既避免虚警造成人力浪费，又避免在确实发生危险时来不及求救。

附图说明

图1为求救方法的实现流程示意图一。

图2为求救方法的状态转换图一。

图3为求救方法的状态转换图二。

图4为求救方法的状态转换图三。

图5为求救方法的状态转换图四。

图6为求救方法的实现流程示意图二。

图7为求救方法的实现流程示意图三。

图8为求救方法的实现流程示意图四。

图9为求救方法的实现流程示意图五。

图10为电子设备的组成结构示意图。

图11为服务器的组成结构示意图。

具体实施方式

下面将参照附图更详细地描述本公开的实施例。虽然附图中显示了本公开的某些实施例，然而应当理解的是，本公开可以通过各种形式来实现，而且不应该被解释为限于这里阐述的实施例，相反提供这些实施例是为了更加透彻和完整地理解本公开。应当理解的是，本公开的附图及实施例仅用于示例性作用，并非用于限制本公开的保护范围。

应当理解，本公开的方法实施方式中记载的各个步骤可以按照不同的顺序执行，和/或并行执行。此外，方法实施方式可以包括附加的步骤和/或省略执行示出的步骤。本公开的范围在此方面不受限制。

本文使用的术语“包括”及其变形是开放性包括，即“包括但不限于”。术语“基于”是“至少部分地基于”。术语“一个实施例”表示“至少一个实施例”；术语“另一实施例”表示至少一个另外的实施例；术语“一些实施例”表示“至少一些实施例”。其他术语的相关定义将在下文描述中给出。

需要注意，本公开中提及的“第一”、“第二”等概念仅用于对不同的装置、模块或单元进行区分，并非用于限定这些装置、模块或单元所执行的功能的顺序或者相互依存关系。

需要注意，本公开中提及的“一个”、“多个”的修饰是示意性而非限制性的，本领域技术人员应当理解，除非在上下文另有明确指出，否则应该理解为“一个或多个”。

人们常常并不能马上确认是否会发生危险，可能仅在施害者真正实施犯罪的时候才能够确认。而人们在不确认、或者不够确认会遇到危险的时候，往往不会报警或者向亲朋好友求助。因此，当危险发生时，人们需要应对危险而没有空闲再发出求救信息。此外，目前发出求救信息也较为繁琐，如在报警时，需要打通电话，然后再陈述险情，当接警员接通电话却未听到报警人说话时，可能会忽略该报警。

为解决上述问题，本申请提出一种求救方法以及所述方法适用的电子设备。

请参见图1，是本申请一实施例提供的一种求救方法的流程示意图，应用于电子设备（在下文中有时也用设备一词，与电子设备是相同的涵义）中。示例性的，电子设备包括但不限于诸如移动电话、笔记本电脑、数字广播接收器、个人数字助理（Personal DigitalAssistant，PDA）、平板电脑（PAD）、便携式多媒体播放器（Portable Media Player，PMP）、车载电子设备（例如车载导航电子设备）、可穿戴式设备、防护设备（如电棍、防狼喷雾等）等等。如图1所示的方法包括如下实施步骤：

步骤101，在电子设备处于预求救状态时，根据用户与所述电子设备的交互，选择保持所述预求救状态、进入求救状态、或者进入非求救状态。

步骤102，在进入所述求救状态后，使所述用户对应的求救目标用户的电子设备接收到所述用户的求救消息。

步骤103，在进入所述非求救状态后，等待进入预求救状态的指令，并在接收到所述指令后进入所述预求救状态，或者，停止所述方法。

在本实施例中，将用户安全状态分为三个状态：预求救状态、求救状态、非求救状态。当用户查觉到危险，而又不确定是否会真发生危险时，可以先进入预求救状态，并在遇到危险后、或者确信将发生危险时，再进入求救状态。而在没有危险时，则进入非求救状态。在用户一直不确定是否会发生危险时，可以一直保持在预求救状态。

电子设备可以在接收到预定的指令后进入预求救状态。具体的，电子设备可以以触控屏按钮或手势、基于电源键音量键等按键的快捷键、语音指令等至少一种方式触发进入预求救状态的指令。例如，用户连续按压电源键7次后进入预求救状态。

在步骤101中，在电子设备处于预求救状态时，根据用户与电子设备的交互，选择保持预求救状态、进入求救状态、或者进入非求救状态。

所述用户与电子设备的交互，为满足预定规则的对电子设备按键或触控屏的手势（如点击、双击、长按、滑动等）、语音指令、密码（图案密码、数字密码等）的一种或多种。

图2示出了一种根据用户与电子设备的交互，选择保持预求救状态、进入求救状态、或者进入非求救状态的实施方法。在图2所示的实施方法中，电子设备中预设有保持预求救状态的交互、进入求救状态的交互以及进入非求救状态的交互，当用户与电子设备的交互与预设的所述保持预求救状态的交互匹配时，使用户安全状态保持为预求救状态；当用户与电子设备的交互与预设的所述进入求救状态的交互匹配时，将用户安全状态转换为求救状态；当用户与电子设备的交互与预设的所述进入非求救状态的交互匹配时，将用户安全状态转换为非求救状态。所述保持预求救状态的交互、所述进入求救状态的交互以及所述进入非求救状态的交互分别为满足预定规则的对电子设备按键或触控屏的手势（如点击、双击、长按、滑动等）、语音指令、密码（图案密码、数字密码等）等的一种或多种，示例性的，所述保持预求救状态的交互为对触控屏的长按，所述进入求救状态的交互为所述长按的终止（如用户手指与触控屏的脱离），所述进入非求救状态的交互为手指在触控屏上滑动形成预设的轨迹，因此，当当前为预求救状态，且用户手指按住触控屏某一个位置不动时，一直保持在预求救状态，手指脱离触控屏时，进入求救状态，手指长按后在触控屏上滑动形成预设的进入非求救状态的轨迹，再脱离触控屏时，则进入非求救状态；在另一个例子中，所述保持预求救状态的交互为对触控屏的第一预定轨迹的滑动单向性滑动（如手指在触控屏上画圆），所述进入求救状态的交互为第二预定轨迹的滑动（如上滑、下滑、左滑、右滑等），所述进入非求救状态的交互为以上两种动作之外的其他动作，如其他轨迹的手势、按钮或按键的点击等。

图3示出了一种根据用户与电子设备的交互，选择保持预求救状态、进入求救状态、或者进入非求救状态的实施方法。在图3所示的实施方法中，电子设备中预设有保持预求救状态的交互以及进入非求救状态的交互，当用户与电子设备的交互与预设的所述保持预求救状态的交互匹配时，使用户安全状态保持为预求救状态；当用户与电子设备的交互与预设的所述进入非求救状态的交互匹配时，将用户安全状态转换为非求救状态；当用户与电子设备的交互既不与预设的所述保持预求救状态的交互匹配，也不与预设的所述进入非求救状态的交互匹配时，将用户安全状态转换为求救状态。示例性的，所述保持预求救状态的交互为对触控屏的长按，所述进入非求救状态的交互为手指在触控屏上滑动形成预设的轨迹，因此，当当前为预求救状态，且用户手指按住触控屏某一个位置不动时，一直保持在预求救状态，手指长按后在触控屏上滑动形成预设的进入非求救状态的轨迹，再脱离触控屏时，则进入非求救状态，手指停止长按而又未在触控屏上滑动形成预设的轨迹（如手势滑动形成其他的轨迹、手指直接脱离触控屏，等等），进入求救状态。

图4示出了一种根据用户与电子设备的交互，选择进入求救状态、或者进入非求救状态的实施方法。在图4所示的实施方法中，电子设备中预设有预定的终止方式（终止指的是预求救状态的终止），当用户与电子设备的交互与所述预定的终止方式匹配时，转换到非求救状态，否则进入到求救状态。示例性的，所述预定的终止方式为在限定时间内（如5s）点击触控屏上的取消求救按钮（或者采用语音指令、密码等其他方式），因此，当用户不再进行保持预求救状态的交互（如长按、预定轨迹的滑动等）时，若用户在停止所述保持预求救状态的交互后的所述限定时间内点击触控屏上的取消求救按钮，则进入非求救状态，否则进入求救状态。

图5示出了一种根据用户与电子设备的交互，选择保持预求救状态、进入求救状态、或者进入非求救状态的实施方法。在图5所示的实施方法中，在当前处于预求救状态，且接收到维持预求救状态的交互后，在一个维持时间内将用户安全状态保持在预求救状态（可以允许用户通过交互转换到其它状态）。

在一实施方式中，所述维持时间可以是技术人员或者用户预先设置的，如设置为5秒、10秒、30秒、1分钟、5分钟、10分钟等值，例如，用户通过以预定频率与设备进行维持预求救状态的交互（如每5s点击一次触控屏或按键），使设备一直保持在预求救状态。

在另一实施方式中，在进入预求救状态时通过界面等方式获取所述维持时间，所述维持时间在之后的交互中保持不变（在进入求救状态或者进入非求救状态前保持不变），或者再次接收用户对所述维持时间的更改，例如，用户在察觉可能有危险后，可以操作设备进入预求救状态，并在设备界面上设置所述维持时间（如10分钟），使得设备在所述维持时间内，保持在预求救状态，用户只需要每次在所述维持时间内进行一次维持预求救状态的交互，就可以一直保持预求救状态，而不需要一直与设备进行交互。

在所述维持时间内，设备等待接收用户与设备的交互，并在接收到所述交互后，根据所述交互选择保持预求救状态、进入求救状态、或者进入非求救状态，并在选择保持预求救状态后，重新在所述维持时间内保持预求救状态。所述选择保持预求救状态、进入求救状态、或者进入非求救状态的交互可以是图2、图3、或图4所示实施例的交互。例如，用户每隔一定时间（所述维持时间），与设备进行一次保持预求救状态的交互（如点击、预定轨迹的滑动等），则保持在预求救状态；与设备进行一次进入非求救状态的交互（如点击设备界面上的取消按键、输入取消密码等），则进入的非求救状态；在所述维持时间结束前，用户未进行任何交互（或者进行一次进入求救状态的交互），则进入求救状态。

在又一实施方式中，在进入预求救状态时通过界面等方式获取所述维持时间，并且设备只接受进入求救状态的交互、或者进入非求救状态的交互。例如，用户可以在进入预求救状态时，设置10分钟的维持时间，在所述维持时间结束前，用户可以点击设备界面上的取消按钮，进入非求救状态，或者在所述维持时间结束后自动进入求救状态（设备界面中也可以包含求救按钮，用户点击后，设备进入求救状态）。

可选的，设备在所述维持时间结束前的预定时间内（如在所述维持时间结束前10s），输出提示信息（可以以声音、震动等方式输出提示信息），使得用户经提示及时地与设备交互，避免用户错过时间而造成设备进入了非用户期望的状态。

图6示出了一种根据用户与电子设备的交互，选择保持预求救状态的实施方法，包括：

步骤1011，以预定的时间规则输出提示信息；

步骤1012，当在输出所述提示信息后的预定接收时间内接收到维持预求救状态的交互时，保持预求救状态。

所述以预定的时间规则输出提示信息，可以是以固定的频率（如每5s一次、10s一次、30s一次、1分种一次等频率）输出提示信息，也可以是以非固定的频率输出提示信息（如相邻两次输出提示信息间隔的时间为从一个时间范围内以一定规律选择的一个时间，如从5s到30s内以均匀分布的方式随机选择）。可以以声音、震动等方式输出提示信息。

在每次输出所述提示信息后，需要用户在在预定时间内与设备进行交互。当在输出所述提示信息后的预定接收时间内接收到维持预求救状态的交互时，保持预求救状态，例如，设备在每次输出提示信息（如震动1s）后，从[10s,20s]范围内随机选择一个时间，并在所选择的时间后输出下一次提示信息；当用户在每次输出提示信息的3s（向述预定接收时间为3s）内与设备进行一次维持预求救状态的交互时（如点击一次、以预定轨迹滑动等），保持预求救状态，否则选择进入求救状态或者非求救状态。

示例性的，当用户察觉危险时，进入预求救状态，为保持预求救状态，用户每隔数秒就与设备进行一次交互；当用户遇到危险时，需要应对危险，而不再与设备进行交互，使得设备在所述预定接收时间结束后，自动进入求救状态（为减少虚警，也可以在连续数次输出提示信息而未收到维持预求救状态的交互、进入非求救状态的交互后再进入求救状态），而不需要再人为触发求救。

在至少一个实施例中，保持预求救状态的交互为可以一直持续的交互，如长按、手指在触控屏上以预定轨迹一直滑动等，设备在所述交互的持续时间内，保持在预求救状态。例如，用户察觉到危险时，进入预求救状态后，手指持续按压触控屏，设备在用户持续按压时保持在预求救状态。

可选的，设备在保持预求救状态的交互结束后的一定时间内保持在预求救状态。例如，在长按后的5s内依然保持在预求救状态，若用户在5s内再次长按，则继续保持预求救状态，否则在5s后进入求救状态。这种方式可以使得避免用户错误地结束保持预求救状态的交互。

可选的，电子设备在从一个状态转换到另一个状态时，输出状态转换提示信息，如以震动、播放预定的状态转换提示音等方式。

可选的，电子设备在从一个状态转换到另一个状态时，在预定时间内允许用户撤销所述状态转换。具体的，电子设备在接收到预定的撤销指令后撤销所述状态转换，所述撤销指令可以以触控屏按钮的点击等方式触发。在所述撤销指令被触发后，可以将状态转换为所述状态转换之前的状态，如在从预求救状态转换到求救状态后，撤销指令被触发时，再转换回预求救状态；也可以是预定的某一个状态，如非求救状态；也可以是除所述状态转换前后的两个状态之外的另一个状态。

应当理解的是，以上并非对所述交互的所有的穷举，还可以采用其他替代的方式。

在步骤102中，在进入求救状态后，使所述用户对应的求救目标用户的电子设备接收到所述用户的求救消息。

所述求救目标用户包括预设用户、处于电子设备实时位置一定区域的其他用户、处于或者管辖电子设备实时位置一定区域的治安工作人员的至少一种。

在一种实施方式中，用户预先设置一个或多个用户作为所述求救目标用户。

在另一种实施方式中，将用户求救时所处位置附近的其他用户作为所述求救目标用户。具体的，设备获取实时位置信息，并发送给服务器，服务器保存有用户及其位置（实时位置、和/或经常滞留位置（如居住地址、工作地址等））的对应关系，服务器根据求救用户的实时位置信息，从所述对应关系中检索得到所述求救用户附近（如500米内）的其他用户，作为所述求救目标用户。

在又一种实施方式中，将处于或者管辖电子设备实时位置一定区域的治安工作人员作为所述求救目标用户。治安工作人员如警察、保安等。服务器中保存有用户及其位置、管辖区域的对应关系，服务器根据求救用户的实时位置信息，从所述对应关系中检索得到所述求救用户附近（如500米内）、或管辖所述实时位置的治安工作人员用户，作为所述求救目标用户。

所述求救目标用户可以为某一种或多种，如只发送给预先设置的紧急联系人，同时发送给紧急联系人以及附近的人，等等。或者根据不同的场景，将求救消息发送给对应场景的求救目标用户，如预设有不同的危险等级，不同的危险等级预设有不同的求救目标用户，用户可以在进入或者处于预求救状态、或者处于求救状态时，设置当前危险等级。

在一种实施方式中，所述使所述用户对应的求救目标用户的电子设备接收到所述用户的求救消息包括：生成求救消息，直接发送或者经由服务器发送所述求救消息给所述求救目标用户的电子设备。所述求救消息中包含所述用户的身份信息（如用户标识、用户账号、姓名、年龄、性别、身份证号码、电话号码等至少一种）、当前位置信息等至少一种。例如，以短信的方式直接发送到所述求救目标用户的电子设备；或者，服务器根据所述求救消息中的所述用户的用户标识，以及服务器中存储的用户与求救目标用户的对应关系，或者根据所述求救消息中的实时位置信息，以及服务器中存储的用户与位置（实时位置、经常滞留位置、管辖区域等）的对应关系，确定所述求救目标用户，并以网络通信或者短信等方式向所述求救目标用户的电子设备发送求救消息；或者，所述求救消息中还包含所述求救目标用户的用户标识（如用户账号、身份证号码、电话号码等至少一种），将所述求救消息发送给服务器后，服务器根据所述求救消息中包含所述求救目标用户的用户标识以网络通信或者短信等方式向所述求救目标用户的电子设备发送求救消息。

在另一种实施方式中，所述使所述用户对应的求救目标用户的电子设备接收到所述用户的求救消息包括：与服务器同步用户安全状态，使得在所述用户的用户安全状态为求救状态时，服务器生成求救消息，确定所述用户对应的求救目标用户，并向所述求救目标用户发送所述求救消息，其中，用户安全状态为预求救状态、求救状态或非求救状态。在与服务器同步用户安全状态后，服务器可以在所述用户处于求救状态时，自动生成求救消息，确定所述用户对应的求救目标用户，并向所述求救目标用户发送所述求救消息。在所述求救目标用户包括附近的用户时，还与服务器同步实时位置信息。

在步骤103中，在进入非求救状态后，等待进入预求救状态的指令，并在接收到所述指令后进入预求救状态，或者，停止所述方法。例如，在进入非求救状态后，显示等待界面，并在所述等待界面中等待进入预求救状态的指令（如显示进入预求救状态的控件，所述进入预求救状态的指令在所述控件被点击时触发，或者在接收到用户对触控屏、按键等的预定手势后触发所述进入预求救状态的指令），并在接收到所述指令后进入预求救状态；或者，在进入非求救状态后，停止所述方法（计算机程序结束运行），设备在接收到所述指令后进入预求救状态（操作系统接收到预定指令后打开包含所述方法的程序，程序启动后进入预求救状态）。

在本申请实施例中，将求救过程分为三个状态：预求救状态、求救状态、非求救状态，在电子设备处于预求救状态时，根据用户与电子设备的交互，选择保持预求救状态、进入求救状态、或者进入非求救状态，在进入求救状态后，再发出求救，使得用户可以在察觉到危险，而又不确定是否会发生危险时，先进入预求救状态，并在真发生危险时，快速进入求救状态，发出求救，既避免虚警造成人力浪费，又避免在确实发生危险时来不及求救。

在一些实施方式中，保持设备处于预求救状态需要用户不断地与设备交互，但用户即使不与设备交互，也能自动进入求救状态，发出求救，从而使得危险发生时，用户可以专心地应对危险，而不需要再担心求救的问题。即使迅速被歹人制服，设备也能自动发出求救信息。

在一些实施方式中，用户可以预先设置维持时间，设备在维持时间内保持预求救状态，若用户在维持时间结束后依然未与设备进行对应的交互，会自动进入求救状态，发出求救。能够减少用户操作，方便用户。

请参见图7，是本申请一实施例提供的一种求救方法的流程示意图。如图7所示的方法包括如下实施步骤：

步骤101，在电子设备处于预求救状态时，根据用户与电子设备的交互，选择保持预求救状态、进入求救状态、或者进入非求救状态。

步骤104，在处于预求救状态时，采集预求救内容信息。

步骤105，在生成所述求救消息时使所述求救消息包含所述预求救内容信息，或者将所述预求救内容信息发送给服务器，使得服务器将所述预求救内容信息携带于所述求救消息中。

在本申请实施例中，在处于预求救状态时，还采集预求救内容信息。所述预求救内容信息为所述用户录入的文字、语音和/或视频，表示所述用户对当前险情的描述，例如，所述用户将当前险情以口述的方式描述成“我怀疑有人在跟踪我”，或者，所述预求救内容信息为当前环境的录音和/或录像数据。在一种实施方式中，设备在处于预求救状态时，自动采集录音和/或录像数据，用户可以口述险情，或者将摄像头对准可疑人，或者其他对于描述险情有价值的目标，等等。在另一种实施方式中，设备在用户的接收到用户的采集指令后采集所述预求救内容信息，所述采集指令可以通过预定手势、控件、语音指令等触发。

当在所述求救消息中包含所述预求救内容信息时，被求救人员可以根据所述预求救内容中的数据，了解所述用户求救时的环境。

在一种实施方式中，在采集所述预求救内容信息后，将其保存在设备中，并在进入求救状态后，在生成所述求救消息时，使其包含所述预求救内容信息，直接发送或者经由服务器发送至所述求救目标用户的电子设备。

在另一种实施方式中，在采集所述预求救内容信息时，以预定的传输策略（如实时传输协议等传输标准、或者其他自定义传输协议）将采集到的所述预求救内容信息同步到服务器中，并且在处于求救状态时，服务器发送至所述求救目标用户的电子设备的求救消息包含所述预求救内容信息。

在本申请实施例中，还可以包含进入非求救状态的处理步骤，与前述实施例一致，这里不再赘述。

在本申请实施例中，在处于预求救状态时，采集预求救内容信息，并在求救消息中包含所述预求救内容信息，使得可以在险情发生之前，将可能会发生的险情、当前的环境等信息保存下来，并在险情发生时，将其作为求救消息的一部分发送出去。因此，即使用户无法在应对险情的同时再描述险情，也能使求救目标用户获知险情内容，从而更好地施救，同时所述预求救内容信息也可以作为向警察局等部门报警的证据。

请参见图8，是本申请一实施例提供的一种求救方法的流程示意图。如图8所示的方法包括如下实施步骤：

步骤101，在电子设备处于预求救状态时，根据用户与电子设备的交互，选择保持预求救状态、进入求救状态、或者进入非求救状态。

步骤106，与服务器同步用户安全状态，用户安全状态为预求救状态、求救状态、非求救状态的一种。

步骤107，向服务器发送包含设备状态信息的消息，使得服务器根据所述设备状态信息确定是否将用户安全状态从预求救状态转换为求救状态，并在将用户安全状态转换为求救状态后向所述求救目标用户的电子设备发送所述求救消息，其中，所述设备状态信息包括电子设备的剩余电量、信号强度、实时位置、当前时间的至少一种。

在本申请实施例中，设备与服务器同步用户安全状态，并向服务器发送包含设备状态信息的消息，使得服务器据所述设备状态信息确定是否将用户安全状态从预求救状态转换为求救状态。例如，在某用户的设备正处于预求救状态、设备电量充足、网络信号良好的情况下，与服务器断开连接（可以将条件限制为在一段时间内断开连接，如5分钟内），可以视为用户发生危险，则服务器可以自动地将用户安全状态从预求救状态转换为求救状态，并在将用户安全状态转换为求救状态后向所述求救目标用户的电子设备发送所述求救消息。服务器也可采用其他基于电子设备的剩余电量、信号强度、实时位置、当前时间等的至少一种构建的规则判断用户是否处于危险中，如实时位置为偏僻处（可以根据地图数据等判断是否为偏僻处，如该位置类型为森林、湖泊等地，或者附近建筑少，等等）、时间为夜晚，等等。

可选的，设备在正处于预求救状态、设备电量充足、网络信号良好的情况下，与服务器断开连接后，可以以震动、语音播放等方式通知用户，使得用户在不处于危险时，调整设备（如重新开机等），使设备重新与服务器建立连接，更新用户安全状态，防止服务器错误地为用户发出求救消息。

可选的，服务器在条件满足，自动将用户从预求救状态转换为求救状态前，向用户的设备发送确认消息（如以短信等方式发送），设备可以接收用户的确认和/或取消指令。在一种实施方式中，确认和/或取消指令可以以密码的方式输入，如预先设置两个密码，当输入一个密码时，触发确认指令，当输入另一个密码时，触发取消指令。歹徒无法得到哪个密码是确认，哪个密码是取消，从而提高求救消息发出的成功率。当服务器未接收到取消指令、未接收到作何反馈消息、或者接收到密码错误的消息时，自动将用户从预求救状态转换为求救状态。

可选的，服务器在条件满足，自动将用户从预求救状态转换为求救状态后，向用户的设备发送将用户从预求救状态转换为求救状态的消息。用户的设备还可以基于用户的指令发送撤销消息（同样可以以密码输入等方式，当密码为预设的撤销密码时，发送撤销消息，否则不发送，或者发送密码错误消息），服务器在接收到所述撤销消息后，再向所述求救目标用户发送求救撤销消息，由所述求救目标用户自行判断是否危险。

在在本申请实施例中，设备与服务器同步用户安全状态，并向服务器发送包含设备状态信息的消息，使得服务器据所述设备状态信息确定是否将用户安全状态从预求救状态转换为求救状态。即使用户突然被制服、设备被损坏等，服务器也可以自动判断用户是否危险，从而自动为用户发送求救消息，提高了求救消息发出的成功率。

可选的，在本申请至少一个实施例中，所述方法还包括：

步骤108，在进入求救状态后，播放预定的求救音频文件。

所述求救音频文件为预先设置的能起到呼救作用的文件，如包含“救命”的语音文件，等等。在退出求救状态后，则停止播放所述求救音频文件。

图9是本申请实施例所述方法的一种流程示意图。

在本申请实施例中，设备在进入求救状态后，播放预定的求救音频文件，可以代替用户求救，吸引附近的人员前来救援，用户可以更专心地应对险情。

可以理解的是，本申请至少一个实施例所述的求救方法可以由建立通信连接（如蓝牙通信）的多个电子设备共同完成。例如，由第一电子设备（如可穿戴设备）获得与用户的交互，并发送给第二电子设备（如手机），第二电子设备根据所述交互选择对应的状态，并完成相应状态对应的动作。或者，如果电子设备为不具备远程通信能力的电子设备，可以通过建立了短程通信连接的具有远程通信能力的设备发送所述求救消息，例如，包含蓝牙模块的电子设备可以在与手机建立蓝牙连接后通过手机发送所述求救消息给所述求救目标用户。

此外，本申请至少一个实施例所述的方法可以集成在防护设备中，如电棍、防狼喷雾等，使得用户在防卫的同时，自动发出求救。具体的，防护设备具有进入预求救状态的指令触发部件（如按键、压力传感器等）、转换到求救状态的部件（可以与防护设备本身的触发部件相结合，如与电棍的电源按键结合，在按下电源按键时，进入求救状态）、转换到非求救状态的部件（可以与防护设备本身的触发部件相结合）。防护设备可以通过蓝牙连接手机将求救消息发送至求救目标用户，或者防护设备本身包含远程通信部件，并由远程通信部件发送求救消息。

图10示出了本发明一个示例性实施例提供的电子设备1000的结构框图。该电子设备1000可以是：移动电话、数字广播接收器、个人数字助理（Personal Digital Assistant，PDA）、平板电脑、MP3播放器(Moving Picture Experts Group Audio LayerIII，动态影像专家压缩标准音频层面3)、MP4(Moving Picture Experts Group Audio Layer IV，动态影像专家压缩标准音频层面4)播放器、可穿戴式设备、防护设备、笔记本电脑或台式电脑。

通常，电子设备1000包括有：处理器1001和存储器1002。

处理器1001可以包括一个或多个处理核心，比如4核心处理器、8核心处理器等。处理器1001可以为特定用途集成电路（Application Specific Integrated Circuit，ASIC）、数字信号处理器（Digital Signal Processor，DSP）、数字信号处理装置（Digital SignalProcessing Device，DSPD）、可编程逻辑装置（ProgRAMmable Logic Device，PLD）、现场可编程门阵列（Field ProgRAMmable Gate Array，FPGA）、中央处理器（Central ProcessingUnit，CPU）、控制器、微控制器、微处理器中的至少一种。处理器1001也可以包括主处理器和协处理器，主处理器是用于对在唤醒状态下的数据进行处理的处理器，也称CPU(CentralProcessing Unit，中央处理器)；协处理器是用于对在待机状态下的数据进行处理的低功耗处理器。在一些实施例中，处理器10001可以在集成有GPU(Graphics Processing Unit，图像处理器)，GPU用于负责显示屏所需要显示的内容的渲染和绘制。一些实施例中，处理器10001还可以包括AI(Artificial Intelligence，人工智能)处理器，该AI处理器用于处理有关机器学习的计算操作。

存储器1002可以包括一个或多个计算机可读存储介质，该计算机可读存储介质可以是非暂态的。存储器1002还可包括高速随机存取存储器，以及非易失性存储器，比如一个或多个磁盘存储设备、闪存存储设备。在一些实施例中，存储器1002中的非暂态的计算机可读存储介质用于存储至少一个指令，该至少一个指令用于被处理器1001所执行以实现本申请中方法实施例提供的求救方法。

在一些实施例中，电子设备1000还可选包括有：外围设备接口1003和至少一个外围设备。处理器1001、存储器1002和外围设备接口1003之间可以通过总线或信号线相连。各个外围设备可以通过总线、信号线或电路板与外围设备接口1003相连。具体地，外围设备包括：通信组件1004、触控屏1005、摄像头1006、音频电路1007、定位组件1008、电源1009、其他输入组件1010中的至少一种。

外围设备接口1003可被用于将I/O(Input/Output，输入/输出)相关的至少一个外围设备连接到处理器1001和存储器1002。在一些实施例中，处理器1001、存储器1002和外围设备接口1003被集成在同一芯片或电路板上；在一些其他实施例中，处理器1001、存储器和外围设备接口1003中的任意一个或两个可以在单独的芯片或电路板上实现，本实施例对此不加以限定。

通信组件1004用于接收和发射RF(Radio Frequency，射频)信号，也称电磁信号。通信组件105通过电磁信号与通信网络以及其他通信设备进行通信。通信组件1004将电信号转换为电磁信号进行发送，或者，将接收到的电磁信号转换为电信号。可选地，通信组件1004包括：天线系统、RF收发器、一个或多个放大器、调谐器、振荡器、数字信号处理器、编解码芯片组、用户身份模块卡等等。通信组件1004可以包括至少一种短距离通信模块，例如是基于Hilink协议、WiFi(IEEE 802.11协议)、Mesh、蓝牙、ZigBee、Thread、Z-Wave、NFC、UWB、LiFi等短距离无线通信协议进行短距离无线通信的任意模块，通信组件1004也可以包括远程通信模块，例如是进行WLAN、GPRS、2G/3G/4G/5G远程通信的任意模块。

触控屏1005用于显示UI(User Interface，用户界面)、采集在显示屏1005的表面或表面上方的触摸信号的能力。该UI可以包括图形、文本、图标、视频及其它们的任意组合。该触摸信号可以作为控制信号输入至处理器1001进行处理。此时，触控屏1005还可以用于提供虚拟按钮和/或虚拟键盘，也称软按钮和/或软键盘。在一些实施例中，触控屏1005可以为一个，设置电子设备1000的前面板；在另一些实施例中，触控屏1005可以为至少两个，分别设置在电子设备1000的不同表面或呈折叠设计；在再一些实施例中，触控屏1005可以是柔性显示屏，设置在电子设备1000的弯曲表面上或折叠面上。甚至，触控屏1005还可以设置成非矩形的不规则图形，也即异形屏。触控屏1005可以采用LCD(Liquid Crystal Display，液晶显示屏)、OLED(Organic Light-Emitting Diode ,有机发光二极管)等材质制备。

摄像头组件1006用于采集图像或视频。可选地，摄像头组件1006包括前置摄像头和后置摄像头。通常，前置摄像头设置在终端的前面板，后置摄像头设置在终端的背面。在一些实施例中，后置摄像头为至少两个，分别为主摄像头、景深摄像头、广角摄像头、长焦摄像头、红外摄像头中的任意一种，以实现主摄像头和景深摄像头融合实现背景虚化功能、主摄像头和广角摄像头融合实现全景拍摄以及VR(Virtual Reality，虚拟现实)拍摄功能或者其它融合拍摄功能。在一些实施例中，摄像头组件1006还可以包括闪光灯。闪光灯可以是单色温闪光灯，也可以是双色温闪光灯。双色温闪光灯是指暖光闪光灯和冷光闪光灯的组合，可以用于不同色温下的光线补偿。

音频电路1007可以包括麦克风和扬声器。麦克风用于采集用户及环境的声波，并将声波转换为电信号输入至处理器1001进行处理，或者输入至通信组件1004以实现语音通信。出于立体声采集或降噪的目的，麦克风可以为多个，分别设置在电子设备1000的不同部位。麦克风还可以是阵列麦克风或全向采集型麦克风。扬声器则用于将来自处理器1001或通信组件1004的电信号转换为声波。扬声器可以是传统的薄膜扬声器，也可以是压电陶瓷扬声器。当扬声器是压电陶瓷扬声器时，不仅可以将电信号转换为人类可听见的声波，也可以将电信号转换为人类听不见的声波以进行测距等用途。在一些实施例中，音频电路1007还可以包括耳机插孔。

定位组件1008用于定位电子设备1000的当前地理位置，以实现导航或LBS(Location Based Service ，基于位置的服务)。定位组件1008可以是基于美国的GPS(Global Positioning System，全球定位系统)、中国的北斗系统、俄罗斯的格雷纳斯系统或欧盟的伽利略系统的定位组件。

电源1009用于为电子设备1000中的各个组件进行供电。电源1009可以是交流电、直流电、一次性电池或可充电电池。当电源1009包括可充电电池时，该可充电电池可以支持有线充电或无线充电。该可充电电池还可以用于支持快充技术。

其他输入组件1010可以包括物理键盘、鼠标、按钮等。这些按钮可包括但不限于：音量按钮、启动按钮。

在一些实施例中，电子设备1000还包括有一个或多个传感器1017。该一个或多个传感器1017包括但不限于：加速度传感器1011、陀螺仪传感器1012、压力传感器1013、指纹传感器1014、光学传感器1015以及接近传感器1016。

加速度传感器1011可以检测以电子设备1000建立的坐标系的三个坐标轴上的加速度大小。比如，加速度传感器1011可以用于检测重力加速度在三个坐标轴上的分量。处理器1001可以根据加速度传感器1011采集的重力加速度信号，控制触摸显示屏1005以横向视图或纵向视图进行用户界面的显示、检测用户对电子设备1000的敲击动作。加速度传感器1011还可以用于游戏或者用户的运动数据的采集。

陀螺仪传感器1012可以检测电子设备1000的机体方向及转动角度，陀螺仪传感器1012可以与加速度传感器1011协同采集用户对电子设备1000的3D动作。处理器1001根据陀螺仪传感器1012采集的数据，可以实现如下功能：动作感应(比如根据用户的倾斜操作来改变UI)、拍摄时的图像稳定、游戏控制以及惯性导航。

压力传感器1013可以设置在电子设备1000的侧边框和/或触摸显示屏1005的下层。当压力传感器1013设置在电子设备1000的侧边框时，可以检测用户对电子设备1000的握持信号，由处理器1001根据压力传感器1013采集的握持信号进行左右手识别或快捷操作。当压力传感器1013设置在触摸显示屏1005的下层时，由处理器1001根据用户对触摸显示屏1005的压力操作，实现对UI界面上的可操作性控件进行控制。可操作性控件包括按钮控件、滚动条控件、图标控件、菜单控件中的至少一种。

指纹传感器1014用于采集用户的指纹，由处理器1001根据指纹传感器1014采集到的指纹识别用户的身份，或者，由指纹传感器1014根据采集到的指纹识别用户的身份。在识别出用户的身份为可信身份时，由处理器1001授权该用户执行相关的敏感操作，该敏感操作包括解锁屏幕、查看加密信息、下载软件、支付及更改设置等。指纹传感器1014可以被设置终端1000的正面、背面或侧面。当终端1000上设置有物理按键或厂商Logo时，指纹传感器1014可以与物理按键或厂商Logo集成在一起。

光学传感器1015用于采集环境光强度。在一个实施例中，处理器1001可以根据光学传感器1015采集的环境光强度，控制触摸显示屏1005的显示亮度。具体地，当环境光强度较高时，调高触摸触控屏1005的显示亮度；当环境光强度较低时，调低触控屏1005的显示亮度。在另一个实施例中，处理器1001还可以根据光学传感器1015采集的环境光强度，动态调整摄像头组件1006的拍摄参数。

接近传感器1016，也称距离传感器，通常设置在电子设备1000的前面板。接近传感器1016用于采集用户与电子设备1000的正面之间的距离。在一个实施例中，当接近传感器1016检测到用户与电子设备1000的正面之间的距离逐渐变小时，由处理器1001控制触摸显示屏1005从亮屏状态切换为息屏状态；当接近传感器1016检测到用户与电子设备1000的正面之间的距离逐渐变大时，由处理器1001控制触控屏1005从息屏状态切换为亮屏状态。

本领域技术人员可以理解，图10中示出的结构并不构成对电子设备1000的限定，可以包括比图示更多或更少的组件，或者组合某些组件，或者采用不同的组件布置。

本实施例的处理器1001执行的各步骤可以参见前述多个方法实施例中相应的电子设备端侧的求救方法，并具有相应方法实施例的有益效果，在此不再赘述。此外，本实施例的电子设备因用于对应实现前述求救方法，因此描述比较简单，相关部分可参照前述方法实施例中相应部分的描述，在此不再赘述。

需要指出，根据实施的需要，可将本发明实施例中描述的各个部件/步骤拆分为更多部件/步骤，也可将两个或多个部件/步骤或者部件/步骤的部分操作组合成新的部件/步骤，以实现本发明实施例的目的。

图11是本申请实施例提供的一种服务器的结构示意图，该服务器2000可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上处理器(centralprocessingunits，CPU)2001和一个或一个以上的存储器2002，其中，所述存储器2002中存储有至少一条指令，所述至少一条指令由所述处理器2001加载并执行以实现上述求救方法中对应服务器的步骤。

在一些实施例中，服务器2000还可选包括有：外围设备接口2003和至少一个外围设备。处理器2001、存储器2002和外围设备接口2003之间可以通过总线或信号线相连。外围设备包括：通信组件2004。通信组件2004用于接收和发射RF(Radio Frequency，射频)信号，也称电磁信号。通信组件2004通过电磁信号与通信网络以及其他通信设备进行通信。

本实施例的处理器2001执行的各步骤可以参见前述多个方法实施例中相应的服务器端侧的求救方法，并具有相应方法实施例的有益效果，在此不再赘述。此外，本实施例的服务器因用于对应实现前述求救方法，因此描述比较简单，相关部分可参照前述方法实施例中相应部分的描述，在此不再赘述。

上述根据本申请实施例的方法可在硬件、固件中实现，或者被实现为可存储在记录介质(诸如CD ROM、RAM、软盘、硬盘或磁光盘)中的软件或计算机代码，或者被实现通过网络下载的原始存储在远程记录介质或非暂时机器可读介质中并将被存储在本地记录介质中的计算机代码，从而在此描述的方法可被存储在使用通用计算机、专用处理器或者可编程或专用硬件(诸如ASIC或FPGA)的记录介质上的这样的软件处理。可以理解，计算机、处理器、微处理器控制器或可编程硬件包括可存储或接收软件或计算机代码的存储组件(例如，RAM、 ROM、闪存等)，当所述软件或计算机代码被计算机、处理器或硬件访问且执行时，实现在此描述的求救方法。此外，当通用计算机访问用于实现在此示出的求救方法的代码时，代码的执行将通用计算机转换为用于执行在此示出的求救方法的专用计算机。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及方法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明实施例的范围。

以上实施方式仅用于说明本发明实施例，而并非对本发明实施例的限制，有关技术领域的普通技术人员，在不脱离本发明实施例的精神和范围的情况下，还可以做出各种变化和变型，因此所有等同的技术方案也属于本发明实施例的范畴。

Claims (15)

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

在所述电子设备处于预求救状态时，根据用户与所述电子设备的交互，选择保持所述预求救状态、进入求救状态、或者进入非求救状态；

在进入所述求救状态后，使所述用户对应的求救目标用户的电子设备接收到所述用户的求救消息；

在进入所述非求救状态后，等待进入预求救状态的指令，并在接收到所述指令后进入所述预求救状态，或者，停止所述方法。

2.根据权利要求1所述的方法，其特征在于，所述求救目标用户包括预设用户、处于所述电子设备实时位置一定区域的其他用户、处于或者管辖所述电子设备实时位置一定区域的治安工作人员的至少一种。

3.根据权利要求1所述的方法，其特征在于，所述使所述用户对应的求救目标用户的电子设备接收到所述用户的求救消息包括：

生成求救消息，直接发送或者经由服务器发送所述求救消息给所述求救目标用户的电子设备；或者，

与服务器同步用户安全状态，使得在所述用户的用户安全状态为所述求救状态时，服务器生成求救消息，确定所述用户对应的求救目标用户，并向所述求救目标用户发送所述求救消息，其中，所述用户安全状态为所述预求救状态、所述求救状态或所述非求救状态。

4.根据权利要求1所述的方法，其特征在于，所述根据用户与所述电子设备的交互，选择保持所述预求救状态、进入求救状态、或者进入非求救状态包括：

在接收到保持所述预求救状态的交互时，保持所述预求救状态；

在接收到进入所述非求救状态的交互时，进入所述非求救状态；

在接收到进入所述求救状态的交互时，或者，在未接收到保持所述预求救状态的交互、并且未接收到进入所述非求救状态的交互时，进入所述求救状态。

5.根据权利要求1所述的方法，其特征在于，所述根据用户与所述电子设备的交互，选择保持所述预求救状态、进入求救状态、或者进入非求救状态包括：

在以预定的终止方式终止所述预求救状态时，进入所述非求救状态；或者，

在以非所述预定的终止方式终止所述预求救状态时，进入所述求救状态。

6.根据权利要求1所述的方法，其特征在于，所述根据用户与所述电子设备的交互，选择保持所述预求救状态、进入求救状态、或者进入非求救状态包括：

在进入所述预求救状态时，获取所述预求救状态的维持时间，并在自进入所述预求救状态起的所述维持时间内，保持所述预求救状态；

当在所述维持时间结束前，接收到预定的终止所述预求救状态的交互时，进入所述非求救状态；

当在所述维持时间内，未接收到维持所述预求救状态的交互，且未接收到预定的终止所述预求救状态的交互时，进入所述求救状态。

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

当在所述维持时间结束前，接收到维持所述预求救状态的交互时，重新在所述维持时间内保持所述预求救状态，或者获取新的维持时间，并在所述新的维持时间内保持所述预求救状态。

8.根据权利要求1-5任一项所述的方法，其特征在于，所述根据用户与所述电子设备的交互，选择保持所述预求救状态包括：

以预定的时间规则输出提示信息；

当在输出所述提示信息后的预定时间内接收到维持所述预求救状态的交互时，保持所述预求救状态。

9.根据权利要求1-5任一项所述的方法，其特征在于，

在处于所述预求救状态，且接收到保持所述预求救状态的交互时，在所述交互持续的时间内保持所述预求救状态，和/或，重新在预定的维持时间内保持所述预求救状态。

10.根据权利要求1-7任一项所述的方法，其特征在于，

所述交互为满足预定规则的对所述电子设备按键或触控屏的手势、语音指令、密码的一种或多种。

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

在处于所述预求救状态时，采集预求救内容信息；

在生成所述求救消息时使所述求救消息包含所述预求救内容信息，或者将所述预求救内容信息发送给服务器，使得服务器将所述预求救内容信息携带于所述求救消息中。

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

与服务器同步用户安全状态，所述用户安全状态为所述预求救状态、所述求救状态、所述非求救状态的一种；

向服务器发送包含设备状态信息的消息，使得服务器根据所述设备状态信息确定是否将所述用户安全状态从所述预求救状态转换为所述求救状态，并在将所述用户安全状态转换为所述求救状态后向所述求救目标用户的电子设备发送所述求救消息；

其中，所述设备状态信息包括所述电子设备的剩余电量、信号强度、实时位置、当前时间的至少一种。

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

在进入所述求救状态后，播放预定的求救音频文件。

14.一种电子设备，包括：处理器、存储有所述处理器可执行指令的存储器，当所述指令被所述处理器执行时，实现如权利要求1-13任一项所述的方法。

15.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时，实现如权利要求1-13任一项所述的方法。

Images