一种移动终端、显示设备及根据浏览器进行投屏的方法

技术领域

本申请涉及投屏技术领域，尤其涉及一种移动终端、显示设备及根据浏览器进行投屏的方法。

背景技术

镜像投屏是指移动终端通过有线或无线的方式连接到显示设备，使移动终端中显示的画面投屏到显示设备中，显示设备实时显示移动终端发送的投屏数据所对应的内容。用户在对移动终端与显示设备进行镜像投屏时，通常需要预先将移动终端和显示设备连接在同一个路由器组成的局域网内。在镜像投屏过程中，移动终端要实时对移动终端所显示的内容进行录屏并把录屏数据通过路由器转发到显示设备，显示设备进行实时解码显示。

以移动终端为电脑、显示设备为电视为例，电脑的浏览器网页内容可以投屏到电视上，以实现电脑端到电视端的浏览器投屏。为了实现浏览器投屏，一种实现方式中，可以在移动终端打开浏览器页面后自动向显示设备发起投屏，例如，在移动终端输入浏览器地址后，移动终端直接触发向显示设备发起投屏的操作。这样，显示设备允许投屏后，移动终端即可将投屏数据发送至显示设备，以使显示设备显示投屏数据。

但是，在上述实现方式中，要兼顾浏览器的类型问题。例如，针对没有点击、输入、滑动等手势线程要求的浏览器，移动终端可以直接向显示设备发起投屏，而针对有手势线程要求的浏览器，则要求通过手势线程来申请录屏，如果仍采用直接投屏的方式，会导致出现报错而无法投屏成功，因此，在浏览器投屏过程中，浏览器兼容性较差。

发明内容

本申请提供一种移动终端、显示设备及根据浏览器进行投屏的方法，可以根据不同的浏览器类型执行不同的投屏方式，提升浏览器的兼容性。

第一方面，本申请一些实施例提供一种移动终端，包括

显示单元，被配置为显示终端界面；

通信单元，被配置为与显示设备建立投屏连接；

处理器，被配置为：

获取待投屏浏览器的浏览器地址，以及，基于所述浏览器地址向显示设备发送获取浏览器网页内容的网页内容请求；

接收所述显示设备根据所述网页内容请求返回的回执信息；

解析所述回执信息，以得到待投屏浏览器的浏览器类型；

根据所述浏览器类型向所述显示设备发起投屏连接；

响应于投屏连接成功的事件，通过所述待投屏浏览器向所述显示设备发送投屏数据，以使所述显示设备显示所述投屏数据。

基于上述移动终端，本申请第一方面还提供一种根据浏览器进行投屏的方法，应用于移动终端，所述移动终端包括显示单元、通信单元和处理器，所述根据浏览器进行投屏的方法包括：

获取输入的待投屏浏览器的浏览器地址，以及，基于所述浏览器地址向显示设备发起获取浏览器网页内容的网页内容请求；

接收所述显示设备根据所述网页内容请求返回的回执信息；

解析所述回执信息，以得到所述回执信息包含的待投屏浏览器的浏览器类型；

根据所述浏览器类型向所述显示设备发起投屏连接；

响应于所述投屏连接成功的事件，通过所述待投屏浏览器向所述显示设备发送投屏数据，以使所述显示设备显示所述投屏数据。

由以上技术方案可知，上述实施例提供的移动终端和根据浏览器进行投屏的方法，包括：获取待投屏浏览器的浏览器地址，基于浏览器地址向显示设备发送获取浏览器网页内容的网页内容请求；接收显示设备根据网页内容请求返回的回执信息；解析回执信息，以得到待投屏浏览器的浏览器类型；根据浏览器类型向显示设备发起投屏连接；响应于投屏连接成功的事件，通过待投屏浏览器向显示设备发送投屏数据，以使显示设备显示投屏数据。针对无手势线程要求的浏览器，可以基于待投屏浏览器直接录制屏幕数据，对有手势线程要求的浏览器，可以基于对操作控件的确认投屏事件，再录制屏幕数据等。本申请可以根据不同的浏览器类型执行不同的投屏方式，进而提升浏览器的兼容性。

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

显示器，被配置为显示投屏界面；

通信器，被配置为与移动终端建立投屏连接；

控制器，被配置为：

接收移动终端发送的网页内容请求，所述网页内容请求是移动终端基于浏览器地址向显示设备发送的获取浏览器网页内容的请求；

根据所述网页内容请求生成回执信息，以及将所述回执信息发送至所述移动终端，所述回执信息中包括浏览器类型；

接收所述移动终端根据所述浏览器类型发送的投屏连接；

响应于所述投屏连接成功的事件，接收所述移动终端发送的投屏数据，以及，控制所述显示器显示所述投屏数据。

基于上述显示设备，本申请第二方面还提供一种根据浏览器进行投屏的方法，应用于显示设备，所述显示设备包括显示器、通信器和控制器，所述根据浏览器进行投屏的方法包括：

接收移动终端发送的网页内容请求，所述网页内容请求是移动终端基于浏览器地址向显示设备发送的获取浏览器网页内容的请求；

根据所述网页内容请求生成回执信息，以及将所述回执信息发送至所述移动终端，所述回执信息中包括浏览器类型；

接收所述移动终端根据所述浏览器类型发送的投屏连接；

响应于所述投屏连接成功的事件，接收所述移动终端发送的投屏数据，以及，控制所述显示器显示所述投屏数据。

由以上技术方案可知，上述实施例提供的显示设备和根据浏览器进行投屏的方法可以接收移动终端发送的网页内容请求，并根据网页内容请求生成回执信息，以及将回执信息发送至移动终端。其中，该回执信息是包括浏览器类型的，之后，显示设备可以接收移动终端根据浏览器类型发送的投屏连接，响应于投屏连接成功的事件，显示设备可以接收移动终端发送的投屏数据，以及控制显示器显示投屏数据。本申请可以根据移动终端不同的浏览器类型执行不同的投屏方式，通过移动终端与显示设备配合，进而提升浏览器的兼容性。

附图说明

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

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

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

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

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

图5为本申请一些实施例提供的通过同一局域网内的路由器实现镜像投屏的示意图；

图6为本申请一些实施例提供的显示设备执行根据浏览器进行投屏的方法流程示意图；

图7为本申请一些实施例提供的移动终端解析回执信息的流程示意图；

图8为本申请一些实施例提供的移动终端执行根据浏览器类型向显示设备发起投屏连接的流程示意图；

图9为本申请一些实施例提供的移动终端执行识别待投屏浏览器的浏览器类型的流程示意图；

图10为本申请一些实施例提供的第一浏览器类型的待投屏浏览器向显示设备发起投屏的操作控件效果示意图；

图11为本申请一些实施例提供的移动终端执行通过待投屏浏览器向显示设备200发送投屏数据的流程示意图；

图12为本申请一些实施例提供的移动终端通过另外一种方式向显示设备发起投屏连接的流程示意图；

图13为本申请一些实施例提供的移动终端通过又一种方式向显示设备发起投屏连接的流程示意图；

图14为本申请一些实施例提供的显示设备执行显示投屏数据的流程示意图；

图15为本申请一些实施例提供的显示设备与移动终端协商流程示意图。

具体实施方式

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

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

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

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

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

图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)等。其中管理器包括以下模块中的至少一个：活动管理器(Activity Manager)用与和系统中正在运行的所有活动进行交互；位置管理器(Location Manager)用于给系统服务或应用提供了系统位置服务的访问；文件包管理器(Package Manager)用于检索当前安装在设备上的应用程序包相关的各种信息；通知管理器(Notification Manager)用于控制通知消息的显示和清除；窗口管理器(WindowManager)用于管理用户界面上的括图标、窗口、工具栏、壁纸和桌面部件。

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

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

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

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

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

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

基于上述显示设备200和移动终端300，可以通过建立镜像投屏连接，使显示设备200播放并显示移动终端300中的内容。镜像投屏即是指移动终端300通过有线或无线的方式连接到显示设备200，使移动终端300中显示的画面投屏到显示设备200中，显示设备200实时显示移动终端300发送的投屏数据所对应的内容。

用户对移动终端300与显示设备200进行镜像投屏时，通常需要预先将移动终端300与显示设备200设置在同一局域网内。例如，以移动终端为电脑、显示设备为电视为例，用户在对电脑与电视进行镜像投屏时，通常需要预先将电脑和电视连接在同一个路由器组成的局域网内。图5为本申请一些实施例提供的通过同一局域网内的路由器实现镜像投屏的示意图，如图5所示，在镜像投屏过程中，电脑可以实时录屏并把录屏数据转发到电视，电视进行实时解码显示。这样，电脑的浏览器网页内容可以投屏到电视上，以实现电脑端到电视端的浏览器投屏。

为了实现移动终端300与显示设备200之间的浏览器投屏，在一些实施例中，可以在移动终端300打开浏览器页面后自动向显示设备200发起投屏。在移动终端300输入浏览器地址后，移动终端300可以直接触发向显示设备200发起投屏的操作。这样，显示设备200允许投屏后，移动终端300即可将投屏数据发送至显示设备200，以使显示设备200显示投屏数据。例如，电脑端通过浏览器打开一个网页，网页会向电视发出网页获取请求，并通过浏览器向电视申请屏幕录制的权限。申请到录制权限之后，电脑端可以获取到视频流，并将视频流发送给电视，电视接收到该视频流后即可播放该视频流。

但是，在上述实现方式中，需要兼顾浏览器的类型问题。在一些实施例中，浏览器按照是否需要通过点击、输入、滑动等手势线程执行投屏的分类方式，可以将浏览器分为有手势线程要求的浏览器和没有手势线程要求的浏览器。例如，手势线程可以包括用户点击、输入、滑动等操作对应的线程。也就是说，在浏览器投屏过程中，有手势要求的浏览器在申请录屏等投屏权限时，需要在用户的点击、输入、滑动等操作中发起。这样，针对没有手势线程要求的浏览器，移动终端300可以直接向显示设备200发起投屏，例如，在输入浏览器地址并打开网页后，通过网页直接向显示设备200进行投屏。而针对有手势线程要求的浏览器，则需要通过手势线程来申请录屏，即，需要由点击、输入等操作来触发投屏，如果仍采用通过开启网页直接投屏的方式，会导致投屏过程出现报错而无法投屏成功。

例如，部分浏览器在打开网页后，会自动弹出网页内容获取的授权窗口，授权窗口点击确定之后可以发起投屏。在网页打开时，可以向电视发起投屏连接，连接成功后，向用户即可申请录屏权限，该过程中不用点击操作按钮及控件就可以执行自动投屏。但是，部分浏览器不允许浏览器打开时自动执行申请录制屏幕权限的逻辑。在此场景下仍采取自动申请的方式时，就会弹出错误提示，该错误用于表示申请权限需通过手势操作的方式实现，如点击、滑动、输入等方式。因此，对于有手势线程要求的浏览器，在浏览器投屏过程中兼容性较差。

为了实现移动终端300与显示设备200之间的浏览器投屏，本申请部分实施例提供一种移动终端300，包括显示单元310、通信单元320和处理器330。其中，显示单元310被配置为显示终端界面，通信单元320被配置为与显示设备200建立投屏连接。本申请可以根据不同的浏览器类型执行不同的投屏方式，进而提升浏览器的兼容性。

为了便于对本申请一些实施例中技术方案的理解，下面结合一些具体实施例和附图对各个步骤进行详细说明。图6为本申请一些实施例提供的显示设备执行根据浏览器进行投屏的方法流程示意图，如图6所示，本申请一些实施例中的处理器330被配置为执行如下步骤S1-S5，具体内容如下：

步骤S1：移动终端300获取待投屏浏览器的浏览器地址，以及，基于浏览器地址向显示设备200发送获取浏览器网页内容的网页内容请求。

在通过浏览器网页对电视等显示设备200进行投屏控制时，需要获取到处于同一网络的电视设备，在确定好可以投屏的设备后，再执行投屏互动。示例性的，通过电脑登录浏览器网页后，想要将该网页投屏到处于同一网络的电视中时，需要获取到要投屏的这些电视的设备信息，如处于同一网络的待发现显示设备的设备列表。

在获取到同一网络的待发现显示设备的设备列表后，就可以将浏览器网页的内容投屏到同一网络中的任意显示设备200中。在执行浏览器投屏时，移动终端300首先可以获取待投屏浏览器的浏览器地址，例如，仍以移动终端300为电脑为例，用户可以基于电脑的浏览器输入该浏览器地址，并在输入完成后，基于浏览器地址向显示设备200发送获取浏览器网页内容的网页内容请求，该网页内容请求即为移动终端300基于浏览器地址向显示设备200发送的获取浏览器网页内容的请求。步骤S1执行完成后可以执行如下步骤S2。

步骤S2：移动终端300接收显示设备200根据网页内容请求返回的回执信息。

在一些实施例中，在电脑端输入的浏览器地址是指向显示设备200的。显示设备200端可以运行有超文本传输安全协议(Hypertext Transfer Protocol Secure，HTTPS)服务器，显示设备200在接收到移动终端300发送的网页内容请求后，可以基于HTTPS服务器请求网页页面，并根据网页内容请求生成回执信息，同时将回执信息返回给移动终端300。这样，移动终端300可以基于该回执信息执行下一步流程。步骤S2执行完成后可以执行如下步骤S3。

步骤S3：移动终端300解析回执信息，以得到待投屏浏览器的浏览器类型。

显示设备200将回执信息返回给移动终端300后，移动终端300可以解析该回执信息。图7为本申请一些实施例提供的移动终端解析回执信息的流程示意图，如图7所示，移动终端300可以从回执信息中解析待投屏浏览器的浏览器页面显示内容和待投屏浏览器向显示设备200执行投屏的逻辑脚本。其中，浏览器页面显示内容即为浏览器网页页面上呈现的页面内容，可以包括相关图片、文字等描述信息。逻辑脚本即为在投屏不同阶段执行不同的逻辑步骤的脚本，即不同的脚本在不同的步骤中执行。示例性的，一部分脚本是在浏览器网页打开页面的时候执行，一部分在有控件或按钮点击操作事件的过程中执行等。

从回执信息中解析出待投屏浏览器的浏览器页面显示内容和逻辑脚本后，移动终端300就可以控制显示单元310根据浏览器页面显示内容显示浏览器页面并基于逻辑脚本和浏览器页面检测待投屏浏览器的浏览器类型。也就是说，在本申请实施例中，可以基于逻辑脚本对浏览器类型进行判断。示例性的，通常同一个步骤运行的是同一个脚本，以打开浏览器网页为例，在判断浏览器类型的过程中，如果脚本运行在A浏览器中，在网页打开后悔自动执行逻辑脚本，则通过逻辑脚本可以判断出当前浏览器类型为A浏览器；如果同一脚本运行在B浏览器中，则通过该逻辑脚本可以判断出当前浏览器为B浏览器。步骤S3执行完成后可以执行如下步骤S4。

步骤S4：移动终端300根据浏览器类型向显示设备200发起投屏连接。

为了解决浏览器的兼容性问题，基于逻辑脚本对浏览器类型进行判断后，移动终端300可以根据浏览器类型向显示设备200发起投屏连接。图8为本申请一些实施例提供的移动终端执行根据浏览器类型向显示设备发起投屏连接的流程示意图，如图8所示，移动终端在发起投屏连接之前，需要先识别待投屏浏览器的浏览器类型。在一些实施例中，根据是否要求通过手势线程发起投屏的操作，可以将浏览器类型分为有手势线程要求的第一浏览器类型和没有手势线程要求的第二浏览器类型。可以理解的是，第一浏览器类型需要通过手势线程来触发投屏，而第二浏览器类型不需要通过手势线程来触发投屏。但是，需要说明的是，第二浏览器类型只是不需要通过手势线程触发，如果通过手势线程触发，同样可以执行投屏流程，而第一浏览器类型是必须要通过手势线程来触发的，如果跳过手势线程的步骤直接进行投屏是无法实现的，例如，可能会提示报错、投屏失败等。

为了识别待投屏浏览器的浏览器类型，移动终端300可以预先设定一个浏览器类型列表，通过该浏览器列表来判断待投屏浏览器的具体类型。图9为本申请一些实施例提供的移动终端执行识别待投屏浏览器的浏览器类型的流程示意图，如图9所示，移动终端300可以预先制定第一浏览器类型列表，该列表中可以存储有所有有手势线程要求的浏览器相关信息。例如，可以包括浏览器名称、浏览器版本号、浏览器手势线程标识码等。示例性的，浏览器手势线程标识码可以设置为true和false，true代表该浏览器有手势线程要求，false代表该浏览器没有手势线程要求。在一些实施例中，浏览器手势线程标识码也可以用0和1来表示等，对此本申请不作具体限定。

第一浏览器类型列表制定完成后，在待投屏浏览器网页打开时，移动终端300可以读取待投屏浏览器对应的浏览器类型，经检测，如果第一浏览器类型列表包含该浏览器类型，即待投屏浏览器的浏览器类型在第一浏览器类型列表中，可以确定待投屏浏览器的浏览器类型为第一浏览器类型。示例性的，第一浏览器类型可以为有手势线程要求的浏览器类型，针对有手势线程要求的浏览器，移动终端可以在待投屏浏览器的网页打开时与显示设备200执行网络连接与指令协商，但是暂不执行屏幕录制与传输操作，可以在待投屏浏览器网页上显示用于执行投屏的按钮和控件等，基于对该按钮或控件的确定事件再发起投屏操作。

相反，如果第一浏览器类型列表不包括浏览器类型，即待投屏浏览器的浏览器类型不在第一浏览器类型列表中，则可以确定待投屏浏览器的浏览器类型为第二浏览器类型。示例性的，第二浏览器类型可以为没有手势线程要求的浏览器类型，针对没有手势线程要求的浏览器类型，可以通过浏览器直接向显示设备200发起投屏连接，例如，移动终端300可以向显示设备200发起网络连接与显示设备200进行指令协商，之后直接执行屏幕录制与传输，以实现移动终端300与显示设备200之间的投屏操作。

继续参见图8，在待投屏浏览器的浏览器类型确定完成后，如果浏览器类型为第一浏览器类型，移动终端300可以控制显示单元310显示用于向显示设备200发起投屏的操作控件，以及，基于操作控件向显示设备200执行投屏连接。图10为本申请一些实施例提供的第一浏览器类型的待投屏浏览器向显示设备发起投屏的操作控件效果示意图，如图10所示，针对第一浏览器类型的待投屏浏览器，可以在待投屏浏览器中设置用于向显示设备200发起投屏的操作控件101，例如，该操作控件101的命名可以为开始投屏。同时，为了便于对该操作控件的监控，可以为该控件设置监听流程，这样，只有在该操作控件产生手势线程后，才执行向显示设备200发起投屏的操作，否则不发起投屏操作。如果浏览器类型为第二浏览器类型，则待投屏浏览器不要求手势线程，则移动终端300可以通过待投屏浏览器直接向显示设备200发起投屏连接。

示例性的，通过第一浏览器类型的待投屏浏览器向显示设备200发起投屏连接时，响应于用户点击开始投屏的操作控件后，会向显示设备200发起执行屏幕录制权限的申请。显示设备200端允许后，移动终端300才开始录制屏幕画面。可以理解的是，如果显示设备200端不允许，则移动终端300将不执行屏幕画面录制等操作。

在一些实施例中，移动终端300在向显示设备200申请投屏时，可以向显示设备200发起指令协商。同时可以将移动终端300的设备名称、浏览器型号等信息发送到显示设备200。显示设备200会返回是否允许投屏的结果，如果显示设备200返回的是允许投屏的结果，则移动终端300可以与显示设备200进行投屏数据内容的协商。示例性的，待投屏浏览器可以遍历预置的媒资格式列表，选择出可支持的媒资格式，然后将支持的分辨率、帧率、支持的视频流等媒资格式信息发送给显示设备200，发送完成后，接收显示设备200协商返回的媒资格式。步骤S4执行完成后可以执行如下步骤S5。

步骤S5：响应于投屏连接成功的事件，移动终端300通过待投屏浏览器向显示设备200发送投屏数据，以使显示设备200显示投屏数据。

移动终端300根据浏览器类型向显示设备200发起投屏连接后，响应于投屏连接成功的事件，移动终端300可以通过待投屏浏览器向显示设备200发送投屏数据，以使显示设备200显示投屏数据。

图11为本申请一些实施例提供的移动终端执行通过待投屏浏览器向显示设备200发送投屏数据的流程示意图，如图11所示，移动终端300在生成投屏数据时，针对无手势线程要求的浏览器类型，可以基于待投屏浏览器直接录制屏幕数据，或者，针对有手势线程要求的浏览器类型，可以基于对操作控件的确认投屏事件，再录制屏幕数据。屏幕数据录制完成后，可以对屏幕数据进行编码，以生成投屏数据，最后，移动终端300向显示设备200发送该投屏数据。这样，显示设备200在接收到投屏数据后，即可控制显示器260显示投屏数据。

由以上技术方案可知，上述实施例提供的移动终端300可以获取待投屏浏览器的浏览器地址，以及，基于浏览器地址向显示设备200发送获取浏览器网页内容的网页内容请求；接收显示设备200根据网页内容请求返回的回执信息；解析回执信息，以得到待投屏浏览器的浏览器类型；根据浏览器类型向显示设备200发起投屏连接；响应于投屏连接成功的事件，通过待投屏浏览器向显示设备200发送投屏数据，以使显示设备200显示投屏数据。通过上述移动终端300，针对无手势线程要求的浏览器类型，可以基于待投屏浏览器直接录制屏幕数据，或者，针对有手势线程要求的浏览器类型，可以基于对操作控件的确认投屏事件，再录制屏幕数据。屏幕数据录制完成后，可以对屏幕数据进行编码，以生成投屏数据。上述移动终端300可以根据不同的浏览器类型执行不同的投屏方式，进而提升浏览器的兼容性。

图12为本申请一些实施例提供的移动终端通过另外一种方式向显示设备发起投屏连接的流程示意图，如图12所示，在上述实施例中，移动终端300是通过预先制定第一浏览器类型列表、读取待投屏浏览器对应的浏览器类型来判断是自动发起浏览器投屏还是通过操作控件来发起投屏的。但是，在一些实施例中，浏览器在实际使用过程中是会升级的，则对应的投屏方式也会有所改变。示例性的，原不要求手势线程的浏览器新增了要求手势线程，或者，原有手势线程要求的浏览器修改为了不要求手势线程，但是，预先指定的第一浏览器类型列表是固定的，则当浏览器类型发生变化时，根据第一浏览器类型匹配的方法将不再适用。

为了兼容浏览器类型发生变化的情况，在一些实施例中，移动终端300可以获取待投屏浏览器的型号信息和版本信息，响应于待投屏浏览器的启动事件，移动终端300可以将待投屏浏览器的型号信息和版本信息上传至服务器400。其中，服务器400中存储有用于表示有手势线程要求的第一标识和用于表示没有手势线程要求的第二标识，之后，移动终端300可以根据型号信息和版本信息检测待投屏浏览器对应的标识，如果待投屏浏览器对应的标识为第一标识，移动终端300可以控制显示单元310显示用于向显示设备200发起投屏的操作控件，以及，基于该操作控件向显示设备200执行投屏连接；如果待投屏浏览器对应的标识为第二标识，则移动终端300可以通过待投屏浏览器向显示设备200发起投屏连接。

示例性的，可以在服务器400对浏览器配置不同的版本信息和型号信息，且该版本信息和型号信息是不断更新的。这样，当移动终端300发起投屏时，可以获取待投屏浏览器的型号信息和版本信息，例如待投屏浏览器的型号信息和版本信息为(A浏览器，90)，并将(A浏览器，90)的信息发送到服务器400。经检测，服务器400存储的有关A浏览器的信息为(A浏览器，90，false)，其中false可以用来表示无手势线程要求的标识，则服务器400可以将(A浏览器，90，false)的信息返回给移动终端300。移动终端300在接收到该反馈信息后，即可直接通过待投屏浏览器向显示设备200发起投屏连接。

可以理解的是，浏览器类型是会变化的，当检测到服务器400中存储的A浏览器的信息变为(A浏览器，90，true)时，则true代表待投屏浏览器是有手势线程要求的，则此时移动终端300可以控制显示单元310显示用于向显示设备200发起投屏的操作控件，之后，基于对操作控件的点击操作向显示设备200发起投屏连接。

图13为本申请一些实施例提供的移动终端通过又一种方式向显示设备发起投屏连接的流程示意图，如图13所示，在另一些实施例中，移动终端300还可以通过如下方式向显示设备200发起投屏连接。响应于待投屏浏览器的打开事件，移动终端300可以向显示设备200发送协商指令，并根据该协商指令向显示设备200发起投屏连接，以及，监听投屏连接的投屏结果。如果投屏结果不包含错误信息，移动终端300可以基于待投屏浏览器录制屏幕数据，以生成投屏数据，并向显示设备200发送投屏数据，以使显示设备200显示投屏数据。而如果投屏结果中包含错误信息，移动终端300可以识别错误信息的错误类别，检测到错误类别为预设类别，移动终端300可以控制显示单元310显示用于向显示设备200发起投屏的操作控件，以及，基于操作控件向显示设备200发起投屏连接；响应于投屏连接成功的事件，通过待投屏浏览器向显示设备200发送投屏数据，以使显示设备200显示投屏数据。

示例性的，移动终端300在打开待投屏浏览器的网页时，可以与显示设备200建立网络连接，并执行网络连接与指令协商。协商成功后，移动终端300可以自动向显示设备200发起投屏，同时监听投屏的结果。如果该投屏结果不包含错误信息，则说明待投屏浏览器支持自动发起投屏，则移动终端300可以开始屏幕数据、编码等以生成投屏数据，并将投屏数据发送给显示设备200，以使显示设备200显示移动终端300发送的投屏数据。相反，如果投屏结果包含错误信息，则可以识别错误信息的类别。例如，错误信息的预设类别可以为，当在有手势线程要求的浏览器中直接发起投屏时，会提示错误信息。这样，如果是此类错误，则移动终端300可以控制显示单元310显示用于向显示设备200发起投屏的操作控件，并基于该操作控件向显示设备200发起投屏连接，同时，响应于投屏连接成功的事件，移动终端300可以通过待投屏浏览器向显示设备200发送投屏数据，以使显示设备200显示投屏数据。在一些实施例中，如果错误信息不是预设类别，则可以显示具体的错误信息提示。

本申请部分实施例还提供一种根据浏览器进行投屏的方法，该方法可以应用于移动终端300，移动终端300包括显示单元310、通信单元320和处理器330。在一些实施例中，根据浏览器进行投屏的方法可以包括如下内容：

移动终端300获取待投屏浏览器的浏览器地址，以及，基于浏览器地址向显示设备200发送获取浏览器网页内容的网页内容请求；

移动终端300接收显示设备200根据网页内容请求返回的回执信息；

移动终端300解析回执信息，以得到待投屏浏览器的浏览器类型；

移动终端300根据浏览器类型向显示设备200发起投屏连接；

响应于投屏连接成功的事件，移动终端300通过待投屏浏览器向显示设备200发送投屏数据，以使显示设备200显示投屏数据。

由以上技术方案可知，上述实施例提供的根据浏览器进行投屏的方法，针对无手势线程要求的浏览器类型，可以基于待投屏浏览器直接录制屏幕数据，或者，针对有手势线程要求的浏览器类型，可以基于对操作控件的确认投屏事件，再录制屏幕数据。屏幕数据录制完成后，可以对屏幕数据进行编码，以生成投屏数据。本申请可以根据不同的浏览器类型执行不同的投屏方式，进而提升浏览器的兼容性。

本申请部分实施例还提供一种显示设备200，在一些实施例中，显示设备200可以包括显示器260、通信器220和控制器250。图14为本申请一些实施例提供的显示设备执行显示投屏数据的流程示意图，如图14所示，其中，显示器260被配置为显示投屏界面，通信器220被配置为与移动终端300建立投屏连接，控制器250被配置为执行如下流程：

显示设备200接收移动终端300发送的网页内容请求，其中，该网页内容请求是移动终端300基于浏览器地址向显示设备200发送的获取浏览器网页内容的请求；

显示设备200根据网页内容请求生成回执信息，以及将回执信息发送至移动终端300，该回执信息中包括浏览器类型；

显示设备200接收移动终端300根据浏览器类型发送的投屏连接；

响应于投屏连接成功的事件，显示设备200接收移动终端300发送的投屏数据，以及，控制显示器260显示投屏数据。

由以上技术方案可知，上述实施例提供的显示设备200可以接收移动终端300发送的网页内容请求，并。根据网页内容请求生成回执信息，以及将回执信息发送至移动终端300。其中，该回执信息是包括浏览器类型的，之后，显示设备200可以接收移动终端300根据浏览器类型发送的投屏连接，响应于投屏连接成功的事件，显示设备200可以接收移动终端300发送的投屏数据，以及控制显示器260显示投屏数据。本申请可以根据移动终端300不同的浏览器类型执行不同的投屏方式，通过移动终端300与显示设备200配合，进而提升浏览器的兼容性。

图15为本申请一些实施例提供的显示设备与移动终端协商流程示意图，如图15所示，在一些实施例中，显示设备200可以接收移动终端300发送的协商指令，并根据协商指令筛选待投屏数据的数据格式。示例性的，示例性的，待投屏浏览器可以遍历预置的媒资格式列表，选择出可支持的媒资格式，然后将支持的分辨率、帧率、支持的视频流等媒资格式信息发送给显示设备200。发送完成后，显示设备200接收到移动终端300发送的格式信息后，显示设备200可以选择适合的媒体分辨率、帧率、格式等信息，并返回给移动终端300，以使移动终端300根据数据格式基于待投屏数据生成投屏数据。

在一些实施例中，显示设备200在选择媒资格式时，可以根据如下规则选择。例如，媒体格式需要选择显示设备200支持的最优播放格式，分辨率帧率可以在网络较好时选高分辨率高帧率，在网络较差时，如果画质优先，则可以选高分辨率低帧率，如果流畅度优先，则可以选低分辨率高帧率等策略。

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

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

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

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