CN115525453B - 多屏协同中断的处理方法及电子设备 - Google Patents

Abstract

本申请实施例提供了一种多屏协同中断的处理方法及电子设备，属于终端技术领域。该方法包括：调用第一函数，第一函数的调用用于发送待编码的投屏数据；响应于第一函数的调用，调用第二函数，第二函数的调用用于触发缓存队列的可用帧的查询流程；响应于第二函数的调用，监听第一函数的调用时间是否超过预设的容忍时间；当第一函数的调用时间超过预设的容忍时间时，终止多屏协同的进程。该方法通过在多屏协同框架设置监听接口，当监听到调用者未调用到目标资源时，通知调用者采取处理措施保证设备运行，进而避免电子设备在多屏协同场景下死机或重启的问题。

Description

多屏协同中断的处理方法及电子设备

技术领域

本申请涉及终端技术领域，尤其涉及一种多屏协同中断的处理方法及电子设备。

背景技术

随着终端技术的发展，更多电子设备支持多屏协同。利用多屏协同可以将电子设备A的屏幕内容通过有线或者无线的方式投射到电子设备B上显示。投屏后，电子设备A的屏幕内容变化会在电子设备B上同步显示。另外，用户还可以通过电子设备B对电子设备A投射过来的屏幕内容进行操作，使得电子设备A响应于电子设备B的操作，显示相应的屏幕内容。

比如，以手机和平板电脑为例，在多屏协同场景下平板电脑可以显示手机上的窗口，并且用户可以通过控制平板电脑中协同窗口的内容反向控制手机侧的屏幕，手机侧屏幕识别到反控命令后实时修改画面内容，并再次将画面数据发送给编码器，编码后发送至平板电脑。

多屏协同场景下，当用户在平板电脑侧的协同窗口上频繁操作(比如多次拖动视频播放进度条以快进，和/或不断放大或缩小协同窗口等)情况下，容易导致手机重启，严重影响用户的使用体验。

发明内容

本申请实施例提供了一种多屏协同中断的处理方法及电子设备，以解决多屏协同场景下设备容易死机或重启的问题。

通过研究发现，在多屏协同场景下的数据交互过程形成一个闭环状态，多个数据流处理所需的资源有限，其中会存在资源争夺，易导致编码器死锁，进而导致电子设备容易死机或重启。在一些实施例中，可以通过在多屏协同框架设置监听接口，当监听到调用者未调用到目标资源时，通知调用者采取处理措施保证设备运行，进而避免电子设备在多屏协同场景下死机或重启。

第一方面，提供了一种多屏协同中断的处理方法，应用于源设备，所述源设备与目的设备建立用于多屏协同的通信连接，所述方法包括：

调用第一函数，所述第一函数的调用用于向媒体编解码器发送待编码的投屏数据，所述投屏数据用于在所述目的设备上同步显示所述源设备的投屏窗口；

响应于所述第一函数的调用，调用第二函数，所述第二函数的调用用于触发缓存队列的可用帧的查询流程，所述缓存队列用于所述源设备压入所述投屏数据；

响应于所述第二函数的调用，监听所述第一函数的调用时间是否超过预设的容忍时间；

当所述第一函数的调用时间超过预设的容忍时间时，终止所述多屏协同的进程。

其中，第一函数例如可以为源设备SurfaceFlinger调用的queuebuffer函数，用于将投屏数据发送至媒体编解码器(media codec)进行编码。第二函数可以是on frameavailable函数，该第二函数的调用用于查询缓存队列的可用帧。缓存队列的可用帧也可以被描述为可用帧，或者帧缓存队列。

在一种实现方式中，对第一函数的调用时间进行监听具体可以是监听源设备中的SurfaceFlinger调用第一函数的时间是否超过预设的容忍时间。

根据本申请实施例提供的多屏协同中断的处理方法，通过在多屏协同的媒体框架侧设置监听接口，对调用者发起的目标资源调用进行监听，当在达到容忍时间时，调用者仍未获取对应的目标资源时，可以通知调用者采取释放进程等处理措施，保证电子设备的运行，避免电子设备由于资源调用冲突导致同屏协同场景下发生设备重启或者死机的问题，提升用户的使用体验。

结合第一方面，在第一方面的某些实现方式中，当所述第一函数的调用时间超过预设的容忍时间时，检查超时属于异常超时或者属于正常超时；

当所述超时属于异常超时时，终止所述多屏协同的进程，所述异常超时为在所述缓存队列的可用帧的查询流程中，由于未调用到公用锁导致的超时。

在一种实现方式中，在对第一函数的调用时间进行监听之前，源设备可以通过媒体框架模块向容忍时间设置模块发送第一调度信息，指示该容忍时间设置模块设置为第一状态，其中，第一状态是指未持有公用锁的状态。

在一种实现方式中，在初始化时，会创建一个AMessage对象，通过容忍时间设置模块设定一个post时延(容忍时间，delay time)，当达到该容忍时间后，通过AMessage对象发送检查指示信息，该检查指示信息可以在dealwatching函数内被捕获，捕获后会check检查超时是正常超时还是异常超时。

结合第一方面，在第一方面的某些实现方式中，响应于所述第二函数的调用，设置第一状态，所述第一状态用于指示当前未持有所述公用锁；

所述当所述第一函数的调用时间超过预设的容忍时间时，检查超时属于异常超时或者属于正常超时，具体包括：

当所述第一函数的调用时间超过预设的容忍时间时，检查所述第一状态是否已更改为第二状态，所述第二状态用于指示当前持有所述公用锁；其中，

若所述第一状态已更改为第二状态，则确定所述超时属于正常超时；

若所述第一状态未更改为第二状态，则确定所述超时属于异常超时。

在一种实现方式中，dealwatching函数内捕获检查指示信息会check当前状态是否是正常状态，如果当前状态为第一状态(也即未持锁状态)，那么确定当前状态为异常，该超时为异常超时；如果当前状态为第二状态(也即持锁状态)，那么确定当前状态为正常，该超时为正常超时。

结合第一方面，在第一方面的某些实现方式中，当当所述超时属于异常超时时，终止所述多屏协同的进程，具体包括：

当所述超时属于异常超时时，显示第一提示信息，所述第一提示信息用于指示用户手动终止所述多屏协同的进程；或者，

当所述超时属于异常超时时，自动终止所述多屏协同的进程。

结合第一方面，在第一方面的某些实现方式中，所述方法还包括：

当所述超时属于异常超时时，向所述第一函数的调用者发送异常反馈信息，所述异常反馈信息用于指示公用锁调用超时。

应理解，本实现方式提供的多屏协同终端的处理方法，在媒体框架侧增加接口调用监听，每当接口被调用，即开启监听。当监听开始的时候，监听算法会识别三种情况，一种是正常情况(在容忍时间内完成函数调用)，被调用后析构，监听释放；第二种是监听后发现达到预设的最大容忍时间，那么下一步可以check是否正常，当发现当前的持有的资源是被用来做具体的事情，那么可以判定该资源持有为正常流程，直接回到正常流程即可；第三种情况下，当发现调用者持有了资源后，没有执行正常动作，那么需要通知调用者，当前的调用发生了一次死锁，如不处理将引发严重问题。

结合第一方面，在第一方面的某些实现方式中，所述方法还包括：

接收所述目的设备发送的反向控制命令，所述反向控制命令用于指示所述源设备控制所述投屏界面进行目标变化；

响应于所述反向控制命令，调用第三函数，所述第三函数用于触发执行所述目标操作的流程；

响应于所述第三函数的调用，调用所述公用锁，并在所述预设的容忍时间内保持持有所述公用锁。

其中，以反向控制命令指示源设备进行视频播放暂停为例，第三函数例如可以是suspend video。

结合第一方面，在第一方面的某些实现方式中，所述目标变化包括以下至少一项：所述投屏界面最小化，所述投屏界面最大化，所述投屏界面滑动，所述投屏界面中的视频播放暂停。

结合第一方面，在第一方面的某些实现方式中，所述响应于所述第二函数的调用，监听所述第一函数的调用时间是否超过预设的容忍时间，具体包括：

响应于所述第二函数的调用，执行查询可用的帧缓存队列的流程；

调用设置于媒体框架模块中的监听接口，监听所述第一函数的调用时间是否超过预设的容忍时间。

结合第一方面，在第一方面的某些实现方式中，所述方法还包括：

通过所述显示模块调用所述第一函数，向媒体编解码器发送待编码的投屏数据；

响应于所述第一函数的调用，所述缓存队列管理模块调用所述第二函数，指示媒体框架模块查询是否存在所述缓存队列的可用帧；

响应于所述第二函数的调用，所述媒体框架模块调用所述监听接口指示图形缓存监听模块监听所述第一函数的调用时间是否超过预设的容忍时间。

第二方面，提供了一种电子设备，包括：

一个或多个通信接口；

一个或多个处理器；

一个或多个存储器；

所述一个或多个存储器存储有一个或多个计算机程序，所述一个或多个计算机程序包括指令，当所述指令被所述一个或多个处理器执行时，使得所述电子设备执行如第一方面的任一实现方式中所述的方法。

第三方面，提供了一种通信系统，包括源设备和目的设备，所述源设备与所述目的设备之间建立有用于多屏协同的通信连接，所述目的设备用于接收用户的操作，并向所述源设备发送反向控制命令，所述源设备用于执行如第一方面的任一实现方式中所述的方法。

第四方面，提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机可执行程序，所述计算机可执行程序在被计算机调用时，使所述计算机执行如第一方面的任一实现方式中所述的方法。

第五方面，提供了一种包含指令的计算机程序产品，当所述计算机程序产品在电子设备上运行时，使得所述电子设备执行如第一方面的任一实现方式中所述的方法。

附图说明

图1为本申请实施例提供的一种多屏协同中断的处理方法适用的系统架构的示意图。

图2为本申请实施例提供的一种多屏系统设备的示意图。

图3为本申请实施例提供的一种多屏协同过程的示意图。

图4为本申请实施例提供的一种第一电子设备100的结构示意图。

图5为本申请实施例提供的一种第一电子设备100的软件结构框图。

图6为本申请实施例提供的又一种多屏协同的示意图。

图7为本申请实施例提供的一种多屏协同下的数据流向的示意图。

图8为本申请实施例提供的一种多屏协同下资源冲突的示意图。

图9为本申请实施例提供的一种多屏协同中断的处理方法的示意图。

图10为本申请实施例提供的一种多屏协同中断的处理方法的示意图。

具体实施方式

需要说明的是，本申请实施例的实施方式部分使用的术语仅用于对本申请的具体实施例进行解释，而非旨在限定本申请。在本申请实施例的描述中，除非另有说明，“/”表示或的意思，例如，A/B可以表示A或B；本文中的“和/或”仅仅是一种描述关联障碍物的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，在本申请实施例的描述中，除非另有说明，“多个”是指两个或多于两个，“至少一个”、“一个或多个”是指一个、两个或两个以上。

以下，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”特征可以明示或者隐含地包括一个或者更多个该特征。

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

为便于理解，以下对本申请实施例涉及的部分技术术语进行解释和说明。

1、投屏

投屏是指一个电子设备将自身的屏幕内容通过有线或者无线方式投射到另一电子设备的屏幕上显示。以下将投射屏幕内容的电子设备称为源设备，将收到投射屏幕内容的电子设备称为目的设备。

源设备的投屏内容可以以投屏窗口的形式在目的设备上显示。其中，该投屏窗口的内容可以与源设备的屏幕内容同步，如果源设备的屏幕内容发生变化，那么目的设备上投屏窗口中的内容也会随之发生相应的变化。

2、反控

反控是指源设备将自身的屏幕内容投射到目的设备上显示，之后用户可以通过在目的设备上输入针对投屏窗口的操作方向对源设备的屏幕内容进行操作，从而实现对源设备屏幕内容的控制。

3、死锁

是指两个或两个以上的进程在执行过程中，因争夺资源而造成的一种互相等待的现象，若无外力干涉调用资源的进程将无法推进下去。如果系统资源充足，进程的资源请求都能得到满足，死锁出现的可能性就很低，否则就会因争夺有限的资源而陷入死锁。

导致死锁的原因主要包括：(1)、系统资源不足；(2)进程运行推进的顺序不合适；(3)资源分配不当等。

基于前述背景技术所介绍，为了解决在多屏协同场景下资源冲突导致的设备死机或重启，致使多屏协同中断的问题，本申请实施例提供了一种多屏协同中断的处理方法，该方法通过多屏协同场景下在框架侧增加接口监听资源调用，使调用者能及时感知到异常，并终止异常事件，避免引发设备死机或重启等，提升用户的使用体验。

示例性的，如图1所示，为本申请实施例提供的一种多屏协同中断的处理方法适用的系统架构的示意图。该系统架构包括第一电子设备100、第二电子设备200。

其中，第一电子设备100和第二电子设备200具体可以为手机、平板电脑、智能电视、笔记本电脑、超级移动个人计算机(ultra-mobile personal computer，UMPC)、手持计算机、上网本、个人数字助理(personal digital assistant，PDA)、可穿戴设备、车载设备、虚拟现实设备等具有显示功能的设备，本申请实施例对此不作任何限制。

例如，第一电子设备100可以是手机，第二电子设备200可以是笔记本电脑；或者，第一电子设备100和第二电子设备200可以均为手机；或者，第一电子设备100和第二电子设备200可以均为笔记本电脑；或者，第一电子设备100可以为手机或平板电脑，第二电子设备200可以为笔记本电脑或智能电视等等。

在一些实施例中，第一电子设备100可以作为源设备，第二电子设备200可以作为第一电子设备101的目的设备。第一电子设备100可以将第一电子设备100中的内容(例如应用、图片、视频或者文档等)投射至电子设备200的显示屏中进行显示，实现跨屏显示功能。

以第一电子设备100是手机、第二电子设备200是笔记本电脑为例(如图1所示)，在一些场景下，用户可以将手机中的一个或多个屏幕内容到笔记本电脑(也即目的设备)中显示。

以下结合附图，继续以第一电子设备是手机，第二电子设备是笔记本电脑为例，对多屏协同的过程进行示例性介绍。

如图2所示，笔记本电脑(即第二电子设备)上可以设置有电子标签201，电子标签也可以称为近场通信(near filed communication，NFC)标签。电子标签201中一般设置有线圈，在笔记本电脑出厂时可以预先向电子标签201的线圈中写入该笔记本电脑的设备信息。该设备信息例如可以包括笔记本电脑的名称、蓝牙媒体访问控制(media accesscontrol，MAC)地址等等。或者，也可以在笔记本电脑中设置NFC芯片，该NFC芯片可以存储有笔记本电脑的设备信息。

在一些实施例中，当用户需要将手机中的应用投射到笔记本电脑中显示时，可以开启手机NFC功能，将手机靠近或接触笔记本电脑上的电子标签201(或NFC芯片)。这样，手机在与电子标签201(或NFC芯片)彼此靠近的情况下，可通过发射近场信号从电子标签201(或NFC芯片)中读取笔记本电脑的设备信息。进而，手机可以根据笔记本电脑的设备信息与笔记本电脑建立无线通信连接。例如，该无线通信连接具体可以为蓝牙连接、无线保真(wireless fidelity，Wi-Fi)连接，或者Wi-Fi点对点(peer to peer，P2P)连接等，本申请实施例对此不作限定。

需要说明的是，手机除了通过触碰笔记本电脑上电子标签201的方式与笔记本建立无线通信连接外，本领域技术人员还可以设计其他方式建立手机与笔记本电脑之间的通信连接，本申请实施例对此不作限定。例如，用户可以使用数据线连接手机与笔记本电脑，从而建立手机与笔记本电脑之间的通信连接。又例如，手机可以通过扫描笔记本电脑上显示的二维码或者条形码获取笔记本电脑的设备信息，并与笔记本电脑建立无线通信连接。

示例性的，如图3所示，手机与笔记本电脑建立连接后，该笔记本电脑上可以显示与手机当前显示界面一致的投屏窗口301。之后，用户可以在该投屏窗口输入操作，实现笔记本电脑与手机的协同工作。

需要说明的是，当用户在笔记本电脑的投屏窗口中输入操作时，手机可以处于亮屏状态(包括灭屏显示状态和开锁下的亮屏状态)或者灭屏状态，本申请实施例对此不作限定。

示例性的，如图4所示，为本申请实施例提供的一种第一电子设备100的结构示意图。

第一电子设备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等。

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

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

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

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

应用程序框架层为应用程序层的应用程序提供应用编程接口(applicationprogramming interface，API)和编程框架。应用程序框架层包括一些预先定义的函数。如图5所示，应用程序框架层可以包括窗口管理器，内容提供器，视图系统，电话管理器，资源管理器，通知管理器，视图系统，NFC服务等。

其中，当第一电子设备100(如手机)打开NFC功能后可以开始运行NFC服务，当第一电子设备与第二电子设备200(如笔记本电脑)的电子标签或NFC芯片靠近或接触时，NFC服务可以调用内核层的NFC驱动读取电子标签中的信息，并基于该信息与第二电子设备200建立无线通信连接。

窗口管理器用于管理窗口程序。窗口管理器可以获取显示屏大小，判断是否有状态栏，锁定屏幕，截取屏幕等。

内容提供器用来存放和获取数据，并使这些数据可以被应用程序访问。所述数据可以包括视频，图像，音频，拨打和接听的电话，浏览历史和书签，电话簿等。

视图系统包括可视控件，例如显示文字的控件，显示图片的控件等。视图系统可用于构建应用程序。显示界面可以由一个或多个视图组成的。例如，包括短信通知图标的显示界面，可以包括显示文字的视图以及显示图片的视图。

电话管理器用于提供第一电子设备100的通信功能。例如通话状态的管理(包括接通，挂断等)。

资源管理器为应用程序提供各种资源，比如本地化字符串，图标，图片，布局文件，视频文件等等。

通知管理器使应用程序可以在状态栏中显示通知信息，可以用于传达告知类型的消息，可以短暂停留后自动消失，无需用户交互。比如通知管理器被用于告知下载完成，消息提醒等。通知管理器还可以是以图表或者滚动条文本形式出现在系统顶部状态栏的通知，例如后台运行的应用程序的通知，还可以是以对话窗口形式出现在屏幕上的通知。例如在状态栏提示文本信息，发出提示音，终端振动，指示灯闪烁等。

Android Runtime包括核心库和虚拟机。Android runtime负责安卓系统的调度和管理。

核心库包含两部分：一部分是java语言需要调用的功能函数，另一部分是安卓的核心库。

应用程序层和应用程序框架层运行在虚拟机中。虚拟机将应用程序层和应用程序框架层的java文件执行为二进制文件。虚拟机用于执行障碍物生命周期的管理，堆栈管理，线程管理，安全和异常的管理，以及垃圾回收等功能。

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

表面管理器用于对显示子系统进行管理，并且为多个应用程序提供了2D和3D图层的融合。

媒体库支持多种常用的音频，视频格式回放和录制，以及静态图像文件等。媒体库可以支持多种音视频编码格式，例如:MPEG4，H.264，MP3，AAC，AMR，JPG，PNG等。

三维图形处理库用于实现三维图形绘图，图像渲染，合成，和图层处理等。

2D图形引擎是2D绘图的绘图引擎。

SurfaceFlinger用于对显示子系统进行管理，并且为多个应用程序提供2D和3D图层的融合。

内核层是硬件和软件之间的层。内核层至少包含显示驱动，摄像头驱动，硬件组合抽象层(HWcomposer)，音频驱动，传感器驱动等。

示例性的，如图6所示，为本申请实施例提供的一种多屏协同的示意图。

在一些实施例中，当手机与笔记本电脑开启多屏协同功能后，手机可以通过与笔记本电脑之间的通信链路将当前显示的界面投射至笔记本电脑，此时笔记本电脑的显示界面上可以同步显示手机侧的投射界面。

参见图6，笔记本电脑显示的视频播放窗口是手机投射过来的显示窗口，该窗口例如包括视频播放画面、视频控件(如快进控件、播放/暂停播放控件、下一个控件等)。可选地，该投屏窗口还可以在视频播放画面上方显示的操作栏中的控件，例如最小化图标601、最大化图标602和关闭图标603等。

在一些实施例中，用户可以通过在笔记本电脑的操作栏输入特定操作(如点击暂停播放控件的操作)。响应于暂停播放的操作，笔记本电脑会通过与手机之间的通信链路向手机发送反向控制命令，该反向控制命令可以用于指示暂停视频播放。手机接收到该反向控制命令后，根据反向控制命令确定对应的配置参数(如生成暂停视频画面的绘图命令，或者生成缓存队列轮转的暂停命令等)，该配置参数用于生成对应的界面(如视频暂停的界面)，手机可以将配置参数压入缓存队列，并且将缓存队列发送至编码器(包括软件媒体编码器和硬件媒体编码器)，编码器对新的投射界面的绘图数据进行编码(如压缩数据量，以及按照手机与笔记本电脑之间的通信协议编码)，之后通过通信链路将编码后的数据发送至笔记本电脑。笔记本电脑根据接收到的绘图数据生成对应的投屏窗口，实现视频的暂停播放。

示例性的，如图7所示，为本申请实施例提供的一种多屏协同下的数据流向的示意图。

本实施例仍以图6所示的手机和笔记本电脑协同播放视频画面为例。多屏协同流程如图7所示，主要包括以下过程：(1)手机与笔记本电脑多屏协同，手机侧通过生成一个虚拟屏，即通过SurfaceFlinger创建一个surface，并将实时的每一帧数据送入编码器，编码器拿到数据编码后送协议进行传输；(2)笔记本电脑侧拿到数据后进行解码，并显示在笔记本电脑侧协同窗口内，可以通过控制协同窗口的内容反向控制手机侧的屏幕，手机侧屏幕识别到反控命令后实时修改画面内容，并再次通过SurfaceFlinger送入编码器送编码；(3)整个过程形成一个闭环状态，中间存在着资源的争夺，务必会出现死锁情况的出现，在上代产品中，即遇到平板侧控制手机侧导致手机重启，其中根本原因是由于编码器内部出现了死锁，导致SurfaceFlinger等待超过预设的容忍时间(如10秒)从而手机软重启。

以下继续结合图6和图7，对手机与笔记本电脑多屏协同的过程进行更加具体的介绍。

在一些实施例中，手机向笔记本电脑投射视频播放画面的过程可以包括：手机和笔记本电脑建立多屏协同的通信链路之后，当手机接收用户输入的视频播放操作(如包括打开视频应用，选择要播放的视频等操作)时，可以响应于该视频播放操作播放对应的视频画面，并且手机可以为该视频应用分配一个对应的缓存队列(buffer queue)，该缓存队列可以用于缓存视频应用运行时产生的数据，如绘图命令OpenGL等。视频应用可以实时生成这些绘图命令，并将这些绘图命令压入对应的缓存队列中保存。之后，缓存队列中的绘图命令可以被发送至系统库的SurfaceFlinger，SurfaceFlinger通过执行绘图命令可绘制出对应的图层和控件(如视频应用的视频画面)，并对这些图层和控件进行合成，生成虚拟屏幕(virtual display)，得到投屏界面对应的帧数据。示例性的，该帧数据可以包括投屏界面的界面配置信息，例如投屏界面对应的应用的开发数据/应用数据配置，投屏界面的边界信息、转向，投屏界面上的图标信息，投屏界面上的文字，图标位置、大小和颜色，文字的显示位置、大小和颜色等等。

需要说明的是，本申请实施例中的虚拟屏幕是指在手机后台运行的屏幕，不直接在前台显示给用户。在一些实施例中，SurfaceFlinger生成虚拟屏幕的过程可以包括：SurfaceFlinger可以在活动管理器中创建虚拟屏幕的工作区堆栈(Virtual screen_workspace_stack)，虚拟屏幕的工作区堆栈的编号为5(stack_id＝5)，这样手机可以基于堆栈中的参数利用绘图命令生成对应的虚拟屏幕。

在一些实施例中，手机还包括媒体编解码器(media codec)，该media codec位于媒体框架层，用于接收SurfaceFlinger输出的帧数据，并对帧数据进行编码和压缩。为便于区分，这里将media codec处理之后的数据称为第一编码数据。其中，经过media codec编码和压缩的第一编码数据的数据量相比于未经过编码和压缩的帧数据可大大降低。

在一些实施例中，手机还包括硬件媒体编解码器(media Hardware codec，mediahw codec)，该media hw codec位于硬件抽象层(hardware abstraction layer，HAL)，可以用于基于手机与笔记本电脑之间的通信协议/编码协议对第一编码数据进行进一步编码，获取第二编码数据。需要说明的是，利用media hw codec对第一编码数据进行编码是为了使得数据能够以符合通信协议规定的编码方式传输数据，并且能够使笔记本电脑成功地读取的第二编码数据。

之后，手机可以将第二编码数据通过通信链路发送至笔记本电脑。笔记本电脑可以对第二编码数据进行解码，根据解码后的绘图命令绘制对应的投屏窗口中的内容，以在笔记本电脑中同步显示手机侧的屏幕内容，实现手机和笔记本电脑的多屏协同。

需要说明的是，SurfaceFlinger将绘图命令压入缓存队列发送至视频编码器时，需要查询是否有可用的缓存队列(或可用帧)。当存在可用帧时，SurfaceFlinger才可以成功调用queuebuffer，进而将绘图命令传输至视频编码器进行编码；当SurfaceFlinger长时间(如超过预设时长)未获取是否有可用的缓存队列的反馈结果时，可能发生了编码器内部死锁，此时容易导致手机重启。其中，SurfaceFlinger查询是否存在可用缓存队列的过程将在下文的实施例中进行具体介绍，此处暂时不详述。

在一些实施例中，当用户在笔记本电脑上针对投屏窗口的某一控件输入特定操作(如通过点击暂停控件输入暂停操作)时，笔记本电脑可以响应该暂停操作，向手机发送反向控制命令，该反向控制命令用于指示暂停视频播放。手机接收到该反向控制命令之后，媒体框架层(或称媒体框架模块)通过暂停编码器(suspend video encoder)调用suspendvideo函数，执行视频暂停的流程。具体地，媒体框架层响应于该反向控制命令的具体指示生成对应的参数，并基于参数配置暂停视频播放状态的信息，获取该状态对应的配置信息。可选地，完成信息配置之后，手机可以通过SurfaceFlinger根据配置信息执行对应的操作(如视频暂停操作)。在该过程中，手机的暂停编码器会调用公用锁。之后，手机在基于配置信息生成暂停的屏幕内容后，可以经过通信链路将该屏幕内容的数据发送至笔记本电脑，使得笔记本电脑得以显示暂停的视频播放画面。

综上介绍，在实际应用中，手机基于反向控制命令生成对应的配置信息，并将基于配置信息执行对应的操作(如视频暂停)的过程中，需要通过暂停编码器对暂停数据进行编码；而手机基于多屏协同协议实时向笔记本电脑投屏界面的过程中，也需要用到编码器(如media codec和media hw codec)对绘图命令等数据进行编码，因而会存在不同调用者对编码资源的争夺。目前，调用者通常在调用编码资源之前，需要首先调用公用锁，资源管理器根据公用锁的调用状态将编码资源分配给对应的调用者，并在分配之后将该编码资源的状态标识为忙，这样已经分配的编码资源就不能被再次分配；当编码资源被释放后，资源管理器会将释放的编码资源标识为空闲，重新参与资源分配。

然而，当编码资源已经被分配给其它调用者(如执行反向控制命令的暂停视频编码器)时，会存在当前调用者发起编码资源调用请求却长时间得不到回应的问题，也即存在编码资源调用冲突导致编码器死锁的问题，此类问题容易导致手机通常重启，会严重影响用户的使用体验。

以下结合附图，对多屏协同过程中编码资源调用冲突的过程进行示例性的介绍。

示例性的，如图8所示，为本申请实施例提供的一种多屏协同下资源冲突的示意图。

本申请实施例仍以上文图6实施例中利用多屏协同功能将手机中的视频投射到笔记本电脑中为例，当用户在笔记本电脑上针对投射的视频播放窗口输入暂停操作时(例如用户点击图6界面上的暂停控件)，响应于该暂停操作，笔记本电脑通过与手机之间的通信链路将暂停命令发送给手机。手机的通信模块接收到暂停命令后可以将其传输至媒体框架层。

之后，媒体框架层中的暂停视频编码器(suspend video encoder)根据该暂停命令向媒体编解码器(media codec)下发参数设置命令(如set parameters(params))，指示媒体编解码器针对暂停命令生成对应的参数。示例性的，媒体编码器生成的参数例如为Media Codec::on set parameters。这里的参数例如可以包括帧率(frames per second，FPS)、分辨率等，此处不作限定。

媒体框架层可以根据媒体编解码器生成的参数进行参数配置。具体地，媒体编码器生成参数后可以向参数配置模块(CCodec)发送参数配置命令(如对应图8所示的mCodec_>signalSetParameters(params))，该参数配置命令例如为signal set parameters。参数配置模块根据该参数配置命令以及获取的参数进行参数配置，其中，该参数配置例如包括对视频暂停、缓存队列轮转暂停等参数进行整合。示例性的，参数配置模块例如可以通过(void)config_>minputSurface_>configure(config_>mlSConfig)GraphicBufferSourceWrapper:publi cInputSurfaceWrapper命令进行视频暂停的参数配置，获得的配置信息例如对应于图8所示的Configure(Config&config))，该配置信息可以用于手机执行反向控制命令指示的操作(如视频暂停操作)。此外，参数配置模块还可以调用相应的接口(如Source set suspended)对轮转中的缓存队列暂停，配置信息还可以包括指示缓存队列暂停的信息(如config.msuspendAtUs)。

需要说明的是，媒体框架层向媒体编解码器下发参数设置命令的过程可以在媒体框架层的Java层执行。之后，媒体编解码器(MediaCodec)可以通过JNI层将生成的参数从Java层转换至C++层，最终获取配置信息。

在一些实施例中，媒体框架层基于配置信息在执行暂停视频操作的过程中，需要调用公用锁(Mutex::Autolock autolock(mMutex))。成功调用公用锁之后，得以利用对应的编码资源对配置参数进行编码。此时公用锁的作用在于当被调用后能够将对应的编码资源标识为忙，从而使得其他进程无法再次调用该编码资源。

此时，由于手机显示模块(SurfaceFlinger)仍在实时生成投屏界面，在向笔记本电脑投射该画面的过程中也需要用到编码资源对绘图数据进行编码，也即同样需要调用公共锁，可能会产生编码资源调用冲突。

示例性的，手机投屏界面调用编码资源的过程可以包括：显示模块(SurfaceFlinger)作为缓存队列生产者(buffer queue producer)在产生投屏界面的屏幕内容的过程中，需要查询是否有可用的缓存队列以压入该界面的相关数据(如绘图数据)，该查询方式例如可以通过调用可用帧监听函数(frame available listener)向bufferqueue查询知否存在可用缓存队列；buffer queue作为缓存队列的代理消费者，响应于该查询信息向graphic buffer source查询是否存在可用缓存队列(具体可以查询是否存在可用缓存队列可用帧)。Graphic buffer source在获取查询信息后，可以响应于该查询信息调用公用锁。若成功获取公用锁，且graphic buffer source查询后确定存在可用帧，那么graphic buffer source会向该缓存队列分配可用帧；缓存队列消费接口监听到可用帧之后，可以调用该可用帧以发送对应的缓存队列(如图8所示的submit_buffer)。

在实际应用中，如果执行视频暂停命令的过程调用公用锁时，该公用锁已经在SurfaceFlinger生成缓存队列的过程中被调用，那么超过预设时长之后，媒体框架层(暂停视频编码器)无法获得响应(对应图8所示的返回值)，就会发生流程卡死，进而无法基于反向控制命令执行暂停视频的操作(也即暂停视频的流程被卡死)。此时由于发生编码资源冲突，编码器内部死锁，容易导致手机侧重启。

或者，在实际应用中，如果在SurfaceFlinger需要调用公共锁时，该公共锁已经被媒体框架层(暂停视频编码器)调用，那么SurfaceFlinger无法在预设时长获取编码资源，也会发生流程卡死，手机侧重启，严重影响用户的正常使用。

针对上述问题，本申请实施例在多屏协同场景下，通过在框架侧增加监听接口调用监听，每当接口被调用，即开启监听，当监听到存在编码资源异常调用或持有时，可以通过上层应用向用户提醒或者采取预设方式自动终止多屏协同进程，从而避免由于编码资源冲突导致的设备重启问题，提升用户的使用体验。

显示模块(SurfaceFlinger)调用queuebuffer函数往编码器里面送数据进行编码，buffer队列收到queuebuffer的调用后执行on frame available函数调用，通知媒体框架模块需要buffer并询问是否有buffer可用，这一层调用过程中会先获取一把锁(或称公用锁、锁函数)，如果获取不到，那么buffer队列在此处等待锁释放。本申请实施例中的监听算法主要在这里开始进行监控，监控过程包括：首先创建一个图形缓存监听模块(graphicbuffer watch)的watch对象，并通过容忍时间设置模块(setDeadline)去记录一个无持锁状态；如果拿到锁了，也会通过setDeadline去记录当前为持锁状态。初始化时会创建一个AMessage对象，这里可以使用谷歌中message机制，通过setDeadline设定一个post时延，也即delayeTime，这里的计时器会等待设定的时延，当达到这个容忍时间后，会post一条消息，这条消息会在dealWatching函数内被捕获，捕获后会去check当前的状态是否是正常的，如果当前状态为无持锁状态，则判定当前状态为异常，如果当前状态为持锁状态，那么认为流程中的超时是正常的。当前buffer队列如果等锁时间超过预设时长(如8s)，那么可以将当前状态和持锁情况打印，中止当前进程，防止发生手机重启。此算法在多屏协同成功后即刻开始监听。

示例性的，如图9所示，为本申请实施例提供的一种多屏协同中断的处理方法的示意图。该处理方法的流程可以应用于第一电子设备(如上文实施例中的手机)，该方法可以包括以下步骤：

S901，显示模块向缓存队列管理模块(buffer queue)查询可用帧。

在一些实施例中，显示模块(SurfaceFlinger)可以调用queuebuffer函数指示缓存队列管理模块(buffer queue)查询是否存在缓存队列的可用帧。

S902，响应于可用帧的查询请求，缓存队列管理模块开启可用帧的查询流程。

具体地，缓存队列管理模块响应于缓存队列查询请求，可以调用on frameavailable函数开启缓存队列可用帧的查询流程。

S903，缓存队列管理模块向媒体框架模块(graphic buffer source)发送可用帧的查询请求。

在一些实施例中，缓存队列管理模块通过调用on frame available函数向媒体框架模块通知当前需要缓存队列的可用帧，并且指示媒体框架模块查询是否存在可用帧。缓存队列管理模块还可以监听媒体框架模块对可用帧的查询结果。

其中，媒体框架模块(graphic buffer source)属于媒体框架层，可以用于管理和分配缓存队列对应的可用帧。在本申请的其它实施例中，媒体框架模块还可以描述为图形缓存资源模块或者图形缓存资源管理模块。

S904，媒体框架模块查询可用帧。

在一些实施例中，当媒体框架模块接收到可用帧的查询请求之后，可以调用onframe available函数开启对可用帧的查询流程。

在一些实施例中，在查询可用帧的过程中，媒体框架模块需要先获取公用锁。此时，媒体框架模块可以先对公用锁的调用状态进行查询。公用锁的调用状态可以包括：公用锁处于被调用状态，或者公用锁处于释放状态。其中，公用锁处于释放状态是指该公用锁当前未被其他调用者调用，处于可被调用的状态。

其中，当确定公用锁当前处于释放状态(也即可以被媒体框架模块调用)时，媒体框架模块可以调用该公用锁，并基于可用帧的查询结果(存在可用帧或者不存在可用帧)向缓存队列管理模块(buffer queue)响应(如分配缓存队列的可用帧)。当确定公用锁当前处于被调用状态(也即已经被其它调用者调用，媒体框架模块当前无法调用该公用锁)时，可以调用监听接口对函数调用进行监听，从而判断公用锁调用是否超时(也即执行步骤S905)。

值得注意的是，现有流程中，通常未在此处设置监控，一般在调用公用锁时，采用故障注入，在调用处设定sleep函数(如设置睡眠10秒)，在源设备和目的设备建立多屏协同后，在未调用到公用锁时，调用该睡眠函数，如睡眠10秒后，手机自动重启。在本申请实施例提供的多屏协同终端处理的方法中，在框架侧设置监听接口，源设备和目的设备协同成功后，触发监听算法，当未调用到公用锁时，调用到监听算法，而后开始睡眠，算法开始监听调用者的调用时间，达到容忍时间点后，释放资源，上报异常，手机无重启发生。

与现有流程不同，在本申请实施例提供的多屏协同终端处理的方法中，如果在SurfaceFlinger调用queuebuffer的过程中，确定公用锁被其他调用者持有时，媒体框架模块会调用监听接口对函数调用进行监听，并根据函数调用时长是否超过容忍时间确定公用锁调用是否超时，避免由于公用锁被其他调用者持有，导致的SurfaceFlinger调用queuebuffer不成功从而使设备重启的问题。

在一些实施例中，该容忍时间可以在进行超时检测之前预先设置。比如，当媒体框架模块接收到可用帧的查询请求时，可以向容忍时间设置模块(setDeadline)发送第一调用信息(dispatch)，使得该setDeadline设置对应的容忍时间。又比如，当媒体框架模块确定公用锁处于被调用状态时，可以向容忍时间设置模块(setDeadline)发送第一调用信息(dispatch)，使得该setDeadline设置对应的容忍时间，并记录当前为第一状态(未持有公用锁的状态)等等。本申请实施例对媒体框架模块指示setDeadline设置对应的容忍时间的具体执行时间不做限定。

S905，媒体框架模块向图形缓存监听模块(graphic buffer watch)发送监听指示消息(new watch)。

其中，该监听指示消息(new watch)用于指示graphic buffer watch监听函数调用的时长是否超过容忍时间。该容忍时间可以根据需要灵活设置，本申请实施例对此不作限定。

需要说明的是，这里对于公用锁是否已经被其它调用者调用的评判，可以利用本流程中的函数(如queuebuffer函数)调用的时长是否超过预设时长来表征。举例来说，比如SurfaceFlinger调用的如queuebuffer函数当前需要一把锁，那么从开始需要这把锁开始计时，到拿到这把锁结束为止，判断这段时间是否超过对应的容忍时间，如果超时容忍时间也即说明调用锁的时间超时。换言之，这里的监听函数超时即拿锁超时。

具体来说，当公用锁已经被其它调用者调用的情况下，媒体框架模块无法及时调用公用锁，进而无法及时向显示模块分配可用帧，此时该on frame available函数一直处于被显示模块调用的状态，当on frame available函数的调用时长超过预设时长时也即调用锁的时间超时。或者，当公用锁未被其它调用者调用的情况下，graphic buffer source可以及时调用该公用锁，并且向分配可用帧，此时显示模块无需一直调用该on frameavailable函数，on frame available函数的调用时长在预设时长之内，也即说明在预设时长内成功调用公用锁。

S906，图形缓存监听模块响应于该监听指示消息，开启监听函数调用是否超时的流程。

在一些实施例中，graphic buffer watch接收到监听指示消息后，可以调用计时器对函数调用时间进行监听。当计时器达到容忍时间，该函数仍处于被调用状态时，graphic buffer watch可以确定函数调用超时。而当计时器达到预设时长，函数不再处于被调用状态时，graphic buffer watch可以确定函数调用未超时。

示例性的，本申请实施例中监听函数调用是否超过预设时长的过程可以包括步骤S907：图形缓存监听模块向计时器发送计时指示消息。

其中，该计时指示消息可以为msg_>post(delayTime)，用于指示计时器设置容忍时长(delay time)，并指示计时器判断当前时间是否超过预设时长，也即判断now time>delay time是否成立。

在一些实施例中，如果当前时间未超过容忍时间(也即对now time>delay time的判断结果为否(No))，计时器保持等待状态(wait)。如果当前时间超过容忍时长(也即对nowtime>delay time的判断结果为是(Yes))，计时器可以向AMessage模块发送超时的通知消息(YES)，该通知消息可以指示AMessage模块定时(如5s之后)向setdealine模块发送流程检查消息(check)。

S908，图形缓存监听模块向媒体框架模块发送监听反馈消息。

这里以当前时间超过容忍时间的情形为例，此时，该监听反馈消息可以向graphicbuffer source指示函数调用超时的监听结果。

S909，媒体框架模块响应于该监听反馈消息向预设时长设置模块发送第二调度信息(dispatch)。

其中，该第二调度信息用于改变setDeadline模块之前设置的状态，比如用于将未持锁状态更改为持锁状态。需要说明的是，该第二调度信息可以是在容忍时间内调用到公用锁的情况下，媒体框架模块向容忍时间设置模块发送的，也即在函数调用未超时的正常流程中，媒体框架模块拿到锁后触发的该第二调度信息的发送。因而，当在未成功调用到公用锁的情形下，本实施例的流程中不会发生该步骤以及下述步骤S910。

S910，容忍时间设置模块响应于调度信息设置新的状态。

其中，该新的状态也可以被描述为第二状态，可以指持有公用锁的状态。

在一些实施例中，当setDeadline模块接收到该第二调度信息之后，可以响应于该第二调度信息对之前设置的状态进行更改，如通过设置新的容忍时间(set nowtime)改变之前设置的状态。

需要说明的是，本申请实施例以下主要以异常超时情形为例进行介绍，而在异常超时流程中步骤S909和步骤S910是不存在的(因为未拿到公用锁，无法触发该调用)。这里之所以在图9中示出步骤S909和步骤S910是为了能更加清楚地解释正常超时或异常超时的检查过程。

S911，AMessage模块向容忍时间设置模块发送流程检查信息。

其中，该流程检查信息用于指示setDeadline模块执行区分正常超时和异常超时的操作。

需要说明的是，在一些情形下，虽然会有超时消息的发送，但该超时消息指示的是正常流程中的超时。因而，需要进一步判断这里的超时是正常超时或者异常超时，如果是正常超时，那么setDeadline模块就需要给正常流程中的超时一个绿灯。

正常超时的情形可以有多种，比如在一种可能的情形下：媒体框架模块在容忍时间之前调用到了公用锁，但在执行查询可用帧的情况的时候，可用帧情况获取得慢，或者在等待获取可用帧的时间过长，此类情形导致的超时属于正常超时。

异常超时则可以是指公用锁长时间被其它调用者持有，媒体框架模块无法通过正常流程拿到公用锁的情况。

S912，容忍时间设置模块响应于该第二调度信息，检测到该超时为异常超时。

示例性的，setDeadline模块检查正常超时或异常超时的过程可以包括：setDeadline模块可以判断在接收到AMessage模块发送的流程检查信息时，是否已经收到了第二调用信息；如果此时已经收到了第二调用信息，说明在得到超时的监听结果之前，graphic buffer source已经调用到了公用锁，并在获得公共锁的触发下发送了第二调用信息(第二次设置状态)，此时为正常超时；相反地，如果此时未接收到第二调用信息，说明graphic buffer source在超时之前未调用到公用锁，该公用锁被其它调用者持有，而且调用者持有了资源后，没有执行正常动作，此时为异常超时。

这里以异常超时为例(也即容忍时间设置模块在接收到流程检查信息时，未接收到第二调用信息)进行说明。当确定该超时为异常超时时，可以执行以下步骤：

步骤S913，容忍时间设置模块向事项监听模块发送第三调度信息。

在一些实施例中，当确定该超时为异常超时的时候，可以通过终止当前的多屏协同进程以避免设备重启。具体地，setDeadline模块可以向事项监听模块(deal watching)发送第三调度信息(dispatch)，该第三调度信息可以用于指示事项监听模块执行中止多屏协同进程的操作。

在一些实施例中，事项监听模块还可以响应于第三调度信息可以记录当前多屏协同进程中涉及的进程日志、当前各个应用程序调用公用锁的状态等，以用于后续分析。

S914，事项监听模块相应于调度信息执行杀进程。

在一些实施例中，事项监听模块可以指示进程查杀模块(图9未示出)执行杀进程，终止多屏协同的相关进程。

可选地，本实施例还可以通过向用户提示当前多屏协同出现异常，使用户手动关闭多屏协同。在提示用户手动终止多屏协同的场景下，本流程可以执行步骤S916：

步骤S915，事项监听模块向显示模块发送进程终止提示信息。

其中，进程终止提示信息可以用于提示当前进程运行异常，需要终止多屏协同进程。

在一些实施例中，显示模块接收到进程终止提示信息后，可以通过显示屏幕向用户提示多屏协同需要终止的提示信息。之后，用户可以根据该提示信息，手动终止多屏协同，如关闭多屏协同功能等。

S916，图形换缓存监听模块向预设时长设置模块发送预设时长解除指示信息。

在一些实施例中，在函数调用时长未超过预设时长，图形缓存监听模块成功调用公用锁时，图形缓存监听模块可以向预设时长设置模块发送该预设时长解除指示信息，监听释放。或者，当确定终止多屏协同时，该图形缓存监听模块也可以向预设时长设置模块发送该预设时长解除指示信息，监听释放。

根据本申请实施例提供的多屏协同中断的处理方法，通过在多屏协同的媒体框架侧设置监听接口，对调用者发起的目标资源调用进行监听，当在达到容忍时间时，调用者仍未获取对应的目标资源时，可以通知调用者采取释放进程等处理措施，保证电子设备的运行，避免电子设备由于资源调用冲突导致同屏协同场景下发生设备重启或者死机的问题，提升用户的使用体验。

示例性的，如图10所示，为本申请实施例提供的另一种多屏协同中断的处理方法的示意性流程图。该流程的执行主体可以是多屏协同中的源设备(如对应上文中的第一电子设备)，该源设备与目的设备建立有用于多屏协同的通信连接。具体可以包括以下步骤：

S1001，调用第一函数，该第一函数的调用用于向媒体编解码器发送待编码的投屏数据，该投屏数据用于在目的设备上同步显示所述源设备的投屏窗口。

其中，这里的第一函数可以对应于上文中SurfaceFlinger调用的queuebuffer函数。

S1002，响应于第一函数的调用，调用第二函数，该第二函数的调用用于触发缓存队列的可用帧的查询流程，该缓存队列用于源设备压入所述投屏数据。

在一些实施例中，源设备中的缓存队列管理模块(buffer queue)接收到SurfaceFlinger对queuebuffer函数的调用后，可以执行onFrameAvailable函数的调用，通知媒体框架模块(graphicaBufferSource)当前需要缓存队列的可用帧，并且指示媒体框架模块查询是否存在缓存队列的可用帧。

S1003，响应于第二函数的调用，监听第一函数的调用时间是否超过预设的容忍时间。

需要说明的是，在进行缓存队列可用帧的查询时，需要下获取公用锁，如果获取不到公用锁，那么缓存队列在此处等待公用锁释放。本申请实施例的方法主要在这里开始进行监控。

在一些实施例中，响应于第二函数的调用，源设备通过媒体框架模块调用监听接口，对第一函数的调用时间进行监听。该过程可以包括：缓存队列管理模块执行onFrameAvailable函数的调用，开启可用的帧缓存序列的查询流程(可对应上述步骤S902)，指示媒体框架模块(graphic buffer source)查询是否存缓存队列的可用帧，并对查询结果进行监听(可对应上述步骤S903)；媒体框架模块调用on frame available函数执行该可用的帧缓存序列的查询，在该查询流程中，媒体框架模块会调用监听接口(graphicBufferWatch)对第一函数的调用时间进行监听。

其中，该监听的具体实现过程的可以参见上述实施例9中相应的介绍，此处不再详述。

在一些实施例中，在开始监听时或者在监听之前，会创建一个graphiaBufferWatch的watch对象，并通过容忍时间设置模块(setDeadline)记录无持锁状态。之后，如果成功调用到公用锁，该setDeadline会将无持锁状态更改为持锁状态。

S1004，当所述第一函数的调用时间超过预设的容忍时间时，终止所述多屏协同的进程。

其中，预设的容忍时间可以为对第一函数的调用时间进行监听之前设置的。具体地，可以在初始化是创建一个AMessage对象(可使用谷歌中的message机制)，通过setDeadline设定一个post时延，也即容忍时间(delay time)。之后计时器会等待该设定的时延，判断当前时间是否达到容忍时间。当达到容忍时间时，确定第一函数的调用时间超过预设的容忍时间时。

在一些实施例中，当所述第一函数的调用时间超过预设的容忍时间时，终止多屏协同的进程，具体包括：当第一函数的调用时间超过预设的容忍时间时，检查超时属于异常超时或者属于正常超时；当超时属于异常超时时，终止多屏协同的进程，异常超时为在缓存队列的可用帧的查询流程中，由于未调用到公用锁导致的超时。

需要说明的是，本申请实施例提供的多屏协同中断的处理方法通过监听函数调用是否超时来判断调用公用锁(或称所函数)是否超时。其中，调用公用锁超时的原因可能是存在其他调用者一直持有该公用锁。比如，源设备在基于目的设备发送的反向控制命令调用对应的函数(如上述实施例9中的suspend video)执行对应操作的过程中，也需要调用公用锁，如果该公用锁在预设的容忍时间内一直未被释放，可能导致SurfaceFlinger调用queueBuffer的过程中无法成功调用公用锁，设备发生死锁，进而产生设备重启等严重问题。

由于函数调用超时并不能完全等同于公用锁调用超时，比如在一些情形下，函数调用超时可以发生在公用锁被正常调用后，由于查询可用的帧缓存队列时间过长导致的，因而，在一些实施例中，当监听到函数调动超时后，还需要进一步检查该超时属于正常超时还是异常超时。

具体地，当监听结果指示调用时间超过预设的容忍时间时，检查调用时间超过预设的容忍时间属于异常超时或者属于正常超时；当调用时间超过预设的容忍时间属于异常超时时，终止多屏协同的进程，该异常超时为在流程中由于未调用到锁函数导致的超时。

在一些实施例中，检查调用时间超过预设的容忍时间属于异常超时或者属于正常超时的过程可以包括：判断在执行检查之前是否已对容忍时间进行重新设置；若在执行所述检查之前已对容忍时间进行重新设置，则确定调用时间超过预设的容忍时间属于异常超时。

在一些实施例中，当所述第一函数的调用时间超过预设的容忍时间时，检查超时属于异常超时或者属于正常超时，具体包括：当第一函数的调用时间超过预设的容忍时间时，检查第一状态是否已更改为第二状态，第二状态用于指示当前持有所述公用锁；其中，若第一状态已更改为第二状态，则确定所述超时属于正常超时；若第一状态未更改为第二状态，则确定超时属于异常超时。

计时器判断当前时间达到容忍时间后，会通过AMessage对象post一条检查指示信息，该检查指示信息可以在dealwatching函数内被捕获，捕获后会check检查超时是正常超时还是异常超时。

在一些实施例中，当超时属于异常超时时，显示第一提示信息，第一提示信息用于指示用户手动终止所述多屏协同的进程；或者，当超时属于异常超时时，自动终止多屏协同的进程。此外，当超时属于异常超时时，媒体框架模块还可以向第一函数的调用者发送异常反馈信息，该异常反馈信息用于指示公用锁调用超时。

在一些实施例中，源设备可以接收目的设备发送的反向控制命令，该反向控制命令用于指示源设备控制投屏界面进行目标变化；响应于该反向控制命令，调用第二函数，该第二函数用于触发执行目标操作的流程；响应于第二函数的调用，调用锁函数，并在预设的容忍时间内保持持有所述锁函数。

其中，目标变化可以包括多种，比如：投屏界面最小化，投屏界面最大化，投屏界面滑动，投屏界面中的视频播放暂停等等。

根据本申请实施例提供的多屏协同中断的处理方法，通过在多屏协同的媒体框架侧设置监听接口，对调用者发起的目标资源调用进行监听，当在达到容忍时间时，调用者仍未获取对应的目标资源时，可以通知调用者采取释放进程等处理措施，保证电子设备的运行，避免电子设备由于资源调用冲突导致同屏协同场景下发生设备重启或者死机的问题，提升用户的使用体验。

基于同样的技术构思，本申请实施例还提供了一种通信系统，包括源设备和目的设备，所述源设备与所述目的设备之间建立有用于多屏协同的通信连接，所述目的设备用于接收用户的操作，并向所述源设备发送反向控制命令，所述源设备用于执行上述任一个方法中的一个或多个步骤。

基于同样的技术构思，本申请实施例还提供了一种电子设备，包括：显示器；一个或多个处理器；一个或多个存储器；所述一个或多个存储器存储有一个或多个计算机程序，所述一个或多个计算机程序包括指令，当所述指令被所述一个或多个处理器执行时，使得所述电子设备执行上述任一个方法中的一个或多个步骤。

基于同样的技术构思，本申请实施例还提供了一种计算机可读存储介质，该计算机可读存储介质中存储有指令，当其在计算机或处理器上运行时，使得计算机或处理器执行上述任一个方法中的一个或多个步骤。

基于同样的技术构思，本申请实施例还提供了一种包含指令的计算机程序产品。当该计算机程序产品在计算机或处理器上运行时，使得计算机或处理器执行上述任一个方法中的一个或多个步骤。

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

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

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

Claims (10)

1.一种多屏协同中断的处理方法，其特征在于，应用于源设备，所述源设备与目的设备建立用于多屏协同的通信连接，所述方法包括：

调用第一函数，所述第一函数的调用用于向媒体编解码器发送待编码的投屏数据，所述投屏数据用于在所述目的设备上同步显示所述源设备的投屏窗口；

响应于所述第一函数的调用，调用第二函数，所述第二函数的调用用于触发缓存队列的可用帧的查询流程，所述缓存队列用于所述源设备压入所述投屏数据；

响应于所述第二函数的调用，监听所述第一函数的调用时间是否超过预设的容忍时间；

当所述第一函数的调用时间超过预设的容忍时间时，终止所述多屏协同的进程。

2.根据权利要求1所述的方法，其特征在于，所述当所述第一函数的调用时间超过预设的容忍时间时，终止所述多屏协同的进程，具体包括：

当所述第一函数的调用时间超过预设的容忍时间时，检查超时属于异常超时或者属于正常超时；

当所述超时属于异常超时时，终止所述多屏协同的进程，所述异常超时为在所述缓存队列的可用帧的查询流程中，由于未调用到公用锁导致的超时。

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

响应于所述第二函数的调用，设置第一状态，所述第一状态用于指示当前未持有所述公用锁；

所述当所述第一函数的调用时间超过预设的容忍时间时，检查超时属于异常超时或者属于正常超时，具体包括：

当所述第一函数的调用时间超过预设的容忍时间时，检查所述第一状态是否已更改为第二状态，所述第二状态用于指示当前持有所述公用锁；其中，

若所述第一状态已更改为第二状态，则确定所述超时属于正常超时；

若所述第一状态未更改为第二状态，则确定所述超时属于异常超时。

4.根据权利要求2或3所述的方法，其特征在于，当所述超时属于异常超时时，终止所述多屏协同的进程，具体包括：

当所述超时属于异常超时时，显示第一提示信息，所述第一提示信息用于指示用户手动终止所述多屏协同的进程；或者，

当所述超时属于异常超时时，自动终止所述多屏协同的进程。

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

当所述超时属于异常超时时，向所述第一函数的调用者发送异常反馈信息，所述异常反馈信息用于指示公用锁调用超时。

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

接收所述目的设备发送的反向控制命令，所述反向控制命令用于指示所述源设备控制投屏界面进行目标变化；

响应于所述反向控制命令，调用第三函数，所述第三函数用于触发执行目标操作的流程；

响应于所述第三函数的调用，调用所述公用锁，并在所述预设的容忍时间内保持持有所述公用锁。

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

所述投屏界面最小化，所述投屏界面最大化，所述投屏界面滑动，所述投屏界面中的视频播放暂停。

8.根据权利要求1或2所述的方法，其特征在于，所述响应于所述第二函数的调用，监听所述第一函数的调用时间是否超过预设的容忍时间，具体包括：

响应于所述第二函数的调用，执行查询可用的帧缓存队列的流程；

调用设置于媒体框架模块中的监听接口，监听所述第一函数的调用时间是否超过预设的容忍时间。

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

通过显示模块调用所述第一函数，向媒体编解码器发送待编码的投屏数据；

响应于所述第一函数的调用，缓存队列管理模块调用所述第二函数，指示媒体框架模块查询是否存在所述缓存队列的可用帧；

响应于所述第二函数的调用，所述媒体框架模块调用所述监听接口指示图形缓存监听模块监听所述第一函数的调用时间是否超过预设的容忍时间。

10.一种电子设备，其特征在于，包括：

一个或多个通信接口；

一个或多个处理器；

一个或多个存储器；

所述一个或多个存储器存储有一个或多个计算机程序，所述一个或多个计算机程序包括指令，当所述指令被所述一个或多个处理器执行时，使得所述电子设备执行如权利要求1至9中任一项所述的方法。