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

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

【技术实现步骤摘要】
多屏协同中断的处理方法及电子设备


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

技术介绍

[0002]随着终端技术的发展，更多电子设备支持多屏协同。利用多屏协同可以将电子设备A的屏幕内容通过有线或者无线的方式投射到电子设备B上显示。投屏后，电子设备A的屏幕内容变化会在电子设备B上同步显示。另外，用户还可以通过电子设备B对电子设备A投射过来的屏幕内容进行操作，使得电子设备A响应于电子设备B的操作，显示相应的屏幕内容。
[0003]比如，以手机和平板电脑为例，在多屏协同场景下平板电脑可以显示手机上的窗口，并且用户可以通过控制平板电脑中协同窗口的内容反向控制手机侧的屏幕，手机侧屏幕识别到反控命令后实时修改画面内容，并再次将画面数据发送给编码器，编码后发送至平板电脑。
[0004]多屏协同场景下，当用户在平板电脑侧的协同窗口上频繁操作(比如多次拖动视频播放进度条以快进，和/或不断放大或缩小协同窗口等)情况下，容易导致手机重启，严重影响用户的使用体验。

技术实现思路

[0005]本申请实施例提供了一种多屏协同中断的处理方法及电子设备，以解决多屏协同场景下设备容易死机或重启的问题。
[0006]通过研究发现，在多屏协同场景下的数据交互过程形成一个闭环状态，多个数据流处理所需的资源有限，其中会存在资源争夺，易导致编码器死锁，进而导致电子设备容易死机或重启。在一些实施例中，可以通过在多屏协同框架设置监听接口，当监听到调用者未调用到目标资源时，通知调用者采取处理措施保证设备运行，进而避免电子设备在多屏协同场景下死机或重启。
[0007]第一方面，提供了一种多屏协同中断的处理方法，应用于源设备，所述源设备与目的设备建立用于多屏协同的通信连接，所述方法包括：
[0008]调用第一函数，所述第一函数的调用用于向媒体编解码器发送待编码的投屏数据，所述投屏数据用于在所述目的设备上同步显示所述源设备的投屏窗口；
[0009]响应于所述第一函数的调用，调用第二函数，所述第二函数的调用用于触发缓存队列的可用帧的查询流程，所述缓存队列用于所述源设备压入所述投屏数据；
[0010]响应于所述第二函数的调用，监听所述第一函数的调用时间是否超过预设的容忍时间；
[0011]当所述第一函数的调用时间超过预设的容忍时间时，终止所述多屏协同的进程。
[0012]其中，第一函数例如可以为源设备SurfaceFlinger调用的queuebuffer函数，用于将投屏数据发送至媒体编解码器(media codec)进行编码。第二函数可以是on frame available函数，该第二函数的调用用于查询缓存队列的可用帧。缓存队列的可用帧也可以
被描述为可用帧，或者帧缓存队列。
[0013]在一种实现方式中，对第一函数的调用时间进行监听具体可以是监听源设备中的SurfaceFlinger调用第一函数的时间是否超过预设的容忍时间。
[0014]根据本申请实施例提供的多屏协同中断的处理方法，通过在多屏协同的媒体框架侧设置监听接口，对调用者发起的目标资源调用进行监听，当在达到容忍时间时，调用者仍未获取对应的目标资源时，可以通知调用者采取释放进程等处理措施，保证电子设备的运行，避免电子设备由于资源调用冲突导致同屏协同场景下发生设备重启或者死机的问题，提升用户的使用体验。
[0015]结合第一方面，在第一方面的某些实现方式中，当所述第一函数的调用时间超过预设的容忍时间时，检查超时属于异常超时或者属于正常超时；
[0016]当所述超时属于异常超时时，终止所述多屏协同的进程，所述异常超时为在所述缓存队列的可用帧的查询流程中，由于未调用到公用锁导致的超时。
[0017]在一种实现方式中，在对第一函数的调用时间进行监听之前，源设备可以通过媒体框架模块向容忍时间设置模块发送第一调度信息，指示该容忍时间设置模块设置为第一状态，其中，第一状态是指未持有公用锁的状态。
[0018]在一种实现方式中，在初始化时，会创建一个AMessage对象，通过容忍时间设置模块设定一个post时延(容忍时间，delay time)，当达到该容忍时间后，通过AMessage对象发送检查指示信息，该检查指示信息可以在dealwatching函数内被捕获，捕获后会check检查超时是正常超时还是异常超时。
[0019]结合第一方面，在第一方面的某些实现方式中，响应于所述第二函数的调用，设置第一状态，所述第一状态用于指示当前未持有所述公用锁；
[0020]所述当所述第一函数的调用时间超过预设的容忍时间时，检查超时属于异常超时或者属于正常超时，具体包括：
[0021]当所述第一函数的调用时间超过预设的容忍时间时，检查所述第一状态是否已更改为第二状态，所述第二状态用于指示当前持有所述公用锁；其中，
[0022]若所述第一状态已更改为第二状态，则确定所述超时属于正常超时；
[0023]若所述第一状态未更改为第二状态，则确定所述超时属于异常超时。
[0024]在一种实现方式中，dealwatching函数内捕获检查指示信息会check当前状态是否是正常状态，如果当前状态为第一状态(也即未持锁状态)，那么确定当前状态为异常，该超时为异常超时；如果当前状态为第二状态(也即持锁状态)，那么确定当前状态为正常，该超时为正常超时。
[0025]结合第一方面，在第一方面的某些实现方式中，当当所述超时属于异常超时时，终止所述多屏协同的进程，具体包括：
[0026]当所述超时属于异常超时时，显示第一提示信息，所述第一提示信息用于指示用户手动终止所述多屏协同的进程；或者，
[0027]当所述超时属于异常超时时，自动终止所述多屏协同的进程。
[0028]结合第一方面，在第一方面的某些实现方式中，所述方法还包括：
[0029]当所述超时属于异常超时时，向所述第一函数的调用者发送异常反馈信息，所述异常反馈信息用于指示公用锁调用超时。
[0030]应理解，本实现方式提供的多屏协同终端的处理方法，在媒体框架侧增加接口调用监听，每当接口被调用，即开启监听。当监听开始的时候，监听算法会识别三种情况，一种是正常情况(在容忍时间内完成函数调用)，被调用后析构，监听释放；第二种是监听后发现达到预设的最大容忍时间，那么下一步可以check是否正常，当发现当前的持有的资源是被用来做具体的事情，那么可以判定该资源持有为正常流程，直接回到正常流程即可；第三种情况下，当发现调用者持有了资源后，没有执行正常动作，那么需要通知调用者，当前的调用发生了一次死锁，如不处理将引发严重问题。
[0031]结合第一方面，在第一方面的某些实现方式中，所述方法还包括：
[0032]接收所述目的设备发送的反向控制命令，所述反向控制命令用于指示所述源设备控制所述投屏界面进行目标变化；
[0033]响应于所述反向控制命令，调用第三函数本文档来自技高网...

【技术保护点】

【技术特征摘要】
1.一种多屏协同中断的处理方法，其特征在于，应用于源设备，所述源设备与目的设备建立用于多屏协同的通信连接，所述方法包括：调用第一函数，所述第一函数的调用用于向媒体编解码器发送待编码的投屏数据，所述投屏数据用于在所述目的设备上同步显示所述源设备的投屏窗口；响应于所述第一函数的调用，调用第二函数，所述第二函数的调用用于触发缓存队列的可用帧的查询流程，所述缓存队列用于所述源设备压入所述投屏数据；响应于所述第二函数的调用，监听所述第一函数的调用时间是否超过预设的容忍时间；当所述第一函数的调用时间超过预设的容忍时间时，终止所述多屏协同的进程。2.根据权利要求1所述的方法，其特征在于，所述当所述第一函数的调用时间超过预设的容忍时间时，终止所述多屏协同的进程，具体包括：当所述第一函数的调用时间超过预设的容忍时间时，检查超时属于异常超时或者属于正常超时；当所述超时属于异常超时时，终止所述多屏协同的进程，所述异常超时为在所述缓存队列的可用帧的查询流程中，由于未调用到公用锁导致的超时。3.根据权利要求2所述的方法，其特征在于，所述方法还包括：响应于所述第二函数的调用，设置第一状态，所述第一状态用于指示当前未持有所述公用锁；所述当所述第一函数的调用时间超过预设的容忍时间时，检查超时属于异常超时或者属于正常超时，具体包括：当所述第一函数的调用时间超过预设的容忍时间时，检查所述第一状态是否已更改为第二状态，所述第二状态用于指示当前持有所述公用锁；其中，若所述第一状态已更改为第二状态，则确定所述超时属于正常超时；若所述第一状态未更改为第二状态，则确定所述超时属于异常超时。4.根据权利要求2或3所述的方法，其特征在于，当当所述超时属于异常超时时，终止所述多屏协同的进程，具体包括：当所述超时属于异常超时时，显示第一提示信息，所述第一提示信息用于指示用户手动终止所述多屏协同的进程；或者，当所述超时属于异常超时时，自动终止所述多屏协同的进程。5.根据权利要求4所...

【专利技术属性】
技术研发人员：汪厚甜，谷代平，
申请(专利权)人：荣耀终端有限公司，
类型：发明
国别省市：