一种终端卡死恢复方法及相关设备与流程

1.本发明涉及终端设备技术领域，尤其涉及一种终端卡死恢复方法及相关设备。


背景技术：

2.随着移动互联网的发展，手机、平板等终端的广泛应用，终端交互已经成为人们沟通与娱乐的主要承载形式。流畅、智能是消费者对于终端的主要需求之一。而大量的智能终端为人们带来丰富的娱乐生活的同时，也时常出现终端卡死但迟迟无法恢复的现象，导致用户体验不佳。
3.现有技术中的终端卡死恢复机制，通常存在着恢复时间过长、缺乏灵活性、部分场景缺少恢复机制的问题，无法满足用户对于终端使用体验的更高要求。例如现有技术中基于安卓系统卡死的恢复方案，该方案默认复位的恢复时间过长、不对卡死场景加以区分缺乏灵活性，影响用户体验；此外，现有技术中针对应用卡死的恢复方案未能全面覆盖所有场景，部分场景缺少恢复机制。用户在使用应用的过程中，如果遇到这一部分场景的应用卡死情况，又缺少有效的恢复方案，用户体验自然不佳。因此如何提供一种快速、有效的终端卡死恢复方案，提升用户体验，是亟待解决的问题。


技术实现要素：

4.本发明实施例提供一种终端卡死恢复方法及相关设备，可以快速、准确地恢复卡死的终端，提升用户体验。
5.第一方面，本发明实施例提供了一种终端卡死恢复方法，可包括：
6.当检测到终端卡死时间到达预置时间t1时，确定所述终端的卡死原因；所述卡死原因包括系统卡死或应用卡死；根据所述卡死原因确定所述终端的卡死场景；执行与所述卡死场景匹配的预设操作恢复所述终端；其中，所述预置时间t1小于所述终端的默认复位时间t2。
7.本发明实施例，在终端出现卡死的情况下，若检测到终端卡死的持续时间到达预置时间t1时，则首先确定终端的卡死原因，再根据该卡死原因进一步确定终端的卡死场景，最终，执行与该卡死场景匹配的预设操作从而恢复卡死的终端；其中，将预置时间t1设置为小于终端的默认复位时间t2。本发明实施例针对现有技术中终端卡死的默认复位时间t2过长、不做场景区分而统一默认复位终端的问题，通过设置比默认复位时间t2更短的预置时间t1，并在终端卡死的持续时间到达预置时间t1时确定终端的卡死原因，并在终端的默认复位时间t2之前根据该卡死原因进一步确定出终端的卡死场景，最后执行与该卡死场景匹配的预设操作，由此可以在默认复位时间t2之前快速、准确地恢复卡死的终端；另外，本发明实施例对终端的卡死场景加以区分，不同卡死场景(如进程间死锁、进程内死锁、服务调用阻塞、应用绘制异常、应用启动超时等)对应不同的恢复方案。例如，对于进程间死锁的场景，可以仅针对造成死锁的进程进行复位，而避免对未造成死锁的其他在运行的进程进行复位，从而快速、精准恢复卡死的终端，且同时起到保护数据的作用。综上，本发明实施例通
过先确认终端的卡死场景，并有针对性地执行与该卡死场景匹配的预设操作，最终能够快速、准确恢复卡死的终端，并有效保护了用户的部分数据，提升了用户体验。
8.在一种可能的实现方式中，所述确定所述终端的卡死原因，包括：获取系统级检测机制和/或应用级检测机制的检测结果；根据所述检测结果确定所述终端的卡死原因。
9.本发明实施例通过系统级检测机制和/或应用级检测机制的检测结果，快速、准确地确定终端的卡死原因，从而为有效提升确定卡死场景的效率和准确率提供基础。
10.在一种可能的实现方式中，所述根据所述卡死原因确定所述终端的卡死场景，包括：当确定所述终端的卡死原因为系统卡死时，获取系统进程调用机制的状态，所述系统进程调用机制的状态包括进程间的访问状态、进程内线程间的访问状态中的一种或多种；根据所述系统进程调用机制的状态，确定所述终端的卡死场景。
11.本发明实施例在确定出终端的卡死原因为系统卡死时，则进一步获取系统进程调用机制的状态，并分析系统进程调用机制中的系统进程以及进程内线程的状态，从而可以快速、准确地确定终端的卡死场景，为快速、准确恢复卡死的终端、保护用户数据提供了基础。
12.在一种可能的实现方式中，所述根据所述系统进程调用机制的状态，确定所述终端的卡死场景，包括：当所述进程间的访问状态为系统进程和其他外部进程出现进程之间相互调用，由于相互等待造成的死锁时，确定所述终端的卡死场景为进程间死锁。
13.本发明实施例中，终端的卡死场景包括了进程间死锁，进程间死锁是由于系统进程和其他外部进程之间相互调用，相互等待出现死锁造成的。当确定出终端处于进程间死锁场景时，可以针对处于此场景下卡死的终端进行快速、准确地恢复，有效提升用户体验。
14.在一种可能的实现方式中，与所述进程间死锁匹配的所述预设操作为复位所述其他外部进程。
15.本发明实施例中，当确定出终端的卡死场景为进程间死锁时，则复位其他外部进程，从而快速、准确恢复卡死的终端。进程间死锁场景无法自动解锁恢复，因此用户长时间等待并无用处。然而，现有技术不对此场景进行区分，需要等待终端卡死的持续时间到达默认复位时间t2才能复位恢复，这严重影响用户体验。因此本发明实施例将此场景区分出来，并提供了快速、准确的恢复方案。同时，对比默认复位终端的机制，本发明实施例可以仅复位导致死锁的其他外部进程，而其他在运行的无关进程不受复位影响，对用户的数据起到一定保护作用，有效提升用户体验。需要说明的是，针对进程间死锁的场景，通过复位系统进程、复位系统进程和其他外部进程、复位其他外部进程三种方式中的任何一种都可以提前恢复卡死的终端，但是对系统进程进行复位相当于重启终端，用户数据可能出现丢失。因此本发明实施例中选择了仅复位其他外部进程的方案，用户体验最佳。
16.在一种可能的实现方式中，所述根据所述系统进程调用机制的状态，确定所述终端的卡死场景，包括：当所述进程内的访问状态为系统进程内两个或两个以上核心线程互相等待造成的死锁时，确定所述终端的卡死场景为进程内死锁。
17.本发明实施例中，终端的卡死场景包括了进程内死锁，进程内死锁是由于系统进程内两个或两个以上核心线程之间互相等待出现死锁造成的。当确定出终端处于进程内死锁场景时，可以针对处于此场景下卡死的终端进行快速、准确地恢复，有效提升用户体验。
18.在一种可能的实现方式中，与所述进程内死锁匹配的所述预设操作为复位所述终
端。
19.本发明实施例中，当确定出终端的卡死场景为进程内死锁时，则复位终端，从而快速、准确恢复卡死的终端。进程内死锁场景无法自动解锁恢复，因此用户长时间等待并无用处。然而，现有技术不对此场景进行区分，需要等待终端卡死的持续时间到达默认复位时间t2才能复位恢复，这严重影响用户体验。因此本发明实施例将此场景区分出来，并提供了快速、准确的恢复方案，减少了用户不必要的等待时间，提升了用户体验。
20.在一种可能的实现方式中，所述根据所述系统进程调用机制的状态，确定所述终端的卡死场景，包括：当所述进程间的访问状态为系统进程调用系统服务，所述系统服务无响应导致所述终端卡死时，确定所述终端的卡死场景为服务调用阻塞。
21.本发明实施例中，终端的卡死场景包括了服务调用阻塞，服务调用阻塞是由于系统进程调用系统服务，系统服务无响应，出现卡死造成的。当确定出终端处于服务调用阻塞场景时，可以针对处于此场景下卡死的终端进行快速、准确地恢复，有效提升用户体验。
22.在一种可能的实现方式中，与所述服务调用阻塞匹配的所述预设操作为复位所述系统服务。
23.本发明实施例中，当确定终端的卡死场景为服务调用阻塞时，则复位系统服务，从而快速、准确恢复卡死的终端。由于服务调用阻塞场景自动恢复所需时间较长，用户需要长时间等待才有可能自动恢复，这严重影响用户体验。因此本发明实施例将此场景区分出来，并提供了快速、准确的恢复方案，减少了用户不必要的等待时间，提升了用户体验。需要说明的是，针对服务调用阻塞的场景，通过复位系统进程、复位系统进程和系统服务、复位系统服务三种方式中的任何一种都可以提前恢复卡死的终端，但是对系统进程进行复位相当于重启终端，用户数据可能出现丢失。因此本发明实施例中选择了仅复位系统服务的方案，用户体验最佳。在一种可能的实现方式中，所述复位所述系统服务，包括：确定所述系统服务是否为系统核心服务；若非系统核心服务则复位所述系统服务；若是系统核心服务则继续等待，直至所述系统服务自动恢复，或所述终端卡死持续时间到达所述默认复位时间t2时，复位所述终端。
24.本发明实施例中，在确定终端的卡死场景为服务调用阻塞后，再进一步判断被调用的系统服务是否属于系统核心服务。如果被调用的系统服务不是系统核心服务，则复位该系统服务，从而快速、准确地恢复卡死的终端；如果被调用的系统服务是系统核心服务，则继续等待，直至被调用的系统服务自动恢复，或者直至终端卡死的持续时间到达默认复位时间t2时，默认复位卡死的终端，能够避免因为贸然操作导致的数据丢失。因此，本发明实施例能够在尽可能保障用户数据不丢失的前提下，快速、准确恢复卡死的终端，进一步提升了用户体验。
25.在一种可能的实现方式中，所述根据所述卡死原因确定所述终端的卡死场景，包括：当确定所述终端的卡死原因为应用卡死时，获取应用级检测机制上报应用异常的内容，所述应用异常的内容为卡死应用的异常报告，所述卡死应用的异常报告包括应用启动异常报告、应用绘制异常报告中的一种或多种；根据所述卡死应用的异常报告，确定所述终端的卡死场景；所述终端的卡死场景包括应用启动超时或应用绘制异常。
26.本发明实施例在确定卡死原因为应用卡死时，则进一步获取应用级检测机制上报应用异常的内容，并分析应用异常的内容，从而可以快速、准确地确定终端的卡死场景，为
快速、准确恢复卡死的终端提供基础。
27.在一种可能的实现方式中，所述根据所述卡死应用的异常报告，确定所述终端的卡死场景，包括：当所述卡死应用的异常报告包括启动流程超时导致异常时，确定所述终端的卡死场景为应用启动超时；当所述卡死应用的异常报告包括绘制流程出现畸形窗口导致异常时，确定所述终端的卡死场景为应用绘制异常。
28.本发明实施例中，终端的卡死场景包括应用启动超时或应用绘制异常。其中，应用启动超时场景是指应用的启动流程在到达预置时间t1后，还没有完成启动的场景；应用绘制异常场景是指应用的绘制流程在完成时出现畸形窗口的场景。本发明实施例在确定终端的卡死原因为应用卡死时，则进一步分析异常报告中的启动流程和绘制流程的状态，快速、精准地确定应用的卡死场景。当确定出终端处于应用启动超时或应用绘制异常场景时，可以针对处于此场景下卡死的终端进行快速、准确地恢复，有效提升用户体验。
29.在一种可能的实现方式中，与所述应用启动超时或应用绘制异常匹配的所述预设操作为复位所述卡死应用。
30.本发明实施例中，当确定出终端的卡死场景为应用启动超时或应用绘制异常时，则复位卡死应用，从而快速、有效恢复卡死的终端。现有技术中，应用启动超时或应用绘制异常场景都没有恢复机制，用户长时间等待并无用处，这严重影响用户体验。因此本发明实施例将此类场景区分出来，并提供有效的恢复方案，快速、准确地恢复卡死的终端，提升用户体验。
31.在一种可能的实现方式中，在所述执行与所述卡死场景匹配的预设操作恢复所述终端之前，还包括：检测是否存在异常触摸事件；所述异常触摸事件包括触摸所述终端的显示屏超过预设次数无响应、点击所述终端的功能键超过预设次数无响应中的一种或多种；所述执行与所述卡死场景匹配的预设操作恢复所述终端，包括：当所述终端的卡死场景为应用启动超时或应用绘制异常，且存在所述异常触摸事件时，执行与所述卡死场景匹配的预设操作恢复所述终端。
32.本发明实施例中，在执行预设操作之前，还需要对终端进行异常触摸事件的检测，再根据检测结果和卡死场景确定是否执行预设操作。上述的异常触摸事件包括触摸终端的显示屏超过预设次数无响应、点击终端的功能键超过预设次数无响应中的一种或多种。本发明实施例中，当确定出终端的卡死场景为应用启动超时或应用绘制异常场景，且存在上述的异常触摸事件时，执行与应用启动超时或应用绘制异常场景匹配的预设操作恢复卡死的终端。本发明实施例引入了异常触摸事件的检测机制，增加了对用户行为的分析，经过分析之后再快速、准确恢复卡死的终端，可有效避免因误判导致的误操作，进一步提升了用户体验。
33.在一种可能的实现方式中，所述执行与所述卡死场景匹配的预设操作恢复所述终端，包括：发送第一消息，所述第一消息用于提示用户确认是否执行所述预设操作；当接收到用户确认执行所述预设操作的指令后，执行所述预设操作恢复所述终端；所述方法，还包括：在执行所述预设操作恢复所述终端后，发送第二消息；所述第二消息用于提示用户所述终端的卡死原因、所述终端的卡死场景中的一种或多种。
34.本发明实施例中，在执行预设操作之前，先向用户发送消息，此消息用于提示用户确认是否执行预设操作，在接收到用户确认执行预设操作的指令后，执行与卡死场景匹配
的预设操作恢复卡死的终端。可选地，还包括在恢复卡死的终端后，向用户发送提示消息，此消息用于提示用户该终端的卡死原因以及卡死场景。本发明实施例可以快速、准确地恢复卡死的终端，同时也加强用户了对终端恢复流程的感知与把控，全面提升了用户体验。
35.在一种可能的实现方式中，所述终端的卡死场景包括其他无法确定场景；所述其他无法确定场景为进程间死锁、进程内死锁、服务调用阻塞、应用绘制异常、应用启动超时之外的场景；与所述其他无法确定场景匹配的所述预设操作为继续等待，直至所述终端自动恢复，或所述终端卡死持续时间到达所述默认复位时间t2时，默认复位所述终端。
36.本发明实施例中，当终端的卡死场景无法确定时，即当终端的卡死场景无法准确定义为进程间死锁、进程内死锁、服务调用阻塞、应用绘制异常、应用启动超时中的一种或多种时，则继续等待，直至卡死的终端自动恢复，或者直至终端卡死的持续时间到达默认复位时间t2时，默认复位卡死的终端。其他无法确定场景不在本发明定义的可快速恢复场景范围之内，因此针对此类场景，仍采用终端的默认复位机制对卡死的终端进行恢复，以此作为本发明实施例定义的可快速恢复场景的补充。本发明实施例在快速、准确恢复卡死的终端前提下，对其他无法确定场景也保留可恢复方案。提升了用户体验，同时保证了本发明提供的终端卡死恢复方法的实用性。
37.第二方面，本发明实施例提供了一种终端卡死恢复装置，可包括：
38.第一检测单元，用于检测终端卡死持续时间是否到达预置时间t1；
39.第一确定单元，用于确定所述终端的卡死原因；所述卡死原因包括系统卡死或应用卡死；
40.第二确定单元，用于确定所述终端的卡死场景；
41.恢复单元，用于执行与所述卡死场景匹配的预设操作恢复所述终端；
42.其中，所述预置时间t1小于所述终端的默认复位时间t2。
43.本发明实施例，首先通过第一检测单元，检测终端卡死的持续时间到达预置时间t1时，然后通过第一确定单元确定出终端的卡死原因，第二确定单元再根据该卡死原因进一步确定出终端的卡死场景，最终，由恢复单元执行与该卡死场景匹配的预设操作从而恢复卡死的终端；其中，将预置时间t1设置为小于终端的默认复位时间t2。本发明实施例中的终端卡死恢复装置针对现有技术中终端卡死的默认复位时间t2过长、不做场景区分而统一默认复位终端的问题，通过设置比默认复位时间t2更短的预置时间t1，并在终端卡死的持续时间到达预置时间t1时确定终端的卡死原因，因而能够在终端的默认复位时间t2之前进一步确定出终端的卡死场景，最后执行与该卡死场景匹配的预设操作，由此在默认复位时间t2之前快速、准确地恢复卡死的终端；另外，本发明实施例中的终端卡死恢复装置对终端的卡死场景加以区分，不同卡死场景(如进程间死锁、进程内死锁、服务调用阻塞、应用绘制异常、应用启动超时等)对应不同的恢复方案。例如，对于进程间死锁的场景，可以仅针对造成死锁的进程进行复位，而避免对未造成死锁的其他在运行的进程进行复位，从而快速、精准恢复卡死的终端，且同时起到保护数据的作用。综上，本发明实施例中的终端卡死恢复装置通过先确认终端的卡死场景，并有针对性地执行与该卡死场景匹配的预设操作，最终能够快速、准确恢复卡死的终端，并有效保护了用户的部分数据，提升了用户体验。
44.在一种可能的实现方式中，所述第一确定单元，具体用于：
45.获取系统级检测机制和/或应用级检测机制的检测结果；根据所述检测结果确定
所述终端的卡死原因。
46.在一种可能的实现方式中，所述第二确定单元，具体用于：
47.当确定所述终端的卡死原因为系统卡死时，获取系统进程调用机制的状态，所述系统进程调用机制的状态包括进程间的访问状态、进程内线程间的访问状态中的一种或多种；根据所述系统进程调用机制的状态，确定所述终端的卡死场景。
48.在一种可能的实现方式中，所述第二确定单元，具体用于：
49.当所述进程间的访问状态为系统进程和其他外部进程出现进程之间相互调用，由于相互等待造成的死锁时，确定所述终端的卡死场景为进程间死锁；
50.所述恢复单元，具体用于：
51.执行与所述进程间死锁匹配的所述预设操作；所述预设操作为复位所述其他外部进程。
52.在一种可能的实现方式中，所述第二确定单元，具体用于：
53.当所述进程内的访问状态为系统进程内两个或两个以上核心线程互相等待造成的死锁时，确定所述终端的卡死场景为进程内死锁；
54.所述恢复单元，具体用于：执行与所述进程内死锁匹配的所述预设操作；所述预设操作为复位所述终端。
55.在一种可能的实现方式中，所述第二确定单元，具体用于：
56.当所述进程间的访问状态为系统进程调用系统服务，所述系统服务无响应导致所述终端卡死时，确定所述终端的卡死场景为服务调用阻塞；
57.所述恢复单元，具体用于：执行与所述服务调用阻塞匹配的所述预设操作；所述预设操作为复位所述系统服务。
58.在一种可能的实现方式中，所述恢复单元，具体用于：
59.确定所述系统服务是否为系统核心服务；若非系统核心服务则复位所述系统服务；若是系统核心服务则继续等待，直至所述系统服务自动恢复，或所述终端卡死持续时间到达所述默认复位时间t2时，复位所述终端。
60.在一种可能的实现方式中，所述第二确定单元，具体用于：
61.当确定所述终端的卡死原因为应用卡死时，获取应用级检测机制上报应用异常的内容，所述应用异常的内容为卡死应用的异常报告，所述卡死应用的异常报告包括应用启动异常报告、应用绘制异常报告中的一种或多种；根据所述卡死应用的异常报告，确定所述终端的卡死场景；所述终端的卡死场景包括应用启动超时或应用绘制异常。
62.在一种可能的实现方式中，所述第二确定单元，具体用于：
63.当所述卡死应用的异常报告包括启动流程超时导致异常时，确定所述终端的卡死场景为应用启动超时；当所述卡死应用的异常报告包括绘制流程出现畸形窗口导致异常时，确定所述终端的卡死场景为应用绘制异常；
64.所述恢复单元，具体用于：
65.执行与所述应用启动超时或应用绘制异常匹配的所述预设操作；所述预设操作为复位所述卡死应用。
66.在一种可能的实现方式中，所述装置还包括：
67.第二检测单元，用于在所述执行与所述卡死场景匹配的预设操作恢复所述终端之
前，检测是否存在异常触摸事件；所述异常触摸事件包括触摸所述终端的显示屏超过预设次数无响应、点击所述终端的功能键超过预设次数无响应中的一种或多种；
68.所述恢复单元，具体用于：
69.当所述终端的卡死场景为应用启动超时或应用绘制异常，且存在所述异常触摸事件时，执行与所述卡死场景匹配的预设操作恢复所述终端。
70.在一种可能的实现方式中，所述恢复单元，具体用于：
71.发送第一消息，所述第一消息用于提示用户确认是否执行所述预设操作；当接收到用户确认执行所述预设操作的指令后，执行所述预设操作恢复所述终端；
72.所述装置，还包括：
73.提示单元，用于在恢复所述终端后，发送第二消息；所述第二消息用于提示用户所述终端的卡死原因、所述终端的卡死场景中的一种或多种。
74.在一种可能的实现方式中，所述第二确定单元，具体用于：
75.确定所述终端的卡死场景为其他无法确定场景；所述其他无法确定场景为进程间死锁、进程内死锁、服务调用阻塞、应用绘制异常、应用启动超时之外的场景；
76.所述恢复单元，具体用于：
77.执行与所述其他无法确定场景匹配的所述预设操作；所述预设操作为继续等待，直至所述终端自动恢复，或所述终端卡死持续时间到达所述默认复位时间t2时，默认复位所述终端。
78.第三方面，本发明实施例提供一种网络设备，该网络设备中包括处理器，处理器被配置为支持该网络设备实现第一方面提供的终端卡死恢复方法中相应的功能。该网络设备还可以包括存储器，存储器用于与处理器耦合，其保存该网络设备必要的程序指令和数据。该网络设备还可以包括通信接口，用于该网络设备与其他设备或通信网络通信。
79.第四方面，本发明实施例提供一种计算机可读存储介质，用于储存为上述第二方面提供的一种终端卡死恢复装置中的处理器中所用的计算机软件指令，其包含用于执行上述方面所设计的程序。
80.第五方面，本发明实施例提供了一种计算机程序，该计算机程序包括指令，当该计算机程序被计算机执行时，使得计算机可以执行上述第二方面中的终端卡死恢复装置中的处理器所执行的流程。
81.第六方面，本技术提供了一种芯片系统，该芯片系统包括处理器，用于支持设备实现上述第一方面中所涉及的功能，例如，生成或处理上述终端卡死恢复方法中所涉及的信息。在一种可能的设计中，所述芯片系统还包括存储器，所述存储器，用于保存设备必要的程序指令和数据。该芯片系统，可以由芯片构成，也可以包含芯片和其他分立器件。
附图说明
82.为了更清楚地说明本发明实施例或背景技术中的技术方案，下面将对本发明实施例或背景技术中所需要使用的附图进行说明。
83.图1是本发明实施例提供的一种终端设备的结构示意图。
84.图2是本发明实施例提供的一种终端设备软件架构示意图。
85.图3是本发明实施例提供的一种终端卡死恢复方法的流程示意图。
86.图4是一种终端系统卡死恢复方法的流程示意图。
87.图5a是一种终端应用卡死检测的示意图。
88.图5b是另一种终端应用卡死检测的示意图。
89.图6是本发明实施例提供的一种终端系统卡死场景定位的示意图。
90.图7是本发明实施例提供的一种终端卡死恢复方法的判断流程示意图。
91.图8是本发明实施例提供的一种终端系统卡死方法对比示意图。
92.图9a是本发明实施例提供的一种终端系统卡死恢复的操作示意图。
93.图9b是本发明实施例提供的一种终端应用卡死恢复的操作示意图。
94.图10是本发明实施例提供的一种终端卡死恢复装置的结构示意图。
95.图11是本发明实施例提供的另一种终端卡死恢复装置的结构示意图。
具体实施方式
96.下面将结合本发明实施例中的附图，对本发明实施例进行描述。
97.本技术的说明书和权利要求书及所述附图中的术语“第一”、“第二”、“第三”和“第四”等是用于区别不同对象，而不是用于描述特定顺序。此外，术语“包括”和“具有”以及它们任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元，或可选地还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。
98.在本文中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本技术的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是，本文所描述的实施例可以与其它实施例相结合。
99.在本说明书中使用的术语“部件”、“模块”、“系统”等用于表示计算机相关的实体、硬件、固件、硬件和软件的组合、软件、或执行中的软件。例如，部件可以是但不限于，在处理器上运行的进程、处理器、对象、可执行文件、执行线程、程序和/或计算机。通过图示，在计算设备上运行的应用和计算设备都可以是部件。一个或多个部件可驻留在进程和/或执行线程中，部件可位于一个计算机上和/或分布在2个或更多个计算机之间。此外，这些部件可从在上面存储有各种数据结构的各种计算机可读介质执行。部件可例如根据具有一个或多个数据分组(例如来自与本地系统、分布式系统和/或网络间的另一部件交互的二个部件的数据，例如通过信号与其它系统交互的互联网)的信号通过本地和/或远程进程来通信。
100.首先，对本技术中的部分用语进行解释说明，以便于本领域技术人员理解。
101.(1)活动(activity)，一种可以包含用户界面的组件，主要用于和用户进行交互。活动分为4个状态：运行中、暂停、停止、销毁。一个活动的生命周期一般是创建、开始、启动(启动后进入运行中状态)、暂停、停止、销毁。
102.(2)看门狗(watchdog)，一种监控操作系统运行状态的手段，在操作系统出现异常时，可以为操作系统提供基础的恢复功能。
103.(3)上层应用(application，app)，终端应用程序。一个应用程序可以包含多个活动。当app应用出现卡死时，可以通过分析活动生命周期的各阶段，确定应用卡死所处的场景。
104.(4)活动管理服务(activity manager service，ams)，主要负责系统中四大组件的启动、切换、调度及应用进程的管理和调度等工作。
105.(5)活动启动流程(resume)，包含创建、开始、启动阶段。新活动创建入栈后，在resume流程到达开始阶段，此时活动处于可见状态但不可和用户交互；然后在resume流程到达启动阶段时，活动在屏幕最前端，处于栈的最顶端，此时活动处于可见状态并且可和用户交互。
106.(6)活动启动阶段(onresume)，当活动启动流程要进入启动阶段时，会调用onresume方法，活动到达启动阶段后处于可见并可和用户交互的激活状态。
107.(7)进程间通信机制(binder)，主要用来实现进程之间的通信。例如，当系统进程需要调用其他进程的能力时，会通过binder机制调用到其他进程，实现系统进程和其他进程之间的通信。
108.首先，分析并提出本技术所具体要解决的技术问题。在现有技术中，关于终端卡死恢复的技术(以基于安卓系统的终端为例)，包括如下方案一和方案二：
109.方案一：基于原生安卓系统的watchdog恢复方案，请参见图4，图4是一种终端系统卡死恢复方法的流程示意图，具体可以包括如下步骤s400和步骤s401：
110.步骤s400:检测系统进程中关键线程是否卡死。
111.步骤s401:当检测到系统卡死持续时间到达终端的默认复位时间t2时，复位重启终端，终端从开机画面处重新启动。
112.该方案一存在以下多个缺点：
113.缺点1：当前终端的默认复位时间t2为60s，用户等待终端从卡死到恢复所需的时间长，体验不佳。
114.缺点2：复位操作固定，不对系统的具体卡死场景加以区分，直接重启终端，容易导致用户部分数据丢失。
115.方案二：针对应用app卡死的恢复方案，请参见图5a和图5b，其中图5a是一种终端应用卡死检测的示意图，图5b是另一种终端应用卡死检测的示意图，具体可以包括如下步骤1：
116.步骤1：应用在运行阶段出现异常卡死时，采用自恢复机制。
117.上述方案二存在以下缺点：
118.缺点1：现有应用app卡死的恢复方案仅仅覆盖应用在运行阶段出现异常的场景，而在应用绘制阶段和应用启动阶段仅提供异常检测和异常上报功能，并没有提供针对这两个阶段出现异常时的恢复方案。当用户在应用绘制阶段或启动阶段遭遇异常时，一般只能通过强制掉电的方式恢复卡死的终端，而没有其他更有效的方案，用户体验不佳。
119.为了解决当前终端卡死恢复技术无法满足实际使用需求的问题，达到快速、准确地恢复卡死的终端，提升用户体验的目的，综合考虑现有技术存在的缺点，本技术实际要解决的技术问题包括如下几方面：
120.1、用时更短的检测机制(方案一的缺点1)。基于原生安卓系统的watchdog恢复方案目前广泛应用，部分解决了终端卡死的恢复问题。然而，由于方案中终端的默认复位时间t2长，导致用户长时间等待，这严重降低了用户体验。因此，需要提出一种用时更短的检测机制，可以更早将卡死的终端恢复过来，减少用户等待时间，提升用户体验。
121.2、精确的终端卡死场景定位(方案一的缺点2)。基于原生安卓系统的watchdog恢复方案，对于终端卡死的情况不做场景区分，当终端卡死的持续时间到达默认复位时间t2时，直接重启终端。此方案缺少灵活判断，无法针对性处理，易导致部分数据丢失。因此，需要一种精准的卡死场景定位能力，直击终端卡死的根源，快速、准确恢复卡死的终端，同时起到保护数据的作用。
122.3、提供可恢复方案(方案二的缺点1)。现有应用app卡死恢复方案仅仅覆盖应用在运行阶段出现异常的场景，而在应用绘制阶段或应用启动阶段只是提供异常检测和异常上报功能，并没有提供针对这两个阶段出现异常的恢复方案，无法满足用户在应用app实际使用中的要求。因此，需要提供一种针对应用绘制阶段或应用启动阶段出现异常的恢复机制，提升使用体验。
123.综上所述，现有的终端卡死恢复方案无法满足用户对于使用体验的更高要求。因此，本技术提供的终端卡死恢复方法用于解决上述技术问题。
124.为了便于理解本发明实施例，下面以终端设备100为例对实施例进行具体说明。应该理解的是，终端设备100可以具有比图中所示的更多的或者更少的部件，可以组合两个或多个的部件，或者可以具有不同的部件配置。图中所示出的各种部件可以在包括一个或多个信号处理和/或专用集成电路在内的硬件、软件、或硬件和软件的组合中实现。
125.请参见图1，图1是本发明实施例提供的一种终端设备的结构示意图。
126.终端设备100可以包括：处理器110，外部存储器接口120，内部存储器121，通用串行总线(universal serial bus，usb)接口130，充电管理模块140，电源管理模块141，电池142，天线1，天线2，移动通信模块150，无线通信模块160，音频模块170，扬声器170a，受话器170b，麦克风170c，耳机接口170d，传感器模块180，按键190，马达191，指示器192，摄像头193，显示屏194，以及用户标识模块(subscriber identification module，sim)卡接口195等。其中传感器模块180可以包括压力传感器180a，陀螺仪传感器180b，气压传感器180c，磁传感器180d，加速度传感器180e，距离传感器180f，接近光传感器180g，指纹传感器180h，温度传感器180j，触摸传感器180k，环境光传感器180l，骨传导传感器180m等。
127.可以理解的是，本发明实施例示意的结构并不构成对终端设备100的具体限定。在本技术另一些实施例中，终端设备100可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件的组合实现。
128.处理器110可以包括一个或多个处理单元，例如：处理器110可以包括应用处理器(application processor，ap)，调制解调处理器，图形处理器(graphics processing unit，gpu)，图像信号处理器(image signal processor，isp)，控制器，存储器，视频编解码器，数字信号处理器(digital signal processor，dsp)，基带处理器，和/或神经网络处理器(neural-network processing unit，npu)等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。
129.其中，控制器可以是终端设备100的神经中枢和指挥中心。控制器可以根据指令操作码和时序信号，产生操作控制信号，完成取指令和执行指令的控制。
130.处理器110中还可以设置存储器，用于存储指令和数据。在一些实施例中，处理器110中的存储器为高速缓冲存储器。该存储器可以保存处理器110刚用过或循环使用的指令
或数据。如果处理器110需要再次使用该指令或数据，可从所述存储器中直接调用。避免了重复存取，减少了处理器110的等待时间，因而提高了系统的效率。
131.在一些实施例中，处理器110可以包括一个或多个接口。接口可以包括集成电路(inter-integrated circuit，i2c)接口，集成电路内置音频(inter-integrated circuit sound，i2s)接口，脉冲编码调制(pulse code modulation，pcm)接口，通用异步收发传输器(universal asynchronous receiver/transmitter，uart)接口，移动产业处理器接口(mobile industry processor interface，mipi)，通用输入输出(general-purpose input/output，gpio)接口，用户标识模块(subscriber identity module，sim)接口，和/或通用串行总线(universal serial bus，usb)接口等。
132.可以理解的是，本发明实施例示意的各模块间的接口连接关系，只是示意性说明，并不构成对终端设备100的结构限定。在本技术另一些实施例中，终端设备100也可以采用上述实施例中不同的接口连接方式，或多种接口连接方式的组合。
133.充电管理模块140用于从充电器接收充电输入。其中，充电器可以是无线充电器，也可以是有线充电器。
134.电源管理模块141用于连接电池142，充电管理模块140与处理器110。电源管理模块141接收电池142和/或充电管理模块140的输入，为处理器110，内部存储器121，外部存储器，显示屏194，摄像头193，和无线通信模块160等供电。
135.终端设备100的无线通信功能可以通过天线1，天线2，移动通信模块150，无线通信模块160，调制解调处理器以及基带处理器等实现。
136.终端设备100通过gpu，显示屏194，以及应用处理器等实现显示功能。gpu为图像处理的微处理器，连接显示屏194和应用处理器。gpu用于执行数学和几何计算，用于图形渲染。处理器110可包括一个或多个gpu，其执行程序指令以生成或改变显示信息。
137.显示屏194用于显示图像，视频等。显示屏194包括显示面板。显示面板可以采用液晶显示屏(liquid crystal display，lcd)，有机发光二极管(organic light-emitting diode，oled)，有源矩阵有机发光二极体或主动矩阵有机发光二极体(active-matrix organic light emitting diode的，amoled)，柔性发光二极管(flex light-emitting diode，fled)，miniled，microled，micro-oled，量子点发光二极管(quantum dot light emitting diodes，qled)等。在一些实施例中，终端设备100可以包括1个或n个显示屏194，n为大于1的正整数。
138.终端设备100可以通过isp，摄像头193，视频编解码器，gpu，显示屏194以及应用处理器等实现拍摄功能。
139.isp用于处理摄像头193反馈的数据。例如，拍照时，打开快门，光线通过镜头被传递到摄像头感光元件上，光信号转换为电信号，摄像头感光元件将所述电信号传递给isp处理，转化为肉眼可见的图像。isp还可以对图像的噪点，亮度，肤色进行算法优化。isp还可以对拍摄场景的曝光，色温等参数优化。在一些实施例中，isp可以设置在摄像头193中。
140.摄像头193用于捕获静态图像或视频。物体通过镜头生成光学图像投射到感光元件。感光元件可以是电荷耦合器件(charge coupled device，ccd)或互补金属氧化物半导体(complementary metal-oxide-semiconductor，cmos)光电晶体管。感光元件把光信号转换成电信号，之后将电信号传递给isp转换成数字图像信号。isp将数字图像信号输出到dsp
加工处理。dsp将数字图像信号转换成标准的rgb，yuv等格式的图像信号。本发明实施例中，摄像头193包括采集人脸识别所需图像的摄像头，如红外摄像头或其他摄像头。该采集人脸识别所需图像的摄像头一般位于终端设备的正面，例如触控屏的上方，也可以位于其他位置，本发明实施例对此不做限制。在一些实施例中，终端设备100可以包括其他摄像头。终端设备还可以包括点阵发射器(图中未示出)，用于发射光线。摄像头采集人脸反射的光线，得到人脸图像，处理器对人脸图像进行处理和分析，通过与存储的人脸图像的信息进行比较以进行验证。
141.数字信号处理器用于处理数字信号，除了可以处理数字图像信号，还可以处理其他数字信号。例如，当终端设备100在频点选择时，数字信号处理器用于对频点能量进行傅里叶变换等。
142.视频编解码器用于对数字视频压缩或解压缩。终端设备100可以支持一种或多种视频编解码器。这样，终端设备100可以播放或录制多种编码格式的视频，例如：动态图像专家组(moving picture experts group，mpeg)1，mpeg2，mpeg3，mpeg4等。
143.npu为神经网络(neural-network，nn)计算处理器，通过借鉴生物神经网络结构，例如借鉴人脑神经元之间传递模式，对输入信息快速处理，还可以不断的自学习。通过npu可以实现终端设备100的智能认知等应用，例如：图像识别，人脸识别，语音识别，文本理解等。
144.外部存储器接口120可以用于连接外部存储卡，例如micro sd卡，实现扩展终端设备100的存储能力。外部存储卡通过外部存储器接口120与处理器110通信，实现数据存储功能。例如将音乐，视频等文件保存在外部存储卡中。
145.内部存储器121可以用于存储计算机可执行程序代码，所述可执行程序代码包括指令。处理器110通过运行存储在内部存储器121的指令，从而执行终端设备100的各种功能应用以及数据处理。内部存储器121可以包括存储程序区和存储数据区。其中，存储程序区可存储操作系统，至少一个功能所需的应用(比如人脸识别功能，指纹识别功能、移动支付功能等)等。存储数据区可存储终端设备100使用过程中所创建的数据(比如人脸信息模板数据，指纹信息模板等)等。此外，内部存储器121可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件，闪存器件，通用闪存存储器(universal flash storage，ufs)等。
146.终端设备100可以通过音频模块170，扬声器170a，受话器170b，麦克风170c，耳机接口170d，以及应用处理器等实现音频功能。例如音乐播放，录音等。
147.音频模块170用于将数字音频信息转换成模拟音频信号输出，也用于将模拟音频输入转换为数字音频信号。
148.扬声器170a，也称“喇叭”，用于将音频电信号转换为声音信号。
149.受话器170b，也称“听筒”，用于将音频电信号转换成声音信号。
150.麦克风170c，也称“话筒”，“传声器”，用于将声音信号转换为电信号。
151.耳机接口170d用于连接有线耳机。耳机接口170d可以是usb接口130，也可以是3.5mm的开放移动终端设备平台(open mobile terminal platform，omtp)标准接口，美国蜂窝电信工业协会(cellular telecommunications industry association of the usa，ctia)标准接口。
152.压力传感器180a用于感受压力信号，可以将压力信号转换成电信号。在一些实施例中，压力传感器180a可以设置于显示屏194。压力传感器180a的种类很多，如电阻式压力传感器，电感式压力传感器，电容式压力传感器等。
153.陀螺仪传感器180b可以用于确定终端设备100的运动姿态。在一些实施例中，可以通过陀螺仪传感器180b确定终端设备100围绕三个轴(即，x，y和z轴)的角速度。
154.接近光传感器180g可以包括例如发光二极管(led)和光检测器，例如光电二极管。发光二极管可以是红外发光二极管。
155.环境光传感器180l用于感知环境光亮度。终端设备100可以根据感知的环境光亮度自适应调节显示屏194亮度。环境光传感器180l也可用于拍照时自动调节白平衡。
156.指纹传感器180h用于采集指纹。终端设备100可以利用采集的指纹特性实现指纹解锁，访问应用锁，指纹拍照，指纹接听来电等。其中，该指纹传感器180h可以设置在触控屏下方，终端设备100可以接收用户在触控屏上该指纹传感器对应的区域的触摸操作，终端设备100可以响应于该触摸操作，采集用户手指的指纹信息，实现本技术实施例中所涉及的指纹识别通过后打开隐藏相册，指纹识别通过后打开隐藏应用，指纹识别通过后登录账号，指纹识别通过后完成付款等。
157.温度传感器180j用于检测温度。在一些实施例中，终端设备100利用温度传感器180j检测的温度，执行温度处理策略。
158.触摸传感器180k，也称“触控面板”。触摸传感器180k可以设置于显示屏194，由触摸传感器180k与显示屏194组成触摸屏，也称“触控屏”。触摸传感器180k用于检测作用于其上或附近的触摸操作。触摸传感器可以将检测到的触摸操作传递给应用处理器，以确定触摸事件类型。可以通过显示屏194提供与触摸操作相关的视觉输出。在另一些实施例中，触摸传感器180k也可以设置于终端设备100的表面，与显示屏194所处的位置不同。
159.按键190包括开机键，音量键等。按键190可以是机械按键。也可以是触摸式按键。终端设备100可以接收按键输入，产生与终端设备100的用户设置以及功能控制有关的键信号输入。
160.指示器192可以是指示灯，可以用于指示充电状态，电量变化，也可以用于指示消息，未接来电，通知等。
161.sim卡接口195用于连接sim卡。sim卡可以通过插入sim卡接口195，或从sim卡接口195拔出，实现和终端设备100的接触和分离。在一些实施例中，终端设备100采用esim，即：嵌入式sim卡。esim卡可以嵌在终端设备100中，不能和终端设备100分离。
162.终端设备100的软件系统可以采用分层架构，事件驱动架构，微核架构，微服务架构，或云架构。本发明实施例以分层架构的android系统为例，示例性说明终端设备100的软件结构。
163.请参见图2，图2是本发明实施例提供的一种终端设备软件架构示意图。
164.分层架构将软件分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中，将android系统分为四层，从上至下分别为应用程序层，应用程序框架层，安卓运行时(android runtime)和系统库，以及内核层。
165.应用程序层可以包括一系列应用程序包。
166.如图2所示，应用程序包可以包括相机，图库，日历，通话，地图，导航，wlan，蓝牙，
音乐，视频，短信息等应用程序(也可以称为应用)。
167.应用程序框架层为应用程序层的应用程序提供应用编程接口(application programming interface，api)和编程框架。应用程序框架层包括一些预先定义的函数。
168.如图2所示，应用程序框架层可以包括窗口管理器，内容提供器，视图系统，电话管理器，资源管理器，通知管理器等。
169.窗口管理器用于管理窗口程序。窗口管理器可以获取显示屏大小，判断是否有状态栏，锁定屏幕，截取屏幕等。
170.内容提供器用来存放和获取数据，并使这些数据可以被应用程序访问。所述数据可以包括视频，图像，音频，拨打和接听的电话，浏览历史和书签，电话簿等。
171.视图系统包括可视控件，例如显示文字的控件，显示图片的控件等。视图系统可用于构建应用程序。显示界面可以由一个或多个视图组成的。例如，包括短信通知图标的显示界面，可以包括显示文字的视图以及显示图片的视图。
172.电话管理器用于提供终端设备100的通信功能。例如通话状态的管理(包括接通，挂断等)。
173.资源管理器为应用程序提供各种资源，比如本地化字符串，图标，图片，布局文件，视频文件等等。
174.通知管理器使应用程序可以在状态栏中显示通知信息，可以用于传达告知类型的消息，可以短暂停留后自动消失，无需用户交互。比如通知管理器被用于告知下载完成，消息提醒等。通知管理器还可以是以图表或者滚动条文本形式出现在系统顶部状态栏的通知，例如后台运行的应用程序的通知，还可以是以对话界面形式出现在屏幕上的通知。例如在状态栏提示文本信息，发出提示音，终端设备振动，指示灯闪烁等。
175.android runtime包括核心库和虚拟机。android runtime负责安卓系统的调度和管理。
176.核心库包含两部分：一部分是java语言需要调用的功能函数，另一部分是安卓的核心库。
177.应用程序层和应用程序框架层运行在虚拟机中。虚拟机将应用程序层和应用程序框架层的java文件执行为二进制文件。虚拟机用于执行对象生命周期的管理，堆栈管理，线程管理，安全和异常的管理，以及垃圾回收等功能。
178.系统库可以包括多个功能模块。例如：表面管理器(surface manager)，媒体库(media libraries)，三维图形处理库(例如：opengl es)，2d图形引擎(例如：sgl)等。
179.表面管理器用于对显示子系统进行管理，并且为多个应用程序提供了2d和3d图层的融合。
180.媒体库支持多种常用的音频，视频格式回放和录制，以及静态图像文件等。媒体库可以支持多种音视频编码格式，例如:mpeg4，h.264，mp3，aac，amr，jpg，png等。
181.三维图形处理库用于实现三维图形绘图，图像渲染，合成，和图层处理等。
182.2d图形引擎是2d绘图的绘图引擎。
183.内核层是硬件和软件之间的层。内核层至少包含显示驱动，摄像头驱动，音频驱动，传感器驱动。
184.基于图1提供的终端设备的结构示意图，以及图2提供的终端设备的软件结构框
图，结合本技术中提供的终端卡死恢复方法，对本技术中提出的技术问题进行具体分析和解决。
185.参见图3，图3是本发明实施例提供的一种终端卡死恢复方法的流程示意图，该方法可应用于上述图1中所述的终端设备中，终端设备可以用于支持并执行图3中所示的方法流程步骤s300-步骤s303。下面将结合附图3从终端设备侧进行描述。该方法可以包括以下步骤s300-步骤s303。
186.步骤s300：检测终端卡死持续时间到达预置时间t1。
187.具体地，设定一个预置时间t1作为阈值。如果检测到终端卡死的持续时间到达了预先设定的阈值t1，则需要确定终端的卡死原因。其中预置时间t1小于终端的默认复位时间t2。例如，目前终端的默认复位时间t2为60s，本发明实施例可以将预置时间t1设置为10s。如果检测到终端卡死的持续时间到达了10s，则确定终端的卡死原因。可选地，也可以将t1设置为其它值，本发明实施例对此不作具体限定。其中，判断终端是否出现卡死，可以通过类似判断线程的monitor接口是否阻塞的方法来确定，例如，如果monitor接口阻塞，则可以确定终端出现卡死；也可以通过类似判断线程的消息队列是否处理消息的方法来确定，例如，如果消息队列不处理消息，则可以确定终端出现卡死。此处不再一一举例。
188.步骤s301：确定所述终端的卡死原因。
189.具体地，本发明实施例中，根据系统级和/或应用级检测机制的检测结果，确定终端的卡死原因。终端的卡死原因包括系统卡死、应用卡死中的一种或多种。一般地，系统级和/或应用级检测机制的检测结果会暂存在后台数据中，通过后台数据可以获取检测结果。根据系统级检测机制的检测结果可以确定终端的卡死原因是否为系统卡死；同理，根据应用级检测机制的检测结果可以确定终端的卡死原因是否为应用卡死。需要说明的是，系统级检测机制可以是类似watchdog检测的检测机制，也可以是其它机制；应用级检测机制可以是类似黑屏卡死检测模块的检测机制，也可以是其它机制。另外，针对系统级检测机制和应用级检测机制可以设置不同的预置时间t1，例如针对系统级检测机制，可将预置时间t1设置为10s，而针对应用级检测机制可将预置时间t1设置为5s，当终端卡死的持续时间到达5s时，则获取应用级检测机制的检测结果，当终端卡死的持续时间到达10s时，则获取系统级检测机制的检测结果。还需要说明的是，系统卡死和应用卡死可能会组合出现，系统卡死可能会导致应用卡死，但是应用卡死不会导致系统卡死，因此当系统卡死和应用卡死组合出现时，采用本发明实施例中解决系统卡死的方法即可恢复卡死的终端。
190.步骤s302：确定所述终端的卡死场景。
191.具体地，在确定终端的卡死原因之后，再根据终端的卡死原因进一步分析系统进程调用机制的状态或应用级检测机制上报应用异常的内容，进一步确定出终端的卡死场景。终端的卡死场景包括进程间死锁、进程内死锁、服务调用阻塞、应用启动超时、应用绘制异常中的一种或多种。
192.例如，当确定出终端的卡死原因为系统卡死时，则进一步获取系统进程调用机制的状态。需要说明的是，系统进程调用机制的状态包括进程间的访问状态、进程内线程间的访问状态中的一种或多种。再根据系统进程调用机制的状态，确定出终端的卡死场景。在对系统进程调用机制的状态进行分析之后，如果确定出进程间的访问状态为系统进程和其他外部进程出现进程之间相互调用，由于相互等待造成的死锁时，则确定终端的卡死场景为
进程间死锁；如果确定出进程内的访问状态为系统进程内两个或两个以上核心线程互相等待造成的死锁时，则确定终端的卡死场景为进程内死锁；如果确定出进程间的访问状态为系统进程调用系统服务，因为该系统服务阻塞无响应从而导致终端出现卡死时，则确定终端的卡死场景为服务调用阻塞。
193.例如，当确定出终端的卡死原因为应用卡死时，则进一步获取应用级检测机制上报应用异常的内容。需要说明的是，应用异常的内容为卡死应用的异常报告，异常报告中包括应用启动异常报告、应用绘制异常报告中的一种或多种。再根据卡死应用的异常报告，确定终端的卡死场景。在对应用异常的内容进行分析之后，如果确定出卡死应用的异常报告包括启动过程超时导致异常时，则确定终端的卡死场景为应用启动超时；如果确定出卡死应用的异常报告包括绘制流程出现畸形窗口导致异常时，则确定终端的卡死场景为应用绘制异常。
194.以上，在确定出终端的卡死原因之后，再根据终端的卡死原因进一步分析终端卡死所处于的阶段与节点，能够快速、准确地确定出终端的卡死场景。而关于具体如何确定终端的卡死场景，可以参见图5b和图6。图5b是另一种终端应用卡死检测的示意图；图6是本发明实施例提供的一种终端系统卡死场景定位的示意图。
195.步骤s303：执行与所述卡死场景匹配的预设操作恢复所述终端。
196.具体地，针对不同的卡死场景，预先设定与各种卡死场景相对应的恢复操作，在执行预先设定的恢复操作之后，可以快速、准确地将终端从卡死状态中恢复过来。需要说明的是，预先设定的恢复操作可以是某个单一操作，也可以是多个操作的组合。
197.例如，针对进程间死锁场景，可以将预设操作设置为仅针对造成死锁的进程进行复位，而不对未造成死锁的其他在运行的进程进行复位；针对进程内死锁场景，可以将预设操作设置为复位终端；针对服务调用阻塞场景，可以将预设操作设置为复位被调用系统服务。
198.而关于上述方法步骤s300-s303具体如何用于恢复卡死的终端，可以参见图7，图7是本发明实施例提供的一种终端卡死恢复方法的判断流程示意图。
199.可选地，当上述方法步骤s300-s303用于恢复卡死的终端时，由于预先设置了比默认复位时间t2更短的预置时间t1，再按照t1时间对终端进行检测，能够更早、更准确地发现终端出现卡死，并能快速确定终端的卡死原因，再进一步根据卡死原因准确地确定出终端的卡死场景，为能够快速、准确恢复卡死的终端提供更深入、更准确的判断依据。在实际使用过程中，处于某些卡死场景下的终端，即使用户选择长时间等待，终端依旧无法自行恢复。如果不提前将处于这些卡死场景下卡死的终端快速恢复，那么只能通过强制掉电或者触发默认复位机制的方式恢复终端，用户体验不佳。因此，本发明实施例在确定了终端的卡死原因之后，再根据终端的卡死原因进一步确定出终端的卡死场景，最终执行与该卡死场景匹配的预设操作，从而能够快速、准确地恢复卡死的终端，有效提升了用户体验。
200.在上述步骤s303中，具体执行何种预设操作才能恢复卡死的终端，会因为卡死场景的不同而有所区别。通过对终端的卡死情况进行深入分析，本发明实施例中终端的卡死原因包括系统卡死和应用卡死。在确定出终端的卡死原因是系统卡死后，再根据系统卡死这一卡死原因进一步细化出三种可快速恢复的场景，针对这三种可快速恢复的场景分别预先设定了对应的恢复操作，执行有针对性的恢复操作可以快速、准确地恢复卡死的终端；在
确定出终端的原因是应用卡死后，再根据应用卡死这一卡死原因进一步细化出两种可优化恢复的场景，针对这两种可优化恢复的场景分别预先设定了对应的恢复操作，执行有针对性的恢复操作可以快速、准确地恢复卡死的终端。
201.其中，在系统卡死原因下，有以下三种可快速恢复场景：
202.1、进程间死锁以及与进程间死锁匹配的预设操作
203.进程间死锁具体为：系统进程和其他外部进程出现进程之间相互调用，由于相互等待造成的死锁。参见图6，例如，系统进程要调用其他外部进程的能力时，会通过binder机制调用到其他外部进程。如果系统进程持有锁，通过binder机制调用到其他外部进程，其他外部进程会通过binder机制回调到持有锁的系统进程，当回调的请求线程再去申请这把锁时，就会出现两个进程之间互相等待造成的死锁。其他外部进程调用系统进程时，也是类似的过程，此处不再赘述。
204.与进程间死锁匹配的预设操作：复位所述其他外部进程。当确定出终端的卡死场景为进程间死锁时，通过复位其他外部进程，破坏造成死锁的“占有并等待”条件，解除死锁从而能够快速、准确恢复卡死的终端。
205.2、进程内死锁以及与进程内死锁匹配的预设操作
206.进程内死锁具体为：系统进程内两个或两个以上核心线程互相等待造成的死锁。参见图6，系统进程内两个或两个以上核心线程持有锁，都需要请求对方的锁，就会出现多线程之间互相等待造成的死锁。
207.与进程内死锁匹配的预设操作：复位所述终端。进程内死锁场景只能通过复位终端的方式进行恢复。与其选择长时间等待至终端的默认复位时间t2，然后触发默认复位机制复位卡死的终端，还不如在确定出终端的卡死场景为进程内死锁时，就采用复位终端的方式恢复卡死的终端，减少用户等待时间，提升用户体验。
208.3、服务调用阻塞以及与服务调用阻塞匹配的预设操作
209.服务调用阻塞具体为：系统进程调用系统服务，所述系统服务无响应导致所述终端卡死。参见图6，系统进程如果要调用系统服务能力时，会通过binder机制调用到系统服务，如果被调用的系统服务因为阻塞而无法响应，也会导致终端出现卡死。
210.与服务调用阻塞匹配的预设操作：复位所述系统服务。当确定出终端的卡死场景为服务调用阻塞时，则可以复位被调用的阻塞的系统服务，从而能够快速、准确恢复卡死的终端。
211.可选地，复位所述系统服务，包括：确定所述系统服务是否为系统核心服务；若非系统核心服务则复位所述系统服务；若是系统核心服务则继续等待，直至所述系统服务自动恢复，或所述终端卡死时间到达所述默认复位时间t2时，复位所述终端。当确定出终端的卡死场景为服务调用阻塞时，再进一步判断被调用的系统服务是否属于系统核心服务。如果被调用的系统服务不是系统核心服务，则复位该系统服务，从而快速、准确地恢复卡死的终端；如果被调用的系统服务是系统核心服务，则继续等待，直至被调用的系统服务自动恢复，或者直至终端卡死的持续时间到达默认复位时间t2时，默认复位卡死的终端，能够避免因为贸然操作导致的数据丢失。
212.另外，在应用卡死原因下，有以下两种可优化恢复场景：
213.1、应用绘制异常
214.应用绘制异常具体为：应用在响应用户启动的过程中，ams会调用应用进程的resume流程，同时同步启动应用绘制draw流程，如果draw流程在预置时间t1内到达performdraw阶段，但是绘制后的窗口是畸形窗口，则可以确定为应用绘制异常。
215.2、应用启动超时
216.应用启动超时具体为：应用在响应用户启动的过程中，ams会调用应用进程的resume流程，同时同步启动应用绘制draw流程。超时检测从onresume阶段开始，若draw流程在超过预置时间t1后仍然没有到达performdraw阶段，应用没能进入到正常运行状态，则可以确定为应用启动超时。
217.3、与应用绘制异常或应用启动超时匹配的预设操作
218.与应用绘制异常或应用启动超时匹配的预设操作：复位所述卡死应用。当确定出终端的卡死场景为应用绘制异常或应用启动超时时，则可以复位卡死的应用，从而能够快速、准确恢复卡死的终端。
219.可选地，在复位所述卡死应用之前，还包括：检测是否存在异常触摸事件；所述异常触摸事件包括触摸所述终端的显示屏超过预设次数无响应、点击所述终端的功能键超过预设次数无响应中的一种或多种。根据终端的卡死场景确定的结果和异常触摸事件检测结果，确定是否执行与所述卡死场景匹配的预设操作。当所述终端的卡死场景为应用启动超时或应用绘制异常，且存在所述异常触摸事件时，执行与所述卡死场景匹配的预设操作恢复所述终端。
220.为了便于理解本发明实施例，针对上述异常触摸事件的检测，下面以终端设备100为例对实施例进行举例说明。例如，对终端设备100的触摸传感器180k和/或显示屏194进行异常触摸事件检测，当用户触摸终端设备100的触摸传感器180k和/或显示屏194超过5次，但是终端无响应时，则可以认为存在异常触摸事件。或者，对终端设备100的按键190进行异常触摸事件检测，当用户触摸终端设备100的按键190超过5次，但是终端无响应时，则可以认为存在异常触摸事件。当终端的卡死场景为应用启动超时或应用绘制异常，且存在异常触摸事件时，则执行与应用启动超时或应用绘制异常匹配的预设操作恢复卡死的终端。需要说明的是，为了便于理解，本发明实施例将预设次数取为5次。本领域技术人员应当理解，预设次数可以是5次，也可以是其他取值的次数，本发明实施例对此不作具体限定。还需要说明的是，异常触摸事件的检测可以是针对终端设备100的触摸传感器180k、显示屏194、按键190中某一单独结构进行检测，也可以是针对它们之间任一组合进行检测。最后需要说明的是，异常触摸事件的检测可以在确定了终端的卡死场景之后进行，也可以是在确定终端的卡死场景之前进行。
221.可选地，上述步骤s303包括，发送第一消息，所述第一消息用于提示用户确认是否执行所述预设操作；当接收到用户确认执行所述预设操作的指令后，执行所述预设操作恢复所述终端。为了便于理解，以终端出现进程间死锁为例，可以先通过弹窗或者通知栏的形式向用户发送消息，发送此消息的目的是需要用户确认是否执行预设操作(与进程间死锁匹配的预设操作为复位其他外部进程)，在接收到用户确认执行预设操作的指令后，执行与进程间死锁匹配的复位其他外部进程的操作从而恢复卡死的终端。可参见图9a，图9a是本发明实施例提供的一种终端系统卡死恢复的操作示意图。需要说明的是，向用户发送消息的方式包括但不限于弹窗或者通知栏的形式。
222.可选地，上述步骤s303之后还包括，发送第二消息；所述第二消息用于提示用户所述终端的卡死原因、所述终端的卡死场景中的一种或多种。为了便于理解，仍以终端出现进程间死锁为例，在执行复位其他外部进程的操作恢复卡死的终端之后，可以先通过弹窗或者通知栏的形式向用户发送消息，发送此消息的目的是提示用户终端的卡死原因为系统卡死、终端的卡死场景为进程间卡死。需要说明的是，向用户发送消息的方式包括但不限于弹窗或者通知栏的形式。还需要说明的是，用于提示用户的消息中可以包含终端的卡死原因、终端的卡死场景中的一种或多种。
223.上述五种卡死场景对应的恢复方案，深入分析不同场景的特点和缺陷。通过设定比默认复位时间t2更短的预置时间t1，再按照t1时间对终端进行检测，能够更早、更准确发现终端出现卡死，快速确定终端的卡死原因，进一步根据卡死原因对终端的卡死场景进一步细分，使得每一种场景下的特点更加聚焦，针对不同卡死场景预先设定行之有效的对应操作，从而能够快速、准确地恢复卡死的终端。本发明实施例相比于现有技术，改进之处体现在检测机制和卡死场景区分方面。
224.针对本技术前述提出的实际要解决的三个技术问题，本发明实施例中提出用时更短的检测机制，能够更早、更精准地发现终端出现卡死，为提前快速、准确地恢复卡死的终端提供基础。可参见图8，图8是本发明实施例提供的一种终端系统卡死方法对比示意图。例如，当终端在0时刻出现卡死，现有技术中的watchdog恢复方案需要等终端卡死的持续时间到达默认复位时间t2(t2为60s)才会通过复位终端的方式恢复卡死的终端；而本发明实施例中，在终端卡死的持续时间到达预置时间t1时(将t1设置为10s)，就可以快速、准确地确定终端的卡死原因以及卡死场景，再执行与卡死场景匹配的预设操作从而能够快速、准确地恢复卡死的终端。
225.本发明实施例中在确定出卡死原因后，再对卡死场景进行细分，针对不同卡死场景预先设定不同的操作，可以有效快速、准确恢复卡死的终端。
226.本发明实施例中针对应用卡死的两种场景，提供可恢复方案，有效覆盖现有技术的盲区。可参见图9b，图9b是本发明实施例提供的一种终端应用卡死恢复的操作示意图，针对应用卡死的应用启动超时或应用绘制异常场景，提供可恢复的方案。例如，当确定终端的卡死场景为应用启动超时或应用绘制异常时，通过弹窗的形式向用户发送消息，提示用户某应用无响应，由用户确定是否执行关闭复位该应用的操作恢复卡死的终端。需要说明的是，向用户发送消息的方式包括但不限于弹窗的形式。
227.综上，本技术克服了现有终端卡死恢复技术中存在的恢复等待时间长、恢复操作缺乏灵活性、部分场景缺少可恢复机制等缺点。
228.需要说明的是，本技术对于以下情况能够快速、准确地恢复卡死的终端：系统卡死下的进程间死锁；系统卡死下的进程内死锁；系统卡死下的服务调用阻塞；应用卡死下的应用启动超时或应用绘制异常。
229.上述详细阐述了本发明实施例的方法，下面提供了本发明实施例的相关装置。
230.请参见图10，图10是本发明实施例提供的一种终端卡死恢复装置的结构示意图，该终端卡死恢复装置10可以包括第一检测单元101、第一确定单元102、第二确定单元103和恢复单元104，其中，各个单元的详细描述如下。
231.第一检测单元101，用于检测终端持续卡死时间是否到达预置时间t1；
232.第一确定单元102，用于确定所述终端的卡死原因；所述卡死原因包括系统卡死或应用卡死；
233.第二确定单元103，用于用于确定所述终端的卡死场景；
234.恢复单元，用于执行与所述卡死场景匹配的预设操作恢复所述终端；
235.其中，所述预置时间t1小于所述终端的默认复位时间t2。
236.在一种可能的实现方式中，所述第一确定单元102，具体用于：
237.获取系统级检测机制和/或应用级检测机制的检测结果；根据所述检测结果确定所述终端的卡死原因。
238.在一种可能的实现方式中，所述第二确定单元103，具体用于：
239.当确定所述终端的卡死原因为系统卡死时，获取系统进程调用机制的状态，所述系统进程调用机制的状态包括进程间的访问状态、进程内线程间的访问状态中的一种或多种；
240.根据所述系统进程调用机制的状态，确定所述终端的卡死场景。
241.在一种可能的实现方式中，所述第二确定单元103，具体用于：
242.当所述进程间的访问状态为系统进程和其他外部进程出现进程之间相互调用，由于相互等待造成的死锁时，确定所述终端的卡死场景为进程间死锁；
243.所述恢复单元104，具体用于：
244.执行与所述进程间死锁匹配的所述预设操作，所述预设操作为复位所述其他外部进程。
245.在一种可能的实现方式中，所述第二确定单元103，具体用于：
246.当所述进程内的访问状态为系统进程内两个或两个以上核心线程互相等待造成的死锁时，确定所述终端的卡死场景为进程内死锁；
247.所述恢复单元104，具体用于：
248.执行与所述进程内死锁匹配的所述预设操作，所述预设操作为复位所述终端。
249.在一种可能的实现方式中，所述第二确定单元103，具体用于：
250.当所述进程间的访问状态为系统进程调用系统服务，所述系统服务无响应导致所述终端卡死时，确定所述终端的卡死场景为服务调用阻塞；
251.所述恢复单元104，具体用于：
252.执行与所述服务调用阻塞匹配的所述预设操作，所述预设操作为复位所述系统服务。
253.在一种可能的实现方式中，所述恢复单元104，具体用于：
254.确定所述系统服务是否为系统核心服务；
255.若非系统核心服务则复位所述系统服务；
256.若是系统核心服务则继续等待，直至所述系统服务自动恢复，或所述终端卡死时间到达所述默认复位时间t2时，复位所述终端。
257.在一种可能的实现方式中，所述第二确定单元103，具体用于：
258.当确定所述终端的卡死原因为应用卡死时，获取应用级检测机制上报应用异常的内容，所述应用异常的内容为卡死应用的异常报告，所述卡死应用的异常报告包括应用启动异常报告、应用绘制异常报告中的一种或多种；
259.根据所述卡死应用的异常报告，确定所述终端的卡死场景；
260.所述终端的卡死场景包括应用启动超时或应用绘制异常。
261.在一种可能的实现方式中，所述第二确定单元103，具体用于：
262.当所述卡死应用的异常报告包括启动流程超时导致异常时，确定所述终端的卡死场景为应用启动超时；
263.当所述卡死应用的异常报告包括绘制流程出现畸形窗口导致异常时，确定所述终端的卡死场景为应用绘制异常；
264.所述恢复单元104，具体用于：
265.执行与所述应用启动超时或应用绘制异常匹配的所述预设操作，所述预设操作为复位所述卡死应用。
266.在一种可能的实现方式中，所述装置，还包括：
267.第二检测单元105，用于在所述执行与所述卡死场景匹配的预设操作恢复所述终端之前，检测是否存在异常触摸事件；所述异常触摸事件包括触摸所述终端的显示屏超过预设次数无响应、点击所述终端的功能键超过预设次数无响应中的一种或多种；
268.所述恢复单元104，具体用于：
269.当所述终端的卡死场景为应用启动超时或应用绘制异常，且存在所述异常触摸事件时，执行与所述卡死场景匹配的预设操作恢复所述终端。
270.在一种可能的实现方式中，所述恢复单元104，具体用于：
271.发送第一消息，所述第一消息用于提示用户确认是否执行所述预设操作；
272.当接收到用户确认执行所述预设操作的指令后，执行所述预设操作恢复所述终端；
273.所述装置，还包括：
274.提示单元106，用于在恢复所述终端后，发送第二消息；所述第二消息用于提示用户所述终端的卡死原因、所述终端的卡死场景中的一种或多种。
275.需要说明的是，本发明实施例中所描述的终端卡死恢复装置10中各功能单元的功能可参见上述图3中所述的方法实施例中步骤s300-步骤s303的相关描述，此处不再赘述。
276.如图11所示，图11是本发明实施例提供的另一种终端卡死恢复装置的结构示意图，该装置20包括至少一个处理器201，至少一个存储器202、至少一个通信接口203。此外，该设备还可以包括天线等通用部件，在此不再详述。
277.处理器201可以是通用中央处理器(cpu)，微处理器，特定应用集成电路(application-specific integrated circuit，asic)，或一个或多个用于控制以上方案程序执行的集成电路。
278.通信接口203，用于与其他设备或通信网络通信，如以太网，无线接入网(ran)，核心网，无线局域网(wireless local area networks，wlan)等。
279.存储器202可以是只读存储器(read-only memory，rom)或可存储静态信息和指令的其他类型的静态存储设备，随机存取存储器(random access memory，ram)或者可存储信息和指令的其他类型的动态存储设备，也可以是电可擦可编程只读存储器(electrically erasable programmable read-only memory，eeprom)、只读光盘(compact disc read-only memory，cd-rom)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用
光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。存储器可以是独立存在，通过总线与处理器相连接。存储器也可以和处理器集成在一起。
280.其中，所述存储器202用于存储执行以上所述的终端卡死恢复方法的应用程序代码，并由处理器201来控制执行。所述处理器201用于执行所述存储器202中存储的应用程序代码。
281.存储器202存储的代码可执行以上图3提供的终端卡死恢复方法，比如当检测到终端卡死持续时间到达预置时间t1时，确定所述终端的卡死原因；根据所述卡死原因确定所述终端的卡死场景；执行与所述卡死场景匹配的预设操作恢复所述终端。其中，所述预置时间t1小于所述终端的默认复位时间t2。
282.需要说明的是，本发明实施例中所描述的终端卡死恢复装置20中各功能单元的功能可参见上述图3中所述的方法实施例中的步骤s300-步骤s303相关描述，此处不再赘述。
283.在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。
284.需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本技术并不受所描述的动作顺序的限制，因为依据本技术，某些步骤可能可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本技术所必须的。
285.在本技术所提供的几个实施例中，应该理解到，所揭露的装置，可通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如上述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性或其它的形式。
286.上述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本发明实施例方案的目的。
287.另外，在本技术各实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
288.上述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本技术的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以为个人计算机、服务端或者网络设备等，具体可以是计算机设备中的处理器)执行本技术各个实施例上述方法的全部或部分步骤。其中，而前述的存储介质可包括：u盘、移动硬盘、磁碟、光盘、只读存储器(read-onlymemory，缩写：rom)或者随机存取存储器
(randomaccessmemory，缩写：ram)等各种可以存储程序代码的介质。
289.以上所述，以上实施例仅用以说明本技术的技术方案，而非对其限制；尽管参照前述实施例对本技术进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本技术各实施例技术方案的精神和范围。