CN111049870B - 应用下载和发送的方法、装置及系统 - Google Patents

Abstract

本申请提供一种应用下载方法、装置及系统，尤其针对下载即启动的应用。该方法包括：服务器从大量已经下载并使用该应用的终端中获取该应用的运行信息，并对这些信息执行数据分析，根据数据分析的结果确定应用文件的排序，访问概率高的排在前，访问概率低的排在后，然后按照这个排序向终端设备传输应用文件。由于访问概率高的应用文件先发送，所以终端启动应用和运行应用的速度将会提高，相应的用户体验将会得到提升。

Description

应用下载和发送的方法、装置及系统

技术领域

本申请涉及计算机技术领域，尤其涉及一种应用下载和发送的方法、装置及系统等。

背景技术

目前在智能手机上兴起一种新的应用形态—小程序，包括不限于微信小程序、支付宝小程序、以及快应用等。小程序与传统手机应用相比最大的差异点在于，小程序无需从应用市场或应用供应商处下载安装，而是通过推荐、搜索、分享等方式直达用户，即点即用。小程序在用户打开使用的瞬间就要完成下载、安装与启动整个过程(下载后立即启动)。但是由于小程序的文件包(包含多个文件)比较大(从几兆到几百兆)，以及网络传输过程中的重定向、建立链接、传输消耗、丢包等导致的延时，使得用户打开小程序的体验极差，会有几秒甚至几十秒的等待。

在应用下载后立即启动的过程中，如何做到启动速度满足用户体验，是当前面临的一大技术难题。该技术难题不局限于小程序的应用场景，可以延伸到任何在下载后需要立即启动的应用，比如即点即用的小程序、即点即玩的游戏、游戏场景中的资源包的实时加载、以及AI模型文件的加载等。

解决这一技术难题现有的技术手段主要有分包和预下载两种。

以小程序为例，开发者将小程序的多个文件划分成不同的分组，在构建文件包时将这些分组打包成不同的分包，用户在使用时按需进行加载。以微信小程序的分包方案为例，在构建小程序分包项目时，输出一个或多个功能的分包，其中必定包含一个主包，所谓的主包，即放置默认启动页面/TabBar页面以及一些所有分包都需用到公共资源/JS脚本等。分包通常是根据开发者的配置进行划分。在小程序启动时，默认会下载主包并启动主包内页面，如果用户需要打开分包内某个功能(或页面)，客户端会再把对应的分包下载下来，下载完成后再进行展示。由于主包相比于整个文件包较小，所以下载延时更小，对用户来说，程序的启动速度更快，所以用户体验更好。但是分包方案仍然存在如下不足：对于可能会被多个子包使用的公共资源，需要全部放到主包当中，而公共资源并非都是首次启动所需资源，如果公共资源过多，会导致主包过大，首次启动时间过长。

文件包的预下载是对要访问的文件包进行预先下载并缓存在端侧设备中，当用户打开相应的程序时，直接从缓存中加载文件包并启动执行，省去文件包下载的延时。但是文件包的预下载也存在如下不足：预下载需要在启动小程序的前一个使用场景下(某个应用的某个页面或某种执行状态)发生，不是所有场景都支持只习惯该与预下载。例如，由第三方开发的软件启动小程序，无法强制要求该第三方软件预先执行下载逻辑。预下载存在误判的情况，当缓存的小程序包用户没有真正使用时，相应的下载流量与存储空间即被浪费。

发明内容

本申请提供一种应用下载和发送的方法、装置及系统，以用于提高应用启动和运行的效率，从而提升用户体验。

以下从多个方面介绍本申请，容易理解的是，该以下多个方面的实现方式和有效效果可互相参考。

第一方面，本申请提供一种应用下载方法，由终端设备执行，包括：采集应用的运行信息并向服务器发送所述运行信息，所述运行信息与所述应用中的多个应用文件的访问相关，例如包括以下信息中的一种或两种：多个应用文件各自的访问次数，所述多个应用文件的访问顺序；接收所述服务器按照传输排序发送的所述多个应用文件，所述传输排序为所述服务器根据所述运行信息确定的顺序。

这种下载方法通常是流式下载，即服务器通过一条网络提供连续的、实时的应用文件下载，终端设备无需等到应用文件全部下载完成即可启动应用。既然终端设备在未完成全部文件的下载之前就可以使用文件，那么如何保证文件下载顺序贴近用户需求，即尽快下载下来用户下一步所需的文件就至关重要。本申请通过对应用文件的访问次数等信息进行分析处理，能够获得更加贴近于用户使用习惯的应用文件顺序，结合流式下载的方法，提高了应用的启动和运行效率，从而提升了用户体验。

在一些实现方式中，所述多个应用文件具有初始排序，所述初始排序是通过文件之间的引用关系确定的，所述文件之间的引用关系是通过静态扫描所述多个应用文件以及预执行所述多个应用文件所生成的。在另一些实现方式中，所述文件之间的引用关系是仅通过静态扫描所述多个应用文件所生成的，或者所述文件之间的引用关系是仅通过预执行所述多个应用文件所生成的。

多个应用文件在服务器上部署的时候存在一个初始排序，该初始排序是通过静态扫描所述多个应用文件以及预执行所述多个应用文件所生成的，该初始排序可以由开发者在个人计算机上完成，也可以由开发者通过服务器提供的能力完成，即服务器可以实现对多个应用文件的扫描以及预执行。

通过初始排序能够获知应用文件之间的引用关系，该后续的排序提供依据。单独通过静态扫描的方式有可能有些文件之间的引用关系获取不到，结合预执行的方式能够更加全面的获得应用文件之间的引用关系。

在一些实现方式中，在执行所述接收步骤之前，所述终端设备向所述服务器发送个性化用户信息，所述个性化用户信息包括以下信息中的一种或多种：所述终端设备的当前位置、所述终端设备的用户的标识和特定文件的标识；并且所述传输排序是所述服务器根据所述运行信息以及所述个性化的用户信息确定的。

除了应用的运行信息之外，传输排序的确定还可以参考终端设备的个性化信息，例如终端设备的位置信息，例如家或公司，不同位置下，即便是同一用户，对同一应用的使用习惯也可能是不同的，即对应用文件的访问顺序和/或访问次数不一样；或者终端设备有多个用户，而这多个用户对同一应用的使用习惯是不同的，因此，利用个性化用户信息对应用文件排序进行一定程度的区分处理，例如位置A对应排序A，位置B对应排序B，这样可以使应用文件的排序更具备针对性，进一步提高应用文件的排序精准度。

在一些实现方式中，在接收所述服务器按照传输排序发送的所述多个应用文件的过程中，所述方法还包括：向所述服务器发送文件请求，所述文件请求用于请求下载所述服务器还未发送的请求文件；接收所述服务器实时发送的所述请求文件。

在接收应用文件的过程中，因为文件排序事先已经确定，可能存在临时请求一个还未下载的文件的情况，若存在这种情况，终端设备向服务器发送用于请求该文件的请求，服务器实时将该文件发送给终端设备。

以上这种情况发生时，可以直接调整文件排序，将该文件的发送优先级提高到当时的最高优先级；也可以不对应用文件的排序进行调整(仅是该次提前发送该文件)。在另一些实现方式中，服务器收集前述文件请求，并对这些文件请求进行分析，在满足一定的条件时才调整文件的排序。也就是说，偶尔的不符合原顺序的文件请求不足以影响全局的排序，若采集到这样的文件请求很多，则触发对全局排序的调整。

第二方面，本申请还提供一种应用发送方法，由服务器执行，包括：获取应用的运行信息，所述应用为在终端设备上正在运行或运行过的应用，所述运行信息包括以下信息中的一种或两种：多个应用文件各自的访问次数，所述多个应用文件的访问顺序；根据所述运行信息确定传输排序；按照所述传输排序向终端设备传输所述多个应用文件。

通过在服务器获取应用的运行信息，并根据应用的运行信息确定应用文件的排序，能够使得应用文件的排序更加贴近用户的使用习惯，将排序好的应用文件一一发送给终端设备，可以尽可能地避免或减小用户等待时间，提高应用的启动及运行效率，提升用户体验。

在一些实现方式下，所述多个应用文件具有初始排序，所述初始排序是通过文件之间的引用关系确定的，所述文件之间的引用关系是通过静态扫描所述多个应用文件以及预执行所述多个应用文件所生成的。初始排序的确定可以是由服务器执行的，也可以是由开发者在自己的开发侧计算机上执行的。

在一些实现方式下，所述确定所述传输排序包括：分析所述应用文件的访问概率和依赖关系中的一种或两种；根据所述访问概率和/或依赖关系确定所述传输排序。具体的，可通过大数据统计的方式分析出各个应用件的访问概率和依赖关系。

访问概率体现了应用文件被使用的可能性。依赖关系体现了应用文件之间的引用关系，或者虽然没有明示的引用关系，但是在运行的过程中，多个应用文件之间存在的依赖关系。

在一些实现方式下，在还未完成所述多个应用文件的传输之前，该方法还包括：接收所述终端设备发送的文件请求，所述文件请求用于请求下载按照所述传输排序还未开始传输的请求文件；根据所述文件请求实时传输所述请求文件。

在一些实现方式下，该方法还包括：若接收到的所述文件请求的数量超过预设阈值，则调整所述传输排序，以提高所述请求文件的传输优先级。换句话说，若在应用文件传输的过程中，收到较多对某个应用文件的实时请求(该文件还没有传输完成)，说明该应用文件的传输滞后于用户的使用，所以需要提升该文件的传输优先级，具体的，可以按照预设值提升该应用文件在所有应用文件中的排序位，也可以按照前述预设阈值提升该应用文件在所有应用文件中的排序位数。

在另一些实现方式下，当收到这样的文件请求时，就实时调整所有应用文件的排序以提升该文件请求所请求的那个应用文件的排序位。

在一些实现方式下，该方法还包括：获取所述应用的个性化用户信息，所述个性化用户信息包括以下信息中的一种或多种：终端设备的位置、所述终端设备的用户的标识和特定文件的标识；所述确定所述传输排序包括：根据所述个性化用户信息和所述运行信息确定所述传输排序。

在一些实现方式下，所述根据所述个性化用户信息和所述运行信息确定所述传输排序包括：计算与所述终端设备的不同位置分别对应的所述应用文件的访问概率和/或依赖关系，确定与所述终端设备的不同位置分别对应的多种传输排序。所述向终端设备传输所述多个应用文件包括：获取所述终端设备的当前位置，并按照与所述当前位置对应的传输排序向所述终端设备传输所述应用文件。

个性化用户信息用来区分不同终端设备或不同的用户，或用来区分同一终端设备或用户的不同状态等，这些可能会影响应用文件的使用。例如，同一用户在位于不同地方时对同一应用的使用习惯会不一样。因此，在对应用文件进行排序的时候，结合这些信息可以使得应用文件的排序更有针对性，传输应用文件的时候也要根据当前的个性化用户信息选择对应的排序，按照该排序传输应用文件，这样更贴合当前使用场景或使用用户的使用习惯，有针对性的提高用户体验。

在一些实现方式下，“调整”排序是更改所有文件的存储顺序，就是存储介质上的文件的顺序被更改了。在另一些实现方式下，文件的传输排序可以认为是服务器传输模块接收到的传输指令，按照传输指令中指令的排序以此传输文件，因此“调整”排序仅是修改了给传输模块的指令，使其能够按照新的排序传输文件。

第三方面，本申请还提供一种应用下载装置，包含多个功能单元，用以实现前述第一方面或第一方面的任意一种实现方式。功能单元可以根据实际需求进行划分，本申请对此不做限定。

第四方面，本申请还提供一种应用发送装置，包含多个功能单元，用以实现前述第二方面或第二方面的任意一种实现方式。功能单元可以根据实际需求进行划分，本申请对此不做限定。

第五方面，本申请还提供一种终端设备，包括处理器、接收器、发送器和存储器，所述存储器用于存储计算机可读指令；所述处理器用于读取所述计算机可读指令执行前述第一方面或第一方面的任意一种实现方式的部分或全部步骤；所述接收器用于从该终端设备的外部(例如服务器)接收数据(例如应用文件)；所述发送器用于向外部发送数据(例如运行信息、应用启动请求、个性化用户信息、文件请求等)。

第六方面，本申请还提供一种服务器，包括处理器、接收器、发送器和存储器，所述存储器用于存储计算机可读指令；所述处理器用于读取所述计算机可读指令执行前述第二方面或第二方面的任意一种实现方式的部分或全部步骤；所述接收器用于从该服务器的外部(例如其他服务器或终端设备)接收数据(例如运行信息、应用启动请求、个性化用户信息、文件请求等)；所述发送器用于向外部发送数据(例如应用文件)。

需要说明的是，前述方面中提到的接收或发送(或传输)步骤是软件模块和硬件的发送器或接收器配合实现的，本申请对硬件部分无实质改进，因此在描述本申请的部分实施例时将对应的软件模块描绘了出来。软件模块由处理器执行，执行后对硬件的接收器或发送器发送指令，以使得接收器或发送器按照软件模块的指示完成接收或发送功能。

第七方面，本申请提供计算机程序产品(或称计算机程序)，包含程序指令，该程序指令在被一个或多个处理器执行时实现前述第一方面或第一方面的任意一种实现方式的部分或全部步骤。

第八方面，本申请提供计算机程序产品(或称计算机程序)，包含程序指令，该程序指令在被一个或多个处理器执行时实现前述第二方面或第二方面的任意一种实现方式的部分或全部步骤。

第九方面，本申请提供一种计算机存储介质，包含程序指令，该程序指令在被一个或多个处理器执行时实现前述第二方面或第二方面的任意一种实现方式的部分或全部步骤。

第十方面，本申请提供一种计算机存储介质，包含程序指令，该程序指令在被一个或多个处理器执行时实现前述第一方面或第一方面的任意一种实现方式的部分或全部步骤。

第十一方面，本申请提供一种应用传输系统，包括服务器和终端设备。所述终端设备接收应用的多个应用文件，启动并运行该应用；将应用的运行信息发送给所述服务器，所述运行信息包括以下信息中的一种或两种：多个应用文件各自的访问次数，所述多个应用文件的访问顺序。所述服务器用于接收所述运行信息，根据所述运行信息确定传输排序，并按照所述传输排序向所述终端设备传输所述多个应用文件，以便于所述终端设备再一次启动并运行所述应用。

附图说明

为了更清楚地说明本申请提供的技术方案，下面将对附图作简单地介绍。显而易见地，下面描述的附图仅仅是本申请的一些实施例。

图1为本实施例应用的网络架构示意图；

图2为本实施例提供的方案的部署示意图；

图3为本实施例提供的方案的运作流程示意图；

图4为本实施例提供的方案的方法流程示意图；

图5为本实施例提供的方案的方法流程示意图；

图6A为本实施例提供的方案的方法流程示意图；

图6B为本实施例提供的方案的文件排序示例图；

图7为本实施例提供的方案的方法流程示意图；

图8为本实施例提供的方案的方法流程示意图；

图9为本实施例提供的终端设备的结构示意图；

图10为本实施例提供的服务器的结构示意图。

具体实施方式

在介绍本申请的实施例之前，首先介绍本申请的实施例中可能出现的几个概念。应理解的是，以下的概念解释可能会因为具体实施例的具体情况有所限制，但并不代表本申请仅能局限于该具体情况，以下概念的解释伴随不同实施例的具体情况可能也会存在差异。

应用文件：本实施例中指的是应用启动并运行所需要的多个文件，包括启动应用所必须的文件、以及启动后运行该应用各个功能所分别需要的文件等。应用文件的部署方式有多种，例如直接部署在终端设备中，例如手机上预安装的应用，终端设备可以无需下载文件就直接启动并运行该应用。而在本实施例中，应用文件被应用开发者发布在服务器上(通常以文件包的形式发布)，终端设备在需要启动该应用的时候才从服务器上下载这些文件，下载其中的部分文件之后才能运行该应用。

文件包：由多个文件聚合成的一个文件。在一种实现方式下，每个文件在聚合之前分别被压缩，压缩之后的多个文件再进行聚合。应用的文件包，指的是应用的多个文件聚合成的一个文件。

端侧：指终端设备或终端设备上运行的软件(例如客户端软件)。

云侧：或者称之为网络侧，通常包括一台或多台服务器，端侧可通过网络访问云侧服务器上的特定数据或服务。

流式下载：通过一条网络提供的连续的、实时的下载方式，而且无需等到内容全部下载完成即可使用。

下面依据附图介绍本申请提供的技术方案的多种实施例。

请参考图1，为本实施例所应用的网络示意图。本实施例提供的方案中的一部分方法可以应用在如图所示的各种端侧的设备上，比如个人计算机、智能手机、平板电脑、智能车载装置、人工智能设备等。本实施例提供的方案中的另一部分方法可以应用在云侧的服务器上，服务器的类型有很多中，方法由一台服务器实现，也可以分布式地由多台服务器实现，其中一台服务器可以指代一台物理装置，也可以指代一台应用了虚拟化技术的虚拟化设备。端侧设备和云侧设备通过有线或无线网络技术建立通信。

另外，本实施例提供的方案中还有一部分在应用开发阶段实现，应用的开发通常是应用提供商在自己的设备上开发的，开发完成后部署到云侧提供的服务上，本实施例下面将以此为例描述，但在其它一些实施例中，若云侧服务器或端侧设备也具备构建应用的能力，构建应用的时候也可以采用本实施例提供的方法(例如下文将会提到的开发侧初始排序方法)。

请参考图2，为本实施例提供的一种系统架构示意图。本实施例提供的方案的一部分实施/部署在终端设备(端侧)中，可作为终端产品的一部分；一部分实施/部署于云侧的服务器，可作为云产品的一部分；还有一部分实施/部署在集成开发环境(integrateddevelopment environment，IDE)中，可作为IDE产品的一部分。

如图2所示，开发侧包括初始化排序单元210和包管理单元220，初始化排序单元210又包括静态扫描模块211和预执行模块212，包管理单元220又包括打包模块221。具体的，开发者首先进行应用开发，生成多个与应用相关的文件，然后这多个文件经过压缩后形成压缩后的文件，然后利用初始化排序单元210对这多个压缩过后的文件进行排序(或不经过压缩直接排序)，最后通过包管理单元220将这多个文件按照初始化排序单元输出的排序结果或排序因素打包成一个文件包，并将该文件包发布到云侧的服务器上。云侧的服务器存储该文件包，等待端侧的获取请求或在某种场景下主动将该文件包发送到端侧。

需要说明的是，压缩是可选项。文件包是多个文件的聚合(按顺序拼接成一个文件)。如果需要压缩的话，在流式下载的模式下，通常是对每个文件进行单独压缩后再拼接。相应的，在使用时，也是每下载完一个文件，解压一个文件。

云侧的服务器上包括包管理单元240和数据处理单元230，其中，包管理单元240又包括传输模块242和重构模块241，数据处理单元230包括数据处理模块231。端侧的终端设备上部署有运行时单元250，该运行时单元250包含下载模块251、启动模块252和数据统计模块2532。开发者完成应用的开发以及将应用部署到云侧之后，端侧和云侧将会继续协同完成本实施例提供的方法。

应用开发者通过集成开发环境开发出可在终端设备中快速打开的应用，并将该应用打包上传到云端服务器上。当用户在终端设备上发出启动该应用的指令之后，会触发终端设备到相应的云端服务器下载该应用的文件包。文件包下载完成后，终端设备加载应用首次启动所需的资源，展示应用的第一个页面。在本实施例提供的方案中，在应用下载的过程中，终端设备优先下载首次启动应用所需的资源，从而不用等待整个文件包下载完成就可以实现应用的启动，提高了应用启动速度，从而提升了用户体验。

现有技术的分包方案具备很多缺点，例如，开发者需要依据分包的原则，分析自己的应用结构与逻辑，对程序进行划分，当业务逻辑复杂的时候，不一定能做到理想的分拆效果；分包方案对多调用关系有限制，分拆的子包之间无法实现自愿的访问；拆分方案不通用，对小游戏包，资源包等不同格式要重新设计。IDE，云端服务器等都需要配合分包进行相应的设计与改动，等等。但是本方案不拆包，而开始可以结合流式下载的方式，优先传输应用启动所需文件(也就是使用概率100％的文件)，避免了分包方案的不足，同时又满足用户的快速启动需求。

请参考图3，为本实施例提供的手机应用启动加载场景中的部署与实现形态，着重展示了与本实施例相关的各系统内外部组件及其相互关系，所涉及的装置可以被分为三种，一种部署于IDE内部作为工具提供给开发者使用，一种作为云侧的一部分在服务器进行部署，一种作为运行时引擎的一部分在手机上部署。

如图所示，数据统计模块353、下载模块351以及启动模块352部署在手机的运行时引擎350中。数据处理模块部署在服务器的大数据平台330中，重构模块341和传输模块342部署在包管理平台340中，其中包管理平台340和大数据平台330可以部署在同一台服务器，也可以部署在不同的服务器上。静态扫描模块311、预执行模块312以及打包模块321部署在开发侧的集成开发环境(IDE)中。

静态扫描模块311属于IDE工具链的一部分。静态扫描模块311用于对应用相关的多个文件执行静态扫描，静态地分析出这多个文件之间的引用关系，作为打包模块321的其中一项输入。预执行模块312也属于IDE工具链的一部分。预执行模块312用于对应用执行预执行，动态地分析出这多个文件间的引用关系，作为打包模块321的另一项输入。

打包模块321属于IDE工具链的一部分，用于将这多个文件打包成文件包并将该文件包发送至云侧的服务器中。打包模块321依赖静态扫描模块311与预执行模块312的执行结果，生成文件包中文件的初始排序。

数据统计模块353用于统计该应用在手机上运行的相关信息，包括各个文件的打开顺序、打开次数等，以及应用运行时的位置、用户的标识等个性化信息。本实施例中数据统计模块353将统计到的信息上传至服务器进行存储，以便于服务器上的数据处理模块331对这些数据进行统计分析。

需要说明的是，同一终端设备可能允许不同的用户登陆使用，所以用户的标识指的是唯一标识一个终端设备用户的信息，可能是用户名、电话号码或身份信息等。

数据处理模块331位于云侧服务器上，用于分析数据统计模块353上报的数据，进一步的云服务器本身也可以具备数据统计能力，统计端侧各种手机的数据，那么数据处理模块331对这些数据也进行处理。数据处理后的结果反馈给重构模块341。

重构模块341负责对文件包中的多个文件进行动态地重排。重排的依据来源于数据处理模块331，还有可能来源于传输模块342的反馈。重排以文件包中的初始化排序为基础，根据数据处理模块331和/或传输模块342的不断反馈，持续动态更新文件的排列顺序。

进一步的，重构模块341还可以依据每个手机上报的个性化信息，为不同的手机生成个性化的排序。

需要说明的是，如果文件包中的每个文件采用了压缩技术来压缩，那么重排是以压缩后的文件为基本单元的，重排过程不需要解压，只是调整文件包内文件的拼接顺序。

在一些实施例中，“重排”可以是重新排列所有文件，生成重拍后的新的文件包；在另一些实施例中，“重排”可以是生成一个新的排序结果，传输模块按照该排序结果从文件包中读取一个个的文件，放入传输的缓冲区内，等待传输到端侧。

传输模块342用于服务器向手机传输数据。传输的数据由文件包的文件依次排列拼接而成，排列的顺序由重构模块341生成。

在下载的过程中，下载模块351可能反馈给传输模块342调度信息，所述调度信息中包含需要调度的文件的信息(例如文件标识)。进一步的，所述调度信息中还可以包含用于指示该文件在文件流中的优先级的信息，以便于要求提升该文件在文件流排序中的优先级。收到调度信息之后，传输模块342需要实时调整该文件的优先级，以便于尽快下载该文件。

需要说明是的，调度信息通常是在需要提升一个(或多个)文件的优先级的时候才被发送的，但是在本申请也不排除在某些情况下手机发送调度信息的目的是用来指示服务器降低一个(或多个)文件的优先级。如果这两种情况都涵盖，调度信息中还可以包括用于指示是提升或降低的信息。

下载模块351用于发起并接收应用的文件包。下载模块351会按照顺序依次接收由传输模块342下发的文件，当启动应用所需的那部分文件全部下载完成后，通知启动模块352启动该应用。

启动模块352负责应用的启动。启动模块352在收到下载模块351的通知后启动应用。

请参考图4，为本实施例提供的应用下载方案的整体流程示意图。该方案主要包括开发阶段S410、下载执行阶段S420、数据采集阶段S430和数据处理/调整阶段S440。

开发阶段S410需要完成文件包中全部文件的初始排序与文件包的部署。具体的，初始排序工具搜集文件包中文件信息，根据搜集到的信息为文件包中的文件进行排序(S411)，该排序在本实施例中称之为初始化排序。将初始化排序后的文件包上传至服务器存储区，即文件包的部署(S412)。

下载执行阶段420需要完成文件包从服务器到手机的下载过程。文件包在服务器存储区部署后，手机可以向服务器发送应用文件包的下载请求。当接收到这样的请求之后，服务器将所有文件按排成一个文件流，返回给手机(S421)。文件流中的文件按初始化的顺序依次排列。手机接收到服务器返回的文件流后，依次读取文件，写入缓存(S422)。当启动应用所需的那部分文件缓存完成，应用即可执行启动流程(S423)。文件流中后续文件继续传输。

当整包下载完成前，用户若访问了某个未下载完成的文件，手机会立即向服务器发起网络请求，服务器实时优先传输该文件，手机则等待该文件下载后，继续执行后续流程。

数据采集阶段430需要完成系统运行过程中所有所需数据的收集。图4中仅是示例性的标识了数据采集阶段，其实，该阶段的数据采集操作可以发生在服务器或手机系统运行阶段的任何阶段。例如，在手机请求下载文件的阶段，手机可以对用户的个性化信息(用户ID、位置信息、特定文件ID等)进行采集；在手机的文件使用阶段，手机可以对文件的访问次数、访问顺序等信息进行采集；在文件流中文件被调整优先级时，服务器或手机可以对该动态调整的信息进行统计。

服务器收集到的数据可以直接存储在服务器的数据存储区内。手机收集的数据需要上传至服务器(S431和S432)，并最终汇集存储到云侧的数据存储区内(图4中的“统计数据”所标识的存储区)。手机收集的数据可以直接上传至服务器，也可以经过一定形式的处理后再上传至服务器。该数据存储区与前述文件包被存储的存储区(图4中“文件包”所标识的存储区)在实际实现时可以是同一个存储区，也可以不同的存储区，具体存储方式可以有多种，图4中仅为了便于理解将两者分开画出，实际如何存储以及存储位置可借鉴任何数据存储方式，本实施例对此不做限定。

数据处理/调整阶段S440需要完成对数据存储区内的统计数据的处理(S441)，并依据处理结果对文件排序进行调整(S442)。当数据采集阶段S430采集到一定量的数据后，服务器对采集的部分或全部数据进行分析，依据分析的结果对已有的排序进行动态调整，让文件的排序更加贴近用户的需求，以减少出现前述优先级调整的可能性。动态调整后的排序用于接下来的文件包传输(S421)。

排序动态调整的时机可以有实时和非实时两种。在实时调整的情况下，数据存储区的数据发生更新后即刻触发数据处理的操作，计算新的文件排序，当文件包收到下载请求后直接应用新的排序。在非实时调整的情况下，数据处理模块按一定的时间间隔从数据存储区内读取数据，当数据有更新时则进行数据处理生成新的文件排序，当文件包被访问时应用新排序。

下面分阶段详细介绍本实施例提供的应用下载方法。

请参考图5，为本实施例提出开发者在开发阶段S510基于IDE编译过程对文件包进行初始化排序的方法，从而在文件包部署之初，使文件包在部署之初就有一个相对合理的排序。

开发阶段S510需要完成文件包中全部文件的初始排序与文件包的部署。在该阶段根据静态扫描(S511)的结果和应用预执行(S512)的结果对文件包中的文件进行排序。

具体的，首先为初始排序工具(可执行脚本)传入未经过排序的初始文件包。初始排序工具对文件包中的文件逐个进行文本静态扫描，匹配页面路由跳转API、文件引用等关键语句信息并记录下来作为扫描记录。依次读取该扫描记录，以入口文件为根节点，将每个条目中被引用文件置为引用文件的子节点。分析完扫描记录后，则构建了一棵完整的引用关系树。

页面路由跳转API是代码层面的一个API，用于从一个页面跳转到另一个页面。例如：NativageTo(“page2”)意思是跳转的page2页面，则说明当前文件引用了page2.js文件。

文件引用语句是表示文件之间引用关系的语句，例如：Image.src＝“path/to/image.png”意思是image.png文件被当前文件引用；Require(“path/to/foo.data”)意思是foo.data文件被当前文件引用。当前文件指的是包含该语句的文件。

需要说明的是，静态扫描一般是扫描每个文件的全文，当然有些对分析排序无用的文件类型可以跳过，例如图片类型(它不存在对其它文件的引用)。

但是，静态扫描只能进行静态的字符串模式匹配，无法对动态处理的情况进行识别。

预执行(S512)是将应用在IDE的模拟器中启动，模拟操作该应用(例如可以基于猴子测试Monkeytest实现)，在页面路由跳转API执行时以及本地文件读取时进行打点统计，然后记录下来作为引用记录。模拟操作完成后依次读取该引用记录，以静态扫描生成的引用关系树为基础，根据该引用记录更新该引用关系树。分析完全部引用记录后，则完成了对引用关系树的刷新。对刷新后的引用关系树进行遍历，生成初始的文件排序，遍历方法例如可以采用广度优先遍历。然后，按生成的文件排序对文件包中的文件排序，生成新的文件包并部署到云侧的存储区中。

Monkeytest是安卓系统自动化测试的一种手段，就是模拟用户的按键输入、触摸屏输入、手势输入等各种各样的操作方式去测试被测试系统，以测试系统的稳定性和兼容性。

下载执行阶段S520主要完成文件包从服务器到手机的下载过程。该阶段与本实施例前述S420阶段类似，其中包含的S521-S523可相应参考前述S421-S423，在此不再赘述。

需要说明的是，当文件包全部下载完成前，终端设备访问了某个未下载完成的文件，终端设备需要立即向云侧发起网络请求，云侧可以实时提升该文件在未传输完的文件流中的排序，优先下载。具体的，在一种实现方式下，云侧可以不改变本地存储的文件的排序，而是传输模块在收到文件调度请求后，在未来得及进行传输的文件所在的缓冲区中，把要求调度的文件移动到该缓冲区的最前端，优先执行传输动作。

上述方法通过静态和动态结合的方式生成合理的初始文件排序，并按照流式下载的方式将应用中的多个文件按顺序提供给终端设备，使得终端设备能够尽快获得应用运行所需的文件，从而提升应用的运行速度，提升用户体验。

进一步的，本实施例还提供一种基于大数据统计的排序调整方法，通过收集应用相关的运行信息，对云侧文件包中的文件排序进行动态调整，从而使得云侧的文件排序能够更贴近用户的使用习惯。通过对排序的调整，使得最可能被端侧使用的文件能够尽早被下载，减少文件下载的等待时间，提升应用的运行速度，从而提升用户体验。

请参考图6A，为基于大数据统计的排序方法的流程示意图。其中的下载执行阶段S620与本实施例前述S420和S520阶段类似，其中包含的S621-S623可相应参考前述S421-S423和S521-S523，在此不再赘述。

数据收集阶段S630要完成调整排序所需要的数据的收集。该阶段的数据采集操作可以发生在系统运行阶段的任何阶段。在手机侧，数据统计模块(图3中的353)可以对应用的启动次数、各个文件的访问次数、各个文件的访问顺序等信息进行统计(S631)。其中有的信息可以直接采集获得，有的信息可通过采集到的信息分析处理获得。

具体的，通过在文件访问函数的位置插入打点统计的代码，对访问文件的名称、时间、当前页面文件(即引用此文件的文件，或者说是引用关系的上一级)等信息进行记录，从而获得以上各种信息。

手机收集到的数据发送到服务器(S632)，在数据达到一定量级之后，由服务器完成大数据分析(S641)，并基于该大数据分析的结果对应用文件包内的文件排序进行调整(S642)。大数据分析主要包括数据清洗、计算各个文件的访问概率以及计算文件排序三个过程。

1)数据清洗。在一次应用启动到关闭的过程中，每个文件的访问次数保留至多一次。有相同入口点的依赖关系，保留最长的。参考图6B文件依赖关系示例图，在应用的一次启动到关闭的过程中，文件之间的依赖关系可能被记录下如下3条：

index.js→p3.js→p1.js

index.js→p3.js

p3.js→p1.js

经过数据清洗后，只保留第一条index.js→p3.js→p1.js。

需要说明的是，图6B示例性地给出了一些文件名称作为文件的标识，在其他实施例中，文件的标识还可以包括文件的存储路径。

2)计算文件访问概率。文件F访问概率＝文件F访问总次数/应用启动总次数。文件访问概率为该文件被访问的概率。文件访问总次数为该文件被访问的总次数。图6B中示例性的示出了三个文件的访问概率。

3)计算文件排序：

a)将文件访问概率换算为排序权重，依据权重由高到底进行文件排序。最大值为1，代表启动所必须的文件。通常来说，文件的访问概率越高，则该文件的权重越大，但是访问概率并非影响权重的唯一因素，例如前文提到的端侧在下载文件包的过程中发出的实时文件调度请求，这种请求也会影响文件的权重。

b)收集上来的数据中也包含文件引用关系，由于这些数据是大量实际数据统计得出的，所以几乎包含了所有引用关系，因此通过这些数据中的文件引用关系生成引用关系树。引用关系树中可能存在多个根节点，多个根节点视为同级节点。

c)对于有相同权重的文件,总访问次数(清洗前)大的排在前面。

需要说明的是，以上描述的大数据分析过程仅是示例，大数据分析方法有多种，尤其是具体到数据清洗方法或数据计算或分析方法等，凡能达到优化本申请提出的文件排序，以达到提高应用启动/运行速度的大数据分析方法均可以应用在本申请提供的方法中。

本实施例提供的方法还可以针对不同类型的终端用户做个性化的文件排序优化，例如对于某些类型的应用，将该应用的用户按照年龄划分为多个年龄段，对不同的年龄段的用户分别进行大数据分析，有针对性地为不同年龄段的用户优化文件排序，适应不同的应用使用需求；或者针对不同类型的应用，分别进行优化等。

通过采集用户对应用的使用信息，并依据大数据分析的方法将文件排序进行优化，能够使得文件排序更加贴近用户的使用习惯，从而进一步提升应用启动/运行效率。

进一步的，参考图7，本实施例还提出一种基于实时调度信息对文件包排序进行动态调整的方法，从而在下载过程中，不断调整文件的结构到更优的排序。

如图7所示，在下载执行阶段S720中，当应用启动所需的文件下载完成后，应用即可启动(S721-S723)，启动后剩余的文件继续下载。若在文件包全部下载完成前，应用访问了某个未下载完成的文件(S724)，则进入实时调整的流程。

在本实施例中所有的文件访问都是通过异步调用的API实现的。当应用调用该API时，如果相应的文件在缓存中(说明该文件已经被下载下来)，则直接读取该文件并执行回调函数。如果文件不存在，则保存文件名与回调函数，另创建一个网络线程，当前调用返回。通过创建的网络线程，手机向服务器发起调度请求，告知服务器缺失的文件名。

服务器收到调度请求后，可以有两种方式实施响应：1)提升该文件在未传输完的文件流中的排序至最前端，优先下载。2)通过另一个线程或进程直接在当前请求的响应中返回该文件。

手机向服务器发起调度请求之后，每当下载完成一个文件时，检测文件名是否与本地保存的那个文件(请求的文件)同名，如果一样则执行保存的那个回调函数，返回文件内容。

实时调度信息也需要收集，使得服务器可以基于这些信息优化文件排序。因此，在服务器收到调度的请求并实施调度的同时，服务器负责记录此次调度涉及的文件的文件名。具体的，在服务器响应该调度请求的函数的结尾处，插入数据收集的代码，以记录时间、该调度请求所请求的文件名等信息。

实时调度信息被收集完成后，则需根据实施调度信息动态调整相应文件的排序。排序调整的时机可以有实时的和非实时两种。在实时调整的情况下，一旦收集到数据有更新，则立即计算新的文件排序。当服务器收到文件包的下载请求后直接应用新的排序。在非实时调整的情况下，可以为触发调整设定一个调度次数的阈值(例如1000次)，每间隔一段时间(例如10分钟)，去检测该阈值是否达到，当达到所设置的阈值后，按预设的配置进行文件排序权重的调整。例如，文件A被请求调度的次数到了1000次，就去调整文件A的权重。文件新权重＝文件旧权重*1.1。权重更新后，按权重大小刷新文件排序。

可见，用户对应用的使用习惯可能会变，仅仅基于历史使用信息获得的排序结果可能会慢慢变得不准确，通过本实施例提供的方法，可以融合实时调度信息来对文件排序进行刷新，能够实现根据用户对应用使用的实时信息来对应用的文件进行排序，令排序更贴近用户使用习惯。

在其它一些实施例中，实时调度信息可以不用来对排序结果进行刷新，或者不立即用来对排序结果进行刷新，即便如此，通过本实施例以上描述的调度请求的发送和响应方式，也能够将用户当前需要的文件及时反馈给用户，满足用户的使用需求，提升用户对应用的使用体验。

图7中的其它未描述的处理过程，例如数据采集阶段S730可参考前述实施例的数据采集阶段S630，实时调度信息的采集和应用运行的其他信息的采集可以一并在本申请提供的方案中使用；数据处理/调整阶段S740和前述实施例类似，只是本实施例中处理的数据中包括了实时调度信息。

需要说明的是，在调整文件排序时，实时调度信息可以和前述实施例采集的应用运行时信息一起考虑，比如对文件A实时调度一次，就相当于文件被访问次数增加了一次；另外，实时调度信息还可以单独考虑，比如例用前述实施例获取的数据调整排序之后，根据文件A的实时调度次数适当提高该文件的优先级。具体结合方法有多种，本实施例不做限定。

本实施例中提供的文件下载方法还可以在手机下载文件的过程统计手机的个性化信息，并根据这些个性化信息有针对性地对应用的文件包的排序进行调整。

请参考8所示，为本实施例提供的一种文件排序调整方法。

在下载执行阶段S820，手机向服务器发送下载请求(S821a)，服务器接收到该请求之后开始文件包的传输(S821)，手机侧接收文件包(S822)。

在文件下载之前，下载过程中或下载之后，手机采集自身的个性化信息(S821b)，个性化信息包括应用运行时手机的位置、当前用户的ID等信息，并将采集到的信息上传到服务器(S832)。

服务器收集到不同手机的个性化信息，再结合前述统计到的文件打开次数等数据以及前述数据分析方法，可以进行一系列的数据处理以分析出用户个性化信息与实际使用资源的关联性等信息(S841)。举例来说，服务器通过数据统计分析可以挖掘出手机位置与文件使用概率的关系，挖掘的结果例如是：

手机在位置A时，文件1使用概率是90％；

手机在位置B时，文件1使用概率是5％；

这说明当手机位于不同的位置时，同一个应用内同一个文件的使用概率是不同的，所以在文件1的使用概率换算为文件1的权重时要考虑到手机的当前位置。例如若手机位于位置A，则文件1的权重为0.9，而若手机位于位置B，文件1的权重为0.01。不同的权重会影响文件1在所有文件中的排序，从而影响其下载顺序。可见，用户在不同的地方使用手机，其使用习惯可能不一样，那么针对这种不同的使用习惯，本实施例能提供不同的文件下载顺序，从而尽可能的贴近用户需求。

服务器会根据S841步骤的处理结果对文件包的排序进行调整(S842)。这里的“调整”可以是根据前面数据处理的结果直接修改文件包内文件的排序，重新生成新排序后的文件包；也可以是记录下文件在不同位置的文件访问概率或权重，以便于后续从多种排序可能性中选择一种。在一些实施例中，服务器在收到手机的应用下载请求之后，从该请求中读取手机的当前位置信息，根据手机的当前位置确定应用文件包中文件的排序，并按照该排序向手机发送文件。

需要说明的是，基于个性化信息的排序调整通常是一种非实时的调整。服务器的数据处理模块按一定的时间间隔的从统计数据存储区内读取数据，当数据有更新时进行数据处理生成新的基于个性化信息的文件排序，当文件包被访问时，根据手机当前的个性化信息应用不同的排序。

可见，本实施例通过将手机的位置等个性化信息加入到文件排序的考虑因素中，能够使得文件排序更加贴近实际，例如同一个应用，当用户位于家和位于公司时，其使用习惯可能是不一样的，所以对每个功能或页面的访问可能性也是不一样的，所以将位置因素纳入排序的考虑因素中，能够使得排序更加贴近用户在不同地点的真实使用习惯，从而尽快下载用户所需文件，减小用户的等待时间，提高用户体验。

请参考图9，为本实施例提供的一种计算机系统的结构示意图。该计算机系统可以为终端设备(参考图1各种类型的终端设备)。该计算机系统包括通信模块910、传感器920、用户输入模块930、输出模块940、处理器950、音视频输入模块960、存储器970以及电源980。

通信模块910可以包括至少一个能使该计算机系统与通信系统或其他计算机系统之间进行通信的模块。例如，通信模块910可以包括有线网络接口，广播接收模块、移动通信模块、无线因特网模块、局域通信模块和位置(或定位)信息模块等其中的一个或多个。这多种模块均在现有技术中有多种实现，本申请不一一描述。

传感器920可以感测系统的当前状态，诸如打开/闭合状态、位置、与用户是否有接触、方向、和加速/减速，并且传感器920可以生成用于控制系统的操作的感测信号。

用户输入模块930，用于接收输入的数字信息、字符信息或接触式触摸操作/非接触式手势，以及接收与系统的用户设置以及功能控制有关的信号输入等。用户输入模块930包括触控面板和/或其他输入设备。

输出模块940包括显示面板，用于显示由用户输入的信息、提供给用户的信息或系统的各种菜单界面等。可选的，可以采用液晶显示器(liquid crystal display，LCD)或有机发光二极管(organic light-emitting diode,OLED)等形式来配置显示面板。在其他一些实施例中，触控面板可覆盖显示面板上，形成触摸显示屏。另外，输出模块940还可以包括音频输出模块、告警器以及触觉模块等。

音视频输入模块960，用于输入音频信号或视频信号。音视频输入模块960可以包括摄像头和麦克风。

电源980可以在处理器950的控制下接收外部电力和内部电力，并且提供系统的各个组件的操作所需的电力。

处理器950可以指示一个或多个处理器，例如，处理器950可以包括一个或多个中央处理器，或者包括一个中央处理器和一个图形处理器，或者包括一个应用处理器和一个协处理器(例如微控制单元或神经网络处理器)。当处理器950包括多个处理单元时，这多个处理单元可以集成在同一块芯片上，也可以各自为独立的芯片。一个处理器可以包括一个或多个物理核，其中物理核为最小的处理模块。

存储器970存储计算机程序，该计算机程序包括操作系统程序972和应用程序971等。典型的操作系统如微软公司的Windows，苹果公司的MacOS等用于台式机或笔记本的系统，又如谷歌公司开发的基于

的安卓

系统等用于移动终端的系统。前述实施例提供的方法中位于端侧的部分可以通过软件的方式实现，作为操作系统程序972的一个功能，可以默认开启，也可以在用户的指令下开启；也可以作为一个应用。

存储器970可以是以下类型中的一种或多种：闪速(flash)存储器、硬盘类型存储器、微型多媒体卡型存储器、卡式存储器(例如SD或XD存储器)、随机存取存储器(randomaccess memory,RAM)、静态随机存取存储器(static RAM,SRAM)、只读存储器(read onlymemory,ROM)、电可擦除可编程只读存储器(electrically erasable programmable read-only memory，EEPROM)、可编程只读存储器(programmable ROM,PROM)、磁存储器、磁盘或光盘。在其他一些实施例中，存储器970也可以是因特网上的网络存储设备，系统可以对在因特网上的存储器970执行更新或读取等操作。

处理器950用于读取存储器970中的计算机程序，然后执行计算机程序定义的方法，例如处理器950读取操作系统程序972从而在该系统运行操作系统以及实现操作系统的各种功能，或读取一种或多种应用程序971，从而在该系统上运行应用。

存储器970还存储有除计算机程序之外的其他数据973，例如本申请中涉及的应用文件，以及运行信息、个性化用户信息等统计数据等。

图9中各个模块的连接关系仅为一种示例，本申请任意实施例提供的方法也可以应用在其它连接方式的终端设备中，例如所有模块通过总线连接。

请参考图10，为本实施例提供的一种计算机系统的结构示意图。该计算机系统可以为服务器。该计算机系统包括处理器1001、存储器1002、发送器1003、接收器1004以及连接以上各器件的总线1005。

存储器1002用于存储软件程序，处理器用于执行该软件程序以实现前述任意一个实施例中云侧实现的方法。接收器1004和发送器1003通常与有线或无线网络配合，用于从服务器外部接收数据，例如接收运行信息，或向服务器外发送数据，例如发送应用文件。处理器1001可以是单核，也可以是多核。

需要说明的是，图9和图10的计算机系统可相互参考。

需要说明的是，前述实施例中提出模块或单元的划分仅作为一种示例性的示出，所描述的各个模块的功能仅是举例说明，本申请并不以此为限。本领域普通技术人员可以根据需求合并其中两个或更多模块的功能，或者将一个模块的功能拆分从而获得更多更细粒度的模块，以及其他变形方式。以上各个实施例的有益效果可互相参考。

以上描述的各个实施例之间相同或相似的部分可相互参考。本申请中的“多个”若无特殊说明，指两个或两个以上，或“至少两个”。本申请中出现的A和/或B包含三种情况A、B以及A和B。

以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理模块，即可以位于一个地方，或者也可以分布到多个网络模块上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。另外，本发明提供的装置实施例附图中，模块之间的连接关系表示它们之间具有通信连接，具体可以实现为一条或多条通信总线或信号线。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上所述，仅为本申请的一些具体实施方式，但本申请的保护范围并不局限于此。

Claims (11)

1.一种应用发送方法，由服务器执行，其特征在于，包括：

获取应用的运行信息，所述应用为在终端设备上正在运行或运行过的应用，所述运行信息与所述应用中的多个应用文件的访问相关；

根据所述运行信息确定传输排序，所述传输排序根据所述应用文件的依赖关系确定，所述依赖关系为应用文件之间的引用关系；

按照所述传输排序向终端设备传输所述多个应用文件；

在还未完成所述多个应用文件的传输之前，还包括：

接收所述终端设备发送的文件请求，所述文件请求用于请求下载按照所述传输排序还未开始传输的请求文件；

根据所述文件请求实时传输所述请求文件。

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

获取所述多个应用文件，所述多个应用文件具有初始排序，所述初始排序是通过文件之间的引用关系确定的。

3.根据权利要求1所述的方法，其特征在于，还包括：若接收到的所述文件请求的数量超过预设阈值，则调整所述传输排序，以提高所述请求文件的传输优先级。

4.根据权利要求1-3任意一项所述的方法，其特征在于，还包括：

获取所述应用的个性化用户信息，所述个性化用户信息包括以下信息中的一种或多种：终端设备的位置、所述终端设备的用户的标识和特定文件的标识；

所述确定所述传输排序包括：根据所述个性化用户信息和所述运行信息确定所述传输排序。

5.根据权利要求4所述的方法，其特征在于，

所述根据所述个性化用户信息和所述运行信息确定所述传输排序包括：计算与所述终端设备的不同位置分别对应的所述应用文件的访问概率和/或依赖关系，确定与所述终端设备的不同位置分别对应的多种传输排序；

所述向终端设备传输所述多个应用文件包括：获取所述终端设备的当前位置，并按照与所述当前位置对应的传输排序向所述终端设备传输所述应用文件。

6.一种应用发送装置，其特征在于，包括：

数据处理模块，用于获取应用的运行信息，所述应用为在终端设备上正在运行或运行过的应用，所述运行信息与所述应用中的多个应用文件的访问相关；

重构模块，用于根据所述运行信息确定传输排序，所述传输排序根据所述应用文件的依赖关系确定，所述依赖关系为应用文件之间的引用关系；

传输模块，用于按照所述传输排序向终端设备传输所述多个应用文件；

所述传输模块还用于，接收所述终端设备发送的文件请求，所述文件请求用于请求下载按照所述传输排序还未开始传输的请求文件；根据所述文件请求实时传输所述请求文件。

7.根据权利要求6所述的装置，其特征在于，还包括：

静态扫描模块，用于静态扫描所述多个应用文件，以获取所述多个应用文件之间的引用关系的第一结果；

预执行模块，用于预执行所述多个应用文件，以获取所述多个应用文件之间的引用关系的第二结果；

打包模块，用于根据所述第一结果和第二结果排列所述多个应用文件。

8.根据权利要求6所述的装置，其特征在于，

所述重构模块还用于：若接收到的所述文件请求的数量超过预设阈值，则调整所述传输排序，以提高所述请求文件的传输优先级。

9.根据权利要求6-8任意一项所述的装置，其特征在于，

所述数据处理模块还用于：获取所述应用的个性化用户信息，所述个性化用户信息包括以下信息中的一种或多种：终端设备的位置、所述终端设备的用户的标识和特定文件的标识；

所述重构模块还用于：根据所述个性化用户信息和所述运行信息确定所述传输排序。

10.根据权利要求9所述的装置，其特征在于，

所述重构模块具体用于：计算与所述终端设备的不同位置分别对应的所述应用文件的访问概率和/或依赖关系，确定与所述终端设备的不同位置分别对应的多种传输排序；

所述传输模块具体用于：获取所述终端设备的当前位置，并按照与所述当前位置对应的传输排序向所述终端设备传输所述应用文件。

11.一种服务器，其特征在于，包括处理器、存储器和发送器，所述存储器用于存储计算机程序，所述处理器用于读取所述计算机程序以实现权利要求1-5任意一项所述的方法。

Images