网络应用的客户端、和用于客户端的资源加载方法与流程

本发明涉及计算机领域，更具体地涉及一种网络应用的客户端、和用于客户端的资源加载方法。

背景技术：

通常，诸如网络游戏、即时通信工具、信息发布平台之类的网络应用包括用于运行在用户终端上的客户端(即，客户端程序)和用于运行在服务器上的伺服端(即，服务器程序)两部分。为了使用网络应用，用户需要首先将网络应用的客户端下载并安装到用户终端上，然后通过网络应用的客户端与网络应用的伺服端进行交互来使用网络应用。

随着网络应用的内容越来越多，网络应用的客户端包含的数据量不可避免地越来越大，因而下载网络应用的客户端所需要的时间也越来越长，这会造成用户对于网络应用的使用上的不便，从而导致网络应用的用户流失。为了节省下载网络应用的客户端所需要的时间，一些网络应用采用了微客户端技术。

微客户端技术的核心思想在于资源分离和按需下载，并且其具体实现包括：在设计网络应用的客户端时只将最初使用网络应用时必需的程序文件和一些不能动态加载的资源文件包括在网络应用的客户端中，然后在用户使用网络应用的过程中根据实际需求逐步下载其他资源文件。目前的微客户端技术主要采用以下两种资源请求/加载方案：1)基于单独文件的资源请求/加载方案；和2)基于场景的资源请求/加载方案。

但是，上述两种资源请求/加载方案存在以下缺陷：1)基于单独文件的资源请求/加载方案适用于浏览器型客户端和用于安装在诸如智能手机、平板电脑之类的移动设备上的轻量级客户端，但并不适合用于安装在诸如台式电脑、笔记本电脑之类的计算机终端上的大型客户端，因为计算机终 端上的大型客户端需要的系统资源极高，而计算机终端大多数情况都是机械硬盘，随机访问性能极差；2)基于场景的资源请求/加载方案虽然适合用于安装计算机终端上的大型客户端，但是用户的使用体验较差，因为每次进入新场景用户都要等待很长时间。

技术实现要素：

鉴于以上所述的一个或多个问题，本发明提供了一种新颖的网络应用的客户端和用于客户端的资源加载方法。

根据本发明实施例的网络应用的客户端，包括应用程序和下载器。其中，下载器被配置为：在接收到来自应用程序的任意一个进程的针对任意一个资源文件的信息获取请求时，判断该资源文件是否已经被完整下载到客户端所安装在的用户终端上；以及如果资源文件已经被完整下载到用户终端上，则向进程发送资源文件的位置信息，如果资源文件尚未被完整下载到用户终端上，则从伺服端下载资源文件并在资源文件被完整下载到用户终端后向进程发送资源文件的位置信息。

根据本发明实施例的用于客户端的资源加载方法，该客户端包括应用程序和下载器，该资源加载方法包括：应用程序的任意一个进程向下载器发送针对任意一个资源文件的信息获取请求；下载器判断资源文件是否已经被完整下载到客户端所安装在的用户终端上，如果资源文件已经被完整下载到用户终端上，则向进程发送资源文件的位置信息，如果资源文件尚未被完整下载到用户终端上，则从伺服端下载资源文件并在资源文件被完整下载到用户终端后向进程发送资源文件的位置信息；以及进程根据资源文件的位置信息读取资源文件。

本发明可以提升客户端的稳定性和下载速度，同时可以保证良好的用户体验。因此，本发明可以使通过客户端进入网络应用的新用户流失率降低，从而更好地起到导入新用户的作用。

附图说明

从下面结合附图对本发明的具体实施方式的描述中可以更好地理解本 发明，其中：

图1是示出包括根据本发明实施例的客户端的网络应用的框图；

图2是示出根据本发明实施例的共享内存的结构示意图；

图3是示出根据本发明实施例的客户端应用程序的任意一个进程实现的资源加载过程的流程图；

图4是示出根据本发明实施例的文件包的结构示意图；

图5是示出根据本发明实施例的下载器实现的对于信息获取请求的响应过程的流程图。

具体实施方式

下面将详细描述本发明的各个方面的特征和示例性实施例。在下面的详细描述中，提出了许多具体细节，以便提供对本发明的全面理解。但是，对于本领域技术人员来说很明显的是，本发明可以在不需要这些具体细节中的一些细节的情况下实施。下面对实施例的描述仅仅是为了通过示出本发明的示例来提供对本发明的更好的理解。本发明决不限于下面所提出的任何具体配置和算法，而是在不脱离本发明的精神的前提下覆盖了元素、部件和算法的任何修改、替换和改进。在附图和下面的描述中，没有示出公知的结构和技术，以便避免对本发明造成不必要的模糊。

下面结合附图详细描述根据本发明实施例的网络应用的客户端和用于客户端的资源加载方法。

图1是示出包括根据本发明实施例的客户端的网络应用100的框图。如图1所示，网络应用100包括客户端112和伺服端104，其中客户端112包括下载器102和客户端应用程序的进程106、108和110。在其它实施例中，客户端可以包括客户端应用程序的更多或更少的进程。

伺服端104被网络应用的所有用户共享，并且被配置为存储客户端应用程序、客户端应用程序开始运行时必需的但是不能动态加载的资源文件、以及可以由客户端112在客户端应用程序的运行过程中动态下载的资源文件，以及在接收到来自客户端112的针对一个或多个资源文件的文件下载请求时向客户端112提供这些资源文件的下载。

下载器102是客户端112的中心，客户端应用程序的进程106、108和110经由下载器102与伺服端104通信。具体地，下载器102被配置为在接收到来自客户端应用程序的任意一个进程(例如，进程106)的针对任意一个资源文件(例如，资源文件F-1)的信息获取请求的情况下，判断资源文件F-1是否已经被完整下载到客户端112所安装在的用户终端上；如果是，则直接向客户端应用程序的进程106发送资源文件F-1的位置信息，否则先从伺服端104下载资源文件F-1并且在资源文件F-1被完整下载到客户端112所安装在的用户终端并被写入相应文件包后向客户端应用程序的进程106发送资源文件F-1的位置信息。客户端应用程序的进程106在接收到下载器102发送的包含资源文件F-1的位置信息的信息获取响应后，将从资源文件F-1的位置信息所指示的位置读取资源文件F-1。

在本实施例中，下载器102发送给客户端应用程序的进程106的信息获取响应除了包括资源文件F-1的位置信息以外，还可以包括资源文件F-1的大小信息、加密方式信息、以及压缩方式信息中的一种或多种信息。这样，客户端应用程序的进程106可以根据来自下载器102的信息获取响应中的上述信息，正确读取资源文件F-1并对资源文件F-1进行解密和解压缩。

在本实施例中，如果客户端应用程序的进程106在发送信息获取请求之后的预定时间内没有接收到来自下载器102的信息获取响应或者接收到的信息获取响应中不包含资源文件F-1的位置信息、加密方式信息、或者压缩方式信息(从而导致客户端应用程序的进程106无法读取或者无法使用资源文件F-1)，则客户端应用程序的进程106将从客户端112所安装在的用户终端上的特定位置读取替代资源文件临时使用，直到接收到资源文件F-1的所有相关信息为止或者直到不再需要资源文件F-1为止。

在本实施例中，在客户端应用程序的进程106、108和110中的第一个启动的进程(例如，进程108)被启动时，客户端112首先判断下载器102和客户端应用程序的版本是否是最新的，如果不是则通过与伺服端104通信将客户端应用程序和下载器102更新到最新版本。这里的更新只是为了保证客户端应用程序和下载器102等必要文件是最新版本，并不会 下载资源文件。接下来，客户端应用程序的进程108判断下载器102是否已经被启动，如果下载器102已经被启动，则客户端应用程序的进程108继续运行客户端应用程序；如果下载器102还未被启动，则客户端应用程序的进程108启动下载器102并且在确认下载器102已经被启动后继续运行客户端应用程序。

在本实施例中，下载器102在启动时会创建一块共享内存用于与客户端应用程序的一个或多个进程通信，其中该共享内存进一步被划分为多个内存块用于缓存分别来自客户端应用程序的一个或多个进程的信息获取请求和/或来自下载器102的信息获取响应。

图2是示出根据本发明实施例的共享内存200的结构示意图。如图2所示，共享内存200被划分为N个内存块202-1、202-2、202-3、...202-N(N是大于0的整数)，每个内存块用于缓存针对任意一个资源文件的信息获取请求或信息获取响应。在本实施例中，信息获取请求与信息获取响应采用相同的消息结构，即每个消息的头部都保存有该消息的发送进程标识符(即，发送进程ID)和接收进程标识符(即，接收进程ID)，并且每个消息的主体部分都保存有该消息的详细信息。应该理解的是，对于作为信息获取请求的消息，其发送进程是客户端应用程序的进程，并且其接收进程是下载器102的进程；对于作为信息获取响应的消息，其发送进程是下载器102的进程，并且其接收进程是客户端应用程序的进程。在信息获取请求被下载器102接收到之后，用于缓存该信息获取请求的内存块将被清空以供缓存进一步的信息获取请求或者信息获取响应；并且在信息获取响应被客户端应用程序的相应进程接收到之后，用于缓存该信息获取响应的内存块将被清空以供缓存进一步的信息获取请求或者信息获取响应。

下载器102在启动时会读取客户端112所安装在的用户终端上的所有文件包内的资源文件的相关信息，包括每个资源文件的位置信息、大小信息、完整性信息、加密方式信息、和压缩方式信息。具体地，每个资源文件的位置信息可以包括以下两方面的信息：包含该资源文件的文件包的标识信息、以及该资源文件在包含其的文件包中的偏移信息。

根据本发明实施例的客户端112通过分离文件的读取和写入操作，极 大地降低了客户端的功能模块之间的耦合性，从而保证了客户端的稳定性。另外，根据本发明实施例的客户端112将文件下载操作集中在下载器102中处理，可以支持客户端应用程序的多个进程同时运行，而无需考虑客户端应用程序的进程之间的读写文件的同步问题。

在本实施例中，考虑到网络和用户终端的计算性能，下载器102被配置为在接收到来自客户端应用程序的一个或多个进程的多个信息获取请求时，并不会同时对这些信息获取请求进行响应，而是会将这些信息获取请求加入请求队列中，然后依次对请求队列中的信息获取请求进行响应。另外，当下载器102需要从伺服端104下载多个资源文件时，也不会同时对这些资源文件进行下载，而是会将针对这些资源文件的文件下载请求加入下载队列中，然后依次对下载队列中的文件下载请求所对应的资源文件进行下载。也就是说，下载器102在处理信息获取请求、下载资源文件、以及返回信息获取响应的时候都采用了类似的队列操作，这样的类似于流水线的多级队列操作保证了在单一流程处理缓慢时，不会对其他的流程产生影响，对于瞬时大量请求的处理能力有很大提升。

类似地，当客户端应用程序的任意一个进程(例如，进程106)向下载器102发送分别针对多个资源文件的多个信息获取请求时，客户端应用程序的进程106可以将这些信息获取请求加入获取队列中并依次向下载器102发送这些信息获取请求。同样，当客户端应用程序的任意一个进程(例如，进程106)读取多个资源文件时，客户端应用程序的进程106也可以将分别针对这些资源文件的多个文件读取请求加入读取队列中，并且依次利用这些文件读取请求读取相应的资源文件。

在本实施例中，每个资源文件都有一个初始的优先级，根据优先级不同，下载器102或者客户端应用程序的进程106会对不同的资源文件按照先后顺序进行处理。同时，客户端应用程序的进程106会根据资源文件的类型、复用程度、以及重要性中的一个或多个因素对资源文件的优先级进行修改，并将新的优先级通知给下载器102，下载器102将优先下载优先级高的文件。

下面结合附图，详细描述客户端应用程序的任意一个进程(例如，进 程106)实现的资源加载过程、以及下载器102实现的对于信息获取请求的响应过程。

图3是示出根据本发明实施例的客户端应用程序的进程106实现的资源加载过程的流程图。如图3所示，客户端应用程序的进程106实现的针对任意一个资源文件(例如，资源文件F-X)的资源加载过程包括：

在302处，当客户端应用程序的进程106需要资源文件F-X时，判断客户端112是否已经缓存资源文件F-X的位置信息。如果资源文件F-X的位置信息已经被缓存，则转到314，否则转到304。

在304处，客户端应用程序的进程106向下载器102发送针对资源文件F-X的信息获取请求(为了说明方便，下面称为信息获取请求R-X)。具体地，客户端应用程序的进程106遍历共享内存寻找空闲的内存块，如果共享内存中没有空闲的内存块，则在共享内存中加入一个新的内存块并将信息获取请求R-X写入该新加入的内存块，否则将信息获取请求R-X写入共享内存中的任意一个空闲的内存块。

在306处，客户端应用程序的进程106判断是否在预定时间内接收到了下载器102发送给其的针对资源文件F-X的信息获取响应(为了说明方便，下面称为信息获取响应Q-X)。具体地，客户端应用程序的进程106遍历共享内存，判断共享内存中是否有接收进程为其本身的针对资源文件F-X的信息获取响应Q-X。如果客户端应用程序的进程106在预定时间内在共享内存中获取到了针对资源文件F-X的信息获取响应Q-X，则转到308；如果客户端应用程序的进程106在预定时间内未从共享内存中获取到针对资源文件F-X的信息获取响应Q-X，则转到310。

在308处，客户端应用程序的进程106将针对资源文件F-X的文件读取请求(为了说明方便，下面简称为FR-X)加入读取队列。

在310处，客户端应用程序的进程106向下载器102发送针对资源文件F-X的替代资源文件T-X的信息获取请求TR-X。

在312处，客户端应用程序的进程106接收下载器102发送给其的针对替代资源文件TR-X的信息获取响应TQ-X。然后，在308处，客户端应用程序的进程106将针对替代资源文件TR-X的文件读取请求TR-X加入 读取队列。

在本实施例中，在客户端应用程序的进程106遍历共享内存的过程中，如果发现有消息的接收进程标识符为本进程的标识符，则接收该消息，并将针对该消息所对应的资源文件的文件读取请求加入读取列队。在读取列队中，优先级并不是影响资源文件的排序的唯一因素，通常还会根据资源文件的位置信息来对资源文件进行排序(这是因为，根据资源文件的位置信息所指示的资源文件的存储顺序对资源文件进行读取相比不按照资源文件的存储顺序对资源文件进行读取(即，乱序对资源文件进行存取)，性能更好)。例如，如图4所示，资源文件A、B、C的优先级分别为10、20、30，并且它们所在的位置分别为文件包D的1024字节、文件包E的2048字节、文件包D的4096字节，所以这三个文件的读取顺序是A、C、B。具体地，客户端应用程序的进程106将针对资源文件A、B、C的文件读取请求ReadA、ReadB、ReadC写入读取队列中的顺序可以是ReadA、ReadC、ReadB，因此资源文件A、B、C按照A、C、B的顺序被读取。

图5是示出根据本发明实施例的下载器实现的对于信息获取请求的响应过程的流程图。如图5所示，下载器102实现的对于任意一个信息获取请求(例如，信息获取请求R-X)的响应过程包括：

在502处，下载器102在接收到例如，来自客户端应用程序的进程106的信息获取请求R-X时，将信息获取请求R-X加入请求队列。具体地，下载器102在创建共享内存后开始遍历共享内存，以检测来自客户端应用程序的一个或多个进程的针对一个或多个资源文件的信息获取请求。

在504处，下载器102判断信息获取请求R-X所请求的资源文件(例如，资源文件F-X)是否已经被完整地下载到客户端112所安装在的用户终端。如果资源文件F-X已经被完整地下载到客户端112所安装在用户终端上，则转到516，否则转到506。

在506处，下载器102将针对资源文件F-X的文件下载请求D-X加入下载队列中。

在508处，下载器102按照下载队列中的排列顺序从伺服端104下载 资源文件F-X。

在510处，下载器102判断是否已经完整下载资源文件F-X。如果资源文件F-X已经被完整下载，则转到512，否则转到518。

在512处，下载器102将资源文件F-X加入I/O(输入/输出)队列中，并且按照I/O队列中的顺序将资源文件F-X写入相应文件包(为了说明方便，下面称为文件包D-1)中。

在514处，下载器102判断资源文件F-X是否被成功写入文件包D-1中。

在516处，如果资源文件F-X已经被成功写入文件包D-1，则将包含资源文件F-X的位置信息的信息获取响应Q-X加入通知队列中，否则将包含资源文件F-X的下载失败信息的信息获取响应Q-X加入通知队列中。

在518处，下载器102判断下载资源文件F-X的失败的次数是否还未超过预定次数(例如，3次)。如果是，则转到508，否则转到516(在516处，将包含资源文件F-X的下载失败信息的信息获取响应Q-X加入通知队列中)。

在520，下载器102将信息获取响应Q-X发送给客户端应用程序的进程106。

应该理解，每个信息获取请求所请求的资源文件具有初始的优先级，下载器102根据信息获取请求所请求的资源文件的优先级对请求队列中的信息获取请求进行排序，并且下载器102优先响应所请求的资源文件的优先级高的信息获取请求(即，优先下载优先级高的资源文件)。同时，请求队列中的信息获取请求所请求的资源文件的优先级不是一成不变的，客户端应用程序的进程会根据所请求的资源文件的类型、复用程度、和重要性中的一项或多项对资源文件的优先级进行动态修改，并将新的优先级通知给下载器102。下载器102可以根据资源文件的新优先级对请求队列中的信息获取请求重新排序，然后按照请求队列中的重新排序后的信息获取请求的排列顺序对这些信息获取请求进行响应。根据用户终端的性能不同，会有不同数量的资源文件被同时下载。例如，在用户终端的中央处理器(CPU)为双核无超线程的CPU的情况下，可以同时下载2个资源文 件；并且在用户终端的CPU是4核8线程的CPU的情况下，可以同时下载8个资源文件。当资源文件开始下载时，针对该资源文件的文件下载请求会从下载队列中被移除。I/O列队也是按优先级排序的有序列队，优先级高的文件会被优先写入文件包。

上面所提到的各种队列中的信息获取请求、文件读取请求、文件下载请求等是按照优先级排序的，而在客户端应用程序的运行过程中，这些请求的优先级并不是一成不变的，这就导致这些请求在相应队列中的排序随它们优先级的变化而变化。在示例实施例中，在客户端应用程序的运行过程中，可能会遇到重复使用的资源文件或者被释放的资源文件。如果一个资源文件已经被客户端应用程序的一个或多个进程请求过，则该资源文件的优先级会因为该资源文件被重复使用而提高。另外，如果一个资源文件的重要性提高了，则该资源文件的优先级也会提高。类似地，如果一个资源文件被释放了，则其优先级会降低。当资源文件的优先级改变时，客户端应用程序的进程会在向下载器发送针对该资源文件的信息获取请求的同时向下载器通知该资源文件的修改后的优先级，下载器接收到该资源文件的修改后的优先级后，会调整处理消息、下载文件、写入文件、以及返回消息的列队，进而完成了优先级对于用户体验的调整。

如上所述，在本发明中，由下载器来处理客户端应用程序的进程对资源文件的加载请求，避免了下载操作对客户端应用程序的影响，保证了客户端应用程序的稳定性。客户端应用程序与下载器之间通过共享内存进行通信，而不是传统的管道或套接(socket)连接，使得客户端应用程序与下载器之间通信的性能达到接近程序内部通信的水准。下载器内部各个流程采用了类似CPU流水线的多级列队处理机制，可以从容地处理大量请求，进一步提升了读写文件的性能以及稳定性。而优先级机制的引入则提供了动态调整资源分配策略的能力，使得网络应用内对用户的体验会比现有方案提升很多。

本领域技术人员将理解，还存在可用于实现本发明实施例的更多可选实施方式和改进方式，并且上述实施方式和示例仅是一个或多个实施例的说明。因此，本发明的范围仅由所附权利要求书限制。