CN116149585A - 一种显示设备及应用同屏显示方法 - Google Patents

Abstract

本申请一些实施例提供一种显示设备及应用同屏显示方法，包括：响应于投屏指令，获取第一应用的准备状态以及启动第二应用；如果准备状态为支持悬浮的状态，控制显示器在第一应用的上方悬浮显示第二应用；如果准备状态为不支持悬浮的状态，控制显示器全屏显示第二应用。本申请在同一窗口同时显示两个应用时，由于两个应用是各自独立的，不依赖原生接口，所以应用的拓展性更强、操作性更佳，维护起来也更方面、减少维护成本。此外，由于两个应用之间可建立交互通信，因此，在两个应用叠加显示的同时，还可实现二者的交互，二者相互通信可以根据需要执行相关的操作，从而解决应用同屏显示过程中应用的交互性和局限性大、维护成本高的问题。

Description

一种显示设备及应用同屏显示方法

技术领域

本申请一些实施例涉及显示设备技术领域，尤其涉及一种显示设备及应用同屏显示方法。

背景技术

在利用显示设备播放视频等应用时，通常情况下，当前界面仅播放并显示一种应用。但是在某种情况下，用户可能有在当前界面播放两种或多种应用的需求，即应用同屏播放的需求。

例如，用户想要同时观看两种应用时，下层应用可以全屏播放，上层应用可以悬浮在下层应用的上方。为此，为了实现同屏播放两个或多个应用的目的，在一些显示设备中，可以通过原生接口实现应用界面悬浮。

但在通过原生接口实现应用同屏显示的过程中，若使用原生接口实现悬浮的方式，在上层应用和下层应用分别显示不同应用界面时，无法通过遥控器或其他按键对应用界面进行控制，且上层应用和下层应用无法通信。因此，采用原生接口的方式导致应用的交互性和局限性较大。而且，通过该方式实现应用界面悬浮的方案其依赖于原生接口，在应用版本发生变化时，需要对底层代码进行修改，如通常情况下可能需要系统升级，因此，应用维护成本也较高。

发明内容

本申请一些实施例提供一种显示设备及应用同屏显示方法，以解决应用同屏显示过程中应用的交互性和局限性大、维护成本高的问题。

第一方面，本申请一些实施例提供一种显示设备，包括：

显示器，被配置为显示用户界面；

控制器，被配置为：

响应于投屏指令，获取第一应用的准备状态，以及启动第二应用；其中，所述第一应用为当前用户界面中显示的应用，所述第二应用为投屏应用；所述准备状态用于表示第一应用是否支持悬浮显示；

如果所述准备状态为支持悬浮的状态，控制所述显示器在所述第一应用的上方悬浮显示所述第二应用；

如果所述准备状态为不支持悬浮的状态，控制所述显示器全屏显示所述第二应用。

第二方面，本申请一些实施例提供一种应用同屏显示方法，应用于第一方面的显示设备，所述应用同屏显示方法包括：

响应于投屏指令，获取第一应用的准备状态，以及启动第二应用；其中，所述第一应用为当前用户界面中显示的应用，所述第二应用为投屏应用；所述准备状态用于表示第一应用是否支持悬浮显示；

如果所述准备状态为支持悬浮的状态，控制所述显示器在所述第一应用的上方悬浮显示所述第二应用；

如果所述准备状态为不支持悬浮的状态，控制所述显示器全屏显示所述第二应用。

由以上技术方案可知，本申请一些实施例提供了一种显示设备及应用同屏显示方法，包括：响应于投屏指令，获取第一应用的准备状态，以及启动第二应用；如果准备状态为支持悬浮的状态，控制显示器在第一应用的上方悬浮显示第二应用；如果准备状态为不支持悬浮的状态，控制显示器全屏显示第二应用。本申请实施例在同一窗口同时显示两个应用时，由于两个应用是各自独立的，没有集成在同一应用中，所以，第一应用与第二应用不依赖原生接口，应用的拓展性更强、操作性更佳，维护起来也更方面、减少维护成本。此外，由于两个应用之间可建立交互通信，因此，在两个应用叠加显示的同时，还可实现二者的交互，二者相互通信可以根据需要执行相关的操作，从而解决应用同屏显示过程中应用的交互性和局限性大、维护成本高的问题。

附图说明

为了更清楚地说明本申请一些实施例或现有技术中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它的附图。

图1为本申请一些实施例提供的显示设备与控制设备之间操作场景的示意图；

图2为本申请一些实施例提供的图1中显示设备的硬件配置框图；

图3为本申请一些实施例提供的图1中控制设备的硬件配置框图；

图4为本申请一些实施例提供的图1中显示设备中软件配置示意图；

图5为本申请一些实施例提供的应用同屏显示方法流程示意图；

图6为本申请一些实施例提供的建立第一应用与第二应用的流程示意图；

图7为本申请一些实施例提供的在第一应用上方显示的操作提示界面示意图；

图8为本申请一些实施例提供的在第一应用的上方悬浮第二应用的流程示意图；

图9为本申请一些实施例提供的在第一应用上方悬浮第二应用的效果示意图；

图10为本申请一些实施例提供的焦点指令流转流程示意图；

图11为本申请一些实施例提供的根据断开指令退出第二应用的流程示意图；

图12为本申请一些实施例提供的根据断开指令解析断开原因的流程示意图；

图13为本申请一些实施例提供的显示设备显示提示消息的示意图；

图14为本申请一些实施例提供的根据屏幕切换指令播放媒资数据的流程示意图；

图15为本申请一些实施例提供的第二应用以横屏状态显示的示意图；

图16为本申请一些实施例提供的第二应用以竖屏状态显示的示意图。

具体实施方式

为使本申请一些实施例的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请一些实施例技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。

需要说明的是，本申请一些实施例中对于术语的简要说明，仅是为了方便理解接下来描述的实施方式，而不是意图限定本申请一些实施例的实施方式。除非另有说明，这些术语应当按照其普通和通常的含义理解。

本申请一些实施例中说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”等是用于区别类似或同类的对象或实体，而不必然意味着限定特定的顺序或先后次序，除非另外注明。应该理解这样使用的用语在适当情况下可以互换。

术语“包括”和“具有”以及他们的任何变形，意图在于覆盖但不排他的包含，例如，包含了一系列组件的产品或设备不必限于清楚地列出的所有组件，而是可包括没有清楚地列出的或对于这些产品或设备固有的其它组件。

术语“模块”是指任何已知或后来开发的硬件、软件、固件、人工智能、模糊逻辑或硬件或/和软件代码的组合，能够执行与该元件相关的功能。

图1为本申请一些实施例提供的显示设备与控制设备之间操作场景的示意图。如图1中示出，用户可通过移动终端300和控制设备100操作显示设备200。

在一些实施例中，移动终端300可与显示设备200安装软件应用，通过网络通信协议实现连接通信，实现一对一控制操作和数据通信的目的。也可以将移动终端300上显示音视频内容传输到显示设备200上，实现同步显示功能。

如图1中还示出，显示设备200还与服务器400通过多种通信方式进行数据通信。可允许显示设备200通过局域网(LAN)、无线局域网(WLAN)和其他网络进行通信连接。

显示设备200除了提供广播接收电视功能之外，还可以附加提供计算机支持功能的智能网络电视功能，包括但不限于，网络电视、智能电视、互联网协议电视(IPTV)等。

图2为本申请一些实施例提供的图1中显示设备200的硬件配置框图。

在一些实施例中，显示设备200包括调谐解调器210、通信器220、检测器230、外部装置接口240、控制器250、显示器260、音频输出接口270、存储器、供电电源、用户接口中的至少一种。

在一些实施例中，检测器230用于采集外部环境或与外部交互的信号。

在一些实施例中，显示器260包括用于呈现画面的显示屏组件，以及驱动图像显示的驱动组件，用于接收源自控制器输出的图像信号，进行显示视频内容、图像内容以及菜单操控界面的组件以及用户操控UI界面等。

在一些实施例中，通信器220是用于根据各种通信协议类型与外部设备或服务器400进行通信的组件。

在一些实施例中，控制器250，通过存储在存储器上中各种软件控制程序，来控制显示设备的工作和响应用户的操作。控制器250控制显示设备200的整体操作。

在一些实施例中，用户可在显示器260上显示的图形用户界面(GUI)输入用户命令，则用户输入接口通过图形用户界面(GUI)接收用户输入命令。

在一些实施例中，用户接口280，为可用于接收控制输入的接口。

图3为本申请一些实施例提供的图1中控制设备的硬件配置框图。如图3所示，控制设备100包括控制器110、通信接口130、用户输入/输出接口、存储器、供电电源。

控制设备100被配置为控制显示设备200，以及可接收用户的输入操作指令，且将操作指令转换为显示设备200可识别和响应的指令，起到用户与显示设备200之间交互中介作用。

在一些实施例中，控制设备100可是一种智能设备。如：控制设备100可根据用户需求安装控制显示设备200的各种应用。

在一些实施例中，如图1所示，移动终端300或其他智能电子设备，可在安装操控显示设备200的应用之后，可以起到控制设备100类似功能。

控制器110包括处理器112和RAM 113和ROM 114、通信接口130以及通信总线。控制器110用于控制控制设备100的运行和操作，以及内部各部件之间通信协作以及外部和内部的数据处理功能。

通信接口130在控制器110的控制下，实现与显示设备200之间控制信号和数据信号的通信。通信接口130可包括WiFi芯片131、蓝牙模块132、NFC模块133等其他近场通信模块中至少之一种。

用户输入/输出接口140，其中，输入接口包括麦克风141、触摸板142、传感器143、按键144等其他输入接口中至少一者。

在一些实施例中，控制设备100包括通信接口130和输入输出接口140中至少一者。控制设备100中配置通信接口130，如：WiFi、蓝牙、NFC等模块，可将用户输入指令通过WiFi协议、或蓝牙协议、或NFC协议编码，发送至显示设备200。

存储器190，用于在控制器的控制下存储驱动和控制控制设备100的各种运行程序、数据和应用。存储器190，可以存储用户输入的各类控制信号指令。

供电电源180，用于在控制器的控制下为控制设备100各元件提供运行电力支持。

图4为本申请一些实施例提供的图1中显示设备中软件配置示意图，在一些实施例中，将系统分为四层，从上至下分别为应用程序(Applications)层(简称“应用层”)、应用程序框架(Application Framework)层(简称“框架层”)和系统库层(简称“系统运行库层”)，以及内核层。

在一些实施例中，应用程序层中运行有至少一个应用程序，这些应用程序可以是操作系统自带的窗口(Window)程序、系统设置程序、时钟程序、相机应用等；也可以是第三方开发者所开发的应用程序。

框架层为应用程序层的应用程序提供应用编程接口(Aplication PogrammingIterface，API)和编程框架。应用程序框架层包括一些预先定义的函数。应用程序框架层相当于一个处理中心，这个中心决定让应用层中的应用程序做出动作。

如图4所示，本申请一些实施例中应用程序框架层包括管理器(Managers)、内容提供者(Content Provider)和视图系统(View System)等。

在一些实施例中，活动管理器用于：管理各个应用程序的生命周期以及通常的导航回退功能。

在一些实施例中，窗口管理器用于管理所有的窗口程序。

在一些实施例中，系统运行库层为上层即框架层提供支撑，当框架层被访问时，操作系统会运行系统运行库层中包含的C/C++库以实现框架层要实现的功能。

在一些实施例中，内核层是硬件和软件之间的层。如图4所示，内核层至少包含以下驱动中的至少一种：音频驱动、显示驱动、蓝牙驱动、摄像头驱动、WIFI驱动、USB驱动、HDMI驱动、传感器驱动(如指纹传感器，温度传感器，触摸传感器、压力传感器等)等。

在一些实施例中，内核层还包括用于进行电源管理的电源驱动模块。

在一些实施例中，图4中的软件架构对应的软件程序和/或模块存储在图2或图3所示的第一存储器或第二存储器中。

基于上述显示设备200，可以播放视频等媒资数据。在利用显示设备200播放视频等应用时，通常情况下，当前界面仅播放并显示一种应用。但是在某种情况下，用户可能有在当前界面播放两种或多种应用的需求，即应用同屏播放的需求。

在一些实施例中，用户想要同时观看两种应用时，下层应用可以全屏播放，上层应用可以悬浮在下层应用的上方。为此，为了实现同屏播放两个或多个应用的目的，在一些显示设备中，可以通过原生接口实现应用界面悬浮。

示例性的，以用户通过显示设备来辅助健身的场景为例。当用户通过显示设备健身时，想要在同一个窗口既要显示摄像头预览画面即用户自己健身的动作画面，也要显示投屏或者健身视频画面，即想要在同一个窗口实现边学边练的目的。针对这种场景，可以将投屏的软件开发工具包集成到显示设备中的健身应用中，在显示设备接收到投屏指令后，下层的健身应用展示用户健身预览画面，上层应用可以悬浮显示在下层应用的上方，这样就实现了在同一个窗口显示两个应用的目的。在本申请一些实施例中，健身应用可以理解为支持用户显示健身画面的相关应用，可以与显示设备200的摄像头结合，用户站在显示设备200前，摄像头捕捉用户的动作，通过健身应用显示用户的健身画面。

但在上述实施方案中，因为两个应用是集成在一起的，所以，维护过程中可能存在交互性和扩展性较差等问题。即，投屏应用将数据或者连接传给健身应用时，健身应用在收到后需要先起播自己的界面进行播放，当需要全屏或非全屏切换投屏应用时，可能需要重写复写相关应用的代码及设计，维护和升级成本较高。再如，如果再有第三方应用要实现同窗口播放时，也需要将该第三方应用集成，扩展性也较差，会影响显示设备的运行效率，同时影响用户的体验感。

另外，在上述通过原生接口实现应用同屏显示的过程中，在上层应用和下层应用分别显示不同应用界面时，无法通过遥控器或其他按键对应用界面进行控制，且上层应用和下层应用无法通信。因此，采用原生接口的方式导致应用的交互性和局限性较大。而且，通过该方式实现应用界面悬浮的方案其依赖于原生接口，在应用版本发生变化时，需要对底层代码进行修改，如通常情况下可能需要系统升级，因此，应用维护成本也较高。

为了解决应用同屏显示过程中应用的交互性和局限性大、维护成本高的问题，本申请一些实施例提供一种应用同屏显示方法，该方法应用于显示设备200。在一些实施例中，显示设备200包括控制器250和显示用户界面的显示器260。本申请旨在通过判断下层应用的准备状态来判断是否悬浮显示在下层应用的上方，建立上层应用与下层应用的交互。因为下层应用被上层应用悬浮而捕捉不到焦点，这样，由上层应用捕捉到焦点指令后，发送给下层应用，再由下层应用发送给其他应用，其他应用可以根据该焦点指令做出相应的操作。

为了便于对本申请一些实施例中技术方案的理解，下面结合一些具体实施例和附图对各个步骤进行详细说明。图5为本申请一些实施例提供的应用同屏显示方法流程示意图，如图5所示，一种应用同屏显示方法可以包括如下步骤S1-S3，具体包括：

S1：响应于投屏指令，获取第一应用的准备状态，以及启动第二应用。

在一些实施例中，投屏指令可以是通过终端设备如手机发出的，也可以是显示设备200配套的遥控器发出的，还可以为其他形式发出的，对此本申请不作限定。可以理解的是，通过投屏指令，可以建立投屏连接，这样，就可以通过投屏指令显示投屏应用。

为了建立上层应用与下层应用的交互，在一些实施例中，显示设备200可以通过如下方式实现。图6为本申请一些实施例提供的建立第一应用与第二应用的流程示意图，如图6所示，显示设备200遍历已部署的所有应用，从所有应用中筛选出支持悬浮功能的第二应用。可以理解的是，第二应用可以为一个，也可以为多个。当第二应用为一个时，则同一窗口可以同时显示两个应用，当第二应用为多个时，即为在同一窗口同时显示多个应用。支持悬浮功能的第二应用筛选出来后，绑定第一应用与第二应用中的客户端服务，这样就建立了第一应用与第二应用的数据互通关系。

需要说明的是，在建立第一应用与第二应用的数据互通关系时，还可以在第一应用启动摄像头后，绑定与其他应用的客户端服务，这样，绑定后第一应用就可以给其他应用如第二应用发送消息，示例性的，发送第一应用是否支持悬浮应用的准备状态，其他应用在接收到第一应用发送的消息后，就可以以此为依据执行后续流程。

在一些实施例中，第一应用为当前用户界面中显示的应用，如为下层应用，第二应用为投屏应用，如为悬浮显示的上层应用，准备状态用于表示第一应用是否支持悬浮显示。第一应用中的准备状态可以包括准备中、准备完成、准备异常等多种状态，对此本申请不作限定。在第二应用启动后，第一应用可以将其准备状态发送给第二应用，以供第二应用判断是否在第一应用的上方悬浮显示。

示例性的，可以通过元数据信息遍历当前整机所有应用，判断是否有支持悬浮的第二应用。如果筛选出了支持悬浮功能的第二应用，则可以依次绑定预设的客户端服务，这样，第一应用和第二应用就完成了交互。

在一些实施例中，第一应用的状态可以用不同的标识来表示，示例性的，第一应用的标识和其表示的内容可以包括：IDLE-准备中、PREPARE-准备完成、FOCUS-准备完成、FINISH-界面退出、ERROR-异常，需要说明的是，上述标识仅为示意性说明，并不构成对标识内容的限定。获取到第一应用的准备状态后，基于第一应用与第二应用的交互功能，第一应用可以将准备状态发送给第二应用，以供第二应用判断是否悬浮。步骤S1完成后，可以执行如下步骤S2。

S2：如果准备状态为支持悬浮的状态，显示设备200控制显示器260在第一应用的上方悬浮显示第二应用。

在一些实施例中，第二应用接收到第一应用发送的准备状态后，可以通过准备状态的具体情况判断其是否支持悬浮的状态。示例性的，当第一应用的准备状态为PREPARE准备完成或FOCUS准备完成的状态时，可以代表其支持悬浮，此时，显示设备200可以控制显示器260在第一应用的上方悬浮显示第二应用。需要说明的是，针对不同的应用，准备状态的标识可能不同。示例性的，对于依赖无线网络通信技术的某些自研投屏应用，其属于后台服务类应用，PREPARED状态代表支持悬浮的准备状态。而对于非后台服务类应用，例如，依赖于启动界面的某些断网投屏，其只有在某个页面下才能使用，该应用可以通过FOCUS控制其功能开关，通知当前应用可以支持悬浮界面显示。

在一些实施例中，在第一应用的上方悬浮显示第二应用之前，显示设备200可以控制控制显示器260在第一应用的上方显示操作提示界面，以为用户操作投屏提供操作提示，引导用户如何实现投屏操作。

图7为本申请一些实施例提供的在第一应用上方显示的操作提示界面示意图，如图7所示，在界面71中可以显示通过摄像头拍摄到的用户画面，在界面72中即操作提示界面中会显示投屏设备的名称、网络名称、当前投屏进度状态、操作提示等，这样，用户一方面可以根据操作提示进行操作，另一方面，显示设备200可以在显示器260上反馈目前投屏连接的状态。

图8为本申请一些实施例提供的在第一应用的上方悬浮第二应用的流程示意图，如图8所示，在一些实施例中，可以通过如下方式执行在第一应用的上方悬浮第二应用。具体包括，首先显示设备200控制控制显示器260全屏显示第一应用，之后，将第二应用的主题设置为透明，最后，控制显示器260在第一应用的上方叠加显示主题为透明的第二应用。

示例性的，图9为本申请一些实施例提供的在第一应用上方悬浮第二应用的效果示意图，如图9所示，以第一应用为健身应用为例，在将第二应用悬浮显示在第一应用上时，首先会在界面91全屏显示健身应用，在接收到投屏指令后，显示设备200会判断健身应用当前的准备状态，如果第一应用的准备状态为PREPARED状态或FOCUS等准备完成的状态，则说明第一应用支持悬浮的状态。也就是说，在本申请实施例中，在执行悬浮显示操作时，悬浮显示的第二应用会对下层的第一应用的准备状态进行判断，只有在下层应用支持悬浮显示时，第二应用才会在下层的第一应用上方悬浮显示。

在一些实施例中，执行在第一应用上方悬浮显示第二应用时，可以将第二应用的主题设置为透明，这样，既可以与第一应用在同一窗口显示第二应用，第二应用在第一应用上方悬浮显示的同时，又不会完全遮挡住第一应用，实现了在第一应用上方悬浮显示第二应用的功能。需要说明的是，在投屏应用过程中，可以在第一应用的上方悬浮显示一个应用，也可以悬浮显示多个应用，对此本申请不作具体限定。

示例性的，仍以第一应用为健身应用为例，健身应用中的界面91显示的是摄像头预览画面，即用户健身的画面，在第一应用上方悬浮显示第二应用时，可以预先设定悬浮显示的位置，例如，可以为右上角悬浮显示，也可以为左上角悬浮显示等。以在右上角悬浮显示第二应用为例，假设第二应用为投屏的健身视频画面，其顶部右上角界面92是健身视频画面，画面以外的悬浮界面则为透明的。这样，只有健身视频画面部分遮挡住了第一应用，其目的为边学边练，另一部分的健身应用界面用户仍然可以看到，这样就不会影响用户观看自己健身的画面，从而实现在同一窗口同时显示两个应用的目的。

在一些实施例中，与图7的操作提示界面相结合，当第一应用支持悬浮显示第二应用时，可以执行第二应用的悬浮显示操作。同时，在第一应用的上方悬浮显示第二应用之后，可以通过发送消息等方式通知下层的健身应用已启动悬浮操作，并生成悬浮回执，以及将悬浮回执发送至第一应用。在本申请实施例中，悬浮回执可以理解为第二应用已成功实现悬浮显示的状态的回执信息。这样，第一应用在接收到该悬浮回执后，可以根据悬浮回执退出操作提示界面，则此时图7中的操作提示界面消失，只在健身应用的上方悬浮显示第二应用。

示例性的，第二应用向第一应用发送的悬浮回执可以为状态信息，例如，可以为已连接CONNECT的状态及未连接DISCONNECT的状态，如果上层的第二应用给下层的第一应用发送的为已连接CONNECT，则说明第一应用与第二应用的悬浮显示已成功，则此时图7中的操作提示界面消失。相反，如果第二应用给第一应用发送的为未连接DISCONNECT的状态，则说明二者悬浮显示未成功，则此时可以保留图7中的操作提示界面，以使用户根据此再次执行悬浮显示操作。步骤S2执行完成后可以执行如下步骤S3。

S3：如果准备状态为不支持悬浮的状态，显示设备200控制显示器260全屏显示第二应用。

在一些实施例中，第二应用接收到第一应用发送的准备状态后，通过准备状态判断其是否支持悬浮的状态时，如果准备状态为不支持悬浮的状态，则显示设备200可以控制显示器260全屏显示第二应用。

示例性的，不支持悬浮的状态可以为FINISH界面退出或ERROR异常的状态，即第一应用可能出现了异常情况。例如，显示设备200的摄像头可能出现异常、第一应用界面出现异常等，则此种场景下，在接收到投屏指令后，显示设备200可以控制显示器260全屏显示第二应用，即全屏显示投屏界面，这样，用户可以根据第二应用完成健身运动。

需要说明的是，在本申请实施例中，在同一窗口同时显示两个应用时，即两个应用画面同屏显示时，由于两个应用是各自独立的，没有集成在同一应用中，所以，第一应用与第二应用不依赖原生接口，应用的拓展性更强、操作性更佳，维护起来也更方面、减少维护成本。此外，由于两个应用之间建立了交互通信，因此，在两个应用叠加显示的同时，还实现了二者的交互，二者相互通信可以根据需要执行相关的操作，从而解决了应用同屏显示过程中应用的交互性和局限性大、维护成本高的问题。

由以上技术方案可知，上述实施例提供的应用同屏显示方法响应于投屏指令，获取第一应用的准备状态，以及启动第二应用；如果准备状态为支持悬浮的状态，控制显示器在第一应用的上方悬浮显示第二应用；如果准备状态为不支持悬浮的状态，控制显示器全屏显示第二应用。本申请实施例在同一窗口同时显示两个应用时，由于两个应用是各自独立的，没有集成在同一应用中，所以，第一应用与第二应用不依赖原生接口，应用的拓展性更强、操作性更佳，维护起来也更方面、减少维护成本。此外，由于两个应用之间可建立交互通信，因此，在两个应用叠加显示的同时，还可实现二者的交互，二者相互通信可以根据需要执行相关的操作，从而解决应用同屏显示过程中应用的交互性和局限性大、维护成本高的问题。

在一些实施例中，在第一应用的上方悬浮显示第二应用后，因为第一应用被第二应用遮挡了，所以下层的第一应用是捕捉不到焦点指令的。其中，焦点指令可以是显示设备200配套的遥控器发出的指令。这样，遥控器将无法控制第一应用的操作，第一应用也无法捕捉到遥控器发出的焦点指令。

为了确保下层的第一应用也能获取到焦点指令，显示设备200还可以执行如下操作。图10为本申请一些实施例提供的焦点指令流转流程示意图，如图10所示，在一些实施例中，显示设备200可以控制第二应用捕捉用户界面中的焦点指令，之后，第二应用可以把捕捉到的焦点指令发送至第一应用。第一应用接收到焦点指令后，可以解析该焦点指令并生成解析结果，同时，将焦点指令的解析结果发送至其他应用，以使其他应用根据该解析结果执行相关操作，其中，其他应用为显示设备中除第一应用和第二应用外的应用。

示例性的，通过遥控器发出焦点指令后，因为第二应用悬浮显示在第一应用的上方，所以第二应用可以捕捉到该焦点指令，而下层的第一应用无法捕捉到该焦点指令，则遥控器也无法控制下层的第一应用。

为了使第一应用也可以获取到该焦点指令，在一些实施例中，第二应用捕捉到焦点指令后，可以基于第一应用和第二应用建立的数据互通关系将该焦点指令发送给第一应用。第一应用接收到该焦点指令后，可以对该焦点指令进行解析，并生成解析结果。示例性的，焦点指令可以为调节当前画面的对比度，当第二应用捕捉到该焦点指令后，可以将调节画面对比度的指令发送至第一应用。第一应用接收到该指令后，可以将该指令通知给除了第一应用和第二应用以外的其他应用，这样，所有应用就都获得到了遥控器发出的焦点指令，并根据指令的具体内容执行相应的操作。

图11为本申请一些实施例提供的根据断开指令退出第二应用的流程示意图，如图11所示，在一些实施例中，显示设备200还可以执行如下流程，包括：响应于投屏断开事件，显示设备200生成断开指令。投屏断开事件可以为遥控器发送的断开投屏指令，也可以为终端设备如手机发出的断开投屏的操作，本申请对此不作具体限定。

显示设备200生成断开指令后，位于上层的第二应用可以捕捉到该断开指令，并通过与第一应用建立起来的数据互通关系将该断开指令发送至第一应用。第一应用接收到第二应用发送的断开指令后，可以将断开指令向第一应用和第二应用以外的其他应用发送，这样，由于第二应用本身是投屏应用，在接收到断开指令后，可以自行或通过其他应用执行投屏的操作，同时，显示设备200可以控制显示器260根据断开指令退出第二应用。这样，通过上层应用界面捕获焦点指令后，可以通过跨进程通信通知给底层应用，底层应用示例性为第一应用，底层应用在接收到焦点指令后，再通过底层应用本身将焦点指令发送给其他应用，一方面实现了多个应用的相互通信、实现了在同一窗口同时显示多个应用的目的，另一方面，解决了第一应用无法获取到焦点指令的问题。

示例性的，焦点指令发出后，处于最上方的第二应用捕捉该焦点指令，并将焦点指令转发给最下层的第一应用，这样，通过最下层的第一应用转发或执行焦点指令中的事件或任务，并通知其他应用，例如中间件应用执行相关操作。这样，既实现了两个或多个应用同时显示的目的，另外，所有的应用都会获取到焦点指令，保证了显示设备200中指令的顺利执行。

为了使用户了解第二应用断开投屏的原因，在一些实施例中，断开指令中还可以携带有断开原因。图12为本申请一些实施例提供的根据断开指令解析断开原因的流程示意图，如图12所示，可以通过如下方式提示用户断开投屏的原因。

当显示设备200接收到断开指令后，首先可以从断开指令中解析断开指令的断开原因。示例性的，投屏应用可能是终端设备如手机发出的，当手机端要与显示设备200断开投屏连接时，可以通过发送消息的方式通知第二应用断开投屏连接，同时携带有断开连接的断开原因，如手机端主动断开、网络原因断开、因多个投屏冲突原因断开等。在一些实施例中，第二应用在接收到上述断开原因后，可以将断开消息发送到底层的第一应用。这样，第一应用可以将该断开消息发送到除第一应用、第二应用以外的其他应用，则显示设备200可以根据断开指令和断开原因生成提示消息。

图13为本申请一些实施例提供的显示设备显示提示消息的示意图，如图13所示，当显示设备200根据断开指令和断开原因生成提示消息后，可以在退出第二应用如投屏应用时，控制显示器260显示该提示消息，这样，用户就可以直观的了解到第二应用断开投屏的原因。可以理解的是，当在显示器260上显示提示消息后，第二应用同时不会再第一应用上方悬浮显示。也就是说，当手机端发出断开指令后，第二应用的界面将会被销毁，不会再显示第二应用的界面。

在一些实施例中，显示设备200还可以检测第一应用的运行状态，如果第一应用的运行状态为运行异常，则检测第二应用的投屏状态；如果第二应用为投屏状态，则退出第二应用；如果第二应用为非投屏状态，则控制显示器260全屏显示第二应用。

示例性的，第一应用可能会因为某些原因运行异常，例如，第一应用配置出现异常、进程出现异常等，显示设备200检测到第一应用的运行状态异常后，可以适应性的设置第二应用的状态。在一些实施例中，经检测，如果第一应用的运行转态为运行异常，第二应用为投屏状态时，因为第一应用出现异常时可能会不再支持投屏状态，则此时第一应用可以向第二应用发出未准备完成的状态，则此时可以退出第二应用，以保证第一应用和第二应用配合的一致性。如果第二应用为非投屏状态时，则此时可以不用再关注第一应用是否支持投屏，为了保证用户能够看到界面，此时显示设备200可以直接控制显示器260全屏显示第二应用即可。这样，虽然第一应用出现了异常，但是未执行投屏的其他应用仍然能够正常显示。

为了支持用户切换投屏显示的效果，在一些实施例中，显示设备200还可以根据用户输入的屏幕切换指令执行对应的操作，如根据屏幕切换指令横屏或竖屏显示第二应用中的媒资数据。

图14为本申请一些实施例提供的根据屏幕切换指令播放媒资数据的流程示意图，如图14所示，在一些实施例中，可以通过如下方式根据屏幕切换指令横屏或竖屏显示第二应用中的媒资数据。响应于用户对第二应用播放媒资数据的屏幕切换指令，显示设备200获取第二应用的播放窗口尺寸。获取到当前播放窗口尺寸后，显示设备200可以根据屏幕切换指令修改播放窗口尺寸，以及，按照修改后的播放窗口尺寸播放第二应用中的媒资数据。可以理解的是，播放窗口尺寸可以包括第二应用即投屏应用界面的宽和高，当界面的宽大于高时，则为横屏播放第二应用；当宽小于高时，则为竖屏播放第二应用。则根据屏幕切换指令播放媒资数据的过程也就是切换横竖屏显示效果的过程。

示例性的，屏幕切换指令可以是用户通过手机端横竖屏切换发出的，也可以是通过遥控器菜单键切换发出的，对此本申请不作限定。可以理解的是，显示设备200可以通过如下方式接收屏幕切换指令，并根据接收到的屏幕切换指令执行相应的流程。

示例性的，当通过手机端或遥控器菜单键发出屏幕切换指令后，首先第二应用获取到该屏幕切换指令，之后，显示设备200会获取当前第二应用的播放窗口尺寸。

获取到当前播放窗口尺寸后，显示设备200可以根据屏幕切换指令修改播放窗口尺寸。示例性的，屏幕切换指令可以为将当前第二应用的播放模式由横屏切换为竖屏，则通过计算，显示设备200可以计算出竖屏对应的宽高比，也就是修改后的播放窗口尺寸，这样，可以按照修改后的播放窗口尺寸播放第二应用中的媒资数据。

在一些实施例中，当手机端横竖屏切换或者遥控器菜单键切换时，显示设备200可以根据视频流的宽高修改投屏应用界面的显示尺寸。同时，可以设定一定的显示规则。例如，图15为本申请一些实施例提供的第二应用以横屏状态显示的示意图，如果投屏的第二应用为横屏显示状态，则可以如图15所示，在当前窗口的右上角悬浮显示第二应用。图16为本申请一些实施例提供的第二应用以竖屏状态显示的示意图，如果投屏的第二应用为竖屏显示状态，则可以如图16所示，在当前窗口的右侧悬浮显示第二应用。

在一些实施例中，根据屏幕切换指令横屏或竖屏显示第二应用中的媒资数据的过程可以通过如下方式实现。示例性的，若当前视频流为横屏，则默认悬浮在右上角，定宽，高按原比例缩放。通过特定字段如setLayoutParams字段动态设置投屏应用界面的尺寸。若当前视频流为竖屏，则默认悬浮在右侧，定高，宽按手机端视频流比例缩放，通过setLayoutParams动态设置投屏应用界面的尺寸，遥控器控制也可以按此逻辑，具体投屏应用界面的宽和高的计算方式可以如下：

将视频流的宽记为VideoWidth，将视频流的高记为VideoHeight，在一些实施例中，如果VideoWidth≥VideoHeight，则父布局的宽为定宽，记为X，则父布局高为X*

VideoHeight/VideoWidth；如果VideoWidth<VideoHeight，则父布局的高为定高，记为Y，则父布局宽为Y*VideoWidth/VideoHeight。其中，父布局为外层投屏应用界面的宽高度。

在一些实施例中，手机端横竖屏切换或遥控器菜单键切换时的宽高计算方式还可以为，获取当前父布局的宽高，分别记为ViewWidth，ViewHeight。如果VideoWidth≥VideoHeight，则父布局的高为定高，记为Y，则父布局的宽为Y*VideoHeight/VideoWidth。如果VideoWidth<VideoHeight，则父布局的高为定高，记为Y，则父布局宽为Y*VideoWidth/VideoHeight。需要说明的是，上述计算过程仅为示例性说明，并不代表实际的计算过程，还可以有其他计算方式或计算步骤等，对此本申请不作限定，上述计算方式也不构成对本申请的限定。

由以上技术方案可知，上述实施例提供的应用同屏显示方法除了实现在同一窗口同时显示两个或多个应用、解决了应用同屏显示过程中应用的交互性和局限性大、维护成本高的问题之外，还可以根据屏幕切换指令切换第二应用的横竖屏的显示效果，这样，可以在满足用户使用体验的同时，提高显示设备200显示器的使用率。

基于上述应用同屏显示方法，本申请部分实施例还提供一种显示设备200。在一些实施例中，显示设备200包括控制器250和显示器260，其中，显示器260被配置为显示用户界面，控制器250被配置为执行如下操作：

响应于投屏指令，获取第一应用的准备状态，以及启动第二应用；其中，第一应用为当前用户界面中显示的应用，第二应用为投屏应用；准备状态用于表示第一应用是否支持悬浮显示；

如果准备状态为支持悬浮的状态，控制显示器在第一应用的上方悬浮显示第二应用；

如果准备状态为不支持悬浮的状态，控制显示器全屏显示第二应用。

由以上技术方案可知，上述实施例提供的显示设备200响应于投屏指令，获取第一应用的准备状态，以及启动第二应用；如果准备状态为支持悬浮的状态，控制显示器260在第一应用的上方悬浮显示第二应用；如果准备状态为不支持悬浮的状态，控制显示器260全屏显示第二应用。本申请实施例在同一窗口同时显示两个应用时，由于两个应用是各自独立的，没有集成在同一应用中，所以，第一应用与第二应用不依赖原生接口，应用的拓展性更强、操作性更佳，维护起来也更方面、减少维护成本。此外，由于两个应用之间建立了交互通信，因此，在两个应用叠加显示的同时，还实现了二者的交互，二者相互通信可以根据需要执行相关的操作，从而解决了应用同屏显示过程中应用的交互性和局限性大、维护成本高的问题。

本说明书中各个实施例之间相同相似的部分互相参照即可，在此不再赘述。

本领域的技术人员可以清楚地了解到本发明实施例中的技术可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本发明实施例中的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例或者实施例的某些部分的方法。

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

为了方便解释，已经结合具体的实施方式进行了上述说明。但是，上述示例性的讨论不是意图穷尽或者将实施方式限定到上述公开的具体形式。根据上述的教导，可以得到多种修改和变形。上述实施方式的选择和描述是为了更好地解释原理以及实际的应用，从而使得本领域技术人员更好的使用实施方式以及适于具体使用考虑的各种不同的变形的实施方式。

Claims (10)

1.一种显示设备，其特征在于，包括：

显示器，被配置为显示用户界面；

控制器，被配置为：

响应于投屏指令，获取第一应用的准备状态，以及启动第二应用；其中，所述第一应用为当前用户界面中显示的应用，所述第二应用为投屏应用；所述准备状态用于表示第一应用是否支持悬浮显示；

如果所述准备状态为支持悬浮的状态，控制所述显示器在所述第一应用的上方悬浮显示所述第二应用；

如果所述准备状态为不支持悬浮的状态，控制所述显示器全屏显示所述第二应用。

2.根据权利要求1所述的显示设备，其特征在于，所述控制器进一步被配置为：

遍历显示设备中的所有应用；

从所有应用中筛选出支持悬浮功能的第二应用；

绑定所述第一应用与所述第二应用中的客户端服务，以建立所述第一应用与所述第二应用的数据互通关系。

3.根据权利要求1所述的显示设备，其特征在于，所述控制器进一步被配置为：

在所述第一应用的上方悬浮显示所述第二应用之前，控制所述显示器在所述第一应用的上方显示操作提示界面；

在所述第一应用的上方悬浮显示所述第二应用之后，生成悬浮回执，以及将所述悬浮回执发送至所述第一应用；

根据所述悬浮回执退出所述操作提示界面。

4.根据权利要求1所述的显示设备，其特征在于，所述控制器执行在所述第一应用的上方悬浮所述第二应用，进一步被配置为：

控制所述显示器全屏显示所述第一应用；

将所述第二应用的主题设置为透明；

控制所述显示器在所述第一应用的上方叠加显示主题为透明的所述第二应用。

5.根据权利要求1所述的显示设备，其特征在于，所述控制器进一步被配置为：

控制所述第二应用捕捉所述用户界面中的焦点指令；

将所述焦点指令发送至所述第一应用；

解析所述焦点指令；

将所述焦点指令的解析结果发送至其他应用，以使所述其他应用根据所述解析结果执行操作，所述其他应用为所述显示设备中除第一应用和第二应用外的应用。

6.根据权利要求1所述的显示设备，其特征在于，所述控制器进一步被配置为：

响应于投屏断开事件，生成断开指令；

将所述断开指令发送至所述第一应用；

控制所述显示器根据所述断开指令退出所述第二应用。

7.根据权利要求6所述的显示设备，其特征在于，所述控制器进一步被配置为：

从所述断开指令中解析断开指令的断开原因；

根据所述断开指令和所述断开原因生成提示消息；

在退出所述第二应用时，控制显示器显示所述提示消息。

8.根据权利要求1所述的显示设备，其特征在于，所述控制器进一步被配置为：

检测所述第一应用的运行状态；

如果所述运行状态为运行异常，检测所述第二应用的投屏状态；

如果所述第二应用为投屏状态，退出所述第二应用；

如果所述第二应用为非投屏状态，控制显示器全屏显示所述第二应用。

9.根据权利要求1所述的显示设备，其特征在于，所述控制器进一步被配置为：

响应于对第二应用播放媒资数据的屏幕切换指令，获取所述第二应用的播放窗口尺寸；

根据所述屏幕切换指令修改所述播放窗口尺寸；

按照修改后的播放窗口尺寸播放所述第二应用中的媒资数据。

10.一种应用同屏显示方法，其特征在于，应用于显示设备，所述显示设备包括显示器和控制器，所述应用同屏显示方法包括：

响应于投屏指令，获取第一应用的准备状态，以及启动第二应用；其中，所述第一应用为当前用户界面中显示的应用，所述第二应用为投屏应用；所述准备状态用于表示第一应用是否支持悬浮显示；

如果所述准备状态为支持悬浮的状态，控制所述显示器在所述第一应用的上方悬浮显示所述第二应用；

如果所述准备状态为不支持悬浮的状态，控制所述显示器全屏显示所述第二应用。

Images