CN114201237A - 应用程序运行方法、装置、电子设备及存储介质 - Google Patents

Abstract

本申请实施例公开一种应用使用管理方法及移动终端，该方法包括：下载待安装应用程序的安装包片段；通过虚拟增量文件系统为宿主应用程序调用已下载的目标安装包片段；以所述宿主应用程序为沙箱，利用所述宿主应用程序提供的系统资源运行所述目标安装包片段。实施本申请实施例，能够实现应用程序的免安装运行，达到边下载边使用的效果，缩短用户的等待时长。

Description

应用程序运行方法、装置、电子设备及存储介质

技术领域

本申请涉及互联网技术领域，具体涉及一种应用程序运行方法、装置、电子设备及存储介质。

背景技术

应用程序(Application)指为完成某项或多项特定工作的计算机程序。一般而言，应用程序在运行之前需要先安装。然而，在实践中发现，当应用程序的数据量较大时，应用程序的安装速度较慢，用户的等待时间过长。

发明内容

本申请实施例公开了一种应用程序运行方法、装置、电子设备及存储介质，能够实现应用程序的免安装运行，达到边下载边使用的效果，缩短用户的等待时长。

本申请实施例公开一种应用程序运行方法，所述方法包括：下载待安装应用程序的安装包片段；通过虚拟增量文件系统为宿主应用程序调用已下载的目标安装包片段；以所述宿主应用程序为沙箱，利用所述宿主应用程序提供的系统资源运行所述目标安装包片段。

本申请实施例公开一种应用程序运行装置，包括：下载模块，用于下载待安装应用程序的安装包片段；调用模块，用于通过虚拟增量文件系统为宿主应用程序调用已下载的目标安装包片段；运行模块，用于以所述宿主应用程序为沙箱，利用所述宿主应用程序提供的系统资源运行所述目标安装包片段。

本申请实施例公开一种电子设备，包括存储器及处理器，所述存储器中存储有计算机程序，所述计算机程序被所述处理器执行时，使得所述处理器实现本申请实施例公开的任意一种应用程序运行方法。

本申请实施例公开一种计算机可读存储介质，其存储计算机程序，其中，所述计算机程序被处理器执行时实现本申请实施例公开的任意一种应用程序运行方法。

与相关技术相比，本申请实施例具有以下有益效果：

虚拟增量文件系统支持文件的分段写入和读取，因此可以分段下载待安装应用程序的安装包片段，无需等待整个安装包片段的下载完成。并且，通过虚拟增量文件系统为宿主应用程序调用已下载的目标安装包片段，以将宿主应用程序作为沙箱，可以直接利用宿主应用程序提供的系统资源运行目标安装包片段，无需重复执行系统注册、请求资源分配等操作，从而实现应用程序的免安装运行。并且，安装包的分段下载和运行，达到了应用程序边下载边使用的效，可以缩短用户的等待时长。

附图说明

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

图1是一个实施例公开的一种应用程序运行方法的应用场景示例图；

图2是一个实施例公开的一种应用程序运行方法的方法流程示意图；

图3是另一个实施例公开的一种应用程序运行方法的方法流程示意图；

图4是一个实施例公开的一种在宿主应用程序中应用Trap Hook技术的示例图；

图5是一个实施例公开的另一种应用程序运行方法的示例图；

图6是一个实施例公开的一种应用程序运行装置的结构示意图；

图7是一个实施例公开的一种电子设备的结构示意图。

具体实施方式

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

需要说明的是，本申请实施例及附图中的术语“包括”和“具有”以及它们任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元，或可选地还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。

本申请实施例公开了本申请实施例公开了一种应用程序运行方法、装置、电子设备及存储介质，能够实现应用程序的免安装运行，达到边下载边使用的效果。以下分别进行详细说明。

请参阅图1，图1是一个实施例公开的一种应用程序运行方法的应用场景示例图。如图1所示，用户10可以通过电子设备20下载待安装应用程序。

电子设备20可以是智能手机、智能手表、平板电脑、个人电脑等，具体不做限定。电子设备的操作系统不做限定，可以是Linux操作系统、安卓(Android)操作系统等。

待安装应用程序可指未安装在电子设备20中的任意一种应用程序。电子设备可通过网页或者应用商店等获取待安装应用程序的下载链接。

当电子设备20检测到用户10输入的，用于指示对待安装应用程序进行下载的用户操作时，可以响应于该用户操作，执行本申请实施例公开的任意一种应用程序运行方法，以实现待安装应用程序的免安装运行。

请参阅图2，图2是一个实施例公开的一种应用程序运行方法的方法流程示意图。该方法可应用于前述的任意一种电子设备，如图2所示，该方法可包括以下步骤：

210、下载待安装应用程序的安装包片段。

待安装应用程序的安装包可被分为至少两个不同的安装包片段，电子设备可以下载安装包片段而非下载整个安装包，一方面可以节省安装包的下载时间，另一方面还可以在待安装应用程序的运行过程中持续下载其它当前未使用的安装包片段，进一步节省应用程序启动前所需的准备时间。

在一个实施例中，电子设备可以按顺序从服务设备中的下载待安装应用程序的各个安装包片段。前述的顺序可以是各个安装包片段分别对应的预测使用顺序。待安装应用程序中的资源往往存在一定的访问顺序。例如，登录页面往往是最先被访问的。因此，各个安装包片段分别对应的预测使用顺序可指在实际运行时，各个安装包片段包括的资源被访问的顺序。按照预测使用顺序下载安装包片段，可以提高安装包片段的命中率。

可选的，待安装应用程序的各个安装包片段可包括：必要安装包片段和非必要安装包片段。其中，必要安装包片段可指对应用程序的运行而言必不可少的安装包片段，非必要安装包片段可指对应用程序的运行而言可选择性忽略的安装包片段。例如，与应用程序的启动相关的安装包片段属于必要安装包片段，与应用程序中某个场景的场景渲染相关的安装包片段可属于非必要安装包片段。鉴于必要安装包片段的重要性，必要安装包片段对应的预测使用顺序，可先于非必要安装包对应的预测使用顺序。即，电子设备可先从服务设备中下载必要安装包片段，再必要安装包片段下载完毕之后，再继续下载非必要安装包片段。

在一个实施例中，各个安装包片段分别对应的预测使用顺序可以是开发人员基于人工经验预先设置的。

在另一个实施例中，各个安装包片段分别对应的预测使用顺序也可以通过非人工的方式获取，具体可以是从样本数据中统计得出的。样本数据可以是从多个不同的电子设备中收集的，可以包括待安装应用程序的各个安装包片段在其它电子设备中分别对应的历史使用顺序。

示例性的，待安装应用程序未在设备A中安装，但已在设备B中安装并运行。可以采集设备B运行待安装应用程序时，各个安装包片段包括的资源被访问的顺序作为各个安装包片段分别对应的历史使用顺序。

电子设备可暂存已下载的安装包片段，以等待对已下载安装包片段的调用。

220、通过虚拟增量文件系统为宿主应用程序调用已下载的目标安装包片段。

虚拟增量文件系统可指在操作系统的应用层实现的文件管理系统，宿主应用程序可指当前已安装的任意一个应用程序。宿主应用程序与虚拟增量文件系统均处于应用层，可基于流式传输方式进行数据传输。虚拟增量文件系统可以是操作系统提供的原生文件系统与应用程序之间的一个虚拟文件管理系统，支持文件的分段写入和分段读取。

在一个实施例中，若操作系统为安卓系统，则虚拟增量文件系统可通过安卓系统的增量文件系统(IncFS)实现。增量文件系统是基于Linux虚拟文件系统衍生出的一种文件系统实现，该系统支持将文件切割成小片，支持文件的分段写入和分段读取。并且，还能够使得安卓操作系统通过安卓调试桥接收流式传输的安卓安装包(Android ApplicationPackage，APK)。

也就是说，待安装应用程序的安装包片段无需在操作系统的内核中解压，而是可以通过虚拟增量文件系统将安装包片段调用至电子设备已安装的宿主应用程序中。

230、以宿主应用程序为沙箱，利用宿主应用程序提供的系统资源运行目标安装包片段。

沙箱(SandBox)可指一个独立作业环境。在本申请实施例中，不同的应用程序都可以在自己的进程中运行，都拥有一个独立的虚拟机实例。因此，宿主应用程序的进程可以看作是一个沙箱环境，可以安全地将在该进程中运行的代码与操作系统的其余进程隔离开来。

此外，宿主应用程序作为已安装的应用程序，已完成在操作系统中的注册，并且也对应有操作系统分配的硬盘资源等。在步骤230中，宿主应用程序提供的系统资源可包括前述的操作系统注册凭据、硬盘资源分配结果等，但不限于此。

步骤220中由虚拟增量文件系统调用的目标安装包片段可以在宿主应用程序的进程中运行，并且目标安装包片段在运行之前可以无需再次进行系统注册和请求资源分配等操作，而是可以直接利用宿主应用程序提供的注册凭据、硬盘资源等系统资源，从而实现免安装运行。并且，由于虚拟增量文件系统支持文件的分段写入和分段读取，使得待安装应用程序的安装包可以通过分段的形式持续传输至宿主应用程序提供的沙箱环境中运行，无需完整下载整个安装包之后再运行，从而达到边下载边使用的效果。

对于数据量较大的应用程序，如大部分高画质的游戏应用而言，基于本申请实施例公开的应用程序运行方法，能够缩短用户在使用应用程序之前的等待时长，极大地改善了用户体验。

请参阅图3，图3是另一个实施例公开的一种应用程序运行方法的方法流程示意图。该方法可应用于前述的任意一种电子设备，如图3所示，该方法可包括以下步骤：

310、下载待安装应用程序的安装包片段。

步骤310的实施方式可参见前述步骤210的实施方式，以下内容不再赘述。

320、截获宿主应用程序的运行进程中产生的文件请求，将文件请求传递给虚拟增量文件系统。

在宿主应用程序的运行进程中，可能会产生一次或多次文件请求，这可能是宿主应用程序原本的代码产生的；或者，也可能是待安装应用程序产生的。

可以理解的是，宿主应用程序原本的代码产生的文件请求原本的请求对象，可能并非为虚拟增量文件系统。这是由于宿主应用程序本身可能并非通过本申请实施例公开的应用程序运行方法启动运行的，宿主应用程序可能遵循传统的应用程序运行方法，先下载整个安装包，并在对安装包的安装完成之后再运行。因此，宿主应用程序本身的文件请求对象不包括虚拟增量文件系统，而是指向其它地址。

此外，由于待安装应用程序的安装包片段是分段加载至宿主应用程序中的，因此在某个安装包片段的运行过程中，也可能产生针对下一个安装包片段的文件请求。因此，在宿主应用程序的运行中产生的文件请求可以是宿主应用程序原本的代码产生的，也可以是由待安装应用程序产生的。

示例性的，可以截获宿主应用程序原本的代码产生的文件请求，以基于该文件请求通过虚拟增量文件系统调用待安装应用程序的第一个已下载的安装包片段；在基于下述的步骤330运行第一个安装包片段时，可以截获第一个安装包片段运行时长生的文件请求，并基于该文件请求通过虚拟增量文件系统调用待安装应用程序的下一个已下载的安装包片段。

在本申请实施例中，可通过在宿主应用序注入的钩子(Hook)截获宿主应用程序的文件请求，使得该文件请求转向虚拟增量文件系统，而非原本的地址，从而实现通过虚拟增量文件系统为宿主应用程序调用目标安装包片段的功能。

在一个实施例中，可通过操作系统的原生钩子(Native Hook)技术截获宿主应用程序的文件请求。以安卓系统为例，Native Hook可包括GOT/PLT Hook、陷阱钩子(TrapHook)、内联钩子(Inline Hook)等，具体不做限定。

可选的，可通过Trap Hook技术截获宿主应用程序的文件请求。Trap Hook也被称为断点Hook，其原理是在需要Hook的地方想办法触发断电，并捕获异常。也就是说，在执行前述步骤320时，可以通过在宿主应用程序的目标地址中插入的陷阱(Trap)指令，截获宿主应用程序的运行进程中产生的文件请求。

在通过Trap Hook技术截获文件请求时，可以利用SIGTRAP或者SIGKILL这两种信号。以下内容以SIGTRAP信号为例，对如果通过Trap Hook截取文件请求的过程进行说明。

示例性的，请参阅图4，图4是一个实施例公开的一种在宿主应用程序中应用TrapHook技术的示例图。如图4所示：首先，需要执行如下准备工作：注册SIGTRAP信号的信号接收句柄(Signal Handler)，并在宿主应用程序需要触发断点的目标地址中写入Trap指令。其中，图4所示的函数A(Func A)、函数B(Func B)和函数C(Func C)是宿主应用程序本身的函数，需要触发断电的目标地址为调用函数A之前。

当操作系统调用Trap指令时，进入内核模式，并调用此前已注册好的信号接收句柄。执行该信号接收句柄，调用钩子处理程序(Call Hook Handler)，执行Hook函数对应的代码。在本申请实施例中，Hook函数对应的代码，可以包括将文件请求传递给虚拟增量文件系统、接收虚拟增量文件系统返回的目标安装包片段，以及运行目标安装包片段。

需要注意的是，在使用Trap Hook时，所有在信号接收句柄执行的代码需要保证异步信号安全(Async-Signal-Safe)。为了避免该限制，可以简单地将信号接收句柄作为蹦床，使用logjmp操作跳出需要异步信号安全的环境，然后再执行Hook函数对应的代码，以减少由于严格的异步信号安全限制而导致的目标安装包片段运行中断，有利于提高应用程序免安装运行的成功率。

在执行完Hook函数之后，需要恢复现场。如图4所示，若需要继续调用宿主应用程序原来的函数A，则可以直接回写函数A的原始指令并恢复寄存器状态。

需要说明的是，前述在宿主应用程序中应用Trap Hook技术是截获宿主应用程序产生的文件请求的一种示例性方式，不应构成限定。

330、由虚拟增量文件系统响应文件请求，读取已下载的目标安装包片段，并将目标安装包片段返回给宿主应用程序。

在前述步骤320中，宿主应用程序的文件请求传递给了虚拟增量文件系统，因此由虚拟增量文件系统响应该文件请求，读取已下载的目标安装包片段，并将目标安装包片段返回至宿主应用程序。其中，将目标安装包片段返回至宿主应用程序，可指将目标安装包片段返回至宿主应用程序提供的沙箱环境中。

在一个实施例中，前述步骤310下载到的安装包片段可以存储在操作系统的原生文件系统中。因此，执行步骤330可包括：由虚拟增量文件系统响应文件请求，从原生文件系统存储的多个安装包片段中获取已下载的目标安装包片段。

可选的，可按照各个安装包片段对应的预测使用顺序从原生文件系统存储的多个安装包片段中获取已下载的目标安装包片段，使得安装包片段的运行也可与预测使用顺序对应，有利于提高应用程序免安装运行的成功率。

340、以宿主应用程序为沙箱，利用宿主应用程序提供的系统资源运行目标安装包片段。

如前述实施例所示，宿主应用程序提供必要的系统注册凭证以及硬盘资源等系统资源，使得目标安装包片段在沙箱环境中运行时可以免除再次注册等操作，实现免安装运行。并且，虚拟增量文件系统支持安装包的分段写入和读取，从而实现应用程序的边下载边使用。

为了更清楚地说明本申请实施例公开的应用程序运行方法。请参阅图5，图5是一个实施例公开的另一种应用程序运行方法的示例图。如图5所示，电子设备可获取预测结果510，预测结果510可包括待安装应用程序的各个安装包片段分别对应的预测使用顺序。基于预测结果510可生成各个安装包片段分别对应的下载任务520。

基于各个安装包分别对应的下载任务520，可从内容分发网络530(ContentDelivery Network，CDN)中下载安装包片段，得到待安装应用程序的多个安装包片段540。其中，内容分发网络530是一种构建在现有网络基础之上的智能虚拟网络，依靠部署在各地的边缘服务器，通过中心平台的负载均衡、内容分发、调度等功能模块，使得电子设备可以就近下载到安装包片段。

下载得到的各个安装包片段540可写入操作系统的原生文件系统550中，以存储安装包片段540。此外，原生文件系统550可主动将存储的安装包片段540写入至虚拟增量文件系统560中；或者，原生文件系统550也可响应虚拟增量文件系统560的读取请求，将存储的安装包片段540返回至虚拟增量文件系统560中。

因此，虚拟增量文件系统560可以获取到原生文件系统存储的安装包片段。当虚拟增量文件系统560接收到待安装应用程序在宿主应用程序570的运行进程中产生的文件请求时，可以响应该文件请求，读取出已下载的目标安装包片段，并将目标安装包片段返回至宿主应用程序570。

需要说明的是，除了内容分发网络530以外，前述的预测结果510、下载任务520、原生文件系统550以及虚拟增量文件系统560均是由电子设备处理的数据，或者是处于电子设备中的模块。

可见，在前述的实施例中，宿主应用程序提供的沙箱环境负责处理待安装应用程序的安装包片段加载，在宿主应用程序的运行进程中产生的文件请求被hook到虚拟增量文件系统。对于安装包片段的使用方而言，感知不到底层是虚拟增量文件系统，可以实现应用程序的边下载边使用。

请参阅图6，图6是一个实施例公开的一种应用程序运行装置的结构示意图。该装置可应用于前述的任意一种电子设备，如图6所示，应用程序运行装置600可包括：下载模块610、调用模块620、运行模块630。

下载模块610，用于下载待安装应用程序的安装包片段；

调用模块620，用于通过虚拟增量文件系统为宿主应用程序调用已下载的目标安装包片段；

运行模块630，用于以宿主应用程序为沙箱，利用宿主应用程序提供的系统资源运行目标安装包片段。

在一个实施例中，下载模块610，还可用于根据待安装应用程序的各个安装包片段分别对应的预测使用顺序，从服务设备中下载安装包片段。

在一个实施例中，预测使用顺序是从样本数据中统计得出的，样本数据包括各个安装包片段的历史使用顺序。

在一个实施例中，待安装应用程序的各个安装包片段包括：必要安装包片段和非必要安装包片段；必要安装包片段对应的预测使用顺序，先于非必要安装包片段对应的预测使用顺序。

在一个实施例中，调用模块620，可包括：截获单元和获取单元。

截获单元，用于截获宿主应用程序的运行进程中产生的文件请求，将文件请求传递给虚拟增量文件系统；

获取单元，用于由虚拟增量文件系统响应文件请求，读取已下载的目标安装包片段，并将目标安装包片段返回给宿主应用程序。

在一个实施例中，应用程序运行装置600还可包括：写入模块。

写入模块，用于将已下载的安装包片段写入操作系统的原生文件系统；

获取单元，还用于由虚拟增量文件系统响应文件请求，从原生文件系统存储的多个安装包片段中获取已下载的目标安装包片段。

可选的，获取单元，还可用于按通过在宿主应用程序的目标地址中插入的陷阱指令，截获宿主应用程序的运行进程中产生的文件请求。

在一个实施例中，截获单元，还用于通过在宿主应用程序的目标地址中插入的陷阱指令，截获宿主应用程序的文件请求。

实施前述实施例公开的应用程序运行装置，由虚拟增量文件系统调用的目标安装包片段可以在宿主应用程序的进程中运行，并且目标安装包片段在运行之前可以无需再次进行注册和硬盘资源分配等操作，而是可以直接利用宿主应用程序提供的注册凭据、硬盘资源等系统资源，从而实现免安装运行。并且，由于虚拟增量文件系统支持文件的分段写入和分段读取，使得待安装应用程序的安装包可以通过分段的形式持续传输至宿主应用程序提供的沙箱环境中运行，无需完整下载整个安装包之后再运行，从而达到边下载边使用的效果，缩短用户的等待时长。

请参阅图7，图7是一个实施例公开的一种电子设备的结构示意图。如图7所示，该电子设备700可以包括：

存储有可执行程序代码的存储器710；

与存储器710耦合的处理器720；

其中，处理器720调用存储器710中存储的可执行程序代码，执行本申请实施例公开的任意一种应用程序运行方法。

需要说明的是，图7所示的电子设备还可以包括电源、输入按键、摄像头、扬声器、屏幕、RF电路、Wi-Fi模块、蓝牙模块、传感器等未显示的组件，本实施例不作赘述。

本申请实施例公开一种计算机可读存储介质，其存储计算机程序，其中，该计算机程序使得计算机执行本申请实施例公开的任意一种应用程序运行方法。

本申请实施例公开一种计算机程序产品，该计算机程序产品包括存储了计算机程序的非瞬时性计算机可读存储介质，且该计算机程序可操作来使计算机执行本申请实施例公开的任意一种应用程序运行方法。

应理解，说明书通篇中提到的“一个实施例”或“一实施例”意味着与实施例有关的特定特征、结构或特性包括在本申请的至少一个实施例中。因此，在整个说明书各处出现的“在一个实施例中”或“在一实施例中”未必一定指相同的实施例。此外，这些特定特征、结构或特性可以以任意适合的方式结合在一个或多个实施例中。本领域技术人员也应该知悉，说明书中所描述的实施例均属于可选实施例，所涉及的动作和模块并不一定是本申请所必须的。

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

上述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物单元，即可位于一个地方，或者也可以分布到多个网络单元上。可根据实际的需要选择其中的部分或全部单元来实现本实施例方案的目的。

另外，在本申请各实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

上述集成的单元若以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可获取的存储器中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或者部分，可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储器中，包括若干请求用以使得一台计算机设备(可以为个人计算机、服务器或者网络设备等，具体可以是计算机设备中的处理器)执行本申请的各个实施例上述方法的部分或全部步骤。

本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序可以存储于一计算机可读存储介质中，存储介质包括只读存储器(Read-Only Memory，ROM)、随机存储器(Random Access Memory，RAM)、可编程只读存储器(Programmable Read-only Memory，PROM)、可擦除可编程只读存储器(Erasable Programmable Read Only Memory，EPROM)、一次可编程只读存储器(One-time Programmable Read-Only Memory，OTPROM)、电子抹除式可复写只读存储器(Electrically-Erasable Programmable Read-Only Memory，EEPROM)、只读光盘(CompactDisc Read-Only Memory，CD-ROM)或其他光盘存储器、磁盘存储器、磁带存储器、或者能够用于携带或存储数据的计算机可读的任何其他介质。

以上对本申请实施例公开的一种应用程序运行方法、装置、电子设备及存储介质进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想。同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims (10)

1.一种应用程序运行方法，其特征在于，所述方法包括：

下载待安装应用程序的安装包片段；

通过虚拟增量文件系统为宿主应用程序调用已下载的目标安装包片段；

以所述宿主应用程序为沙箱，利用所述宿主应用程序提供的系统资源运行所述目标安装包片段。

2.根据权利要求1所述的方法，其特征在于，所述下载待安装应用程序的安装包片段，包括：

根据待安装应用程序的各个安装包片段分别对应的预测使用顺序，从服务设备中下载安装包片段。

3.根据权利要求2所述的方法，其特征在于，所述预测使用顺序是从样本数据中统计得出的，所述样本数据包括所述各个安装包片段的历史使用顺序。

4.根据权利要求2所述的方法，其特征在于，所述待安装应用程序的各个安装包片段包括：必要安装包片段和非必要安装包片段；所述必要安装包片段对应的预测使用顺序，先于所述非必要安装包片段对应的预测使用顺序。

5.根据权利要求1-4任一项所述的方法，其特征在于，所述通过虚拟增量文件系统为所述宿主应用程序调用已下载的目标安装包片段，包括：

截获所述宿主应用程序的运行进程中产生的文件请求，将所述文件请求传递给所述虚拟增量文件系统；

由所述虚拟增量文件系统响应所述文件请求，读取已下载的目标安装包片段，并将所述目标安装包片段返回给宿主应用程序。

6.根据权利要求5所述的方法，其特征在于，在所述下载待安装应用程序的安装包片段之后，所述方法还包括：

将已下载的安装包片段写入操作系统的原生文件系统；

所述由所述虚拟增量文件系统响应所述文件请求，读取已下载的目标安装包片段，包括：

由所述虚拟增量文件系统响应所述文件请求，从所述原生文件系统存储的多个安装包片段中获取已下载的目标安装包片段。

7.根据权利要求5所述的方法，其特征在于，所述截获所述宿主应用程序的运行进程中产生的文件请求，包括：

通过在所述宿主应用程序的目标地址中插入的陷阱指令，截获所述宿主应用程序的运行进程中产生的文件请求。

8.一种应用程序运行装置，其特征在于，包括：

下载模块，用于下载待安装应用程序的安装包片段；

调用模块，用于通过虚拟增量文件系统为宿主应用程序调用已下载的目标安装包片段；

运行模块，用于以所述宿主应用程序为沙箱，利用所述宿主应用程序提供的系统资源运行所述目标安装包片段。

9.一种电子设备，其特征在于，包括存储器及处理器，所述存储器中存储有计算机程序，所述计算机程序被所述处理器执行时，使得所述处理器实现如权利要求1至7任一项所述的方法。

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至7任一项所述的方法。

Images