CN116450387A - 看门狗检测方法及电子设备 - Google Patents

Abstract

本申请提供了一种看门狗检测方法。该方法包括：在系统服务进程初始化的过程中，第一看门狗启动；其中，第一看门狗用于检测系统服务进程，并在系统服务进程异常时重启该系统服务进程，该系统服务进程位于电子设备的应用程序框架层中；第二看门狗启动对第一看门狗的检测功能；其中，第二看门狗位于电子设备内核层中，还用于对内核系统进行检测；第二看门狗在第一看门狗异常时，重启内核系统。这样，由于第二看门狗对第一看门狗的检测功能是在系统服务进程启动后才启动的，因此可以避免第二看门狗在系统服务进程启动前就对第一看门狗进行检测的问题，进而不出现第二看门狗在系统服务进程启动前误认为第一看门狗异常而重启内核系统的现象。

Description

看门狗检测方法及电子设备

技术领域

本申请涉及智能终端领域，尤其涉及一种看门狗检测方法及电子设备。

背景技术

看门狗，又称watchdog timer，从本质上来讲就是一个定时器。看门狗可以分为软件看门狗和硬件看门狗。看门狗，一般有一个输入一个输出，其中，输入叫做喂狗(kickingthe dog or service the dog)，输出一般用于在其检测的业务进程或硬件出现异常时，对相应的业务进程或硬件进行复位，以使其检测的业务进程或硬件恢复正常。

虽然软件看门狗可以对其检测的业务进程进行恢复，但在实际应用中，由于不可控因素的干扰，软件看门狗有可能无法成功复位其检测的业务进程，甚至软件看门狗失效，从而影响设备的正常使用。

发明内容

为了解决上述技术问题，本申请提供一种看门狗检测方法及电子设备。在该方法中，第二看门狗不仅用于对内核系统进行检测，还用于对第一看门狗进行检测。其中，第一看门狗用于检测位于电子设备应用程序框架层中的系统服务进程，并在系统服务进程异常时重启系统服务进程。由于第二看门狗对第一看门狗的检测功能是在系统服务进程启动后才启动的，因此可以避免第二看门狗在系统服务进程启动前就对第一看门狗进行检测的问题，进而不出现第二看门狗在系统服务进程启动前误认为第一看门狗异常而重启内核系统的现象。

第一方面，本申请提供一种看门狗检测方法。该方法包括：在系统服务进程初始化的过程中，第一看门狗启动；其中，第一看门狗用于检测系统服务进程，并在系统服务进程异常时重启系统服务进程；系统服务进程位于电子设备的应用程序框架层中；第二看门狗启动对第一看门狗的检测功能；其中，第二看门狗位于电子设备内核层中，第二看门狗还用于对内核系统进行检测；第二看门狗在第一看门狗异常时，重启内核系统。这样，由于第二看门狗对第一看门狗的检测功能是在系统服务进程启动后才启动的，因此可以避免第二看门狗在系统服务进程启动前就对第一看门狗进行检测的问题，进而不出现第二看门狗在系统服务进程启动前误认为第一看门狗异常而重启内核系统的现象。

示例性的，第一看门狗为下述提及的System Server WatchDog，第二看门狗为下述提及的Hungdetect看门狗。

根据第一方面，在系统服务进程初始化之前，该方法还包括：在内核系统初始化的过程中，第二看门狗启动；第二看门狗在检测到内核系统异常时，重启内核系统。这样，当内核系统启动时，第二看门狗对内核系统的检测功能就启动，能够实现对内核系统运行状态的有效检测。

根据第一方面，或者以上第一方面的任意一种实现方式，第二看门狗启动对第一看门狗的检测功能，包括：第二看门狗如果接收到指示信息，则启动对第一看门狗的检测功能；其中，指示信息用于指示系统服务进程执行初始化操作。

根据第一方面，或者以上第一方面的任意一种实现方式，第二看门狗在第一看门狗异常时，重启内核系统，包括：第二看门狗在第一看门狗失效或者第一看门狗无法成功重启系统服务进程时，重启内核系统。这样，无论是第一看门狗自身失效，还是第一看门狗在系统服务进程异常时无法成功重启系统服务进程，第二看门狗都能够通过重启内核系统以实现对应用程序框架层中系统服务进程的恢复。

根据第一方面，或者以上第一方面的任意一种实现方式，该方法还包括：第一看门狗在系统服务进程正常时，定时对第二看门狗进行喂狗操作；第一看门狗在系统服务进程正常时，停止对第二看门狗的喂狗操作；如果第二看门狗在一个或连续多个检测周期内没有接收到第一看门狗的喂狗操作，则确定第一看门狗异常。

根据第一方面，或者以上第一方面的任意一种实现方式，该方法还包括：系统服务进程定时检测目标服务是否运行正常；其中，目标服务运行在系统服务进程中；如果目标服务运行正常，则系统服务进程对第一看门狗进行喂狗操作；如果目标服务运行异常，则系统服务进程停止对第一看门狗的喂狗操作；如果第一看门狗在一个或连续多个检测周期内没有接收到系统服务进程的喂狗操作，则确定系统服务进程异常。

根据第一方面，或者以上第一方面的任意一种实现方式，目标服务至少包括窗口管理服务、运行管理服务、包管理服务。

根据第一方面，或者以上第一方面的任意一种实现方式，第二检测周期是第一检测周期的整数倍；其中，第一检测周期为第一看门狗对系统服务进程的检测周期，第二检测周期为第二看门狗对第一看门狗的检测周期。这样，由于第二检测周期长于第一检测周期，达到了先由第一看门狗对应用程序框架层进行恢复，再由第二看门狗当第一看门狗无法成功对应用程序框架层进行恢复时再对内核系统进行恢复，以此确保了电子设备分层分级恢复的效果。

第二方面，本申请提供一种电子设备。该电子设备包括：一个或多个处理器；一个或多个存储器；所述一个或多个存储器存储有一个或多个程序，当所述一个或者多个程序被所述一个或多个处理器执行时，使得所述电子设备执行第一方面以及第一方面中任意一项的看门狗检测方法。

第二方面以及第二方面的任意一种实现方式分别与第一方面以及第一方面的任意一种实现方式相对应。第二方面以及第二方面的任意一种实现方式所对应的技术效果可参见上述第一方面以及第一方面的任意一种实现方式所对应的技术效果，此处不再赘述。

第三方面，本申请提供了一种计算机可读介质，该计算机可读存储介质包括计算机程序，当计算机程序在电子设备上运行时，使得电子设备执行第一方面以及第一方面中任意一项的看门狗检测方法。

第三方面以及第三方面的任意一种实现方式分别与第一方面以及第一方面的任意一种实现方式相对应。第三方面以及第三方面的任意一种实现方式所对应的技术效果可参见上述第一方面以及第一方面的任意一种实现方式所对应的技术效果，此处不再赘述。

附图说明

图1为示例性示出的电子设备的硬件结构示意图；

图2为示例性示出的电子设备的软件结构示意图；

图3为示例性示出的本申请实施例提供的看门狗检测方法对应的系统架构示意图；

图4为示例性示出的本申请实施例提供的看门狗检测方法的流程示意图之一；

图5为针对图4所示的看门狗检测方法适用于的应用场景的示意图；

图6为示例性示出的本申请实施例提供的看门狗检测方法的流程示意图之一；

图7为示例性示出的本申请实施例提供的看门狗检测方法的流程示意图之二；

图8为针对图7所示的看门狗检测方法适用于的应用场景的示意图；

图9为示例性示出的本申请实施例提供的看门狗检测方法的流程示意图之三；

图10为针对图9所示的看门狗检测方法适用于的应用场景的示意图；

图11为示例性示出的看门狗检测方法适用于的应用场景的又一示意图；

图12为示例性示出的看门狗检测方法适用于的应用场景的又一示意图；

图13为示例性示出的CPU核状态检测示意图之一；

图14为示例性示出的CPU核状态检测示意图之二；

图15为示例性示出的看门狗检测方法适用于的应用场景的又一示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。

本申请实施例的说明书和权利要求书中的术语“第一”和“第二”等是用于区别不同的对象，而不是用于描述对象的特定顺序。例如，第一目标对象和第二目标对象等是用于区别不同的目标对象，而不是用于描述目标对象的特定顺序。

在本申请实施例中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本申请实施例中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。

在本申请实施例的描述中，除非另有说明，“多个”的含义是指两个或两个以上。例如，多个处理单元是指两个或两个以上的处理单元；多个系统是指两个或两个以上的系统。

图1示出了电子设备100的结构示意图。可选地，电子设备100可以为终端，也可以称为终端设备，终端可以为蜂窝电话(cellular phone)或平板电脑(pad)等，本申请不做限定。应该理解的是，图1所示电子设备100仅是电子设备的一个范例，并且电子设备100可以具有比图中所示的更多的或者更少的部件，可以组合两个或多个的部件，或者可以具有不同的部件配置。图1中所示出的各种部件可以在包括一个或多个信号处理和/或专用集成电路在内的硬件、软件、或硬件和软件的组合中实现。

电子设备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可以包括压力传感器，陀螺仪传感器，气压传感器，磁传感器，加速度传感器，距离传感器，接近光传感器，指纹传感器，温度传感器，触摸传感器，环境光传感器，骨传导传感器等。

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

其中，控制器可以是电子设备100的神经中枢和指挥中心。控制器可以根据指令操作码和时序信号，产生操作控制信号，完成取指令和执行指令的控制。

处理器110中还可以设置存储器，用于存储指令和数据。在一些实施例中，处理器110可以包括一个或多个接口，如PCM接口，通用串行总线(universal serial bus，USB)接口等。PCM接口也可以用于音频通信，将模拟信号抽样，量化和编码。在一些实施例中，音频模块170与无线通信模块160可以通过PCM总线接口耦合。在一些实施例中，音频模块170也可以通过PCM接口向无线通信模块160传递音频信号，实现通过蓝牙耳机接听电话的功能。所述I2S接口和所述PCM接口都可以用于音频通信。USB接口130是符合USB标准规范的接口，具体可以是Mini USB接口，Micro USB接口，USB Type C接口等。USB接口130可以用于连接充电器为电子设备100充电，也可以用于电子设备100与外围设备之间传输数据。也可以用于连接耳机，通过耳机播放音频。该接口还可以用于连接其他电子设备，例如AR设备等。

此外，需要说明的是，在一些实施例中，处理器110可以内置硬件看门狗，例如，将处理器110中的定时器作为硬件看门狗。处理器110通过程序的初始化，写入初值，并启动定时器对处理器110进行检测。一旦处理器110发生错误，这个定时器就向处理器110发出重启信号。

在另外一些实施例中，电子设备100中可以设置独立的看门狗芯片作为硬件看门狗，用于对处理器110进行检测。其中，看门狗芯片主要包括一个用于喂狗的引脚(一般与处理器110的GPIO(General Purpose Input Output，通用输入/输出)引脚相连)和一个复位引脚(与处理器110的复位/重启(RESET)引脚相连)。如果处理器110没有在一定时间内改变喂狗引脚的电平，复位引脚就会改变状态以复位处理器110。

充电管理模块140用于从充电器接收充电输入。充电管理模块140为电池142充电的同时，还可以通过电源管理模块141为电子设备供电。电源管理模块141用于连接电池142，充电管理模块140与处理器110。电源管理模块141接收电池142和/或充电管理模块140的输入，为处理器110，内部存储器121，外部存储器，显示屏194，摄像头193，和无线通信模块160等供电。

电子设备100的无线通信功能可以通过天线1，天线2，移动通信模块150，无线通信模块160，调制解调处理器以及基带处理器等实现。天线1和天线2用于发射和接收电磁波信号。移动通信模块150可以提供应用在电子设备100上的包括2G/3G/4G/5G等无线通信的解决方案。无线通信模块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)等无线通信的解决方案。在一些实施例中，电子设备100的天线1和移动通信模块150耦合，天线2和无线通信模块160耦合，使得电子设备100可以通过无线通信技术与网络以及其他设备通信。

电子设备100通过GPU，显示屏194，以及应用处理器等实现显示功能。显示屏194用于显示图像，视频等。在一些实施例中，电子设备100可以包括1个或N个显示屏194，N为大于1的正整数。

电子设备100可以通过ISP，摄像头193，视频编解码器，GPU，显示屏194以及应用处理器等实现拍摄功能。摄像头193用于捕获静态图像或视频。在一些实施例中，电子设备100可以包括1个或N个摄像头193，N为大于1的正整数。

视频编解码器用于对数字视频压缩或解压缩。电子设备100可以支持一种或多种视频编解码器。这样，电子设备100可以播放或录制多种编码格式的视频，例如：动态图像专家组(moving picture experts group，MPEG)1，MPEG2，MPEG3，MPEG4等。

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

内部存储器121可以用于存储计算机可执行程序代码，所述可执行程序代码包括指令。处理器110通过运行存储在内部存储器121的指令，从而执行电子设备100的各种功能应用以及数据处理，使得电子设备100实现本申请实施例中的看门狗检测方法。内部存储器121可以包括存储程序区和存储数据区。其中，存储程序区可存储操作系统，至少一个功能所需的应用程序(比如声音播放功能，图像播放功能等)等。存储数据区可存储电子设备100使用过程中所创建的数据(比如音频数据，电话本等)等。

电子设备100可以通过音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D，以及应用处理器等实现音频功能。例如音乐播放，录音等。

音频模块170用于将数字音频信息转换成模拟音频信号输出，也用于将模拟音频输入转换为数字音频信号。音频模块170还可以用于对音频信号编码和解码。在一些实施例中，音频模块170可以设置于处理器110中，或将音频模块170的部分功能模块设置于处理器110中。

扬声器170A，也称“喇叭”，用于将音频电信号转换为声音信号。电子设备100可以通过扬声器170A收听音乐，或收听免提通话。

受话器170B，也称“听筒”，用于将音频电信号转换成声音信号。当电子设备100接听电话或语音信息时，可以通过将受话器170B靠近人耳接听语音。

麦克风170C，也称“话筒”，“传声器”，用于将声音信号转换为电信号。

耳机接口170D用于连接有线耳机。耳机接口170D可以是USB接口130，也可以是3.5mm的开放移动电子设备平台(open mobile terminal platform，OMTP)标准接口，美国蜂窝电信工业协会(cellular telecommunications industry association of the USA，CTIA)标准接口。

压力传感器用于感受压力信号，可以将压力信号转换成电信号。在一些实施例中，压力传感器可以设置于显示屏194。在一些实施例中，作用于相同触摸位置，但不同触摸操作强度的触摸操作，可以对应不同的操作指令。

触摸传感器，也称“触控面板”。触摸传感器可以设置于显示屏194，由触摸传感器与显示屏194组成触摸屏，也称“触控屏”。触摸传感器用于检测作用于其上或附近的触摸操作。触摸传感器可以将检测到的触摸操作传递给应用处理器，以确定触摸事件类型。可以通过显示屏194提供与触摸操作相关的视觉输出。

按键190包括开机键，音量键等。电子设备100可以接收按键输入，产生与电子设备100的用户设置以及功能控制有关的键信号输入。

电子设备100的软件系统可以采用分层架构，事件驱动架构，微核架构，微服务架构，或云架构。本申请实施例以分层架构的Android系统为例，示例性说明电子设备100的软件结构。

图2是本申请实施例的电子设备100的软件结构框图。

电子设备100的分层架构将软件分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中，将Android系统分为三层，从上至下分别为应用程序层，应用程序框架层，以及内核层。

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

如图2所示，应用程序包可以包括相机，图库，日历，通话，地图，导航，音乐，视频，短信息等应用程序。

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

如图2所示，应用程序框架层可以包括系统服务(System Server)、系统服务看门狗(System Server WatchDog)、图层整合器(SurfaceFlinger)、系统关键任务超时检测看门狗(Xcollie)、初始化服务(Init)、初始化服务看门狗(Init看门狗)等。

System Server是Android基本服务的提供者，是Android系统运行的最基本需求。系统中的一些服务驻留在System Server中,常见的比如WMS(Window Manager Server，窗口管理服务)、AMS(Activity Manager System Service，运行管理服务)、PMS(PackageManager Server，包管理服务)等，这些服务都以一个线程的方式存在于System Server进程中。

System Server WatchDog，用来检测System Server是否发生了死锁，无响应等问题。当System Server出现故障时，System Server WatchDog杀死(kill)System Server进程，实现软重启进行System Server的自恢复。其中，System Server WatchDog检测的对象主要分为两类，一个是对象锁，一个是线程的处理器(Handler)。

其中，System Server WatchDog是在System Server进程中被初始化和启动的。在System Server被启动时，各种Android服务被注册和启动，其中也包括了System ServerWatchDog的初始化和启动。

System Server周期性地检测AMS、WMS等关键服务是否正常运行。若SystemServer检测AMS、WMS等关键服务都正常运行，则对System Server WatchDog进行喂狗操作。若System Server检测到AMS、WMS等关键服务中任一运行不正常，则不对System ServerWatchDog进行喂狗操作。当System Server连续多个(如三个)周期不对System ServerWatchDog进行喂狗操作时，System Server WatchDog复位System Server进程。

SurfaceFlinger，是在System Server进程中启动的，并且负责统一管理设备的帧缓冲区。SurfaceFlinger在启动的过程中会创建两个线程，其中一个线程用来检测控制台事件，而另外一个线程用来渲染系统的UI。具体的，SurfaceFlinger可以用于对显示子系统进行管理，并且未多个应用程序提供2D和3D图层的融合。

在一些实现方式中，SurfaceFlinger也可以设置与安卓系统的系统库中，本申请对此不做限定。

系统关键任务超时检测看门狗(Xcollie)，用于检测关键进程中执行的动作是否完成。其中，Xcollie可以设置两个线程，一个线程用于在关键线程执行动作开始时将关键进程的状态标记设置为正常，并根据关键进程执行动作是否超时确定是否将关键进程的状态标记设置为异常，一个线程用于轮询各个关键进程的状态，并在关键进程的状态标记为异常时复位该关键进程。

示例性的，关键进程可以是SurfaceFlinger、Vold(volume Daemon)、AudioFlinger、Face Regconize(人脸识别)等。

其中，Vold，即Volume守护进程，用来管理Android中存储类的热拔插事件。AudioFlinger是音频系统策略的执行者，负责音频流设备的管理及音频流数据的处理传输。Face Regconize用于实现人脸识别、人脸验证等。

Init，是Linux系统用户空间的第一个进程，也就是基于Linux内核的Android系统用户空间的第一个进程。其中，Init进程主要负责解析property文件并初始化property，解析脚本init.rc、触发Action及启动Service，提供系统property服务管理及完成对应的触发事件，以及维护系统级Service。

Init看门狗，用于对Init流程进行检测，并在Init流程异常时复位Init进程。

内核层是硬件和软件之间的层。

如图2所示，内核层至少包含卡死检测看门狗(Hungdetect看门狗)和CPU核状态看门狗。

其中，Hungdetect看门狗，用于对内核系统进行检测，并在内核错误(KernelPanic)时，控制内核重启。

在本实施例中，Hungdetect看门狗还用于对System Server WatchDog、Xcollie以及Init看门狗进行检测，并在System Server WatchDog、Xcollie以及Init看门狗任一失效，或者System Server WatchDog、Xcollie以及Init看门狗任一检测的业务无法恢复时，控制内核重启。

CPU核状态看门狗，用于对CPU各个核的运行状态进行检测，并在CPU核状态满足预设内核重启条件时，控制内核重启。

在本实施例中，硬件看门狗还可以对Hungdetect看门狗和CPU核状态看门狗进行检测，例如对Hungdetect看门狗和CPU核状态看门狗的复位动作进行检测。其中，在Hungdetect看门狗和CPU核状态看门狗任一失效，或者Hungdetect看门狗和CPU核状态看门狗无法成功重启内核时，硬件看门狗可以控制整机重启。

示例性的，内核层还可以包括用于检测进程是否处于D(uninterruptible sleep，不可中断的深度睡眠)状态的软件看门狗(本文将其称为hungtast看门狗)。

相应的，在实际应用中，硬件看门狗还可以对hungtast看门狗进行检测。可以理解的，关于硬件看门狗对hungtast看门狗的检测，可以参见上述硬件看门狗对hungdetect看门狗的检测，在此不再赘述。

可以理解的是，图2示出的软件结构中的层以及各层中包含的部件，并不构成对电子设备100的具体限定。在本申请另一些实施例中，电子设备100可以包括比图示更多或更少的层，以及每个层中可以包括更多或更少的部件，本申请不做限定。

可以理解的是，电子设备为了实现本申请中的看门狗检测方法，其包含了执行各个功能相应的硬件和/或软件模块。结合本文中所公开的实施例描述的各示例的算法步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。本领域技术人员可以结合实施例对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

本申请实施例提供一种看门狗检测方法。在本实施例中，电子设备下层看门狗不仅可以对本层业务是否异常进行检测，并在本层业务异常时对本层业务进行复位操作。电子设备下层看门狗还可以对上层看门狗进行检测，在上层看门狗失效或者上层看门狗无法恢复上层业务时，对本层业务进行复位操作，以此实现对上层业务的恢复，也即实现了分层分级恢复的看门狗检测方法。

需要说明的是，本实施例中涉及的“层”可以是按照电子设备软件和硬件划分的，也可以是按照电子设备系统架构划分的，本申请对此不做限制。

图3为本申请实施例提供的系统架构图。下述以电子设备的第一层和第二层为例，对本实施例提供的看门狗检测方法进行解释说明。其中，第一层为第二层的上一层。

如图3所示，在电子设备第一层中包括第一看门狗，用于检测第一层中的第一业务，在第一业务异常时对第一业务进行复位或重启操作。

示例性的，当第一业务正常运行时，第一业务定时对第一看门狗进行第一喂狗操作。当第一业务无法正常运行时，第一业务停止对第一看门狗的第一喂狗操作。第一看门狗如果在一个检测周期内或者连续多个(如3个)检测周期内没有接收到第一业务的第一喂狗操作，则对第一业务进行复位或重启操作。

又示例性的，第一看门狗定时获取第一业务的第一状态标记。当第一业务正常运行时，其第一状态标记指示业务正常；当第一业务无法正常运行时，其第一状态标记指示业务异常。例如，状态标记为“ERROR”时，指示业务异常；状态标记为“OK”时，指示业务正常。第一看门狗如果获取到的第一业务的第一状态标记指示第一业务异常，或者连续多个(如3个)检测周期内获取到的第一业务的第一状态标记均指示第一业务异常，则对第一业务进行复位或重启操作。

如图3所示，在电子设备第二层中包括第二看门狗，用于检测第二层中的第二业务，在第二业务异常时对第二业务进行复位或重启操作。

示例性的，当第二业务正常运行时，第二业务定时对第二看门狗进行第二喂狗操作。当第二业务无法正常运行时，第二业务停止对第二看门狗的第二喂狗操作。第二看门狗如果在一个检测周期内或者连续多个(如3个)检测周期内没有接收到第二业务的第二喂狗操作，则对第二业务进行复位或重启操作。

又示例性的，第二看门狗定时获取第二业务的第二状态标记。当第二业务正常运行时，其第二状态标记指示业务正常；当第二业务无法正常运行时，其第二状态标记指示业务异常。第二看门狗如果获取到的第二业务的第二状态标记指示第二业务异常，或者连续多个(如3个)检测周期内获取到的第二业务的第二状态标记均指示第二业务异常，则对第二业务进行复位或重启操作。

继续参照图3，第二看门狗，除了检测第二层中的第二业务，还用于检测第一看门狗，并在第一看门狗异常时对第二业务进行复位或重启操作，以在第二业务复位或重启成功后重新加载运行第一层中的第一业务，使得第一业务恢复正常。其中，第一看门狗异常可以指的是第一看门狗失效，也可以是第一看门狗无法成功恢复或重启第一业务。

示例性的，当第一看门狗正常运行且其检测的第一业务正常运行时，第一看门狗定时对第二看门狗进行第三喂狗操作。当第一看门狗无法正常运行，或者无法成功恢复或重启第一业务时，第一看门狗停止对第二看门狗的第三喂狗操作。第二看门狗如果在一个检测周期内或者连续多个(如3个)检测周期内没有接收到第一看门狗的第三喂狗操作，则对第二业务进行复位或重启操作。

又示例性的，第二看门狗定时获取第一看门狗的第三状态标记。当第一看门狗正常运行且其检测的第一业务正常运行时，第一看门狗的第三状态标记指示业务正常；当第一看门狗无法正常运行，或者无法成功恢复或重启第一业务时，第一看门狗的第三状态标记指示业务异常。第二看门狗如果获取到的第一看门狗的第三状态标记指示业务异常，或者连续多个(如3个)检测周期内获取到的第一看门狗的第三状态标记均指示业务异常，则对第二业务进行复位或重启操作。

其中，第一看门狗和第二看门狗均为软件看门狗时，第二看门狗针对第一看门狗的检测周期长于第一看门狗对第一业务的检测周期。可选的，第二看门狗针对第一看门狗的检测周期是第一看门狗对第一业务的检测周期的整数倍，如2倍。

作为一种可选的实施方式，第一层为电子设备的应用程序层，第二层为电子设备的应用程序框架层。其中，第一业务为应用程序，第二业务为系统服务。

作为另一种可选的实施方式，第一层为电子设备的应用程序框架层，第二层为电子设备的内核层。其中，第一业务为系统服务，第二业务为内核系统。

作为又一种可选的实施方式，第一层为电子设备的应用程序内核层，第二层为电子设备的硬件层。其中，第一业务为内核系统，第二业务为处理芯片。

需要指出的是，第二看门狗对第二业务进行复位或重启操作，可以是由第二业务停止第一喂狗操作或者第二业务的状态标记指示业务异常触发的，也可以是由第一看门狗停止第二喂狗操作或者第一看门狗的状态标记指示业务异常触发的。

这样，通过设置层与层之间的检测机制，实现了对电子设备的分层分级恢复。由于第二层是第一层的下层，所以第二层进行业务恢复或重启的颗粒度要大于第一层进行业务恢复或重启的颗粒度，使第一层业务恢复的成功率就越高。其中，当电子设备第一层中的第一看门狗无法成功恢复其检测的第一业务时，可以通过第二层(也即下一层)来恢复第一层中第一业务，也即在将第二业务复位或重启后重新加载运行第一业务，以此使第一层中第一业务得以恢复正常。若第二层中第二业务也无法成功恢复时，可以继续通过其下一层(也即第三层)来恢复，由此能够避免电子设备某一层中反复执行复位或重启操作却无法成功的问题。

基于上述描述的电子设备分层分级的恢复方案，以下通过其适用于的几种具体场景对本申请技术方案进行详细说明。

场景一

在本场景中，电子设备的应用程序框架层与内核层之间设置检测机制，以内核层中Hungdetect看门狗(卡死检测看门狗)对应用程序框架层中System Server WatchDog(系统服务看门狗)进行检测为例，对本申请提供的看门狗检测方法进行解释说明。

图4为示例性示出的System Server WatchDog执行看门狗检测方法的流程示意图。

如图4所示，System Server WatchDog执行看门狗检测方法的流程，具体包括：

步骤101，在系统服务进程启动的过程中，初始化系统服务看门狗。

通过上述描述可知，系统服务看门狗，即System Server WatchDog是用于检测应用程序框架层中的系统服务进程，即System Server进程的，例如检测System Server进程是否发生了死锁，无响应等问题。

步骤102，系统服务进程按照预设周期检测自身是否在正常运行。

需要说明的是，由于在System Server进程启动时，各种Android服务会被注册和启动，例如AMS、WMS等。因此，步骤102中的操作例如是系统服务进程周期性地检测运行于其中的上述注册和启动的关键服务是否运行正常。

相应的，在这些关键服务正常运行时，确定系统服务进程当前正常运行，执行步骤103；否则，确定系统服务进程无法正常运行，执行步骤105。

步骤103，系统服务进程向系统服务看门狗发送第一喂狗信息。

示例性的，在一些实现方式中，系统服务进程向系统服务看门狗发送的第一喂狗信息，例如可以是“kick”标记信息，也可以是其他约定好的信息。

基于看门狗的工作原理，系统服务看门狗在喂狗周期内接收到系统服务进程发送的第一喂狗信息，便会认为系统服务进程当前能够正常运行，无需执行复位操作，即系统服务看门狗接收到第一喂狗信息后，不对系统服务进程做处理。

步骤104，系统服务看门狗向位于内核层的卡死检测看门狗发送第二喂狗信息。

示例性的，在一些实现方式中，统服务看门狗向卡死检测看门发送的第二喂狗信息，例如可以是“kick”标记信息，也可以是其他约定好的信息。

基于看门狗的工作原理，卡死检测看门在喂狗周期内接收到系统服务看门狗送的第二喂狗信息，便会认为系统服务进程当前能够正常运行，无需执行复位操作，即卡死检测看门接收到第二喂狗信息后，不对会重启内核系统。

本实施例对步骤103和步骤104的时序不做限定。

步骤105，在喂狗周期内，系统服务看门狗如果没有接收到系统服务进程发送的第一喂狗信息，停止向卡死检测看门狗发送第二喂狗信息，并对系统服务进程执行复位操作。

具体的说，在一些实现方式中，为了避免频繁的对系统服务进程执行复位操作，即重启，降低用户使用电子设备的影响，可以设置系统服务看门狗在连续多个(如3个)喂狗周期，或者说检测周期内没有接收到系统服务进程发送的第一喂狗信息时，再对系统服务进程执行复位操作。

进一步地，在一些实现方式中，为了避免系统服务进程发送了第一喂狗信息，但因为某些原因，如外在因素的干扰导致第一喂狗信息没有及时到达系统服务看门狗，进而导致系统服务看门狗误以为系统服务进程出现异常，而对系统服务进程执行复位操作。可以设置在n个喂狗周期内没有接收到系统服务进程发送的第一喂狗信息时，先触发狗叫，在(n+m)个喂狗周期内没有接收到系统服务进程发送的第一喂狗信息时，再执行狗咬。

示例性的，n为大于0的整数，m为大于0的整数。

此外，关于上述所说狗咬，即触发系统服务看门狗对系统服务进程执行复位操作，而狗叫则是为了提醒运维人员对系统进行维护测试。

相应的，为了便于运维人员对系统进行维护测试，并且精准定位异常问题。在触发狗叫时，系统服务看门狗可以通过预先编译好的dump逻辑抓取异常日志。

此外，需要说明的，当系统服务看门狗停止向卡死检测看门狗发送第二喂狗信息时，如果在预设周期内没有接收系统服务看门狗发送的第二喂狗信息，则会认为系统服务看门狗没有成功复位系统服务进程，或者系统服务看门狗失效，即无法对系统服务进程进行复位。这种情况下，卡死检测卡门狗便会执行复位操作，即重启内核系统。这样，在内核重启成功后，System Server进程便会被重新加载启动，从而恢复正常。

此外，对于卡死检测看门狗，除了会接收来自上层的系统服务看门狗提供的第一喂狗信息，还会接收本层检测的内核系统提供的第三喂狗信息。故而，在实际应用中，触发卡死检测看门狗执行复位操作的条件可以是在预设周期未接收到第二喂狗信息，也可以是在预设周期未接收到第三喂狗信息。

此外，由于第二喂狗信息和第三喂狗信息时来自不同的对象，因此对应的预设周期可以不相同，具体的设置方式可以根据实际的业务需求进行设置，本申请对此不做限制。

此外，需要说明的是，在实际应用中，第一喂狗信息可以是系统服务进程主动发送给系统服务看门狗的，也可以是系统服务看门狗主动从系统服务进程获取的，本实施例对此不做限制。

相应的，第二喂狗信息可以是系统服务看门狗主动发送给卡死检测看门狗的，也可以是卡死检测看门狗主动从系统服务看门狗获取的，本实施例对此不做限制。

相应的，第三喂狗信息可以是内核系统主动发送给卡死检测看门狗的，也可以是卡死检测看门狗主动从内核系统获取的，本实施例对此不做限制。

由此，本实施例提供的看门狗检测方法，通过将检测System Server的SystemServer WatchDog接入内核层的Hungdetect看门狗，在System Server WatchDog出现异常，无法通过复位将检测的业务进程恢复正常时，由内核层的Hungdetect看门狗执行复位操作，从而基于上述分层分级恢复的原理，使得出现异常的业务进程能够恢复正常，进而保证电子设备的正常使用。

为了更好的理解Hungdetect看门狗对System Server WatchDog进行检测的实现方案，以下结合图5进行具体说明。

图5为示例性示出的一种应用场景示意图。如图5所示，在电子设备的应用程序框架层中包括System Server WatchDog，用于检测应用程序框架层中的System Server进程，例如检测System Server进程是否发生了死锁，无响应等问题。

其中，System Server进程周期性地检测运行于其进程中的关键服务是否运行正常，关键服务例如可以是AMS、WMS等。当运行于System Server进程中的各关键服务均正常运行时，System Server进程定时对System Server WatchDog进行第一喂狗操作，即SystemServer进程定时向System Server WatchDog发送上述所说的第一喂狗信息，或者SystemServer WatchDog定时从System Server进程获取第一喂狗信息。当运行于System Server进程中的任一关键服务无法正常运行时，System Server进程停止对System ServerWatchDog的第一喂狗操作。

System Server WatchDog如果在一个检测周期内或者连续多个(如3个)检测周期内没有接收到System Server进程的第一喂狗操作，则对System Server进程进行重启操作。

如图5所示，在电子设备的内核层中包括Hungdetect看门狗，用于检测内核系统是否正常运行。

其中，当内核系统正常运行时，内核系统定时对Hungdetect看门狗进行第二喂狗操作，即内核系统定时向Hungdetect看门狗发送上述所说的第三喂狗信息，或者Hungdetect看门狗定时从内核系统获取第三喂狗信息。当内核系统无法正常运行时，内核系统停止对Hungdetect看门狗的第二喂狗操作。

Hungdetect看门狗如果在一个检测周期内或者连续多个(如3个)检测周期内没有接收到内核系统的第二喂狗操作，则对重启内核系统。

继续参照图5，Hungdetect看门狗除了可以检测内核系统，还可以检测SystemServer WatchDog，并在System Server WatchDog异常时重启内核系统，以在内核重启成功后重新加载System Server进程，使得System Server进程恢复正常。其中，System ServerWatchDog异常可以指的是System Server WatchDog失效，也可以是System ServerWatchDog无法成功重启System Server进程。

其中，当System Server WatchDog正常运行且其检测的System Server进程正常运行时，System Server WatchDog定时对Hungdetect看门狗进行第三喂狗操作，即SystemServer WatchDog定时向Hungdetect看门狗发送上述所说的第二喂狗信息，或者Hungdetect看门狗定时从System Server WatchDog获取第二喂狗信息。当System ServerWatchDog无法正常运行，或者无法成功重启System Server进程时，System ServerWatchDog停止对Hungdetect看门狗的第三喂狗操作。

Hungdetect看门狗如果在一个检测周期内或者连续多个(如3个)检测周期内没有接收到System Server WatchDog的第三喂狗操作，则重启内核系统。进而，在内核重启成功后，System Server进程会被重新加载启动以恢复正常。

其中，Hungdetect看门狗对System Server WatchDog的检测周期长于SystemServer WatchDog对System Server进程的检测周期。可选的，Hungdetect看门狗对SystemServer WatchDog的检测周期是System Server WatchDog对System Server进程的检测周期的整数倍。例如，System Server WatchDog对System Server进程的检测周期为30秒，Hungdetect看门狗对System Server WatchDog的检测周期为60秒。

这样，通过在内核层与应用程序框架层之间设置检测机制，实现了对电子设备的分层分级恢复。由于内核重启的颗粒度要大于System Server进程重启的颗粒度，进而在System Server进程无法重启成功时，通过内核重启能够极大地提高恢复System Server进程的成功率，进而也能够避免电子设备应用程序框架层反复重启System Server进程却无法成功的问题。

在一种电子设备重启的应用场景中，可能会出现内核系统启动成功，但SystemServer进程启动不成功的情况。此时，内核层中的Hungdetect看门狗依旧会对SystemServer WatchDog进行检测。由于System Server进程启动不成功，则System ServerWatchDog无法执行对Hungdetect看门狗的喂狗操作，进而Hungdetect看门狗会认为SystemServer WatchDog异常，并再次重启内核系统，进而可能导致内核系统多次重启的问题。

为了解决此问题，本实施例对内核层中的Hungdetect看门狗的启动时间进行调整。其中，在System Server成功启动后，Hungdetect看门狗对System Server WatchDog的检测功能才会启动，而非是在内核系统启动后就会启动。

图6为示例性示出的一种看门狗检测方法的流程示意图。如图6所示，该门狗检测方法的流程，具体包括：

步骤11,在系统服务进程初始化的过程中，System Server WatchDog启动。

步骤12,Hungdetect看门狗启动对System Server WatchDog的检测功能。

步骤13,Hungdetect看门狗在System Server WatchDog异常时，重启内核系统。

当电子设备初始化重启时，System Server会被杀死(kill)，System ServerWatchDog也会关闭喂狗功能，此时System Server WatchDog不会再对内核层中的Hungdetect看门狗进行喂狗操作。直到System Server重启成功时，System ServerWatchDog才会对继续对Hungdetect看门狗进行喂狗操作。

在电子设备初始化的流程中，内核系统先启动，应用框架层中的进程才会启动。当内核系统进行初始化时，内核层中的Hungdetect看门狗启动，但其对System ServerWatchDog的检测功能不启动。当应用框架层中System Server初始化时，再指示内核层中的Hungdetect看门狗启动其对System Server WatchDog的检测功能。

示例性的，当System Server执行初始化操作时，向内核层中的Hungdetect看门狗发送指示信息，其中，该指示信息用于指示System Server已初始化，或者用于指示Hungdetect看门狗启动对System Server WatchDog的检测功能。进而，内核系统基于该指示信息，启动其对System Server WatchDog的检测功能，以实现对System ServerWatchDog的检测。

这样，由于Hungdetect看门狗对System Server WatchDog的检测功能是在SystemServer启动后才启动的，至少是成功启动一次后才启动的，因此可以避免Hungdetect看门狗在System Server启动前就对System Server WatchDog进行检测的问题，进而不出现Hungdetect看门狗在System Server启动前误认为System Server WatchDog异常而重启内核系统的现象。

场景二

在本场景中，电子设备的应用程序框架层与内核层之间设置检测机制，以内核层中Hungdetect看门狗对应用程序框架层中Xcollie(系统关键任务超时检测看门狗)进行检测为例，对本申请提供的看门狗检测方法进行解释说明。

图7为示例性示出的Xcollie执行看门狗检测方法的流程示意图。如图7所示，Xcollie执行看门狗检测方法的流程，具体包括：

步骤201，初始化系统关键任务超时检测看门狗，将标识关键进程的状态信息设置为正常标记。

具体的说，本实施例中所说的关键进程例如可以是上文提及的Vold、SurfaceFlinger、AudioFlinger、Face Regconize等，此次不再一一列举，本申请对此不做限制。

此外，需要说明的是，关于初始化系统关键任务超时检测看门狗的时机，在一些实现方式中，可以是在启动关键进程的过程中初始化，由此可以保证关键检测看门狗能够在关键进程执行的动作对应的函数被调用时，关键检测看门狗便可以及时开始检测。

此外，通过上述描述可知，系统关键任务超时检测看门狗是关键进程中的一个常驻线程，用于检测所在关键检测执行的动作(action)是否完成，以SurfaceFlinger为例，则系统关键任务超时检测看门狗检测的action例如可以是渲染系统UI的动作是否完成。因此，在另一些实现方式中，系统关键任务超时检测看门狗也可以是在启动关键进程，调用关键进程执行的动作对应的函数时初始化的，这样便可以根据业务需求确定哪些动作需要由系统关键任务超时检测看门狗进行检测，更好的适应多种应用场景。

也就是说，是否初始化系统关键任务超时检测看门狗，由系统关键任务超时检测看门狗检测action是否执行完成，可以根据实际的业务需求确定。

此外，关于上述所说的在系统关键任务超时检测看门狗初始化成功后，将标识关键进程的状态信息设置为正常标记，例如可以是设置成“OK”。相应的，对于下文提到的异常标记，例如可以用“ERROR”表示。

此外，在一些实现方式中，也可以根据需要，约定用“1”作为正常标记，用“0”作为异常标记。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。在实际应用中，正常标记和异常标记可以根据需要约定，本申请对此不做限制。

步骤202，系统关键任务超时检测看门狗在检测到关键进程执行的动作调用开始节点后，记录关键进程执行动作的执行时长。

可理解的，在实际应用中，关键进程执行的action具体是由实现该action的功能函数(或者说程序代码，后续统称为函数)实现的，而在该函数中会由标识动作开始的开始节点(begin标识位)和标识动作结束的结束节点(end标识位)。

示例性的，系统关键任务超时检测看门狗可以根据begin标识位的调用，获知action的开始时间，根据end标识位的调用，获知action的结束时间。

此外，对于每一个action的超时时长可以根据业务特色，以及action正常的执行完毕所需的时间合理设置。

例如，对于完成时间为5ms(从调用开始节点到调用结束节点的时间)的action，超时时长可以为5ms，或者8ms，或者n*5ms。示例性的，n例如为大于0的整数。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

步骤203，在执行时长到达动作对应的超时时间时，系统关键任务超时检测看门狗查询动作的结束节点是否被调用。

具体的说，在执行时长到达动作对应的超时时间，但结束节点未被调用，即出现timeout时，执行步骤204；否则，执行步骤206。

步骤204，系统关键任务超时检测看门狗将标识关键进程的状态信息由正常标记修改为异常标记。

具体的说，在出现timeout时，标明关键进程执行的action没有被完成，这种情况可能是因为关键进程出现了异常。因此，为了使得系统关键任务超时检测看门狗或检测关键进程看门的卡死检测看门狗执行复位操作，以使关键进程恢复正常，需要将标识关键进程的状态信息由正常标记修改为异常标记，如将“OK”修改为“ERROR”。这样，在关键进程执行复位操作，下次初始化成功后，便可以将“ERROR”重新修改为“OK”，系统关键任务超时检测看门狗就可以继续检测需要检测的action。

步骤205，系统关键任务超时检测看门狗将异常标记发送至内核层中的卡死检测看门狗，由卡死检测看门狗执行复位操作。

可理解的，由于应用程序框架层是位于内核层之上的，因此位于应用程序框架中的系统关键任务超时检测看门狗执行复位操作时比位于内核层的卡死检测看门狗执行复位操作时对电子设备的影响小。因此，在一些实现方式中，在执行步骤205之前，系统关键任务超时检测看门狗可以先执行复位操作。

示例性的，如果关键检测看门狗复位成功，即将使关键进程恢复正常，则将关键进程的状态信息由异常标记修改为正常标记，并将正常标记发送至内核层中的卡死检测看门狗，这样卡死检测看门狗在预设周期(喂狗周期)到达时，便不会进行狗叫，甚至狗咬(即执行对内核系统的复位操作)。

示例性的，如果关键检测看门狗没有复位成功，例如没有将关键进程恢复正常，或者系统关键任务超时检测看门狗失效导致无法对关键进程进行复位，这种情况下才执行步骤205，即借助下层的卡死检测看门狗进行复位。

此外，需要理解的是，在实际应用中，位于下层的卡死检测看门狗进行业务恢复或重启的颗粒度要大于位于上层的系统关键任务超时检测看门狗进行业务恢复或重启的颗粒度，而卡死检测看门狗执行复位操作对电子设备的影响要大于系统关键任务超时检测看门狗执行复位操作对电子设备的影响，因此触发卡死检测看门狗执行复位的周期通常会大于触发系统关键任务超时检测看门狗执行复位的周期。

基于此，为了更好的理解本实施例中的看门狗检测方案中，何时由系统关键任务超时检测看门狗中复位操作，何时由卡死检测看门狗执行复位操作，以下给出两种具体的实现方式。

方式1：

示例性的，系统关键任务超时检测看门狗检测关键进程的状态信息处于异常标记的异常时长。

相应的，在异常时长小于时长阈值时，系统关键任务超时检测看门狗重新执行复位操作；在异常时长不小于时长阈值时，执行上述步骤205。

可理解的，关于上述所说的时长阈值，在一些实现方式中可以时根据出现timeout的action的超时时长，以及卡死检测看门狗的检测周期(也可以理解为喂狗周期)和应用程序框架层与内核层之间的时延确定。

方式2：

示例性的，与方式1类似，系统关键任务超时检测看门狗依旧可以检测关键进程的状态信息处于异常标记的异常时长。不同之处在于，该方式中是通过判断超时次数来确定是由系统关键任务超时检测看门狗继续执行复位操作，还是由卡死检测看门狗执行复位操作。故而，在得到异常时长后，系统关键任务超时检测看门狗可以根据异常时长和超时时长来确定超时次数。

相应的，在超时次数小于次数阈值时，系统关键任务超时检测看门狗重新执行复位操作；在异常时长不小于次数阈值时，则执行步骤205。

关于超时次数的设置，与时长阈值的设置类似，可以根据业务需求结合实际情况进行设置，本申请对此不做限制。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

此外，需要说明的是，在实际应用，应用程序框架层中除了会有系统关键任务超时检测看门狗，还会有系统服务看门狗，初始化看门狗等用于检测不同业务进程的看门狗。因此，为了使得位于下层的卡死检测看门狗能够实现对上层的不同看门狗的检测，可以在内核层中设置预先封装的用于决策是否由卡死检测看门狗执行复位操作的公共节点。

相应的，系统关键任务超时检测看门狗发送给卡死检测看门狗的异常标记，在这种设置了公共节点的实现方案中，具体是将异常标记发送至内核层中公共节点。

示例性的，公共节点中预先置入了预设策略，即决策是否由卡死检测看门狗执行复位操作的策略。故而，公共节点在接收到上层的看门狗，例如本实施例中所说的系统关键任务超时检测看门狗发送的异常标记后，会根据异常标记和预设策略，确定是否需要由卡死检测看门狗执行复位操作。

相应的，公共节点通过处理，在确定需要由卡死检测看门狗执行复位操作时，通知卡死检测看门狗执行复位操作。

示例性的，在一些实现方式中，公共节点在确定需要由卡死检测看门狗执行复位操作时，可以主动向卡死检测看门狗发送复位指令，也可以由卡死检测看门狗定期从公共节点获取公共节点决策出的指令信息，进而在获取到复位指令时，执行复位操作。

此外，需要说明的是，为了使得本实施例提供的技术方案能够适用于更多的应用场景，满足不同的业务需求，在实际应用中，可以根据业务需求标识哪些action的执行过程出现异常时，可以借助下层的卡死检测看门狗进行复位。

示例性的，上述操作例如可以在启动关键进程，调用关键进程执行的动作对应的函数时，初始化系统关键任务超时检测看门狗时，为关键进程执行的动作对应的函数设置分层恢复标记。这样，在关键进程的状态信息为异常状态，且其执行的action设置由分层恢复标记时，系统关键任务超时检测看门狗便会通知卡死检测看门狗执行复位操作。

需要说明的是，关于上述所说的分层恢复标记，在实际应用中可以根据需要设置，此次不做限制。

示例性的，在一些实现方式中，系统关键任务超时检测看门狗可以只将设置了分层恢复标记的action对应的关键进程的异常标记发送给卡死检测看门狗，这样对于卡死检测看门狗在接收到异常标记，或者说公共节点接收到异常标记后，不需要考虑该异常标记对应的关键进程是否设置了分层恢复标记，默认接收到的都设置了分层恢复标记，即都卡死检测看门狗介入。

示例性的，在另一些实现方式中，系统关键任务超时检测看门狗可以不区分关键进程是否设置了分层恢复标记，在检测到标识关键进程的状态信息发生变化时，直接将标识关键进程的状态信息以及为该关键进程设置的其他标记信息，例如分层恢复标记发送给下层的公共节点或卡死检测看门狗，由下层的公共节点或卡死检测看门狗来识别是否需要介入。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

步骤206，停止对关键进程执行的动作的检测。

可理解的，在实际应用中，关键进程状态的变化如表1所示。

表1关键进程状态变化表

场景	状态
		初始化(init)	正常
执行结束(end)	正常
		执行超时(Timeout)	异常

也就是说，在超时时长内，如果结束节点被调用，说明本次执行的action正常结束，这种情况下，系统关键任务超时检测看门狗无需做处理，即不需要做复位操作，因此在本次执行的action正常结束后，系统关键任务超时检测看门狗便可以停止对关键进程执行的该action的检测，从而节省对电子设备系统资源的占用。

此外，需要说明的是，在基于上述分层分级恢复方案所适用于的系统架构实现本实施例提供的看门狗检测方法时，在结束节点被调用时，同样可以向下层，即内核层的卡死检测看门狗发送标识关键进程的状态信息。对于这种情况，系统关键任务超时检测看门狗下发给卡死检测看门狗的状态信息，具体为标识关键进程处于正常状态的正常标记，例如“OK”。

此外，在一些实现方式中，在结束对该action的检测时，系统关键任务超时检测看门狗发送给卡死检测看门狗的信息还可以是标识该action正常结束的状态信息，这样，后续卡死检测看门狗在预设周期(喂狗周期)内没有接收到关于关键进程执行该action的状态信息时，也不会认为关键进程发生异常，或者认为系统关键任务超时检测看门狗失效，进而不会执行复位操作。

由此，本实施例提供的看门狗检测方法，通过将检测关键进程的Xcollie接入内核层的Hungdetect看门狗，在Xcollie出现异常，无法通过复位将检测的业务进程恢复正常时，由内核层的Hungdetect看门狗执行复位操作，从而基于上述分层分级恢复的原理，使得出现异常的业务进程能够恢复正常，进而保证电子设备的正常使用。

为了更好的理解Hungdetect看门狗对Xcollie进行检测的实现方案，以下结合图8进行具体说明。

图8为示例性示出的一种应用场景示意图。如图8所示，在电子设备的应用程序框架层中包括Xcollie，用于检测关键进程SurfaceFlinger执行的action是否完成，例如检测渲染系统的UI操作是否完成。

可理解的，SurfaceFlinger，是在System Server进程中启动的，并且负责统一管理设备的帧缓冲区。SurfaceFlinger在启动的过程中会创建两个线程，其中一个线程用来检测控制台事件(后续称为线程A)，而另外一个线程(后续称为线程B)用来渲染系统的UI。具体的，SurfaceFlinger可以用于对显示子系统进行管理，并且为多个应用程序提供2D和3D图层的融合。

关Xcollie，用于检测关键进程中执行的动作是否完成。其中，Xcollie可以设置两个线程，一个线程(后续称为线程C)用于在关键线程执行动作开始时将关键进程的状态标记设置为正常，并根据关键进程执行动作是否超时确定是否将关键进程的状态标记设置为异常，一个线程(后续称为线程D)用于轮询各个关键进程的状态，并在关键进程的状态标记为异常时复位该关键进程。

基于Xcollie和SurfaceFlinger的特性，继续参见图8，Xcollie从SurfaceFlinger获取的第一状态标记，具体是由Xcollie中线程D获取的。

示例性的，在一些实现方式中，第一状态标记可以是由线程D主动根据SurfaceFlinger中线程A检测的控制台事件和/或线程B渲染的进度信息确定的。

示例性的，在另一些实现方式中，确定第一状态标记的信息可以是由SurfaceFlinger中线程A和线程B主动发送给Xcollie，然后由Xcollie中的线程D根据接收到的信息确定第一状态标记。

继续参见图8，当SurfaceFlinger执行的action被正常执行时，Xcollie获取到的第一状态标记为正常标记，例如“OK”，当SurfaceFlinger执行的action出现timeout时，，Xcollie获取到的第一状态标记为异常标记，例如“ERROR”。

也就是说，SurfaceFlinger给到Xcollie的信息，实质是标识其状态的。Xcollie是否执行复位操作，或者是否通知内核层的Hungdetect看门狗执行复位操作，是根据标识其状态的第一状态标记确定的。

示例性的，在一些实现方式中，Xcollie如果在一个检测周期内或者连续多个(如3个)检测周期内获取到的第一状态标记均为异常标记，则对SurfaceFlinger进程进行重启操作，即由Xcollie执行复位操作。

继续参见图8，在电子设备的内核层中包括Hungdetect看门狗，用于检测内核系统是否正常运行。

其中，当内核系统正常运行时，内核系统定时对Hungdetect看门狗进行喂狗操作。当内核系统无法正常运行时，内核系统停止对Hungdetect看门狗的喂狗操作。

示例性的，Hungdetect看门狗如果在一个检测周期内或者连续多个(如3个)检测周期内没有接收到内核系统的喂狗操作，则重启内核系统，即执行复位操作。

继续参照图8，Hungdetect看门狗除了可以检测内核系统，还可以检测Xcollie，并在Xcollie异常时重启内核系统，以在内核重启成功后重新加载SurfaceFlinger进程，使得SurfaceFlinger进程恢复正常。其中，Xcollie异常可以指的是Xcollie失效，也可以是Xcollie无法成功重启SurfaceFlinger进程。

其中，当Xcollie正常运行且其检测的SurfaceFlinger进程正常运行时，Xcollie可以主动向Hungdetect看门狗发送第二状态标记，也可以由Hungdetect看门狗主动从Xcollie获取第二状态标记。

可理解的，在一些实现方式中，不论是Xcollie主动向Hungdetect看门狗发送第二状态标记，还是由Hungdetect看门狗主动从Xcollie获取第二状态标记，均可以按照预设周期进行，即定时发送或定时获取。

需要说明的，在实际应用中，第二状态标记可以与第一状态标记相同，也可以不同。

示例性的，在第一状态标记为正常标记时，如果Xcollie正常(有效)则第二状态标记与第一状态标记相同，也为正常标记。

示例性的，在第一状态标记为正常标记时，如果Xcollie异常常(失效)则第二状态标记与第一状态标记不相同，具体为异常标记。

示例性的，在第一状态标记为异常标记时，不论Xcollie是否正常，第二状态标记均与第一状态标记相同，为异常标记。

也就是说，对于Xcollie接入Hungdetect的场景，不论Xcollie能否正常运行，或者能否重启SurfaceFlinger进程，Hungdetect看门狗均可以获取到第二状态标记。

此外，需要说明的是，在另一些实现方式中，第二状态标记可以是Hungdetect看门狗对与Xcollie之间进行通信的通道的检测，或者是Xcollie发送信息的检测。

具体的，如果Hungdetect看门狗没有查询到Xcollie提供的任何信息，也无法检测到Xcollie当前的状态，则可以生成异常的第二状态标记。

示例性的，Hungdetect看门狗如果在一个检测周期内或者连续多个(如3个)检测周期内没有获取到标识SurfaceFlinger进程恢复正常的第二状态标记，或者没有获取到标识Xcollie停止检测SurfaceFlinger执行的action的信息，则重启内核系统。进而，在内核重启成功后，SurfaceFlinger进程会被重新加载启动以恢复正常。

此外，可理解的，为了保证该方案的实现，Hungdetect看门狗对Xcollie的检测周期长于Xcollie对SurfaceFlinger进程的检测周期。

可选的，Hungdetect看门狗对Xcollie的检测周期是Xcollie对SurfaceFlinger进程的检测周期的整数倍。例如，Xcollie对SurfaceFlinger进程的检测周期为30秒，Hungdetect看门狗对Xcollie的检测周期为60秒。

这样，通过在内核层与应用程序框架层之间设置检测机制，实现了对电子设备的分层分级恢复。由于内核重启的颗粒度要大于SurfaceFlinger进程重启的颗粒度，进而在SurfaceFlinger进程无法重启成功时，通过内核重启能够极大地提高恢复SurfaceFlinger进程的成功率，进而也能够避免电子设备应用程序框架层反复重启SurfaceFlinger进程却无法成功的问题。

场景三

在本场景中，电子设备的应用程序框架层与内核层之间设置检测机制，其中，内核层中Hungdetect看门狗可以同时对应用程序框架层中多个软件看门狗进行检测。

参见图9，图9为示例性示出的通过借助内核层中预先封装的公共节点，将应用程序框架层中的多个软件看门狗接入Hungdetect看门狗，实现Hungdetect看门狗可以同时对应用程序框架层中多个软件看门狗进行检测的流程示意图。

如图9所示，本实施例提供的看门狗检测方法应用内核层中预先封装好的公共节点，具体包括：

步骤301，公共节点接收应用程序框架层中各软件看门狗提供的信息。

示例性，上述所说的各软件看门狗，例如可以是System Server WatchDog、Xcollie、Init看门狗等，此次不再一一列举，本申请对此不做限制。

相应的，关于上述所说的各软件看门狗提供的信息，具体到实际应用中与软件看门狗的特性有关。

例如，对于System Server WatchDog，提供的信息可以为上述场景一中所说的第二喂狗信息。

可理解的，在System Server WatchDog提供的信息是第二喂狗信息时，表明System Server WatchDog有效，其检测的System Server进程也正常。

相应的，在一些实现场景中，System Server WatchDog提供的信息也可能不是第二喂狗信息，例如在System Server WatchDog失效或其检测的System Server进程异常时，System Server WatchDog会停止提供第二喂狗信息。这种情况下，System ServerWatchDog可以不再提供信息，也可以将提供的信息设置是“null”，或者为了便于告知下层的公共节点当前已经处于异常，可以提供约定的异常信息。

对于Xcollie提供的信息则可以是上述场景二中所说的第二状态标记。根据场景二的描述可知，在需要借助卡死检测看门狗(Hungdetect看门狗)执行复位操作时，第二状态标记为异常标记，在Xcollie和对应的关键进程状态正常时，提供的第二状态标记为正常标记。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

步骤302，公共节点根据各软件看门狗对应的业务进程，确定各软件看门狗提供的信息的优先级。

示例性的，以Android系统为例，大部分关键进程都是在System Server进程中注册启动的，因此System Server进程正常是保证其他关键进程正常的前提，因此在一些实现方式中，可以将System Server进程相关的信息确定为第一优先级，将运行在SystemServer进程中的其他关键进程的提供的信息确定为第二优先级，即第一优先级高于第二优先级。

基于此，对于信息是由System Server WatchDog提供的，则优先级确定为第一优先级，对于信息是由Xcollie提供的，则优先级确定为第二优先级。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。在实际应用中，还可以根据其他业务需求合理设置不同业务进程的优先级，以更好适应于各种应用场景。

步骤303，公共节点根据预设决策和确定的各软件看门狗提供的信息的优先级，确定是否执行复位操作。

示例性的，在一些实现方式中，预设决策可以规定，在第一优先级的信息是上述所说的第二喂狗信息时，即表明System Server进程是正常的，此时不论其他软件看门狗提供的信息是什么内容，当前均不需要卡死检测看门狗介入执行复位操作。

示例性的，在另一些实现方式中，预设决策可以规定，在第一优先级的信息是上述所说的第二喂狗信息，在其他软件看门狗(比如N个)提供的信息有n个为异常信息的情况下，确定当前需要卡死检测看门狗介入执行复位操作。

示例性的，n为大于1的整数，N为大于n的整数。

例如，公共节点在一个检测周期内，一共接收到5个软件看门狗的信息，其中一个为System Server WatchDog提供的，4个(即上述所说的N)为其他软件看门狗提供的(2个提供的信息是正常信息，2个是异常信息)，如果规定n≥2时，要卡死检测看门狗介入执行复位操作，则在这种情况下，公共节点作出的决策信息即为复位指令。

示例性的，在另一些实现方式中，预设决策可以规定，在第一优先级的信息是上述所说的第二喂狗信息，在提供第二优先级的信息的软件看门狗为指定的软件看门狗，例如设置了复位标记时，确定当前需要卡死检测看门狗介入执行复位操作。

进一步地，在上述基础上，还可以考虑上层的每个软件看门狗失效，或者说其检测的业务进程异常是时间，如果在连续多个周期(如3个)都没有恢复正常，则公共节点确定当前需要卡死检测看门狗介入执行复位操作。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。在实际应用中，还可以根据其他业务需求合理设置不同预设策略，以更好适应于各种应用场景。

相应的，基于上述预设策略和确定的各软件看门狗提供的信息的优先级，如果确定需要执行复位操作，则执行步骤304；否则，执行步骤305。

步骤304，公共节点提供复位指令，触发卡死检测看门狗执行复位操作。

关于卡死检测看门狗执行复位操作的描述，详见上述场景一和场景二的部分，此次不再赘述。

步骤305，公共节点提供约定的喂狗信息给卡死检测看门狗。

可理解的，公共节点提供约定的喂狗信息例如可以时“kick”标记，或者“OK”标记等，以使卡死检测卡门狗获知上层的软件看门狗和其检测的业务进程正常，当前不需要其介入重启内核系统。

由此，本实施例提供的看门狗检测方法，预先封装能够决策在上层的软件看门狗无法成功复位出现异常的业务进程时，是否由下层的软件看门狗执行复位的公共节点，由公共节点统一对接收上层不同软件看门狗发送的标识上层的软件看门狗检测的业务进程/业务进程执行的动作的状态标记，通过根据预设策略对状态标记进行分析决策，在确定需要由卡死检测看门狗执行复位时才通知卡死检测看门狗执行复位，使得本申请中的分层分级的恢复方案更加合理。

此外，公共节点根据业务需求，可以根据来自上层不同软件看门狗的喂狗信息、状态标记决策出一个处理结果，从而在不影响用户使用电子设备的情况下，尽可能减少卡死检测看门狗对内核系统的重启操作，降低了资源开销。

为了更好的理解应用程序框架层中的多个软件看门狗接入Hungdetect看门狗的实现方案，下述以内核层中Hungdetect看门狗同时对应用程序框架层中System ServerWatchDog和Xcollie进行检测为例，对本申请提供的看门狗检测方法进行解释说明。

参见图10，图10为示例性示出的一种应用场景示意图。

如图10所示，在电子设备的应用程序框架层中包括System Server WatchDog、System Server WatchDog检测的System Server进程、Xcollie，以及与Xcollie对应的关键进程，如SurfaceFlinger；在电子设备的内核层中包括Hungdetect看门狗，用于检测内核系统是否正常运行，以及分别与应用程序框架层的System Server WatchDog、Xcollie和内核层的Hungdetect看门狗进行通信的公共节点。

关于System Server WatchDog检测System Server进程，System Server进程对System Server WatchDog进行第一喂狗操作，何时重启System Server进程，以及SystemServer WatchDog何时执行第二喂狗操作(场景一中的第二喂狗信息)，详见场景一中的描述，此次不再赘述。

关于Xcollie检测SurfaceFlinger中的action，Xcollie如何获取SurfaceFlinger的第一状态标记，何时重启SurfaceFlinger，以及Xcollie何时提供第二状态标记，详见场景二中的描述，此次不再赘述。

关于Hungdetect看门狗如何检测内核系统，内核系统对Hungdetect看门狗进行第三喂狗操作，何时重启内核系统，详见场景一或场景二中关于Hungdetect看门狗对本层的内核系统进行检测的描述，此次不再赘述。

以下结合图10着重描述将第二喂狗操作与第二状态标记写入内核层的公共节点，由公共节点决策是否由卡死检测看门狗执行复位操作，而非直接给到Hungdetect看门狗。

示例性的，在具体实现时，公共节点中可以根据业务需求预先置入预设策略，即决策是否由卡死检测看门狗执行复位操作的策略。

故而，公共节点会根据预置的预设策略，以及得到的喂狗信息和状态标记来决策当前是否需要由Hungdetect看门狗执行复位操作。

关于上述所说的得到的喂狗信息，在一些实现场景下，可能得到的是描述SystemServer WatchDog正常的信息，对于这种情况，表明其检测的System Server进程也正常，此时System Server WatchDog对Hungdetect看门狗的喂狗正常。

相应的，在另一些实现场景下，也可能得到是描述System Server WatchDog失效，或者System Server WatchDog正常但是其检测的System Server进程异常的信息，SystemServer WatchDog停止向Hungdetect看门狗提供喂狗信息，即无法执行第二喂狗操作，也可以理解为System Server WatchDog对Hungdetect看门狗的喂狗异常。

关于上述所说的状态标记，在一些实现场景中，可能是正常标记，即Xcollie和SurfaceFlinger均正常。在另一些实现场景中，可能是异常标记，即Xcollie和SurfaceFlinger至少有一个是异常。

相应的，公共节点通过处理，会得到决策信息。

示例性的，在一些实现方式中，公共节点处理得到的决策信息，可以主动推送给Hungdetect看门狗，也可以由Hungdetect看门狗主动从公共节点获取。

以决策信息是需要Hungdetect看门狗执行复位操作为例，则一种场景下，公共节点在确定需要由Hungdetect看门狗执行复位操作时，会主动通知Hungdetect看门狗执行复位操作。在另一种场景下，公共节点在确定需要由Hungdetect看门狗执行复位操作时，可以先将决策信息进行保存，等待Hungdetect看门狗定期从公共节点获取公共节点决策出的决策信息，进而在获取到复位指令时，执行复位操作。

相应的，在得到决策信息是不需要Hungdetect看门狗执行复位操作时，为可以统一向Hungdetect看门狗发送约定的喂狗信息，实现喂狗，从而避免Hungdetect看门狗触发狗叫，甚至狗咬。

又示例性的，在一些实现方式中，内核层中公共节点，用于存储应用程序框架层中软件看门狗对Hungdetect看门狗的踢狗信息，以及发送的进程状态信息。其中，踢狗信息中可以包括软件看门狗的名称以及踢狗动作(kick)，进程状态信息可以包括软件看门狗的名称以及进程状态(OK或ERROR)。Hungdetect看门狗，作为公共节点的消费者，可以定时(或周期性地)查看公共节点中存储的踢狗信息，以及发送的进程状态信息(如OK或ERROR)。

Hungdetect看门狗基于定时(或周期性地)在公共节点中获取到的踢狗信息和/或进程状态信息，以及预设策略，确定是否执行复位内核系统的操作。其中，预设策略可以是前述提及的预设决策与各软件看门狗提供的信息的优先级，在此不再赘述。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

场景四

在本场景中，电子设备的内核层与硬件层之间设置检测机制，以硬件层中硬件看门狗对内核层中Hungdetect看门狗进行检测为例，对本申请提供的看门狗检测方法进行解释说明。

图11为示例性示出的一种应用场景示意图。

如图11所示，在电子设备的内核层中包括Hungdetect看门狗，用于检测内核系统是否正常运行。

其中，当内核系统正常运行时，内核系统定时对Hungdetect看门狗进行第一喂狗操作。当运内核系统无法正常运行时，内核系统停止对Hungdetect看门狗的第一喂狗操作。Hungdetect看门狗如果在一个检测周期内或者连续多个(如3个)检测周期内没有接收到内核系统的第一喂狗操作，则重启内核系统。

如图11所示，在电子设备的硬件层中包括硬件看门狗(Hardware WatchDog)，用于对硬件芯片进行检测。

其中，当硬件芯片中程序运行正常时，硬件芯片会定时对硬件看门狗进行第二喂狗操作，如将硬件看门狗的第一计时置零，使其重新开始计时。当硬件芯片中程序运行异常时，则停止对硬件看门狗进行第二喂狗操作。

硬件看门狗在没有收到硬件芯片的第二喂狗操作时，若第一计时增加到第一设定值，则对硬件芯片进行复位，实现电子设备整机重启。此处，与第一计时对应的检测周期，即为硬件看门狗用于检测硬件芯片的检测周期。其中，硬件看门狗中的第一计时器用于实现第一计时的操作。

继续参照图11，硬件看门狗除了可以检测硬件芯片，还可以检测Hungdetect看门狗，并在Hungdetect看门狗异常时复位硬件芯片，以使电子设备整机重启，内核系统恢复。其中，Hungdetect看门狗异常可以指的是Hungdetect看门狗失效，也可以是Hungdetect看门狗无法成功重启内核系统。

其中，当Hungdetect看门狗正常运行且其检测的内核系统正常运行时，Hungdetect看门狗定时对Hungdetect看门狗进行第三喂狗操作，如将硬件看门狗的第二计时置零，使其重新开始计时。当Hungdetect看门狗无法正常运行，或者无法成功重启内核系统时，Hungdetect看门狗停止对硬件看门狗的第三喂狗操作。

作为一种可选的实施方式，Hungdetect看门狗在触发内核系统复位(或重启)前，停止对硬件看门狗的第三喂狗操作。

硬件看门狗在没有收到Hungdetect看门狗的第三喂狗操作时，若第二计时增加到第二设定值，则对硬件芯片进行复位，实现电子设备整机重启。此处，与第二计时对应的检测周期，即为硬件看门狗用于检测Hungdetect看门狗的检测周期。其中，硬件看门狗中的第二计时器用于实现第二计时的操作。

这样，通过在硬件层与内核层之间设置检测机制，实现了对电子设备的分层分级恢复。由于硬件重启的颗粒度要大于内核重启的颗粒度，进而在内核无法重启成功时，通过硬件重启能够极大地提高恢复内核系统的成功率，进而也能够避免电子设备内核层反复重启内核系统却无法成功的问题。

场景五

在本场景中，在电子设备的内核层与硬件层之间设置检测机制，以硬件层中硬件看门狗对内核层中CPU核状态看门狗进行检测为例，对本申请提供的看门狗检测方法进行解释说明。

图12为示例性示出的一种应用场景示意图。

如图12所示，在电子设备的内核层中包括CPU核状态看门狗，用于对CPU运行状态进行检查，并在CPU运行状态满足预设内核重启条件时，控制重启内核。

具体的，CPU核状态看门狗可以用于对各个CPU核的运行状态进行检测，并在各个CPU核的运行状态满足预设内核重启条件时，控制重启内核。

其中，CPU核状态看门狗定时获取CPU各个核的运行状态，并在CPU核状态满足预设内核重启条件时，控制重启内核。例如，CPU核状态看门狗每30秒获取一次CPU各个核的运行状态，并在CPU核状态满足预设内核重启条件时，控制重启内核。

作为一种可选的实施方式，CPU核状态看门狗可以基于CPU核上的任务是否可以被调度，来确定CPU核的运行状态，以此实现对CPU调度问题的检测。

其中，CPU的每个核上绑定一个目标任务，该目标任务定时运行在绑定的CPU核上，例如，该目标任务每30秒在其绑定的CPU核上运行一次。CPU核状态看门狗通过第一检测任务定时检测绑定在各个CPU核上的目标任务是否可以被调度，以此确定各个CPU核的运行状态。例如，第一检测任务每30秒查查询一次绑定在各个CPU核上的目标任务是否可以被调度。如果某个CPU核上的目标任务无法被调度，则CPU核状态看门狗即可确定该CPU核的运行状态为异常；如果某个CPU核上的目标任务可以被调度，则CPU核状态看门狗即可确定该CPU核的运行状态为正常。

如图13所示，电子设备的CPU包括8个核，分别为CPU0核、CPU1核、CPU2核、…、CPU7核。其中，每个CPU核上绑定一个目标任务，如CPU0核绑定目标任务Tast 0，CPU1核绑定目标任务Tast 1，CPU2核绑定目标任务Tast 2，…，CPU7核绑定目标任务Tast 7。每个目标任务定时运行在其绑定的CPU核上，如目标任务Tast 0定时运行在CPU0核上，目标任务Tast 1定时运行在CPU1核上，目标任务Tast 2定时运行在CPU2核上，…，目标任务Tast 7定时运行在CPU7核上。

CPU核状态看门狗通过第一检测任务定时检测各个目标任务(Tast 0-Tast 7)是否可以在其绑定的CPU核上被调度，以此确定各个CPU核的运行状态。其中，第一检测任务可以运行在任意一个CPU核上。例如，若Tast 0无法在其绑定的CPU0核上被调度，则CPU核状态看门狗可以确定CPU0核的运行状态为异常。例如，若Tast 7可以在其绑定的CPU0核上被调度，则CPU核状态看门狗可以确定CPU7核的运行状态为正常。如此，CPU核状态看门狗可以确定各个CPU核的运行状态。

示例性的，可以使用“1”和“0”标识CPU核的运行状态。例如，当CPU核的运行状态为“1”时，CPU核运行正常；当CPU核的运行状态为“0”时，CPU核运行异常。进而，第一检测任务定时检测各个目标任务是否可以在其绑定的CPU核上被调度，并根据检测结果生成与各CPU核对应的运行状态标识，进而CPU核状态看门狗可以根据第一检测任务生成的运行状态标识，确定各CPU核的运行状态是否异常。其中，运行状态标识中的位数与CPU核的数量相同。例如，CPU包括8个核，分别为CPU0核、CPU1核、CPU2核、…、CPU7核，则运行状态标识可以包括8个位，8个位的值依次分别标识各个CPU核的运行状态。假设，第一检测任务生成的运行状态标识为“111111101”，则CPU核状态看门狗可以根据该运行状态标识确定CPU6核的运行状态为异常，其余CPU核的运行状态为正常。

作为另一种可选的实施方式，CPU核状态看门狗可以基于探测消息确定CPU核的运行状态。

其中，CPU核状态看门狗可以通过第二检测任务定时基于探测消息确定CPU核的运行状态。例如，CPU核状态看门狗可以通过第二检测任务每30秒基于探测消息确定一次CPU核的运行状态。

示例性的，CPU核状态看门狗可以通过第二检测任务向物理状态为在线(online)的CPU核发送探测消息后，如果接收到CPU核针对该探测消息发送的探测反馈消息，则确定该CPU核的运行状态为正常，否则确定该CPU核的运行状态为异常。需要指出的是，CPU核状态看门狗可以不对物理状态为离线(offline)的CPU核的运行状态进行探测。

可选的，探测消息可以是ping消息。其中，CPU核状态看门狗可以通过第二检测任务以中断(Interrupt)的形式向CPU核发送ping消息，CPU核针对该ping消息以中断的形式发送反馈消息，以此实现CPU核状态看门狗对CPU中断风暴的检测。

如图14所示，电子设备的CPU包括8个核，分别为CPU0核、CPU1核、CPU2核、…、CPU7核。CPU核状态看门狗通过第二检测任务定时依次向物理状态为online的CPU核发送ping消息，如果接收到CPU核针对该ping消息发送的反馈消息，则确定该CPU核可以正常响应，并将其运行状态确定为正常，否则该CPU核无法正常响应，并将其运行状态确定为异常。例如，CPU核状态看门狗通过第二检测任务向物理状态为online的CPU0核发送ping消息后，如果能够接收到CPU0核针对该ping消息发送的反馈消息，则确定CPU0核的运行状态确定为正常。再例如，CPU核状态看门狗通过第二检测任务向物理状态为online的CPU1核发送ping消息后，如果无法接收到CPU1核针对该ping消息发送的反馈消息，则确定CPU1核的运行状态确定为异常。如此，CPU核状态看门狗可以确定各个CPU核的运行状态。

CPU核状态看门狗在确定CPU各个核的运行状态之后，判断CPU各个核的运行状态是否满足预设内核重启条件，若是，则控制重启内核。本实施例对预设内核重启条件不做限定。

示例性的，如果运行状态为异常的CPU核的数量超过预设数量阈值，则CPU核状态看门狗确定CPU各个核的运行状态满足预设内核重启条件，并控制重启内核。

又示例性的，如果CPU目标核的运行状态为异常，则CPU核状态看门狗确定CPU各个核的运行状态满足预设内核重启条件，并控制重启内核。其中，CPU目标核为预设类型的CPU核，例如是CPU大核或者是CPU中比较重要的核。例如，若CPU0核为CPU大核，当其运行状态为异常时，CPU核状态看门狗确定CPU各个核的运行状态满足预设内核重启条件，并控制重启内核。

作为一种可选的实施方式，CPU核状态看门狗可以基于CPU核上的任务是否可以被调度确定的CPU核的第一运行状态，以及CPU核状态看门狗可以基于探测消息确定的CPU核的第二运行状态。当某个CPU核的第一运行状态和第二运行状态均指示异常时，CPU核状态看门狗确定该CPU运行异常。

作为另一种可选的实施方式，CPU核状态看门狗可以基于CPU核上的任务是否可以被调度确定的CPU核的第一运行状态，以及CPU核状态看门狗可以基于探测消息确定的CPU核的第二运行状态。当某个CPU核的第一运行状态和第二运行状态任一指示异常时，CPU核状态看门狗确定该CPU运行异常。

如图12所示，在电子设备的硬件层中包括硬件看门狗(Hardware WatchDog)，用于对硬件芯片进行检测。

其中，当硬件芯片中程序运行正常时，硬件芯片会定时对硬件看门狗进行第二喂狗操作，如将硬件看门狗的第一计时置零，使其重新开始计时。当硬件芯片中程序运行异常时，则停止对硬件看门狗进行第二喂狗操作。

硬件看门狗在没有收到硬件芯片的第二喂狗操作时，若第一计时增加到第一设定值，则对硬件芯片进行复位，实现电子设备整机重启。此处，与第一计时对应的检测周期，即为硬件看门狗用于检测硬件芯片的检测周期。其中，硬件看门狗中的第一计时器用于实现第一计时的操作。

继续参照图12，硬件看门狗除了可以检测硬件芯片，还可以检测CPU核状态看门狗，并在CPU核状态看门狗异常时复位硬件芯片，以使电子设备整机重启，内核系统恢复。其中，CPU核状态看门狗异常可以指的是CPU核状态看门狗失效，也可以是CPU核状态看门狗无法成功重启内核系统。

其中，当CPU核状态看门狗正常运行且其检测的CPU核状态不满足预设内核重启条件时，CPU核状态看门狗定时对Hungdetect看门狗进行第三喂狗操作，如将硬件看门狗的第二计时置零，使其重新开始计时。当CPU核状态看门狗无法正常运行，或者无法成功重启内核系统时，CPU核状态看门狗停止对硬件看门狗的第三喂狗操作。

作为一种可选的实施方式，CPU核状态看门狗在触发内核系统复位(或重启)前，停止对硬件看门狗的第三喂狗操作。

硬件看门狗在没有收到CPU核状态看门狗的第三喂狗操作时，若第二计时增加到第二设定值，则对硬件芯片进行复位，实现电子设备整机重启。此处，与第二计时对应的检测周期，即为硬件看门狗用于检测CPU核状态看门狗的检测周期。其中，硬件看门狗中的第二计时器用于实现第二计时的操作。

在一种实施方式中，硬件看门狗除了可以检测硬件芯片，还可以同时检测内核层中的CPU核状态看门狗与Hungdetect看门狗。此时，硬件看门狗中可以设置第二计时器和第三计时器，分别用于检测CPU核状态看门狗与Hungdetect看门狗对硬件看门狗的喂狗操作。例如，硬件看门狗在没有收到CPU核状态看门狗的喂狗操作时，若第二计时增加到第二设定值，则对硬件芯片进行复位，实现电子设备整机重启。硬件看门狗在没有收到Hungdetect看门狗的喂狗操作时，若第三计时增加到第三设定值，则对硬件芯片进行复位，实现电子设备整机重启。此处，与第二计时对应的检测周期，即为硬件看门狗用于检测CPU核状态看门狗的检测周期；与第三计时对应的检测周期，即为硬件看门狗用于检测Hungdetect看门狗的检测周期。关于第一设定值、第二设定值与第三设定值的大小，本实施例不做限定。

若硬件看门狗还可以同时检测内核层中的其它看门狗，处理方式可以参见上述硬件看门狗对hungdetect看门狗或CPU核状态看门狗的检测，在此不再赘述。

这样，通过在硬件层与内核层之间设置检测机制，实现了对电子设备的分层分级恢复。由于硬件重启的颗粒度要大于内核重启的颗粒度，进而在内核无法重启成功时，通过硬件重启能够极大地提高恢复内核系统的成功率，进而也能够避免电子设备内核层反复重启内核系统却无法成功的问题。

场景六

在本场景中，电子设备的应用程序框架层与内核层之间、内核层与硬件层之间均设置检测机制，且内核层中Hungdetect看门狗可以同时对应用程序框架层中多个软件看门狗进行检测。

图15为示例性示出的一种应用场景示意图。

如图15所示，在电子设备的应用程序框架层中包括System Server WatchDog、Xcollie和Init看门狗。其中，System Server WatchDog，用于检测应用程序框架层中的System Server进程，例如检测System Server进程是否发生了死锁，无响应等问题。Xcollie，用于检测关键进程SurfaceFlinger执行的action是否完成，例如检测渲染系统的UI操作是否完成。Init看门狗，用于对Init流程进行检测，例如检测电子设备关机、开机流程是否异常。

在电子设备的内核层中包括Hungdetect看门狗和CPU核状态看门狗。其中，Hungdetect看门狗用于检测内核系统，例如检测内核系统是否卡死。CPU核状态看门狗，用于对CPU各个核的运行状态进行检测，例如检测各个CPU核是否运行异常。

在电子设备的硬件层包括硬件看门狗。其中，图15中所示的第一硬件看门狗、第二硬件看门狗和第三硬件看门狗，可以理解为是针对不同芯片不同平台设置的处理逻辑不同的硬件看门狗。本申请实施例提供对电子设备进行分层分级恢复的技术方案，可以适配不同的硬件看门狗，如图15中所示的第一硬件看门狗、第二硬件看门狗和第三硬件看门狗。其中，针对不同的硬件看门狗的适配可以是在代码编译阶段实现的。下述以电子设备中实际使用第一看门狗为例进行解释说明。

参照图15，在本实施例中，内核层Hungdetect看门狗不仅可以检测内核系统，还可以对应用程序框架层中System Server WatchDog、Xcollie和Init看门狗等进行检测。

在本实施例中，内核层设置公共节点，用于存储应用程序框架层中软件看门狗对Hungdetect看门狗的踢狗信息，以及发送的进程状态信息。Hungdetect看门狗，作为公共节点的消费者，可以定时(或周期性地)查看公共节点中存储的踢狗信息，以及发送的进程状态信息(如OK或ERROR)。

进而，Hungdetect看门狗在周期性地获取公共节点中存储的踢狗信息，以及进程状态信息之后，按照预设的策略，确定是否要执行内核重启操作。

可选的，Hungdetect看门狗检测的应用程序框架层中任意一个软件看门狗异常时，Hungdetect看门狗都会执行内核重启操作，以通过内核重启来恢复应用程序框架层中相应的进程。

又可选的，Hungdetect看门狗检测的应用程序框架层中多个软件看门狗异常时，Hungdetect看门狗再执行内核重启操作，以通过内核重启来恢复应用程序框架层中相应的进程。

又可选的，Hungdetect看门狗检测的应用程序框架层中任意一个软件看门狗在连续多个周期内都异常时，Hungdetect看门狗再执行内核重启操作，以通过内核重启来恢复应用程序框架层中相应的进程。

示例性的，以三个周期为例，假设Hungdetect看门狗连续三个周期没有获取到System Server WatchDog的踢狗信息，或者，连续三个周期获取到Xcollie发送的进程状态信息为ERROR，则执行内核重启操作。

类似的，在本实施例中，硬件层第一硬件看门狗不仅可以检测硬件芯片，还可以对内核层中Hungdetect看门狗和CPU核状态看门狗等进行检测。

如果Hungdetect看门狗或CPU核状态看门狗没有按时对第一硬件看门狗执行踢狗操作，则第一硬件看门狗复位其检测的硬件芯片，使整机重启，以通过整机重启来恢复内核系统。

本场景未尽详细解释之处请参见前述场景中的描述，在此不再赘述。

这样，通过在电子设备层与层之间设置检测机制，实现了对电子设备的分层分级恢复。由于下次恢复的颗粒度要大于上层恢复的颗粒度，进而在上层无法成功恢复时，通过下层重启的方式来提高上层恢复的成功率，进而也能够避免电子设备某一层反复重启却无法成功的问题。

此外，需要说明的是，为了使得本申请提供的看门狗检测方法能够适应于不同芯片平台，从而实现多级的狗看护，以实现对电子设备的全面覆盖，保证电子设备能够正常使用，在内核层中还可以设置一个预先封装的适配节点，以使内核层中CPU核状态看门狗和Hungdetect看门狗等能够被不同芯片平台提供的硬件看门狗进行检测。

示例性的，由于不同平台的硬件看门狗在加载时所需时间不同，因此相同时间内未获取CPU核状态看门狗提供的喂狗信息，对于不同的硬件看门狗，有些可能会认为正常，有些则会认为异常，进而执行狗叫，甚至狗咬。因此，为了保证本申请技术方案能够适配不同的硬件看门狗，在电子设备启动时，可以调用硬件看门狗的关闭接口将其关闭，待上层的软件看门狗都启动后再开启硬件看门狗。

此外，在具体实现时，为了简化调用程序，避免代码冗余，可以统一封装初始化硬件狗的接口，触发狗咬(执行复位)的接口和停止喂狗的接口，然后通过这些统一的接口去调用电子设备当前采用的硬件狗的处理逻辑，从而实现一套方案能够适配不同的硬件看门狗。

本实施例还提供一种计算机存储介质，该计算机存储介质中存储有计算机指令，当该计算机指令在电子设备上运行时，使得电子设备执行上述相关方法步骤实现上述实施例中的看门狗检测方法。

本实施例还提供了一种计算机程序产品，当该计算机程序产品在计算机上运行时，使得计算机执行上述相关步骤，以实现上述实施例中的看门狗检测方法。

另外，本申请的实施例还提供一种装置，这个装置具体可以是芯片，组件或模块，该装置可包括相连的处理器和存储器；其中，存储器用于存储计算机执行指令，当装置运行时，处理器可执行存储器存储的计算机执行指令，以使芯片执行上述各方法实施例中的看门狗检测方法。

其中，本实施例提供的电子设备、计算机存储介质、计算机程序产品或芯片均用于执行上文所提供的对应的方法，因此，其所能达到的有益效果可参考上文所提供的看门狗检测方法中的有益效果，此处不再赘述。

通过以上实施方式的描述，所属领域的技术人员可以了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个装置，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

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

Claims (10)

1.一种看门狗检测方法，其特征在于，应用于电子设备中，包括：

在系统服务进程初始化的过程中，第一看门狗启动；其中，所述第一看门狗用于检测所述系统服务进程，并在所述系统服务进程异常时重启所述系统服务进程；所述系统服务进程位于电子设备的应用程序框架层中；

第二看门狗启动对所述第一看门狗的检测功能；其中，所述第二看门狗位于电子设备内核层中，所述第二看门狗还用于对内核系统进行检测；

所述第二看门狗在所述第一看门狗异常时，重启所述内核系统。

2.根据权利要求1所述的方法，其特征在于，在所述系统服务进程初始化之前，还包括：

在内核系统初始化的过程中，所述第二看门狗启动；

所述第二看门狗在检测到内核系统异常时，重启所述内核系统。

3.根据权利要求1所述的方法，其特征在于，所述第二看门狗启动对所述第一看门狗的检测功能，包括：

所述第二看门狗如果接收到指示信息，则启动对所述第一看门狗的检测功能；其中，所述指示信息用于指示所述系统服务进程执行初始化操作。

4.根据权利要求1所述的方法，其特征在于，所述第二看门狗在所述第一看门狗异常时，重启所述内核系统，包括：

所述第二看门狗在所述第一看门狗失效或者所述第一看门狗无法成功重启所述系统服务进程时，重启所述内核系统。

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

所述第一看门狗在所述系统服务进程正常时，定时对所述第二看门狗进行喂狗操作；

所述第一看门狗在所述系统服务进程正常时，停止对所述第二看门狗的喂狗操作；

如果所述第二看门狗在一个或连续多个检测周期内没有接收到所述第一看门狗的喂狗操作，则确定所述第一看门狗异常。

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

所述系统服务进程定时检测目标服务是否运行正常；其中，所述目标服务运行在所述系统服务进程中；

如果所述目标服务运行正常，则所述系统服务进程对所述第一看门狗进行喂狗操作；

如果所述目标服务运行异常，则所述系统服务进程停止对所述第一看门狗的喂狗操作；

如果所述第一看门狗在一个或连续多个检测周期内没有接收到所述系统服务进程的喂狗操作，则确定所述系统服务进程异常。

7.根据权利要求6所述的方法，其特征在于，所述目标服务至少包括窗口管理服务、运行管理服务、包管理服务。

8.根据权利要求1所述的方法，其特征在于，第二检测周期是第一检测周期的整数倍；其中，

所述第一检测周期为所述第一看门狗对所述系统服务进程的检测周期，所述第二检测周期为所述第二看门狗对所述第一看门狗的检测周期。

9.一种电子设备，其特征在于，包括：一个或多个处理器；一个或多个存储器；所述一个或多个存储器存储有一个或多个程序，当所述一个或者多个程序被所述一个或多个处理器执行时，使得所述电子设备执行权利要求1～8中任一项所述的看门狗检测方法。

10.一种计算机可读存储介质，包括计算机程序，其特征在于，当所述计算机程序在电子设备上运行时，使得所述电子设备执行如权利要求1～8中任意一项所述的看门狗检测方法。