CN118132174A - 一种跨系统内容显示方法及设备 - Google Patents

Abstract

本申请公开了一种跨系统内容显示方法及设备，涉及终端技术领域，可以为用户提供更加便捷、流畅的跨系统内容浏览体验。本申请中，电子设备上运行的虚拟机可以提供一个独立于电子设备原生操作系统的运行环境。电子设备可以虚拟机提供不同于原生操作系统所能提供的应用运行体验。例如，电子设备可以在原生操作系统未安装某一应用时，基于虚拟机所提供的运行环境为用户提供正常的应用内容浏览体验。

Description

一种跨系统内容显示方法及设备

技术领域

本申请涉及终端技术领域，尤其涉及一种跨系统内容显示方法及设备。

背景技术

随着移动互联网技术和应用显示技术的发展，跨系统内容显示在生态融合场景中的应用越来越广泛。作为一种示例，第一设备(如个人计算机(personal computer，PC))可以将某一应用内容推广至第二设备(如手机)，用于用户在手机上浏览该应用内容。其中，PC与手机上安装有不同的操作系统，因此手机与PC可以为用户带来不同的应用内容浏览体验。

作为一种常见的实现方式，如图1所示，响应于点击浏览应用内容按钮的操作，PC可以通过展示二维码的方式将应用内容推广至手机。其中，PC提供的二维码中可以携带有应用内容的链接。如图1所示，在用户使用手机扫描该二维码时，手机可以获取应用内容的链接，并根据应用内容的链接跳转至对应的应用界面(如界面A)。

但是，上述展示二维码以及扫描二维码的过程需要用户在手机和PC两个设备上协同操作才能完成，对于用户来说操作繁琐。

发明内容

本申请提供一种跨系统内容显示方法及设备，可以为用户提供更加便捷、流畅的跨系统内容浏览体验。

为达到上述目的，本申请采用如下技术方案：

第一方面，提供一种跨系统内容显示方法，该方法应用于电子设备，其中电子设备包括第一系统和第二系统，该方法包括：显示第一窗口，其中第一窗口用于呈现第一应用界面，第一应用界面对应的第一应用属于第一系统；响应于在第一应用界面上的第一操作，显示第二窗口，其中第二窗口用于呈现第二应用界面，第二应用界面对应的第二应用属于第二系统。

示例性地，第一应用如浏览器，第一应用界面如浏览器界面；或者，第一应用如应用商店，第一应用界面如应用商店界面。当然，第一应用界面还可以是其它包括第二应用界面对应的按钮/控件/选项的应用界面，本申请不做具体限定。

示例性地，第一系统如系统，第二系统如/>系统。当然，第一系统和第二系统还可以是其它操作系统，本申请不做具体限定。

示例性地，第二系统运行在电子设备的虚拟机中。

上述第一方面提供的方案，包括第一系统和第二系统的电子设备可以在接收到用户在第一应用的第一应用界面上打开第二应用的第二应用界面的操作时，通过第二系统跨系统运行第二应用界面对应的任务，进而向用户展示第二应用界面。其中，基于该方法，电子设备不仅可以基于原生操作系统为用户提供界面展示服务，还可以无需借助其它设备，基于虚拟机中运行的操作系统为用户提供不同于原生操作系统的界面展示服务。在降低用户的操作复杂度的同时，可以为用户提供正常的多样化的应用内容浏览体验。

作为一种可能的实现方式，上述第一系统没有安装第二应用。基于此，在第一系统未安装第二应用，且第一系统接收到用于浏览第二应用的第二应用界面的需求时，电子设备可以通过第二系统运行安装在其中的第二应用进而顺利向用户展示第二应用界面。基于此，电子设备无需借助其它设备便可以顺利响应用户的第二应用界面浏览需求。在降低用户的操作复杂度的同时，为用户提供正常的应用内容浏览体验。

作为一种可能的实现方式，上述响应于在第一应用界面上的第一操作，显示第二窗口，包括：第一系统在接收到在第一应用界面上的第一操作后，向第二系统发送第二应用界面的界面信息；第二系统根据第二应用界面的界面信息启动安装在第二系统中的第二应用以及绘制渲染得到第二应用界面；第二系统向第一系统发送第二应用界面的界面数据；第一系统根据界面数据显示第二窗口。基于此，第一系统可以在需要跨系统显示界面时，通过向第二系统发送第二应用界面的界面信息以指示第一操作所针对的目标应用和目标界面，便于第二系统能够准确启动目标应用以及准确完成目标界面渲染，顺利完成目标界面的跨系统显示，为用户提供正常的应用内容浏览体验。

作为一种可能的实现方式，上述第一系统向第二系统发送第二应用界面的界面信息，包括：第一系统将第二应用界面的界面信息写入第一系统的第一存储区域，其中第一存储区域与第二系统中的第二存储区域存在映射关系；第二系统从第二存储区域中获取第二应用界面的界面信息。基于此，第一系统可以将第二应用界面的界面信息写入第一存储区域；对应地，第二系统可以通过监测第二存储区域中写入的数据，获取第二应用界面的界面信息。

其中，第一存储区域与第二存储区域存在映射关系是指第二存储区域中存储的内容会随着第二系统在第一存储区域的写入操作同步更新，第一存储区域中存储的内容会随着第二系统第二存储区域的写入操作同步更新。基于此，在第一系统将第二应用界面的界面信息写入第一存储区域时，第二系统便可以从第二存储区域中获取第二应用界面的界面信息。

作为一种可能的实现方式，上述第一应用界面是浏览器界面，浏览器界面上包括第二应用界面对应的按钮，第一操作是用户在所述浏览器界面上点击第二应用界面对应的按钮的操作。本申请不对第一应用界面做具体限定，示例性地，第一应用界面可以是浏览器界面。作为一种示例，若第一应用界面是浏览器界面，第一系统可以将第二应用界面的界面信息写入第一存储区域；对应地，第二系统可以通过监测第二存储区域中写入的数据，获取第二应用界面的界面信息。

作为一种可能的实现方式，上述第一系统向第二系统发送第二应用界面的界面信息，包括：第一系统通过第一系统中的软件开发工具包(Software Development Kit，SDK)向第二系统中的SDK发送第二应用界面的界面信息。基于此，第一系统可以直接将第二应用界面的界面信息发送至第二系统。

作为一种可能的实现方式，上述第一应用界面是应用商店界面，应用商店界面上包括第二应用界面对应的按钮，第一操作是用户在应用商店界面上点击第二应用界面对应的按钮的操作。本申请不对第一应用界面做具体限定，示例性地，第一应用界面可以是应用商店界面。作为一种示例，若第一应用界面是应用商店界面，第一系统可以将第二应用界面的界面信息直接发送至第二系统。

作为一种可能的实现方式，上述第二应用界面的界面信息包括第二应用的标识。基于此，第一系统可以在需要跨系统显示界面时，通过向第二系统发送第二应用的标识以指示第一操作所针对的目标应用，便于第二系统能够准确启动目标应用。

作为一种可能的实现方式，上述第二应用界面的界面信息还包括第二应用界面的深度链接。基于此，第一系统可以在需要跨系统显示界面时，通过向第二系统发送第二应用界面的深度链接指示第一操作所针对的目标界面，便于第二系统能够准确进行目标界面渲染。

作为一种可能的实现方式，上述第二应用界面是第二应用的首页。本申请对第二应用界面不做具体限定，示例性地，第二应用界面可以是第二应用的首页。

例如，若第二应用界面的界面信息仅包括第二应用的标识，第二应用界面可以是第二应用的首页。又如，若第二应用界面的界面信息包括第二应用的标识和第二应用界面的深度链接，其中第二应用界面的深度链接为第二应用的首页的深度链接，第二应用界面即第二应用的首页。

作为一种可能的实现方式，上述第二应用界面是第二应用的指定应用页面。本申请对第二应用界面不做具体限定，示例性地，第二应用界面可以是第二应用的指定应用页面。

例如，若第二应用界面的界面信息包括第二应用的标识和第二应用界面的深度链接，其中第二应用界面的深度链接为第二应用的指定应用页面的深度链接，第二应用界面即第二应用的指定应用页面。

作为一种可能的实现方式，上述第二应用界面的界面信息还包括以下中的一个或多个：第二应用界面的尺寸、第二应用界面的分辨率、第二应用界面的转向。可以理解，在本申请实施例中，第二系统仅用于进行第二应用界面的绘制和渲染等，最终显示时界面窗口的创建以及界面的送显还是由原生操作系统(即第一系统)负责，因此第一系统可以通过将上述信息提前发送给第二系统，用于第二系统可以根据界面尺寸、分辨率、转向等一个或多个信息进行界面绘制和渲染具有对应参数特征的第二应用界面，为用户提供效果更加的界面展示体验。

第二方面，提供一种电子设备，该电子设备包括：处理单元，用于：运行第一系统和第二系统；显示单元，用于：显示第一窗口，其中第一窗口用于呈现第一应用界面，第一应用界面对应的第一应用属于第一系统；上述处理单元还用于：响应于在第一应用界面上的第一操作，在第二系统中运行第二应用的第二应用界面对应的任务，并指示显示单元显示第二窗口，其中第二窗口用于呈现第二应用界面；上述显示单元还用于：在第二窗口中呈现第二应用界面。

上述第二方面提供的方案，包括第一系统和第二系统的电子设备可以在接收到用户在第一应用的第一应用界面上打开第二应用的第二应用界面的操作时，通过第二系统跨系统运行第二应用界面对应的任务，进而向用户展示第二应用界面。其中，基于该方法，电子设备不仅可以基于原生操作系统为用户提供界面展示服务，还可以无需借助其它设备，基于虚拟机中运行的操作系统为用户提供不同于原生操作系统的界面展示服务。在降低用户的操作复杂度的同时，可以为用户提供正常的多样化的应用内容浏览体验。

作为一种可能的实现方式，上述第一系统没有安装第二应用。基于此，在第一系统未安装第二应用，且第一系统接收到用于浏览第二应用的第二应用界面的需求时，电子设备可以通过第二系统运行安装在其中的第二应用进而顺利向用户展示第二应用界面。基于此，电子设备无需借助其它设备便可以顺利响应用户的第二应用界面浏览需求。在降低用户的操作复杂度的同时，为用户提供正常的应用内容浏览体验。

作为一种可能的实现方式，上述处理单元响应于在第一应用界面上的第一操作，在第二系统中运行第二应用的第二应用界面对应的任务，并指示显示单元显示第二窗口，包括：处理单元中的第一系统在接收到在第一应用界面上的第一操作后，向第二系统发送第二应用界面的界面信息；第二系统根据第二应用界面的界面信息启动安装在第二系统中的第二应用以及绘制渲染得到第二应用界面；第二系统向第一系统发送第二应用界面的界面数据；第一系统根据界面数据指示显示单元显示第二窗口。基于此，第一系统可以在需要跨系统显示界面时，通过向第二系统发送第二应用界面的界面信息以指示第一操作所针对的目标应用和目标界面，便于第二系统能够准确启动目标应用以及准确完成目标界面渲染，顺利完成目标界面的跨系统显示，为用户提供正常的应用内容浏览体验。

作为一种可能的实现方式，上述第一系统向第二系统发送第二应用界面的界面信息，包括：第一系统将第二应用界面的界面信息写入第一系统的第一存储区域，其中第一存储区域与第二系统中的第二存储区域存在映射关系；第二系统从第二存储区域中获取第二应用界面的界面信息。基于此，第一系统可以将第二应用界面的界面信息写入第一存储区域；对应地，第二系统可以通过监测第二存储区域中写入的数据，获取第二应用界面的界面信息。

作为一种可能的实现方式，上述第一应用界面是浏览器界面，浏览器界面上包括第二应用界面对应的按钮，第一操作是用户在所述浏览器界面上点击第二应用界面对应的按钮的操作。本申请不对第一应用界面做具体限定，示例性地，第一应用界面可以是浏览器界面。作为一种示例，若第一应用界面是浏览器界面，第一系统可以将第二应用界面的界面信息写入第一存储区域；对应地，第二系统可以通过监测第二存储区域中写入的数据，获取第二应用界面的界面信息。

作为一种可能的实现方式，上述第一系统向第二系统发送第二应用界面的界面信息，包括：第一系统通过第一系统中的SDK向第二系统中的SDK发送第二应用界面的界面信息。基于此，第一系统可以直接将第二应用界面的界面信息发送至第二系统。

作为一种可能的实现方式，上述第一应用界面是应用商店界面，应用商店界面上包括第二应用界面对应的按钮，第一操作是用户在应用商店界面上点击第二应用界面对应的按钮的操作。本申请不对第一应用界面做具体限定，示例性地，第一应用界面可以是应用商店界面。作为一种示例，若第一应用界面是应用商店界面，第一系统可以将第二应用界面的界面信息直接发送至第二系统。

作为一种可能的实现方式，上述第二应用界面的界面信息包括第二应用的标识。基于此，第一系统可以在需要跨系统显示界面时，通过向第二系统发送第二应用的标识以指示第一操作所针对的目标应用，便于第二系统能够准确启动目标应用。

作为一种可能的实现方式，上述第二应用界面的界面信息还包括第二应用界面的深度链接。基于此，第一系统可以在需要跨系统显示界面时，通过向第二系统发送第二应用界面的深度链接指示第一操作所针对的目标界面，便于第二系统能够准确进行目标界面渲染。

作为一种可能的实现方式，上述第二应用界面是第二应用的首页。本申请对第二应用界面不做具体限定，示例性地，第二应用界面可以是第二应用的首页。

作为一种可能的实现方式，上述第二应用界面是第二应用的指定应用页面。本申请对第二应用界面不做具体限定，示例性地，第二应用界面可以是第二应用的指定应用页面。

作为一种可能的实现方式，上述第二应用界面的界面信息还包括以下中的一个或多个：第二应用界面的尺寸、第二应用界面的分辨率、第二应用界面的转向。基于此，绘制和渲染具有对应参数特征的第二应用界面，为用户提供效果更加的界面展示体验。

第三方面，提供一种电子设备，该电子设备包括：通信接口，用于进行设备间的通信；存储器，用于存储计算机程序指令；处理器，用于执行所述计算机程序指令，以支持电子设备实现如第一方面任一种可能的实现方式中的方法。

第四方面，提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序指令，该计算机程序指令被处理器执行时实现如第一方面任一种可能的实现方式中的方法。

第五方面，提供一种包含指令的计算机程序产品，当该计算机程序产品在计算机上运行时，使得计算机实现如第一方面任一种可能的实现方式中的方法。

第六方面，提供一种芯片系统，该芯片系统包括处理电路、存储介质，存储介质中存储有计算机程序指令；所述计算机程序指令被所述处理器执行时，实现如第一方面任一种可能的实现方式中的方法。该芯片系统可以由芯片构成，也可以包含芯片和其他分立器件。

附图说明

图1为一种常规的跨系统内容显示过程示意图；

图2为本申请实施例提供的一种电子设备的硬件结构示意图；

图3为本申请实施例提供的一种电子设备基于操作系统的模块化示意图；

图4A为本申请实施例提供的一种跨系统内容显示方法的流程图；

图4B为本申请实施例提供的另一种跨系统内容显示方法的流程图；

图5为本申请实施例提供的两种第一操作示意图；

图6为本申请实施例提供的一种电子设备的软件结构示意图；

图7为本申请实施例提供的一种跨系统内容显示过程中的交互图；

图8为本申请实施例提供的另一种跨系统内容显示过程中的交互图；

图9为本申请实施例提供的一种跨系统内容显示效果示意图；

图10为本申请实施例提供的另一种跨系统内容显示效果示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。其中，在本申请实施例的描述中，除非另有说明，“/”表示或的意思，例如，A/B可以表示A或B；本文中的“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，在本申请实施例的描述中，“多个”是指两个或多于两个。

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

我们知道，生态融合场景可以包括如基于多屏协同技术的多屏协同场景和基于模拟器的模拟器场景(或者容器场景)等。其中，多屏协同场景通常是跨设备的内容展示场景。模拟器场景通常是不跨设备的内容展示场景。

示例性地，在电子设备(以PC为例)中未安装某一应用程序(Application，APP)(或者安卓应用程序包文件(Android package，APK)，本申请实施例以APP作为示例)时，作为一种实现方式，电子设备可以基于多屏协同技术指示安装有上述APP的协同设备在协同设备上运行上述APP，实现向用户展示对应的应用界面的目的；作为另一种实现方式，电子设备可以通过在模拟器中运行的操作系统启动安装在模拟器中的上述APP，实现向用户展示对应的应用界面的目的。

可以看出，上述采用常规的多屏协同技术实现内容展示的实现方式需要两台设备(如PC和手机)，且协同设备(如手机)上需要安装有应用内容对应的APP，以及需要用户在手机和PC上协同操作才能实现跨系统的内容展示。

例如，作为一种方式，用户需要在PC(即电子设备)上操作使其展示携带有应用内容链接的二维码；之后，用户需要在手机(即协同设备)上安装有APP的情况下打开该APP，然后打开“扫一扫”功能扫描PC显示屏上的二维码，使手机获取该二维码中携带的应用内容链接；最后，手机才能根据获取的应用内容的链接跳转至对应的应用界面。

又如，作为另一种方式，用户需要在PC上操作使其展示携带有应用内容链接的二维码；之后，用户需要在手机上打开“扫一扫”功能(如“扫一扫”功能)扫描PC显示屏上的二维码，使手机获取该二维码中携带的应用内容链接；最后，手机才能根据获取的应用内容的链接启动APP，并跳转至对应的应用界面。

可以理解，无论采用上述哪一种方式实现跨系统的内容展示，均需要用户在两台设备上协同操作才能完成。并且，若手机上未安装有内容对应的APP，还需要用户先在手机上安装APP。因此，上述常规方法对于用户来说操作非常繁琐。

基于上述考虑，为了提供更加便捷、流畅的跨系统内容浏览体验，本申请实施例提供一种跨系统内容显示方法。该方法无需用户在多台设备上操作，仅基于一个设备便可以实现跨系统的内容显示。相比于常规的多屏协同技术，不仅可以减少用户在两台设备上协同操作所带来的繁杂的工作量，还可以减少用户在手机上安装APP所带来的额外工作量。并且，该方法中，跨系统的内容显示可以由用户的简单操作触发，大大降低用户的操作复杂度，提高用户体验。

其中，本申请实施例所提供的跨系统内容显示方法主要基于电子设备上运行的虚拟机(如模拟器、容器等)，其中，虚拟机可以提供一个独立于电子设备原生操作系统(如第一操作系统)的运行环境。电子设备可以在虚拟机中基于虚拟机所提供的运行环境，运行不同于电子设备原生操作系统的操作系统(如第二操作系统)，以提供不同于第一操作系统所能提供的应用运行体验。例如，基于本申请实施例提供的跨系统内容显示方法，电子设备可以在第一操作系统未安装某一APP(时，无需在第一操作系统中安装该APP，基于虚拟机所提供的运行环境为用户提供正常的应用内容浏览体验。

作为一种示例，电子设备可以基于其中安装的移动应用运行虚拟机，以提供独立于电子设备原生操作系统的运行环境，实现本申请实施例提供的一种跨系统内容显示方法。

其中，本申请所述电子设备可以包括但不限于智能手机、上网本、平板电脑、PC、掌上电脑、车载设备、可穿戴设备(如智能手表、智能手环、智能眼镜等)、相机(如单反相机、卡片式相机等)、智能电视、个人数字助理(personal digital assistant，PDA)、便携式多媒体播放器(portable multimedia player，PMP)、投影设备、智慧屏设备、增强现实(augmented reality，AR)/虚拟现实(virtual reality，VR)设备、混合现实(mixedreality，MR)设备、电视机或人机交互场景中的体感游戏机等电子设备。本申请对电子设备的具体功能和结构不做限定。

作为一种示例，请参考图2，图2示出了本申请实施例提供的一种电子设备的硬件结构示意图。

如图2所示，电子设备可以包括处理器(如中央处理单元(central processingunit，CPU))210，存储器(包括外部存储器接口220和内部存储器221)，通用串行总线(universal serial bus，USB)接口230，充电管理模块240，电源管理模块241，电池242，天线1，天线2，移动通信模块250，无线通信模块260，音频模块270，扬声器270A，受话器270B，麦克风270C，耳机接口270D，传感器模块280，按键290，马达291，指示器292，摄像头293，显示屏294等。其中，传感器模块280可以包括触摸传感器280A。可选的，传感器模块280还可以包括压力传感器，陀螺仪传感器，气压传感器，磁传感器，加速度传感器，距离传感器，接近光传感器，指纹传感器，温度传感器，环境光传感器，骨传导传感器等。

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

处理器210可以包括一个或多个处理单元。例如：处理器210可以包括应用处理器(application processor，AP)，调制解调处理器，图形处理器(graphics processingunit，GPU)，图像信号处理器(image signal processor，ISP)，飞行控制器，视频编解码器，数字信号处理器(digital signal processor，DSP)，基带处理器，和/或神经网络处理器(neural-network processing unit，NPU)等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。

处理器210中还可以设置存储器，用于存储指令和数据。在一些实施例中，处理器210中的存储器为高速缓冲存储器。该存储器可以保存处理器210刚用过或循环使用的指令或数据。如果处理器210需要再次使用该指令或数据，可从所述存储器中直接调用。避免了重复存取，减少了处理器210的等待时间，因而提高了系统的效率。

在一些实施例中，处理器210可以包括一个或多个接口。接口可以包括集成电路(inter-integrated circuit，I2C)接口，集成电路内置音频(inter-integrated circuitsound，I2S)接口，脉冲编码调制(pulse code modulation，PCM)接口，通用异步收发传输器(universal asynchronous receiver/transmitter，UART)接口，移动产业处理器接口(mobile industry processor interface，MIPI)，通用输入输出(general-purposeinput/output，GPIO)接口，用户标识模块(subscriber identity module，SIM)接口，和/或通用串行总线(universal serial bus，USB)接口等。

I2C接口是一种双向同步串行总线，包括一根串行数据线(serial data line，SDA)和一根串行时钟线(derail clock line，SCL)。在一些实施例中，处理器210可以包含多组I2C总线。处理器210可以通过不同的I2C总线接口分别耦合触摸传感器280A，麦克风，摄像头293等。例如，处理器210可以通过I2C接口耦合触摸传感器280A，使处理器210与触摸传感器280A通过I2C总线接口通信，实现电子设备的触摸功能。

在本申请实施例中，处理器210可以通过I2C总线接口获取触摸传感器280A检测到的用户在界面上的点击(如单击、双击等)操作、滑动操作、长按操作或者拖拽操作等触摸操作，从而确定触摸操作所对应的具体意图，进而响应该触摸操作。其中，点击操作如点击预设按钮/控件的操作。

USB接口230是符合USB标准规范的接口，具体可以是Mini USB接口，Micro USB接口，USB Type C接口等。USB接口230可以用于连接充电器为电子设备充电，也可以用于电子设备与输入/输出设备之间传输数据。其中，输入/输出设备如有线鼠标、有线键盘等。

在本申请实施例中，处理器210可以通过USB接口230获取用户通过有线鼠标点击预设按钮/控件的操作。

充电管理模块240用于从充电器接收充电输入。电源管理模块241用于连接电池242，充电管理模块240与处理器210。电源管理模块241接收电池242和/或充电管理模块240的输入，为处理器210，内部存储器221，显示屏294，摄像组件293和无线通信模块260等供电。

电子设备的无线通信功能可以通过天线1，天线2，移动通信模块250，无线通信模块260，调制解调处理器以及基带处理器等实现。

无线通信模块260可以提供应用在电子设备上的包括无线局域网(wirelesslocal area networks，WLAN)(如WiFi网络)，蓝牙BT，全球导航卫星系统(globalnavigation satellite system，GNSS)，调频(frequency modulation，FM)，近距离无线通信技术(near field communication，NFC)，红外技术(infrared，IR)等无线通信的解决方案。无线通信模块260可以是集成至少一个通信处理模块的一个或多个器件。

在一些实施例中，电子设备的天线1和移动通信模块250耦合，天线2和无线通信模块260耦合，使得电子设备可以通过无线通信技术与网络以及其他设备通信。所述无线通信技术可以包括全球移动通讯系统(global system for mobile communications，GSM)，通用分组无线服务(general packet radio service，GPRS)，码分多址接入(code divisionmultiple access，CDMA)，宽带码分多址(wideband code division multiple access，WCDMA)，时分码分多址(time-division code division multiple access，TD-SCDMA)，长期演进(long term evolution，LTE)，BT，GNSS，WLAN，NFC，FM，和/或IR技术等。所述GNSS可以包括全球卫星定位系统(global positioning system，GPS)，全球导航卫星系统(globalnavigation satellite system，GLONASS)，北斗卫星导航系统(beidou navigationsatellite system，BDS)，准天顶卫星系统(quasi-zenith satellite system，QZSS)和/或星基增强系统(satellite based augmentation systems，SBAS)。

在本申请一些实施例中，电子设备可以基于无线通信技术，通过无线通信模块260与输入设备进行信息交互，如接收用户通过输入设备触发的输入操作等。示例性地，输入设备如无线鼠标、无线键盘等。用户输入操作如用户点击预设按钮/控件的操作。

电子设备通过GPU，显示屏294，以及应用处理器等实现显示功能。GPU为图像处理的微处理器，连接显示屏294和应用处理器。GPU用于执行数学和几何计算，用于图形绘制和渲染。处理器210可包括一个或多个GPU，其执行程序指令以生成或改变显示信息。

在本申请实施例中，电子设备可以通过运行在虚拟机中的第二操作系统中的虚拟GPU负责完成第二应用界面的绘制和渲染。

显示屏294用于显示图像，视频等界面。显示屏294包括显示面板。显示面板可以采用液晶显示屏(liquid crystal display，LCD)，有机发光二极管(organic light-emitting diode，OLED)，有源矩阵有机发光二极体或主动矩阵有机发光二极体(active-matrix organic light emitting diode的，AMOLED)，柔性发光二极管(flex light-emitting diode，FLED)，Miniled，MicroLed，Micro-oLed，量子点发光二极管(quantum dotlight emitting diodes，QLED)等。在一些实施例中，电子设备可以包括1个或N个显示屏294，N为大于1的正整数。

在本申请实施例中，电子设备可以通过显示屏294显示运行在虚拟机中的操作系统负责绘制渲染的应用界面(如第二应用界面)。电子设备也可以通过显示屏294显示电子设备原生操作系统负责绘制渲染的应用界面(如第一应用界面)。

电子设备可以通过ISP，摄像组件293，视频编解码器，GPU，显示屏294以及应用处理器等实现拍摄功能。

外部存储器接口220可以用于连接外部存储卡，例如Micro SD卡，实现扩展电子设备的存储能力。外部存储卡通过外部存储器接口220与处理器210通信，实现数据存储功能。

内部存储器221可以用于存储计算机可执行程序代码。示例性地，计算机程序可以包括操作系统程序和应用程序。操作系统可包括但不限于 OS等操作系统。其中，可执行程序代码包括指令。处理器210通过运行存储在内部存储器221的指令，从而执行电子设备的各种功能应用以及数据处理。内部存储器221可以包括存储程序区和存储数据区。其中，存储程序区可存储操作系统，至少一个功能所需的应用程序等。存储数据区可存储电子设备使用过程中所创建的数据(比如输入事件、投屏数据等)等。此外，内部存储器221可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件，闪存器件，通用闪存存储器(universal flash storage，UFS)等。处理器210通过运行存储在内部存储器221的指令，和/或存储在设置于处理器中的存储器的指令，执行电子设备的各种功能应用以及数据处理。

在本申请实施例中，电子设备的内部存储器221包括第一存储区域，该第一存储区域与虚拟机中的虚拟存储区域(如第二存储区域)存在映射关系。例如，第二存储区域中存储的内容会随着电子设备在第一存储区域的写入操作同步更新，第一存储区域中存储的内容会随着虚拟机在第二存储区域的写入操作同步更新。

作为一种示例，上述第一存储区域可以由电子设备基于虚拟机的运行为其设置，上述第二存储区域可以由虚拟机在运行在其中的第二操作系统的内核层中的设置。

电子设备可以通过音频模块270，扬声器270A，受话器270B，麦克风270C以及应用处理器等实现音频功能。例如音乐播放，录音等。关于音频模块270，扬声器270A，受话器270B和麦克风270C的具体工作原理和作用，可以参考常规技术中的介绍。

触摸传感器280A，也称“触控面板”。触摸传感器280A可以设置于显示屏294，由触摸传感器280A与显示屏294组成触摸屏，也称“触控屏”。触摸传感器280A用于检测作用于其上或附近的触摸操作。触摸传感器可以将检测到的触摸操作(包括触摸位置、触摸力度、接触面积和触摸时长等信息)传递给处理器，以确定触摸事件类型。可以通过显示屏294提供与触摸操作相关的视觉输出。在另一些实施例中，触摸传感器280A也可以设置于电子设备的表面，与显示屏294所处的位置不同。

在本申请实施例中，触摸传感器280A检测到的触摸操作可以是用户通过手指在触摸屏上或附近的操作，也可以是用户使用手写笔、触控笔、触控球等触控辅助工具在触摸屏上或附近的操作，本申请不做限定。

另外，关于按键290、马达291、指示器292等硬件的介绍，可以参考常规技术，本申请实施例不再赘述。

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

以下将结合具体场景，对本申请实施例提供的一种跨系统内容显示方法进行具体介绍。

我们知道，若电子设备未安装某一应用的APP(如第二应用的APP)，那么在用户在某些界面(如网页(也称浏览器界面)、应用商店界面)上点击打开该应用界面时，作为一种可能的情况1，电子设备可能无法响应用户的操作，导致用户无法正常浏览其想要浏览的应用界面。作为一种可能的情况2，电子设备可能会展示携带有应用界面链接的二维码，用于用户使用其它安装有第二应用APP的设备扫描该二维码，进而在其它设备上打开对应的应用界面，也就是图1所示常规的方法。上述请求2需要用户在两台设备上协同操作才能完成。并且，若手机上未安装有内容对应的APP，还需要用户先在手机上安装APP，因此对于用户来说操作非常繁琐。

而基于本申请实施例提供的一种跨系统内容显示方法，电子设备中运行有虚拟机，虚拟机的操作系统为第二操作系统，第二操作系统中安装有第二应用的APP。若电子设备的原生操作系统中未安装第二应用的APP，在接收到用户在某一界面上打开第二应用的第二应用界面的操作时，原生操作系统可以将该第二应用界面的界面信息存储在(如写入)第一存储区域。其中，第一存储区域与虚拟机中的虚拟存储区域(如第二存储区域)存在映射关系，因此第二存储区域中存储的内容会随着原生操作系统在第一存储区域的写入操作同步更新。之后，虚拟机中的第二操作系统可以根据第二应用界面的界面信息拉起对应的第二应用，并拉起第二应用界面对应的应用活动(如Activity)，以及将第二应用界面的数据发送回电子设备原生操作系统，用于后续的第二应用界面送显。通过这一过程，电子设备可以在第一操作系统未安装某一APP时，无需借助协同设备，基于虚拟机所提供的运行环境顺利响应用户的界面浏览需求，在降低用户的操作复杂度的同时，为用户提供正常的应用内容浏览体验。

其中，在本申请实施例中，电子设备未安装第二应用的APP可能存在以下两种情况：情况a，电子设备未安装第二应用的APP，且应用开发方未针对电子设备开发适配于其原生操作系统(即第一操作系统)的第二应用的APP导致电子设备无法在原生操作系统中安装第二应用的APP；情况b，应用开发方针对电子设备开发了适配于其原生操作系统(即第一操作系统)的第二应用的APP，但是电子设备未安装第二应用的APP。对于上述情况a和情况b，均可以采用本申请实施例提供的方案实现第二应用界面的跨系统显示。

可以理解，基于本申请实施例所述电子设备的原生操作系统(即第一操作系统)和虚拟机中安装的操作系统(即第二操作系统)，电子设备所能提供的运行环境可以包括两个，一个如图3所示Host端，另一个如图3所示Guest端。其中，Host端可以基于电子设备的硬件和第一操作系统为用户提供服务，Guest端可以基于电子设备的硬件和第二操作系统为用户提供服务。第一操作系统的应用层中不包括第二应用，第二操作系统的应用层中包括第二应用。

在一些示例中，Guest端在通过电子设备的硬件和第二操作系统为用户提供服务时，通常需要Host端的配合。

以下将结合图3所示电子设备中的Host端和Guest端，介绍本申请实施例提供的一种跨系统内容显示方法的具体过程。请参考图4A和图4B，图4A和图4B示出了本申请实施例提供的两种跨系统内容显示方法的流程图。

如图4A所示，本申请实施例提供的一种跨系统内容显示方法包括S401-S406：

S401：电子设备的Host端在未安装第二应用时，接收用户打开第二应用的第二应用界面的第一操作。

其中，Host端中运行有第一操作系统。第一操作系统的应用层中不包括第二应用。

作为一种示例，第一操作可以是用户在第一应用界面上打开第二应用的第二应用界面的操作，第一应用界面对应第一应用。第一应用安装并运行在Host端，第一应用如浏览器、应用商店等，第一应用界面如浏览器界面、应用商店界面或者其它推广页等。

作为一些可能的示例，第一操作可以由用户通过触控方式输入，也可以由通过使用输入设备(如鼠标、键盘、麦克风等)输入，本申请实施例不做限定。

作为一些可能的示例，第一操作可以是用户在第一应用界面上对第二应用界面相关按钮或控件的点击操作，长按后选择打开的操作，双击操作；也可以是用户的语音指示操作，指令输入操作，预设手势操作，肢体操作等其它操作，本申请实施例不做限定。

示例性地，请参考图5，图5示出了本申请实施例提供的两种第一操作示意图。其中，图5中的(a)示出了用户在浏览器界面(即第一应用界面)上点击关于“阅读”应用(即第二应用)中书籍A的“开始阅读”按钮的操作，即第一操作；其中图5中的(a)所示第一操作用于打开“阅读”应用中书籍A的第一章节(即第二应用界面是“阅读”应用中书籍A的第一章节)。

需要说明的是，在本申请实施例中，第二应用界面可以是第二应用的首页(如图5中的(b)所示)，也可以是第二应用的某一指定页面，本申请实施例不做具体限定。在一些实施例中，假设第一操作是用户在图5中的(a)所示浏览器界面上点击关于“阅读”应用(即第二应用)中书籍A的“开始阅读”按钮的操作，第二应用界面是“阅读”应用中书籍A的“第一页”。在另一些实施例中，假设第一操作是用户在图5中的(a)所示浏览器界面上点击关于“阅读”应用(即第二应用)的“打开阅读应用”按钮的操作，第二应用界面是“阅读”应用的首页。

S402：响应于第一操作，电子设备的Host端将第二应用界面的界面信息写入第一存储区域。

作为一种示例，第二应用界面的界面信息可以包括第二应用界面对应的第二应用的标识(如第二应用包名)。

可选的，第二应用界面的界面信息还可以包括第二应用界面的深度链接(deeplink)。其中，第二应用界面的深度链接并不是必须的，如果第二应用界面的界面信息中不包括第二应用界面的深度链接，电子设备的Guest端可以在启动第二应用之后启动第二应用首页对应的应用活动，这部分会在下文S404中具体介绍。

示例性地，以第二应用是“阅读”应用为例，第二应用包名如com.huawei.yuedu。

示例性地，第二应用界面的深度链接可以为统一资源标识符(uniform resourceidentifier，URI)格式。对于URI格式的深度链接，在基于深度链接(deeplink)技术访问应用界面时，可以依赖统一资源定位器(uniform resource locator，URL)Scheme，在通过解析URL Scheme确定深度链接所对应的应用并启动该应用之后，直接根据深度链接指示的信息绘制并渲染应用的界面(如应用首页或者指定应用页面)。

其中，不同应用的Scheme通常不同。因此，可以通过分析Scheme确定深度链接所对应的应用，以便执行后续应用界面的访问。

作为一种示例，第二应用界面的深度链接的协议格式可以如下：Scheme://host:port/path？query。其中，Scheme代表Scheme协议名称，host代表Scheme作用的地址域，port代表深度链接对应的应用的接口，path代表想要跳转的应用界面(如应用首页或者指定应用页面)的路径，query代表想要传递的参数。以第二应用是“阅读”应用为例，第二应用界面的深度链接如yuedue://com.huawei.yuedu/showcampaign？campaignid＝yuedu.play5。

作为一种可能的实现方式，第一存储区域与电子设备中，虚拟机中Guest端的虚拟存储区域(如第二存储区域)存在映射关系。例如，第二存储区域中存储的内容会随着电子设备的Host端在第一存储区域的写入操作同步更新，第一存储区域中存储的内容会随着电子设备的Guest端在第二存储区域的写入操作同步更新。

需要说明的是，本申请实施例仅以第一存储区域与Guest端的第二存储区域存在映射关系，因此Host端通过向第一存储区域写入第二应用界面的界面信息，实现将第二应用界面的界面信息发送至Guest端作为示例，本申请实施例并不限定Host端向Guest端传输第二应用界面的界面信息的具体方式。例如，作为另一种可能的实现方式，Host端可以通过与Guest端的基础通信服务向Guest端传输第二应用界面的界面信息。

在一些实施例中，第二应用界面的界面信息还可以包括但不限于以下信息中的一个或多个：第二应用界面的尺寸、第二应用界面的分辨率、第二应用界面的转向(如横屏或者竖屏)等。其中，第二应用一界面的尺寸、第二应用界面的分辨率和第二应用界面的转向由Host端根据自身默认参数(记作第一默认参数)确定。可以理解，在本申请实施例中，Guest端仅用于进行第二应用界面的绘制和渲染等，最终显示时界面窗口的创建以及界面的送显还是由原生操作系统(即第一操作系统)负责，因此Host端可以通过将上述信息提前发送给Guest端，用于Guest端可以根据界面尺寸、分辨率、转向等一个或多个信息进行界面绘制和渲染具有对应参数特征的第二应用界面。

需要说明的是，上述第二应用界面的尺寸、第二应用界面的分辨率、第二应用界面的转向并不是必须的。Guest端也可以根据其内部配置自行绘制和渲染第二尺寸、第二分辨率、第二转向的第二应用界面，之后，Host端在送显时，可以自行将其调整为第一尺寸、第一分辨率、第一转向的第二应用界面，并通过尺寸为第一尺寸的窗口显示调整后的第二应用界面。

S403：在识别到第一存储区域中有新写入内容时，电子设备的Guest端获取第一存储区域中新写入的第二应用界面的界面信息。

其中，Guest端中安装并运行第二操作系统。第二操作系统的应用层中包括第二应用。

可以理解，由于第一存储区域与电子设备的Guest端中的第二存储区域存在映射关系，因此，在电子设备的Host端将第二应用界面的界面信息写入第一存储区域时，电子设备的Host端可以通过第二存储区域的同步更新感知到。并且，Guest端可以通过读取第二存储区域中的内容，以获取Host端写入第一存储区域的第二应用界面的界面信息。

需要说明的是，本申请实施例仅以第一存储区域与Guest端的第二存储区域存在映射关系，因此Host端通过向第一存储区域写入第二应用界面的界面信息，实现将第二应用界面的界面信息发送至Guest端作为示例，本申请实施例并不限定Guest端获取第二应用界面的界面信息的具体方式。例如，作为另一种可能的实现方式，Guest端可以通过与Host端的基础通信服务接收Host端发送的第二应用界面的界面信息。

S404：电子设备的Guest端根据第二应用界面的界面信息启动第二应用，并绘制渲染第二应用界面。

作为一种示例，电子设备的Guest端可以根据第二应用界面的界面信息中的第二应用包名启动第二应用，并根据第二应用界面的界面信息中第二应用界面的深度链接启动第二应用界面对应的应用活动，进而绘制渲染第二应用界面。

作为另一种示例，电子设备的Guest端可以根据第二应用界面的界面信息中的第二应用界面的深度链接启动第二应用，并启动第二应用界面对应的应用活动，进而绘制渲染第二应用界面。

例如，假设第二应用界面的深度链接是URI格式的深度链接，Guest端可以通过深度链接中的URL Scheme确定深度链接所对应的应用并启动该应用之后，直接根据深度链接指示的地址域(host)、应用接口(port)、第二应用界面的路径(path)、参数(query)等信息启动第二应用界面对应的应用活动。

在一些实施例中，在Guest端根据第二应用界面的界面信息启动第二应用之前，Guest端可以先根据第二应用界面的界面信息验证是否满足预设条件，若满足预设条件，则启动第二应用；若不满足预设条件，则按照预设置流程处理。

其中，预设条件如Guest端中是否安装了第二应用界面对应的第二应用。

作为一种可能的情况，若电子设备的Guest端经过验证，确定Guest端中安装了第二应用界面对应的第二应用，那么Guest端可以根据第二应用界面的界面信息中的第二应用包名启动第二应用，并根据第二应用界面的界面信息中第二应用界面的深度链接启动第二应用界面对应的应用活动。

作为另一种可能的情况，若电子设备的Guest端经过验证，确定Guest端中未安装第二应用界面对应的第二应用，那么作为一种可能的实现方式，Guest端可以按照预设置流程处理。示例性地，预设置流程如提示用户下载并在Guest端中安装第二应用，或者不做响应等，本申请实施例不做具体限定。

其中，在根据第二应用界面的界面信息验证Guest端中是否安装了第二应用时，作为一种可能的实现方式，Guest端可以根据第二应用界面的界面信息中的第二应用包名验证Guest端中是否安装了第二应用。例如，假设第二应用包名对应的应用启动器在Guest端的Launcher列表中，则确定Guest端中安装了第二应用。在这种情况下，Guest端可以启动Launcher列表中第二应用的启动器，以启动第二应用。

作为另一种可能的实现方式，Guest端可以根据第二应用界面的界面信息中的第二应用界面的深度链接验证Guest端中是否安装了第二应用。例如，假设深度链接中的URLScheme对应的应用启动器在Guest端的Launcher列表中，则确定Guest端中安装了第二应用，在这种情况下，Guest端可以启动Launcher列表中第二应用的启动器，以启动第二应用。又如，假设深度链接中的URL Scheme对应的应用启动器不在Guest端的Launcher列表中，则确定Guest端中未安装第二应用，在这种情况下，Guest端可以按照预设置流程处理。

当然，存在一种可能，第二应用界面的界面信息中可能不包含第二应用界面的深度链接，在这种情况下，Guest端可以根据第二应用界面的界面信息中的第二应用包名验证Guest端中是否安装了第二应用。需要说明的是，对于第二应用界面的界面信息中不包含第二应用界面的深度链接的情况，在Guest端启动第二应用之后绘制并渲染的第二应用界面是第二应用首页。

其中，在Guest端绘制渲染第二应用界面时，作为一种可能的实现方式，Guest端可以根据自身默认参数(记作第二默认参数)绘制和渲染第二应用界面，例如绘制和渲染第二尺寸、第二分辨率、第二转向的第二应用界面。

作为另一种可能的实现方式，若第二应用界面的界面信息中包括第二应用界面的尺寸(如第一尺寸)、第二应用界面的分辨率(如第一分辨率)和第二应用界面的转向(如第一转向)，Guest端可以根据第二应用界面的界面信息绘制和渲染第一尺寸、第一分辨率、第一转向的第二应用界面。

S405：电子设备的Guest端向电子设备的Host端发送第二应用界面的数据。

其中，Guest端向Host端发送第二应用界面的数据用于Host端将第二应用界面送显。

作为一种示例，第二应用界面的数据可以包括但不限于第二应用界面标识、第二应用界面的尺寸、第二应用界面的分辨率、第二应用界面的转向、第二应用界面上的图标、第二应用界面上的文字等元素，以及第二应用界面上每一个图标、文字等元素的具体显示位置、大小和颜色等。其中，第二应用界面的转向包括横屏或竖屏。关于界面数据的具体介绍，可以参考常规技术，本申请实施例不限定。

作为一种示例，第二应用界面的尺寸如第一尺寸，第二应用界面的分辨率如第一分辨率，第二应用界面的转向如第一转向。

作为另一种示例，第二应用界面的尺寸如第二尺寸，第二应用界面的分辨率如第二分辨率，第二应用界面的转向如第二转向。

其中，第二尺寸可以与第一尺寸相同，也可以不同；第二分辨率可以与第一分辨率相同，也可以不同；第二转向可以与第一转向相同，也可以不同。

S406：电子设备的Host端创建窗口并在窗口中显示第二应用界面。

作为一种可能的实现方式，Host端可以根据自身默认参数(即第一默认参数)创建第一尺寸的窗口，并在该窗口中显示第一转向、第一分辨率的第二应用界面。

例如，若Host端向Guest端发送的第二应用界面的数据中包括第二应用界面的尺寸(如第一尺寸)、第二应用界面的分辨率(如第一分辨率)和第二应用界面的转向(如第一转向)，由于Guest端会根据上述参数绘制对应参数的第二应用界面，因此Host端可以直接根据第一默认参数创建第一尺寸的窗口。

作为另一种可能的实现方式，Host端可以根据第一默认参数创建第一尺寸的窗口，并将第二应用界面调整为符合自身默认参数(即(即第一默认参数))的第二应用界面，如调整后的第二应用界面为第一转向、第一分辨率的第二应用界面，再在该窗口中显示第一转向、第一分辨率的第二应用界面。

例如，若Host端向Guest端发送的第二应用界面的数据中包括第二应用界面的尺寸、第二应用界面的分辨率和第二应用界面的转向，由于Guest端会根据自身默认参数(即第二默认参数)绘制和渲染第二尺寸、第二分辨率、第二转向的第二应用界面，因此第二应用界面的参数可能与Host端送显时的参数不匹配，如第二尺寸与第一尺寸不同、第二分辨率与第一分辨率不同或者第二转向与第一转向不同，在这种情况下，为了保证第二应用界面的正常合理显示，Host端会将第二应用界面调整为符合自身默认参数(即第一默认参数)的第二应用界面，如调整为第一尺寸、第一分辨率、第一转向的第二应用界面。

需要说明的是，图4A仅以第一操作是用户在第一应用界面(如浏览器界面)上打开第二应用界面的操作作为示例，介绍本申请实施例提供的一种跨系统内容显示方法。在一些实施例中，若第一操作是用户在第一应用界面(如应用商店界面)上打开第二应用界面的操作，如图4B中的S402＇所示，Host端可以直接向Guest端发送第二应用界面的界面信息。例如，Host端和Guest端中均可以包括用于支持与对方通信的软件开发工具包(SoftwareDevelopment Kit，SDK)，Host端可以通过Host端中的SDK向Guest端中的SDK发送第二应用界面的界面信息。对应地，如图4B所示，Guest端执行S404和S405，之后Host端执行S406。

示例性地，图5中的(b)示出了用户在应用商店界面(即第一应用界面)上点击关于“阅读”应用(即第二应用)的“下载并打开应用”按钮的操作，即第一操作；其中图5中的(b)所示第一操作用于打开“阅读”应用首页(即第二应用界面是“阅读”应用首页)。

作为一种示例，请参考图6，图6示出了本申请实施例提供的一种电子设备的软件结构示意图。本申请实施例所述一种跨系统内容显示方法可以基于图6所示软件结构实现。

如图6所示，电子设备的Host端中安装有第一操作系统。Host端可以包括应用层、框架(framework，FWK)层和硬件层。

Host端的应用层可以包括一系列应用程序包，例如图6所示浏览器、应用商店、虚拟机应用(如书籍A的移动应用)。应用层还可以包括其它原生的应用(如集成在操作系统中的应用)或者第三方应用(如用户通过应用商店下载安装的应用)，如相机、图库、日历、通话、地图、导航、蓝牙、音乐、视频、短信息、即时通信应用等应用程序，本申请实施例不予限定。

作为一种示例，本申请实施例所述用户的第一操作可以由用户在浏览器的界面上触发，也可以由用户在应用商店的界面上触发。

其中，虚拟机应用用于提供虚拟机功能。例如，在Host端运行虚拟机应用时，则会启动虚拟机，以提供独立于Host端操作系统(即第一操作系统)的运行环境，实现本申请实施例提供的一种跨系统内容显示方法。

Host端的框架层用于为Host端的应用层的应用程序提供应用编程接口(application programming interface，API)和编程框架。如图6所示，Host端的框架层可以包括窗口管理服务(window management service，WMS)、应用注册服务、虚拟机管理服务、通信服务和用于支持Host端与Guest端通信的SDK。在一些实施例中，Host端的应用层还可以包括其它服务，如活动管理服务、包管理服务、内容提供服务、视图系统、电话管理服务、资源管理服务、通知管理服务、位置管理服务等，本申请实施例不予限定。

其中，Host端的窗口管理服务承载着和“界面”有关的数据和属性，用于管理和“界面”有关的状态，例如用于管理Host窗口程序和事件派发等。其中，管理窗口程序包括根据应用程序的显示请求在应用服务端和WMS的协助下有序地输出给显示屏或其他显示设备。事件派发是指将来自键盘、物理按键、触摸屏、鼠标等的用户事件派发给相应的控件或窗口。窗口管理服务还可以获取显示屏大小，判断是否有状态栏，锁定屏幕，截取屏幕等。

在本申请实施例中，Host端的窗口管理服务可以用于根据来自Guest端的第二应用界面的数据，为第二应用界面创建窗口。例如，在为第二应用界面创建窗口时，Host端的窗口管理服务可以根据自身默认参数(即第一默认参数)为第二应用界面创建第一尺寸的窗口。

Host端的应用注册服务用于负责管理应用的注册表，如应用界面中某一按钮或控件对应的链接项的注册表。其中，注册表可以包括但不限于按钮或控件对应的应用包的标识(如应用包名)和界面深度链接信息。

Host端的虚拟机管理服务用于为虚拟机应用提供相应的服务，如信息传输服务、参数适配服务等。在本申请一些实施例中，Host端的虚拟机管理服务可以用于将第二应用界面的界面信息通过通信服务写入第一存储区域。在本申请一些实施例中，Host端的虚拟机管理服务还可以用于根据自身默认参数(如第一默认参数)确定第二应用界面的界面参数，与第二应用界面的界面信息一起通过通信服务写入第一存储区域。

Host端的通信服务用于为Host端提供与Guest端之间的通信。在本申请实施例中，Host端的通信服务可以用于将来自虚拟机管理服务的第二应用界面的界面信息写入第一存储区域的方式传输至Guest端。

Host端中的SDK用于根据用户在第二预设应用界面(如应用商店界面)上打开第二应用界面的第一操作，向Guest端传输第二应用界面的界面信息。在本申请一些实施例中，Host端中的SDK可以通过直接与Guest端中SDK通信的方式，将第二应用界面的界面信息传输至Guest端。

Host端的硬件层可以包括图6所示显示屏、处理器、存储器等。在一些实施例中，Host端的硬件层还可以包括摄像头、麦克风、传感器、电源、天线等其它部件。作为一种示例，Host端的硬件层可以包括图2所示各个部件。

其中，Host端的显示屏用于显示界面。在本申请实施例中，Host端的显示屏用于显示上述第二应用界面和第一应用界面。

Host端的处理器可以包括但不限于AP、调制解调处理器、GPU、ISP、飞行控制器、视频编解码器、DSP、基带处理器NPU等中的一个或多个。

Host端的存储器可以用于存储计算机可执行程序代码。示例性地，计算机程序可以包括第一操作系统程序和应用程序(如浏览器、应用商店、虚拟机应用等)。在本申请实施例中，Host端的存储器包括第一存储区域，该第一存储区域与Guest端的虚拟存储区域(如第二存储区域)存在映射关系。

以及，如图6所示，电子设备的Guest端中安装有第二操作系统。Guest端可以包括应用层、框架层和虚拟硬件(Hardware emulation)层。

Guest端的应用层可以包括一系列应用程序包，例如图6所示第二应用、LauncherApp。当然，应用层还可以包括其它应用，本申请实施例不予限定。

Guest端的框架层用于为Guest端的应用层的应用程序提供应用编程接口API和编程框架。如图6所示，Guest端的框架层可以包括通信服务、用于支持Guest端与Host端通信的SDK、窗口管理服务、虚拟机管理服务、应用管理服务和活动管理服务(activitymanagement service，AMS)。在一些实施例中，Guest端的应用层还可以包括其它服务，如活动管理服务、包管理服务、内容提供服务、视图系统、电话管理服务、资源管理服务、通知管理服务、位置管理服务等，本申请实施例不予限定。

其中，Guest端的通信服务用于为Guest端提供与Host端之间的通信。在本申请实施例中，Guest端的通信服务可以用于从第二存储区域中获取Host端写入的第二应用界面的界面信息。

Guest端中的SDK用于接收来自Host端的信息，如第二应用界面的界面信息。在本申请一些实施例中，Guest端中的SDK可以直接接收Host端通过Host端中的SDK发送的第二应用界面的界面信息。

Guest端的窗口管理服务用于在接收到来自Host端的第二应用界面的界面信息后，对第二应用界面的界面信息进行解析和分析，其中分析如发送方的合法性判断等。Guest端的窗口管理服务还用于将第二应用界面的界面信息传输至Guest端的虚拟机管理服务进行后续处理，如分析第二应用界面的界面信息是否符合预设条件、将第二应用界面的界面信息传输至下一处理模块等。

Guest端的虚拟机管理服务用于为虚拟机应用提供相应的服务，如分析来自Host端的第二应用界面的界面信息，根据系统设置执行对应的操作，如点击Launcher列表中的第二应用的启动器等。

Guest端的应用管理服务用于为Guest端的应用层中的应用程序(包括第二应用)提供服务。在本申请实施例中，Guest端的应用管理服务可以根据LauncherApp的指示，启动第二应用。

在本申请实施例中，在Guest端安装第二应用时，第二应用会向Guest端的应用管理服务注册deeplink协议。其中，协议格式如Scheme://host:port/path？query。

Guest端的活动管理服务用于负责管理Guest端的Activity，负责系统中各组件的启动、切换、调度及应用程序的管理和调度等工作。具体的，AMS中定义了分别用来保存进程(Process)、活动(Activity)和任务(Task)的数据类。在本申请实施例中，Guest端的活动管理服务可以用于在第二应用启动后，根据第二应用界面的界面信息中第二应用界面的深度链接信息拉起对应的应用活动。

Guest端的虚拟硬件层用于为Guest端中第二操作系统的运行提供硬件基础。如图6所示，Guest端的虚拟硬件层包括虚拟处理器和虚拟存储器等。当然，Guest端的虚拟硬件层还可以包括其它虚拟硬件部件，本申请实施例不做限定。

其中，Guest端的虚拟处理器以包括但不限于AP、调制解调处理器、GPU、ISP、飞行控制器、视频编解码器、DSP、基带处理器NPU等中的一个或多个。

Guest端的虚拟存储器可以用于存储计算机可执行程序代码。示例性地，计算机程序可以包括第二操作系统程序和应用程序(如第二应用等)。在本申请实施例中，Guest端的虚拟存储器包括第二存储区域，该第二存储区域与Host端的第一存储区域存在映射关系。

以下将结合图6所示结构的电子设备，进一步介绍本申请图4A和图4B所示一种跨系统内容显示方法的几种具体实现过程。

请参考图7，图7以用户在浏览器界面(即第一应用界面是浏览器界面)上进行第一操作为例，示出了本申请实施例提供的一种跨系统内容显示过程中的交互图。如图7所示，本申请实施例提供的一种跨系统内容显示过程可以包括S701-S717：

S701：Host端中的浏览器应用向Host端的应用注册服务注册链接项。

其中，浏览器应用向应用注册服务注册的链接项可以包括但不限于浏览器界面上一个或多个按钮或控件对应的链接项。链接项可以用于指示在虚拟机中打开应用界面。

示例性地，Host端中的浏览器应用可以向Host端的应用注册服务注册如图5中的(a)所示“打开阅读应用”按钮、书籍A的“开始阅读”按钮、书籍A的“第一章”按钮、书籍A的“第二章”按钮、书籍A的“第三章”按钮、书籍B的“第一章”按钮、书籍B的“第二章”按钮、书籍B的“第三章”按钮等对应的链接项。

其中，按钮对应的链接项可以包括虚拟机标识(如虚拟机名称等)、按钮对应的应用包的标识(如应用包名)和按钮对应的应用界面的深度链接。

示例性地，以图5中的(a)所示“打开阅读应用”按钮为例，浏览器应用向应用注册服务注册的链接项可以包括：虚拟机名称(如移动应用引擎名称(MobileAppEngine))、阅读应用包名(如com.huawei.yuedu)和阅读应用首页的深度链接。

又一示例性地，以图5中的(a)所示书籍A的“第一章”按钮为例，浏览器应用向应用注册服务注册的链接项可以包括：虚拟机名称(如移动应用引擎名称(MobileAppEngine))、阅读应用包名(如com.huawei.yuedu)和阅读应用第一章节第一页的深度链接。

作为一种可能的实现方式，浏览器应用可以使用浏览器应用的自定义协议向应用注册服务注册浏览器界面上一个或多个按钮或控件对应的链接项。

S702：在Guest端安装第二应用时，第二应用向Guest端的应用管理服务注册第二应用界面上一个或多个按钮或控件对应的深度链接。

其中，第二应用界面上一个或多个按钮或控件对应的深度链接的协议格式如Scheme://host:port/path？query，关于这部分的具体介绍，可以参考上文中的说明，这里不再赘述。

作为一种可能的示例，上述第二应用向Guest端的应用管理服务注册深度链接的功能可以是第二操作系统的原生功能。

需要说明的是，本申请实施例不限定S701和S702的具体时序关系，S701和S702可以同时发生，也可以S701在前S702在后，还可以S702在前S701在后。

S703：Host端中的浏览器应用接收用户打开第二应用的第二应用界面的第一操作。

示例性地，第一操作如图5中的(a)所示用户在浏览器界面上点击关于“阅读”应用(即第二应用)中书籍A的“开始阅读”按钮的操作。

关于S703的介绍，可以参考上文中对S401的介绍，这里不再赘述。

S704：响应于第一操作，Host端中的浏览器应用向虚拟机应用发送第二应用界面的界面信息。

其中，第二应用界面的界面信息可以包括第二应用界面对应的第二应用的标识(如第二应用包名)。

在一些实施例中，第二应用界面的界面信息还可以包括第二应用界面的深度链接。关于第二应用界面的具体介绍，可以参考上文中的相关描述，这里不再赘述。

可以理解，由于浏览器应用向应用注册服务注册过第二应用界面上按钮/控件的链接项，因此在接收到用户打开第二应用的第二应用界面的第一操作时，Host端可以根据应用注册服务所提供的注册表启动虚拟机应用。

S705：Host端的虚拟机应用将第二应用界面的界面信息发送给虚拟机管理服务。

在一些实施例中，虚拟机应用在接收到第二应用界面的界面信息之后可以对第二应用界面的界面信息进行解析和分析。其中，分析如验证Host端中是否安装有第二应用界面对应的第二应用。

在一些实施例中，若虚拟机应用确定Host端中未安装第二应用，虚拟机应用可以将第二应用界面的界面信息进行封装后发送给虚拟机管理服务。

S706：Host端的虚拟机管理服务将第二应用界面的界面信息发送给通信服务。

在一些实施例中，虚拟机管理服务还可以在第二应用界面的界面信息中加入以下信息中的一个或多个：第二应用界面的尺寸、第二应用界面的分辨率、第二应用界面的转向(如横屏或者竖屏)等。其中，第二应用界面的尺寸、第二应用界面的分辨率和第二应用界面的转向由虚拟机管理服务根据自身默认参数(记作第一默认参数)确定。

S707：Host端的通信服务将第二应用界面的界面信息存储在第一存储区域。

其中，由于第一存储区域与Guest端中的第二存储区域存在映射关系，因此，通信服务通过将第二应用界面的界面信息存储在第一存储区域的形式，便可以成功将第二应用界面的界面信息传输至Guest端。

关于S704-S707的其它相关介绍，还可以参考上文中对S403的说明，这里不再赘述。

S708：Guest端的第二存储区域感知到写入第一存储区域的第二应用界面的界面信息并存储第二应用界面的界面信息。

关于S708的具体介绍，可以参考上文中对S402的介绍，这里不再赘述。

S709：Guest端的通信服务从第二存储区域中获取第二应用界面的界面信息。

S710：Guest端的通信服务将第二应用界面的界面信息发送给窗口管理服务。

S711：Guest端的窗口管理服务将第二应用界面的界面信息发送给虚拟机管理服务。

在一些实施例中，窗口管理服务在接收到第二应用界面的界面信息之后可以对第二应用界面的界面信息进行解析和分析。其中，分析如进行发送方合法性验证等，本申请不做限定。

在一些实施例中，若窗口管理服务对第二应用界面的界面信息进行验证通过，则将第二应用界面的界面信息发送虚拟机管理服务。

S712：Guest端的虚拟机管理服务验证第二应用界面的界面信息是否满足预设条件。若满足预设条件，虚拟机管理服务启动LauncherApp中第二应用的启动器。

作为一种示例，预设条件如Guest端中是否安装了第二应用界面对应的第二应用。

其中，在验证Guest端中是否安装了第二应用时，作为一种可能的实现方式，虚拟机管理服务可以根据第二应用界面的界面信息中的第二应用包名验证Guest端中是否安装了第二应用。例如，假设第二应用包名对应的应用启动器在Guest端的Launcher列表中，则确定Guest端中安装了第二应用。在这种情况下，虚拟机管理服务可以启动Launcher列表中第二应用的启动器，以启动第二应用。

作为另一种可能的实现方式，虚拟机管理服务可以根据第二应用界面的界面信息中的第二应用界面的深度链接验证Guest端中是否安装了第二应用。例如，假设深度链接中的URL Scheme对应的应用启动器在Guest端的Launcher列表中，则确定Guest端中安装了第二应用，在这种情况下，虚拟机管理服务可以启动Launcher列表中第二应用的启动器，以启动第二应用。

进一步地，若Guest端中安装了第二应用界面对应的第二应用，Guest端中的LauncherApp执行S713。

当然，存在一种可能，假设深度链接中的URL Scheme对应的应用启动器不在Guest端的Launcher列表中，则确定Guest端中未安装第二应用，在这种情况下，虚拟机管理服务可以按照预设置流程处理。

以及，也存在一种可能，第二应用界面的界面信息中可能不包含第二应用界面的深度链接，在这种情况下，虚拟机管理服务可以根据第二应用界面的界面信息中的第二应用包名验证Guest端中是否安装了第二应用。

S713：Guest端中的LauncherApp调用应用管理服务以拉起第二应用。

S714：Guest端的应用管理服务指示第二应用启动。

在一些实施例中，应用管理服务可以通过遍历已经注册的深度链接协议，查询匹配项的方式，寻找目标与应用。如果有找到匹配项，应用管理服务可以指示注册该深度链接协议的目标应用(即第二应用)启动。

S715：Guest端中的第二应用调用活动管理服务，启动第二应用并启动第二应用界面对应的应用活动。

在一些实施例中，活动管理服务可以根据第二应用界面的界面信息中的第二应用包名启动第二应用，并根据第二应用界面的界面信息中第二应用界面的深度链接启动第二应用界面对应的应用活动。

关于S709-S715的其它相关介绍，还可以参考上文中对S404的说明，这里不再赘述。

S716：Guest端的活动管理服务通过窗口管理服务向Host端的窗口管理服务发送第二应用界面的数据。

关于S716的具体介绍，可以参考上文中对S405的介绍，这里不再赘述。

S717：Host端的窗口管理服务创建窗口并指示显示屏在创建的窗口中显示第二应用界面。

作为一种可能的实现方式，窗口管理服务可以根据自身默认参数(即第一默认参数)创建第一尺寸的窗口，并指示显示屏在该窗口中显示第一转向、第一分辨率的第二应用界面。

作为另一种可能的实现方式，窗口管理服务可以根据自身默认参数(即第一默认参数)创建第一尺寸的窗口，并将第二应用界面调整为符合自身默认参数(即(即第一默认参数))的第二应用界面，如调整后的第二应用界面为第一转向、第一分辨率的第二应用界面，然后指示显示屏在创建的窗口中显示第二应用界面。

关于S717的其它相关介绍，可以参考上文中对S406的介绍，这里不再赘述。

请参考图8，图8以用户在应用商店界面(即第一应用界面是应用商店界面)上进行第一操作为例，示出了本申请实施例提供的另一种跨系统内容显示过程中的交互图。如图8所示，本申请实施例提供的一种跨系统内容显示过程可以包括S801-S811：

S801：Host端中的应用商店应用接收用户打开第二应用的第二应用界面的第一操作。

示例性地，第一操作如图5中的(b)所示用户在应用商店界面上点击关于“阅读”应用(即第二应用)的“下载并打开应用”按钮的操作。

关于S801的介绍，可以参考上文中对S401的介绍，这里不再赘述。

S802：Host端中的应用商店应用向Guest端中的SDK发送第二应用界面的界面信息。

其中，第二应用界面的界面信息可以包括第二应用界面对应的第二应用的标识(如第二应用包名)。

在一些实施例中，第二应用界面的界面信息还可以包括第二应用界面的深度链接。关于第二应用界面的具体介绍，可以参考上文中的相关描述，这里不再赘述。

S803：Host端的SDK向Guest端的SDK发送第二应用界面的界面信息。

S804：Guest端的SDK将第二应用界面的界面信息发送给窗口管理服务。

S805：Guest端的窗口管理服务将第二应用界面的界面信息发送给虚拟机管理服务。

S806：Guest端的虚拟机管理服务验证第二应用界面的界面信息是否满足预设条件。若满足预设条件，虚拟机管理服务启动LauncherApp中第二应用的启动器。

S807：Guest端中的LauncherApp调用应用管理服务以拉起第二应用。

S808：Guest端的应用管理服务指示第二应用启动。

S809：Guest端中的第二应用调用活动管理服务，启动第二应用并启动第二应用界面对应的应用活动。

S810：Guest端的活动管理服务通过窗口管理服务向Host端的窗口管理服务发送第二应用界面的数据。

S811：Host端的窗口管理服务创建窗口并指示显示屏在创建的窗口中显示第二应用界面。

关于S805-S811的其它相关介绍，还可以参考上文中对S711-S717的说明，这里不再赘述。

可以理解，基于本申请实施例提供的一种跨系统内容显示方法，电子设备中运行有虚拟机，虚拟机的操作系统为第二操作系统，第二操作系统中安装有第二应用的APP。若电子设备的原生操作系统(如第一操作系统)中未安装第二应用的APP，在接收到用户在某一界面(如第一应用界面)上打开第二应用的第二应用界面的操作时，原生操作系统可以将该第二应用界面的界面信息存储在(如写入)第一存储区域。其中，第一存储区域与虚拟机中的虚拟存储区域(如第二存储区域)存在映射关系，因此第二存储区域中存储的内容会随着原生操作系统在第一存储区域的写入操作同步更新。之后，虚拟机中的第二操作系统可以根据第二应用界面的界面信息拉起对应的第二应用，并拉起第二应用界面对应的应用活动，以及将第二应用界面的数据发送回电子设备原生操作系统，用于后续的第二应用界面送显。

通过这一过程，电子设备可以在第一操作系统未安装某一APP时，无需借助协同设备，基于虚拟机所提供的运行环境顺利响应用户的界面浏览需求。示例性地，如图9和图10所示，基于本申请实施例提供的方法，即使电子设备中未安装阅读应用，电子设备也可以智能化的提供阅读应用界面的展示。因此，可见，本申请提供的方案可以在电子设备中第一操作系统未安装某一APP时，在降低用户的操作复杂度的同时，为用户提供正常的应用内容浏览体验。

其中，图9和图10分别以用户在浏览器界面和应用商店界面上触发第一操作，示出了本申请实施例所能实现的跨系统内容显示效果。

需要说明的是，本申请上述实施例均以通过一个电子设备实现跨系统内容显示作为示例，本申请实施例提供的一种跨系统内容显示方法还可以适用于跨系统跨设备的内容显示。例如，若电子设备的原生操作系统(如第一操作系统)中未安装第二应用的APP，在接收到用户在某一界面(如第一应用界面)上打开第二应用的第二应用界面的操作时，电子设备可以通过SDK向协同设备发送第二应用界面的界面信息。其中，协同设备中安装有第二操作系统且安装有第二应用的APP。基于此，协同设备可以根据第二应用界面的界面信息拉起对应的第二应用，并跳转至对应的第二应用界面。通过这一过程，电子设备可以在第一操作系统未安装某一APP时，无需借助协同设备，基于虚拟机所提供的运行环境顺利响应用户的界面浏览需求，在降低用户的操作复杂度的同时，为用户提供正常的应用内容浏览体验。

应理解，本申请实施例的各个方案可以进行合理的组合使用，并且实施例中出现的各个术语的解释或说明可以在各个实施例中互相参考或解释，对此不作限定。

还应理解，在本申请的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。

可以理解的是，电子设备为了实现上述任一个实施例的功能，其包含了执行各个功能相应的硬件结构和/或软件模块。本领域技术人员应该很容易意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

本申请实施例可以对电子设备进行功能模块的划分，例如，可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。需要说明的是，本申请实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。

还应理解，电子设备中的各个模块可以通过软件和/或硬件形式实现，对此不作具体限定。换言之，电子设备是以功能模块的形式来呈现。这里的“模块”可以指特定应用集成电路ASIC、电路、执行一个或多个软件或固件程序的处理器和存储器、集成逻辑电路，和/或其它可以提供上述功能的器件。

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

结合本申请实施例所描述的方法或者算法的步骤可以硬件的方式来实现，也可以是由处理器执行软件指令的方式来实现。软件指令可以由相应的软件模块组成，软件模块可以被存放于RAM存储器、闪存、ROM存储器、EPROM存储器、EEPROM存储器、寄存器、硬盘、移动硬盘、CD-ROM或者本领域熟知的任何其它形式的存储介质中。一种示例性地存储介质耦合至处理器，从而使处理器能够从该存储介质读取信息，且可向该存储介质写入信息。当然，存储介质也可以是处理器的组成部分。处理器和存储介质可以位于ASIC中。另外，该ASIC可以位于电子设备中。当然，处理器和存储介质也可以作为分立组件存在于电子设备中。

通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。

Claims (16)

1.一种跨系统内容显示方法，其特征在于，所述方法应用于电子设备，所述电子设备包括第一系统和第二系统，

显示第一窗口，所述第一窗口用于呈现第一应用界面，所述第一应用界面对应的第一应用属于所述第一系统；

响应于在所述第一应用界面上的第一操作，显示第二窗口，所述第二窗口用于呈现第二应用界面，所述第二应用界面对应的第二应用属于所述第二系统。

2.根据权利要求1所述的方法，其特征在于，所述第一系统没有安装所述第二应用。

3.根据权利要求1或2所述的方法，其特征在于，所述响应于在所述第一应用界面上的第一操作，显示第二窗口，包括：

所述第一系统在接收到所述第一操作后，向所述第二系统发送第二应用界面的界面信息；

所述第二系统根据所述第二应用界面的界面信息启动安装在所述第二系统中的所述第二应用以及绘制渲染得到所述第二应用界面；

所述第二系统向所述第一系统发送所述第二应用界面的界面数据；

所述第一系统根据所述界面数据显示所述第二窗口。

4.根据权利要求3所述的方法，其特征在于，所述第一系统向所述第二系统发送第二应用界面的界面信息，包括：

所述第一系统将所述第二应用界面的界面信息写入所述第一系统的第一存储区域，其中所述第一存储区域与所述第二系统中的第二存储区域存在映射关系；所述第二系统从所述第二存储区域中获取所述第二应用界面的界面信息。

5.根据权利要求4所述的方法，其特征在于，所述第一应用界面是浏览器界面，所述浏览器界面上包括所述第二应用界面对应的按钮，所述第一操作是用户在所述浏览器界面上点击所述第二应用界面对应的按钮的操作。

6.根据权利要求3所述的方法，其特征在于，所述第一系统向所述第二系统发送第二应用界面的界面信息，包括：

所述第一系统通过所述第一系统中的软件开发工具包SDK向所述第二系统中的SDK发送所述第二应用界面的界面信息。

7.根据权利要求6所述的方法，其特征在于，所述第一应用界面是应用商店界面，所述应用商店界面上包括所述第二应用界面对应的按钮，所述第一操作是用户在所述应用商店界面上点击所述第二应用界面对应的按钮的操作。

8.根据权利要求3-7中任一项所述的方法，其特征在于，所述第二应用界面的界面信息包括所述第二应用的标识。

9.根据权利要求8所述的方法，其特征在于，所述第二应用界面的界面信息还包括所述第二应用界面的深度链接。

10.根据权利要求8或9所述的方法，其特征在于，所述第二应用界面是所述第二应用的首页。

11.根据权利要求9所述的方法，其特征在于，所述第二应用界面是所述第二应用的指定应用页面。

12.根据权利要求8-11中任一项所述的方法，其特征在于，所述第二应用界面的界面信息还包括以下中的一个或多个：所述第二应用界面的尺寸、所述第二应用界面的分辨率、所述第二应用界面的转向。

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

通信接口，用于与其它电子设备通信；

存储器，用于存储计算机程序指令；

处理器，用于执行所述计算机程序指令，以支持所述电子设备实现如权利要求1-12中任一项所述的方法。

14.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序指令，所述计算机程序指令被处理电路执行时实现如权利要求1-12中任一项所述的方法。

15.一种包含指令的计算机程序产品，其特征在于，当所述计算机程序产品在计算机上运行时，使得所述计算机执行如权利要求1-12中任一项所述的方法。

16.一种芯片系统，其特征在于，所述芯片系统包括处理电路、存储介质，所述存储介质中存储有计算机程序指令；所述计算机程序指令被所述处理电路执行时实现如权利要求1-12中任一项所述的方法。