CN111935510B - 一种双浏览器应用加载方法及显示设备 - Google Patents

Abstract

本申请提供一种双浏览器应用加载方法及显示设备，该方法包括：在用户选择的视频播放操作的情况下，第一浏览器通知下载代理预下载与视频的片源信息相关的视频资源，并在获取下载代理反馈的会话ID后，触发第二浏览器启动并加载视频播放应用，且通过会话ID和片源信息，持续从下载代理中获取预下载的视频资源，以在视频播放应用中播放。本申请不再使用单一的浏览器，而是采用双浏览器，在用户浏览信息时，采用资源占用低的第一浏览器；在用户观看视频时，采用观看视频的第二浏览器。因此，应用本申请提供的技术方案，可以缩短投屏流程的时间，进而能够提高投屏效率。

Description

一种双浏览器应用加载方法及显示设备

技术领域

本申请涉及通信技术领域，特别涉及一种双浏览器应用加载方法及显示设备。

背景技术

在电视平台上，内存、CPU、网络等资源是非常重要的。如何合理的利用这些资源对于提高电视平台的可用性和提升用户体验有着非常重要的意义。

然而，现有的电视平台主要基于浏览器加载应用，以使用户通过浏览器加载的应用浏览页面信息和播放视频。但现有技术中电视通常内设一个既能够用于加载浏览信息应用又能够加载视频播放应用的浏览器，这样，用户可以通过该浏览器既能够浏览信息又能够观看视频，但是，现有兼备浏览信息和观看视频功能的浏览器，在运行时，资源占用高，无论在浏览信息还是观看视频时，均会无差别启动并运行，这样，在浏览信息时，就会造成没有必要的资源消耗，且加载浏览信息应用慢，进而使得与用户交互性差，从而也造成用户体验差。

发明内容

有鉴于此，本申请提供双浏览器应用加载的方法及显示设备，以在提高加载应用速度的基础上，还能够提高与用户的交互性。

具体地，本申请是通过如下技术方案实现的：

第一方面，本申请提供了一种显示设备，包括：

显示器；

与所述显示器耦合的控制器，所述控制器内设有用于加载信息浏览应用的第一浏览器、用于加载视频播放应用的第二浏览器和下载代理，且所述第一浏览器内设有用于与下载代理会话的第一插件，所述第二浏览器内设有用于与下载代理会话的第二插件，所述第一浏览器用于执行：

响应于用户选择的视频播放操作，获取与所述视频对应的片源信息；

向所述下载代理通过所述第一插件发送第一会话信息，所述第一会话信息用于使所述下载代理预下载与所述片源信息相关的视频资源，并在通过自有服务器验证后，回应第二会话信息；

从所述第二会话信息中获取会话ID，并向所述第二浏览器发送所述片源信息和会话ID，以使所述第二浏览器根据所述片源信息和所述会话ID，启动并加载视频播放应用，并通过所述第二插件持续从所述下载代理中获取预下载的视频资源，以同时在所述视频播放应用中播放视频资源中的视频。

第二方面，本申请提供了一种双浏览器应用加载方法，应用于第一方面的显示设备中的第一浏览器，该方法包括：

响应于用户选择的视频播放操作，获取与所述视频对应的片源信息；

向所述下载代理通过所述第一插件发送第一会话信息，所述第一会话信息用于使所述下载代理预下载与所述片源信息相关的视频资源，并在通过自有服务器验证后，回应第二会话信息；

从所述第二会话信息中获取会话ID，并向所述第二浏览器发送所述片源信息和会话ID，以使所述第二浏览器根据所述片源信息和所述会话ID，启动并加载视频播放应用，并通过所述第二插件持续从所述下载代理中获取预下载的视频资源，以同时在所述视频播放应用中播放视频资源中的视频。

第三方面，本申请提供了一种双浏览器应用加载方法，应用于第一方面的显示设备中的第二浏览器，该方法包括：

获取第一浏览器发送的片源信息和会话ID，所述片源信息是第一浏览器响应于用户选择的视频播放操作，获取的与所述视频对应的信息；所述会话ID是下载代理在获取第一浏览器通过第一插件发送的第一会话信息后，向自有服务器发送验证，并在验证成功后，生成的用于回应第一浏览器第二会话信息的会话ID；所述第一会话信息是用于指示所述下载代理预下载与所述片源信息相关的视频资源；

在获取所述片源信息和所述会话ID后，启动并加载视频播放应用；

向所述下载代理通过所述第二插件发送所述片源信息和所述会话ID，以根据所述片源信息和所述会话ID，持续从所述下载代理中获取预下载的视频资源，以同时在所述视频播放应用中播放视频资源中的视频。

第四方面，本申请提供了一种双浏览器应用加载方法，应用于第一方面的显示设备中的下载代理，该方法包括：

在接收所述第一浏览器通过所述第一插件发送的第一会话信息后，向自有服务器发送验证信息；所述第一会话信息包括片源信息，所述片源信息是所述第一浏览器响应于用户选择的视频播放操作，获取的与所述视频相关的信息；

在验证通过后，生成与所述第一会话信息对应的会话ID，并向自有服务器请求预下载与所述片源信息相关的视频资源并保存，同时，向所述第一浏览器发送包括会话ID的第二会话信息，以使所述第一浏览器向所述第二浏览器发送所述会话ID和所述片源信息，触发所述第二浏览器件启动并加载视频播放应用，以根据所述会话ID和所述片源信息，持续从所述下载代理中获取预下载的视频资源，并同时在所述视频播放应用中播放视频资源中的视频。

由以上技术方案可以看出，本申请中，在用户选择的视频播放操作的情况下，第一浏览器通知下载代理预下载与视频的片源信息相关的视频资源，并在获取下载代理反馈的会话ID后，触发第二浏览器启动并加载视频播放应用，且通过会话ID和片源信息，持续从下载代理中获取预下载的视频资源，以在视频播放应用中播放。相对于现有技术，本申请不再使用单一的浏览器，而是采用双浏览器，在用户浏览信息时，采用资源占用低的第一浏览器；在用户观看视频时，采用观看视频的第二浏览器，同时，建立第一浏览器和第二浏览器与下载代理的会话机制，以从下载代理中预下载用户所观看视频的视频资源，使得用户在选择观看视频时，便能够快速地且无间断地在第二浏览器加载的视频播放应用中观看视频。可见，不仅能够提高应用加载速度，还能够提高与用户的交互性。

附图说明

图1中示例性示出了根据一些实施例的显示设备与控制装置之间操作场景的示意图；

图2中示例性示出了根据一些实施例的显示设备200的硬件配置框图；

图3中示例性示出了根据一些实施例的控制设备100的硬件配置框图；

图4中示例性示出了根据一些实施例的显示设备200中软件配置示意图；

图5中示例性示出了根据一些实施例的显示设备200中应用程序的图标控件界面显示示意图；

图6中示例性示出了根据一些实施例的应用在第一浏览器上的双浏览器应用加载方法的第一种实现流程图；

图7中示例性示出了根据一些实施例的应用在第一浏览器上的双浏览器应用加载方法的第二种实现流程图；

图8中示例性示出了根据一些实施例的应用在第二浏览器上的双浏览器应用加载方法的实现流程图；

图9中示例性示出了根据一些实施例的应用在下载代理上的双浏览器应用加载方法的实现流程图；

图10中示例性示出了根据一些实施例的双浏览器应用加载的交互示意图。

具体实施方式

为使本申请的目的、实施方式和优点更加清楚，下面将结合本申请示例性实施例中的附图，对本申请示例性实施方式进行清楚、完整地描述，显然，所描述的示例性实施例仅是本申请一部分实施例，而不是全部的实施例。

基于本申请描述的示例性实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请所附权利要求保护的范围。此外，虽然本申请中公开内容按照示范性一个或几个实例来介绍，但应理解，可以就这些公开内容的各个方面也可以单独构成一个完整实施方式。

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

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

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

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

本申请中使用的术语“遥控器”，是指电子设备(如本申请中公开的显示设备)的一个组件，通常可在较短的距离范围内无线控制电子设备。一般使用红外线和/或射频(RF)信号和/或蓝牙与电子设备连接，也可以包括WiFi、无线USB、蓝牙、动作传感器等功能模块。例如：手持式触摸遥控器，是以触摸屏中用户界面取代一般遥控装置中的大部分物理内置硬键。

本申请中使用的术语“手势”，是指用户通过一种手型的变化或手部运动等动作，用于表达预期想法、动作、目的/或结果的用户行为。

图1中示例性示出了根据实施例中显示设备与控制装置之间操作场景的示意图。如图1中示出，用户可通过移动终端300和控制装置100操作显示设备200。

在一些实施例中，控制装置100可以是遥控器，遥控器和显示设备的通信包括红外协议通信或蓝牙协议通信，及其他短距离通信方式等，通过无线或其他有线方式来控制显示设备200。用户可以通过遥控器上按键，语音输入、控制面板输入等输入用户指令，来控制显示设备200。如：用户可以通过遥控器上音量加减键、频道控制键、上/下/左/右的移动按键、语音输入按键、菜单键、开关机按键等输入相应控制指令，来实现控制显示设备200的功能。

在一些实施例中，也可以使用移动终端、平板电脑、计算机、笔记本电脑、和其他智能设备以控制显示设备200。例如，使用在智能设备上运行的应用程序控制显示设备200。该应用程序通过配置可以在与智能设备关联的屏幕上，在直观的用户界面(UI)中为用户提供各种控制。

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

如图1中还示出，显示设备200还与服务器400通过多种通信方式进行数据通信。可允许显示设备200通过局域网(LAN)、无线局域网(WLAN)和其他网络进行通信连接。服务器400可以向显示设备200提供各种内容和互动。示例的，显示设备200通过发送和接收信息，以及电子节目指南(EPG)互动，接收软件程序更新，或访问远程储存的数字媒体库。服务器400可以是一个集群，也可以是多个集群，可以包括一类或多类服务器。通过服务器400提供视频点播和广告服务等其他网络服务内容。

显示设备200，可以液晶显示器、OLED显示器、投影显示设备。具体显示设备类型，尺寸大小和分辨率等不作限定，本领技术人员可以理解的是，显示设备200可以根据需要做性能和配置上一些改变。

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

图2中示例性示出了根据示例性实施例中显示设备200的硬件配置框图。

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

在一些实施例中，显示器275，用于接收源自第一处理器输出的图像信号，进行显示视频内容和图像以及菜单操控界面的组件。

在一些实施例中，显示器275，包括用于呈现画面的显示屏组件，以及驱动图像显示的驱动组件。

在一些实施例中，显示视频内容，可以来自广播电视内容，也可以是说，可通过有线或无线通信协议接收的各种广播信号。或者，可显示来自网络通信协议接收来自网络服务器端发送的各种图像内容。

在一些实施例中，显示器275用于呈现显示设备200中产生且用于控制显示设备200的用户操控UI界面。

在一些实施例中，根据显示器275类型不同，还包括用于驱动显示的驱动组件。

在一些实施例中，显示器275为一种投影显示器，还可以包括一种投影装置和投影屏幕。

在一些实施例中，通信器220是用于根据各种通信协议类型与外部设备或外部服务器进行通信的组件。例如：通信器可以包括Wifi芯片，蓝牙通信协议芯片，有线以太网通信协议芯片等其他网络通信协议芯片或近场通信协议芯片，以及红外接收器中的至少一种。

在一些实施例中，显示设备200可以通过通信器220与外部控制设备100或内容提供设备之间建立控制信号和数据信号发送和接收。

在一些实施例中，用户接口265，可用于接收控制装置100(如：红外遥控器等)红外控制信号。

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

在一些实施例中，检测器230包括光接收器，用于采集环境光线强度的传感器，可以通过采集环境光可以自适应性显示参数变化等。

在一些实施例中，检测器230还可以包括图像采集器，如相机、摄像头等，可以用于采集外部环境场景，以及用于采集用户的属性或与用户交互手势，可以自适应变化显示参数，也可以识别用户手势，以实现与用户之间互动的功能。

在一些实施例中，检测器230还可以包括温度传感器等，如通过感测环境温度。

在一些实施例中，显示设备200可自适应调整图像的显示色温。如当温度偏高的环境时，可调整显示设备200显示图像色温偏冷色调，或当温度偏低的环境时，可以调整显示设备200显示图像偏暖色调。

在一些实施例中，检测器230还可声音采集器等，如麦克风，可以用于接收用户的声音。示例性的，包括用户控制显示设备200的控制指令的语音信号，或采集环境声音，用于识别环境场景类型，使得显示设备200可以自适应适应环境噪声。

在一些实施例中，如图2所示，输入/输出接口255被配置为，可进行控制器250与外部其他设备或其他控制器250之间的数据传输。如接收外部设备的视频信号数据和音频信号数据、或命令指令数据等。

在一些实施例中，外部装置接口240可以包括，但不限于如下：可以高清多媒体接口HDMI接口、模拟或数据高清分量输入接口、复合视频输入接口、USB输入接口、RGB端口等任一个或多个接口。也可以是上述多个接口形成复合性的输入/输出接口。

在一些实施例中，如图2所示，调谐解调器210被配置为，通过有线或无线接收方式接收广播电视信号，可以进行放大、混频和谐振等调制解调处理，从多多个无线或有线广播电视信号中解调出音视频信号，该音视频信号可以包括用户所选择电视频道频率中所携带的电视音视频信号，以及EPG数据信号。

在一些实施例中，调谐解调器210解调的频点受到控制器250的控制，控制器250可根据用户选择发出控制信号，以使的调制解调器响应用户选择的电视信号频率以及调制解调该频率所携带的电视信号。

在一些实施例中，广播电视信号可根据电视信号广播制式不同区分为地面广播信号、有线广播信号、卫星广播信号或互联网广播信号等。或者根据调制类型不同可以区分为数字调制信号，模拟调制信号等。或者根据信号种类不同区分为数字信号、模拟信号等。

在一些实施例中，控制器250和调谐解调器210可以位于不同的分体设备中，即调谐解调器210也可在控制器250所在的主体设备的外置设备中，如外置机顶盒等。这样，机顶盒将接收到的广播电视信号调制解调后的电视音视频信号输出给主体设备，主体设备经过第一输入/输出接口接收音视频信号。

在一些实施例中，控制器250，通过存储在存储器上中各种软件控制程序，来控制显示设备的工作和响应用户的操作。控制器250可以控制显示设备200的整体操作。例如：响应于接收到用于选择在显示器275上显示UI对象的用户命令，控制器250便可以执行与由用户命令选择的对象有关的操作。

在一些实施例中，所述对象可以是可选对象中的任何一个，例如超链接或图标。与所选择的对象有关操作，例如：显示连接到超链接页面、文档、图像等操作，或者执行与所述图标相对应程序的操作。用于选择UI对象用户命令，可以是通过连接到显示设备200的各种输入装置(例如，鼠标、键盘、触摸板等)输入命令或者与由用户说出语音相对应的语音命令。

如图2所示，控制器250包括随机存取存储器251(Random Access Memory，RAM)、只读存储器252(Read-Only Memory,ROM)、视频处理器270、音频处理器280、其他处理器253(例如：图形处理器(Graphics Processing Unit，GPU)、中央处理器254(CentralProcessing Unit，CPU)、通信接口(Communication Interface)，以及通信总线256(Bus)中的至少一种。其中，通信总线连接各个部件。

在一些实施例中，RAM 251用于存储操作系统或其他正在运行中的程序的临时数据

在一些实施例中，ROM 252用于存储各种系统启动的指令。

在一些实施例中，ROM 252用于存储一个基本输入输出系统，称为基本输入输出系统(Basic Input Output System，BIOS)。用于完成对系统的加电自检、系统中各功能模块的初始化、系统的基本输入/输出的驱动程序及引导操作系统。

在一些实施例中，在收到开机信号时，显示设备200电源开始启动，CPU运行ROM252中系统启动指令，将存储在存储器的操作系统的临时数据拷贝至RAM 251中，以便于启动或运行操作系统。当操作系统启动完成后，CPU再将存储器中各种应用程序的临时数据拷贝至RAM 251中,然后，以便于启动或运行各种应用程序。

在一些实施例中，CPU处理器254，用于执行存储在存储器中操作系统和应用程序指令。以及根据接收外部输入的各种交互指令，来执行各种应用程序、数据和内容，以便最终显示和播放各种音视频内容。

在一些示例性实施例中，CPU处理器254，可以包括多个处理器。多个处理器可包括一个主处理器以及一个或多个子处理器。主处理器，用于在预加电模式中执行显示设备200一些操作，和/或在正常模式下显示画面的操作。一个或多个子处理器，用于在待机模式等状态下一种操作。

在一些实施例中，图形处理器253，用于产生各种图形对象，如：图标、操作菜单、以及用户输入指令显示图形等。包括运算器，通过接收用户输入各种交互指令进行运算，根据显示属性显示各种对象。以及包括渲染器，对基于运算器得到的各种对象，进行渲染，上述渲染后的对象用于显示在显示器上。

在一些实施例中，视频处理器270被配置为将接收外部视频信号，根据输入信号的标准编解码协议，进行解压缩、解码、缩放、降噪、帧率转换、分辨率转换、图像合成等等视频处理，可得到直接可显示设备200上显示或播放的信号。

在一些实施例中，视频处理器270，包括解复用模块、视频解码模块、图像合成模块、帧率转换模块、显示格式化模块等。

其中，解复用模块，用于对输入音视频数据流进行解复用处理，如输入MPEG-2,则解复用模块进行解复用成视频信号和音频信号等。

视频解码模块，则用于对解复用后的视频信号进行处理，包括解码和缩放处理等。

图像合成模块，如图像合成器，其用于将图形生成器根据用户输入或自身生成的GUI信号，与缩放处理后视频图像进行叠加混合处理，以生成可供显示的图像信号。

帧率转换模块，用于对转换输入视频帧率，如将60Hz帧率转换为120Hz帧率或240Hz帧率，通常的格式采用如插帧方式实现。

显示格式化模块，则用于将接收帧率转换后视频输出信号，改变信号以符合显示格式的信号，如输出RGB数据信号。

在一些实施例中，图形处理器253可以和视频处理器可以集成设置，也可以分开设置，集成设置的时候可以执行输出给显示器的图形信号的处理，分离设置的时候可以分别执行不同的功能，例如GPU+FRC(Frame Rate Conversion))架构。

在一些实施例中，音频处理器280，用于接收外部的音频信号，根据输入信号的标准编解码协议，进行解压缩和解码，以及降噪、数模转换、和放大处理等处理，得到可以在扬声器中播放的声音信号。

在一些实施例中，视频处理器270可以包括一颗或多颗芯片组成。音频处理器，也可以包括一颗或多颗芯片组成。

在一些实施例中，视频处理器270和音频处理器280，可以单独的芯片，也可以于控制器一起集成在一颗或多颗芯片中。

在一些实施例中，音频输出，在控制器250的控制下接收音频处理器280输出的声音信号，如：扬声器286，以及除了显示设备200自身携带的扬声器之外，可以输出至外接设备的发生装置的外接音响输出端子，如：外接音响接口或耳机接口等，还可以包括通信接口中的近距离通信模块，例如：用于进行蓝牙扬声器声音输出的蓝牙模块。

供电电源290，在控制器250控制下，将外部电源输入的电力为显示设备200提供电源供电支持。供电电源290可以包括安装显示设备200内部的内置电源电路，也可以是安装在显示设备200外部电源，在显示设备200中提供外接电源的电源接口。

用户接口265，用于接收用户的输入信号，然后，将接收用户输入信号发送给控制器250。用户输入信号可以是通过红外接收器接收的遥控器信号，可以通过网络通信模块接收各种用户控制信号。

在一些实施例中，用户通过控制装置100或移动终端300输入用户命令，用户输入接口则根据用户的输入，显示设备200则通过控制器250响应用户的输入。

在一些实施例中，用户可在显示器275上显示的图形用户界面(GUI)输入用户命令，则用户输入接口通过图形用户界面(GUI)接收用户输入命令。或者，用户可通过输入特定的声音或手势进行输入用户命令，则用户输入接口通过传感器识别出声音或手势，来接收用户输入命令。

在一些实施例中，“用户界面”，是应用程序或操作系统与用户之间进行交互和信息交换的介质接口，它实现信息的内部形式与用户可以接受形式之间的转换。用户界面常用的表现形式是图形用户界面(Graphic User Interface，GUI)，是指采用图形方式显示的与计算机操作相关的用户界面。它可以是在电子设备的显示屏中显示的一个图标、窗口、控件等界面元素，其中控件可以包括图标、按钮、菜单、选项卡、文本框、对话框、状态栏、导航栏、Widget等可视的界面元素。

存储器260，包括存储用于驱动显示设备200的各种软件模块。如：第一存储器中存储的各种软件模块，包括：基础模块、检测模块、通信模块、显示控制模块、浏览器模块、和各种服务模块等中的至少一种。

基础模块用于显示设备200中各个硬件之间信号通信、并向上层模块发送处理和控制信号的底层软件模块。检测模块用于从各种传感器或用户输入接口中收集各种信息，并进行数模转换以及分析管理的管理模块。

例如，语音识别模块中包括语音解析模块和语音指令数据库模块。显示控制模块用于控制显示器进行显示图像内容的模块，可以用于播放多媒体图像内容和UI界面等信息。通信模块，用于与外部设备之间进行控制和数据通信的模块。浏览器模块，用于执行浏览服务器之间数据通信的模块。服务模块，用于提供各种服务以及各类应用程序在内的模块。同时，存储器260还用存储接收外部数据和用户数据、各种用户界面中各个项目的图像以及焦点对象的视觉效果图等。

图3示例性示出了根据示例性实施例中控制设备100的配置框图。如图3所示，控制设备100包括控制器110、通信接口130、用户输入/输出接口、存储器、供电电源。

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

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

在一些实施例中，如图1所示，移动终端300或其他智能电子设备，可在安装操控显示设备200的应用之后，可以起到控制设备100类似功能。如：用户可以通过安装应用，在移动终端300或其他智能电子设备上可提供的图形用户界面的各种功能键或虚拟按钮，以实现控制设备100实体按键的功能。

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

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

用户输入/输出接口140，其中，输入接口包括麦克风141、触摸板142、传感器143、按键144等其他输入接口中至少一者。如：用户可以通过语音、触摸、手势、按压等动作实现用户指令输入功能，输入接口通过将接收的模拟信号转换为数字信号，以及数字信号转换为相应指令信号，发送至显示设备200。

输出接口包括将接收的用户指令发送至显示设备200的接口。在一些实施例中，可以红外接口，也可以是射频接口。如：红外信号接口时，需要将用户输入指令按照红外控制协议转化为红外控制信号，经红外发送模块进行发送至显示设备200。再如：射频信号接口时，需将用户输入指令转化为数字信号，然后按照射频控制信号调制协议进行调制后，由射频发送端子发送至显示设备200。

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

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

供电电源180，用于在控制器的控制下为控制设备100各元件提供运行电力支持。可以电池及相关控制电路。

在一些实施例中，系统可以包括内核(Kernel)、命令解析器(shell)、文件系统和应用程序。内核、shell和文件系统一起组成了基本的操作系统结构，它们让用户可以管理文件、运行程序并使用系统。上电后，内核启动，激活内核空间，抽象硬件、初始化硬件参数等，运行并维护虚拟内存、调度器、信号及进程间通信(IPC)。内核启动后，再加载Shell和用户应用程序。应用程序在启动后被编译成机器码，形成一个进程。

参见图4，在一些实施例中，将系统分为四层，从上至下分别为应用程序(Applications)层(简称“应用层”)，应用程序框架(Application Framework)层(简称“框架层”)，安卓运行时(Android runtime)和系统库层(简称“系统运行库层”)，以及内核层。

在一些实施例中，应用程序层中运行有至少一个应用程序，这些应用程序可以是操作系统自带的窗口(Window)程序、系统设置程序、时钟程序、相机应用等；也可以是第三方开发者所开发的应用程序，比如嗨见程序、K歌程序、魔镜程序等。在具体实施时，应用程序层中的应用程序包不限于以上举例，实际还可以包括其它应用程序包，本申请实施例对此不做限制。

框架层为应用程序层的应用程序提供应用编程接口(application programminginterface，API)和编程框架。应用程序框架层包括一些预先定义的函数。应用程序框架层相当于一个处理中心，这个中心决定让应用层中的应用程序做出动作。应用程序通过API接口，可在执行中访问系统中的资源和取得系统的服务

如图4所示，本申请实施例中应用程序框架层包括管理器(Managers)，内容提供者(Content Provider)等，其中管理器包括以下模块中的至少一个：活动管理器(ActivityManager)用与和系统中正在运行的所有活动进行交互；位置管理器(Location Manager)用于给系统服务或应用提供了系统位置服务的访问；文件包管理器(Package Manager)用于检索当前安装在设备上的应用程序包相关的各种信息；通知管理器(NotificationManager)用于控制通知消息的显示和清除；窗口管理器(Window Manager)用于管理用户界面上的括图标、窗口、工具栏、壁纸和桌面部件。

在一些实施例中，活动管理器用于：管理各个应用程序的生命周期以及通常的导航回退功能，比如控制应用程序的退出(包括将显示窗口中当前显示的用户界面切换到系统桌面)、打开、后退(包括将显示窗口中当前显示的用户界面切换到当前显示的用户界面的上一级用户界面)等。

在一些实施例中，窗口管理器用于管理所有的窗口程序，比如获取显示屏大小，判断是否有状态栏，锁定屏幕，截取屏幕，控制显示窗口变化(例如将显示窗口缩小显示、抖动显示、扭曲变形显示等)等。

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

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

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

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

在一些实施例中，以魔镜应用(拍照应用)为例，当遥控接收装置接收到遥控器输入操作，相应的硬件中断被发给内核层。内核层将输入操作加工成原始输入事件(包括输入操作的值，输入操作的时间戳等信息)。原始输入事件被存储在内核层。应用程序框架层从内核层获取原始输入事件，根据焦点当前的位置识别该输入事件所对应的控件以及以该输入操作是确认操作，该确认操作所对应的控件为魔镜应用图标的控件，魔镜应用调用应用框架层的接口，启动魔镜应用，进而通过调用内核层启动摄像头驱动，实现通过摄像头捕获静态图像或视频。

在一些实施例中，对于具备触控功能的显示设备，以分屏操作为例，显示设备接收用户作用于显示屏上的输入操作(如分屏操作)，内核层可以根据输入操作产生相应的输入事件，并向应用程序框架层上报该事件。由应用程序框架层的活动管理器设置与该输入操作对应的窗口模式(如多窗口模式)以及窗口位置和大小等。应用程序框架层的窗口管理根据活动管理器的设置绘制窗口，然后将绘制的窗口数据发送给内核层的显示驱动，由显示驱动在显示屏的不同显示区域显示与之对应的应用界面。

在一些实施例中，如图5中所示，应用程序层包含至少一个应用程序可以在显示器中显示对应的图标控件，如：直播电视应用程序图标控件、视频点播应用程序图标控件、媒体中心应用程序图标控件、应用程序中心图标控件、游戏应用图标控件等。

在一些实施例中，直播电视应用程序，可以通过不同的信号源提供直播电视。例如，直播电视应用程序可以使用来自有线电视、无线广播、卫星服务或其他类型的直播电视服务的输入提供电视信号。以及，直播电视应用程序可在显示设备200上显示直播电视信号的视频。

在一些实施例中，视频点播应用程序，可以提供来自不同存储源的视频。不同于直播电视应用程序，视频点播提供来自某些存储源的视频显示。例如，视频点播可以来自云存储的服务器端、来自包含已存视频节目的本地硬盘储存器。

在一些实施例中，媒体中心应用程序，可以提供各种多媒体内容播放的应用程序。例如，媒体中心，可以为不同于直播电视或视频点播，用户可通过媒体中心应用程序访问各种图像或音频所提供服务。

在一些实施例中，应用程序中心，可以提供储存各种应用程序。应用程序可以是一种游戏、应用程序，或某些和计算机系统或其他设备相关但可以在智能电视中运行的其他应用程序。应用程序中心可从不同来源获得这些应用程序，将它们储存在本地储存器中，然后在显示设备200上可运行。

为了使本申请的目的、技术方案和优点更加清楚，下面结合附图和具体实施例对本申请进行详细描述。

在本申请中，上述显示设备的控制器内设有用于加载信息浏览应用的第一浏览器、用于加载视频播放应用的第二浏览器和下载代理，且第一浏览器内设有用于与下载代理会话的第一插件，第二浏览器内设有用于与下载代理会话的第二插件。

不同的浏览器在资源占用、视频播放能力方面具有不同的表现，而且往往不能兼顾。例如，Cobalt浏览器具备资源占用低、响应效率高的优点，但是播放视频能力差；视频播放浏览器具备完善的视频播放解决方案，但是会产生额外的资源消耗。

基于上述考虑，本申请实施例可以根据用户使用场景，充分发挥不同浏览器的特性，并加速自有媒资视频起播效率。例如，如果用户使用浏览器浏览信息时，则启动第一浏览器加载浏览信息应用；如果用户使用浏览器观看视频时，则启动第二浏览器加载视频播放应用。

为了降低资源消耗，加速显示设备的启动并提高用户操作的可交互性，本申请的第一浏览器采用用于加载浏览信息应用的、资源占用低的浏览器运行用户界面。基于此，结合上述对Cobalt浏览器的描述，第一浏览器可以采用Cobalt浏览器。

为了保证流媒体播放能力，第二浏览器可以使用具备流媒体播放能力的浏览器来进行视频播放。

由于第一浏览器和第二浏览器之间的通信，以及，第二浏览器加载播放视频应用和渲染播放页面时会存在一定的时间消耗，在这种情况下，本实施例利用下载代理来完成视频的预下载，以降低双浏览器切换以及视频播放应用的加载和渲染消耗的时间，从而提高视频起播的速度，为用户带来良好的体验。同时，由于双浏览器运行环境的特殊性，需要提供可靠的机制来保证双浏览器播放内容及播放行为的一致性，基于此，本申请采用第一插件和第二插件与下载代理进行会话机制，以保证双浏览器播放内容及播放行为的一致性，针对上述会话机制，本申请会针对具体实施例进行详细描述，在此，不再赘述。

下面对本申请实施例提供的双浏览器应用加载的方法进行描述：

第一方面，请参见图6，图6中示例性示出了根据一些实施例的双浏览器应用加载方法的流程示意图。图6所示流程的执行主体可以是上述的第一浏览器。且如图6所示，该流程可以包括以下步骤：

步骤101，响应于用户选择的视频播放操作，获取与视频对应的片源信息。

片源就是片子的来源处，也就是，视频的来源处。而片源信息可以理解为视频来源于何处的信息，也就是，原始剧本信息或源头视频信息。

用户在第一浏览器当前页面中选择视频播放的操作后，第一浏览器确定出用户所选择的视频，便可以获取该视频的片源信息。进而根据该片源信息，确定出该视频来源于何处的片源信息，这样，便可以根据片源信息，获取该视频的来源处，也就是片源，以从该视频的来源处下载该视频。

示例性的，假设用户在第一浏览器当前页面中点击了一部来源于网站A的电影，第一浏览器确定该电影，进而获取到该视频来源于网站A的片源信息，这样，便可以根据该视频来源于网站A的片源信息，从网站A下载该视频。

假设用户在第一浏览器当前页面中点击了来源于爱奇艺应用程序中电视剧甄嬛传第二集的视频，则第一浏览器便可根据甄嬛传第二集视频，获取到该视频的片源信息是来源于爱奇艺应用程序中甄嬛传第二集。这样，便可以根据该视频来源于爱奇艺应用程序中甄嬛传第二集的片源信息，从爱奇艺应用程序中下载该视频。

基于上述分析，可知，第一浏览器主要负责向用户在前台中展示页面，以供用户浏览。例如视频海报、资讯信息等。

本申请的一个实施例中，在步骤101之前，该方法还可以包括如下步骤：

如果用户触发的操作是视频播放操作，则执行步骤101。

其中，当用户在第一浏览器的当前页面中浏览信息时，上述用户触发的操作可能是浏览信息操作，也可能是视频播放操作。

基于此，一个实施例中，如果用户触发的操作是浏览信息操作，则第一浏览器响应于用户选择的浏览信息操作，获取与用户所选择的浏览信息对应的信息来源，并启动与该信息来源对应的应用，以在应用中浏览信息。

可见，在本申请实施例提供的技术方案中，不进行视频播放时，启动第一浏览器进行应用页面加载，此时，能够在满足用户浏览信息的需求上，实现极低的资源占用；且只有在需要进行视频播放时，才会启动第二浏览器加载应用页面并进行视频播放。

步骤102，向下载代理通过第一插件发送第一会话信息，第一会话信息用于使下载代理预下载与片源信息相关的视频资源，并在通过自有服务器验证后，回应第二会话信息。

在本申请中，第一浏览器与下载代理之间是通过第一插件进行交互的，也就是说，第一插件是作为下载代理和第一浏览器提供进行会话的接口，无论下载代理向第一浏览器发送信息，还是第一浏览器向下载代理发送信息，都要通过第一插件这个接口进行会话，例如，本实施例中的第一会话信息，就是通过第一插件转达至下载代理，以通知下载代理预下载与片源信息相关的视频资源。

上述第一浏览器在获取视频的片源信息后，便会形成包含片源信息的第一会话信息，该第一会话信息就是用于通知预下载与片源信息相关的视频资源。

上述自有服务器可以理解为显示设备可以自由下载且不受限制的服务器。后续将对自有服务器进行详细描述，在此不再赘述。

在本申请中，下载代理除去负责视频预加载的功能之外，同时，还可以起到视频防盗和流量控制等功能。

需求注意的是，下载代理是以独立的进程运行，并处理来自双浏览器的请求。

下载代理预下载与片源信息相关的视频资源可以理解为，在第二浏览器未启动和播放该视频时，提前下载该视频的视频资源，以备第二浏览器不再进行缓冲，而是直接播放，这样，可以提高第二浏览器加载视频播放应用播放视频的速度，为用户带来良好的体验效果。

下载代理在获取第一会话信息后，便会通过自有服务器对自身进行验证，自有服务器验证通过后，下载代理会生成一个会话ID。该会话ID可以表示为此会话是一条与片源信息相关的、且具有唯一性的会话。

需要说明的是，下载代理在接收到第一会话信息后，首先，通过自有服务器验证，待验证成功后，会生成会话ID，并立即向第一浏览器回应包含会话ID的第二会话信息。然后，才通过自有服务器下载与片源信息相关的视频资源。这样，可以保证第一浏览器能够及时获取第二会话信息中的会话ID，以便与第二浏览器进行交互。

步骤103，从第二会话信息中获取会话ID，并向第二浏览器发送片源信息和会话ID，以使第二浏览器根据片源信息和会话ID，启动并加载视频播放应用，并通过第二插件持续从下载代理中获取预下载的视频资源，以同时在视频播放应用中播放视频资源中的视频。

其中，上述视频播放应用就是用于播放视频的应用程序。

在本实施例中，鉴于片源信息对应的视频资源是从自有服务器下载获得的，则表明，片源信息是属于自有服务器运维的片源信息，这样，视频播放应用可以是本地所拥有的视频播放应用。

示例性的，假设该用户是海信集团，则视频播放应用可以是海信集团拥有的视频播放应用，以能够在不需要取得授权的情况下，直接播放从自有服务器下载的视频资源。

第二浏览器加载的视频播放应用可以是新创建的一个用于加载应用的窗口，也可以是在第二浏览器中当前页面中加载该视频播放应用，本实施例对此并不限定。

在一种实施例中，第一浏览器通过RPC(Romote Procedure Call，远程过程调用)调用向第二浏览器发送片源信息和会话ID。

第一浏览器通过RPC调用片源信息和会话ID的目的是告知第二浏览器进行视频播放。

需要说明的是，第一浏览器在向第二浏览器发送片源信息和会话ID时，下载代理已经开始下载视频流。也就是，下载代理在回应第二会话信息后，立即开始下载视频流，并存储在下载代理中，也就是本地中，以备第二浏览器从本地中下载视频资源并进行播放，从而实现能够非常快速的获取视频资源并能够连续播放视频。

另外，第二浏览器在收到片源信息和会话ID后，会立即启动并加载视频播放应用，此时，下载代理仍然在下载与片源信息相关的视频中。

同时，下载代理在预下载的视频资源的同时，会返回视频URL(Uniform ResourceLocator，统一资源定位器)，此视频URL为本地的视频URL，以备第二浏览器根据会话ID查询到视频URL对应的视频资源。

由上述分析得知，第一浏览器到第二浏览器的切换时间、以及第二浏览器加载视频播放应用的时间与下载代理从自有服务器下载与片源信息相关的视频流所使用的时间是同步进行的。

本申请的一个实施例中，响应于用户触发停止视频播放的操作，第二浏览器通过第二插件发送用于指示下载代理停止下载的指令信息，以使下载代理指示自有服务器停止下载。

在本申请中，下载代理除去负责视频预加载的功能之外，同时，还可以起到视频防盗和流量控制等功能。

需要注意的是，下载代理是以独立的进程运行，并处理来自双浏览器的请求。

由上述分析可知，由于预下载流程在第一浏览器中启动，而视频播放在第二浏览器中进行，这需要协同双浏览器的行为，保证播放内容的一致性和行为的一致性。由于浏览器本身的缓存只能应用在该浏览器，无法实现与其他浏览器的信息共享，也无法同步行为。因此，本申请利用下载代理实现了会话机制，来保证双浏览器下内容和行为的一致性。下载代理为双浏览器提供会话ID，而会话信息则缓存在下载代理中。任一浏览器通过会话id都能够获得一致的上下文环境。因此，这种会话机制能够保证上下文环境的数据共享和行为的同步。避免双浏览器产生不一致的内容和播放行为。

由此可见，在本申请实施例提供的技术方案中，在用户选择的视频播放操作的情况下，第一浏览器通知下载代理预下载与视频的片源信息相关的视频资源，并在获取下载代理反馈的会话ID后，触发第二浏览器启动并加载视频播放应用，且通过会话ID和片源信息，持续从下载代理中获取预下载的视频资源，以在视频播放应用中播放。相对于现有技术，本申请不再使用单一的浏览器，而是采用双浏览器，在用户浏览信息时，采用资源占用低的第一浏览器；在用户观看视频时，采用观看视频的第二浏览器，同时，建立第一浏览器和第二浏览器与下载代理的会话机制，以从下载代理中预下载用户所观看视频的视频资源，使得用户在选择观看视频时，便能够快速地且无间断地在第二浏览器加载的视频播放应用中观看视频。可见，不仅能够提高应用加载速度，还能够提高与用户的交互性。

本申请的一个实施例中，如图7所示，在步骤101之后，还可以包括如下步骤104～步骤105：

步骤104，如果确定片源信息属于自有服务器运维的片源信息，则执行步骤102；如果确定片源信息属于第三方服务器运维的片源信息，则执行步骤105。

基于上述分析可知，上述自有服务器可以理解为显示设备可以自由下载且不受限制的服务器。如，显示设备是属于用户A授权的产品，那么，用户A便可以自由从用户A所拥有的服务器中下载任何信息。

示例性的，假设自有服务器为海信集团的服务器，则海信集团的显示设备，则可以自由地从海信集团自身的服务器下载与片源信息相关的视频资源。

步骤105，向第二浏览器发送片源信息对应的视频URL，以使第二浏览器启动并加载视频播放应用，向自有服务器获取视频URL对应的视频资源，以在视频播放应用中播放视频资源中的视频。

与自有服务器相对的第三方服务器，基于此，上述片源信息属于第三方服务器可以理解为上述片源信息不属于自有服务器运维的片源信息。

基于上述示例，假设自有服务器是海信集团，则第三方服务器可能是爱奇艺所拥有的服务器、腾讯所拥有的服务器、优酷所拥有的服务器等，相对于海信集团而言，只有该服务器不是自身所拥有的服务器，则均属于第三服务器。

基于上述分析，针对用户选择视频的片源信息不属于自有服务器(属于第三方服务器)的片源信息，则相对于自有服务器而言，下载片源信息对应的视频资源，就没有那样自由，会受一定的限制。基于此，针对片源信息不属于自有服务器的片源信息的情况，就意味着，不能使用自身的下载代理向自有服务器下载与片源信息对应的视频资源，在使用第三方服务器进行下载视频资源时，可能存在视频资源交易，在交易达成后，便可以从第二方服务器中边下载视频资源，边观看视频。

在本步骤中，在用户选择的操作是视频播放操作时，第一浏览器响应于用户的视频播放操作，获取该视频的片源信息，并判断该片源是否属于自有服务器运维的片源信息，如果该片源信息不属于自身服务器运维的片源信息，第一浏览器则需要向第二浏览器发送片源信息对应的视频URL，这样，第二浏览器在获取视频URL后，触发第二浏览器启动并加载视频播放应用，并同时依据视频URL，从第三方服务器中下载片源信息对应的视频资源。

可见，在本申请实施例提供的技术方案中，在需要进行视频播放时，首先需要判断该视频对应的片源信息是否属于自有服务器运维的片源信息，针对属于自有服务器运维的片源信息，则使用下载代理从自有服务器中下载与该片源信息对应的视频资源，并在第二浏览器启动的视频播放应用中播放，能够在提高加载应用速度的基础上，还能够提高与用户的交互性。针对属于第三方服务器运维的片源信息，需要在启动第二浏览器加载应用页面的同时，需要向第三方服务器下载与该片源信息对应的视频资源，以在启动并运行的应用中进行视频播放，能够为用户提供观看视频的路径，以使用户最终均能观看视频。

第二方面，请参见图8，图8中示例性示出了根据一些实施例的双浏览器应用加载方法的流程示意图。图8所示流程的执行主体可以是上述的第二浏览器。且如图8所示，该流程可以包括以下步骤201～步骤203：

步骤201，获取第一浏览器发送的片源信息和会话ID，片源信息是第一浏览器响应于用户选择的视频播放操作，获取的与视频对应的信息；会话ID是下载代理在获取第一浏览器通过第一插件发送的第一会话信息后，向自有服务器发送验证，并在验证成功后，生成的用于回应第一浏览器第二会话信息的会话ID；第一会话信息是用于指示下载代理预下载与所述片源信息相关的视频资源。

其中，如前所述，上述片源信息可以理解为视频来源于何处的信息。会话ID是下载代理在收到包括片源信息的第一会话信息后，向自有服务器进行认证，认证合格后，生成的。

下载代理在生成会话ID后，一方面，立即向第一浏览器发送会话ID，另一方面，根据片源信息向自有服务器请求预下载。

第一浏览器在接收到会话ID后，将会话ID和片源信息发给第二浏览器。

需要注意的是，上述片源信息可以是自有服务器运维的片源信息，也可以是第三方服务器运维的片源信息，在本实施例中，鉴于第一浏览器发送第二浏览器的数据中除去片源信息之前，还包括会话ID，则表明第一浏览器已经确定该片源信息是自有服务器运维的片源信息，且已经通过下载代理进行预下载。

在一种实施例中，第一浏览器通过RPC调用向第二浏览器发送片源信息和会话ID。

第一浏览器通过RPC调用片源信息和会话ID的目的是告知第二浏览器进行视频播放。

步骤202，在获取片源信息和会话ID后，启动并加载视频播放应用。

第二浏览器在获取片源信息和会话ID后，则表明，第二浏览器已被激活，需要利用第二浏览器观看视频。基于此，第二浏览器启动并加载视频播放应用，以用于在获取到片源信息对应的视频资源后，在已经启动的视频播放应用中播放，以提高第二浏览器利用视频播放应用播放视频的速度，这样，对于用户而言，无需花太长的时间等待，能够迅速地在第二浏览器加载的视频播放应用中观看到视频，为用户带来良好的体验效果。

第二浏览器加载的视频播放应用可以是新创建的一个用于加载应用的窗口，也可以是在第二浏览器中当前页面中加载该视频播放应用，本实施例对此并不限定。

另外，第二浏览器包括了浏览器创建窗口、加载播放应用及渲染播放视频的时间。这些时间往往与CPU及内存以及播放视频应用的复杂度有关。

在网络带宽为nMb，且经过时间t秒可以下载的数据为n/8*t(MB)，而视频播放应用所播放的视频资源均为本地html，不占用网络带宽，因此网络带宽可以全部被下载代理使用，进而能够加快视频资源的下载。

需要注意的是，第一浏览器到第二浏览器的切换时间以及第二浏览器启动并加载视频播放应用的加载时间，恰好正是下载代理正在从自有服务器下载与片源信息相关的视频资源所用的时间。也就是说，第一浏览器到第二浏览器的切换时间、以及第二浏览器加载视频播放应用的时间与下载代理从自有服务器下载与片源信息相关的视频流所使用的时间是同步进行的。

步骤203，向下载代理通过第二插件发送片源信息和会话ID，以根据所述片源信息和会话ID，持续从下载代理中获取预下载的视频资源，并同时在视频播放应用中播放视频资源中的视频。

其中，第二插件能够为第二浏览器提供与下载代理会话的接口，例如，为第二浏览器提供下载代理中视频资源的本地视频URL，通知下载代理开始下载，停止下载等。

基于上述描述，可能存在用户在观看视频的过程中，由于某种原因，暂停视频播放应用播放视频，或者是，用户关闭视频播放应用。此时，第二浏览器便会通过第二插件通知下载代理停止从自有服务器中下载视频。

如果用户解决完上述事情后，又继续恢复观看视频，则第二浏览器便会通过第二插件发送会话ID和片源信息，并通知下载代理继续从自有服务器中下载与片源信息相关的视频。以使用户可以无间断地观看该视频。

由于显示设备的第二浏览器可能存在无法及时升级的情况，基于该种情况，可能会存在第二浏览器所加载的视频播放应用不支持部分视频格式的情况。例如，目前，假设该显示设备为电视，视频格式为H265视频已广泛支持，但是由于电视的第二浏览器可能由于版本问题而无法支持H265视频编码。基于上述问题，本申请的一种实施例中，在步骤203之后，该方法还可以包括：

在解码视频资源的视频时，确定该视频的视频格式不是预设的视频格式，则通过第二插件向下载代理发送第三会话信息；其中，第三会话信息用于使下载代理更新视频URL，回应表征已经更新完毕的第四会话信息；

按照会话ID，从下载代理中获得更新后的视频URL，并按照更新后的视频URL，在本地中下载与片源信息相关的视频资源。

需要说明的是，第二浏览器与下载代理还均是通过会话ID进行会话，以保持会话信息的一致性，

示例性的，假设在对视频解码时，第二浏览器加载的视频播放应用播放不了H265的视频，第二浏览器可以通过第二插件告知下载代理切换H264视频编码的视频，下载代理能够自动生成新的URL，并告知第二浏览器，并从自有服务器中下载H264视频。该方法不仅可以提高用户体验，还能够提升电视的可用性。

可见，在本申请实施例提供的技术方案中，第二浏览器在确定不能播放视频，则会向下载代理发送的第三会话信息，以使下载代理从新下载与第三会话信息中的预设的视频格式、且片源信息对应的视频资源，并同步更新视频URL，第二浏览器根据更新后的视频URL，下载与片源信息对应的视频资源并播放。该方法不仅可以提高用户体验，还能够提升电视的可用性。

基于上述描述，可知，第二浏览器在获取片源信息和会话ID后，首先，通过第二插件向下端代理发送会话ID，下载代理依据会话ID搜索到该会话ID对应的已经下载好的视频的视频URL，并通过第二插件向第二浏览器反馈表示已经找到该会话ID的视频URL的反馈信息，第二浏览器在收到该反馈信息后，继续通过第二插件向下载代理发送片源信息，且并根据片源信息，在下载代理中利用视频URL获取与片源信息相关的视频资源，以在第二浏览器运行的视频播放应用中持续播放。其中，第二浏览器所播放的视频数据实际为已下载到本地的视频流数据。这样，可以保证视频播放应用能够快速获取并持续且不简断地播放视频。

另外，由上述分析可知，本申请利用下载代理实现了会话机制，来保证第一浏览器和第二浏览器下内容和行为的一致性。下载代理为双浏览器提供会话ID。第一浏览器和第二浏览器均会通过会话ID获得一致的上下文环境。因此，这种会话机制能够保证上下文环境的数据共享和行为的同步。避免第一浏览器和第二浏览器产生不一致的内容和播放行为。

由此可见，在本申请实施例提供的技术方案中，在用户选择的视频播放操作的情况下，第二浏览器获取第一浏览器发送的片源信息和会话ID后，立即启动并加载视频播放应用，且通过会话ID和片源信息，持续从下载代理中获取预下载的视频资源，以在视频播放应用中播放。相对于现有技术，本申请不再使用单一的浏览器，而是采用双浏览器，在用户浏览信息时，采用资源占用低的第一浏览器；在用户观看视频时，采用观看视频的第二浏览器，同时，建立第一浏览器和第二浏览器与下载代理的会话机制，以从下载代理中预下载用户所观看视频的视频资源，使得用户在选择观看视频时，便能够快速地且无间断地在第二浏览器加载的视频播放应用中观看视频。可见，不仅能够提高应用加载速度，还能够提高与用户的交互性。

第三方面，请参见图9，图9中示例性示出了根据一些实施例的双浏览器应用加载方法的流程示意图。图9所示流程的执行主体可以是上述的下载代理。且如图9所示，该流程可以包括以下步骤301～步骤302：

步骤301，在接收第一浏览器通过第一插件发送的第一会话信息后，向自有服务器发送验证信息；第一会话信息包括片源信息，片源信息是所述第一浏览器响应于用户选择的视频播放操作，获取的与所述视频相关的信息。

其中，第一插件是作为下载代理和第一浏览器提供进行会话的接口，无论下载代理向第一浏览器发送信息，还是第一浏览器向下载代理发送信息，都要通过第一插件这个接口进行会话，例如，本实施例中的第一会话信息，就是通过第一插件转达至下载代理，以通知下载代理预下载与片源信息相关的视频资源。

下载代理在接收到第一会话信息后，便确定需要从自有服务器下载与片源信息对应的视频资源，在进行下载前，需要向自有服务器发送验证自身是否具备下载资源的资格的验证信息。

步骤302，在验证通过后，生成与第一会话信息对应的会话ID，并向自有服务器请求预下载与片源信息相关的视频资源并保存，同时，向第一浏览器发送包括会话ID的第二会话信息，以使第一浏览器向第二浏览器发送会话ID和片源信息，触发第二浏览器件启动并加载视频播放应用，以根据会话ID和片源信息，持续从下载代理中获取预下载的视频资源，并同时在视频播放应用中播放视频资源中的视频。

在本申请中，验证通过，则表明下载代理拥有从自身服务器下载资源的资格。也就是，在自有服务器通过验证信息后，下载代理会生成一个会话ID。该会话ID可以表示为此会话是一条与片源信息相关的、且具有唯一性的会话。以使第一浏览器和第二浏览器通过会话ID找到与片源信息相关的会话内容，从而保证双浏览器下内容和行为的一致性。

下载代理在生成会话ID后，一方面，会立即向第一浏览器发送会话ID，另一方面，会根据片源信息向自有服务器请求预下载。

需要说明的是，鉴于片源信息是第一浏览器通过第一插件发送至下载代理的第一会话信息，则表明，上述片源信息是自有服务器运维的片源信息，需要下载代理从自有服务器中下载与片源信息相关的视频资源。

由上分析可知，第二插件能够为第二浏览器提供与下载代理会话的接口，例如，为第二浏览器提供下载代理中视频资源的本地视频URL，通知下载代理开始下载，停止下载等。

基于上述描述，可能存在用户在观看视频的过程中，由于某种原因，暂停视频播放应用播放视频，或者是，用户关闭视频播放应用。此时，下载代理便会接收到第二浏览器通过第二插件发送的停止从自有服务器中下载视频通知。

如果用户解决完上述事情后，又继续恢复观看视频，则下载代理通过第二插件获取到第二浏览器发送的会话ID和片源信息，并继续从自有服务器中下载与片源信息相关的视频，以使用户可以无间断地观看该视频。

由于显示设备的第二浏览器可能存在无法及时升级的情况，基于该种情况，可能会存在第二浏览器所加载的视频播放应用不支持部分视频格式的情况。例如，目前，假设该显示设备为电视，视频格式为H265视频已广泛支持，但是由于电视的第二浏览器可能由于版本问题而无法支持H265视频编码。基于上述问题，本申请的一种实施例中，在步骤302之后，该方法还可以包括：

接收到第二浏览器第二插件发送的第三会话信息；其中，第三会话信息是第二浏览器在解码视频资源的视频时，确定该视频的视频格式不是预设的视频格式，向下载代理通知表示需要下载预设的视频格式、且与片源信息对应的视频的信息。

按照第一会话信息，从有服务器中下载预设的视频格式、且与片源信息对应的视频，并更新视频URL，同时，向第二会话信息反馈表征已经更新完毕的第四会话信息，以使第二浏览器按照会话ID，从下载代理中更新后的视频URL，并按照更新后的视频URL，在本地中下载与片源信息相关的视频资源。

示例性的，假设第二浏览器加载的视频播放应用播放不了H265的视频，则下载代理在获得第二浏览器通过第二插件告知下载代理切换H264视频编码的视频后，能够自动生成新的URL告知第二浏览器和并从自有服务器中下载H264视频。

可见，在本申请实施例提供的技术方案中，下载代理在获知第二浏览器不能播放视频，则会按照第二浏览器发送的第三会话信息，从新下载与第三会话信息中的预设的视频格式、且片源信息对应的视频资源，并同步更新视频URL，以使第二浏览器根据更新后的视频URL，下载与片源信息对应的视频资源并播放。该方法不仅可以提高用户体验，还能够提升电视的可用性。

需要注意的是，下载代理正在从自有服务器下载与片源信息相关的视频资源所用的时间恰好正是第一浏览器到第二浏览器的切换时间以及第二浏览器启动并加载视频播放应用的加载时间。也就是说，下载代理从自有服务器下载与片源信息相关的视频流所使用的时间与第一浏览器到第二浏览器的切换时间、以及第二浏览器加载视频播放应用的时间是同步进行的。

由上分析可知，本申请的下载代理实现了会话机制，能够保证双浏览器下内容和行为的一致性。下载代理为双浏览器提供会话id，而会话信息则缓存在下载代理中。任一浏览器通过会话id都能够获得一致的上下文环境。因此，这种会话机制能够保证上下文环境的数据共享和行为的同步。避免双浏览器产生不一致的内容和播放行为。

由此可见，在本申请实施例提供的技术方案中，在用户选择的视频播放操作的情况下，下载代理在获取第一浏览器通过第一插件发送的第一会话信息后，回应包括会话ID的第二会话信息，并同时按照第一会话信息，下载与片源信息对应的视频资源，以使在第一浏览器向第二浏览发送的片源信息和会话ID后，第二浏览器立即启动并加载视频播放应用，且通过会话ID和片源信息，持续从下载代理中获取预下载的视频资源，以在视频播放应用中播放。相对于现有技术，本申请不再使用单一的浏览器，而是采用双浏览器，在用户浏览信息时，采用资源占用低的第一浏览器；在用户观看视频时，采用观看视频的第二浏览器，同时，建立第一浏览器和第二浏览器与下载代理的会话机制，以从下载代理中预下载用户所观看视频的视频资源，使得用户在选择观看视频时，便能够快速地且无间断地在第二浏览器加载的视频播放应用中观看视频。可见，不仅能够提高应用加载速度，还能够提高与用户的交互性。

基于上述实施例的描述，为了能够对第一浏览器、第二浏览器和下载代理之间的对话机制理解的更加清楚，现举一示例，如图10所示，该示例具体为：

如果用户操作是视频播放操作，响应于用户选择的视频播放操作，第一浏览器获取与视频对应的片源信息，且如果确定片源信息属于自身服务器运维的片源信息，则向下载代理通过第一插件发送第一会话信息。如果确定片源信息属于第三方服务器运维的片源信息，则向第二浏览器发送片源信息对应的视频URL，以使第二浏览器启动并加载视频播放应用，并同时向第三服务器获取视频URL对应的视频资源，以在视频播放应用中播放视频资源中的视频。

下载代理依据第一会话信息，预下载与片源信息相关的视频资源，并在通过自有服务器验证后，回应第二会话信息。

第一浏览器从第二会话信息中获取会话ID，并向第二浏览器发送片源信息和会话ID。

第二浏览器根据片源信息和会话ID，启动并加载视频播放应用，并通过第二插件持续从下载代理中获取预下载的视频资源，以同时在视频播放应用中播放视频资源中的视频。

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

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

Claims (8)

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

显示器；

与所述显示器耦合的控制器，所述控制器内设有用于加载信息浏览应用的第一浏览器、用于加载视频播放应用的第二浏览器和下载代理，且所述第一浏览器内设有用于与下载代理会话的第一插件，所述第二浏览器内设有用于与下载代理会话的第二插件，所述第一浏览器用于执行：

如果用户触发的操作是浏览信息操作，则响应于用户选择的浏览信息操作，获取与用户所选择的浏览信息对应的信息来源，并启动与该信息来源对应的应用，以在应用中浏览信息；

如果用户触发的操作是视频播放操作，则响应于用户选择的视频播放操作，获取与所述视频对应的片源信息；

向所述下载代理通过所述第一插件发送携带所述片源信息的第一会话信息，所述第一会话信息用于使所述下载代理预下载与所述片源信息相关的视频资源，并在通过自有服务器验证后，回应第二会话信息；

从所述第二会话信息中获取会话ID，并向所述第二浏览器发送所述片源信息和会话ID，以使所述第二浏览器根据所述片源信息和所述会话ID，启动并加载视频播放应用，并通过所述第二插件持续从所述下载代理中获取预下载的视频资源，以同时在所述视频播放应用中播放视频资源中的视频。

2.根据权利要求1所述的显示设备，其特征在于，在所述获取与所述视频对应的片源信息之后，所述控制器还用于执行：

如果确定所述片源信息属于自有服务器运维的片源信息，则执行所述向所述下载代理通过所述第一插件发送携带所述片源信息的第一会话信息的步骤；

如果确定所述片源信息属于第三方服务器运维的片源信息，则向所述第二浏览器发送所述片源信息，以使所述第二浏览器启动并加载视频播放应用，并通过解析所述片源信息中的视频URL，向第三方服务器获取所述视频URL对应的视频资源，以在所述视频播放应用中播放视频资源中的视频。

3.根据权利要求1所述的显示设备，其特征在于，所述第一浏览器通过远程过程调用RPC向所述第二浏览器发送所述片源信息和会话ID。

4.一种双浏览器应用加载的方法，其特征在于，应用于权利要求1~3中任一项所述的显示设备的第一浏览器，所述方法包括：

如果用户触发的操作是浏览信息操作，则响应于用户选择的浏览信息操作，获取与用户所选择的浏览信息对应的信息来源，并启动与该信息来源对应的应用，以在应用中浏览信息；

如果用户触发的操作是视频播放操作，则响应于用户选择的视频播放操作，获取与所述视频对应的片源信息；

向所述下载代理通过所述第一插件发送携带所述片源信息的第一会话信息，所述第一会话信息用于使所述下载代理预下载与所述片源信息相关的视频资源，并在通过自有服务器验证后，回应第二会话信息；

从所述第二会话信息中获取会话ID，并向所述第二浏览器发送所述片源信息和会话ID，以使所述第二浏览器根据所述片源信息和所述会话ID，启动并加载视频播放应用，并通过所述第二插件持续从所述下载代理中获取预下载的视频资源，以同时在所述视频播放应用中播放视频资源中的视频。

5.根据权利要求4所述的方法，其特征在于，在所述获取与所述视频对应的片源信息之后，还包括：

如果确定所述片源信息属于自身服务器运维的片源信息，则执行所述向所述下载代理通过所述第一插件发送携带所述片源信息的第一会话信息的步骤；

如果确定所述片源信息属于第三方服务器运维的片源信息，则向所述第二浏览器发送所述片源信息对应的视频URL，以使所述第二浏览器启动并加载视频播放应用，并同时向第三服务器获取所述视频URL对应的视频资源，以在所述视频播放应用中播放视频资源中的视频。

6.一种双浏览器应用加载的方法，其特征在于，应用于权利要求1~3中任一项所述的显示设备的第二浏览器，所述方法包括：

获取第一浏览器发送的片源信息和会话ID，所述片源信息是第一浏览器响应于用户选择的视频播放操作，获取的与所述视频对应的信息；所述会话ID是下载代理在获取第一浏览器通过第一插件发送的第一会话信息后，向自有服务器发送验证，并在验证成功后，生成的用于回应第一浏览器第二会话信息的会话ID；所述第一会话信息是用于指示所述下载代理预下载与所述片源信息相关的视频资源；

在获取所述片源信息和所述会话ID后，启动并加载视频播放应用；

向所述下载代理通过所述第二插件发送所述片源信息和所述会话ID，以根据所述片源信息和所述会话ID，持续从所述下载代理中获取预下载的视频资源，以同时在所述视频播放应用中播放视频资源中的视频。

7.根据权利要求6所述的方法，其特征在于，所述向所述下载代理通过所述第二插件发送所述片源信息和所述会话ID，以根据所述片源信息和所述会话ID，持续从所述下载代理中获取预下载的视频资源，包括：

向所述下载代理通过所述第二插件发送所述会话ID和所述片源信息，以根据所述会话ID，从所述下载代理获取与所述会话ID对应的视频URL，并根据所述片源信息，持续从所述视频URL中获得与所述片源信息对应的视频资源。

8.一种双浏览器应用加载的方法，其特征在于，应用于权利要求1~3中任一项所述的显示设备的下载代理，所述方法包括：

在接收所述第一浏览器通过所述第一插件发送的第一会话信息后，向自有服务器发送验证信息；所述第一会话信息包括片源信息，所述片源信息是所述第一浏览器响应于用户选择的视频播放操作，获取的与所述视频相关的信息；

在验证通过后，生成与所述第一会话信息对应的会话ID，并向自有服务器请求预下载与所述片源信息相关的视频资源并保存，同时，向所述第一浏览器发送包括会话ID的第二会话信息，以使所述第一浏览器向所述第二浏览器发送所述会话ID和所述片源信息，触发所述第二浏览器件启动并加载视频播放应用，以根据所述会话ID和所述片源信息，持续从所述下载代理中获取预下载的视频资源，并同时在所述视频播放应用中播放视频资源中的视频。

Images