CN115017004A - 进程监控方法及电子设备 - Google Patents

Abstract

本申请实施例提供一种进程监控方法及电子设备，涉及媒体播放技术领域。在本申请方案中，在系统服务system_server进程中创建媒体播放对象；对与媒体播放对象的同步接口对应的媒体服务mediaserver进程的同步接口添加监控器。当监控器的监控时长达到预期耗时，如果被监控的同步接口及其设计的本地服务的逻辑段没有执行完，那么终止媒体服务mediaserver进程。如此，媒体服务mediaserver进程的同步接口将不再阻塞系统服务system_server进程，从而避免出现冻屏或重启。

Description

进程监控方法及电子设备

技术领域

本申请涉及媒体播放技术领域，尤其涉及一种进程监控方法及电子设备。

背景技术

目前，大多数终端设备提供了声音设置功能。在声音设置界面中，不但包含了铃声类型选择选项，还包含了音量调节选项。用户可以通过对这些选项的触控操作，为来电、通知、短信、语音和闹钟等设置铃声和音量。

通常，为了便于用户预先体验声音的设置效果，在用户操作这些选项之后，终端设备的系统服务system_server进程会立即调用媒体服务mediaserver进程，媒体服务mediaserver进程又会与本地服务native层交互，以通过本地服务native层获取硬件编解码等服务，进而播放声音。

然而，在上述过程中，如果媒体服务mediaserver进程或本地服务native层被阻塞，那么将会导致系统服务system_server进程被阻塞，进而导致设备冻屏或重启，从而影响用户使用体验。

发明内容

本申请提供一种进程监控方法及电子设备，解决了由于媒体服务mediaserver进程或本地服务native层被阻塞，导致系统服务system_server进程被阻塞，进而导致设备冻屏或重启的问题。

为达到上述目的，本申请采用如下技术方案：

第一方面，本申请实施例提供一种进程监控方法，该方法包括：

在系统服务进程中创建媒体播放对象；

对与第一同步接口对应的第二同步接口添加监控器，并设置监控器的预期耗时，该第一同步接口属于媒体播放对象，该第二同步接口属于媒体服务进程；

运行媒体服务进程，启动监控器；

在第一条件下终止媒体服务进程，第一条件为：监控器的监控时长达到预期耗时，且未执行完成与第二同步接口对应的逻辑段。

通过该方案，当用于监控媒体服务进程的同步接口的监控器的监控时长达到预期最大耗时，如果被监控的媒体服务进程的同步接口及其设计的本地服务的逻辑段没有执行完，那么媒体服务进程自杀。如此，该同步接口将不再阻塞系统服务进程，进而不会出现冻屏或重启，从而提升了用户使用体验。

在一些实施例中，该方法还包括：

在第二条件下执行媒体服务进程的其他逻辑段，第二条件为：执行完成与第二同步接口对应的逻辑段，且监控器的监控时长未达到预期耗时。

在一些实施例中，第一同步接口与第二同步接口为一一对应关系。

在一些实施例中，第一同步接口的数量为多个；

对与第一同步接口对应的第二同步接口添加监控器，包括：

对与每个第一同步接口对应的第二同步接口分别添加监控器。

在一些实施例中，第一同步接口为媒体播放对象的任意同步接口，或者为媒体播放对象的全部同步接口中符合目标条件的同步接口。

在一些实施例中，目标条件包括以下至少一项：

同步接口的阻塞概率大于或等于第一阈值；

同步接口的使用概率大于或等于第二阈值。

在一些实施例中，在为多个第二同步接口中的每个第二同步接口分别添加监控器的情况下，每个监控器的预设耗时相等，或者，每个监控器的预设耗时不相等。

在一些实施例中，在系统服务进程中创建媒体播放对象，包括：

响应于用户通过系统设置音频的操作，在系统服务进程中创建媒体播放对象；或者，

在系统生成目标事件的提醒消息后，在系统服务进程中创建媒体播放对象。

在一些实施例中，设置音频的操作包括以下任意一项：

调节音量的操作；

设置铃声的操作。

在一些实施例中，目标事件包括以下任意一项：

系统接收到其他设备发送的消息；

系统接收到其他应用程序或其他进程发送的消息。

在一些实施例中，终止媒体服务进程之后，该方法还包括：

在准备就绪后，重新启动媒体服务进程。

在一些实施例中，媒体播放对象的同步接口包括以下至少一项：

创建数据源接口、准备接口、开始接口、停止接口、释放接口、重置接口、暂停接口、错误接口、指定播放位置接口、循环播放接口。

第二方面，提供一种电子设备，包括处理器，该处理器与存储器耦合，该处理器用于执行该存储器中存储的计算机程序或指令，以使得电子设备实现如第一方面中任一项的进程监控方法。

第三方面，提供一种芯片系统，该芯片系统与存储器耦合，该芯片系统用于读取并执行该存储器中存储的计算机程序，以实现如第一方面中任一项的进程监控方法。

第四方面，提供一种计算机可读存储介质，该计算机可读存储介质存储有计算机程序，当该计算机程序在电子设备上运行时，使得电子设备执行如第一方面中任一项的进程监控方法。

第五方面，提供一种计算机程序产品，当计算机程序产品在计算机上运行时，使得计算机执行如第一方面中任一项的进程监控方法。

可以理解的是，上述第二方面至第五方面的有益效果可以参见上述第一方面中的相关描述，在此不再赘述。

附图说明

图1为本申请实施例提供的通过系统设置铃声及音量的操作示意图；

图2为本申请实施例提供的系统服务system_server进程被阻塞的示意图；

图3A为本申请实施例提供的准备过程的流程示意图；

图3B为本申请实施例提供的创建数据源过程的流程示意图；

图4为本申请实施例提供的线程监控机制的示意图；

图5为本申请实施例提供的媒体播放器的生命周期的示意图；

图6为本申请实施例提供的一种进程监控方法的流程示意图；

图7为本申请一实施例提供的对媒体服务的同步接口添加监控器的示意图；

图8为本申请另一实施例提供的对媒体服务的同步接口添加监控器的示意图；

图9为本申请实施例提供的对准备过程添加监控的示意图；

图10为本申请实施例提供的监控媒体服务进程的流程示意图；

图11为本申请实施例提供的媒体服务进程的状态示意图；

图12为本申请实施例提供的对第三方应用程序调用的媒体服务进程进行监控的示意图；

图13为本申请实施例提供的电子设备的结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。

在本申请的描述中，除非另有说明，“/”表示或的意思，例如，A/B可以表示A或B；本文中的“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。并且，在本申请的描述中，除非另有说明，“多个”是指两个或多于两个。另外，为了便于清楚描述本申请实施例的技术方案，本申请实施例中的“第一”和“第二”等是用于区别不同的对象，或者用于区别对同一对象的不同处理，而不是用于描述对象的特定顺序。

在本申请说明书中描述的参考“一个实施例”或“一些实施例”等意味着在本申请的一个或多个实施例中包括结合该实施例描述的特定特征、结构或特点。由此，在本说明书中的不同之处出现的语句“在一个实施例中”、“在一些实施例中”、“在其他一些实施例中”、“在另外一些实施例中”等不是必然都参考相同的实施例，而是意味着“一个或多个但不是所有的实施例”，除非是以其他方式另外特别强调。术语“包括”、“包含”、“具有”及它们的变形都意味着“包括但不限于”，除非是以其他方式另外特别强调。

首先对本申请中涉及的一些名词或者术语进行解释说明。

冻屏是指在屏幕显示的用户界面(user interface，UI)呈现锁定状态，无法响应用户对屏幕的操作。从软件角度上分析，冻屏通常是内存泄漏(memory leak)引起的，而内存泄漏通常是由于对象没有及时释放造成的。由于一个对象可能包含多个子对象，并且有些类属于相互继承的关系，因此一个对象未释放将引起多处内存泄漏，从而导致冻屏。

java语言的交互方式分为同步交互方式和异步交互方式。同步交互方式是指在发送一个请求消息后，需要等待返回消息，然后才能够发送下一个请求消息。异步交互方式是指在发送一个请求消息后，不需要等待返回消息，随时可以再发送下一个请求消息。本申请实施例涉及的各个接口为采用同步交互方式的同步接口。同步接口在采用交互方式时，由多个字符组成一个信息帧，每个信息帧用同步字符作为开始，在统一的时钟信号控制下，发送端将信息帧中的字符一个接一个地通过同步接口传输。

系统服务system_server是操作系统(operating system，OS)的基本服务的提供者。通常，系统服务system_server包括了内容提供服务content_service、壁纸管理服务wall paper manager_service、振动器服务vibrate_service、网络管理服务networkmanager_service、磁盘加载服务mount_service、输入法管理服务input method manager_service、熵服务entropy_service等各种基础服务。

以安卓(Android)系统为例，由于系统服务system_server是安卓系统运行的最基本需求，几乎所有重要的服务均运行在系统进程system_process中，而系统进程system_process是java虚拟机的第一个进程和核心进程，因此整个安卓系统的业务都是围绕系统服务system_server展开的。当系统进程system_process卡住时，将会导致冻屏。在冻屏的时长超过预设时长之后，为了保证安卓系统的正常使用，java虚拟机将会重启，即电子设备将会重启。需要说明的是，本申请提供的进程监控方法既适用于安卓系统，也适用于其他操作系统，本申请实施例不作限定。

媒体播放器mediaplayer是一款通用的独立媒体播放器。媒体播放器mediaplayer既可以作为一个单独的应用程序使用，也可以由超文本标记语言(HTML)文本的超级连接启动以播放流信息，还可以作为一个集成平台Activex对象在网页中使用。媒体播放器mediaplayer几乎支持各种格式文件，包括.wav、.snd、.aif、.au和.mp3等格式的音频文件，.mov、.avi、.qt、.wmv、.mpg和.m1v等格式的图像文件，.asx、.wax和.m3u等格式的播放列表文件。既能够实现音频的独立播放，又能够实现音频和视频的同步播放。

媒体服务mediaserver存储在frameworks/base/media/mediaserver目录中，专门用于提供多媒体服务。作为多媒体服务的核心，与媒体播放相关的事宜几乎都通过媒体服务mediaserver进程实现。具体包括了音频播放、多媒体文件的播放、摄像头操作和音频管理等。媒体服务mediaserver通过binder进程间通信方式来完成其他进程的请求。例如，媒体服务mediaserver既可以被系统服务system_server进程创建的媒体播放对象调用，也可以被第三方应用程序进程创建的媒体播放对象调用。

本地服务native层是硬件抽象层(hardware abstraction layer，HAL)的一部分，提供了一系列第三方类库，例如系统C库、多媒体库、提供网络工具webkit、轻量级数据库sqlite、安全套接层协议(secure socket layer，SSL)、向量图像库(skia graphicslibrary，SGL)等。在本申请实施例中，媒体服务mediaserver调用了本地服务native层的多媒体库，例如该多媒体库为媒体提取器media_extrator。

binder的中文释义为粘合剂，意思是粘合了两个不同的进程。从进程间通信(inter-process communication)角度分析，binder是一种跨进程通信方式/机制。在本申请实施例中，系统服务system_server进程和媒体服务mediaserver进程之间采用binder通信方式，媒体服务mediaserver进程和本地服务native进程之间也采用binder通信方式。

具体到本申请实施例，在某些场景下，例如在用户使用声音设置功能设置铃声或调节音量的场景中，系统服务system_server进程会通过媒体播放器mediaplayer调用媒体服务mediaserver进程。当系统服务system_server进程通过媒体播放器mediaplayer调用媒体服务mediaserver进程时，媒体服务mediaserver进程会与本地服务native层交互，以通过本地服务native层获取硬件编解码等服务，然后通过声卡、扬声器、耳机、扩音器等硬件播音频。但是，如果媒体服务mediaserver进程或本地服务native层被阻塞，那么将会导致系统服务system_server进程被阻塞。当作为核心进程的系统服务system_server进程被阻塞后，屏幕会呈现冻屏状态。

图1示出了通过系统设置铃声及音量的操作示意图。

图2示出了系统服务system_server进程被阻塞的示意图。

如图1中的(a)所示，在系统设置的声音和振动设置界面中，提供了响铃、振动和静音三种提示模式。当响铃提示模式处于被选中状态时，对于来电、信息、通知、闹钟、音乐、视频、游戏、通话、智慧语音等各种涉及声音播放的功能，分别提供了铃声和音量设置选项，这样用户可以根据喜好为每个功能分别设置铃声和音量。例如，用户可以左右拖动控件01，用来增大或减小闹钟的音量。再例如，用户可以通过点击区域02，触发显示如图1中的(b)所示的铃声类型选择界面，因此用户可以点击“追逐”03作为闹钟铃声。在用户设置与某项功能对应的音量或铃声之后，为了便于用户预先体验音频的设置效果，手机通常会按照如图2所示的流程播放用户设置的音频。

如图2所示，在系统接收到用户在声音和振动设置界面上选择铃声或设置音量的设置操作之后，系统会通知振动+铃声播放方法，创建新媒体播放对象new MediaPlayer。新媒体播放对象new MediaPlayer通常包括但不限于下述几种常用同步接口：创建数据源Mediaplayer.setDataSource接口、准备Mediaplayer.prepare接口、开始Mediaplayer.start接口、停止Mediaplayer.stop接口、释放Mediaplayer.release接口。这些同步接口中的每个同步接口分别对应一个逻辑段(logic segment)。在执行完成一个同步接口对应的逻辑段之后，会继续执行下一个同步接口对应的逻辑段，直至进程结束，从而实现音频播放。

对于媒体服务mediaserver的每个同步接口，在运行到每个同步接口对应的阶段时，均会调用媒体服务mediaserver进程，而媒体服务mediaserver进程又会与本地服务native层的媒体提取器media_extrator进程交互，以通过媒体提取器media_extrator进程获取硬件编解码等服务。但是，在运行到每个同步接口对应的逻辑段时，基于下述几种原因，可能会出现媒体服务mediaserver进程或本地服务native层被卡住或被阻塞的情况。

原因一、binder线程到达上限。

通常，binder由客户机(client)、服务器(server)、服务管理器(servicemanager)以及binder驱动组成。如果客户机向服务器发起请求的频率过高，且服务器对所有的业务执行都加了锁的话，那么就会导致服务器用于接收处理binder事件的线程全部卡住。假设线程池默认最多同时支持15个任务，这些任务可以是任意进程间的任务，例如系统服务system_server进程和媒体服务mediaserver进程之间的binder通信任务，或者媒体服务mediaserver进程和本地服务native层之间的binder通信任务。在达到15个任务之后，binder资源耗尽，导致通路受限，无法再处理binder请求。如果这个时候其他线程再调用该服务器提供的binder方法，就很容易出现媒体服务mediaserver进程或本地服务native层被阻塞。

原因二、媒体服务mediaserver进程处理流程慢。

由于各个进程是基于芯片(microchip)实现的，因此，在某些情况下，即便正在执行少量的任务，但受到芯片能力的影响，也会出现无法获取到某个任务的情况。例如无法获取到媒体服务mediaserver服务，从而导致媒体服务mediaserver进程处理流程慢，进而导致媒体服务mediaserver进程被阻塞。

原因三、硬件编解码卡住。

本申请实施例中，媒体播放依赖于硬件解码，而本地服务native层用于提供硬件编解码等服务。在媒体服务mediaserver进程与本地服务native层交互过程中，本地服务native层可能会出现逻辑问题，例如本地服务native层的媒体提取器media.extractor进程卡住，从而导致本地服务native层卡住，无法正常提供解码服务，进而导致媒体服务mediaserver进程阻塞。

基于上述任意一种原因，如果媒体服务mediaserver进程或本地服务native层被阻塞，那么将会导致系统服务system_server进程被阻塞。当作为核心进程的系统服务system_server进程被阻塞后，屏幕会呈现冻屏状态。

需要说明的是，由于媒体播放器mediaplayer的各个接口均为同步接口，因此均存在如果媒体服务mediaserver进程或本地服务native层被阻塞，不会向系统服务system_server进程上报成功或失败的信号，导致系统服务system_server进程被阻塞的问题。为了更清楚地示意同步接口被阻塞的过程，下面以如图3A所示的准备(prepare)过程和如图3B所示的创建数据源(setDataSource)过程为例进行示例性说明。

如图3A所示，系统服务system_server进程可以通过媒体播放器mediaplayer的准备Mediaplayer.prepare接口调用媒体服务mediaserver进程的异步准备prepareAsync()方法，开始持锁等待mSignal.wait(mLock)，即进行了加锁。然后，通过媒体服务mediaserver进程执行在异步准备onPrepareAsync()方法；之后，通过媒体提取器media_extrator进程执行准备数据源makeDataSource()方法和远程数据源包裹方法RemoteDataSource::wrap()方法；再之后，通过媒体服务mediaserver进程执行完成异步准备finishPrepareAsync()方法。然后，通过通知notify()方法、信号回调mSignal.signal()方法，向mSignal.wait(mLock)上报成功消息或失败消息。在这个过程中，准备数据源makeDataSource()方法和远程数据源包裹方法RemoteDataSource::wrap()方法是用于向底层解码服务传输数据源信息的，在这里存在被卡住的可能性，那么将会导致系统服务system_server进程被阻塞。当作为核心进程的系统服务system_server进程被阻塞后，屏幕进入冻屏状态。

与如图3A所示的准备(prepare)过程类似，在如图3B所示的创建数据源(setDataSource)过程中，系统服务system_server进程可以通过媒体播放器mediaplayer的准备媒体播放创建数据源MediaPlayer.setDataSource接口调用媒体服务mediaserver进程的创建数据源setDataSource()方法。然后通过创建数据源准备setDataSource_pre方法拉起可能需要的底层解码服务。之后，采用所有服务创建Codec2Client::CreateFromAllServices()方法进行每个服务注册事件监听。在创建数据源准备setDataSource_pre方法完成后，通过创建数据源公布setDataSource_post方法下发到驱动侧继续执行创建数据源流程。在通过所有服务创建Codec2Client::CreateFromAllServices()方法接口执行时，由于芯片原因可能导致该接口被卡住，进而导致系统服务system_server进程被阻塞。当作为核心进程的系统服务system_server进程被阻塞后，屏幕进入冻屏状态。

在屏幕进入冻屏状态之后，如果持续处于冻屏状态，将会影响用户使用电子设备。为了解决这一问题，相关技术提出了重启机制：预设定时时长，例如60秒。在屏幕进入冻屏状态之后，开始定时。如果在达到定时时长之前，解决了系统服务system_server进程的阻塞问题，屏幕由冻屏状态切换至正常工作状态，那么用户可以继续使用电子设备。如果在达到定时时长时，系统服务system_server进程仍被阻塞，屏幕依然处于冻屏状态，那么电子设备的虚拟机将会重启。如此在重启之后，用户可以继续使用电子设备。

上述重启机制虽然解决了屏幕处于冻屏状态影响用户使用电子设备的问题，但是长时间等待可能并不符合用户预期。特别是，在虚拟机重启之后，原来运行的所有进程均会被结束，例如将后台运行的所有应用程序关闭。如果用户想要使电子设备恢复重启之前的状态，那么可能要进行大量繁琐的操作，降低了用户的使用体验。

为了解决由于系统服务system_server进程被阻塞导致的设备冻屏或重启的问题，本申请实施例提出了一种进程监控方案。在系统服务system_server进程中创建媒体播放对象mediaplayer；然后，对与媒体播放器mediaplayer的同步接口对应的媒体服务mediaserver进程的同步接口添加监控器。当被监控的同步接口及其设计的本地服务native逻辑段执行完成时，如果监控器的监控时长没有达到预期耗时，那么媒体服务mediaserver进程将按照原有的逻辑段继续进行。当监控器的监控时长达到预期最大耗时，如果被监控的同步接口及其设计的本地服务native的逻辑段没有执行完，那么媒体服务mediaserver进程自杀。如此，该同步接口将不再阻塞系统服务system_server进程，进而不会出现冻屏或重启，从而提升了用户使用体验。

需要说明的是，本申请的目的是，对媒体播放器mediaplayer的同步接口对应的媒体服务mediaserver的同步接口添加监控器，以监控阻塞事件是否超时。因此，下面将围绕线程监控机制、媒体播放器mediaplayer的生命周期、对同步接口的线程监控方法、媒体服务mediaserver进程的状态等展开示例性说明。

图4示出了一种线程(thread)监控机制的示意图。

如图4中的(a)所示，线程1包括了3个线程运行阶段，每个线程运行阶段可视为一个逻辑段。在线程1启动之后，按照原有的设计，先执行线程运行阶段1；在执行完成线程运行阶段1之后，再执行线程运行阶段2；在执行完成线程运行阶段2之后，再执行线程运行阶段3。直至执行完成线程运行阶段3，线程1结束。

如图4中的(b)所示，对线程1的线程运行阶段2添加了监控器，并设置预期耗时。具体方案为：在执行完成线程运行阶段1之后，监控器对线程运行阶段2开始监控。当被监控的线程运行阶段2执行完成时，如果监控时长没有超过该预期耗时，那么如图4中(b)的实线箭头流程所示，结束监控，并继续按照原有的逻辑段进行，即执行线程运行阶段3。如果监控时长达到该预期耗时，被监控的线程运行阶段2还没有执行完，即线程运行阶段2超时，则如图4中(b)的虚线箭头流程所示，启动线程自杀，从而终止线程1。

上述预期耗时可以根据实际使用需求确定。可以理解，对于不同的线程，或不同的线程运行阶段，根据其逻辑的复杂程度、芯片处理能力等，预期耗时可能也有所不同。例如，对于一个较为简单的逻辑段，执行时间较短，那么设置的预期耗时也可以较短；而对于一个较为复杂的逻辑段，执行时间长，那么设置的预期耗时也可以较长。

需要说明的是，图4提供的线程监控机制也适用于对进程中的各个逻辑段的监控。在传统概念中，进程是拥有资源的基本单位；线程是调度和分配的基本单位，不拥有系统资源，但可以访问隶属于进程的资源。一个进程可以运行多个线程，多个线程可共享数据。具体到本申请实施例的音频播放过程，系统服务system_server、媒体服务mediaserver等属于进程，在调用过程中又涉及到了线程及其他进程。

另外，本申请实施例根据媒体服务mediaserver进程包含的多个同步接口，将该进程划分为多个数据段。每个同步接口的数据段被称为一个逻辑段、一个运行阶段或一个逻辑流程。例如，在如图7或图8所示的媒体服务mediaserver进程中，创建数据源setDataSource接口、异步准备prepareAsync接口、开始start接口、停止stop接口、断开disconnect接口、重置reset接口各自分别对应一个逻辑段。因此，参照如图4提供的线程监控机制，可以对与媒体服务mediaserver进程的同步接口对应的逻辑段进行监控。

此外，上述“自杀”是指当线程/进程在执行任务，且任务又没有处理中断时，如果任务超时，那么可以销毁或终止线程/进程，以结束该线程/进程的生命周期。具体到本申请实施例，当在媒体服务mediaserver进程中通过媒体播放器mediaplayer播放声音时，如果媒体服务mediaserver进程或本地服务native进程卡住，导致任务超时，那么可以提前结束媒体服务mediaserver进程的生命周期，从而销毁线程或终止线程。

图5示出了媒体播放器mediaplayer的生命周期(状态机)的示意图。

如图5所示，媒体播放器mediaplayer的生命周期可以包括：空闲(idle)状态、初始化(initialized)状态、就绪(prepared)状态、准备中(preparing)状态、开始(started)状态、停止(stop)状态、暂停(paused)状态、播放完毕(playback completed)状态、结束(end)状态和错误(error)状态。

需要说明的是，在图5中，①用于表示重置reset()方法，②用于表示创建数据源setDataSource()方法，③用于表示同步准备prepare()方法，④用于表示开始start()方法，⑤用于表示停止stop()方法，⑥用于表示暂停pause()方法，⑦用于表示异步准备prepareAsync()方法，⑧用于表示释放release()方法，⑨用于表示指定播放位置seekTo()方法，⑩用于表示存在错误onError()方法。

下面对进入和离开媒体播放器mediaplayer的生命周期中的各个状态的方法进行说明。

1)空闲状态，也称为闲置状态，是一个生命周期的开始。

在使用创建new MediaPlayer()方法，或者任何其他状态调用了reset()方法之后，进入空闲状态。

2)结束状态是一个生命周期的结束。

在空闲状态调用release()方法后，会释放资源，进入结束状态。

3)错误状态用于指示播放器引擎内部发生的错误。

当检测到异常时，系统回调onError()方法进入错误状态。例如，注册一个OnErrorListener重写onError()方法，以用于获取播放器引擎内部发生的错误。另外，在处于错误状态时，可以使用reset()方法回到空闲状态。

4)初始化状态用于指示已完成设置播放文件。

在空闲状态调用setDataSource()方法，媒体播放器mediaplayer会迁移到初始化状态。其中，setDataSource()方法具体可以包括：

setDataSource(String path)、

setDataSource(FileDescriptor fd)、

setDataSource(Context context,Uri uri)、

setDataSource(FileDescriptor fd,long offset,long length)。

5)就绪状态用于指示已完成准备。

6)准备中状态用于指示处于准备中。

一种方式为，初始化状态调用prepare()方法进入就绪状态。

另一种方式为，初始化状态调用prepareAsync()方法进入准备中状态，注册OnPreparedListener.OnPrepared()方法。

无论采用上述两种方式中的哪种方式，如果数据量较大那么均容易造成主线程阻塞。

7)开始状态用于指示开始播放。

就绪状态调用start()方法进入开始状态。

8)停止状态

如果在就绪状态、开始状态、暂停状态或播放完毕状态下，调用stop()方法，那么媒体播放器mediaplayer将会迁移到停止状态。

9)暂停状态

如果开始状态调用pause()方法，那么进入暂停状态。如果暂停状态调用start()方法，那么进入开始状态。

10)播放完毕状态

如果设置了SetLooping()方法,那么播放完毕之后会重新进入开始状态。如果没有设置循环模式，则调用完成OnCompletion.onCompletion()回调方法，媒体播放器mediaplayer会进入播放完毕状态。

结合上述实施例对进入和离开媒体播放器mediaplayer的生命周期中的各个状态的描述，通常会采用某些方法/函数以进入和离开某个状态，以完成整个生命周期。下面通过表1对媒体播放器mediaplayer的常用方法/函数进行示例性说明。

表1

方法/函数	说明
		create()	创建一个要播放的多媒体
getCurrentPosition()	得到当前播放位置
		getDuration()	得到文件的时间
getVideoHeight()	得到视频的高度
		getVideoWidth()	得到视频的宽度
isLooping()	是否循环播放
		isPlaying()	是否正在播放
pause()	暂停
		prepare()	同步准备
prepareAsync()	异步准备
		release()	释放MediaPlayer对象相关的资源
reset()	重置MediaPlayer对象为刚刚创建的状态
		seekTo()	指定播放的位置
setAudioStreamType()	设置流媒体的类型
		setDataSource()	设置多媒体数据来源/创建数据源
setDisplay()	设置用SurfaceHolder来显示多媒体
		setLooping()	设置是否循环播放
setOnButteringUpdateListener()	网络流媒体的缓冲监听
		setOnErrorListener()	设置错误信息监听
setOnVideoSizeChangedListener()	视频尺寸监听
		setScreenOnWhilePlaying()	设置是否使用SurfaceHolder接口保持屏幕显示
setVolume()	设置音量
		start()	开始播放
stop()	停止播放

通常，媒体播放器mediaplayer的整个生命周期以空闲状态为开始，以结束状态为终止，两个状态间还可以包括若干个其他状态。需要说明的是，具体实现时，在每个生命周期的空闲状态和结束状态之间的状态可能存在差异。本申请实施例将从离开上一个状态到进入下一个状态的过程视为一个逻辑段，在执行每个逻辑段可以采用上述常用方法实现。

例如，采用setDataSource()方法进入初始化状态，采用prepareAsync()方法从初始化状态切换至就绪状态，采用start()从就绪状态切换至开始状态，采用stop()从开始状态切换至停止状态，采用release()从停止状态切换至结束状态。可以理解的是，媒体播放器mediaplayer的生命周期还可以包括其他逻辑段，可以根据实际使用需求确定，本申请实施例不作限定。

具体到本申请实施例，媒体播放器mediaplayer的同步接口包括以下至少一项：创建数据源接口、准备接口、开始接口、停止接口、释放接口、重置接口、暂停接口、错误接口、指定播放位置接口、循环播放接口。媒体播放器mediaplayer的每个同步接口对应一个逻辑段。媒体播放器mediaplayer会通过一系列的同步接口调用媒体服务mediaserver的同步接口，从而实现媒体播放器mediaplayer的生命周期的各个状态切换。因此上述常用方法与媒体播放器mediaplayer、媒体服务mediaserver的同步接口为对应关系。

结合上述实施例的描述，由于媒体播放器mediaplayer的各个接口为同步接口，因此，当媒体服务mediaserver进程或本地服务native进程阻塞时，不会向系统服务system_server进程上报成功或失败的信号，导致系统服务system_server进程一直持锁等待，进而导致屏幕呈现冻屏状态。在冻屏状态持续时长超过预设定时时长后，电子设备将会重启。鉴于这一问题，基于如图4所示的监控机制，本申请实施例提出一种进程监控方法，该方法可以对与图5所示的生命周期中的各个逻辑段/同步接口进行监控。

如图6所示，该方法可以包括下述的S601至S606。

S601、在系统服务system_server进程中创建媒体播放对象。

上述媒体播放对象也称为媒体播放实例。

本申请实施例可以采用下述两种方式创建媒体播放对象：

一种方式为，用new直接创建，MediaPlayer mp＝new MediaPlayer()。

另一种方式为，用create创建，MediaPlayer mp＝MediaPlayer.create(this,R.raw.test)。需要说明的是，这种方式不再调用setDataSource()方法。

需要说明的是，本申请实施例提出的进程监控方法适用于任何在系统服务system_server进程创建媒体播放对象，并监控媒体服务mediaserver的同步接口的场景中。

在一种实现方式中，可以响应于用户通过系统设置音频的操作，在系统服务system_server进程中创建媒体播放对象。其中，该设置音频的操作可以包括以下任意一项：

调节音量的操作；

设置铃声的操作。

例如，如图1所示，在系统设置的声音和振动设置界面中，如果用户对来电、信息、通知、闹钟、音乐、视频、游戏、通话、智慧语音等各种涉及声音播放的功能进行了设置铃声和音量的操作，那么会在系统服务system_server进程中创建媒体播放对象。然后对与媒体播放对象的同步接口对应的媒体服务mediaserver进程的同步接口添加监控器，并设置预期耗时。这样可以对媒体服务mediaserver进程的同步接口进行监控。

在一种实现方式中，可以在系统生成目标事件的提醒消息后，在系统服务system_server进程中创建媒体播放对象。其中，该目标事件可以包括以下任意一项：

系统接收到其他设备发送的消息；

系统接收到其他应用程序或其他进程发送的消息。

例如，在电子设备接收到服务器等其他设备发送的消息时，例如应用程序升级消息和用户消费信息等，通知栏会显示提示信息，此外还会播放提示音。对于播放提示音这一过程，先在系统服务system_server中进程创建媒体播放对象，然后对与媒体播放对象的同步接口对应的媒体服务mediaserver进程的同步接口添加监控器，并设置预期耗时。这样可以对媒体服务mediaserver进程的同步接口进行监控。

又例如，电子设备的某些应用程序或进程会向系统发送通知消息，例如屏幕使用时间应用程序会监测所有活动的使用时间，并在某些时候会向系统发送该使用时间，这样系统会通过通知栏显示该使用时间的提示信息，此外还会播放提示音。对于播放提示音这一过程，先在系统服务system_server进程中创建媒体播放对象，然后对与媒体播放对象的同步接口对应的媒体服务mediaserver进程的同步接口添加监控器，并设置预期耗时。这样可以对媒体服务mediaserver进程的同步接口进行监控。

S602、对与媒体播放对象的同步接口对应的媒体服务mediaserver进程的同步接口添加监控器，并设置监控器的预期耗时。

本申请实施例可以对与第一同步接口对应的第二同步接口添加监控器，并设置监控器的预期耗时。其中，第一同步接口属于媒体播放对象，第二同步接口属于媒体服务进程。

上述媒体播放对象可以包括至少一个同步接口。媒体播放对象的同步接口与媒体服务进程的同步接口为一一对应关系，第一同步接口和第二同步接口为一一对应关系。

上述对媒体服务mediaserver进程的同步接口添加监控器是指在媒体服务mediaserver进程的同步接口的入口添加开始监控，在媒体服务mediaserver进程的同步接口的出口结束监控。

上述第一同步接口为媒体播放对象的任意同步接口，或者为媒体播放对象的全部同步接口中符合目标条件的同步接口。其中，目标条件包括以下至少一项：

同步接口的阻塞概率大于或等于第一阈值；

同步接口的使用概率大于或等于第二阈值。

需要说明的是，上述第一阈值和第二阈值可以相等或不等。

针对媒体服务mediaserver进程的多个同步接口，可以添加至少一个监控器。该至少一个监控器用于监控多个同步接口中的至少一个同步接口。其中，一个监控器为一个监控线程，且一个监控线程对应一个预期耗时。针对为一个同步接口添加的监控线程，该监控线程的起始时刻为该同步接口的开始运行时刻。

当为不同的同步接口分别添加监控器时，一种可能的实现方式为，各个监控器对应的预期耗时不相等。结合上述实施例对预期耗时的描述，对于与各个同步接口对应的逻辑段，根据其逻辑的复杂程度、芯片处理能力等，各个监控器的预期耗时可能也有所不同。对于一个较为简单的逻辑段，执行时间较短，那么设置的监控器的预期耗时也可以较短；而对于一个较为复杂的逻辑段，执行时间较长，那么设置的监控器的预期耗时也可以较长。

另一种可能的实现方式为，各个监控器对应的预期耗时相等。在进程正常运行的情况下，尽管各个逻辑段的执行时间存在差异，但是这些执行时间是毫秒级甚至是微秒级，用户往往感受不到差异。由于阻塞逻辑段的原因很复杂，因此当进程在某些逻辑段阻塞时，各个逻辑段的阻塞时间难以预估。这种情况下，可以将各个监控器对应的预期耗时设置为一个统一的时长。例如，预先通过填写网络调查问卷、走访、大数据等方式获取大量用户数据，对这些用户数据进行分析，得出大多数用户愿意等待冻屏的最大时长为10秒，那么在创建进程时可以将各个监控器对应的预期耗时均设置为10秒。

需要说明的是，本申请实施例中，上述监控器的预期耗时小于重启虚拟机的预设定时时长。该预设时长为从进入冻屏到开始重启虚拟机的时长。以重启虚拟机的预设定时时长为60秒，监控器的预期耗时为10秒为例。按照现有监控机制，如果媒体服务mediaserver进程被阻塞，将导致系统服务system_server进程被阻塞，屏幕进入冻屏状态，如果60秒后屏幕依然处于冻屏状态，那么虚拟机将会开始重启。但是，如果采用本申请实施例提供的监控机制，当监控时长达到10秒时，阻塞超出预期，媒体服务mediaserver进程自杀，这样将不再阻塞系统服务system_server进程，更不会重启虚拟机。

此外，上述监控器可以为定时器(timer)或看门狗(watch dog，WD)。其中，定时器是通过计数实现的；看门狗是一种特殊的定时器，其不但具备了中断功能，还具备了复位功能。当然，监控器还可以通过其他硬件、软件或软硬结合的方式实现，本申请实施例不作限定。

结合上述实施例对图5的描述，不同媒体播放对象mediaplayer的生命周期包括的状态可能有所不同，与媒体播放对象mediaplayer、媒体服务mediaserver对应的同步接口也有所不同。本申请实施例的进程监控方法可以对各类同步接口均进行监控。下面以媒体播放对象mediaplayer包括：创建数据源setDataSource接口、准备repare接口、开始start接口、停止stop接口、释放release接口和重置reset接口，对应的，媒体服务mediaserver进程包括：创建数据源setDataSource接口、异步准备prepareAsync接口、开始start接口、停止stop接口、断开disconnect接口和重置reset接口为例，对为媒体服务mediaserver进程的同步接口设置添加监控器的具体方案进行说明。

方案1、对媒体服务mediaserver进程的多个同步接口中的每个同步接口，分别添加一个监控器。一个监控器为一个监控线程或监控进程。

如图7所示，媒体服务mediaserver进程包括6个同步接口，这6个同步接口的监控线程添加方式如下：对媒体服务mediaserver进程的创建数据源setDataSource接口添加监控线程1，对媒体服务mediaserver进程的异步准备prepareAsync接口添加监控线程2，对媒体服务mediaserver进程的开始start接口添加监控线程3，对媒体服务mediaserver进程的停止stop接口添加监控线程4，对媒体服务mediaserver进程的断开disconnect接口添加监控线程5，对媒体服务mediaserver进程的重置reset接口添加监控线程6。

可以理解的，由于方案1对每个同步接口均添加了监控线程，因此在任意一个同步接口及其设计的本地服务native的逻辑段超时的情况下，均可以被对应的监控线程及时监控到，这种方案的监控效果更好。

方案2、对媒体服务mediaserver进程的多个同步接口中的符合目标条件的同步接口，分别添加一个监控器。例如，该目标条件为同步接口发生阻塞的概率(即阻塞概率)大于或等于预设值，或者同步接口的使用概率大于或等于预设值。

如图8所示，假设媒体服务mediaserver进程中的创建数据源setDataSource接口、异步准备prepareAsync接口、开始start接口、停止stop接口发生阻塞的概率大于或等于预设值，那么对媒体服务mediaserver进程的同步接口监控线程添加方式如下：对媒体服务mediaserver进程的创建数据源setDataSource接口添加监控线程1，对媒体服务mediaserver进程的异步准备prepareAsync接口添加监控线程2，对媒体服务mediaserver进程的开始start接口添加监控线程3，对媒体服务mediaserver进程的停止stop接口添加监控线程4。

可以理解的是，对于某些发生阻塞概率较高或使用概率较高的同步接口，由于发生阻塞概率较高，因此通过添加监控进程可以及时发现阻塞事件。而对某些发生阻塞概率较低或使用概率较低的同步接口，由于发生阻塞概率较低，不添加监控进程可以减少占用的内存。

S603、在运行媒体服务mediaserver进程后，启动监控器，以通过监控器监控媒体服务mediaserver进程的同步接口。

在运行媒体服务mediaserver进程后，对于添加了监控器的同步接口，可以按照各个同步接口的执行顺序，分别对每个同步接口进行如下步骤：

在同步接口的接口入口开始定时，并执行与同步接口对应的逻辑，即，媒体服务mediaserver进程和监控进程同时执行。然后，根据这两个进程中率先完成的进程，判断媒体服务mediaserver进程和本地服务进程是否阻塞。如果先完成与媒体服务mediaserver进程的同步接口对应的逻辑段，而监控进程尚未完成，那么可以确定媒体服务mediaserver进程和与之对应的本地服务进程未阻塞或阻塞未超时，执行下述S604。如果先完成监控进程，而与媒体服务mediaserver进程的同步接口和与之对应的本地服务的逻辑段未完成，那么可以确定媒体服务mediaserver进程和本地服务进程阻塞超时，执行下述S605和S606。

S604、在执行完成与媒体服务mediaserver进程的同步接口对应的逻辑段时，若监控时长未达到预期耗时，则继续执行媒体服务mediaserver进程的其他逻辑段。

上述执行完成与媒体服务mediaserver进程的同步接口对应的逻辑段，且监控器的监控时长未达到预期耗时可以称为第二条件。

S605、在监控时长达到预期耗时，若未执行完成与媒体服务mediaserver进程的同步接口对应的逻辑段，则终止媒体服务mediaserver进程。

上述监控器的监控时长达到预期耗时，且未执行完成与媒体服务mediaserver进程的同步接口对应的逻辑段可以称为第一条件。

如果监控时长达到预期耗时，未执行完成与媒体服务mediaserver进程的同步接口对应的逻辑段，操作系统会调用进程终止原语，按下述方法终止该进程：

a)根据媒体服务mediaserver进程的标识符，从进程控制块(process controlblock PCB)集合中检索出该进程的PCB，并读取该进程的状态。

b)若该进程正处于执行状态，则立即终止该进程的执行，并置调度标志为真。

c)若该进程还有子孙进程，还应将其所有子孙进程予以终止，以防成为不可控的进程。

d)将该进程拥有的全部资源，归还给其父进程或归还系统。

e)将该进程的PCB从所在队列或链表中移出。

下面以如图9所示的准备过程为例进行说明。假设监控器的预期耗时为10秒。在系统服务system_server进程的媒体播放准备接口MediaPlayer.prepare()方法调用媒体服务mediaserver进程的异步准备prepareAsync()方法时，开始持锁等待mSignal.wait(mLock)，同时，监控器在异步准备方法prepareAsync()入口开始监控。媒体服务mediaserver进程按照原有的设计，先执行在异步准备onPrepareAsync()方法；之后，执行准备数据源makeDataSource()方法和远程数据源包裹方法RemoteDataSource::wrap()方法；再之后，执行完成异步准备finishPrepareAsync()方法。如果在执行完成异步准备finishPrepareAsync()方法时，监控时长尚未达到10秒，那么可以确定异步准备接口未堵塞。然后，通过通知notify()方法、信号回调mSignal.signal()方法，向mSignal.wait(mLock)上报成功消息或失败消息。如果在监控时长达到10秒，而未执行完成媒体播放准备接口MediaPlayer.prepare()方法，那么可以确定媒体服务mediaserver进程和本地服务进程阻塞，从而可以终止媒体服务mediaserver进程。

可以理解的是，通过对媒体播放器mediaplayer的同步接口对应的媒体服务mediaserver的同步接口添加监控。当被监控的同步接口及其设计的本地服务native逻辑段执行完成时，如果没有达到预期最大耗时，那么媒体服务mediaserver进程将按照原有逻辑段继续进行。当达到预期最大耗时，如果被监控的同步接口及其设计的本地服务native逻辑段没有执行完，那么媒体服务mediaserver进程自杀。如此，该同步接口将不再阻塞系统服务system_server进程，进而不会出现冻屏或重启，从而提升了用户使用电子设备的体验。

S606、在准备就绪后，重新启动媒体服务mediaserver进程。

在终止媒体服务mediaserver进程之后，媒体服务mediaserver进程再次排入优先级队列，并在分配处理器资源后，重新启动媒体服务mediaserver进程。如此可以保证不影响后续媒体功能，达到了自检自愈的功能，提升了产品的健壮性。

结合上述实施例的描述，媒体服务mediaserver进程发生阻塞的原因包括:binder线程到达上限、媒体服务mediaserver进程处理流程慢、native层编解码卡住。大量的实验数据证明，在终止并重新启动媒体服务mediaserver进程之后，再次发生阻塞概率较低。这是因为：一方面，在终止媒体服务mediaserver进程之后，binder资源得到释放，因此在重新启动媒体服务mediaserver进程之后，可以继续处理binder请求，几乎不会再次发生堵塞；另一方面，基于芯片的运行机制，终止一个进程，再重新启动该进程，往往会提升处理速度，因此重新启动媒体服务mediaserver进程，再次发生阻塞的概率较低；再一方面，本地服务native无法提供服务通常是由于逻辑错误导致的，在终止并重新启动媒体服务mediaserver进程之后，出现同样的逻辑错误概率较低，因此几乎不会出现本地服务native层卡住的问题。

图10示出了一种监控媒体服务mediaserver进程的流程示意图。

假设媒体服务mediaserver进程包括如下接口：创建数据源setDataSource接口、异步准备prepareAsync接口、开始start接口、停止stop接口、断开disconnect接口和重置reset接口，且为这些同步接口中的每个同步接口分别添加一个监控时长是10秒的监控线程。

在启动媒体服务mediaserver进程后，可以采用监控线程1对创建数据源setDataSource接口进行监控。如果在执行完成创建数据源setDataSource接口对应的逻辑段时，未达到10秒，则继续执行异步准备prepareAsync接口对应的逻辑段，并采用监控线程2对异步准备prepareAsync接口进行监控。如果在监控时长达到10秒时，未完成创建数据源setDataSource接口对应的逻辑段，那么可以启动媒体服务mediaserver进程自杀，并结束监控线程1。

如果在执行完成异步准备prepareAsync接口对应的逻辑段时，未达到10秒，则继续执行开始start接口对应的逻辑段，并采用监控线程3对开始start接口进行监控。如果在监控时长达到10秒时，未完成开始start接口对应的逻辑段，那么可以启动媒体服务mediaserver进程自杀，并结束监控线程2。

如果在执行完成停止stop接口对应的逻辑段时，未达到10秒，则继续执行断开disconnect接口对应的逻辑段，并采用监控线程5对断开disconnect接口进行监控。如果在监控时长达到10秒时，未完成停止stop接口对应的逻辑段，那么可以启动媒体服务mediaserver进程自杀，并结束监控线程3。

如果在执行完成断开disconnect接口对应的逻辑段时，未达到10秒，则继续执行重置reset接口对应的逻辑段，并采用监控线程6对重置reset接口进行监控。如果在监控时长达到10秒时，未完成断开disconnect接口进对应的逻辑段，那么可以启动媒体服务mediaserver进程自杀，并结束监控线程4。

如果在执行完成重置reset接口对应的逻辑段时，未达到10秒，则向系统服务进程返回结果，并结束媒体服务mediaserver进程。如果在监控时长达到10秒时，未完成重置reset接口对应的逻辑段，那么可以启动媒体服务mediaserver进程自杀，并结束监控线程5。

可以理解的是，对于媒体服务mediaserver进程，由于对每个同步接口对应的逻辑段均添加了监控器，因此当按照逻辑顺序执行时，若任意一个逻辑段出现了堵塞，则均可以及时启动媒体服务mediaserver进程自杀。如此，媒体服务mediaserver进程将不再阻塞系统服务system_server进程，进而不会出现冻屏或重启。

图11示出了媒体服务mediaserver进程的状态示意图。

需要说明的是，本申请实施例涉及系统服务system_server进程、媒体服务mediaserver进程、本地服务native进程等，这些进程均可以包括就绪状态(ready)、运行状态(running)、阻塞状态(blocked)。除此之外，媒体服务mediaserver进程还包括一个介于就绪状态和阻塞状态之间的终止状态。下面以媒体服务mediaserver进程为例，对各个状态进行示例说明。

就绪状态：是指在创建媒体服务mediaserver进程之后，媒体服务mediaserver进程已获得除处理器外的所需资源，等待分配处理器资源。在分配了处理器之后，媒体服务mediaserver进程就可按照如图10所示的逻辑段执行。就绪状态的进程可以按多个优先级来划分队列。例如，当一个进程由于时间片用完而进入就绪状态时，排入低优先级队列；当进程由输入/输出(I/O)操作完成而进入就绪状态时，排入高优先级队列。

运行状态：是指媒体服务mediaserver进程占用处理器资源的状态。通常，处于运行状态的进程的数目小于等于处理器的数目。在没有其他进程可以执行时，如所有进程都在阻塞状态，通常会自动执行系统的空闲进程。

阻塞状态：是指由于进程等待某种事件(如I/O操作或进程同步)，在事件发生之前无法继续执行的状态。仍以图10为例，在运行至媒体服务mediaserver进程的任意一个同步接口的逻辑段时，均可能发生阻塞，即进入阻塞状态。

终止状态：是本申请实施例提出的一种由阻塞状态向就绪状态过渡的状态。在媒体服务mediaserver进程在某个逻辑段的运行超时的情况下，可以立即启动媒体服务mediaserver进程自杀，进入终止状态。然后再重新启动媒体服务mediaserver进程，进入就绪状态。

需要说明的是，上述实施例是以应用于通过系统服务system_server进程创建的媒体播放对象mediaplayer，并对与媒体播放对象mediaplayer的同步接口对应的媒体服务mediaserver的同步接口添加监控的场景为例进行说明的，其并不对本申请实施例形成限定。本申请实施例提供的进程监控方法，还可以应用于通过第三方应用程序进程创建媒体播放对象mediaplayer，并对与媒体播放器mediaplayer的同步接口对应的媒体服务mediaserver的同步接口添加监控的场景。

图12示出了对第三方应用程序调用的媒体服务mediaserver进程进行监控的示意图。例如，在用户触发第三方应用程序播放一首歌曲时，会创建新媒体播放对象newmediaplayer，流程与图2类似。与图2不同之处在于，图12的准备接口分为同步准备接口和异步准备接口两种。基于第三方应用程序调用的媒体服务mediaserver进程也会基于binder线程到达上限、媒体服务mediaserver进程处理流程慢、硬件编解码卡住这些原因发生阻塞。因此可以采用与图6类似的进程监控方法，对与媒体播放对象的同步接口对应的媒体服务mediaserver进程的同步接口添加监控器，并进行监控。可以参照上述实施例的描述，此处不再赘述。

本申请上述实施例提供的进程监控方法的执行主体可以为电子设备，也可以为该电子设备中能够实现该进程监控方法的功能模块和/或功能实体，并且本申请方案能够通过硬件和/或软件的方式实现，具体的可以根据实际使用需求确定，本申请实施例不作限定。下面以电子设备为例，结合附图对本申请实施例提供的进程监控方法进行示例性的说明。

本申请实施例中的电子设备可以为移动终端，也可以为非移动终端。示例性的，移动终端可以为手机、平板电脑、笔记本电脑、掌上电脑、车载终端、可穿戴设备、超级移动个人计算机(ultra-mobile personal computer，UMPC)、上网本或者个人数字助理(personaldigital assistant，PDA)等，非移动终端可以为个人计算机(personal computer，PC)、电视机(television，TV)、柜员机或者自助机等，本申请实施例不作具体限定。

上文描述了本申请提供的方法实施例，下文将描述本申请提供的装置实施例。应理解，装置实施例的描述与方法实施例的描述相互对应，因此，未详细描述的内容可以参见上文方法实施例，为了简洁，这里不再赘述。

上文主要从方法步骤的角度对本申请实施例提供的方案进行了描述。可以理解的是，为了实现上述功能，实施该方法的电子设备包含了执行各个功能相应的硬件结构和/或软件模块。本领域技术人员应该可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的保护范围。

本申请实施例可以根据上述方法示例，对电子设备进行功能模块的划分，例如，可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。需要说明的是，本申请实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有其它可行的划分方式。下面以采用对应各个功能划分各个功能模块为例进行说明。

本申请实施例提供一种进程监控装置。该装置可以用于执行上文方法实施例中电子设备所执行的动作。该装置包括处理模块。

处理模块可以用于：在系统服务system_server进程中创建媒体播放对象。对与媒体播放对象的同步接口对应的媒体服务mediaserver进程的同步接口添加监控器，并设置监控器的预期耗时。在运行媒体服务mediaserver进程后，通过监控器监控媒体服务mediaserver进程的同步接口。在执行完成与媒体服务mediaserver进程的同步接口对应的逻辑段时，若监控时长未达到预期耗时，则继续执行媒体服务mediaserver进程的其他逻辑段。或者，在监控时长达到预期耗时，若未执行完成与媒体服务mediaserver进程的同步接口对应的逻辑段，则终止媒体服务mediaserver进程，并重新启动媒体服务mediaserver进程。

图13是本申请实施例的电子设备的结构示意图。如图13所示，电子设备100可以包括处理器110，外部存储器接口120，内部存储器121，通用串行总线(universal serialbus，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等。

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

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

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

本申请实施例中，处理器110可以用于：在系统服务system_server进程中创建媒体播放对象。对与媒体播放对象的同步接口对应的媒体服务mediaserver进程的同步接口添加监控器，并设置监控器的预期耗时。在运行媒体服务mediaserver进程后，启动监控器，以通过监控器监控媒体服务mediaserver进程的同步接口。在执行完成与媒体服务mediaserver进程的同步接口对应的逻辑段时，若监控器的监控时长未达到预期耗时，则继续执行媒体服务mediaserver进程的其他逻辑段。或者，在监控器的监控时长达到预期耗时，若未执行完成与媒体服务mediaserver进程的同步接口对应的逻辑段，则终止媒体服务mediaserver进程，并重新启动媒体服务mediaserver进程。

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

可选地，在一些实施例中，本申请提供一种芯片，该芯片与存储器耦合，该芯片用于读取并执行存储器中存储的计算机程序或指令，以执行上述各实施例中的方法。

可选地，在一些实施例中，本申请提供一种电子设备，该电子设备包括芯片，该芯片用于读取并执行存储器存储的计算机程序或指令，使得各实施例中的方法被执行。

可选地，在一些实施例中，本申请实施例还提供了一种计算机可读存储介质，该计算机可读存储介质存储有程序代码，当计算机程序代码在计算机上运行时，使得计算机执行上述各实施例中的方法。

可选地，在一些实施例中，本申请实施例还提供了一种计算机程序产品，该计算机程序产品包括计算机程序代码，当计算机程序代码在计算机上运行时，使得计算机执行上述各实施例中的方法。

在本申请实施例中，各个设备包括硬件层、运行在硬件层之上的操作系统层，以及运行在操作系统层上的应用层。其中，硬件层可以包括中央处理器(central processingunit，CPU)、内存管理单元(memory management unit，MMU)和内存(也称为主存)等硬件。操作系统层的操作系统可以是任意一种或多种通过进程(process)实现业务处理的计算机操作系统，例如，Linux操作系统、Unix操作系统、Android操作系统、iOS操作系统或windows操作系统等。应用层可以包含浏览器、通讯录、文字处理软件、即时通信软件等应用。

本申请实施例并未对本申请实施例提供的方法的执行主体的具体结构进行特别限定，只要能够通过运行记录有本申请实施例提供的方法的代码的程序，以根据本申请实施例提供的方法进行通信即可。例如，本申请实施例提供的方法的执行主体可以是设备，或者，是设备中能够调用程序并执行程序的功能模块。

本申请的各个方面或特征可以实现成方法、装置或使用标准编程和/或工程技术的制品。本文中使用的术语“制品”可以涵盖可从任何计算机可读器件、载体或介质访问的计算机程序。例如，计算机可读介质可以包括但不限于：磁存储器件(例如，硬盘、软盘或磁带等)，光盘(例如，压缩盘(compact disc，CD)、数字通用盘(digital versatile disc，DVD)等)，智能卡和闪存器件(例如，可擦写可编程只读存储器(erasable programmableread-only memory，EPROM)、卡、棒或钥匙驱动器等)。

本文描述的各种存储介质可代表用于存储信息的一个或多个设备和/或其它机器可读介质。术语“机器可读介质”可以包括但不限于：无线信道和能够存储、包含和/或承载指令和/或数据的各种其它介质。

应理解，本申请实施例中提及的处理器可以是中央处理单元(centralprocessing unit，CPU)，还可以是其他通用处理器、数字信号处理器(digital signalprocessor，DSP)、专用集成电路(application specific integrated circuit，ASIC)、现成可编程门阵列(field programmable gate array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

还应理解，本申请实施例中提及的存储器可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(read-only memory，ROM)、可编程只读存储器(programmable ROM，PROM)、可擦除可编程只读存储器(erasable PROM，EPROM)、电可擦除可编程只读存储器(electrically EPROM，EEPROM)或闪存。易失性存储器可以是随机存取存储器(random access memory，RAM)。例如，RAM可以用作外部高速缓存。作为示例而非限定，RAM可以包括如下多种形式：静态随机存取存储器(static RAM，SRAM)、动态随机存取存储器(dynamic RAM，DRAM)、同步动态随机存取存储器(synchronous DRAM，SDRAM)、双倍数据速率同步动态随机存取存储器(doubledata rate SDRAM，DDR SDRAM)、增强型同步动态随机存取存储器(enhanced SDRAM，ESDRAM)、同步连接动态随机存取存储器(synchlink DRAM，SLDRAM)和直接内存总线随机存取存储器(direct rambus RAM，DR RAM)。

需要说明的是，当处理器为通用处理器、DSP、ASIC、FPGA或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件时，存储器(存储模块)可以集成在处理器中。

还需要说明的是，本文描述的存储器旨在包括但不限于这些和任意其它适合类型的存储器。

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

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

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

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上，或者说对现有技术做出贡献的部分，或者该技术方案的部分，可以以计算机软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，该计算机软件产品包括若干指令，该指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。前述的存储介质可以包括但不限于：U盘、移动硬盘、ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中在本申请的说明书中所使用的术语只是为了描述具体的实施例的目的，不是旨在于限制本申请。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (18)

1.一种进程监控方法，其特征在于，所述方法包括：

在系统服务进程中创建媒体播放对象；

对与第一同步接口对应的第二同步接口添加监控器，并设置所述监控器的预期耗时，所述第一同步接口属于所述媒体播放对象，所述第二同步接口属于媒体服务进程；

运行所述媒体服务进程，启动所述监控器；

在第一条件下终止所述媒体服务进程，所述第一条件为：所述监控器的监控时长达到所述预期耗时，且未执行完成与所述第二同步接口对应的逻辑段。

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

在第二条件下执行所述媒体服务进程的其他逻辑段，所述第二条件为：执行完成与所述第二同步接口对应的逻辑段，且所述监控器的监控时长未达到所述预期耗时。

3.根据权利要求1或2所述的方法，其特征在于，所述第一同步接口与所述第二同步接口为一一对应关系。

4.根据权利要求3所述的方法，其特征在于，所述第一同步接口的数量为多个；

所述对与第一同步接口对应的第二同步接口添加监控器，包括：

对与每个第一同步接口对应的第二同步接口分别添加监控器。

5.根据权利要求4所述的方法，其特征在于，所述第一同步接口为所述媒体播放对象的任意同步接口，或者为所述媒体播放对象的全部同步接口中符合目标条件的同步接口。

6.根据权利要求5所述的方法，其特征在于，所述目标条件包括以下至少一项：

同步接口的阻塞概率大于或等于第一阈值；

同步接口的使用概率大于或等于第二阈值。

7.根据权利要求4所述的方法，其特征在于，在为多个第二同步接口中的每个第二同步接口分别添加监控器的情况下，每个监控器的预设耗时相等，或者，每个监控器的预设耗时不相等。

8.根据权利要求1至7中任一项所述的方法，其特征在于，所述监控器的预期耗时小于预设时长，所述预设时长为从进入冻屏到开始重启虚拟机的时长。

9.根据权利要求1至7中任一项所述的方法，其特征在于，所述监控器为定时器或看门狗。

10.根据权利要求1至9中任一项所述的方法，其特征在于，所述在系统服务进程中创建媒体播放对象，包括：

响应于用户通过系统设置音频的操作，在所述系统服务进程中创建所述媒体播放对象；或者，

在系统生成目标事件的提醒消息后，在所述系统服务进程中创建所述媒体播放对象。

11.根据权利要求10所述的方法，其特征在于，所述设置音频的操作包括以下任意一项：

调节音量的操作；

设置铃声的操作。

12.根据权利要求10所述的方法，其特征在于，所述目标事件包括以下任意一项：

系统接收到其他设备发送的消息；

系统接收到其他应用程序或其他进程发送的消息。

13.根据权利要求1至12中任一项所述的方法，其特征在于，在终止所述媒体服务进程之后，所述方法还包括：

在准备就绪后，重新启动所述媒体服务进程。

14.根据权利要求1至13中任一项所述的方法，其特征在于，所述媒体播放对象的同步接口包括以下至少一项：

创建数据源接口、准备接口、开始接口、停止接口、释放接口、重置接口、暂停接口、错误接口、指定播放位置接口、循环播放接口。

15.一种电子设备，其特征在于，包括处理器，所述处理器与存储器耦合，所述处理器用于执行所述存储器中存储的计算机程序或指令，以使得所述电子设备实现如权利要求1至14中任一项所述的进程监控方法。

16.一种芯片系统，其特征在于，所述芯片系统与存储器耦合，所述芯片系统用于读取并执行所述存储器中存储的计算机程序，以实现如权利要求1至14中任一项所述的进程监控方法。

17.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机程序，当所述计算机程序在电子设备上运行时，使得所述电子设备执行如权利要求1至14中任一项所述的进程监控方法。

18.一种计算机程序产品，其特征在于，当所述计算机程序产品在计算机上运行时，使得所述计算机执行如权利要求1至14中任一项所述的进程监控方法。

Images