CN116932126A - 一种应用嵌入方法、装置、终端、介质及程序产品 - Google Patents

Abstract

本申请实施例公开了一种应用嵌入方法、装置、终端、介质及程序产品，其中的方法包括：在检测到第一应用的第一应用页面中存在嵌入第二应用的操作后，确定插件容器；在插件容器构建出第二应用的第二对象模型；并在插件容器中将第一应用的第一对象模型共享给第二应用；调用插件容器根据第二应用的第二对象模型，在第一应用页面中嵌入显示第二应用的第二应用页面；在检测到第一应用页面中的任一功能组件，被用于更新第二应用页面中的显示元素时，调用插件容器根据第二应用所共享的第一对象模型更新显示第二应用页面。采用本申请实施例能够在第一应用和第二应用之间共享对象模型，实现第一应用和第二应用之间的交互。

Description

一种应用嵌入方法、装置、终端、介质及程序产品

技术领域

本申请涉及计算机技术领域，具体涉及人工智能领域，尤其涉及一种应用嵌入方法，一种应用嵌入装置、一种终端、一种计算机可读存储介质及一种计算机程序产品。

背景技术

随着应用程序(或简称为应用)的广泛使用，应用程序提供的应用功能也愈加丰富，如有些应用程序支持应用嵌入功能。所谓应用嵌入功能可是指：在第一应用(或称为主应用或父应用)提供的应用页面中嵌入第二应用(或称为子应用)的功能。

经研究发现，应用程序提供的应用嵌入功能可以是通过容器方案实现的。常见的可通过Iframe创建容器以实现应用嵌入，Iframe具有环境隔离机制，这个使得Iframe创建的容器(或称为宿主环境)是全新且独立的；也就是说，第一应用和该容器承载的第二应用之间是相互独立运行的，从而该容器承载的第二应用的应用页面(或称为子页面)作为独立区域，不受父页面的运行影响。然而，这种强隔离性会导致主应用和子应用之间无法实现交互，如子应用无法使用主应用中的一些功能，使得在主应用中不能便捷地使用子应用，限制应用扩展能力。

发明内容

本申请实施例提供一种应用嵌入方法、装置、终端、介质及程序产品，能够在第一应用和第二应用之间共享对象模型，实现第一应用和第二应用之间的交互。

一方面，本申请实施例提供一种应用嵌入方法，该方法包括：

在检测到第一应用的第一应用页面中存在嵌入第二应用的操作后，确定用于承载第二应用的插件容器；

在插件容器中运行第二应用的脚本文件，以构建出第二应用的第二对象模型；并在插件容器中，将第一应用的第一对象模型共享给第二应用；第一对象模型包括第一应用的应用界面中的各功能组件所对应的组件变量的属性值；第二对象模型包括第二应用的应用界面中的各功能组件所对应的组件变量的属性值；

调用插件容器根据第二应用的第二对象模型，在第一应用页面中嵌入显示第二应用的第二应用页面；

在检测到第一应用页面中的任一功能组件，被用于更新第二应用页面中的显示元素时，调用插件容器根据第二应用所共享的第一对象模型更新显示第二应用页面。

另一方面，本申请实施例提供一种应用嵌入装置，该装置包括：

处理单元，用于在检测到第一应用的第一应用页面中存在嵌入第二应用的操作后，确定用于承载第二应用的插件容器；

处理单元，还用于在插件容器中运行第二应用的脚本文件，以构建出第二应用的第二对象模型；并在插件容器中，将第一应用的第一对象模型共享给第二应用；第一对象模型包括第一应用的应用界面中的各功能组件所对应的组件变量的属性值；第二对象模型包括第二应用的应用界面中的各功能组件所对应的组件变量的属性值；

调用单元，还用于调用插件容器根据第二应用的第二对象模型，在第一应用页面中嵌入显示第二应用的第二应用页面；

调用单元，还用于在检测到第一应用页面中的任一功能组件，被用于更新第二应用页面中的显示元素时，调用插件容器根据第二应用所共享的第一对象模型更新显示第二应用页面。

在一种实现方式中，第二应用的脚本文件是通过第二应用的全局变量，构建第二应用的第二对象模型的；其中，全局变量位于第二应用的脚本文件中；

处理单元，还用于：

对第二应用的脚本文件中的全局变量进行变量劫持，创建得到模型作用域。

在一种实现方式中，插件容器中包括模型作用域；处理单元，用于在插件容器中，将第一应用的对象模型共享给第二应用时，具体用于：

将第一应用的第一对象模型以及第二应用的第二对象模型，添加至模型作用域中；

根据约束关系在模型作用域中融合第一对象模型以及第二对象模型，以将第一对象模型共享给第二应用；其中，第一对象模型以及第二对象模型被融合成一个对象模型流。

在一种实现方式中，处理单元，还用于：

通过插件容器中的沙箱，在插件容器中创建脚本作用域；

根据约束关系将第一应用的脚本文件以及第二应用的脚本文件，添加至脚本作用域，以将第一应用的脚本文件共享给第二应用；其中，任一脚本文件包括：相应应用的应用页面中的各功能组件对应的组件变量；

处理单元，用于在插件容器中运行第二应用的脚本文件时，具体用于：

在插件容器中的脚本作用域中运行第二应用的脚本文件。

在一种实现方式中，处理单元，用于在检测到第一应用页面中的任一功能组件，被用于更新第二应用页面中的显示元素时，调用插件容器根据第二应用所共享的第一对象模型更新显示第二应用页面时，具体用于：

在检测到第一应用页面中的任一功能组件被用于更新第二应用页面中的显示元素时，调用插件容器从第二应用所共享的第一应用的脚本文件中，获取任一功能组件所对应的组件变量作为目标变量；

调用插件容器从第二应用所共享的第一对象模型中，获取目标变量对应的属性值；

通过第二应用的脚本文件根据目标变量对应的属性值，更新第二应用的第二对象模型；并调用插件容器根据更新后的第二对象模型，更新显示第二应用页面。

在一种实现方式中，处理单元，还用于：

获取第一应用的脚本文件对应的变量依赖关系，变量依赖关系指示：第一应用的脚本文件中的各个组件变量之间的调用关系；

将变量依赖关系挂载至脚本作用域中，以使在检测到第一应用页面中的任一功能组件被用于更新第二应用页面中的显示元素时，调用插件容器根据变量依赖关系，确定被任一功能组件对应的组件变量调用的其他组件变量，并将任一功能组件对应的组件变量和其他组件变量作为目标变量。

在一种实现方式中，第一应用关联有至少一个应用，至少一个应用中的各个应用均被允许嵌入至第一应用页面，且至少一个应用中的各个应用的网络地址存储在存储空间中；处理单元，还用于：

在检测到第一应用的第一应用页面中存在嵌入第二应用的操作后，从存储空间中查找第二应用的网络地址；

在查找到第二应用的网络地址后，基于第二应用的网络地址获取第二应用的脚本文件。

在一种实现方式中，处理单元，还用于：

在检测到第一应用的第一应用页面中存在嵌入第二应用的操作后，确定第二应用的尺寸数据，尺寸数据用于指示：第二应用的第二应用页面的界面尺寸；

根据尺寸数据在所述第一应用页面中绘制容器区域，容器区域用于显示第二应用的第二应用页面。

在一种实现方式中，处理单元，还用于：

在第二应用处于激活状态的生命周期的过程中，激活第一业务逻辑，并根据激活的第一业务逻辑执行目标操作；第一业务逻辑包括：定时调用逻辑或回调逻辑，中的任一种或两种；

其中，当第一应用页面中的输入焦点位于第二应用页面中时，第二应用处于激活状态的生命周期。

在一种实现方式中，处理单元，还用于：

在第二应用处于展开状态的生命周期的过程中，将插件容器的容器信息以及第二应用的应用信息进行缓存处理；

若检测到第二应用进入快照模式，则根据缓存的插件容器的容器信息以及第二应用的应用信息，重新调用插件容器加载第二应用的第二应用页面；

其中，插件容器的容器信息包括：尺寸数据以及坐标信息；第二应用的应用信息包括：第二应用的脚本文件以及第二对象模型。

在一种实现方式中，处理单元，还用于：

在第二应用处于删除状态的生命周期的过程中，调用插件容器在脚本作用域中删除第二应用的脚本文件，以在第一应用的第一应用页面中隐藏第二应用的第二应用页面。

另一方面，本申请提供了一种终端，该终端包括：

处理器，用于加载并执行计算机程序；

计算机可读存储介质，该计算机可读存储介质中存储有计算机程序，该计算机程序被处理器执行时，实现上述应用嵌入方法。

另一方面，本申请提供了一种计算机可读存储介质，计算机可读存储介质存储有计算机程序，该计算机程序适于由处理器加载并执行上述应用嵌入方法。

另一方面，本申请提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。终端的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该终端执行上述应用嵌入方法。

本申请实施例中，在检测到第一应用的第一应用页面中存在嵌入第二应用的操作后，可在插件容器中将第一应用的第一对象模型共享给第二应用，使得第二应用能够访问第一应用的第一对象模型。进一步的，在后续检测到第一应用页面中的任一功能组件被用于更新第二应用页面中的显示元素时，能够调用插件容器根据第二应用所共享的第一对象模型更新显示第二应用页面，以实现第二应用使用第一应用提供的功能，实现第二应用和第一应用之间的交互，在一定程度上可提升第二应用的应用扩展能力。

附图说明

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

图1示出了本申请一个示例性实施例提供的一种微前端的设计思路的流程示意图；

图2示出了本申请一个示例性实施例提供的一种应用嵌入系统的架构示意图；

图3示出了本申请一个示例性实施例提供的一种应用嵌入方法的流程示意图；

图4示出了本申请一个示例性实施例提供的一种在第一应用页面中嵌入第二应用的示意图；

图5示出了本申请一个示例性实施例提供的一种从开发者视图看到的第二应用，访问第一应用的内存变量的示意图；

图6示出了本申请一个示例性实施例提供的一种从开发者视图看到的第一对象模型和第二对象模型之间，融合为DOM流的示意图；

图7示出了本申请一个示例性实施例提供的一种在第一应用页面中渲染显示第二应用的第二应用页面的示意图；

图8示出了本申请一个示例性实施例提供的一种第二应用调用第一应用的功能组件的示意图；

图9示出了本申请一个示例性实施例提供的一种应用嵌入方法的流程示意图；

图10示出了本申请一个示例性实施例提供的一种在第一应用页面中输出提示窗口的示意图；

图11示出了本申请一个示例性实施例提供的一种采用快照模式，在第一应用页面中重建第二应用页面的重建时间对比示意图；

图12示出了本申请一个示例性实施例提供的一种公用资源复用的流程的示意图；

图13示出了本申请一个示例性实施例提供的一种生命周期的示意图；

图14示出了本申请一个示例性实施例提供的一种自定义事件的示意图；

图15示出了本申请一个示例性实施例提供的一种在第一应用页面中删除第二应用页面的示意图；

图16示出了本申请一个示例性实施例提供的一种应用嵌入装置的结构示意图；

图17示出了本申请一个示例性实施例提供的一种终端的结构示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

在本申请实施例中，涉及一种应用嵌入方案；该应用嵌入方案支持在第一应用中嵌入第二个应用，具体是在第一应用的应用页面中嵌入第二应用。为便于描述，本申请实施例将支持嵌入应用的第一应用(或第一应用程序)称为主应用，相应的将被嵌入至主应用的第二应用称为子应用，在后续实施例中对这两个称呼不作区分，在此说明。其中，应用或应用程序可是指为完成某项或多项特定工作的计算机程序。按照不同维度(如应用程序的运行方式、功能等)对应用程序进行归类，可得到同一应用程序在不同维度下的类型，其中：①按照应用程序的运行方式分类，应用程序可包括但不限于：安装在终端中的客户端、无需下载安装即可使用的小程序、通过浏览器打开的web应用程序等等。②按照应用程序的功能类型分类，应用程序可包括但不限于：社交类应用程序、办公类应用程序或娱乐类应用等；其中，社交类应用程序可包括：IM(Instant Messaging，即时通信)应用程序(如基于互联网的即时交流消息和社交交互的应用程序)、内容交互应用程序(如能够实现内容交互的应用程序)等等；办公类应用程序可包括：在线文档应用(或简称为在线文档，支持多个用户对象协作、云端实时保存的文档)、普通文档应用(区别于在线文档，其不支持多个用户对象对同一文档进行协同编辑)或幻灯片应用等等。

进一步的，根据主应用所属的应用类型不同，支持被嵌入至主应用的子应用所属的应用类型可能也不相同。以主应用所属的应用类型为在线文档应用为例，可嵌入至该在线文档应用中的子应用可包括：区别于在线文档应用本身的其他应用(或称为第三方应用)；例如：子应用和主应用是安装于同一终端中的相互独立的客户端。或者，子应用还可以包括：在线文档应用的自研应用(或称为自研功能)，该自研应用不能脱离在线文档应用去使用；例如：在线文档的自研应用可包括具有支持构建思维导图的功能的应用。为便于阐述，后续以主应用为在线文档应用，子应用为在线文档应用中的一种自研应用为例进行介绍，在此说明。

目前，在线文档应用中嵌入子应用的技术方案主要分为两类：一类是微前端技术方案(或简称为微前端(Micro Frontend))，基于该微前端的设计思路可设计容器方案，能够实现子应用的独立开发、测试及部署。其中，微前端借鉴了微服务的架构理念，核心在于将一个庞大的前端应用拆分成多个独立灵活型应用，每个应用都可以独立开发、独立运行、独立部署，再将这些小型应用融合为一个完整的应用，或者将原本运行已久、没有关联的几个应用融合为一个应用。一种微前端的设计思路的流程示意图可参见图1，如图1所示，通过控制器可将多个独立的应用(如微前端A、微前端B以及微前端C)融合为完整应用。目前，有四种典型的微前端实现方案：路由分发式微前端(即通过路由将不同的业务分发到不同的独立前端应用上)、使用iframe嵌入(即iframe创建一个全新且独立的宿主环境，使得主应用和子应用相互独立运行)、Web Components技术(即通过非倾入的方式封装组件，每个组件组织好它自身的结构，不会干扰页面上的其他代码)和自制框架(即通过设计加载和通讯机制实现微前端)。另一类是组件化技术方案，即使用组件化的方式开发子应用，并在编译阶段生成子应用，这能够实现子应用的规范化开发。其中，组件化方案的大致原理包括：在源码阶段，借助开发框架将子应用作为组件封装，供其他模块调用，以实现子应用嵌入；这种将子应用作为前端组件开发的方式，导致子应用无法独立开发测试部署，与主应用存在耦合性使得子应用对主应用的依赖性很强。

本申请实施例提供的应用嵌入方案是一种子应用容器化的方案，是采用微前端的设计思路设计的，具体是属于微前端中的自研框架中的一种实现。具体地，本申请实施例涉及的应用嵌入方案提供了一种新型的插件容器(或简称容器或Hina容器)，通过该插件容器可实现子应用(如第二应用)和主应用(如第一应用)之间共享文档对象模型(DocumentObject Model，DOM，或简称为对象模型)；通过共享文档对象模型使得第二应用的第二应用页面与第一应用页面融为一体，不仅实现将一个独立运行的应用(如任一子应用)转化成主应用(如在线文档应用)中的内容，而且第二应用能够调用第一应用提供的功能，实现第一应用和第二应用之间的交互，进而提高应用扩展能力(如主应用提供的功能能够被子应用所调用)。

本申请实施例提供的一种第二应用容器化方案的架构示意图可参见图2，图2示出了本申请一个示例性实施例提供的一种应用嵌入系统的架构示意图。如图2所示，该应用嵌入系统包括：插件容器、第一应用、Ark以及插件系统；其中，插件系统包括插件弹窗和插件云函数。

在实际的应用嵌入场景中，该应用嵌入系统中的各个部分执行应用嵌入方案的大致实现过程可包括：首先，开发者可采用npm(Node Package Manager，NodeJS包管理和分发工具)工具对插件容器进行打包，得到插件容器对应的npm包；并将该npm包添加至第一应用的插件库中，以实现将插件容器的npm包提供给品类进行安装使用，此处的品类可是指支持嵌入插件容器的第一应用。其次，当使用第一应用的用户对象具有在第一应用提供的第一应用页面中嵌入第二应用的需求时，可以通过调用插件系统中的插件云函数，以插件弹窗的形式将插件容器插入至第一应用提供的第一应用页面中。然后，通过插件容器实现第二应用和第一应用之间共享文档对象模型的过程，并通过该插件容器渲染显示第二应用的第二应用页面，以使第二应用嵌入至第一应用提供的应用界面中，即第二应用页面与第一应用页面融合。进一步的，在用户对象具有在第二应用的第二应用页面中使用第一应用的功能的需求时，插件容器可根据第一应用中的ark框架实现第二应用和第一应用之间的数据通信，进而实现第二应用调用第一应用的功能。例如，第一应用提供字体加粗功能，那么当用户对象具有使用该字体加粗功能对第二应用页面中的目标字符串(由一个或多个字符组成)进行加粗的需求时，响应于第一应用页面中的加粗组件(或按键、按钮或组件)被选中，插件容器可通过该加粗组件与第一应用进行数据交互，以达到第二应用页面中的目标字符串被加粗的效果。

基于前述描述可知，本申请实施例最重要的创新点在于提供一种新型的插件容器，通过该插件容器可实现第一应用和第二应用共享文档对象模型；上述主要给出插件容器与外界各个系统之间的交互过程，下面对本申请实施例提供的插件容器的结构进行较为详细的介绍；其中：

继续参见图2，插件容器(或称为Hina容器)主要分为多个层次结构，该层次结构自上而下分别为：渲染层、逻辑层、网络层及基础层。各个层次结构之间具有调用关系，通过调用关系可将各个独立层次结构的功能连接起来，以实现插件容器的功能。其中，插件容器中的各个层次结构之间的调用关系为：高层调用低层；也就是说，高层可调用低层执行相应操作。例如，逻辑层可调用网络层执行相应操作(如解析操作)；再如，渲染层可调用逻辑层执行相应操作(如渲染操作)；等等。其中，插件容器中的各个层次结构可包括一个或多个模块，使得层次结构具有相应模块所指示的功能。下面按照层次结构从下之上的顺序，对插件容器中的各个层次结构所包含的模块进行简单介绍，其中：

(1)基础层根据其所包含的模块指示的功能，可用于实现插件容器的基本功能。基础层可包括但不限于：日志模块、生命周期模块、通信模块。其中，日志模块可用于上报日志，该日志可包括：对插件容器运行过程中所产生的相关操作(如访问操作、运行操作或删除操作等)进行记录所产生的数据等。生命周期模块可用于在某个生命周期内执行为该某个生命周期所设置的业务逻辑，以在该某个生命周期内实现业务逻辑对应的功能。其中，生命周期可是指一个活动(activity)从启动到结束(或销毁)的过程；例如，可将插件容器从启动到卸载的过程称为一个生命周期，再如，可以将插件容器中开始渲染显示第二应用到结束渲染第二应用的构成称为一个生命周期，本申请实施例对整个流程中的生命周期不作限定。通信模块可用于实现插件容器和外界系统之间的通讯；例如，插件容器可通过该通信模块调用第一应用提供的功能或变量；更具体地，该通信模块在具有调用或使用第一应用提供的功能的需求时，可依赖于第一应用提供的Ark框架从第一应用中调用相应代码模块(或代码片段)，以实现相应功能。需要说明的是，上述基础层所包含的各个模块只是示例性的，在实际应用中基础层还可以包括用于实现其他功能的其他模块，在此不作穷举。

(2)网络层包括：JS(JavaScript)加载器、HTML(Hyper Text Markup L anguage，超文本标记)加载器以及CSS(Cascading Style Sheets，层叠样式表)加载器。每种加载器可用于加载相应数据格式的文件(或称为代码)，如JS加载器可通过调用基础层中的通信模块，以及请求的网络地址URL(Uniform Reso urce Locator，统一资源定位器)向服务器发起请求，以请求下载JS文件。同理，HTML加载器可用于加载HTML文件。CSS可用于加载CSS文件。前端的应用页面(或简称为页面)的展示和交互是由页面的JS文件、HTML文件以及CSS文件共同实现的；JS文件在应用页面中的作用是控制HTML中的各个显示元素(或简称为元素，如组件)，以实现应用页面中的内容的动态变化，如在应用页面中单击某个按钮后，在应用页面中新增某个元素的动态过程，是由JS文件操作HTML文件实现的。CSS文件和HTML文件配合使用可实现对应用页面的应用页面结构和样式(如颜色)的布局；例如，通过HTML文件可实现对应用页面的应用页面结构的布局，如显示元素在应用页面上的显示位置等，通过CSS可实现对各个显示元素的样式的步骤，如使应用页面中的字体颜色更加明亮等。

(3)逻辑层包括：JS解析器、HTML解析器、CSS解析器、CSS隔离、J S沙箱模块(Sandbox)以及全局劫持模块。其中，①JS解析器、HTML解析器以及CSS解析器可用于解析相应数据格式的文件。以JS解析器解析脚本文件为例，任一应用的脚本文件或称为JS文件，该脚本文件包括：相应应用(即该任一应用)的应用页面中的各功能组件对应的组件变量(或称为代码片段)；当应用页面的脚本文件被下载时，就可以通过JS解析器对下载的脚本文件进行解析并操作HTML文件，以创建该应用的文档对象模块(DocumentObjectModel，DOM)；该文档对象模块可简称为对象模块，任一应用的对象模块包括：相应应用的应用界面中的各功能组件所对应的组件变量的属性以及属性值。文档对象模块可被结构化为一颗对象树，通过该对象树可实现创建动态HTML，以更新应用页面的元素(或显示元素)。

②沙箱模块和全局劫持模块是插件容器中的核心模块，也是本申请实施例创建的插件容器能够实现第二应用和第一应用之间共享文档对象模型的关键技术实现。其中，沙箱模块可简称为沙箱或沙盒，是一个虚拟系统程序，提供一种按照安全策略限制程序行为的独立执行环境(或称为沙箱环境)；在该执行环境中可运行浏览器或应用程序，而不对外界产生任何影响。更为详细地，本申请实施例涉及的JS沙箱可是基于proxy(代理)技术实现的；凭借proxy技术可以设置访问拦截器，来劫持对象的性能，能够在一定程度上解决JS沙箱不能访问全局的问题。全局劫持模块可用于对脚本文件中的全局变量进行劫持，具体是依靠Prototype方法劫持技术来实现对脚本文件中的全局变量的劫持的。

(4)渲染层用于调用逻辑层中解析得到的文档对象模型，以实现渲染显示页面。具体地，渲染层中可包括：应用组件模块(Web components)以及封装模块(Shadow DOM)；其中，封装模块通过封装组件，可实现应用页面的样式隔离，如应用页面中的每个元素相互不影响。在渲染过程中，渲染层可根据文档对象模块渲染应用页面中的组件，以实现对应用页面的渲染显示。

基于前述介绍的应用嵌入方案、应用嵌入系统以及插件容器，本申请实施例提出更为详细的应用嵌入方法，该应用嵌入方法可以是由运行有第一应用的目标终端来执行，目标终端可包括但不限于：智能手机(如Android手机、iOS手机等)、平板电脑、便携式个人计算机、移动互联网设备(Mobile Internet Devices，简称MID)、智能电视或车载设备等智能设备；本申请实施例对目标终端的具体类型不作限定。

下面结合图3对本申请实施例提出的应用嵌入方法进行详细介绍。图3示出了本申请一个示例性实施例提供的一种应用嵌入方法的流程示意图；该应用嵌入方法可包括但不限于步骤S301-S304：

S301：在检测到第一应用的第一应用页面中存在嵌入第二应用的操作后，确定用于承载第二应用的插件容器。

具体实现中，在用户对象使用第一应用的过程中，可触发显示第一应用的第一应用页面，该第一应用页面可是第一应用提供的任一应用页面。例如，第一应用为在线文档应用，那么该第一应用的第一应用页面可以是任一在线文档的文档页面；再如，第一应用为幻灯片应用，或在线文档应用提供的幻灯片功能时，第一应用的第一应用页面可以是任一幻灯片文件中的一页幻灯片。然后，在用户对象具有在第一应用页面中嵌入另一个应用(即第二应用)的需求时，用户对象可在第一应用页面中执行嵌入操作，以实现在第一应用页面中嵌入第二应用。

其中，根据第一应用或第一应用页面的不同，在第一应用页面中执行的嵌入操作并不相同。下面结合附图4，并以第一应用为在线文档应用，第一应用页面为任一在线文档的文档页面为例，给出一种示例性的在文档页面中执行嵌入操作的示意图。如图4所示，在用户对象通过目标终端使用在线文档应用时，可在目标终端的终端屏幕(或显示屏幕、显示屏)中显示任一在线文档的文档页面401。该文档页面401中包括文档内容区域402(或称为编辑区)和工具栏403(或称为资源区)。其中，文档内容区域402用于显示相应在线文档的文档内容，如文档内容可包括：文字、图像、链接、动画等。工具栏403中承载有在线文档应用所提供的一种或多种功能组件；根据第一应用的应用类型不同，第一应用提供的功能组件并不相同，如在线文档应用提供的功能组件可包括但不限于：用于设置字体大小的功能组件、用于设置字体样式的功能组件、用于加粗字体的功能组件4021或者用于在文档内容区域402插入内容(如图片、子应用、表格等)的功能组件4022等等；当工具栏403中的任一功能组件被触发时，在线文档应用可执行被触发的功能组件所对应的操作。

假设用于触发在文档页面中嵌入第二应用的嵌入入口设置于功能组件4032中，那么响应于针对功能组件4032的触发(如单击)，可显示组件窗口40321，该组件窗口40321中包括嵌入入口404，且该嵌入入口404以功能组件的形式显示于组件窗口40321中。然后，响应于对嵌入入口404的触发，目标终端确定检测到在文档页面(即第一应用页面)中存在嵌入第二应用的操作。此实现方式下，用户对象在第一应用页面中执行的嵌入操作可包括：先触发功能组件4032，再触发组件窗口40321中的嵌入入口404。应当理解的是，用户对象在第一应用页面中执行的嵌入操作并不仅限于上述描述的一种实现方式；例如，若嵌入入口直接设置于工具栏中，那么用户对象在第一应用页面中执行的嵌入操作还可以包括：直接在工具栏中触发该嵌入入口的操作；本申请实施例对嵌入操作的具体实施过程不作限定。

进一步的，在检测到第一应用的第一应用页面中存在嵌入第二应用的操作后，表示用户对象想要在第一应用页面中插入第二应用，那么执行确定用于承载第二应用的一个插件容器的步骤；所谓用于承载第二应用的插件容器可是指：负责将第二应用的第二应用页面显示于第一应用页面之上，且负责第二应用和第一应用之间的交互的容器。正如前述所描述的，插件容器被以npm包的形式提供给第一应用使用，那么第一应用(或目标终端)可通过解析该npm包实现为第二应用创建一个插件容器；然后，在为第二应用创建一个插件容器后，可将该插件容器插入至第一应用的第一应用页面中，具体是插入至第一应用页面中的光标所在位置处，此时可在第一应用页面中显示插件容器所对应的容器区域。

在第一应用页面中插入插件容器的示意图可继续参见图4，假设用户对象在文档页面中执行嵌入操作之前，光标405在文档页面中的显示位置如图4所示的；那么用户对象在执行嵌入操作后，可将插件容器嵌入至执行嵌入操作之前光标405所在的显示位置处。其中，插件容器嵌入第一应用页面之后的界面表现形式为：在光标位置处显示一个容器区域406(或简称为区域)。

需要说明的是，第一应用的第一应用页面中支持嵌入多个第二应用；此实现方式下，每个第二应用对应一个插件容器，也就是说，每一个插件容器用于承载一个独立的第二应用；虽然第一应用页面中插入了多个第二应用，其数据不一样，但每个第二应用和主应用之间交互的逻辑是一样的。为便于阐述，后续实施例均以在第一应用页面中嵌入一个第二应用为例，对在主应用中嵌入子应用的实施过程进行阐述。

S302：在插件容器中运行第二应用的脚本文件，以构建第二应用的第二对象模型。

基于步骤S301所示的具体实施过程，可实现在第一应用的第一应用页面中插入插件容器；然后，可通过插件容器来动态运行获取到的第二应用的脚本文件，以便于构建得到第二应用的第二应用页面的第二对象模型(或称为第二文档对象模型DOM)。这样插件容器可以基于构建得到的第二对象模型，在第一应用页面中的容器区域内渲染显示第二应用的第二应用页面，以实现在第一应用页面中融合第二应用的第二应用页面。

其中，通过插件容器运行第二应用的脚本文件的过程，是在插件容器中的脚本作用域中实现的；换句话说，在插件容器中包括一个脚本作用域，该脚本作用域可理解为一个JS层面的执行环境，这样就可以在该JS执行环境中运行第二应用的脚本文件。具体实现中，在第一应用的第一应用页面中插入插件容器后，可通过插件容器中的JS沙箱在插件容器中创建一个脚本作用域；然后，将第一应用的脚本文件以及第二应用的脚本文件，添加至该脚本作用域中，使得第二应用和第一应用融为一体，具体是第二应用的JS代码和第二应用的JS代码融为一体；进而实现将第一应用的脚本文件共享给第二应用的脚本文件。然后，插件容器可在该脚本作用域中运行第二应用的脚本文件，以实现创建第二应用的第二对象模型；详细地，第二应用的脚本文件是通过第二应用的全局变量(如createElement、getElementById等)，实现构建第二应用的第二对象模型的，第二应用的全局变量位于第二应用的脚本文件中，因而通过执行第二应用的脚本文件可创建第二应用的第二对象模型。

基于此，本申请实施例支持在插件容器中采用沙箱技术创建一个脚本作用域，使得第一应用的脚本文件和第二应用的脚本文件可以被放置到同一作用域中，从而实现第一应用的脚本文件共享给第二应用。值得注意的是，考虑到本申请实施例中的第一应用的脚本文件和第二应用的脚本文件是位于同一脚本作用域中，这使得本申请实施例能够支持根据业务需求为第一应用和第二应用设置约束关系。例如，一种示例性的约束关系可以包括：第二应用可访问第一应用的内存变量，但第一应用不可访问第二应用的内存变量；那么在将第一应用的脚本文件和第二应用的脚本文件添加至脚本作用域时，需要将第二应用的脚本文件挂载至第一应用的脚本文件中。相比于现有技术中第一应用和第二应用的完全隔离，导致需要独立的两份维护成本而言，本申请实施例通过设置约束关系可以实现控制代码的维护成本。

综上所述，本申请实施例一方面可实现上下文不完全隔离，另一方面支持第二应用不仅能访问自己的内存变量，还可以在脚本作用域中访问到一部分第一应用的脚本文件中的内存变量，如访问内存变量window.hina；能够提高第二应用和第一应用之间的通信性能，满足数据同步需求和开发者的管理需求。其中，一种示例性的从开发者视图看到的第二应用访问第一应用的内存变量的示意图可参见图5。

另外，可以理解的是，第一应用的脚本文件中可包括至少一个代码片段(或称为组件变量)，该至少一个代码片段中的各个代码片段可用于实现不同的功能。并且，在执行第一应用的脚本文件时，会存在代码片段之间的相互调用；例如，执行代码片段1的过程中需调用代码片段2。考虑到本申请实施例可以实现第一应用和第二应用之间的DOM结构共享，进而可能存在第二应用调用第一应用的代码片段的需求；因此，本申请实施例支持对第一应用的脚本文件中的各个代码片段之间的变量依赖关系(或称为依赖模块变量，简称为依赖)进行管理，其中，变量依赖关系指示了第一应用的脚本文件中的各个组件变量之间的调用关系。其中，在第一应用页面中插入插件容器时，可一并向插件容器中注入变量依赖关系(如react或weblog等)，具体是将变量依赖关系挂载至插件容器中创建的脚本作用域中；以便于第二应用在资源加载时，可通过插件容器将该变量依赖关系传递给第二应用，使得第二应用可直接根据变量依赖关系调用第一应用的脚本文件中的相应代码片段，以减少第二应用的资源加载，提升第二资源的加载性能和加载速度。

S303：在插件容器中，将第一应用的第一对象模型共享给第二应用。

具体实现中，在插件容器中包括模型作用域，该模型作用域可理解为一个HTML层面的执行环境；该模型作用域可是通过劫持第二应用的脚本文件中的全局变量创建的。进一步的，通过将第一应用的第一对象模型以及第二应用的第二对象模型，添加至该模型作用域中；并根据约束关系在模型作用域中实现融合第一对象模型以及第二对象模型，就可以实现将第一对象模型共享给第二对象模型。在实际应用中，上述描述的第一应用的第一对象模型和第二应用的第二对象模型的融合过程可理解为：第一对象模型以及第二对象模型被融合成一个对象模型流，即第一对象模型和第二对象模型被挂载至对象模型流中，以实现第一应用和第二应用共享对象模型流。值得注意的是，上述提及的第一应用的第一对象模型是运行第一应用的脚本文件构建得到的，且插件容器并不会干涉第一应用的脚本文件的运行过程。其中，第一对象模型包括第一应用的应用界面中的各功能组件所对应的组件变量的属性值；第二对象模型包括第二应用的应用界面中的各功能组件所对应的组件变量的属性值。

其中，本申请实施例支持在插件容器中采用全局劫持技术创建一个模型作用域；具体是在加载得到第二应用的脚本文件后，对该第二应用的脚本文件中的全局变量进行变量劫持，创建得到一个特定的HTML操作作用域(即模型作用域)；这样可将第一应用的第一对象模型和第二应用的第二对象模型放置到该HTML操作作用域中，从而实现将第一应用的第一对象模型和第二应用的第二对象模型挂载至对象模型流中。通过在模型作用域中融合第一应用的第一对象模型和第二应用的第二对象模型，可实现第一应用和第二应用之间共享对象模型流(或称为DOM结构)，即第一应用第二应用的对象模型彼此可见，使得第二应用的第二应用页面中的显示元素变化在可控情况下，可与第一应用产生交互。其中，一种示例性的从开发者视图看到的第一对象模型和第二对象模型之间融合为DOM流的示意图可参见图6；如图6所示的，第二对象模型所包含的标签属性均被添加至对象模型流中，以实现与第一对象模型的融合。

还需说明的是，与步骤S302中描述的约束关系类似的，在将第一对象模型和第二对象模型添加至模型作用域的过程中，同样可以根据约束条件将第二对象模型挂载至第一对象模型中，使得第二对象模型成为第一对象模型中的一部分；从而达到控制代码的维护成本的目的。其中，约束关系的相关内容可参见前述相关描述，在此不作赘述。

S304：调用插件容器根据第二应用的第二对象模型，在第一应用页面中嵌入显示第二应用的第二应用页面。

具体实现中，插件容器在得到第二应用的第二对象模型(即DOM树)后，可将第二对象模型的DOM树，与，对第二应用的CSS文件解析得到的CSS树合并，生成Rendering Tree(渲染树)。然后，在第一应用页面中的容器区域内布局该渲染树，如确定待绘制的第二应用的第二应用页面中的各个显示元素的尺寸、位置等。然后，绘制该渲染树，以实现绘制在容器区域内绘制第二应用页面的像素信息。最后，将布局渲染树得到的信息，以及绘制渲染树得到的信息进行合并，以实现根据该渲染树在第一应用页面中的容器区域内嵌入显示(或称为渲染显示)第二应用的第二应用页面。

一种示例性的在第一应用页面中渲染显示第二应用的第二应用页面的示意图可参见图7；如图7所示，可在第一应用页面701中插入的容器区域内，渲染显示第二应用的第二应用页面；其中，第二应用的第二应用页面可是指第二应用页面中的任一页面(如主页面)，本申请实施例对第二应用页面不作限定。另外，在第二应用的第二应用页面渲染显示至第一应用页面中的情况下，表示第二应用已嵌入至第一应用中；因此，用户对象可以在第二应用中进行单独交互，所谓单独交互可是指用户对象只与第二应用之间进行人机交互，即用户对象可在第一应用界面中使用第二应用的功能，或对第二应用页面中的显示元素进行操作(如移动、删除或新增显示元素等)。例如，第二应用为视频类应用，那么用户对象可以在第一应用界面中播放第二应用提供的视频，即在第一应用界面中的容器区域内播放第二应用提供的视频。

S305：在检测到第一应用页面中的任一功能组件被用于更新第二应用页面中的显示元素时，调用插件容器根据第二应用所共享的第一对象模型更新显示第二应用页面。

基于前述对脚本作用域和模型作用域的相关描述可知，本申请实施例通过在插件容器中采用沙箱技术创建脚本作用域，可实现将第一应用的脚本文件和第二应用的脚本文件放到同一引擎(或执行环境)中；并且，通过在插件容器中采用全局劫持技术创建模型作用域，可实现将第一应用的第一对象模型和第二应用的第二对象模型挂载至DOM流中，进而实现第一应用和第二应用共享DOM结构。基于上述这种设计，使得上下文并不完全隔离，且能够实现内存变量的共享，也使得本申请实施例支持第二应用调用或使用第一应用提供的功能组件。

具体地，第二应用调用第一应用提供的功能组件的具体实施过程可包括：首先，当目标终端在检测到第一应用页面中的任一功能组件，被用于更新第二应用页面中的显示元素时，表示用户对象想要使用第一应用提供的该任一功能组件的相应功能，此时可调用插件容器从脚本作用域中的第二应用所共享的第一应用的脚本文件中，获取该任一功能组件所对应的组件变量作为目标变量。然后，调用插件容器从模型作用域中的第二应用所共享的第一对象模型中，或者，第二应用所共享的对象模型流中，获取目标变量对应的属性以及属性的属性值，该属性可用于定义第一应用页面中被选中的该任一功能组件的功能。然后，通过第二应用的脚本文件根据目标变量对应的属性值，来更新第二应用的第二对象模型，得到更新后的第二对象模型。最后，调用插件容器根据该更新后的第二对象模型，在第一应用页面中的容器区域内更新显示第二应用页面。

其中，上述提及的获取到的目标变量可包括：该任一功能组件对应的组件变量(如用于实现该任一功能组件的相应功能的代码片段)；以及，与该任一功能组件对应的组件变量之间存在变量依赖关系的其他组件变量，如该其他组件变量可包括该任一功能组件对应的组件变量在运行过程中所需调用的组件变量。变量依赖关系的相关介绍可参见前述描述，在此不作赘述。具体实现中，在检测到第一应用页面中的任一功能组件被用于更新第二应用页面中的显示元素时，调用插件容器根据变量依赖关系，确定被任一功能组件对应的组件变量调用的其他组件变量，并将第二应用中的该任一功能组件对应的组件变量，以及被该组件变量调用的其他组件变量作为目标变量。

基于上述对第二应用调用第一应用的功能组件的具体实现过程的相关描述，下面结合图8给出第二应用调用第一应用的功能组件的一种界面示意图；如图8所示，在第一应用的第一应用页面801中嵌入显示第二应用的第二应用页面802，该第二应用页面802中包括字符串“子应用内容”；若用户对象想要对字符串“子应用内容”中的部分内容“子应用”进行字体加粗处理，则用户对象可先在第二应用页面802中选中待处理的“子应用”，然后在第一应用页面801中的工具栏中选中具有字体加粗功能的功能组件803。此时，目标终端确定检测到第一应用页面801中的功能组件803，被用于更新第二应用页面802中的显示元素“子应用”，则可调用插件容器根据第二应用所共享的第一对象模型，来更新显示第二应用页面802中的显示元素“子应用”，更新后的第二应用页面802中的显示元素“子应用”表现为加粗效果。

本申请实施例中，在检测到第一应用的第一应用页面中存在嵌入第二应用的操作后，可在插件容器中将第一应用的第一对象模型共享给第二应用，使得第二应用能够访问第一应用的第一对象模型。进一步的，在后续检测到第一应用页面中的任一功能组件被用于更新第二应用页面中的显示元素时，能够调用插件容器从脚本作用域中访问到第一应用的第一脚本文件中的目标变量，并根据该目标变量从模型作用域中的第一对象模型中确定相应的属性值，再将该属性值添加至第二应用的第二对象模型中，以为第二应用中的显示元素添加属性；从而达到第二应用使用第一应用提供的该任一功能组件对应的功能。

上述图3所示实施例给出了本申请实施例提供的应用嵌入方法的主要实施过程，下面结合图2所示的插件容器的各个层次结构，给出应用嵌入方法的完整实施流程；请参见图9，图9示出了本申请一个示例性实施例提供的一种应用嵌入方法的流程示意图；该应用嵌入方法可由目标终端来执行，该应用嵌入方法可包括步骤S901-S909：

S901：第一应用在检测到第一应用页面中存在嵌入第二应用的操作时，获取应用参数。

需要说明的是，第一应用检测在第一应用页面中是否存在用户对象执行的，用于嵌入第二应用的操作(或嵌入操作)的具体实施过程，可参见前述图3所示实施例中步骤S301所示的具体实施过程的相关描述，在此不作赘述。

具体实现中，在第一应用检测到第一应用页面中存在用户对象执行的，嵌入第二应用的操作后，第一应用从插件侧(或插件库)中获取插件容器(如以npm包形式存在)，并获取该待嵌入的第二应用的应用参数；然后，将该第二应用的应用参数填写至插件容器的代码中，便于插件容器基于该第二应用的应用参数承载该第二应用，以实现将第二应用嵌入至第一应用的第一应用页面中。其中，第二应用的应用参数可包括但不限于：网络地址(或称为统一资源定位器(Uniform Resource Locator，URL))、尺寸数据等。第二应用的网络地址用于指示：存放第二应用的资源(如脚本文件、样式文件等等)的服务器的IP地址。第二应用的尺寸数据用于指示：第二应用的第二应用页面的界面尺寸。

下面对第一应用获取第二应用的应用参数的具体实施方式进行简单介绍，其中：

实施方式一：支持由开发者预先将第一应用关联的至少一个应用的应用参数存储在第一应用的存储空间中；此实现方式下，在检测到第一应用的第一应用页面中存在嵌入第二应用的操作后，可从第一应用的存储空间中查到到第二应用的应用参数。具体地，开发者可实现将第一应用关联的至少一个应用存储至第一应用的存储空间中，该与第一应用关联的至少一个应用可以是由开发者指定的，且均被允许嵌入至第一应用页面的应用。

基于前述描述可知，应用的应用参数可包括多种，如网络地址以及尺寸数据；因此，在将应用的应用参数存储至第一应用的存储空间的过程中，可以对应用参数进行分类存储。例如，在存储空间中的一个子空间中存储第一应用关联的至少一个应用中的各个应用的网络地址，以及，在存储空间中的另一个子空间中存储第一应用的关联的至少一个应用中的各个应用的尺寸数据。通过分类存储应用参数的方式，在一定程度上可提高应用参数的查到速率。当然，本申请实施例并不限定应用参数的具体存储格式，上述只是对应用参数的存储格式的一种举例说明。

实施方式二：支持由用户对象在第一应用页面中输入待嵌入至第一应用页面的第二应用的应用参数；此实现方式下，在检测到第一应用的第一应用页面中存在嵌入第二应用的操作后，可在第一应用页面中显示一个提示窗口，该提示窗口用于提示需输入第二应用的应用参数，这样用户对象可在该提示窗口中输入第二应用的应用参数。其中，在提示窗口中输入第二应用的应用参数的方式可包括但不限于：通过从粘贴板中的将第二应用的应用参数粘贴至该提示窗口内；或者，在该提示窗口内通过虚拟键盘(或目标终端的外接输入设备)输入第二应用的应用参数；等等。然后，目标终端可根据用户对象输入的第二应用的应用参数执行相关操作；如应用参数为第二应用的网络地址，则目标终端根据该网络地址从服务器拉取第二应用的资源。

以应用参数包括网络地址和尺寸数据为例，一种示例性的在第一应用页面中输出提示窗口的示意图可参见图10，如图10所示，在第一应用的第一应用页面中检测到存在嵌入第二应用的操作后，可在第一应用页面中输出提示窗口1001；其中，该提示窗口1001中包括网络地址输入栏1002和尺寸数据输入栏1003，以便于用户对象可直接在相应输入栏中输入相应参数，这样目标终端就可以获取到第二应用的应用参数。

值得注意的是，上述只是给出两种示例性的获取第二应用的应用参数的实施过程，本申请实施例对第一应用获取第二应用的应用参数的具体实施过程不作限定。

S902：第一应用确定用于承载第二应用的插件容器，以实现在第一应用页面中插入插件容器。

其中，第一应用在第一应用页面中插入插件容器时，是按照子应用的尺寸数据进行插入的。具体地，在获取到第二应用的尺寸数据后，可按照该尺寸数据在第一应用页面中绘制用于渲染显示第二应用的第二应用页面的容器区域，以实现在第一应用页面中插入插件容器。例如，在检测到第一应用的第一应用页面中存在嵌入第二应用的操作后，获取到的第二应用的尺寸数据为“长5厘米，宽5厘米”，则在第一应用页面中嵌入的插件容器的容器区域表现为一个5*5厘米的正方形区域。正如前述所描述的，该第二应用的尺寸数据可以是由开发人员预先设定的，或者，是由用户对象自定义的，那么与第一应用关联的至少一个应用中的各个应用的尺寸数据可能存在不同；进而不同的应用嵌入到第一应用页面时所显示的容器区域的显示大小可能是不同的，这能够丰富第二应用嵌入至第一应用页面的嵌入样式，满足用户对象对第一应用页面中嵌入的容器区域的自定义需求。

S903：插件容器中的逻辑层初始化沙箱以创建脚本作用域，以及劫持全局变量以创建模型作用域。

S904：插件容器中的网络层加载第二应用的脚本文件、样式文件以及超文本文件。

步骤S903-S904中，在获取到待嵌入至第一应用页面的第二应用的网络地址后，如在第一应用的存储空间中查找到第二应用的网络地址后；本申请实施例提供的插件容器就可以通过url链接(即网络地址)的方式承载第二应用。具体实现中，插件容器可基于第二应用的网络地址获取(或下载、加载)第二应用的资源，该资源可包括用于实现页面显示的各种数据格式的文件，如脚本文件(JS文件)、样式文件(CSS文件)以及超文本文件(HTML文件)；然后，插件容器根据下载的第二应用的资源在第一应用页面中的容器区域内嵌入显示第二应用的第二应用页面。

需要说明的是，插件容器根据第二应用的网络地址加载第二应用的资源的加载过程可能是动态的；例如，插件容器在加载到第二应用的部分脚本文件后，可根据已加载的部分脚本文件继续下载剩余的脚本文件。那么在第二应用的资源的动态加载过程中，支持在插件容器的逻辑层中初始化沙箱以创建脚本作用域，以及劫持全局变量以创建模型作用域。

还需说明的是，在插件容器加载第二应用的资源的过程中，具体是插件容器调用网络层加载第二应用的资源的过程中，本申请实施例还支持采用快照(或快照模式)来对加载的第二应用的资源进行缓存，这样后续在需要获取第二应用的资源的情况下，可通过快照模式实现数据恢复或还原，进而提升优化加载的时间。所谓快照模式可是指一种基于时间点的数据拷贝技术，它的目的在于能够记录出某个时刻的数据信息(如第二应用的资源，如脚本文件)并将其保存，如果后续发生故障需要数据恢复的实施，可通过快照来将数据恢复到之前时间点的状态，进而实现数据的初始化还原。举例来说，在第一应用页面中显示第二应用页面的过程中，可对第二应用的资源(如脚本文件)进行快照缓存，那么在第二应用页面被滑动隐藏后需重新显示的情况下，可以根据快照缓存快速获取第二应用的资源进行数据还原。一种采用快照模式在第一应用页面中重建第二应用页面的示例性重建时间对比图可参见图11；如图11所示，现有的不支持快照模式的应用重建所需的时间大约在300毫秒(ms)之上，采用本申请实施例提供的快照模式进行应用重建所需的时间在15毫秒之下。由此可见，采用快照模式进行资源缓存，可省略从服务器中重新下载第二应用的资源的步骤，进而提高资源加载性能。

还需说明的是，基于前述描述可知本申请实施例能够实现第一应用和第二应用对DOM流的共享，这使得本申请实施例还支持公用资源的复用；其中，公用资源的复用是指公用资源的重复使用，公用资源可包括上述提及的脚本文件、样式文件中的需重复使用的文件。在具体实现中，开发者可将应用加载过程中需重复使用的资源确定为公用资源；并将公用资源设置为全局变量缓存起来，具体是为公用资源设置global属性，以实现将公用资源设置为全局变量。这样加载待嵌入至第一应用中的任一个或多个第二应用的过程中，均可以直接从缓存中获取公用资源进行加载，而不必每次都从服务器中下载能够重复使用的资源；在本申请实施例中将加载公用资源的过程称为预加载，在此说明。这不仅能够提升第二应用的加载性能，还可以实现多个第二应用之间的资源共享；并且，还可以由第二应用控制其可共享的公用资源，提高公用资源确定的灵活性。

下面结合图12给出公用资源复用的流程的示意图；如图12所示，在加载第二应用的资源的过程中，若检测到待加载的任一资源被设置global属性，表示可优先读取缓存中的该任一资源，则在缓存中查找该任一资源；若在缓存中查找到该任一资源，则实现对该任一资源的读取。若在缓存中未查找到该任一资源，可根据第二应用的网络地址下载该任一资源，并在下载完成后对该任一资源进行缓存处理，这样下次访问该任一资源时就不用重复下载，而是可直接从缓存中读取该任一资源，提高资源加载速率。

S905：插件容器中的逻辑层运行第二应用的脚本文件，以构建第二应用的第二对象模型。

S906：插件容器中的逻辑层进行插件容器挂载，以实现将第一应用的脚本文件和第一对象模型共享给第二应用。

S907：插件容器中的渲染层调用逻辑层中的第二应用的第二对象模型，在第一应用页面中的容器区域内渲染显示第二应用的第二应用页面。

S908：在检测到第一应用页面中的任一功能组件，被用于更新第二应用页面中的显示元素时，调用插件容器与第一应用中的Ark进行数据通信，以实现根据第二应用所共享的第一对象模型更新显示第二应用页面。

需要说明的是，步骤S905-S908所示的具体实施过程，可参见前述图3所示实施例中的步骤S302-S305所示的具体实施过程的相关描述，在此不作赘述。

另外，本申请实施例还支持丰富的生命周期，以便于开发者在各个生命周期开发或设置具体的业务逻辑。具体实现中，本申请实施例支持在第二应用嵌入第一应用的第一应用页面的过程中，将一个或多个步骤设置为生命周期，这样开发者可在任一生命周期插入业务逻辑。这样在第二应用的第二应用页面成功插入至第一应用的第一应用页面后，可在各个生命周期内响应开发者设置的相应的业务逻辑。举例来说，对于第二应用，可以根据具体应用场景采用如图13所示的生命周期；如图13所示，开发者可以在第一应用中嵌入第二应用的各个生命周期设置一种或多种业务逻辑，这样用户对象在使用第二应用的过程中，当第二应用进入相应生命周期后，可激活业务逻辑实现相应操作。

下面给出几种示例性的生命周期，其中：

①第二应用处于激活状态“appDidBecomeActive”的生命周期。在第二应用处于激活状态的生命周期的过程中，可以激活运行时所需的一些业务逻辑，如激活第一业务逻辑，该第一业务逻辑可包括但不限于：定时调用逻辑或回调逻辑中的一种或两种；然后，根据激活的第一业务逻辑执行目标操作。该目标操作可是指：调用用于实现第一业务逻辑的目标函数时所执行的操作；例如，用于实现定时调用逻辑的目标函数可包括setInterval函数，那么可调用setInterval函数实现定时触发第二应用的某种功能；再如，用于实现回调逻辑的目标函数可包括requestAnimation函数，那么可以调用requestAnimation函数实现重新回调画面的功能。其中，实现第二应用处于激活状态的操作可包括：光标落入第二应用的第二应用页面中的任一显示位置的操作。

②第二应用处于未激活状态“appDidBecomeInactive”的生命周期；在第二应用处于未激活状态的生命周期的过程中，可以停止未激活状态下不需要的业务逻辑(如上述提及的第一业务逻辑)，以达到优化性能的目的；具体是停止调用用于实现业务逻辑的目标函数；其中，实现第二应处于未激活状态的操作可包括：光标落入第一应用页面中除第二应用页面以外的任一显示区域。

③第二应用处于展示状态(appDidAppear)的生命周期。在第二应用处于展示状态的生命周期的过程中，可以将插件容器的容器信息以及第二应用的应用信息进行缓存处理，以便于后续做快照模式下的初始化还原；所谓快照模式下的初始化还原可是指：若检测到第二应用进入快照模式，则可以根据缓存的插件容器的容器信息以及第二应用的应用信息，重新调用插件容器加载第二应用的第二应用页面；其中，插件容器的容器信息包括：尺寸数据以及坐标信息等；第二应用的应用信息包括：第二应用的脚本文件以及第二对象模型等。

④第二应用处于删除状态(appWillDisappear)的生命周期；在第二应用处于删除状态的生命周期的过程中，为第二应用设置的业务逻辑可包括缓存资源；即在第一应用页面中删除容器区域之前，先对插件容器的尺寸数据、坐标信息等进行缓存，以为快照模式下的初始化还原做准备。或者，在第二应用处于删除状态的生命周期的过程中，还可以调用插件容器在脚本作用域中删除第二应用的脚本文件，以实现从第一应用的第一应用页面中隐藏第二应用的第二应用页面。其中，第二应用进入删除状态的操作可包括：滚动显示第一应用页面的过程中，第二应用页面被隐藏，以使第二应用页面不可见的操作。⑤第二应用处于卸载状态(appWillUnmount)的生命周期；在第二应用处于卸载状态的生命周期的过程中，为第二应用设置的业务逻辑可包括：清除第二应用的资源以及缓存等，如删除第二应用实例；若第一应用删除第二应用的网络地址时，才确定在第一应用页面删除容器区域，以实现在第一应用中对第二应用的彻底删除。

下面结合图14，并以在第二应用处于展示状态的生命周期时，开发者为第二应用设置的自定义事件(或业务逻辑)为：将第二应用页面下载保存为图标，为例，给出第二应用和第一应用共同完善第二应用的自定义事件的示意图；如图14所示，在第二应用具有自定义事件“下载保存图片”的情况下，响应于对第二应用页面1401中的任一显示位置的触发，可显示下载按钮1402；当该下载按钮1402被触发(如单击)时，表示用户对象想要将第二应用页面下载并保存为图片，则可将第二应用页面设置为图片格式，以实现将第二应用页面下载保存为图片。由此可知，本申请实施例支持第一应用和第二应用之间，基于事件(如第二应用的自定义事件)的通数据信，使得通信管理更加清晰，通信成本更低。

可以理解的是，上述是本申请实施例给出的几种示例性的生命周期，以及相应的业务逻辑。在实际应用中，生命周期和生命周期相应的业务逻辑可以发生改变；例如，本申请实施例还支持开发者在第二应用处于展示状态时，设置样式隔离(如动态给样式文件加前缀，或使用渲染层中的封装模块(shadow dom)来隔离)的业务逻辑，这样可避免第二应用页面中的显示元素和第一应用页面中的显示元素的重叠或交错显示，达到美化页面样式的目的。

S909：插件容器卸载，以实现在第一应用页面中删除容器区域。

所谓插件容器卸载可是指：在第一应用中卸载或删除插件容器；由于插件容器是用来承载第二应用的，那么当在第一应用中删除插件容器后，在第一应用的第一应用页面中也删除第二应用页面。其中，本申请实施例中的第一应用可通过强制清除第二应用的网络地址，或者，改变第二应用的网络地址等方式，实现清除插件容器的挂载，在此不作详细介绍。一种示例性的在第一应用页面中删除第二应用页面的实现过程可参见图15。

本申请实施例中，在检测到第一应用的第一应用页面中存在嵌入第二应用的操作后，可在插件容器中将第一应用的第一对象模型共享给第二应用，使得第二应用能够访问第一应用的第一对象模型。进一步的，在后续检测到第一应用页面中的任一功能组件被用于更新第二应用页面中的显示元素时，能够调用插件容器从脚本作用域中访问到第一应用的第一脚本文件中的目标变量，并根据该目标变量从模型作用域中的第一对象模型中确定相应的属性值，再将该属性值添加至第二应用的第二对象模型中，以为第二应用中的显示元素添加属性；从而达到第二应用使用第一应用提供的该任一功能组件对应的功能。

上述详细阐述了本申请实施例的方法，为了便于更好地实施本申请实施例的上述方法，相应地，下面提供了本申请实施例的装置。

图16示出了本申请一个示例性实施例提供的一种应用嵌入装置的结构示意图，该应用嵌入装置可以是运行于目标终端的一个计算机程序(包括程序代码)；该应用嵌入装置可以用于执行图3及图9所示的方法实施例中的部分或全部步骤；该装置包括如下单元：

处理单元1601，用于在检测到第一应用的第一应用页面中存在嵌入第二应用的操作后，确定用于承载第二应用的插件容器；

处理单元1601，还用于在插件容器中运行第二应用的脚本文件，以构建出第二应用的第二对象模型；并在插件容器中，将第一应用的第一对象模型共享给第二应用；第一对象模型包括第一应用的应用界面中的各功能组件所对应的组件变量的属性值；第二对象模型包括第二应用的应用界面中的各功能组件所对应的组件变量的属性值；

调用单元1602，还用于调用插件容器根据第二应用的第二对象模型，在第一应用页面中嵌入显示第二应用的第二应用页面；

调用单元1602，还用于在检测到第一应用页面中的任一功能组件，被用于更新第二应用页面中的显示元素时，调用插件容器根据第二应用所共享的第一对象模型更新显示第二应用页面。

在一种实现方式中，第二应用的脚本文件是通过第二应用的全局变量，构建第二应用的第二对象模型的；其中，全局变量位于第二应用的脚本文件中；

处理单元1601，还用于：

对第二应用的脚本文件中的全局变量进行变量劫持，创建得到模型作用域。

在一种实现方式中，插件容器中包括模型作用域；处理单元1601，用于在插件容器中，将第一应用的对象模型共享给第二应用时，具体用于：

将第一应用的第一对象模型以及第二应用的第二对象模型，添加至模型作用域中；

根据约束关系在模型作用域中融合第一对象模型以及第二对象模型，以将第一对象模型共享给第二应用；其中，第一对象模型以及第二对象模型被融合成一个对象模型流。

在一种实现方式中，处理单元1601，还用于：

通过插件容器中的沙箱，在插件容器中创建脚本作用域；

根据约束关系将第一应用的脚本文件以及第二应用的脚本文件，添加至脚本作用域，以将第一应用的脚本文件共享给第二应用；其中，任一脚本文件包括：相应应用的应用页面中的各功能组件对应的组件变量；

处理单元1601，用于在插件容器中运行第二应用的脚本文件时，具体用于：

在插件容器中的脚本作用域中运行第二应用的脚本文件。

在一种实现方式中，处理单元1601，用于在检测到第一应用页面中的任一功能组件，被用于更新第二应用页面中的显示元素时，调用插件容器根据第二应用所共享的第一对象模型更新显示第二应用页面时，具体用于：

在检测到第一应用页面中的任一功能组件被用于更新第二应用页面中的显示元素时，调用插件容器从第二应用所共享的第一应用的脚本文件中，获取任一功能组件所对应的组件变量作为目标变量；

调用插件容器从第二应用所共享的第一对象模型中，获取目标变量对应的属性值；

通过第二应用的脚本文件根据目标变量对应的属性值，更新第二应用的第二对象模型；并调用插件容器根据更新后的第二对象模型，更新显示第二应用页面。

在一种实现方式中，处理单元1601，还用于：

获取第一应用的脚本文件对应的变量依赖关系，变量依赖关系指示：第一应用的脚本文件中的各个组件变量之间的调用关系；

将变量依赖关系挂载至脚本作用域中，以使在检测到第一应用页面中的任一功能组件被用于更新第二应用页面中的显示元素时，调用插件容器根据变量依赖关系，确定被任一功能组件对应的组件变量调用的其他组件变量，并将任一功能组件对应的组件变量和其他组件变量作为目标变量。

在一种实现方式中，第一应用关联有至少一个应用，至少一个应用中的各个应用均被允许嵌入至第一应用页面，且至少一个应用中的各个应用的网络地址存储在存储空间中；处理单元1601，还用于：

在检测到第一应用的第一应用页面中存在嵌入第二应用的操作后，从存储空间中查找第二应用的网络地址；

在查找到第二应用的网络地址后，基于第二应用的网络地址获取第二应用的脚本文件。

在一种实现方式中，处理单元1601，还用于：

在检测到第一应用的第一应用页面中存在嵌入第二应用的操作后，确定第二应用的尺寸数据，尺寸数据用于指示：第二应用的第二应用页面的界面尺寸；

根据尺寸数据在所述第一应用页面中绘制容器区域，容器区域用于显示第二应用的第二应用页面。

在一种实现方式中，处理单元1601，还用于：

在第二应用处于激活状态的生命周期的过程中，激活第一业务逻辑，并根据激活的第一业务逻辑执行目标操作；第一业务逻辑包括：定时调用逻辑或回调逻辑，中的任一种或两种；

其中，当第一应用页面中的输入焦点位于第二应用页面中时，第二应用处于激活状态的生命周期。

在一种实现方式中，处理单元1601，还用于：

在第二应用处于展开状态的生命周期的过程中，将插件容器的容器信息以及第二应用的应用信息进行缓存处理；

若检测到第二应用进入快照模式，则根据缓存的插件容器的容器信息以及第二应用的应用信息，重新调用插件容器加载第二应用的第二应用页面；

其中，插件容器的容器信息包括：尺寸数据以及坐标信息；第二应用的应用信息包括：第二应用的脚本文件以及第二对象模型。

在一种实现方式中，处理单元1601，还用于：

在第二应用处于删除状态的生命周期的过程中，调用插件容器在脚本作用域中删除第二应用的脚本文件，以在第一应用的第一应用页面中隐藏第二应用的第二应用页面。

根据本申请的一个实施例，图16所示的应用嵌入装置中的各个单元可以分别或全部合并为一个或若干个另外的单元来构成，或者其中的某个(些)单元还可以再拆分为功能上更小的多个单元来构成，这可以实现同样的操作，而不影响本申请的实施例的技术效果的实现。上述单元是基于逻辑功能划分的，在实际应用中，一个单元的功能也可以由多个单元来实现，或者多个单元的功能由一个单元实现。在本申请的其它实施例中，该应用嵌入装置也可以包括其它单元，在实际应用中，这些功能也可以由其它单元协助实现，并且可以由多个单元协作实现。根据本申请的另一个实施例，可以通过在包括中央处理单元(CPU)、随机存取存储介质(RAM)、只读存储介质(ROM)等处理元件和存储元件的例如计算机的通用计算设备上运行能够执行如图3及图9所示的相应方法所涉及的各步骤的计算机程序(包括程序代码)，来构造如图16中所示的应用嵌入装置，以及来实现本申请实施例的应用嵌入方法。计算机程序可以记载于例如计算机可读记录介质上，并通过计算机可读记录介质装载于上述计算设备中，并在其中运行。

本申请实施例中，处理单元1601在检测到第一应用的第一应用页面中存在嵌入第二应用的操作后，可在插件容器中将第一应用的第一对象模型共享给第二应用，使得第二应用能够访问第一应用的第一对象模型。进一步的，在后续检测到第一应用页面中的任一功能组件被用于更新第二应用页面中的显示元素时，能够调用插件容器根据第二应用所共享的第一对象模型更新显示第二应用页面，以实现第二应用使用第一应用提供的功能，实现第二应用和第一应用之间的交互，在一定程度上可提升第二应用的应用扩展能力。

图17示出了本申请一个示例性实施例提供的一种终端的结构示意图；该终端是前述实施例提及的目标终端。请参见图17，该终端包括处理器1701、通信接口1702以及计算机可读存储介质1703。其中，处理器1701、通信接口1702以及计算机可读存储介质1703可通过总线或者其它方式连接。其中，通信接口1702用于接收和发送数据。计算机可读存储介质1703可以存储在终端的存储器中，计算机可读存储介质1703用于存储计算机程序，计算机程序包括程序指令，处理器1701用于执行计算机可读存储介质1703存储的程序指令。处理器1701(或称CPU(Central Processing Unit，中央处理器))是终端的计算核心以及控制核心，其适于实现一条或多条指令，具体适于加载并执行一条或多条指令从而实现相应方法流程或相应功能。

本申请实施例还提供了一种计算机可读存储介质(Memory)，计算机可读存储介质是终端中的记忆设备，用于存放程序和数据。可以理解的是，此处的计算机可读存储介质既可以包括终端中的内置存储介质，当然也可以包括终端所支持的扩展存储介质。计算机可读存储介质提供存储空间，该存储空间存储了终端的处理系统。并且，在该存储空间中还存放了适于被处理器1701加载并执行的一条或多条的指令，这些指令可以是一个或多个的计算机程序(包括程序代码)。需要说明的是，此处的计算机可读存储介质可以是高速RAM存储器，也可以是非不稳定的存储器(non-volatile memory)，例如至少一个磁盘存储器；可选的，还可以是至少一个位于远离前述处理器的计算机可读存储介质。

在一个实施例中，该计算机可读存储介质中存储有一条或多条指令；由处理器1701加载并执行计算机可读存储介质中存放的一条或多条指令，以实现上述应用嵌入方法实施例中的相应步骤。计算机可读存储介质中的一条或多条指令由处理器1701加载并执行如下步骤：

在检测到第一应用的第一应用页面中存在嵌入第二应用的操作后，确定用于承载第二应用的插件容器；

在插件容器中运行第二应用的脚本文件，以构建出第二应用的第二对象模型；并在插件容器中，将第一应用的第一对象模型共享给第二应用；第一对象模型包括第一应用的应用界面中的各功能组件所对应的组件变量的属性值；第二对象模型包括第二应用的应用界面中的各功能组件所对应的组件变量的属性值；

调用插件容器根据第二应用的第二对象模型，在第一应用页面中嵌入显示第二应用的第二应用页面；

在检测到第一应用页面中的任一功能组件，被用于更新第二应用页面中的显示元素时，调用插件容器根据第二应用所共享的第一对象模型更新显示第二应用页面。

在一种实现方式中，第二应用的脚本文件是通过第二应用的全局变量，构建第二应用的第二对象模型的；其中，全局变量位于第二应用的脚本文件中；

计算机可读存储介质中的一条或多条指令由处理器1701加载并还执行如下步骤：

对第二应用的脚本文件中的全局变量进行变量劫持，创建得到模型作用域。

在一种实现方式中，插件容器中包括模型作用域；计算机可读存储介质中的一条或多条指令由处理器1701加载并在执行在插件容器中，将第一应用的对象模型共享给第二应用时，具体执行如下步骤：

将第一应用的第一对象模型以及第二应用的第二对象模型，添加至模型作用域中；

根据约束关系在模型作用域中融合第一对象模型以及第二对象模型，以将第一对象模型共享给第二应用；其中，第一对象模型以及第二对象模型被融合成一个对象模型流。

在一种实现方式中，计算机可读存储介质中的一条或多条指令由处理器1701加载并还执行如下步骤：

通过插件容器中的沙箱，在插件容器中创建脚本作用域；

根据约束关系将第一应用的脚本文件以及第二应用的脚本文件，添加至脚本作用域，以将第一应用的脚本文件共享给第二应用；其中，任一脚本文件包括：相应应用的应用页面中的各功能组件对应的组件变量；

计算机可读存储介质中的一条或多条指令由处理器1701加载并在执行在插件容器中运行第二应用的脚本文件时，具体执行如下步骤：

在插件容器中的脚本作用域中运行第二应用的脚本文件。

在一种实现方式中，计算机可读存储介质中的一条或多条指令由处理器1701加载并在执行在检测到第一应用页面中的任一功能组件，被用于更新第二应用页面中的显示元素时，调用插件容器根据第二应用所共享的第一对象模型更新显示第二应用页面时，具体执行如下步骤：

在检测到第一应用页面中的任一功能组件被用于更新第二应用页面中的显示元素时，调用插件容器从第二应用所共享的第一应用的脚本文件中，获取任一功能组件所对应的组件变量作为目标变量；

调用插件容器从第二应用所共享的第一对象模型中，获取目标变量对应的属性值；

通过第二应用的脚本文件根据目标变量对应的属性值，更新第二应用的第二对象模型；并调用插件容器根据更新后的第二对象模型，更新显示第二应用页面。

在一种实现方式中，计算机可读存储介质中的一条或多条指令由处理器1701加载并还执行如下步骤：

获取第一应用的脚本文件对应的变量依赖关系，变量依赖关系指示：第一应用的脚本文件中的各个组件变量之间的调用关系；

将变量依赖关系挂载至脚本作用域中，以使在检测到第一应用页面中的任一功能组件被用于更新第二应用页面中的显示元素时，调用插件容器根据变量依赖关系，确定被任一功能组件对应的组件变量调用的其他组件变量，并将任一功能组件对应的组件变量和其他组件变量作为目标变量。

在一种实现方式中，第一应用关联有至少一个应用，至少一个应用中的各个应用均被允许嵌入至第一应用页面，且至少一个应用中的各个应用的网络地址存储在存储空间中；计算机可读存储介质中的一条或多条指令由处理器1701加载并还执行如下步骤：

在检测到第一应用的第一应用页面中存在嵌入第二应用的操作后，从存储空间中查找第二应用的网络地址；

在查找到第二应用的网络地址后，基于第二应用的网络地址获取第二应用的脚本文件。

在一种实现方式中，计算机可读存储介质中的一条或多条指令由处理器1701加载并还执行如下步骤：

在检测到第一应用的第一应用页面中存在嵌入第二应用的操作后，确定第二应用的尺寸数据，尺寸数据用于指示：第二应用的第二应用页面的界面尺寸；

根据尺寸数据在所述第一应用页面中绘制容器区域，容器区域用于显示第二应用的第二应用页面。

在一种实现方式中，计算机可读存储介质中的一条或多条指令由处理器1701加载并还执行如下步骤：

在第二应用处于激活状态的生命周期的过程中，激活第一业务逻辑，并根据激活的第一业务逻辑执行目标操作；第一业务逻辑包括：定时调用逻辑或回调逻辑，中的任一种或两种；

其中，当第一应用页面中的输入焦点位于第二应用页面中时，第二应用处于激活状态的生命周期。

在一种实现方式中，计算机可读存储介质中的一条或多条指令由处理器1701加载并还执行如下步骤：

在第二应用处于展开状态的生命周期的过程中，将插件容器的容器信息以及第二应用的应用信息进行缓存处理；

若检测到第二应用进入快照模式，则根据缓存的插件容器的容器信息以及第二应用的应用信息，重新调用插件容器加载第二应用的第二应用页面；

其中，插件容器的容器信息包括：尺寸数据以及坐标信息；第二应用的应用信息包括：第二应用的脚本文件以及第二对象模型。

在一种实现方式中，计算机可读存储介质中的一条或多条指令由处理器1701加载并还执行如下步骤：

在第二应用处于删除状态的生命周期的过程中，调用插件容器在脚本作用域中删除第二应用的脚本文件，以在第一应用的第一应用页面中隐藏第二应用的第二应用页面。

基于同一发明构思，本申请实施例中提供的区块链节点设备解决问题的原理与有益效果与本申请方法实施例中基于区块链网络的数据压缩方法、区块同步方法解决问题的原理和有益效果相似，可以参见方法的实施的原理和有益效果，为简洁描述，在这里不再赘述。

本申请实施例还提供一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。区块链节点设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该区块链节点设备执行上述基于区块链网络的数据压缩方法、区块同步方法。

本领域普通技术对象可以意识到，结合本申请中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术对象可以对每个特定的应用，使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行计算机程序指令时，全部或部分地产生按照本发明实施例所述的流程或功能。计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程设备。计算机指令可以存储在计算机可读存储介质中，或者通过计算机可读存储介质进行传输。计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如，同轴电缆、光纤、数字线(DSL))或无线(例如，红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据处理设备。可用介质可以是磁性介质(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如，固态硬盘(Solid State Disk，SSD))等。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术对象在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (15)

1.一种应用嵌入方法，其特征在于，包括：

在检测到第一应用的第一应用页面中存在嵌入第二应用的操作后，确定用于承载所述第二应用的插件容器；

在所述插件容器中运行所述第二应用的脚本文件，以构建出所述第二应用的第二对象模型；并在所述插件容器中，将所述第一应用的第一对象模型共享给所述第二应用；所述第一对象模型包括所述第一应用的应用界面中的各功能组件所对应的组件变量的属性值；所述第二对象模型包括所述第二应用的应用界面中的各功能组件所对应的组件变量的属性值；

调用所述插件容器根据所述第二应用的第二对象模型，在所述第一应用页面中嵌入显示所述第二应用的第二应用页面；

在检测到所述第一应用页面中的任一功能组件，被用于更新第二应用页面中的显示元素时，调用所述插件容器根据所述第二应用所共享的第一对象模型更新显示所述第二应用页面。

2.如权利要求1所述的方法，其特征在于，所述第二应用的脚本文件是通过所述第二应用的全局变量，构建所述第二应用的第二对象模型的；其中，所述全局变量位于所述第二应用的脚本文件中；

所述在所述插件容器中运行所述第二应用的脚本文件之前，还包括：

对所述第二应用的脚本文件中的全局变量进行变量劫持，创建得到模型作用域。

3.如权利要求2所述的方法，其特征在于，所述在所述插件容器中，将所述第一应用的对象模型共享给所述第二应用，包括：

将所述第一应用的第一对象模型以及所述第二应用的第二对象模型，添加至所述模型作用域中；

根据约束关系在所述模型作用域中融合所述第一对象模型以及所述第二对象模型，以将所述第一对象模型共享给所述第二应用；其中，所述第一对象模型以及所述第二对象模型被融合成一个对象模型流。

4.如权利要求1所述的方法，其特征在于，所述在所述插件容器中运行所述第二应用的脚本文件之前，还包括：

通过所述插件容器中的沙箱，在所述插件容器中创建脚本作用域；

根据约束关系将所述第一应用的脚本文件以及所述第二应用的脚本文件，添加至所述脚本作用域，以将所述第一应用的脚本文件共享给所述第二应用；其中，任一脚本文件包括：相应应用的应用页面中的各功能组件对应的组件变量；

所述在所述插件容器中运行所述第二应用的脚本文件，包括：

在所述插件容器中的脚本作用域中运行所述第二应用的脚本文件。

5.如权利要求4所述的方法，其特征在于，所述在检测到所述第一应用页面中的任一功能组件，被用于更新第二应用页面中的显示元素时，调用所述插件容器根据所述第二应用所共享的第一对象模型更新显示所述第二应用页面，包括：

在检测到所述第一应用页面中的任一功能组件被用于更新第二应用页面中的显示元素时，调用所述插件容器从所述第二应用所共享的第一应用的脚本文件中，获取所述任一功能组件所对应的组件变量作为目标变量；

调用所述插件容器从所述第二应用所共享的第一对象模型中，获取所述目标变量对应的属性值；

通过所述第二应用的脚本文件根据所述目标变量对应的属性值，更新所述第二应用的第二对象模型；并调用所述插件容器根据更新后的第二对象模型，更新显示所述第二应用页面。

6.如权利要求5所述的方法，其特征在于，所述方法还包括：

获取所述第一应用的脚本文件对应的变量依赖关系，所述变量依赖关系指示：所述第一应用的脚本文件中的各个组件变量之间的调用关系；

将所述变量依赖关系挂载至所述脚本作用域中，以使在检测到所述第一应用页面中的任一功能组件被用于更新第二应用页面中的显示元素时，调用所述插件容器根据所述变量依赖关系，确定被所述任一功能组件对应的组件变量调用的其他组件变量，并将所述任一功能组件对应的组件变量和所述其他组件变量作为目标变量。

7.如权利要求1-6任一项所述的方法，其特征在于，所述第一应用关联有至少一个应用，所述至少一个应用中的各个应用均被允许嵌入至所述第一应用页面，且所述至少一个应用中的各个应用的网络地址存储在存储空间中；所述方法还包括：

在检测到第一应用的第一应用页面中存在嵌入第二应用的操作后，从所述存储空间中查找所述第二应用的网络地址；

在查找到所述第二应用的网络地址后，基于所述第二应用的网络地址获取所述第二应用的脚本文件。

8.如权利要求1所述的方法，其特征在于，所述方法还包括：

在检测到第一应用的第一应用页面中存在嵌入第二应用的操作后，确定所述第二应用的尺寸数据，所述尺寸数据用于指示：所述第二应用的第二应用页面的界面尺寸；

根据所述尺寸数据在所述第一应用页面中绘制容器区域，所述容器区域用于显示所述第二应用的第二应用页面。

9.如权利要求1所述的方法，其特征在于，所述方法还包括：

在所述第二应用处于激活状态的生命周期的过程中，激活第一业务逻辑，并根据激活的所述第一业务逻辑执行目标操作；第一业务逻辑包括：定时调用逻辑或回调逻辑，中的任一种或两种；

其中，当所述第一应用页面中的输入焦点位于所述第二应用页面中时，所述第二应用处于所述激活状态的生命周期。

10.如权利要求1所述的方法，其特征在于，所述方法还包括：

在所述第二应用处于展开状态的生命周期的过程中，将所述插件容器的容器信息以及所述第二应用的应用信息进行缓存处理；

若检测到所述第二应用进入快照模式，则根据缓存的所述插件容器的容器信息以及所述第二应用的应用信息，重新调用所述插件容器加载所述第二应用的第二应用页面；

其中，所述插件容器的容器信息包括：尺寸数据以及坐标信息；所述第二应用的应用信息包括：所述第二应用的脚本文件以及第二对象模型。

11.如权利要求1所述的方法，其特征在于，所述方法还包括：

在所述第二应用处于删除状态的生命周期的过程中，调用所述插件容器在脚本作用域中删除所述第二应用的脚本文件，以在所述第一应用的第一应用页面中隐藏所述第二应用的第二应用页面。

12.一种应用嵌入装置，其特征在于，包括：

处理单元，用于在检测到第一应用的第一应用页面中存在嵌入第二应用的操作后，确定用于承载所述第二应用的插件容器；

所述处理单元，还用于在所述插件容器中运行所述第二应用的脚本文件，以构建出所述第二应用的第二对象模型；并在所述插件容器中，将所述第一应用的第一对象模型共享给所述第二应用；所述第一对象模型包括所述第一应用的应用界面中的各功能组件所对应的组件变量的属性值；所述第二对象模型包括所述第二应用的应用界面中的各功能组件所对应的组件变量的属性值；

调用单元，用于调用所述插件容器根据所述第二应用的第二对象模型，在所述第一应用页面中嵌入显示所述第二应用的第二应用页面；

所述调用单元，还用于在检测到所述第一应用页面中的任一功能组件，被用于更新第二应用页面中的显示元素时，调用所述插件容器根据所述第二应用所共享的第一对象模型更新显示所述第二应用页面。

13.一种终端，其特征在于，包括：

处理器，适于执行计算机程序；

计算机可读存储介质，所述计算机可读存储介质中存储有计算机程序，所述计算机程序被所述处理器执行时，实现如权利要求1-11任一项所述的应用嵌入方法。

14.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机程序，所述计算机程序适于被处理器加载并执行如权利要求1-11任一项所述的应用嵌入方法。

15.一种计算机程序产品，其特征在于，所述计算机程序产品包括计算机指令，所述计算机指令被处理器执行时实现如权利要求1-11任一项所述的应用嵌入方法。